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

Using timezone: Greenwich Mean Time
* GummiEnte joins09:30
Hello...09:31
* bonniot joins09:36
good morning09:37
<GummiEnte>Hood morning Daniel.09:40
Ok, serialisation does what it should do. serialVersionUID also working as expected.09:41
<bonniot>:-)
<GummiEnte>What about The Externalizable Interface?
This is an interface that has to be implemented, if you want even more control over the serialisation...
<bonniot>did you try it in Nice?09:42
<GummiEnte>This interface defeins some functiosn that have to be implemented ...
Not until now...
<bonniot>if the interface defines methods, you can implement them in Nice, no problem
<GummiEnte>But the changes with the closures are really hard...
<bonniot>we'll fix that09:43
what is the current status?
<GummiEnte>with the latest cvs version there occur at quite a few places... If I fix the first 10, I get the next 10... and so on...
...and some of the ifxes doesn't taste that good...
<bonniot>and what form do they have?
then you shouldn't make them
<GummiEnte>well mostly it is something like:09:44
var a;
foreach(... a = somethingelse; ...);
if (a instance...09:45
or even without instanceof behind the closure...
<bonniot>ok. with instanceof i understand why
<GummiEnte>but the var a is local to the scope of the function...
<bonniot>but not of the anonymous function
<GummiEnte>N,o, that's right.09:46
<bonniot>without instanceof, i am surprised
can you give an example?
<GummiEnte>Let me navigate to a concrete examle
...
Ah, Ok. It is of the following form:09:47
var ?a = null;
foreach(... a=something_ungleich_null; ...);
if (a==null) {do_something;} else {a.foobar} ; 09:48
then it gives me the error, that a might be null....for the else tree.
<bonniot>ok, instanceof and comparison to null are handled in the same way
<GummiEnte>Ok.09:49
<bonniot>so it is the same problem
i know how to make these cases pass
do all of them involve foreach?
<GummiEnte>But the thing with null should't be a problem, should it?
<bonniot>forbreak, map?
<GummiEnte>Yes, most of them.
I found these functions handy...
<bonniot>because the value assigned is not null?
sure :-)
that's true, it would just be more work to take this into account09:50
<GummiEnte>Ok.
<bonniot>for now, i will use the properties of foreach to allow all these cases
<GummiEnte>As far as I see, there is quite a lot of work for you and arjan to do...
<bonniot>btw, if you disable the capture in analyse.nice it should pass, doesn't it?09:51
<GummiEnte>I hoven't done this up to now...
<bonniot>well, there is always room for improvement
<GummiEnte>I wanted to give you some feedback about the state with the "strict" checks enabled.
<bonniot>thanks, that's useful
<GummiEnte>I'm now going to compile a compiler with the commented out lines... lets see if this rocks...09:53
...still waitng for your comments about my "native" proposals... To much arguements against them, or to much for them? 09:54
Ok, with the "chckes" disabled still some errors:09:57
var a;
a = ... ;
if (a instanceof ...) {
foreach(...) {09:58
...
<bonniot>yes, ok, i see why
how many are there?
<GummiEnte>hard to say... some others appear first, if I remove the first... and so on... at the moment for the first package only 3...09:59
<bonniot>ok
<GummiEnte>But I know, there will be more.
Should I remove them?
<bonniot>i should be able to handle that too soon
<GummiEnte>Ok, so I leave it like it is for the moment... 10:03
...ah, ok... that was my first package, all other packages depend on... :/ I'll go and have a cup of tea for the moment...10:05
* arjanb joins10:21
<GummiEnte>Hello Arjan.10:22
<arjanb>hi
<bonniot>hi10:24
<arjanb>another trick to fix the errors10:25
A a = .. .10:26
foreach (.... a = ... )
var a2 = a;
if (a2 instanceof) ...
<GummiEnte>yes, but that does only work for local vars, so that I need the variables in the closure... often I need the changes to the var outside.10:27
<bonniot>i'm going to commit changes in a few minutes :-)
<GummiEnte>:)
I'm impressed, how fast the nice compiler develops...
<bonniot>that's the advantage of open-source :-)10:30
<GummiEnte>Yes, really.10:32
<bonniot>ok, it's all commited10:40
can you test it and tell if there is any problem left?
<GummiEnte>Ok, give me some minutes to compile...
<bonniot>it should handle both cases (instanceof around and after the closure)10:41
ok :-)
don't forget to cvs update too ;-)
<GummiEnte>should I comment out or with comments in...
yes, sute :--))
<bonniot>no commenting out10:42
you should try the pure CVs version
<GummiEnte>ok
<bonniot>it seems commit messages arrive out of order on nice-commit10:44
<arjanb>but it only takes a few minutes10:45
<bonniot>well, now i see my commits of 11:02 and 11:41, but there was one in-between10:47
<GummiEnte>:-)))))
It has compiled nearlly without problems...
<bonniot>cool10:48
nearly?
<GummiEnte>Your the best... :-) You two I mean. Thnx a lot...
Yes, some changes I made in between, but not checked ... But only programming errors...
<bonniot>we can't help with that :-)10:49
<GummiEnte>The only thing now still not working is the thing that forces me to recompile all packages at once...10:51
<bonniot>as a reward, you could go to http://freshmeat.net/projects/nice_compiler and rate the project :-)
what is that?10:52
<GummiEnte>Ah, I haven't any freshmeat account... or have I ... ?10:53
<bonniot>easy to get one :-)
<arjanb>A a = new B();11:00
if (a instanceof B) {
int y = a.x;
}
...
()->void f = () => {a = new A();};
<bonniot>yes?11:04
<arjanb>this one doesn't compile because the variable is marked captured too early
<GummiEnte>Ok, I've rated...11:05
<bonniot>true. we could be more precise
the thing is that for two escaping closures, the order should not matter11:06
<GummiEnte>The thing with recompoilation we already talked about (don't really now anymore, If it was arjan or daniel..., sorry)
<bonniot>i agree we should support this testcase sometime in the future11:07
chris: any idea what it is about?11:08
or arjan?11:09
<GummiEnte>I assume it has to do with package.nicei...11:11
If I compile "against" a already compiled pacakge, the compiler complains about soem "not declared" symblos.11:12
<bonniot>i don't remember hearing about htis11:15
<GummiEnte>Ok, then it was arjan I told about...11:16
I'll have to leave for lunch now... W'll see us in about 1 hour...11:17
<bonniot>gutten appetit!11:18
<GummiEnte>Thnx... :)11:21
<arjanb>i don't know anymore why the recompiles are needed and haven't found it back in the logs11:42
<bonniot>you remember hearing about it? did you check your email archive?12:01
<arjanb>yes and it was not by mail12:04
i'm thinking about getters and setters and a few things i'm not sure about12:16
should setters return a value?12:17
defined only inside a class or outside too?
a setter/getter in a subclass should it use the getter/setter in the superclass or access the field directly12:19
<bonniot>i think the setter should return the new value, because you can use it in chain assignments:12:23
let x = a.x = 0;
<arjanb>a possibility is to let the language handle chained assignment istead of each function itself12:24
<bonniot>it's not only assignments12:25
f(a.x = 0)
<arjanb>well every time an assignment is used as expression12:26
<bonniot>that would complicate the compiler. what is the benefit?12:27
<arjanb>complexity only in one place12:32
now different things like arraySetOp try to optimize when they don't have to return a value12:33
<bonniot>a[x] = e is not an assignment anyway, so you would need to handle separately too12:36
<arjanb>true12:37
<bonniot>anyway, i'm not against changing the implementation of assignments if it turns out to be simpler, but i don't think it's obvious. so I would rather use focus on new features now
<arjanb>and the other 2 questions?12:38
<GummiEnte>back12:41
<bonniot>arjanb: a priori, they should be definable outside too, unless that poses a problem12:42
if getters/setters are methods, then you should be able to user super to access the previous implementation12:44
it might be possible to introduce syntactic sugar later
<arjanb>the choice is should use or should be able to use12:45
i just don't have a good feeling about defining a getter\setter for a class from a different place as another package12:47
<bonniot>it could be very useful, when you want to "add a field" to an existing class12:50
you can implement it as a hashtable, but for users they will not see it12:51
<arjanb>yes but in case the field already exist i think it's not a good thing
<bonniot>why?12:53
<arjanb>because it's reasonable to assume certain behaviour of field of class within a package12:56
<bonniot>you could say the same for methods, that they should not be overridable12:58
<arjanb>maybe it could be done with a modifier that restrict where method can be overridable
<bonniot>i think that could be the same as the read/write visibility of the field12:59
<arjanb>where to call and where to override aren't exactly the same13:01
but how often they differ in practise i have no idea yet13:03
<bonniot>for methods it is the same
i think in a first step, we should keep the design as simple as possible13:04
it will be easier to understand for users, and easier to imlement for us
<arjanb>agreed
<bonniot>then, if we find issues, we can think about modifications
i was wondering if we could make getters and setters completely normal methods13:05
that is, we put no special support at all
then, we say that
a.x = e
is syntactic sugar for a.x(e)13:06
<arjanb>for a.getX(e) ?
<bonniot>and a.x is sugar for a.x(), which is already the case
i'm not sure if get/set is necessary13:07
what I don't like about them is that you have to capitalize the first letter
what if both x and X exist?
<arjanb>but for java compatibility you want get and set at least in bytecode13:08
<bonniot>in bytecode, yes
the other thing to implement would be that for a class that has a field x13:09
if there is no setter for x, then one is generated
<arjanb>for java classes you mean?
<bonniot>no
<arjanb>for javaclasses it could solve the protected field problem13:10
<bonniot>we cannot modify the java class13:11
we could do it for Nice classe that have a java superclass, but that's a different issue, let's say focused :-)13:12
actually, it would be nice to be able to write a.x = e when a is of a java class with a setX() method13:13
<arjanb>yes
<bonniot>so maybe we can use getX/setX names
this feature will then come freely
<arjanb>i think both getX/setX and x()/ x() = .. should be allowed in Nice13:14
<bonniot>hum, that might be confusing
<arjanb>it are just aliasses
<bonniot>you mean, for defining the getters and setters?13:15
<arjanb>for calling and maybe for defining
if you define a getter for a nonexisting field how would the compiler now that it has to generate a get... in bytecode?13:16
<bonniot>because you defined it13:17
<arjanb>how do you see the difference between a method with a single argument and a setter?
getter i mean13:18
<bonniot>there is no difference :-)
<arjanb>so every new fields has implicit methodDeclaration of getter/setter and if there now default implementation the compiler will insert one?13:21
now=no
<bonniot>yes13:22
<arjanb>class A {13:29
int x = 0;
x(value) {
assert value>=0;
x = value;
return value;
}
}
class B {
x(value) {
...
x = value;
return value;
}
}
let b = new B();
b.x = -1;
what should happen?
<bonniot>the overrident setter is called13:31
<arjanb>x = value; in class B what happens there?13:32
<bonniot>yes, we need special treatment here, or this will be a recursive call13:33
<arjanb>yes and a fundemental choice between setting the field or calling the setter of A13:34
<bonniot>i think setting the field13:35
to call the setter of A you can use super
<arjanb>i think the calling the setter of A13:36
because that's more consistent with the case where class A doesn't have a real field x13:39
<bonniot>true13:42
i have another idea, which is even simpler
for the whole spec
when you declare a field, it always generates both the default getter and setter (with the specified visibility)
as soon as you want some non-standard behaviour, you remove or rename the field, and define the getters and setters yourself13:43
for the clients, they will not see the difference13:44
it is slightly less convenient if you only want to customize one of them13:45
<arjanb>i don't like this C# solution13:46
what if you want non-standard behaviour in a subclass?
<bonniot>then you override the default getter/setter13:47
* GummiEnte leaves13:48
<arjanb>so you could have 2 pairs of getter and setter overridable in a subclass13:49
<bonniot>?13:50
why 2 pairs?
<arjanb>1 of the auto generated and the other of the defined getter/setter in the class where the field is declared13:53
<bonniot>where the field is declared, that's where the autogenerated is13:54
in the subclasses, there is no new getter and setter, there might be an overriding
what is the problem?
<arjanb>class A {13:56
int x = 0;
int y() = x;
int y(int value) {
x = value;
return value;
}
}
class B extends A{}
<bonniot>class A does not make sense13:57
why not just class A { int y; } ?13:58
it's exactly equivalent
<arjanb>y could do something special with x in the getter/setter13:59
<bonniot>ok
so what is the problem?
<arjanb>that you can overide both x() and y() in B14:00
<bonniot>if x is just meant to be the "implementation" of the property y, then you declare it as private14:01
<arjanb>that's possible if class A and B aren't in the same file14:04
<bonniot>it's always possible14:05
yes, if they are in the same file, x will still be visible14:06
but that means A and B are closely coupled, soI don't see the problem
<arjanb>and how do you call the constructor of a when you want to set the field
<bonniot>x?14:08
<arjanb>yes
<bonniot>well, you don't need to set it because it has a default value
<arjanb>if it has not?14:09
<bonniot>of course, we also need custom constructors
so, since x is a private field, the author of A will either give it a default value, or write a custom constructor that sets it to a sensible value14:10
again, we can refine the design later, but this is quite simple and already gives the most important feature14:11
i think it is already more advanced than C#, because you don't need to write the properties in the default case, and you can give different visibility to get and set14:12
<arjanb>true14:13
<bonniot>i think ~ 90% of properties have the default implementation
people just writte getters and setters to be safe, in case they need it later
with this, you can safely start with a field
can you override accessors in C# ?14:15
<arjanb>but i'm not sure which is better: field and getter/setter with the same name or your proposal
<bonniot>my proposal is a first step14:16
<arjanb>overloading setters is not possible in C#
<bonniot>and override?14:17
<arjanb>override only if declared virtual or declared in an interface14:19
<bonniot>ok14:21
it is still possible to support later field and accessors with the same name
i think we don't need to handle getters/setters differently at all (provided overrides use super, which is OK for now)14:31
<arjanb>the compilation of custom constructors is quite difficult14:38
<bonniot>did you try it?
<arjanb>no only thinking about
you want the custom constructors inside the class so that they are callable from java but the jvm requires that the statement in a constructor is call to super constructor14:39
<bonniot>why is that a problem?14:43
<arjanb>how do you can the real or another custom constructor at the end of an custom constructor?14:44
can=call
i assume you can't call multiple constructors in a constructor14:46
hmz i can't find that stated explicitly in the jvm spec14:50
<bonniot>maybe it is just the Java spec
even in Java, you can do
super(f(x));
so f is executed before the call to super
you cannot access this before the call to super, i think14:51
anyway, that's another feature, we can work on that one later :-)14:55
do you agree with the simple spec for properties as a first step?14:57
<arjanb>about yes15:02
<bonniot>i thought I would commit some testcases, so we can check we agree on the spec and think of all possible issues, and it will help to implement the spec correctly15:04
<arjanb>ok
<bonniot>check out http://www.csdaily.com/ :-)15:07
<arjanb>great but that site doesn't looks very active15:10
<bonniot>no...15:11
we have to make it widely known just now :-)
<arjanb>we don't realy need more users at the moment15:12
<bonniot>why not? most features are quite stable now15:13
<arjanb>stable but the todo list is still quite long15:15
<bonniot>that's not a problem, is it? :-)
the todo list will never become empty, unless the project dies :-)15:17
<arjanb>the part of the todo with the things where everyone agrees on that should be done is quite long15:19
<bonniot>properties, custom constructors, visibility15:21
what else?
<arjanb>bugs
<bonniot>we should add bugs? :-)
seriously, i don't think any of the known bugs is a stopper for anyone15:24
maybe i'm wrong, it would be good to know if it is the case
<arjanb>the bugs with initializers and with tuples are quite serious15:25
<bonniot>for initializers it's solved as far as i know15:26
it's just that the "clean" solution is not completely used yet, so I did not close it15:27
for tuples, you provided a workaround in one case15:29
<arjanb>java.nice is becoming big what about making a subpackage with seperate files for every java.* package15:30
<bonniot>does it really matter?15:33
<arjanb>easier to find where an retyping is15:34
<bonniot>yes, but that's not something one does all the time, and you can use 'search'15:36
:-)
the pb with a different package is that it will need to be implicitely imported too
and currently, this will also slow down compilation15:37
<arjanb>only different files then?
it has happened that some retyping was added twice
<bonniot>it seems that 75% is java.util, so it would not change much15:40
but i don't mind several java-*.nice files if you wish
<arjanb>yes that is the only package i actively made retypings for15:41
<bonniot>it has also lots of generic types
<arjanb>for the testcases of properties the only thing i'm not sure about is the supercalls15:51
<bonniot>yes?16:18
<arjanb>i still think you shouldn't have to use supercalls in getters/setters16:22
<bonniot>yes, we could implement that use the of property in an override is sugar for a super call16:32
but i think we should keep it simple for the first step of implementation, and using super is then natural16:33
<arjanb>ok
* GummiEnte joins17:57
Hello again...17:58
<bonniot>hello
<GummiEnte>Bad news... Something is broken...
Exception in thread "main" java.lang.ClassFormatError: com/condor_edv/e3m/util/list/MyListElem (Repetitive method name/signature)
It must be one of your latest changes... Until yesterday that has worked...17:59
<bonniot>can you isolate a testcase?18:00
<GummiEnte>Let me see...
<arjanb>duplicate getter of setter maybe
<GummiEnte>Yes, if I look into the bytecode, there seems to be something duplicated...18:01
<arjanb>do you have a set.. or get... method in MyListElem or superclass
?
<GummiEnte>private class MyListElem<T> {
T e;
MyListElem<T> next;
}
<arjanb>what exactly is duplicated in bytecode?18:02
<GummiEnte>Method public setNext (com/condor_edv/e3m/util/list/MyListElem ) -> com/condor_edv/e3m/util/list/MyListElem18:03
Method public setNext (com/condor_edv/e3m/util/list/MyListElem ) -> com/condor_edv/e3m/util/list/MyListElem
The code for the methods are also nearly the same.18:04
Do you want the code? Or maybe the complete class?18:05
<arjanb>don't need the code
how do you compile this class18:06
<GummiEnte>aehh, ant...
<arjanb>daniel could you check if where getters/setters are generated is in the correct compilation fase
<GummiEnte>until now I haven't had any problems with this package... so for this package I doesn't remove the package.nicei.18:07
<arjanb>i mean do you use -R?
<GummiEnte>No... Not -R.
These package gets compiled in a firststep.
<arjanb>i see
<GummiEnte>and until now, it had worked without any problems. Only two other packages (with more code in) must be recompiled complety every time I reference to them... 18:08
<arjanb>removing package.nicei should work for now18:09
<GummiEnte>That becomes really unhandy.18:10
<bonniot>you can add recompile_all="true" to the ant task18:12
arjan, could you reproduce this?
<arjanb>commenting line 218..220 in bossa.syntax.NiceClass should work too
<GummiEnte>Yes, but now I even have to recompile all the utilitiy packages ...
<bonniot>i'm surprised, because it should have been caught by the testsuite18:13
commenting will do too
<GummiEnte>So, I've programmed something special, that is not in your testcases?
<bonniot>it does not look so special, but it might depend on the build18:15
what is the relevant part of the build file?18:16
<GummiEnte>Well, I even could reproduce it without the ant... compile package A and B (indepent of each other). Then compile package C that depends on B. then package D that depends on C and A...18:17
<arjanb>in which package you have that class?18:21
<GummiEnte>That is the surpising thing (for me, cause before it does cause anything that hurds.) the class is in A
...---forme cuase it does NOT...18:24
<arjanb>daniel how to import 2 packages in testsuite format?18:25
<bonniot>import a,b ?18:26
<arjanb>i have reproduce it in a testcase18:29
<GummiEnte>Great.
<arjanb>_/// PASS
_ /// package a
_ /// Toplevel
_ class A<T> {
_ ?T e;
_ ?A<T> x;
_ }
_ /// package b
_ ;
_ /// package c import a
_ ;
_ /// package d import a,c
_ new A(e:null, x:null);
<bonniot>good18:30
i think createGetter should only be called when initially compiling a package18:31
<arjanb>yes
simplified a bit18:32
_/// PASS
_ /// package a
_ /// Toplevel
class A<T> {
?A<T> x;
}
_ /// package c import a
;
_ /// package d import a,c
new A(x:null);
daniel can you fix this?18:36
<bonniot>can't you?18:39
i think i have fixed one of the tuple bugs18:49
<arjanb>i'm not sure how to fix it18:50
<bonniot>did you try not to generate when the package is already compiled?
<GummiEnte>Ok, I'll have to leave... Thnx for all your support... We'll see us tomorow morning.18:55
<arjanb>cu
<GummiEnte>cu18:56
bye18:57
* GummiEnte leaves
<bonniot>arjan?18:59
<arjanb>yes19:00
i don't know classes are compiled19:01
but fields seems to have some way to avoid duplication
<bonniot>definition.inInterfaceFile will tell you if this package is already compiled19:03
<arjanb>that doesn't seem to work :(19:14
if (! definition.inInterfaceFile())19:16
{
String fname = sym.getName().toString();
String suffix = Character.toUpperCase(fname.charAt(0)) + fname.substring(1);
createGetter(suffix);
if (!isFinal)
createSetter(suffix);
}19:17
i don't get it19:18
<bonniot>does inInterfaceFile return false several times?19:19
<arjanb>no only once19:25
something strange here19:32
because i can't trigger this problem when using 2 packages
you fixed bug #749019 :-)19:36
<Bluelive>your near a miljon bugs ?19:38
wow
<arjanb>no sourceforge has so many bugs
<bonniot>:-)))19:39
the bug numbers are global for all SF
that would be more bugs than lines of code :-)19:41
<Bluelive>thats incredably few for the amount of project the sf has
<arjanb>not all bugs are reported in the bug tracker19:42
<bonniot>and most projects on SF don't have many users...19:47
<arjanb>daniel have you tried the testcase for duplicates getters?19:48
<bonniot>no19:55
<arjanb>any idea what the cause is?21:32
:(21:59
new problems22:00
<bonniot>?22:02
<arjanb> testsuite: testsuite\compiler\methods\optionalParameters.testsuite
testsuite: testsuite\compiler\native\fields.testsuite
Exception in thread "main" java.lang.OutOfMemoryError
<bonniot>is this the consequence of a change you made?22:03
<arjanb>i have added quite a few retyping for java.io22:04
<bonniot>at what proportion of the testsuite does this happen?22:05
<arjanb>half way
i'm now trying with most of java.io retypings commented out
not half way but at 2 third22:07
the retypings aren't the problem i think, it only came a few testsuite further22:15
hmm inserting system.gc() in the testsuite runner doesn't seem to make a difference22:37
<bonniot>and rightly so. gc will happen automatically when needed22:38
<arjanb>how big is the memory usage when running the testsuite a minute or so
when you are
<bonniot>as reported by the system?22:39
<arjanb>yes
<bonniot>I'll try
if this happens to you just now, it must be because of a change in your version of the compiler22:40
did you add lots of debugging info, for instance?22:41
<arjanb>no
<bonniot>i experiemented before that printing a lot of info can cause memory exhaustion, because the output is saved in memory22:42
you should check you diff compared to CVS
<arjanb>afaik only change is these retyping22:43
<bonniot>but you said you commented them out
<arjanb>most of them
<bonniot>you can save a copy away, and reupdate from CVS, to see if this makes the difference22:44
<arjanb>i will try
it does make a difference23:06
testsuite ran completely now23:11
17:15 mins23:12
time is grower faster than the number of testsuites
what to do know?23:19
<bonniot>have you given up about the duplicate getter?23:22
<arjanb>i have no idea where to look23:23
strange i have updated from cvs and set the new retypings back and no memory problems yet23:55
<bonniot>what was updated?00:02
<arjanb>only the tuple thing so i almost only cleaned my tree with updated form cvs00:04
<Bluelive>have you been profiling the compiler btw ?
<arjanb>no

Generated by Sualtam