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

* arjanb joins11:18
* bonniot joins12:19
hello arjan
<arjanb>hello
<bonniot>for slices, I thought that if we want to add it now, we should choose the conservative option, and only allow positive indexes12:20
also, can it be implemented as a library + syntactic sugar?12:21
<arjanb>yes
<bonniot>what about slices on the lhs of = ?
yes, that could be sugar too12:23
<arjanb>yes but the semantics are tricky
python does replacement in such cases
but arrays have fixed size in jvm12:24
<bonniot>but does the lhs need to be the same length?
<arjanb>not in python
<bonniot>i mean the rhs
so it cannot work on arrays then12:25
ok, so we should not cover this, at least for now
i wondered if we could not unify slices and ranges12:26
ie, instead of e[i:j], have e[i..j]
so [i..j] would always be parsed as a range12:27
and e[i..j] would be sugar for apply(e, [i..j])
<arjanb>i have thought about that and it works in the simple cases
<bonniot>then in the library, we define T[] apply(T[], Range)12:28
but not in all cases?
<arjanb>you get differences when you allow negative indexes in slice12:29
<bonniot>depending on the semantics you choose
for instance 0..-1 is an empty range, right?12:30
<arjanb>yes
<bonniot>so it would match pythin semantics, no?
e[0:-1] == []
<arjanb>no that return the thing except the last element in python12:31
<bonniot>so was it e[i:j] when i == 0 and j == -1 that returns [] ?
<arjanb>in python i>j it returns []12:32
<bonniot>so that matches well the idea that i..j is empty in that case12:33
i think the complication in their slice syntax is that e[0:-1] is not12:34
<arjanb>no negatives are first converted to lenght-x
<bonniot>e[0:(-1)], but e[0 :- 1]12:35
that is, :- is a "keyword"
<arjanb>not in python but in my proposal
<bonniot>why not in pythin?12:36
isn't e[0:-1] different than e[0:i] with i == -1 in python?
<arjanb>no
<bonniot>but you said so above12:37
you said e[0:-1] is the whole array except last element
and that e[i:j] is [] if i > j12:38
i just tried, and they do indeed mean the same: whole but last12:40
<arjanb>i wasn't clear that's only when i and j are non negative
<bonniot>yes, ok
what i don't like about python behaviour is that when you do index computation, you might end up with a negative index "by accident", and then it is better to fail, or maybe to return an empty array12:41
i suppose this is the idea of your proposal
<arjanb>yes
<bonniot>but i think it would be cleaner if your :- keyword was something different, so that there is no confusion12:42
especially if we use ranges
<arjanb>or to allow only integer literals after :-12:43
<bonniot>no, beacuase i don't like that :-1 is not the same as :i when i == -1
after all, why not simply e[i .. e.length-1] ?12:45
that is, no special handling12:46
in any case, we would need open ranges i.. and ..j
<arjanb>yes12:47
for me are ranges and slices 2 different things12:48
<bonniot>cool for loops: for (int i : 0..)
it's always better if you can reduce the number of concepts
<arjanb>another thing is that the end index of .. notation is inclusive12:49
<bonniot>e[i..j] seems to be very logical, more than e[i:j] i think
yes, but why is it a problem?12:50
<arjanb>in all java methods using indexes is end index exclusive12:51
<bonniot>which ones for instance?12:52
<arjanb>substring sublist12:53
<bonniot>that's true12:55
mathematically, the notation would be [i..j[ for exclusive on the right, ]i..j[ for exclusive on both ends, ...12:57
but I think this would be very hard to parse
<arjanb>yes12:58
<bonniot>so maybe we should keep this as a proposal at this point, and see if we find a good solution
i would much rather see visibility modifiers implemented, as I think they are more important and general12:59
ranges also seem simpler13:00
didn't you have an implementation already?
<arjanb>partially
<bonniot>your warning for comparison with null is good, but I don't think the string "Warning: " should be hard-wired in the message. If wanted, it can be the listener that decides how to print the warning16:01
<arjanb>yes another thing i'm thinking about is to split usererror in error that stop the compilation or only stop after finishing the current compilation phase16:04
<bonniot>is there any one that stops the compilation at the moment?16:43
<arjanb>every usererror stops compilation now16:45
<bonniot>that is not true17:04
try compiling:
void foo1() { int i = dummy1; }
void foo2() { int i = dummy2; }
you will get two errors
./test/main.nice:3:23:
dummy1 is not declared
./test/main.nice:5:23:
dummy2 is not declared
<arjanb>i see but it only continue compiling in some cases17:09
<bonniot>yes. it cannot always continue: if a symbol is not found, you cannot typecheck it. this can easily make it impossible to handle the whole method17:11
it's true that we could report more errors in more cases
for instance it is not done for typechecking
but there is no need to create new kinds of errors i think17:12
look at AST to see how it is done
<arjanb>i see but i would like to make the choice for every seperate error17:14
and don't i can be done this way for typechecking because some errors can cause multiple error elsewhere17:35
parser/ast construction stops after one error
<bonniot>for parse errors, it's quite difficult to recover, since you don't know what symbol to expect next17:57
i don't see what is special about typechecking
it can be like resolution
<arjanb>there are quite fewer user errors in the ast construction part17:58
quite a few
<bonniot>that's true17:59
i will look at reporting several typechecking errors, ok?18:00
<arjanb>and for parser errors when multiple files are to be parsed it could continue with the next file
<bonniot>yes, that should be feasible
it's done for typechecking. i'm running a make world to check that does not cause any problem18:05
but listen, frankly, I think this is a relatively minor aspect18:07
it's sure nice to have, but it's easy to do without it
on the other hand, things like initializers, visibility, properties are really missing18:08
you must have seen that the interest in Nice has grown recently (because of 0.8 and freshmeat I think)
<arjanb>yes
<bonniot>(and because the language is maturing)
i think we should really set priorities, and work on those first18:09
what do you think?18:14
<arjanb>i agree18:15
what are the priorities now?18:16
<bonniot>those above18:17
<arjanb>my opinion about what has priority seem to differ
<bonniot>what do you think is a priority?
<arjanb>stdlib and other usability things18:20
things as visibility i never use for things that haven't thousand lines of code
<bonniot>yes, if you project is one page long you don't need visibility :-)18:23
but I think most interesting projects are longer than that, or at least eventually get there...18:24
<arjanb>i would like to hear more of things that users need at the moment
but they complain not enough18:25
<bonniot>i remember the question was asked here about when visibility will be implemented
true. another question I got by email was whether Nice can be used to create Beans
one step in that direction is to implement properties, since beans must export getters and setters18:26
the thing about stdlib is that if some feature is missing, users can easily add it themselves18:27
while most of them won't modify the compiler18:28
<arjanb>true
<bonniot>so since it's mostly me and you touching the compiler, it is more efficient that we concentrate on that part
that said, if you have something ready to add, go ahead
i have also a patch to recover from parse errors in different files :-)18:39
<arjanb>i trying to find out why having a class named Visibility breaks the compiler18:51
no succes yet it even breaks when the class is in a different package
<bonniot>is it a Java class?
what is the error message?
<arjanb>yes
src\bossa\modules\Compilation.nice: line 76, column 13:
startNewCompilation is not declared
i have no idea why it gives this error
<bonniot>is it a public method?18:52
is it in the classpath of the compiler?
<arjanb>yes and yes
<bonniot>is the class itself found?18:54
are you using it only from Nice source, or also from Java?
<arjanb>visibility is used in a field of some class in bossa.syntax18:56
class itself found how do you mean. i get only that error18:57
<bonniot>well startNewCompilation is a method
you can try to use the containing class (by using it as a type)18:58
i did not understand if it was used from Java or Nice code
I'll be going for tonight soon19:00
<arjanb>visibility is used from java
if i can't find it i will mail it to you19:03
<bonniot>i think it's better to move it outside of bossa.syntax in any case
why did you remove ClassicExpression in the parser? It seemed clearer before19:04
<arjanb>i only merged it with expression
<bonniot>i have to go. bye!19:11
<arjanb>bye
* bonniot leaves19:12
* alexgreif joins19:58
hi arjan
<arjanb>hi
<alexgreif>I have a problem with the new development version:
by only recompiling the code with the new nicec I get the following error from the eclipse framework:19:59
Unhandled exception caught in event loop.
Reason:
java.lang.ExceptionInInitializerError
<arjanb>you are using nicec in eclipse?20:00
<alexgreif>unfortunately it dies not tell me in which class. But only one class is called by reflection... I decompiled the class but it has no static initializer
no, I compile it in the shell
eclipse only uses the jar
javadoc tells that this error is thrown if an error is in the static initializer20:01
<arjanb>never heard of that error before 20:02
but is that all the info you get from eclipse?20:03
<alexgreif>yes , its not very redselig :(
<arjanb>doesn't have eclipse some sort of debug mode?20:05
<alexgreif>I dont know exactly ... I try the same with the old nicec, to ckeck whether its really only the new nicec20:06
hm I compiled the same stuff with an old nicec, and the same error occures. strange, I cant remember to have changes some sources... I will investigate further20:09
<arjanb>did you use the -R option?20:11
<alexgreif>yes I tried with -R, and the same error with 0.9.0 and 0.9.1. The only thing I did was to restart my unix machine.20:27
never change a winning team :((20:28
is -R the same as removing the nice folder and all .class and .nicei files?
<arjanb>almost
<alexgreif>I will again switch to the latest nicec version and try to find the reason.20:30
<arjanb>you could try to reduce the number of nice classes20:31
<alexgreif>I dont see a difference in the output when I run nicec with or without -R. Even if I dont change the sources, nicec is "writing in archive"20:35
even the time is equal in boch cases. strange. If I dont change sources, -R should take much longer20:37
I invoke nicec like:20:38
nicec -R --classpath ... -a ... package
<arjanb>you should see typechecking generating code and linking when using -R
<alexgreif>yes, but I see the same without -R, also in the case when I dont change sources20:39
I use the -a option. Does the behaviour depend on this option? I dont think so20:40
<arjanb>no
any progress in finding the problem?21:10
<alexgreif>I think I can tell you the reason in a few minutes21:24
it was a missing resourceBoundle in the jar file. 21:27
<arjanb>so no nicec bug21:29
<alexgreif>fortunately not.
the nicec does not copy properties files in the jar by default?
or more generally: files that are not .class .nicei .nice 21:30
AFAIK java copies non-java files by default in the output21:31
<arjanb>i have to look for that21:32
<alexgreif>should I write a feature request, or bug report at sf?21:33
or to daniel?
<arjanb>only .class and .nicei files are copied21:34
i think you should first ask daniel about it21:36
<alexgreif>we should not hardcode that .properties should be copied in the jar, maybe we should copy all *unknown * files
ok
I put it in my shell script until then
<arjanb>maybe adding a compiler switch for copying all files is the best solution21:37
<alexgreif>yes21:45
I have to go now, cu 21:48
* alexgreif leaves

Generated by Sualtam