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

Using timezone: Central European Time
<arjanb>CallExp is quite resistant to conversion00:22
does the testsuite print correct line numbers?00:57
<bonniot>on stack traces?01:10
<bonniot>when running the generated code i don't think so (given TestCase.java:373)01:13
this should be changed to printStackTraceWithSourceInfo01:14
<arjanb>hmm same stacktrace01:28
i'm too tired to find it01:41
i give up01:54
<bonniot>if the trace is during compilation, then it must be caught somewhere else02:12
i'll change that tomorrow02:19
* bonniot leaves
* bonniot joins10:12
hello arjan10:51
<bonniot>do you think the Pattern class could be simplified by creating subclasses for some cases?10:52
<arjanb>yes though not easily10:53
<bonniot>what would be the difficulty?10:55
<arjanb>that you not always know at pattern creation what kind of pattern it is10:56
<arjanb>foo(bar) bar can be an atAny, an enum, a constant, a reference to an unique object10:58
wouldn't the atBool and atValue patterns be easy to factor out?11:03
and atNull11:04
<arjanb>bar could also be a boolean or a null i think11:05
<bonniot>no, it's a reference (to something that might be a boolean or null, but that doesn't matter, it's a different case)11:08
<arjanb>it does matter because they are value constant patterns after the reference is resolved11:12
<bonniot>at the moment it seens only integer references are handled11:17
but yes, that could be done
it would be possible to make resolveGlobalConstants return a Pattern. then you can create the right one when you found out and return that11:19
static void resolveValues(Pattern[] patterns)11:20
for(int i = 0; i < patterns.length; i++) {
patterns[i] = patterns[i].resolveGlobalConstants();
<arjanb>that could work11:23
except for an abstract pattern class it could be nice code11:25
<arjanb>a subclass for each kind of pattern in Nice11:27
<arjanb>this is very odd11:54
i get a null pointer exception at this line:11:56
cst is null
public static void enter(Constraint c)11:57
throws TypingEx
if( c != null)
<bonniot>ah, I already got that
the thing is that there is also a non-static enter method
probably what you should get here is an ambiguity12:00
ah no, because the non-static one has a more precise type
cst should have type ?Constraint (since it can be null) and then it should work12:01
<arjanb>*sigh* looking for hours for something like this12:02
<bonniot>yes, it's very tricky12:04
<arjanb>i'm now against the convenient default retyping of returntypes12:10
<bonniot>because of this case?12:11
<arjanb>and a few more cases12:12
most null comparison warnings in the compiler are caused by that12:13
<bonniot>but without it using java libraries would be a nightmare12:14
<bonniot>especially as there is this trend in Java to say you should seldom use null (because it's not handled well as in Nice ;-)
<arjanb>that trend isn't followed in the java of the compiler12:16
*java part12:17
it will become a non-problem as we switch to Nice
<arjanb>it's quite a struggle during the conversion12:19
finally passing the testsuite12:22
<bonniot>i'm checking the stack trace printing inside the testsuite12:30
<arjanb>i did get a stacktrace but the line number was wrong12:41
<bonniot>yes, it did not call the special stack printing method12:43
but more is needed, because the generated code is run inside a custom class loader, and the stack printing code only looked on the system class loader
i got it working now, i'll check it does not break anything12:44
<CIA-3>03arjanb * 10Nice/src/bossa/ (13 files in 2 dirs): Converted CallExp to nice code.12:45
<bonniot>how did you bootstrap with the change of Expression.isNull and ReferenceOp?13:12
<arjanb>nothing special13:13
<bonniot>could you send your bootstrap script?13:17
<CIA-3>03bonniot * 10Nice/src/nice/tools/util/DirectoryClassLoader.java: Make DirectoryClassLoader also find resources.13:23
<bonniot>hum, i guess it's that you don't use the new inlined methods with the old compiler, right?13:26
<bonniot>simpler in this case. the advantage of my setting is that it works directly when you add a new inlined method and the nice code that refers to it13:31
<arjanb>i see13:35
<CIA-3>03bonniot * 10Nice/stdlib/nice/lang/source-lines.nice: 14:04
Accept a ClassLoader argument, which is useful when the code was loaded
from a custom class loader.
03bonniot * 10Nice/src/nice/tools/testsuite/TestCase.java: 14:20
Provide source line numbers in stack traces when the generated code fails.
Print line numbers when printing the testcase source.
03bonniot * 10Nice/src/nice/tools/testsuite/ (TestCase.java NiceSourceFile.java): Cosmetic improvements on output.14:33
<bonniot>do you think you could do the simplification of Pattern? This should make Adam's job easier14:50
<arjanb>i can try14:51
it will take some time because i find it hard to concentrate atm14:55
not sure changing pattern now is a good idea16:33
<arjanb>because it would more like a complete rewrite16:38
<bonniot>i thought it's possible to factor out some subclasses progressively16:40
what's the problem with that?16:47
<arjanb>Dispatch.java needs to be changed as well16:48
<arjanb>it depends closely on Pattern
i made Pattern a big mesh by adding all these pattern16:55
<bonniot>but Dispatch should only depend methods in Pattern. they can be implemented in subclasses without changing Dispatch16:56
all the patterns are useful :-)
now the thing is to simplify the class
it looks like Dispatch would need very little change, probably just some minor ones in generateValues17:11
<arjanb>for example i need to remove boolean pattern hack17:12
<bonniot>the way I see it, you could create subclasses of Pattern which have the same interface as currently, so other code can stay the same17:16
<arjanb>when is that article about Nice coming?19:52
<bonniot>i don't know, i was wondering too20:28
<arjanb>have seen jython and groovy20:29
it seems monthly and jruby is next20:38
<CIA-3>03arjanb * 10Nice/src/bossa/ (4 files in 2 dirs): Don't use special tc's for testing boolean patterns.21:01

Generated by Sualtam