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

Using timezone: Central European Time
* ChanServ leaves01:06
* ChanServ joins02:06
* bonniot leaves
* arjanb leaves02:41
* ChanServ leaves10:01
* magnus-- leaves
* CIA-8 leaves
* ChanServ joins10:02
* CIA-8 joins
* magnus-- joins
* bonniot joins10:33
* arjanb joins11:46
about 7% is done of the conversion and now i'm stuck12:20
<bonniot>are you converting expressions and statements?12:27
<bonniot>and what is blocking?12:29
<arjanb>the java part of bossa.syntax is compiled first and the other expression and statements are used in classes like pattern, enumdefiniton, customconsturtor, ...12:30
<bonniot>couldn't the Nice part be compiled first?12:48
in Expression, the only back-reference I see is about FieldAccess12:49
and since we're in Nice, we don't need to put the method inside the class, so you can start without it
<arjanb>i think there are more depencies in the other direction12:50
<bonniot>in which direction?
<arjanb>nice to java parts
<bonniot>can you point some?12:51
<arjanb>the codegeneration and typechecking parts12:53
<bonniot>those could be in separate packages12:54
i think that would actually be good design, made possible by multimethods
allo? what do you think?13:10
<arjanb>i don't see how that would solve it13:11
<bonniot>first you compile nice.tools.ast.expressions13:14
then the existing java classes in bossa.syntax13:15
then nice.tools.ast.typechecking
does that make sense?13:18
<arjanb>yes though i think i can continue in an easier way13:25
<arjanb>for the most expressions and statements it's only the constructor that is used elsewhere13:27
so adding a create... method to dispatch.java would solve13:29
<bonniot>but splitting packages would avoid that work-around, and I think it would make the design clearer13:33
for instance, with a separate package for code generation, it would be simpler to work on an alternative code generator, and there should more restricted dependency on gnu.expr13:35
<arjanb>i can continue easily now and i'm sure i will find other dependencies which may require even more design changes13:39
<bonniot>ok, as you wish. keep me posted, and we can do a pair review before commiting :-)13:41
<arjanb>having imports working differently than in java is a real pain in the conversion13:59
<arjanb>because a import affects the whole package in Nice
and the java bossa.syntax classes uses importing of single classes extensively14:03
<bonniot>i agree we should limit import .* like in Java14:22
that can be done together with the visibility system
* magnus-- leaves15:34
<arjanb>sigh my concentration has depleted19:14
<bonniot>it's a good idea to make pauses ;-)19:16
<arjanb>i do reguarly but the weather is the problem19:18
<bonniot>too hot?19:39
<arjanb>too humid19:56
converted overloadedsymbolexp but now the location info goes wrong somewhere19:59
will do no more conversion for today20:43
btw i send my latest version by mail20:44
<bonniot>ok got it21:07
<arjanb>any comments?23:32
you could try to convert a small class to see the problems23:36
<CIA-8>03bonniot * 10Nice/src/bossa/modules/Content.java: 23:44
When source code is not available, use the last compilation time to determine
if importing packages should be recompiled.
<bonniot>i'd rather not try conversion atm, because I have other things in mind, but i'm ready to answer questions...23:45
is there any specific pb?23:47
<CIA-8>03bonniot * 10Nice/src/bossa/modules/JarCompiledContent.java:
Take into account the date of the jar file itself, to be sure to recompile
importing packages when the jar was created after compilation.
<arjanb>i don't have any specific problems but i found some issues that should solved before 1.023:50
<bonniot>what issues?23:51
<arjanb>leaking imports, nullness inference for final fields23:52
i need too much casts and notnulls now
<bonniot>what is causing the casts?23:54
<arjanb>mainly arrays types that don't fit23:55
<bonniot>is that bc of Java or pure Nice?23:56
<bonniot>if you see a pattern, you could add it to the wiki page about casts. unless it's a known feature request already00:00
<arjanb>one of the problems is: <T,U,V | T <: ?V, ?V <: ?U > ?U[] toArray(Collection<T>, ?V[])00:01
this signature is correct but very inconvenient because of returning ?U[]00:02
<bonniot>cannot there be a version without '?' ?00:05
<arjanb>i can add one the stdlib
<bonniot>but would that be correct?00:07
it seems not, depending on the size of the array00:08
<arjanb>if it throws an exceptions in case the collection is smaller thna the array
<bonniot>toArray does strange things, like adding null at the end if there is room00:09
it doesn't
why not use simply toArray() ?
<bonniot>it doesn't thrown in that case00:10
<arjanb>but the stdlib function i could add will throw in that case00:11
<bonniot>why not use simply toArray() ?00:12
<arjanb>making it the possible to state the exact array type is usefull when interacting with java code
<bonniot>if you know your array is going to fit, you don't need the return type, you can use the array you passed00:13
<arjanb>that's ugly and mostly doesn't help because it's a new array00:16
actually you can already control the array type with the expected type:00:24
Collection<String> c = ["a", "b"];
String[] s = c.toArray();
Object[] o = c.toArray();
println(s.getClass + " / " + o.getClass);
you get:
class [Ljava.lang.String; / class [Ljava.lang.Object;
<arjanb>i known that works in case of an exact return type00:25
and toArray() is less efficient00:30
<bonniot>well, arrays at runtime only have a monotype anyway00:49
but yes, the efficiency can matter
it should be possible to make it as efficient, though, just harder
<CIA-8>03arjanb * 10Nice/stdlib/nice/lang/array.nice: Added method for filling arrays from a collection.01:36
probably the requirement should be stated formally as a contract instead of in text
<arjanb>good night02:17
* arjanb leaves
* bonniot leaves02:22