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

Using timezone: Central European Time
<bonniot>good night02:40
* bonniot leaves02:44
* arjanb leaves03:04
* ChanServ leaves04:28
* ChanServ joins
* Bluelive joins07:39
* zzorn joins08:39
* bonniot joins09:13
* arjanb joins13:15
<bonniot>hi13:21
<arjanb>hi
<bonniot>i looked at making retypings lazy13:23
to avoid loading classes that are never used
it needs a few changes, but it might work13:24
saves about 100 classes from 500 when compiling a niceswing program
speedup is about 10%. not as good as I hoped, but mesurable ;-)13:25
<arjanb>what about having special packages for retypings13:26
<bonniot>wdym?
<arjanb>like retypings.java.io included with nicec so that nice.lang doesn't get big with all these retyping of standard java classes13:27
<bonniot>what would be the goal?13:28
<arjanb>only read the retyping when their package is imported13:29
<bonniot>what if you do:13:30
let f = bar.getFile();
then you have a java.io.File, but you never explicitely mentioned java.io13:31
<arjanb>the retypings need to be read implicitly then13:37
i don't know if it's worth to avoid parsing and reduce memory in that way
<bonniot>it could be a further optimization13:38
lazy loading would still be useful, because if you reference one java.io member, you don't want to start to load everything else13:39
<arjanb>right
<bonniot>after I commit visibility, if I can get lazy loading tested and clean, I'll commit it13:40
one change it requires is the fullName associated with java methods for identifying what method alternatives belong to13:41
at the moment, it has the name of the method and its Nice type
hum13:42
problem is, we need the Nice type to perform coverage anyway13:43
so can we avoid loading the retypings?
<arjanb>coverage tests for java methods is only needed when it has a nice alternative right?13:47
<bonniot>no
if a Java interface declares a method, and a Nice class implements the interface, we must check there is an implementation13:48
<arjanb>so a nice alternative or a nice subtype of the declaring class13:49
<bonniot>this means we would need to know the whole class hierarchy (from Nice classes) before deciding if we load the retyping13:53
arjanb: what do you think about tuple syntax? the several proposals?15:14
<arjanb>i agree with it but i don't know how to do type inference for tuples15:20
<bonniot>just look at the type of the value, check it's a tuple, and use the type componenents to set the value of each new var15:22
could you try this: http://rafb.net/paste/results/m9oTdr87.nln.html15:29
i get a failure on the second testcase, but only if it is after the first one15:30
weird interaction
i wonder if it's a logical problem in the compiler, or something to do with the filesystem
so it would be interesting to know if you can reproduce it on win15:31
<arjanb>i get failure too15:32
<bonniot>if you have any idea how this can interract like this...15:33
at least it's not a regression
Compiled class a.A was not found ?15:34
<arjanb>yes
swapping the 2 yields:15:35
F:\Nice\testsuite-temp-folder\b\main.nice: line 4, column 19:
Arguments (java.lang.String) do not fit:
a.A new a.A(nice.lang.int)
<bonniot>reading the class is failing with a EOFException, while reading an attribute named java/lang/Object of enormous length15:36
interesting
the two a.A classes are confused15:37
but they should be in separate directories, so invisible to the other tests
!
<arjanb>a bug in the testsuite code?15:38
<bonniot>it would be interesting to try to reproduce it with it, yes
i meant _without_ the testsuite ;-)15:49
* arjanb was diverted by someone18:07
did you find anything else?
<bonniot>about that failure?18:19
<CIA-5>03bonniot * 10Nice/ (22 files in 9 dirs): 18:36
Each module (and package) now has its own Scope.
All symbols are still public, but only visible to packages that import their
englobing package.
<arjanb>it doesn't seem to happen outside the testsuite18:37
<bonniot>ok18:38
did you look at tuples?18:54
<arjanb>not yet18:57
<bonniot>are there other missing forms?
for((int i, String s) : l) ?
<arjanb>afaik only let, var and enhanced for 18:59
<bonniot>ok19:01
another idea for the parser: 0b1101110 (binary literals)
i was surprised to see we don't have it, and neither does java
<CIA-5>03bonniot * 10Nice/src/nice/tools/visibility/api.nice: Display scope names.19:05
<bonniot>bbl19:06
<arjanb>that would be useful
should binary literals be fixed length? and how should negative ones be handled?20:24
<bonniot>back21:26
i think they could be any length (max 32 for int, 64 for long with L at the end)21:27
like decimal
i guess it should be the 2-complenent notation, as they are stored21:28
so 0b1...1 (32 1s) is -121:29
really, they should be handled exactly like hexadecimal literals, i guess the code will be very similar, except for the decoding21:30
<arjanb>i think 2-complement is confusing for arbitarily length
<bonniot>isn't it the same for hexa? 0xFFFFFFFF is -1, no?21:31
i think most of the time this notation will be used for bit sets, so what you want is to match the representation of the int21:32
i don't see any other way
is that OK? what is the alternative?21:35
<arjanb>that's ok
but i rather fix the length on multiples of 821:36
<bonniot>why?21:37
0b111 is useful to define a bit mask
<arjanb>in 2complenent that would be -121:38
<bonniot>ah, then we misunderstood each other21:39
i meant 0b111 should be 7
so it's really the normal binary system for positive integers21:40
just that if it's bigger than the biggest value of the type, it wraps, as do all integers
is this what you wanted?
<arjanb>what would 0b11111111 have as value?
<bonniot>let me count ;-)21:41
<arjanb>as byte it's -1 and as short/int/long it's 25521:42
<bonniot>i think it's 127
next one would be 255
byte(255) == -1, right?21:43
<arjanb>yeah
<bonniot>so that makes sense to me21:44
the literals are int by default, can be made long with L
and you can always convert to get smaller values
there is no 0b in C, or some mainstream language?21:48
just got the first visibility check working (for global values) !21:49
<arjanb>hmmz the most common language with binary literals is sql! :)21:52
<Bluelive>its quite common21:53
<bonniot>;-)
<arjanb>this wins the most trivial implemented feature contest22:08
<Bluelive>what about a not only supporting -1 but also +1 or =1 ? :)22:09
<arjanb>but now i think ConstantExp contains an older bug22:11
int x = 0xFFFF_FFFF;
Incorrect type in assignment to x
Found : nice.lang.long
Expected: nice.lang.int
i think implicit promotion to long is not allowed in java22:17
<bonniot>int x = 0xFFFFFFFF; does that work?22:18
<arjanb>no22:19
<Bluelive>simply becomes -1 right ?
0xFFL ?22:20
<arjanb>it should but nicec makes it a long now
<bonniot>for those things we really want to do the same as java22:21
i can add tests in regtest/coreJava22:22
other cases?22:23
<arjanb>for decimal > 2^31 too22:24
<bonniot>wow
wait, that's normal, no?22:25
<arjanb>what?22:26
<bonniot>javac -encoding latin1 coreJava.java && java coreJava > ok.out
coreJava.java:87: integer number too large: 2147483648
x = 2147483648;
<arjanb>yes22:27
<bonniot>so no problem?
except for hexa
can you fix it soon?22:28
then I would commit the testcase
<CIA-5>03arjanb * 10Nice/ (3 files in 3 dirs): Implemented binary literals like '0b1111000'.22:32
<bonniot>short implementation ;-)22:34
it would be good to have a test with the high bit set22:44
<Bluelive>##java, ugh, luckily you the 'official' nice 22:45
<arjanb>Bluelive huh?22:46
<Bluelive>freenode declared that #java is reserved for sun, and so its now ##java
an 'about' channel
<arjanb>sigh
<bonniot>so what happens on #java?22:47
<arjanb>i guess it will be a dead channel soon22:48
as for the regtest, longs needing 64 bits for a value is useful to test too22:50
<Bluelive>#java is now an autoredirect to ##java22:52
<arjanb>that makes no sense22:53
<bonniot>indeed22:55
<Bluelive>politics22:59
removing the old code generator of pluk is hardwork, wish i designed that better23:03
<CIA-5>03bonniot * 10Nice/src/nice/tools/visibility/flat.nice: Removed useless assertion.23:23
* Bluelive leaves23:53
<arjanb>grmbl00:05
<bonniot>?00:06
* zzorn leaves
<arjanb>i have int handling fixed except for the corner case -214748364800:07
because that parses as -(2147483648)
and 2147483648 isn't an int
<bonniot>didn't we handle that before?
<arjanb>yes but that was a workaround00:10
<bonniot>so what changed?00:11
<arjanb>the constantexp is created before it's made negative
maybe implicit longs could be allowed for decimal literals00:14
<bonniot>ConstantExp negativeIntConstantExp():
{ LocatedString representation; }
{
"-" representation=integerLiteral()
{
representation.prepend("-");
return bossa.syntax.dispatch.createIntegerConstantExp(representation);
}
}
"the constantexp is created before it's made negative" ??
<arjanb>that one is only used in patterns00:16
<CIA-5>03bonniot * 10Nice/regtest/coreJava/coreJava.code: Check that 0xFFFFFFFF is an int.00:21
<arjanb>what do you think of the decimal case?00:28
<bonniot>what is the situation?00:33
<arjanb>whether implicit long decimal literals are allowed00:34
<bonniot>what's the current behavior?00:36
<arjanb>it's allowed
<bonniot>and is there a problem with that?00:38
<arjanb>in case of binary and hexidecimal yes00:39
<bonniot>i think the rule should be that the literal has the smallest possible type that can contain it00:42
well, for decimal at least ;-)
i guess it makes sense for 0xFF to be an int, otherwise it would be confusing00:43
0xFFFFFFFF is an int too
above that it's a long00:44
<arjanb>ok00:45
<bonniot>golden rule is, valid java syntax should be valid, and obviously have the same semantics
well, actually i was wondering if we really want to support octal ;-)00:46
what do you think about octal?
println(0100); // prints 64
confusing, no?
and it's inconsistent with 0x and 0b00:47
<arjanb>it's valid java and i have no idea why they put that arte00:49
that C artifact in
<bonniot>it's like int y[]; !00:51
if octal is really useful, I guess there could be 0o100 for it
but I think we could simply remove language support for it (there are methods to parse octal I think)00:52
<arjanb>yeah00:56
<CIA-5>03arjanb * 10Nice/src/bossa/syntax/constant.nice: Fix handling of non decimal litetal int/long distinction.01:02
<arjanb>hmm typo
<bonniot>:-)01:03
why not allow large numbers to be long without the L ?01:05
<arjanb>it's needed for numbers between 2^31 and 2^32 so it's more consistent requiring the L always01:09
<bonniot>it's needed in decimal?01:10
<arjanb>only in non decimal01:11
<bonniot>ah ok, I did not pay attention ;-)
i think binary literals should be in the NEWS01:13
<CIA-5>03bonniot * 10Nice/testsuite/compiler/ (2 files in 2 dirs): Moved binary literal tests with other literal tests.01:19
<bonniot>the 0xFFFFFFFF testcase is compiling now, but it's not passing because the value is incorrect:01:25
int x = 0xFFFFFFFF;
println("" + x); // prints 1 !!
<CIA-5>03arjanb * 10Nice/NEWS: Integer literal changes.
<arjanb>and println(x + "") ?01:27
<bonniot> int x = 0xFFFFFFFF;01:30
assert x == 1;
that passes
<CIA-5>03arjanb * 10Nice/src/bossa/syntax/constant.nice: Fix sign of hex literals.01:46
<bonniot>is constant.nice:204 used ?01:58
<arjanb>not that i known02:03
<CIA-5>03bonniot * 10Nice/src/bossa/syntax/constant.nice: 02:16
Removed debugging stack trace printing.
Removed unused '#' hexadecimal format support.
<bonniot>i wonder if we should stop compiling dispatch methods inside classes that are in an imported package02:34
<arjanb>yeah i think imported packages should not be not modified02:52
<bonniot>on the other hand, it's practical if you want to define a class for reuse in Java, but define its methods modularly, in several packages03:09
<arjanb>i think that's a pretty rare case03:11