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

Using timezone: Central European Time
* arjanb leaves02:38
* arjanb joins11:21
* bonniot joins14:43
hi14:45
<arjanb>hi
i'm writing a little program in nice now so i'm hunting bugs14:46
<bonniot>what is the program?14:47
<arjanb>it's for a programming competition14:48
it's game that will be played against other program14:49
<bonniot>is the competition public?14:50
<arjanb>the final version cannot be in nice but nice is easier for trying things out
public but afaik all contestants are dutch
<bonniot>why cannot it be in nice?14:52
(all dutch because the instructions are in dutch ? :-)14:53
<arjanb>because you have to send the source and only java,c and pascal are supported14:54
no the site is in english
<bonniot>you could try to decompile the bytecode with a Java decompiler14:55
if it works, that's Java source ;-)
<arjanb>it's not much work to convert the final version to java 14:56
did you know that you can have labelled break's without any looping construct?
<bonniot>in Nice or Java?14:59
<arjanb>both
<bonniot>so then yes, because I wrote the code for Nice :-)
<arjanb>well i find it odd15:01
and it doesn't work because of some bug in reachibility code15:03
block: {
print("abc");
break block;
}
print("xyz"):
D:\Nice\.\testbug\test.nice: line 23, column 1:15:05
This statement is never executed
line 23: print("xyz");
this construct only doesn't use the word goto
why not allow labels only for loops?15:08
<bonniot>no, labelled break is not equivalent to goto15:11
it is structured (you can only exit an englobing block) while the problem with goto is that you can jump to an arbitrary location, which easily makes code very hard to follow15:12
<arjanb>yes15:13
i can't think of any use for it15:17
<bonniot>it can be useful in a complex nesting of blocks, when in a special case you need to stop processing15:26
i agree it is quite rare, since one should rather write small methods, and then you can use return15:27
but I don't see a strong reason to remove it
<arjanb>ok but it doesn't work right now
<bonniot>yes. now we have the testcase, so we can fix it eventually15:29
<arjanb>why haven't you committed the super call changes yet?15:36
<bonniot>not satisfied with it yet15:46
<arjanb>i see15:55
one other little thing i noticed
x = arr[0] = 5;15:56
Incorrect type in assignment to x
Found : nice.lang.void
Expected: nice.lang.int
i'm doubting whether this is good or not15:57
<bonniot>i think it would be more logical for this to work, since it does for normal assignment16:07
<arjanb>yes i could change this16:10
it won't yield pretty bytecode16:25
can be detected whether a non void return is needed? 16:26
<bonniot>yes, you can. you should look at gnu.expr.IncrementExp. I wrote that class, and the situation is exactly the same16:30
the bytecode is actually pretty
it is just a 'dup' on the value16:31
well, you have to be careful where the duplicate should be on the stack
<arjanb>i see you can duplicate and insert into stack at once using dup_x1 or dup_x216:36
<bonniot>yeah. have you looked at IncrementExp?16:40
<arjanb>yes16:41
if (type == Type.pointer_type)16:50
try {16:51
componentType = ((ArrayType) args[0].getType()).getComponentType();
}
catch (ClassCastException ex) {}
ugly code in ArraySetOp
<bonniot>what do you propose instead?16:52
<arjanb>if (type == Type.pointer_type && args[0].getType() instanceof ArrayType)16:54
componentType = ((ArrayType) args[0].getType()).getComponentType();
<bonniot>this is functionally equivalent, but does the getType and the class checking twice16:57
<arjanb>yes but catching ClassCastException is not good
<bonniot>only if you catch an arbitrary cast somewhere in the code17:00
but ok, some version of getType could possibly throw one by accident
the idea here is that this code is only an optimization, and it does not matter if it fails due to an exception17:01
so it is harmless to catch an exception and not do anything in that case
<arjanb>i have it working now17:49
<bonniot>great18:06
do you have enough testcases?
<arjanb>i think so
and committed18:19
daniel have you read a part of the thread that Isaac has linked to in his latest nice-info post?18:28
<bonniot>i have replied to his post18:30
i don't have the time the read the thread just now
<arjanb>still working on your disssertation?18:31
<bonniot>it's going to be a bit longer than expected :-(18:32
<arjanb>longer in time or text?
<bonniot>if somebody can summarize other points in that thread in answer to my post, and he posts that summary to the list, I will happily answer
time18:33
did you read the thread?18:35
<arjanb>i'm reading now18:36
<bonniot>so you can do the summary :-)18:38
<arjanb>this post has some critics on nice: http://groups.google.com/groups?q=g:thl1864418959d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=bljg69%24kmq%241%40news.oberberg.net18:40
<bonniot>his point about ? is partly wrong (supposing he thinks of option types a la ML). option types are less practical than our ? types (because they don't have subtyping like String <: ?String18:43
for constructors, we know it well, and the solutions are coming
about modularity, that was the point in Isaac's quote, but there is nothing precise here18:45
<arjanb>*away for dinner*18:46
*back*19:14
i see you made some methods for reflection but didn't parametrize Class19:22
we could wait untill the next prototype of 1.5 to see how they want to use Class<T>19:34
<bonniot>is Class<T> already in the current protos?20:09
how is it used?
<arjanb>no so i don't know20:11
<bonniot>you should make some changelog entry for the array set change20:42
<arjanb>yes20:43
when the development version is up to date request #812772 could be closed20:44
<bonniot>do you have the rights to do it?20:46
<arjanb>no only for bugs
changelog updated20:58
fixed the reachability of labeled breaks to loops21:31
but the case without loops doesn't work yet21:32
and doesn't look easy to fix21:36
<bonniot>why not?21:51
<arjanb>that with loops was an obvious bug but i have no idea how reachability things work21:53
<bonniot>well, setReachable would need to be called at the end of the labelled block that is targeted by a break, that's all22:07
<arjanb>so blocks need field to store that22:08
<bonniot>yes22:09
<arjanb>and how about the odd case of targeting some other statement22:10
<bonniot>if it's a simple statement, it cannot contain a break, can it?22:11
<arjanb>label: break label; is valid code i believe
<bonniot>is that the only case?22:12
<arjanb>not sure i have no idea what a break in other cases means22:13
but we could allow labeled breaks only for loops and blocks22:14
<bonniot>sure, if that does not complicate or slow down (lookahead) the parser too much22:16
<arjanb>it's easy to check in analyse.nice22:17
<bonniot>otherwise, it is fine to have code after label: break label; to be unreachable, as this is non-sensical anyway
<arjanb>so no need for complicating the parser
<bonniot>by instanceof?
<arjanb>yes22:18
<bonniot>then I am not sure it is worth it22:20
we gain very little
<arjanb>wdym?22:21
<bonniot>this check will not bring much: labeling simple statements is absurd but harmless, and will propably almost never happen in normal code. on the other hand, it will cost in runtime (instanceof is expensive), and of course (very slightly) complicate the compiler. so I am not sure it is worth it22:29
<arjanb>that check will only happen when a break label doesn't target a loop and the complexity you have already by supporting blocks22:31
<bonniot>how do you do it only when a break label doesn't target a loop?22:34
can you show me the diff?
<arjanb>see my last change to analyse.nice22:35
<bonniot>did you implement that?22:38
<arjanb>i fixed the loop case of the bug an hour ago22:39
<bonniot>ok, i saw that
i see at the TODO line, that you could check if the target was a block22:40
i think that's OK
<arjanb>or i add 4 lines to the parser and assume it's a block there22:41
<bonniot>what i thought you wanted to do was to allow _labels_ only for loops and blocks22:42
but I see now you didn't say that
implementing at the TODO place is OK with me22:43
if you choose rather to modify the parser, please show me the diff before commiting
<arjanb>the parser change would look something like:22:51
Statement LabeledStatement() :
{ LocatedString label; Statement res; boolean forLoop; }
{
label=ident() ":"
{ forLoop = "for".equals(getToken(1).toString()); }
- res=Statement()
{
{ forLoop = "for".equals(getToken(1).toString()); }
+ ( res=Block()
+ | res=ForStatement()
+ | res=WhileStatement()
+ | res=DoStatement()
+ )
{
<bonniot>that seems good. did you really try and test it?22:52
<arjanb>no22:53
why are you reluctant to parser changes now?22:54
<bonniot>one could argue for
label: if (...) { ... }
i am not
i said it seemed good!
i am reluctant to implementing this in any costly way22:55
but the above diff would not be costly, so it's fine if it works well
<arjanb>i think i have enough experience now to avoid stupid things in the parser23:03
<bonniot>i didn't mean to say you didn't!23:04
<arjanb>i know23:05
<bonniot>ok, good :-)23:06
<arjanb>i was only a bit surprised at your reaction23:07

Generated by Sualtam