Log of the #nice channel on irc.freenode.net

Using timezone: Central European Time
<bonniot>for reference: jar Class-Path is indeed specified as being added on the CP just *after* that containing jar: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html02:44
* bonniot leaves10:56
* bonniot joins11:11
* arjanb leaves11:50
* arjanb joins
* ArtemGr joins12:02
why shouldn't http://rafb.net/paste/results/DcgrS647.html work with a "package-visible" soultion?12:08
if solution is that package method are dispatched thru B.dispatch, then
foo( A this, B that ) is dispatched thru b.dispatch with no problems.
foo( A this, B that ) shouldn't be dispatched from package a anyway, since a know nothing about class B
and when package c imports a, b, it imports foo(A this,B that) from b. then multi-methods will work independent from whatever class-loading is present
method test, in package a, is compiled when nothing is known about b, so it cannot refer to b.dispatch12:21
<ArtemGr>there is no method test(A,B) in package a12:22
<bonniot>int test(A a) = a.foo(a);
what would be the bytecode for that?
<ArtemGr>only package b and packages importing from b knows about test(A,B)
<bonniot>you're confusing foo and test
<ArtemGr>and package b can dispatch thru b.dispatch.12:23
bytecode for test(A) have nothing to do with test(A,B), it's different methods in the dispatch tables
<bonniot>so what bytecode for test?12:24
again, there is no test(A,B), there is foo(A,B)
<ArtemGr>yes, i've meant foo(A,B)12:26
you see the problem?
test must call the dispatch method for foo
<ArtemGr>foo(A) have one signature, foo(A,B) have another signature, these method are different. the proposal is to dispatch foo(A,B) thru b.dispatch, and not thru A. no, i don't see a problem12:27
<bonniot>there is no foo(A)
<ArtemGr>test(A) invokes foo(A), which isn't changed by foo(A,B)
<bonniot>foo is defined inside the class, so it's foo(A this, A that)12:28
there is only one foo method, with two implementations
<ArtemGr>i see. wishful thinking on my side, i suppose : )12:29
could you explain me the problem with classloaders?12:30
<bonniot>ok, np
<ArtemGr>what about class B virtual table. wouldn't it contain correct reference to foo(A,B) ?
about classloaders, i will do a testcase...12:31
<bonniot>btw, i found the spec for Class-Path in manifest. it is indeed added just after the current jar file in the classpath
testcase is great, less formal description is OK too if you like12:32
<ArtemGr>class-path will work if only the main jar is put onto classpath..12:33
what about class B virtual table?
<bonniot>"what about class B virtual table" whatever we do in class B cannot have an influence in this case, since test is compiled without knowledge of it
class-path: yes. that would make the common case quite easy I think12:34
<ArtemGr>why? virtual tables are usually taken from the current class in runtime.
A a = new B() will load virtual table from B
but think of the bytecode of test:
it's calling A.foo(A), or a.dispatch.foo(A,A) if you compile outside classes12:35
in both cases, B is not involved. and the first arg is a runtime A, not a B
sorry, it's a B
my testcase is actually not what I wanted, making another one12:36
<ArtemGr>can't test call a.foo(A) instead of a.dispatch.foo(A,A), that is, use the "virtual table" dispatch?
yes, you can, but it won't work in this new testcase12:38
changed test to take two args
we cannot rely on jvm dispatch to solve all cases, because it only does single dispatch12:39
<ArtemGr>i see12:40
the problem with the classloader is that i compile package b and load it at runtime,12:42
therefore package a is loaded first,
primarily becouse package a is already used by the system when the package b is compiled.
that is why alternative class loading is impossible - can't load class A from package b when it is already instantiated from package a.
<bonniot>well you can, in a different classloader, but i'm not sure that's the solution12:43
maybe it is...
<ArtemGr>i think i can't (re!)load class A from package b when it is already used (have instances)12:44
<bonniot>cannot you already have the b import a, c import a situation? how does it work currently?
or that's the problem you just ran into?
<ArtemGr>i think it is rather a problem when a is always loaded before b.12:45
<bonniot>didn't you say that each package is loaded in its own classloader?12:46
<ArtemGr>is "b import a, c import a" different from "b import a"?12:47
<bonniot>yes, in that c can "overwrite" changes b made to a
but i see there is already a problem with b import a12:48
essentially a is a "template" and b is a main page using a, right?
<ArtemGr>i think i have this problem with a single template (in a testing environment), that is, with a "b import a" and without "c import a".12:50
on the contrary, a is the application, which uses class A
b is the template, compiled from the application, which tries to add multi-method to A
<bonniot>so who import whom?
<ArtemGr>b import a12:51
and b is invoked from a using reflrection
<bonniot>if a is the application, and does not import b, how do you know b is needed. ok, just answered i guess12:52
<ArtemGr>remember, templates are dynamically compiled at runtime
<bonniot>yes, i was considering that
what triggers the compilation of b?12:53
<ArtemGr>and running in the same JVM
b is compiled when it's source is changed by an operator (thru user interface)12:54
<bonniot>ok, so it's compiled eagerly?
<ArtemGr>yes, how the operator will know if his code is alright otherwise?12:55
<bonniot>ok, makes sense
i see better now12:56
where does the data come that directs to b though reflexion?
<ArtemGr>application (a) provides the template (b) with a context (A)12:57
let's call it "Context" instead of "A"12:59
this context is in fact where the muti-methods are often added, becouse is natural to write "static"
"something( Context )" methods.
<bonniot>if you modify a, how do you discover if it broke b?13:00
<ArtemGr>i have a tool wich recompiles all templates present in the application13:01
i evel plan to run niceunit on these templates
<bonniot>so why not directly depend on them instead of using reflexion?
<ArtemGr>becouse they changed and compiled at runtime, without reboot
<bonniot>but a too, no?13:02
<ArtemGr>a(pplication) is compiled by myself at my workstation, it is then sent to servers, where different templates are compiled by it.13:03
so i don't even have the templates at hand
application is single, number of templates will be limitless, templates are added and edited by operators, not by me13:04
the number of templates is already large
think of it as of JSP13:05
how does calling a template through reflexion look like?13:06
(the general idea, not the details)13:07
<ArtemGr>there is a method "main( Template, Context )", i just find it and invoke it.13:08
<bonniot>what's the Template object?
<ArtemGr>it's the template13:10
(defined in "b")
<bonniot>i thought of the template as the package b
and how do you know what template to instantiate, what his name is?13:11
<ArtemGr>it could be just "b", but historically i've made a Template class to be present in that b.
<ArtemGr>application knows where each template is located, as it compiles it, loads it, and invokes it rhtu that loader13:12
every template have it's own loader13:13
templates can have a unique package name also
but currently it's just a different loaders
<bonniot>"knows" how?13:14
sorry for all the questions, but I need to understand the architecture
<ArtemGr>application has it's own id space, where each template have a unique id13:15
there is a unique "controller" class, which is instantiated by this id. it compiles and loads templates.13:16
<bonniot>ok, but how does it get the ids? it scans a dir at runtime? rescans it once it a while?
(i think I'm seeing a possible solution...)13:19
<ArtemGr>identifiers are kept in other objects, it's like an objectDB, only each object is currently backed by a key-value database (with composite keys and values)13:26
<bonniot>ok, but since you say the templates are not know when you write the app, I suppose the ids are somehow discovered at runtime13:29
here's my idea, we'll see if it matches the requirements:
<ArtemGr>identifiers are generated at runtime, using cryptographically strong randomizer13:30
new template (or other object) - new id
<bonniot>you write the app as now, without knowledge of the templates. for clarity, in my architecture i'll call this the framework
this is compiled once for all and sent to the server13:31
on the server, templates can be added dynamically
they are compiled, with template1 import framework, template2 import framework, ...
additionally, when a template is added or recompiled, somce short code is automatically generated, that depends on all the templates and knows how to load them. call that code 'main'13:33
main is compiled after it's generated
if it fails, the new template introduces a problem that needs to be investigated13:34
if now, the generated code becomes the new app. it can be reloaded in the jvm by a main loop doing only that
that's it
no reflexion at all
does that make sense?13:35
(well, reflexion to load the new app, only)
no clean sepatation between templates, bad template from one user can broke everything, or i need a complicated login to "deduce" bad template;
compilation time will grow with the number of templates - more templates more time - and intent of NiceTee was to make the application fast, not slow; there will be a lot of "sleeping" templates on a server - compiled seldom, but present. parsing them all every time will eat too much;
implementation of this round-trip requires a lot of work (startup is already complicated with security sandbox at hand) will complicate things and reduce reliability.13:43
<bonniot>bad templates: you store compiled templates somewhere. as long as a new source causes problems, you don't use it for other templates are modified, so no problem13:44
also it means that the framework and all templates are not recompiled each time, just reloaded from the compiled version, which should be fast
how often are templates modified?13:45
<ArtemGr>yeah, thanks, and if there are conflicts between templates, who will automatically solve them? the system must work without me.
templates are modified every two minutes by a single user, during their development.13:46
<bonniot>conflict can happen in any case. do you prefer the app to fail at runtime?
<ArtemGr>conflict can't practically happen when template is sealed in the classloader, (which impose own security restrictions, by the way, so loading everything into one classloader is another rework).13:47
"do you prefer the app to fail at runtime?" - if that's the only possibility for it not to fail, then i'll prefer to quit this business.13:50
<bonniot>conflicts are something that exist at the source level, i don't think a jvm mechanism can solve it. it might hide the problem, but that's worse
that said, to get a conflict you need to do something quite contrived, so i don't expect to be a problem in practice13:51
<ArtemGr>i don't see how there can be conflicts between b and c, if they are loaded from separate classloaders.
and compiled separately, without b knowing of c, or c of b.
and you propose to compile everything together13:52
becouse if main knows of b and of c, then b knows of c and they can conflict
<bonniot>they can conflict in any case13:53
here's an example
in the framework, an abstract class A
b defines a method methodB(A), and some subclasses B1, B2 of A, for which it implements methodB13:54
c defines a subclass C of A. doesn't know of methodB, so doesn't implement it
what happens when methodB is called on a C ?13:55
<ArtemGr>c knows nothing of methodB
it compiles separately
<bonniot>you mean you never want any two template to interract?13:56
<ArtemGr>no i don't. template can define multiple classes and iteractions. if template is too complicated, it can be made a module. templates are to fast-program or configure things, there is no point in making a complicated programming system from them.13:58
<bonniot>ok. it should be even simpler then13:59
just decouple the part that loads a template from the framework14:00
<ArtemGr>and run the template in a different JVM?14:02
alternatively, compiling templates in a mode that does not put dispatch code in other packages should be sufficient
<bonniot>can it happen that a template overrides a method in the framework?14:04
<ArtemGr>sure, but it is required very seldom and can be avoided for now. currently i can't write even most basic templates.14:06
<bonniot>ok, let's keep this as a possible option, but i want to investigate the other one14:07
basically, your app starts doing something when it gets a request for a page, right?
<ArtemGr>or other event. okay.14:09
<bonniot>and the first thing it does is to find the matching template, and delegate all the work to the template?
<ArtemGr>no. usual template is doing only some part of the rendering. template can also register itself as a plugin and participate in application internal work.14:10
<bonniot>ok, i would need to think more then. what's disturbing me in this architecture is a kind of circular dependency between the app and the templates. it's static in one direction, and by reflexion in the other way, but still circular. but maybe we should first look at the simple solution which should work without changes on your side, if you want14:14
<ArtemGr>forgive me, but i do not think you are doing a useful thing now. you are trying to redesign my application, while i have an upper hand there and have enough creativity for such tasks, i hope.
you should care about the language instead.
the same problem would arise with "eval" implementation, and with any dynamically loaded code, for that matter, so it would be desirable to have some solution in the compiler, (like putting all and every used method into dispatch, i don't know)
about circular dependencies, every application have them: your code is loaded by JVM, uses JVM, implement JVM interfaces and used by the JVM.14:16
<bonniot>i see your point. so let's ust speak about the simple solution now, OK?14:17
<ArtemGr>sure. i will be glad to spoke about the simple solution. i can't compile the Nice with your patch, by the way.14:18
<bonniot>the problem is that you cannot bootstrap now to apply the patch, right? did you try with make? (since that's working fine)
ah, it's only with the patch that it fails? that makes more sense ;-)
<ArtemGr>i've tried on the Linux i have, got another weird error.
no, without a patch it fails too. that's funny. with patch it can't find one method and without it can't find another one.14:19
<bonniot>bootstrap is kind of fragile, because the of partial Java/partial Nice implementation
strange, because as you can see CVS bootstraps (without the patch)
you tried make?14:20
made sure you had a clean CVS tree and the recent bootstrap compiler?
<ArtemGr>yes. will try again now. the error was really weird.14:21
<bonniot>i can work on adding the patch and making it bootstrap
<ArtemGr>do you think changing the classpath should mitigate the bootstrapping error>14:23
<bonniot>changing how?14:24
(btw, when you apply a fix to the compiler, you don't always need to restart a bootstrap. often you can only recompiler the compiler once, and use that)14:25
<ArtemGr>just concentrating on it yet : )
<bonniot>i'm trying to produce a patched version just for you (without a full bootstrap)14:27
classpath for the failing bootstrap is just "classes"...14:28
<bonniot>ok, uploading14:31
it should compile in dispatch classes methods whose first argument is not in the same package as the method declaration
which should solve your problems
<ArtemGr>downloaded. trying...
<bonniot>completely untested ;-)14:33
<ArtemGr>hmm, recompiled libraries (including ru.glim.string), but still can't compile the application. says:14:38
ru.glim.string must be compiled, but no source code is available.
<bonniot>so recompile it! ;-)
sorry, didn't read the first line
probably it's not seeing the recompiled version14:39
check your classpath
btw, there is a way to have more verbosity about where packages are found
<ArtemGr>yes, will try debug.modules14:40
well, it's not the classpath, i'm sure of it.14:44
no such problem with the current bootstrap ( nice.sf.net/nice.jar )14:49
<bonniot>that's only because the new once forces recompilation not compiled by earlier versions of the compiler, to avoid problems14:50
<ArtemGr>i know, it gave me such message before. but now this message is permanent.14:52
<bonniot>the error means that the new compiler sees a compiled version of ru.glim, just not the new one
what is the verbose output?
<ArtemGr> [java] Locating ru.promo.helper:14:53
[java] Source : E:\Peoples\Glim\Promo\build\src\ru\promo\helper
[java] Compiled: E:\Peoples\Glim\Promo\release\nice\ru\promo\helper
[java] Locating ru.glim.string:
[java] Source : none
[java] Compiled: E:\Peoples\Glim\Promo\release\lib\glippets.jar
[java] ru.glim.string: parsing
[java] E:\Peoples\Glim\Promo\build\src\ru\promo\helper\testHelpers.nice: line 3, column 8:
[java] ru.glim.string must be compiled, but no source code is available.
[java] The source path is: E:\Peoples\Glim\Promo\build/src
[java] compilation failed with 1 error
<bonniot>"ls -l" E:\Peoples\Glim\Promo\release\lib\glippets.jar14:54
actually what matters is the date of the ru/glim files inside the jar
"Glim\Promo\build/src" that looks strange, alternating \ and /. does it work?14:55
<ArtemGr>i've recompiled glippets and checked that date is current.
10 minutes ago.
when i've reported the problem.14:56
<bonniot>date inside the jar?
could it be something that doesn't handle timezones well?
(i.e. if nice.lang is dated in the future, then everything always needs to be recompiled ;-)14:57
but it's later in russia...
<ArtemGr>yes, nice.jar you've supplied is dated in the future somehow.14:58
<bonniot>what matters is the dates inside the jar, not the jar file itself
(almost sure)
but if it is, maybe the inside too
<ArtemGr>repacked nice.jar...15:05
wow, now i have Exception in thread "PoolThread-9" java.lang.NoSuchMethodError: nice.tools.compiler.dispatch.compile(Lbossa/modules/Compilation;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V when dynamically compiling NiceTee!..
<bonniot>ah, of course, you interface with the compiler...15:06
you could try recompiling nice.tools.compiler package15:07
<ArtemGr>that is what i do in the bootstrap, isn't it?
<bonniot>yes, but many more things too, that will fail
recompiling only nice.tools.compiler is more likely to work15:08
<ArtemGr>but it is the same error
<bonniot>what is the top of the stack trace now?
i think it can work15:09
i can try it here, actually15:11
yes, looks alright15:12
<ArtemGr>the top of the stack
at ru.glim.nicetee.fun.compile(Unknown Source)
at ru.glim.nicetee.Compiler.compile(tee.nice)
at ru.promo.m.Template.compileNiceTee(Template.java:334)
does it matter?
<bonniot>any idea what is causing the dat/time problem? how much in the future is it?
i'm uploading a new version, which has that method at the right place ;-)
ok it's there, same url. be careful of caches, get the new version!15:14
<ArtemGr>it has a funny date now (2005-03-28 08:52 if you care about difference)15:16
isn't that the bootstrap compiler?
<ArtemGr>oh, got wrong command from history. 8-J
<bonniot>md5: 20174b85816220082f03f888684c8ba2
that should be sure enough ;-)15:18
<ArtemGr>the date seems ok this time: 17:1415:19
<bonniot>weird, but good
<ArtemGr>okay, it works. now i can go on with my work. thanks!15:33
that was really a stress to me, this situation.15:35
sorry for not going for the quickest fix first15:37
that's something important to make very clear in general: do you need a quick fix, or do we think about the ideal solution for the long term15:38
<ArtemGr>well, you gave me the quick fix right away, i just wasn't able to build it and i thought its more of my own problem... : )15:41
<bonniot>yeah. it was a conjunction of several unlucky circumstances...15:42
<ArtemGr>time pressure on my side being one of them. ; )
* grom358 joins15:49
hey there15:50
<grom358>is there a roadmap document for Nice?
<bonniot>yes, see the homepage -> roadmap15:51
although most of the things there are actually already done in the current version
a few more features to add before 1.0
<grom358>is there going to be more language features added?15:52
like type inference, generators, synatix macros, etc15:53
<bonniot>after 1.0? sure, if good ideas come up
macros is definitely a big one for after 1.015:54
type inference is already partly supported, but yes it's planned to take it further
generators? isn't that pure library stuff?
see the nice.functional package. unless you are speaking of something else15:55
okay.. I will do
yes, so as far as i can see, this is implemented as a library in nice, so I would not exactly call it a language construct as they do ;-)15:58
maybe they cannot do that in boo
<grom358>mmm.. what about the generator expressions though?15:59
eg. oddNumbers = i for i in range(10) if i % 2
<bonniot>that's syntactic sugar for filter, no?16:00
(1..10).filter(int i => i % 2 == 0)16:01
in nice
(1..10).filter(int i => i % 2 == 1)16:02
i guess ;-)
"if i % 2" gasp
<grom358>not quite. Generator can represent infinite sets. Then again I could be wrong
<bonniot>in nice.functional, there are infinite sets too16:03
it's just implemented as closures
a generator of ints is really just a function ()->int
<grom358>are anonymous functions and closures the same thing?16:04
closures are the usual technical term, while I expect anonymous functions to be a bit clearer to people without a functional background16:05
<grom358>are Nice templates compatible with Java 1.5 Generics.
<bonniot>we're working on adapting the syntax at the moment16:06
mostly implemented in CVS already
<grom358>bonniot: yeah, I have been playing around with languages lately. And was using lambda functions in Scheme. And when I saw closures they appeared the same thing. So thats for confirming that
<bonniot>understood ;-)16:07
you really need to check with each language, because the terminology is not quite fixed
<grom358>yeah.. the biggest one is what OO is16:08
but he, that's normal, it's a moving field
<grom358>I wonder if Sun will ever take notice of Nice16:09
<bonniot>does that matter?
<grom358>nope. Just would be nice to see some of these features make there way into Java16:10
<bonniot>don't hope too hard, Java is changing very slowly (and for good reasons too)
but diversity is good
what I hope of Sun is that they recognize this diversity, which they start to do16:11
<grom358>yeah.. I know Java is changing slowly. One of the reasons been looking at other languages like Scheme, Common Lisp, Nice, Python, Ruby and OCaml
<bonniot>we're working hard to make Nice play as well as posible in an heterogenous environment, aren't we artem? ;-)16:12
those are all worth looking at
a plus of nice is that it plays well with java, so you have huge libraries, and you can reuse existing code16:13
and using the jvm means pretty good performance
but I hope nice is interesting as a language in itself ;-)16:14
<grom358>yeah.. I have experience with Java as well. OCaml offers good performance. There is native compilers for Lisp as well.
<ArtemGr>Using it in heterogenous environment, yeah. Mostly okay.
<bonniot>ArtemGr: and getting better ;-)
<ArtemGr>bonniot: would be great if that problem of mine is solved in some general way...16:16
<bonniot>grom358: yes, those implementations have good performance too. i think it came after more work (writing dedicated native compiler, or at least compiling to C)
ArtemGr: you mean so it can be commited to CVS?
<grom358>how good is integration getting with using Nice code from Java? Do you still have to use dispatch?16:17
<bonniot>grom358: you mean calling "my.pkg.dispatch.foo(..)" ?
<grom358>eg. Example 8.1 at http://nice.sourceforge.net/manual.html#compilationMethods16:19
eerrr... nevermind me
<ArtemGr>bonniot: well, i mean to find an ideal solution, when this problem is completely solved and even for public methods, but if not possible, then at least some package methods should be handled in a special way, and yes, in the CVS, so that i can continue to work on the compiler.
<bonniot>grom358: precisely, not using dispatch anymore in that example ;-)16:20
saw an old version?
ArtemGr: my fix is not specific to package methods, it will work for public methods too16:21
<grom358>well, keep up the good work on Nice
<bonniot>and yes, i'm planning to commit that change soon. should simplify bootstrap too ;-)
grom358: thanks
<ArtemGr>bonniot: but it break the compiler itself and methods no longer generated in classes, while i have nothing against generating methods in classes.
<bonniot>ArtemGr: only in specific cases16:22
most methods are still inside classes
(the compiler is a bootstrap problem which I will fix, so it's a minor issue)
<grom358>oh.. one last thing. Is Nice going to have synatic attributes?
<bonniot>grom358: like?
ArtemGr: it's only methods declared in a package whose first argument is a class in another package which don't get inside the class anymore16:23
so not the most common case, and not very surprising
i would like to support that again later if possible, but it's not a high priority16:24
stability first
<ArtemGr>bonniot: i had to change reflection invocation from Template.main to dispatch.main, presumably becouse Template.main wasn't longer in the Template.
<grom358>like in Boo. 16:25
<bonniot>grom358: i'm not up to speed on that one
ArtemGr: is main declared in another package than Template?
<grom358>there is an example at http://boo.codehaus.org/BooManifesto.pdf
<bonniot>hum, no static typing?...16:26
<ArtemGr>bonniot: no, class Tempate and its main method are declared in the same package, although in different modules (source files).16:27
<bonniot>at least the example is using syntactic attributes for things that nice can handle statically
like notNull
it's also planned to support "properties"/"implicit getters/setter"16:28
<grom358>that would be Nice (excuse the pun)
<bonniot>otherwise, it looks a bit like macros, no?
grom358: that's before 1.0 stuff
ArtemGr: indeed, my patch is too strict ;-)16:29
it checks the module, not the package
<grom358>bonniot: yeah, those syntactic attributes are a bit like macros
<bonniot>ArtemGr: this will not be the final version
same package is OK16:30
<grom358>I guess it depends on what your macro system can do. I am no Boo expert so I don't get the difference between them
<ArtemGr>bonniot: funny to hear that "receiver = null;" checks something ; ) (just joking)
<grom358>all it says is "Syntactic macros are pretty much like syntactic attributes in the sense that they are16:31
external objects invoked by the compiler to transform the code tree although they serve a
different purpose: syntactic macros augment the language with new constructs.
<bonniot>ArtemGr: i've actually applied a patch slightly more clever ;-)
grom358: OK16:32
<grom358>about your example: (1..10).filter(int i => i % 2 == 0) . Does that generate the numbers 1 through to 10 before filtering?
not the whole list, if that's what you mean16:33
<grom358>mmm.. how in Nice would you write something like a fibonacci sequence generator?16:35
<bonniot>example somewhere?16:37
<grom358>eg. like http://boo.codehaus.org/Generator+Methods16:39
I think Python has this as well now
<bonniot>you should ask Bryn on the list, he's the specialist about generators ;-)16:40
but i guess this should be it:16:47
()->int fibonacci() {16:48
var a = 1, b = 1;
return ()=> {
(a,b) = (b, a+b);
return b;
actually, that's missing the first term. add 'let res = b' before the computation, and return res instead16:50
of course it looks a bit simpler with the syntactic sugar, but this is essentially the same thing I think16:51
<grom358>okay.. cool
<bonniot>nice.function defines several combinators for generators
<grom358>I will look into it. One other thing, does Nice have hereto documents. That is, can specify multi-line string literals without having to go String a = "some very long line...\n" + "some more text"16:52
<bonniot>yes: """First line16:53
Second line.
<grom358>:-) cool.. okay I will have to stop asking questions and actually look in the manual. But that feature combined with being able to have variables in string literals will help avoid having to split up strings when output say some HTML16:55
ok, i'll take a break myself, then look at properly bootstraping that compiler16:57
<grom358>with nulls, just wondering how that integrates with Java. For example, say I am using JDBC and go rs.getString("some_field").length() but the db can return null for this field. So what happens here?17:03
okay.. I found the answer in the manual17:17
* grom358 leaves17:22
<bonniot>ArtemGr: changed the check to:17:37
receiver.definition.module.pkg != def.module.pkg
(the .pkg was not there before)
<bonniot>that might even fix the bootstrap, since there are less methods affected that way. I don't expect it though17:40
<ArtemGr>i'll try it
ah, i can't, there is no .pkg
<bonniot>no problem, i'm trying it now17:42
seems to be going far...17:46
<ArtemGr>compiler2 passed?17:47
<ArtemGr>cool. could you send me a patch right away? i have one thing broken in production, that will be fixed by it.17:48
<bonniot>so you can build from source?17:49
it worked, just started the testsuite
<ArtemGr>yes, and fix that thing, the sooner the better : )17:50
or the generated jar...
it should be in classes/nice.jar
<bonniot>what should be there?17:51
i'll upload the jar too, just in case. but wait a moment
i minute and it will be there17:53
(what will this fix, btw?)
<ArtemGr>NiceTee templates are used from Velocity with reflection. it is very poverful mechanizm to extend Velocity when needed without changing the application itself. And NiceTee methods are not visible from Velocity now...17:54
<bonniot>ok, it's there
ok, will be going. hope this works for you17:56
<ArtemGr>okay. thanks!17:57
<bonniot>and your problem was methods that weren't inside classes and that should?
<ArtemGr>class Templace is defined in one module and it's method in other modules, so methods are not in the Template, yes.17:58
<bonniot>ok, that shuld be fixed indeed
see you..
<ArtemGr>yes, good bye.
* ArtemGr leaves18:35
<CIA-3>03arjanb * 10Nice/testsuite/compiler/classes/field-override-packages.testsuite: Testcases for field override across packages (including one bug testcase).19:04
* Bluelive joins19:56
* Bluelive leaves23:09

Generated by Sualtam