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

Using timezone: Central European Time
* bonniot leaves04:26
* arjanb leaves09:54
* arjanb joins10:26
* ArtemGr joins12:06
salute! i have a question...12:21
arjanb: when package a is a library (in a separate jar), then Nice seems to generate modified classes if there are multi-methods for classes from package a...12:23
so there is two version of a class, original - in a jar - and the new one (with new method)
the question is: how the classloader will know it should load the new version?
i stumbled into "method not found" problem when using custom classloader to load recently compiled package with new multi-methods in it...12:25
dispatch classes are modified - the problem doesn't arise when multi-method is applied to a Java classes, but arises when multi-method is applied to a Nice class. therefore i had "method not found" errors in the packages which worked before, the problem arised after one of the library classes was rewritten from Java to Nice...12:28
arjanb: do you know anything about that problem?12:29
i don't know how to solve this problem, sometimes compiling in a different order helps12:32
when nicec may modify earlier compiled is a topic of discussion12:34
i think modification of existing classes happens to often now12:35
daniel knows more about how compilation of packages is done12:36
<ArtemGr>but is should be possible to reference multi-methods introduced by package b directly, when they are invoked from package b. it is probably what is done for Java classes?
<arjanb>i think so12:37
<ArtemGr>do you know where this decision is made in Nice sources?12:38
<arjanb>bossa.modules probably12:41
* bonniot joins13:30
see log for Artem's questions13:36
ArtemGr: what error message do you get exactly?13:44
i can think of two different situations, so I'd like to know which one this is
<ArtemGr>Exception in thread "PoolThread-9" java.lang.NoSuchMethodError: ru.promo.m.cms.Workspace.mode()Ltemplate/Mode;13:45
at template.fun$test.lambda2(test.nice:13)
at template.fun$test.apply0(Unknown Source)
at gnu.expr.ModuleMethod.apply0(ModuleMethod.java:84)
at template.fun.test(test.nice:137)
i'm working on a testcase
i'm not sure if you can do it easily in the current testengine
<ArtemGr>in the trace above, Workspace is a library class, mode is a multi-method introduced to it.
i can't, i'm doing a conventional testcase, with a shell script
<bonniot>ok, that's perfect13:47
btw, do you need a quick workaround?
<ArtemGr>My workaround is currently to replace13:49
void mode( Workspace dugout ) = ...
void mode( ?Template workaround, Workspace dugout ) = ...
and invoke mode( null, dugout ) instead of mode( dugout ).
But the problem is that i don't know what else is broken, Workspace is a widely used class...
<bonniot>cannot you do a final compilation and put everything in one jar? that's a setup that should work without problem13:50
you shouldn't need the library jar at all at runtime13:51
<ArtemGr>NiceTee templates are compiled separately from the application and run in a separate ClassLoader, in principle.13:52
<bonniot>ah ok
if you want to temporarily disable compiling nice methods inside classes, you can simply add 'receiver = null;' in bossa.syntax niceMethod.nice:37113:56
but i agree this should be fixed
<ArtemGr>thanks! i'll try this right away.
<bonniot>i guess we could simply disable it when the class is not in the same package as the method13:58
it would be nice to do it in all cases, but i guess that should come if we can be sure this does not cause such problems13:59
<ArtemGr>the problem is not the compilation itself, but that new classes are ignored if parent classloader have a previous version.14:02
<bonniot>that's a feature no?14:04
would you *always* want the parent to be searched first?
<ArtemGr>solution could be to invoke package multi-methods thru the package "dispatch" class, that is, if class Foo declared in package A, but method bar(Foo) declared in B, then invocations of bar(Foo) should go thru B.dispatch, instead of A.Foo.14:05
BTW, the method i have problems with is package-visible, there should be no problems with invoking it thru B.dispatch...14:06
"would you *always* want the parent to be searched first?" - from what i know, this behaviour can't be changed, it's a part of Java security. I've tried to load local classes first in my custom ClassLoader, but i've got errors of "loading constraint violated" from native JVM method...14:07
<bonniot>yeah, just checked ClassLoader.loadClass javadoc14:08
but I remember overriding it without problem
see the inlineLoader in bossa.syntax NiceUtils.java14:10
<ArtemGr>looks very much like what i've tried. will try again. it it works, i need nothing else.14:16
<arjanb>maybe that only works when java security isn't enabled14:17
<ArtemGr>with exactly the code from NiceUtils14:21
java.lang.LinkageError: Class ru/promo/m/cms/Workspace violates loader constraints
will try to turn off security now
<bonniot>which security is that? where is it configured?14:23
* Artem joins14:28
* ArtemGr leaves
What i did now, is used defineClass with no ProtectionDomain parameter. No effect. Global security was turned off already: Policy.setPolicy and System.setSecurityManager aren't invoked.14:31
the problem might be that i extend ClassLoader instead of URLClassLoader...14:34
<bonniot>i'm not sure yet wether this is a compilation problem or a classloader problem14:36
a testcase would help clarify the issue
<raboof>bonniot: btw, did you fix the bug with class templates that i ran into the other day? would it be wise for me to upgrade to current cvs?14:48
<bonniot>raboof: yes, it's fixed. thought i mentioned it on the channel14:54
<raboof>yeah, you said you `probably' fixed it but still needed to run some tests14:56
so CVS is relatively stable atm?14:57
<ArtemGr>CVS is always stable. ; )
<raboof>ok :)
<ArtemGr>Commits made after the testsuite run, not before.14:58
an even more stable version is http://nice.sf.net/nice.jar
* Artem joins15:00
* ArtemGr leaves
<bonniot>it's basically CVS updated a few times a day, but only put there if all normal tests are passed, it can bootstrap itself, and run a few more apps
it's a bit old at the moment, but should be updated next time
<raboof>hrm. wouldn't it be sweet if a shell supported `cd nice.jar'? :)15:02
that has probably been done, somewhere, by someone ;)
<ArtemGr>midnight commander can do this..15:03
<bonniot>emacs too, of course ;-)
i even read about cd ftp://foo.com/bar ;-)15:04
<raboof>sweet ;)15:05
<bonniot>if every tool was build as a library and used interfaces, it would be trivial to add such extensions...15:07
<ArtemGr>i've submitted a bug report with a testcase in it...15:14
<bonniot>ok, thanks15:16
<raboof>seems http://nice.sf.net/nice.jar doesn't carry the fix just yet - are there docs on bootstrapping from cvs?15:26
<bonniot>ArtemGr: i need to adpat run.sh a bit...15:28
raboof: indeed, it hasn't been updated since the fix. it should during the next run
i'm not sure if there are docs, but it should not be hard15:29
especially with online support ;-)
<ArtemGr>btw, i can't compile fresh Nice, becouse of NoSuchMethodError, that same that is mentioned in
<raboof>and we can generate the docs in the process. right. I checked out the `Nice' module and ran `make'15:30
this gives http://rafb.net/paste/results/L7jr7i54.html15:31
<bonniot>raboof: that would be great. a wiki page
<raboof>when is nice.sf.net/nice.jar updated, btw? i'll add that to Dev/DevelopmentVersion @wiki15:32
<bonniot>try wget hhtp://nice.sf.net/nice.jar -O external/nice-bootstrap.jar
your error looks like your system nice compiler (used to bootstrap) is ancient ;-)15:33
<raboof>ok, some warnings, but it's getting further now
<bonniot>when? several times a day, provided the conditions i wrote above are met15:34
ArtemGr: it seems one can't use '*' for jar (on unix ?)15:35
<ArtemGr>the test in http://nice.sourceforge.net/tests.html downloads the compiler each time it runs. i have the latest compiler, downloade from nice.sourceforge.net half an hour ago15:36
<bonniot>ArtemGr: i was telling to raboof to update his compiler, not to you ;-)15:37
<ArtemGr>ah, excuse me
ArtemGr: the error you're getting seems related to the one we're looking at now, I think15:38
looks like it happens with your ant script but not the makefile
ok, finally I get run.sh to behave as expected15:41
but you never use -jar ...15:42
so for instance nice.lang.fun is not found, that's what makes it fail now...15:43
<ArtemGr>works on windows...15:44
<bonniot>where is nice.lang.fun found?
not in a.jar, not in out/
<raboof>first part of the result with the newer nice.jar:
<bonniot>what javac is this?15:46
"file too short" best error message ever!
<raboof>javac is a symlink to /usr/bin/gcj-wrapper-3.315:47
<bonniot>ach, not good
<ArtemGr>bonniot: no nice.lang.fun, but there is a nice.lang.dispatch in out...
<bonniot>it's far from a javac replacement, unfortunately
<raboof>ah, let's see if i have another one.15:48
<bonniot>ArtemGr: yes
ArtemGr: but nice.lang.dispatch references nice.lang.fun
so this is not a realistic compilation scheme, it will never work
raboof: jikes is the closest free compiler. i've been working on making it work15:49
for the moment, if you want to avoid problems, use sun tools if you can
or ibm or whatever
<raboof>yeah, no problem :)15:50
i'll just have to find an apt source for them, after that it's trivial :)
<bonniot>you can tell where they are to the makefile
<raboof>i assume kaffe is also no good?
<bonniot>raboof: not so easy, sun is not very free in their licenses yet...15:51
apt-get install java-package
<ArtemGr>bonniot: but it works! 8 j
here is a simplification: http://rafb.net/paste/results/xIikVv37.html
<bonniot>raboof: but then you still need to download the tarball from sun directly, and make-jpkg it to produce a deb
<raboof>sounds easy enough15:52
<ArtemGr>bonniot: excuse me, my simplification is bad (it fails in the first string with NoSuchMethodError, by the way)
bonniot: hmm, or perhaps it is good, just gives unexpected results15:53
<bonniot>Should pass...15:55
Exception in thread "main" java.lang.NoSuchMethodError: a.A.a()Ljava/lang/String;
at b.fun.main(b.nice:6)
at b.dispatch.main(Unknown Source)
Exception in thread "main" java.lang.NoClassDefFoundError: b/dispatch
<ArtemGr>yes, it is bad, i see now where
the thing is, that both b.jar:a.jar and a.jar:b.jar fails in the same way 8-j15:57
<bonniot>what di you change last?15:58
<ArtemGr>b is compiled after a
do you have same results?16:00
<bonniot>Should pass...
Exception in thread "main" java.lang.NoSuchMethodError: a.A.a()Ljava/lang/String;
at b.fun.main(b.nice:6)
at b.dispatch.main(Unknown Source)
Exception in thread "main" java.lang.NoSuchMethodError: a.A.a()Ljava/lang/String;
at b.fun.main(b.nice:6)
at b.dispatch.main(Unknown Source)
<ArtemGr>that's what i mean - both fails
<bonniot>first one should work16:01
<ArtemGr>that's another situation (bug) - that's why i've used "out" in the first "run.sh" version - A.class is modified in the "out" but left untouched in "b.jar"...16:03
at least i see that A.class in "out" is different from the one in "b.jar".16:05
i made a version that leave everything around, so it's easier to understand what happens:16:07
i'm surprised this is failing. i suppose this is a bug in the part gather classes to put in the jar16:08
i'm going to look at that
it's definitely a problem that we don't have regression tests for these situations
would you have some time to work on that in the mean time?16:09
<ArtemGr>such testcases can be put into Nice/regtest, no?
<raboof>ok. wrote Dev/BootstrappingFromCVS - seems to be working (or at least it's taking a long time to fail :))16:11
<bonniot>raboof: :-)16:12
thanks a lot
ArtemGr: maybe, but I think with some adaptation
regtest was not written with complete control over the build process in mind
it's was the first framework before the testsuite16:13
one problem is that it's unix oriented, which does not encourage everybody to use it ;-)16:14
i guess such cases could be written in ant too, right?
<bonniot>i have this idea for the ultimate test engine:16:15
<ArtemGr>although shell scripts might be easier for complicated testcases, where every testcase requires custom shell script..16:16
<bonniot>the tests themselves would be nice programs. there would be a library of helper methods to handle the usual cases16:17
for instance pass("assert 1 != 2");16:18
but by calling lower-level methods, you could completely control the build process
and there would be no magic testengine, just normal methods that finally call the compilation api
that can also be interesting to create similar testcases:16:19
for (int i = 0; i < 10; i++) pass("assert "i" != " + (i+1));
you could do things like:16:22
<ArtemGr>compile( "class A{}", toJar: "a.jar" );
compile( "int bar( A a ) = 1;", main: "let a = new A(); !assert a.bar() == 1;", toJar: "b.jar" );
run( classpath: [ "a.jar", "b.jar" ] );
<bonniot>let p1 = pkg("""package p1; ... ");
to test recompilation
ArtemGr: yes, that kind of stuff ;-)16:23
there could even be calls to javac in there16:25
it's a bit more time to invest to write the framework in the beginning, but then it's the most flexible and extensible16:26
<raboof>Hum - what could cause http://rafb.net/paste/results/l2uUg057.html ? I'm not directly using slice() anywhere, asking myself `line 92 of *what*?' :)
but maybe i'm mixing versions of nice. lemme first try removing the old one completely :)16:27
<bonniot>ArtemGr: actually, it might not be that much work to start doing this, since the compilation API is already available16:29
the only missing feature is passing a program as a string instead of the name of a file16:30
but that could be implemented in a first step by writing the string to a temp file, and then call the compiler ;-)
(that's that the current testsuite is doing, really)
raboof: yeah, that looks weird16:31
<ArtemGr>bonniot: i can work on this, in principle, but not in "meantime", since i'm very loaded now. can curently scratch about two days a month - on holidays.
i had thought about "caching eval" implementation in Nice on lat holidays, BTW ; )
let's just keep this in mind
<raboof>hm, no, also when using purely CVS nice (as far as i can see) it's giving me that error16:33
<bonniot>right now, i feel it would probably not be worth spending time on building another framework that this one
raboof: would you happen to jave old .class files around?
<ArtemGr>yeah, there are more important things to finish, for me also.16:34
<bonniot>btw, don't you have spare time during the nights? just kidding ;-)
ok, i'll take a short break, then I look at this jar issue16:35
<ArtemGr>good luck
<raboof>bonniot: not in or below the current directory
<arjanb>raboof: what does nicec --version give?16:38
<raboof>0.9.11 prerelease (build 2005.04.06, 14:14:03 UTC), Compiled using JDK 1.4.116:39
fresh from cvs :)
<arjanb>the error suggests the nice.lang package used is still the old one16:42
<bonniot>raboof: could you try:16:46
cat > ~/.nice.conf16:47
debug.modules = true
and then see what nicec prints when compiling16:48
it makes it more verbose about where packages are loaded from
echo 'debug.modules = true' > ~/.nice.conf
that's more minimal ;-)16:49
<raboof>http://rafb.net/paste/results/H2qZt588.html - not much of an improvement i'm afraid16:51
<bonniot>it's not supposed to improve, just to be more verbose16:54
java -jar /usr/local/share/java/nice.jar --version
<raboof> 0.9.11 prerelease (build 2005.04.06, 14:14:03 UTC) Compiled using JDK 1.4.116:55
can you paste the program?16:56
<raboof>moment, making it more minimal16:58
<bonniot>i might know
<bonniot>could you try 'make fixpoint' in your Nice source tree, and reinstall that?17:02
the bootstrap compiler does not have the new format for method identifiers, so it's likely that this was causing a problem because the compiler was not regenrated17:03
<raboof>`make fixpoint, make install', them i'm retrying.17:05
in the meanwhile it seems it doesn't matter much what the content of the file i'm compiling is ;)17:06
<bonniot>it should have been, but since you had problems with wrong javac in the middle, this might have messed things up
ok, we'll see
<raboof>i *think* i checked out a fresh version before re-trying, not 100% positive though
<bonniot>in any case, fixpoint is compiling one more time, so it can only help ;-)17:07
* ArtemGr leaves
* ArtemGr joins
<bonniot>ArtemGr: two things:17:08
1) not compiling inside classes from other packages fixes this problem, at least17:09
bonniot: writing in archive
arjanb: writing in archive
silly automatic completion!!!
that was:
a: writing in archive
b: writing in archive
only b first17:10
so obviously a is overwriting b
it's trivial
<ArtemGr>a writes to a.jar, b to b.jar, how anything is overwritten?17:11
<bonniot>that's when writing to b.jar
http://rafb.net/paste/results/0pLv2237.html :-)17:12
<raboof>bonniot: hooray, indeed the error is now gone.17:13
sorry for that. the joys of living at the bleeding edge ;-)
<raboof>i'll try bootstrapping from scratch again, to see whether the `make fixpoint' after `make' is really neccessary (and thus should be added to the wiki)
<bonniot>that = the delay, not that the error is gone ;-)17:15
<raboof>no problem of course, happy to have such a bleeding edge available in the first place :)
<bonniot>raboof: in any case that would be *instead* of just make
<raboof>oh ok17:16
<ArtemGr>bonniot: i don't understand what do you mean. do you use http://rafb.net/paste/results/t4r5po77.html or something else?17:19
<bonniot>i do17:20
<ArtemGr>so what has been changed?
<bonniot>atually at the moment it's only not compiling inside imported classes17:21
i think changing the way the jar is built should be ebough though, investigating that17:22
actually, i've been wondering whether we should not stop completely writing .class files in directory, and simply generate one .jar per package17:24
ArtemGr: did you check if adding receiver=null solved your initial problem?17:26
<ArtemGr>i don't use -jar compilation at all: i compile everything into directory and manually jar it - i don't need nicec -jar becouse i have the nice itself in the application.
bonniot: i can't compile Nice
even with make?
i think i'm going to commit that change, as it simplifies at lot of things, and should solve the problems17:27
<raboof>oh wait, the problem probably was that i did the `make install' in a couple of phases because my groff version previously was too old to generate docs17:30
the best is 'make world' since it will also run the tests, so any such problem would be detected17:32
<ArtemGr>compiling into directory should be much faster: rewriting a .class in a big jar will take a lot of time to copy the whole jar. it can be made even faster by not creating "nice" directory, which is not enough to run the package anyway.17:35
<bonniot>ArtemGr: i don't think a jar would ever be modified, only created17:36
creating a jar might be faster than creating several .class, because jars are compressed, and IO is slow17:37
(making worlkd myself, before commiting http://rafb.net/paste/results/qR2hIp71.html)17:38
<ArtemGr>Nice is not ACID database ; ) and don't use synchronization, so IO is cached and don't use any time.17:39
<raboof>w00t. An exception has occured in the compiler.17:41
ok, i'll look at that later :)
<bonniot>true about cache. but then filling caches eventually means some things fall out of it...
anyway the goal is to go faster
but i don't think there is any reason it would be slower17:42
raboof: you are doing too fancy stuff ;-))
seriously, just submit a bug report17:43
<ArtemGr>how multi-dispatching is handled then, especialy if each jar is written only once?
i mean that classloader problem, how should it work if classloader sees the unmodified class first?17:45
<bonniot>you don't change the existing dispatching code, you create new one
the unmodified class should not be on your classpath at all17:46
or we have to make sure that the new one is seen
<ArtemGr>why is that? i have libraries a, b, c, all written in Nice, and have an application - isn't it a natural setup?
the question is how nicec stores the compiled code
currently it's fragile, and that's not good
we must come up with a way that just works ;-)17:48
<ArtemGr>when i change application, i copy application to a server, but libraries are left untouched, so, i suppose that library code is not duplicated in the application, so library should be on classpath..
<bonniot>library code _that is modified by the application_ is not really library code anymore17:49
<ArtemGr>yes, but only a small subset of the library is changed by application and redistributed with it, and the rest of the library is still separate, so the library is on classpath.17:51
i thought that Nice solves this by calling package dispatch methods instead of library ones.
that is, B.dispatch, instead of A.foo
<bonniot>no, it doesn't do that17:52
(let's call 'a' a package, and 'A' a class, OK)?
just to be clear
<ArtemGr>b.dispatch, instead of a.Foo
<bonniot>it doesn't17:53
a.foo you mean?
b.dispatch.foo instead of a.Foo.foo, right?
<ArtemGr>no, for a method "doSomething": b.dispatch.doSomething instead of a.Foo.doSomething.
<bonniot>ok, that's clear
and no, it doesn't do that
in the beginning, all dispatch code was in 'dispach' classes
now only methods that cannot be inside a class are there17:55
here's my current idea:
a.jar { a.A, a.dispatch, a.fun }
b.jar { a.A, a.dispatch, b.dispatch, b.fun }
(provided b imports a)17:56
this is good, because if c also imports a, you don't want b to mess with it
(which happens currently)
a.fun is really the only thing that's stable by import17:57
this will work, provided b.jar is before a.jar in the classpath, right?
<bonniot>the a b c situation is really the motivation for not using directories anymore
agreed on that?17:59
<ArtemGr>yes, that is a good setup18:01
but to solve class loading problem when b.jar is after a.jar in classpath,
can you dispatch "doSomething" thru b.dispatch and not thru a.A when
doSomething (defined in package b) is package-visible.
<bonniot>we could (that's my current patch) but I don't think it's enough18:04
<raboof>http://rafb.net/paste/results/4HTMyt22.html - care to try that on your end?18:06
<bonniot>ArtemGr: http://rafb.net/paste/results/DcgrS647.html18:07
if a.jar is before, this would fail
raboof: what do you get?18:08
<raboof>a java.lang.IndexOutOfBoundsException at compile-time
<ArtemGr>java.lang.IndexOutOfBoundsException: -1
at mlsub.typing.lowlevel.BitVector.set(BitVector.java:135)
at mlsub.typing.lowlevel.BitMatrix.set(BitMatrix.java:184)
at mlsub.typing.lowlevel.K0.leq0(K0.java:686)
at mlsub.typing.lowlevel.K0.leq(K0.java:652)
<raboof>yeah, that one :)
<bonniot>you're a good testcase finder ;-)18:09
<raboof>thanks :)
<bonniot>how is that different from your previous code?
<raboof>actually, i'm not so sure :). it started to go wrong when i added a `= null' default value to an ?IntTreeNode<T> member18:10
but while trying to get the minimal testcase that shows the problem, i removed that one ;)
<bonniot>raboof: looks like it's a subset of your original program, which *is* working18:14
i'll investigate
i guess workaround is the same: keep the constraint to individual methods instead of the whole class (puttint the methods outside the class)
ArtemGr: do you see the problem in that case? (back to the jar questions ;-)18:15
<bonniot>are you familiar with jar manifest classpath entries?18:19
use one18:20
<bonniot>could me use them so that b.jar says its classpath is a.jar? what would that do?
where is a.jar looked for?
<ArtemGr>in the same directory where the b.jar is18:21
<bonniot>and a.jar is added at the end of the classpath or in front? (compared to b.jar)
<ArtemGr>don't know. it's not shown in java.class.path, and i don't know of a way how to query bootstrap loader of its paths18:24
<bonniot>if it's at the end, it might be a solution, no?18:25
<ArtemGr>can test empirically, if you want, but i doubt it will solve the problem
it will be implementation dependent, at least18:26
<bonniot>that would be very strange if that's not specified
you have the pointer to the docs for that at hand?18:27
the order not specified in these
yeah, couldn't find a precise spec yet18:52
but the behaviour seems to be to add *after*
<ArtemGr>it look more like a workaround that a solution18:54
and it isn't a solution for dynamic class loaders, which are used often too
what is the problem with writing everything into b.dispatch (and importing b.dispatch from c)?18:56
<bonniot>that doesn't solve the testcase, does it?
i haven't worked out all details yet but it seems:18:57
compiling into jar only improves the current situation
we require the classpath to be "in the right order"
using Class-Path in manifest might make that easier to achieve18:58
what's the problem exactly with dynamic class loaders?
<ArtemGr>that class loader must check its parent for the class first18:59
<bonniot>ok, i'll need to be shown an example to understand the problem19:00
now i must go, will be back later...
<ArtemGr>see you
* ArtemGr leaves19:43
* Bluelive joins20:02
<bonniot>raboof: does the workaround work?21:52
<CIA-3>03bonniot * 10Nice/src/mlsub/typing/lowlevel/Engine.java: Whitespace cleanup.22:38
<bonniot>raboof: looking at it now...22:54
* Bluelive leaves
<bonniot>raboof: fixed, doing the full testing...23:18
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): Fix introduction of constrained class type parameters.23:52

Generated by Sualtam