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

Using timezone: Central European Time
* zzorn joins10:09
* bonniot joins10:23
* ArtemGr joins10:25
<bonniot>hi10:37
<ArtemGr>salute10:40
<bonniot>congrats for your build file!10:41
is it in a releasable state?
<ArtemGr>thank's
yes, i think it's ok10:42
<bonniot>could you send it to me by email?
<ArtemGr>i'm trying the testsuite now, though
<bonniot>ok
never too careful ;-)10:43
<ArtemGr>testsuite\compiler\native\constructors.testsuite failed11:26
<bonniot>what output do you get?11:31
it's not failing in CVS: http://nice.sourceforge.net/tests.html
(which just means it's probably something in your setup/build file)11:33
<ArtemGr>Sendint script to the email fount at the bottom of http://nice.sourceforge.net/11:53
sent11:55
<bonniot>ok, i'll do a build from scratch12:03
didn't get your email...
ok i did12:05
it just got classified as junk. you're in my address book now, so it won't happen again12:06
do I need to set somethings?12:07
<ArtemGr>FYI: there is a error in 'check_lib' and 'check_compiler' targets: <arg value="testsuite" /> should be replaced with <arg value="testsuite/lib" /> and <arg value="testsuite/compiler" /> respectively.
<bonniot> Path component ${env.NICE}/nice.jar does not exist
<ArtemGr>the "NICE" environment variable12:08
Should change it to NICEPATH probably.
I just happen to have "NICE" in my environment instead of NICEPATH.12:09
<bonniot>ok, it's flying now
did you see the external dir?
how do you find javacc?12:10
<ArtemGr>see the target 'javacc' in the build script12:11
<bonniot>ok, it just failed on that12:12
nicely explained ;-)
<ArtemGr>i personally got it using Firefox12:13
<bonniot>expanding javacc into /classes is probably not the right thing to do in the long term
I used wget ;-)
<ArtemGr>to me the classes is just a temporary dir used for building, it was named 'build' first. even if 'javacc' is not erased, it will not be packed into nice.jar or otherwise used, so it's ok imho12:15
since the first "clean" command is <delete dir="${build}" />, i feel it safer to place anything into build than somebody else.12:17
somewhere else
<bonniot>ok12:19
the build was successful
launching check_compiler now
<ArtemGr>i thought first to make a 'build/classes', but placing directly into build was simpler at the moment.
and now i renamed 'build' into 'classes', becouse 'classes' was default for the testsuite and is already ignored in .cvsignore...12:20
<bonniot>ok
check_compiler:
[java] run test engine
[java] testsuite: testsuite/compiler/native/constructors.testsuite
[java] testsuite: testsuite/compiler/statements/variables/scoping.testsuite
it looks fine12:21
(i touched that file, since most recent ones are run first)
sure you did not fiddle with something while the testsuite was running?
i'll let it run, and go for lunch...12:22
<ArtemGr>i thought it maybe a bootstrapping problem. i still am compiling from prepelease, and it seems there might be some classes included from prerelease compiler (that's probably why you are rebuilding twice in Makefile) ..12:23
bon appetit12:24
i've recopiled the compiler with previously recompiled compiler :-)12:41
but testsuite still fails: http://bizlink.ru/ant4nice/
<bonniot> [java] number of testcases: 120212:50
[java] successes : 1175
[java] regressions: 0
[java] warnings : 0
[java] known bugs : 27
everything fine here12:51
is that the only error you get?
what JDK?
interestingly, it's probably one of the only testcases using multi-threading. could that be significant?12:54
do you have a multi-processor system?
it does look thread safe though
does it fail if you do:12:55
java -cp classes nice.tools.testsuite.TestNice testsuite/compiler/native/constructors.testsuite
?
<ArtemGr> [java] number of testcases: 1202
[java] successes : 1174
[java] regressions: 1
[java] warnings : 0
[java] known bugs : 27
failure seems to be about assertions, not multithreading12:56
<bonniot>nope
assert is used to check that the testcase behaves as expected12:57
and that behaviour includes running a thread
<ArtemGr>java -cp classes nice.tools.testsuite.TestNice ... - does fail12:58
<bonniot>ok. so you can reproduce it more easily
could you try printing the InterruptedException if there is one?
another possibility is that the case only passes by chance for me. checking that13:02
no, it looks fine13:04
what do you get?
<ArtemGr>i can't catch InterruptedException in the debugger.13:05
<bonniot>just add a println
<ArtemGr>although testcase still fails13:06
<bonniot>wait, I'm silly
it's fine *here*, but mabye not on your setup
can you look at the bytecode for class pkg.A ?13:07
the interesting thing is constructors (Runnable) and (Runnable,int)
<ArtemGr>i managed to break at pkg.fun.main13:10
i'e i'm in the debugger now, at line 10
although "line 10" is probably wrong
<bonniot>it might be easier if you looked at the bytecode13:11
or send me the A.class by mail
I have a precise idea about what might be going on
<ArtemGr>Method arguments:13:12
args = instance of java.lang.String[0] (id=816)
Local variables:
c = instance of java.lang.Class(reflected class=pkg.Nice, id=815)
make = instance of java.lang.reflect.Constructor(id=817)
instance = instance of pkg.Nice(id=818)
<bonniot>the whole question is, what constructor is called (through reflexion)13:13
please send me the .class
<ArtemGr>do you mean fun.class ?13:16
i'll send you the whole package zipped13:17
<bonniot>no need
A.class
<ArtemGr>Glim@cygwin:/c/spool/Java/rebuild/Nice/testsuite-temp-folder/$ find | grep -v nice/lang13:18
.
./nice
./pkg
./pkg/dispatch.class
./pkg/fun.class
./pkg/main.nice
./pkg/Nice.class
./pkg/package.nicei
<bonniot>uh?13:19
<ArtemGr>BTW, here is a dump of the constructor choosed:
main[1] dump make
make = {
clazz: instance of java.lang.Class(reflected class=pkg.Nice, id=815)
slot: 0
parameterTypes: instance of java.lang.Class[0] (id=820)
exceptionTypes: instance of java.lang.Class[0] (id=821)
modifiers: 1
constructorAccessor: instance of sun.reflect.DelegatingConstructorAccessorImpl(id=822)13:20
root: instance of java.lang.reflect.Constructor(id=823)
java.lang.reflect.AccessibleObject.ACCESS_PERMISSION: instance of java.lang.reflect.ReflectPermission(id=824)
java.lang.reflect.AccessibleObject.securityCheckCache: null
java.lang.reflect.AccessibleObject.override: false
java.lang.reflect.AccessibleObject.reflectionFactory: instance of sun.reflect.ReflectionFactory(id=825)
java.lang.reflect.AccessibleObject.class$java$lang$Class: instance of java.lang.Class(reflected class=java.lang.Clas
s, id=67)
}
main[1] dump make.parameterTypes
make.parameterTypes = {
}
main[1]
<bonniot>no, i would need the bytecode of the constructors
with javap or similar13:21
<ArtemGr>it's strange, but i don'see the A.class 8 )
<bonniot>oh, it's in testsuite-fail-folder
if the testcase failed
found it?13:33
<ArtemGr>testsuite-temp-folder was used in one of the command-line windows (that is, its current directory was testsuite-temp-folder), so testsuite couldn't rename the folder becouse windows do its hideous "locking".13:36
<bonniot>ah
but still testsuite-temp-folder has the last testcase, not the one failing13:37
i advise you put the testcase on a file in its own
<ArtemGr>i've sent you the file
<bonniot>ok, it's what I thought13:39
it's not your fault
the functionality this testcase is testing is not always working properly, only I never ran into it before13:41
you can add a bug marker on this one and move on ;-)
ie /// PASS bug13:42
<ArtemGr>but i don't need it to move on ; )13:43
<bonniot>the bug marker let you avoid seeing a spurious error showing up during testing13:44
what JDK are you using?
<ArtemGr>1.4.2_0613:45
<bonniot>interestingly, I cannot reproduce it with any Sun JDK, but I can with kaffe
good for my testing ;-)
<ArtemGr>what's the problem, by the way?13:46
<bonniot>interaction between Java overloaded constructors and Nice default constructors with keywords13:50
<ArtemGr>"the bug marker let you avoid ..." - it's obvious, i just don't need it now, and i'll update from CVS next time anyway.
<bonniot>i will add the rationale for the expected behaviour in the testcase comments
<ArtemGr>that's fine. i was meant to ask why is it failing sporadically?13:52
<bonniot>there is some mangling going on because of things that can be distinguished in Nice source but that would be the same in bytecode by simple erasure13:54
at the moment the mangling is done lazily, so whatever method is compiled first gets the "real" name, and the next one gets a mangled name13:55
it seems that somewhere which method gets compiled first depends on the implementation of the JDK (like iterating on a Collection has no specified ordering)13:56
what will have to be done is to make sure the method I want gets the simple name
<ArtemGr>i think it is depends on some current 'state' rather than implementation, that is, implementation might be the same, but order of methods returned still be random on different setups, so it is truly a random bug.13:59
<bonniot>right, it could be the same implementation, just depending on what memory location an object gets ;-)14:00
<ArtemGr>yes, i forgot that default hashCode is memory pointer14:01
<bonniot>right14:02
so, shall I add you to the project's members?14:11
<ArtemGr>i wouldn't mind a cvs access so that i can do some things directly, thanks14:30
i can commit the ant script for starters14:31
<bonniot>here you go14:34
yes, please commit the ant script
<ArtemGr>for example, the ant script i previously sent doesn't generate the debugging information (javac debug is off by default)14:35
thanks again. i'll try not to break anything. ' )14:38
<bonniot>no problem. please always run the testsuite before commiting14:39
and when in doubt, ask ;-)
<ArtemGr>all right
<bonniot>i see it's your first project on SF. been on other open source projects elsewhere?14:40
<ArtemGr>i've been on JADE for a short time, but figured our goals are too different. had a few patches made to jdbm, they are still there i suppose.14:43
<bonniot>JADE, the stylesheet tool?14:44
<ArtemGr>http://jade.dautelle.com/14:45
<bonniot>overloaded name then ;-)14:46
<ArtemGr>i've been working on a performance-critical c++ project for a long time, and most thigs where written by hands (including hash table) becouse i wasn't satisfied with performance of libraries available. 8 )14:47
therefore i am relatively recently exposed to the opensource java world14:48
<bonniot>it certainly sounds like you can add insight to Nice ;-)
<ArtemGr>hope so14:49
<bonniot>what do you do?
<ArtemGr>Original content-management system (CMS) with deep web-CRM (customer-relationship-management) features planned.14:51
Am using "NiceTee" templates a lot already in existing projects.14:52
Primary user is a 'promo.ru' web agency (web-site developing and marketing they do).14:54
<bonniot>cool14:55
we'll really need to make a "Done with Nice" webpage ;-)
did you manage to plug NiceTee with the compiler so you can get error messages and stuff?
<ArtemGr>yes14:56
some of our clients: http://agency.promo.ru/clients/our_clients/index.html ; )
(a lot of west copanies have/making russian representative offices)14:57
<bonniot>now that looks good!14:59
impressive15:01
so Nice is deployed on all those websites? or not yet?
<ArtemGr>I hope we'll made an english version of our soft, but it will be some time. We've not even started implementing the CRM functionality..
Our CMS is only beginning to be used, and still there are sites developed on PHP and communivare. NiceTee and Nice (in the CMS itself) are used a bit in "http://whirlpool.ru/".15:04
I think there will be a "done with WebCRM" page sometime, and the WebCRM itself (which is the name of our project) will be on the "Done with Nice" webpage..15:07
<bonniot>now I understand better why -endoding is important for you15:19
<ArtemGr>I'm going to use MacroDef in place of repeated javac and java Ant tasks.15:32
<bonniot>to simplify the build script?15:33
<ArtemGr>yes, and to made it more manageable15:34
<bonniot>ok15:36
i'm going to be away for a couple of hours...16:27
<ArtemGr>what property do you usually have pointing to the current Nice release? NICE, NICEPATH, something else?18:03
i've managed to write automatic detection from $NICE_JAR, $NICE and $NICEPATH variables.19:43
<bonniot>back20:16
i usually either use 'nicec' from the system PATH, or external/nice-bootstrap.jar20:17
it's good to support env vars too
<ArtemGr>nicec uses vars. shell version uses NICE_JAR and nicec.bar uses NICE ..20:18
<CIA-2>03artemgr * 10Nice/build.xml: Nicec bootstrapping using Ant.20:23
<ArtemGr>I've made a lot of changes to the script. You should take a look. %-)20:28
<bonniot>ok20:29
can you summarize?
<ArtemGr>macroses; main targets ("ant -p") with dependencies; protection from recompiling everything from the beginning each time; correct step to '--recompile-all bossa.syntax' instead of 'nice.lang'; NICE_JAR detection; working wget download if there is no javacc.20:35
generation of share/java/nice.jar20:36
some configuration properties to be used with -D...=..., like 'compiler' and 'checkFail'.20:37
<bonniot>sounds very good20:38
<ArtemGr>CRLF changed to LF : )
with "dos2unix" from cygwin20:39
Ah, i just checked, Eclipse has CRLF to LF conversion in the menu, too...20:40
<bonniot>i think cvs would take care of that, if you are speaking of the build.xml file itself20:41
<ArtemGr>I've seen problems with CRLF endings when generated JDBM and Velocity patches using anonymous CVS access. Don't know why, but the fact is that there were files with different endings in the same CVS (and with the same .java extension). Eclipse have the option to 'convert to platform encoding' but than again i don't know if this option is safe or on the contrary...20:45
<bonniot>i think text files in CVS are with LF. the exception is that if you commit a CRLF file from Unix, then it will stay like that20:47
<ArtemGr>Yes, you're right! Modern IDE's have their own options though, like "Treat all new files as binary" in Eclipse.21:01
<bonniot>does that ever make sense?21:03
<ArtemGr>"does that ever make sense?" - if you have a lot of binary files; but by default it should convert XML to LF all right21:22
* ArtemGr leaves23:02

Generated by Sualtam