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

* arjanb joins10:23
* alexgreif joins10:50
* bonniot joins10:51
have you restarted blanche?
<bonniot>yes. when i am sleeping, it is sleeping too :-/10:52
<alexgreif>so you are not in budapest?
<bonniot>i am
<alexgreif>ah, its the laptop, your server?10:53
<bonniot>no, it's a desktop machine
<bonniot>hi arjan
<alexgreif>just curiosity
<bonniot>what did you think?10:54
<alexgreif>is the nice developer version on nice.sf.net/nice.jar? for the flow4j compilation?
<alexgreif>ok, I will compile it ...
<bonniot>i'm not sure when it was last updated10:55
i am sending a new one at the moment
<alexgreif>ok, then tell me if there.
<bonniot>what you need to change is to avoid declaring two local variables with the same name in the same scope
<arjanb>daniel: http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NiceConstructors10:58
<bonniot>interesting :-)11:00
<arjanb>the log doesn't seem to change to date automaticly11:02
<bonniot>it's a bug ;-/11:03
about syntax highlighting, havea look at http://www.javalobby.org/threadMode2.jsp?forum=17&thread=8082&start=011:05
it is actually a shareware, no we woN't use it directly11:06
and it is built on top of swing
but in the discussion, one person refers to jEdit's similar functionality, which is GPL, and also customizable for different languages11:07
<alexgreif>new flow4j is uploaded11:21
<arjanb>so no problems found in making it compile?11:22
no problems
<bonniot>i wrote the first part of my anser about constructors. please lok at it and give comments11:36
<alexgreif>did you get the new plugin?
<bonniot>i got the email. but i'm writing in the wiki at the moment, i cannot do both ... :-)11:40
<arjanb>alex did you recompile flow4j from scratch(with the existing class and .nicei files removed) ?11:52
<bonniot>just use the -R option11:53
no need to delete files by hand!
updated the wiki page. comments?11:54
<arjanb>you mention public-read and having that depends on having properties or not12:00
<bonniot>because they overlap?
<arjanb>yes if you have properties you can achive public-read with a public getter12:01
<bonniot>the point would be the same12:02
<arjanb>-R is not exactly the same as deleting the class and .nicei files12:03
<bonniot>and maybe public-read could be a short notation for this common case of property
why not?
<arjanb>abstract class X {}12:04
class Y extends X{}
void foo(X);
foo(@Y) {}
compile and then change to
abstract class XX {}
class Y extends XX{}
void foo(X);
foo(@Y) {}
then compile with -R and guess the error
<bonniot>ok, this is a know issue12:05
kown. :-(
the move to compile everything into a jar would actually fix this :-))
one jar per package12:06
<alexgreif>d: I curious about your plugin feedback... tell me if you have time. I have to work now heavyly, so Ill be away12:08
<bonniot>i just tried12:10
i see no output anywhere now :-(
not in the eclipse console
not in the x terminal
<alexgreif>can you open the console view?12:15
try to create a new small project, maybe it stored some preferences somwwhere12:16
<bonniot>i have a small console window, next to the task window12:20
<alexgreif>then open : Window->show view->problems12:21
<bonniot>i have no "problems" in show view12:22
i can get a list with other
where is it in there?
don't see it12:23
<alexgreif>maybe its not installed on your eclipse12:24
<bonniot>it sounds like something basic12:25
what is it?
in what section is it in "other" on your eclipse?
<alexgreif>the eclipse gebug plugins
<bonniot>i have a "Debug" section12:26
it has: breakpoints, console, debug, expressions and variables views12:27
<alexgreif>we have to discuss it later ... :(( i have to phone :((
<alexgreif>Ill provide a snap from my screen12:32
<bonniot>i'm installing eclipse-jdt (java development tools) at the moment12:33
maybe it comes with it?
* alexgreif joins12:39
<bonniot>this flood detection is annoying
i wish we could setup the limit a bit higher...
i mailed the freenode guys, but did not get an answer yet12:40
they might be busy preparing a new version of the server...
alexgreif: i have the java tools installed, but still no problems view
what is that view anyway?12:41
<bonniot>ok, so i believe you
is this different from the console view?12:43
is it a standard view?
<alexgreif>in eclipse there are editors and views. Editor is eg. a texteditor. view is everything else.
<alexgreif>the console and the problems view are both in a tabbed view
<bonniot>what are they for, respectively?12:44
<alexgreif>what menu items do you have under window->show views?
<bonniot>Debug, which has inside: breakpoints, console, debug, expressions and variables views
<alexgreif>console is for stdin and stdout of a running prog, like nice output
<bonniot>show views->others?12:45
this is the one that should have everything
the others are just shortcuts, right?
in others, i have:
<alexgreif>select window-open perspective- resource12:46
<bonniot>ant, basic, cvs, debug, java, team, update, other
<alexgreif>are you in the resource perspective?
<alexgreif>under vindow-showview I have:12:47
ant, bookmarks, navigatoroutlines problems properties, tasks, other...
<bonniot>and if you go to others, where can you find "problems"?12:48
<alexgreif>in "Basic"
<bonniot>in basic i have: bookmarks, navigator, outline, properties, search, tasks12:49
<alexgreif>I have the same but problems too :)) :((
<bonniot>what versions of eclipse?12:50
<alexgreif>a fene vigye el!!!
Version: 2.1.0
Build id: 200306051737
an idea:
<bonniot>2.1.0 200303272130
<alexgreif>create a java project with a bug init, this bug should be shown in the problems view
<bonniot>ok i'll try12:51
<alexgreif>Im curious where the jdt shows the bug after you select "rebuild project"
<bonniot>it shows it into Tasks12:53
<bonniot>for you it's in problems?
I show a snap...
<bonniot>i could think it was changed in a recent version
a problems was created then
<alexgreif>maybe you are right
you see I have the problems tab and the tasks tab
<bonniot>i see12:59
<alexgreif>I thin I have Eclipse 3.0 M113:01
milestone build M1 (June 6, 2003)
but is says Version: 2.1.013:02
??? strange.
<bonniot>is it difficult to use Tasks instead of Problems for the moment?
i think it is because it is a milestone before 3.013:03
so its version is smaller than 3.0
<alexgreif>and you have Release Build: 2.1
from March 28, 2003.
<alexgreif>yep, I have a newer version, the 3.0 alpha :)
<bonniot>it's as if we said: Nice 1.0 M1 (version 0.9.0)
<alexgreif>cmon, get the 3.0 alpha... please!!!13:04
<bonniot>can i do it by software update?13:05
<alexgreif>i dont know...13:07
I headr from a friend, that ist very slow
maybe you get the tarball and install it from sratch
<bonniot>i asked debian-java about their plans to upgrade to a newer version13:10
<alexgreif>ah, so there is none available?13:11
<bonniot>currently not in debian
<alexgreif>so what can we do?13:12
<bonniot>there might an unofficial package
i can install the tarball
<alexgreif>build from the sources?
<bonniot>that's possible too, but i don't see why it is needed. it is probably quite long...13:13
<alexgreif>ok, the get the tarball, and extract it. there should be a script to start eclipse
<bonniot>started the download13:17
<bonniot>is it a non-busy day today for you?
<alexgreif>maybe there is a doc for tips and tricks to run from a tarball
in munich its unnepnap so Im alone in the company :)13:18
its busy if somebody is calling
<bonniot>why aren't you also on holiday then?
or are you? ;-)
<alexgreif>I should so much but lassan, lassan :)
on in berlin ist no holyday :((13:19
<bonniot>i see, germany is a federal country
<alexgreif>Im employed in berlin, so I have to work, even if Im currently in munich
<bonniot>in france or hungary, the holiday are all national i think
<alexgreif>my supervisor is not here (nobody is here) so Its fine to chat :)13:20
france, is more centralistic,
<alexgreif>like luis seize :))
<bonniot>and napoleon...13:21
how long will you stay in BP?
<bonniot>when you start rewriting the plugin, why not do it in Nice?
BP: no idea. probably several years. maybe forever...13:22
<alexgreif>In java I make faster progress, thats importannt for me, because its so much to learn in eclipse, and I dont want to waste time with nice problems, that I surely would have13:23
<bonniot>but, but, ...
<alexgreif>I mean, you are currently only on holydays in hungary?
<bonniot>nice should be faster! :-)
no, i live there
<alexgreif>I know but but.. Im a rooky to eclipse, its so powerful, and if I rewrite the plugin then I will make many reforms, that is easier in java than in nice13:24
so you dont work for your institute?13:25
in france?
<bonniot>i do, but from a distance ;-)
<alexgreif>do you have a flat in france?
<alexgreif>oh, I thought so
<bonniot>why is it easier in java?
<alexgreif>I have to think less :)
<bonniot>i moved here almost two years ago...
think about what?13:27
<alexgreif>I thought you are all the tiime in france, okm now I know.
think about syntax... but maybe you are right, I should try it
<bonniot>probably you are more used to Java, but you need to get familiar with Nice...13:28
and if you experience problems or have questions, you know where to find help!
<alexgreif>rtfm :)13:29
I have to read the manual, after I read the plugin user guide!
<bonniot>yes, but there are also nice-info, #nice, bonniot@...
<alexgreif>so you are a rendes magyar allampolgar?
yep irc, is fine!!!13:30
<bonniot>nem ertem, mit jelent allampolgar
polgar is citizen
<alexgreif>or just a vendegmunkas?
<bonniot>turista vagyok :-)
<alexgreif>relatives of mine are living in BP13:31
<arjanb>why does a frenchman move to BP?
<alexgreif>girls, girls, girls :)
<bonniot>you have one guess!
<alexgreif>as pretty as in france and italy !!!!!13:32
<bonniot>well, i won't comment on the plural. this conversation is logged, after all...
<alexgreif>you should censore it tomorrow, especially the part, what Im doing today13:33
<bonniot>it might already be in google cache, or archive.net!
<bonniot>what relatives do you have here?
<alexgreif>a cousine
she will move there soon from szekszard13:35
I was borne in szekszard
she will work for the university (history)
<bonniot>so what citizenship do you have?
<bonniot>and what are you most? ;-)
ok, I have to weork something :((13:37
tell em when you run eclipse or encounter problems
<alexgreif>are nice programs running faster than java ones?13:40
<bonniot>i was speaking about development time13:43
in running time, they should be roughly equivalent
might be a bit slower still, but we made progress in optimization13:44
<alexgreif>Im speaking about execution time
<bonniot>me too, in the last two lines
but i don't think that's the most important question13:45
and when nice is slower, it should be slightly slower.
i think development time is more important
development + bug finding + maintenance
alex, one good aspect about writing in nice is also that you cannot copy-paste13:47
<bonniot>so you will come up with original abd better ideas, and their will be no license problem :-)
<alexgreif>i realized that already:
<bonniot>and it's good to increase the number of projects in Nice, as they can serve as examples13:48
besides, you will see how fun it is to "bootstrap": develop the Nice plugin using ... the Nice plugin :-)13:49
same as the Nice compiler, partly written in Nice
<arjanb>so when will nicec more to Nice?
<bonniot>it should be easie with the plugin, though. if there is a problem, you can always use the command line13:50
and it's good, because it will make you use your own plugin, so you can get good ideas for it
<alexgreif>ok ok ok, you got me I *will* write it in nice!
<bonniot>and ... oh no need for more arguments :-)13:51
arjanb: it's a long term plan, but not a priority, since it will not add much benefits to the users
<arjanb>i fear i have to send you a diff again daniel :-(13:52
<bonniot>but when we develop something new, we can do it in Nice, if it does not pose bootstrapping problems
<bonniot>a bug?
<arjanb>which i can't find
<bonniot>what is the source?13:53
and the error?
<arjanb> enum Color {red, blue, green}
boolean foo(Color);
foo(=red) = false;
foo(=blue) = true;
foo(=green) = false;
assert foo(blue);
*/// PASS13:54
* /// package a
* /// Toplevel
enum Color {red, blue, green}
boolean foo(Color);
foo(=red) = false;
foo(=blue) = true;
foo(=green) = false;
* /// package b import a
assert foo(blue);
<arjanb> java.lang.NoSuchMethodError: a.Color: method <init>()V not found
at a.fun.<clinit>(F:\Nice\testsuite-temp-folder\a)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:217)
at nice.tools.testsuite.TestCase.runMain(TestCase.java:359)
single package no problems at all
<bonniot>why is the bytecode of a.Color?13:55
what ...
it seems it has no constructor
<arjanb>yes but in a single package case it has a constructor13:57
<bonniot>is EnumDefinition use a subclass of NiceClass?
<arjanb>subclass of definition13:58
<bonniot>but how do you generate a bytecode class?
<arjanb>that happens automagicly13:59
<bonniot>but not well, apparently
ok, send a diff
is this the only testcase that fails?14:00
have you written testcases for all the situations you can think of?
<arjanb>diff send14:06
<bonniot>isn't EnumDef.Symbol a subclass of GlobalVarDeclaration.GlobalVarSymbol ?14:08
not yet
<bonniot>it will?14:09
<arjanb>yes but i don't know when14:10
if i look at the times of the files it seems that the class get modified from the other packages leafing the constructor away14:11
<bonniot>you should use a file hear with copyright 2003 for the new files
there are already some14:12
<bonniot>it's good to avoid using new ArrayList(0) when you just want to pass an empty list14:14
either pass null if the method accepts it, or declare a static final field that holds a reference to an empty list14:15
this avoids creating useless objects are wasting memory
(just some minor comments, as i'm reading)14:16
i see, you declare a ClassDefinition and a NiceClass as fields in EnumDefinition
that must be what you called "magic" :-)14:17
<arjanb>i do nothing to compile it
<bonniot>yes. this is done by the children feature of Node, which does the several passes, including code geenration14:18
yes alex? :-)
<alexgreif>Im not here, I have to telephone :((
<bonniot>arjanb: i think the problem is simply that you create a ClassDefinition internally, but it is not know in the list of classes14:20
you have to modify AST.findElements, to add the enum classes to the list of classes14:21
<arjanb>trying now14:23
<bonniot>another principle to keep in mind is to monimize the number of instanceof and casts in the code14:24
for instance, i see many times14:25
you should create a method in (EnumDefinition.EnumSymbol that returns the value as a NewExp
<alexgreif>is the manual up to date with the new features?
<bonniot>bryn made some updates recently14:26
so it is rather up-to-date
<arjanb>for 0.8.0
<bonniot>you can check in the changelog, to see if anything is missing from the manual
<alexgreif>ok.is it http://nice.sourceforge.net/manual.html ?14:27
<bonniot>there are ps and pdf versions too, if you prefer
their formatting is not perfect
<bonniot>it does not speak about enum for instance :-)14:29
<arjanb>daniel thanks enums work now
do you have all the testcases you could think of?
<bonniot>ok, then add the last ones. and could you try some cleanup, fix the headers, ...?14:31
<arjanb>yes code like this is very ugly14:32
if (((GlobalVarDeclaration.GlobalVarSymbol)symbol).getValue() instanceof ConstantExp)
ConstantExp val = (ConstantExp)((GlobalVarDeclaration.GlobalVarSymbol)symbol).getValue();
i think VarSymbol could have a getConstantValue, which could be null if the value is not constant14:33
that would make sense, and simplify such code
<arjanb>good idea
if there was implicit cast by instanceof then it had looked a lot better14:34
<bonniot>yes, but instanceof is better to avoid too14:35
i think it can be inefficient
anyway, it is not like that in Java, and not even yet in Nice
<arjanb>i don't know but needs to be tested before optimizing dispatch in Nice14:36
do you know anything describe the cost of an instanceof
<bonniot>no. i might depend greatly on the jvm used (and maybe on the weather too ;-)14:38
yes, experiments would be needed14:39
i think enums, visibility and constructors are higher priority than dispatch optimization
do you remember who asked for enums in nice-info? was it rohan?14:40
he could be a beta-tester :-)
<arjanb>yes but some optimization should be done before 1.0
yes it was rohan14:41
<bonniot>good, because we know he is still around
dou you want to send me a new patch after the cleanup? now i have not read everything. i have not even installed it, just read the diff from the mail reader :-)14:42
or you can commit, and i look at the diff from there14:43
i fixed the problem that prevented flow4j from building automatically :-)14:53
maybe it will be used in 2 days ... :-(14:54
<alexgreif>what is the eclipse plugin doing?15:18
<bonniot>i did not try yet to install the new eclipse
i need to work too :-/
but i am confident it will work
<bonniot>so there is no problem, since it works for you15:19
what are your plans now?
<alexgreif>I will read the plugin user guide, then the nice manual, and then I satrt the new plugin.15:27
I just printed the nicem manual for the plane, if I dont fall asleap :)15:29
In eclipse many classes are instantiated by reflection. is this a problem with nice classes?15:30
<bonniot>no problem. nice classes are the same as java classes, with one constructor that takes the values of all the fields, in the declaration order15:48
so you should be able to construct them by reflection
<alexgreif>is there a constructor without args?
<bonniot>not if there are fields15:49
but you can always pass null for each field, if you know what you are doing
<arjanb>maybe is it useful to make the compiler generate a constructor with the minimal number of args15:50
<alexgreif>eclipse creates the instance and calls wich constructor?
<bonniot>arjanb: what does minimal mean in this context?15:51
alexgreif: is it that you pass eclipse a class name, and it instantiate it for you?
<arjanb>only the fields that have no default value
<bonniot>alexgreif: in what cases?15:52
<alexgreif>yes, its all in the plugin.xml file
<bonniot>arjanb: that would make no difference in Nice code
arjanb: so if it is especially for this kind of situation, why not one without any arg?
alexgreif: does the plugin class need fields?15:53
<bonniot>then it is no problem. a class with no fields has a no-arg constructor15:54
<alexgreif>but it can have fields, and then?
<bonniot>arjanb: actually, it could be more convenient when using a Nice class from Java code
alexgreif: so does it need fields or not?15:55
does your existing plugin class have fields?
<arjanb>daniel: you're right
<alexgreif>all classes can have fields.
<bonniot>you are the one who writes them, so you decide if they do or not
the question is whether you need to put instance fields in them or not15:56
<alexgreif>hm, I have to think...
<bonniot>for instance, do you need more than one instance of the plugin class loaded?
does it ever happen?15:57
<alexgreif>eg. the NiceBuilder class that is declared in the xml file will have fields, but every class that is declared in the manifest file is instantiated by reflection
<bonniot>if not, you can store state in package variables/constants
<alexgreif>its not only the plugin class itself. look in the plugin.xml of a jdt plugin and you see many tens of fully qualified class names 15:58
<bonniot>and can there be several NiceBuilder objects instanciated?
i think so, I dont know how eclipse internally handles them
<bonniot>you could check this easily by printing something in the constructor15:59
<alexgreif>yes I know but eclipse instantiates many types by reflection. all wievs perspectives, preference pages...16:00
not all instances that were created by reflection are singletons!!16:01
if its that what you mean
<bonniot>but if they need a field (like a link to the workbench), how is it set?16:02
yes, that's what i meant,
<alexgreif>eg a property page that has a field to the project itself. and its not set by the constructor, but you can set it yourself by asking the workbench16:04
isnt it possible to create alaways a no-arg constructor?16:05
.. if the user provides none
<bonniot>yes, it would be possible
<alexgreif>then it would work with reflection without taking the fields into acccount
<bonniot>but this gives an unsafe way to create an instance16:06
<alexgreif>I see.
<bonniot>(in particular if a field should never be null)
i see that NicePlugin has no instance field16:08
<alexgreif>but the user can set all fields to cast(null), so with the noarg constructor the compiler could do the same
<bonniot>of course the compiler can do it (he doesn't need cast :-)16:10
<alexgreif>but look at net.sf.nice.internal.ui.NiceProjectPropertyPage that is creted by refl. too
<bonniot>but when the user uses cast, he knows that this is dangerous
<alexgreif>and it has many fields
<bonniot>with the noarg constructor, you give another unsafe way to create an instance, which is not explicitly unsafe like cast16:11
i see that class
<alexgreif>ok, how should we handle this problem, that is quite simple in java? classes that are instantiated by relf, but have fields?16:12
I think thats a general queestion16:13
<bonniot>you can instantiate by refl, while giving values to the fields
<arjanb>a noargs constructor isn't unsafe when all fields are maybe null16:14
<alexgreif>I can but eclipse cannot know how many and which type
<bonniot>so one option is to do arjan's proposal, and that you declare all fields with an option type (this is what happens in Java anyway)
and with a default value of null16:15
<alexgreif>ok like cast(null)?
<bonniot>no need for cast
<alexgreif>what is an option type?16:17
<bonniot>alexgreif: isn't eclipse able to call a static method that returns an instance?
<alexgreif>I dont know. I may change in future eclipse versions16:18
<bonniot>but now?16:20
<alexgreif>I dont know the internals of eclipse :(( how it handles reflection. Thats not documented in the APIS
<bonniot>but the content of plugin.xml must be documented for instance16:21
and it must say something about how the class is created
that it needs a no-arg constructor, or something like that16:22
but i can believe they only support no-arg constructors
<alexgreif>I think too
<bonniot>OK, so i see 3 options:
1) you write the plugin completely in Java after all16:23
2) you write the plugin in Nice, but classes that need no-arg constructors and have instance fields in Java
probably that would be only a few classes in Java16:24
3) the compiler is modified to let you somehow create no-arg constructors even when there are fields
whether 3 is possible when you start writing the new plugin depends on 2 things:
if we set this as a priority,16:25
and when you start ;-)
what do you think?
<alexgreif>phone :((( I answer later
<arjanb>daniel you said that setmarkedkind must done first in pattern.java before checking class constraints16:33
but i see also this in pattern.java :
static void in(Monotype[] monotypes, Pattern[] patterns)16:34
throws TypingEx
for (int i = 0; i < monotypes.length; i++)
private void leq(Monotype m) throws TypingEx
m = m.equivalent();
<alexgreif>d: version 2) is okm IMO16:41
<bonniot>arjanb: the difference is that in that code, only the raw type is being used16:42
so it does not matter16:43
in your code, you used the whole type, which created the problem in conjunction with setMarkedType being called too late
it should be safe to do setMarkedType earlier too, but in that case it is not necessary16:44
alexgreif: ok
<alexgreif>danieL: I will start with 2), thats the most compatible solution and is acceptable for a nice project
<bonniot>one trick is to handle the circular dependancies between nice and java16:45
<alexgreif>when I thought about the problem I forgot 2) :)
<bonniot>do you think there might be circular dependencies between nice and java classes of the plugin?16:46
<alexgreif>huh, I dont know yet. maybe. you mena then we have proplems with 2) ?16:48
<arjanb>well then becomes building the plugin complex16:49
building == compiling16:50
<alexgreif>question if I have a nice class thet has fields but all fields I do preset with *null*. What kind of contructor do the compiler generate? also a no args one?
<bonniot>not yet
that was plan 3 :-)16:51
wait i have the killer solution:
<alexgreif>I mean only if all fields are preset with null.
<bonniot>you write the plugin completely in Nice
for each class that needs a small subclass in Java, that only adds a no-arg constructor, by calling the automaticly generated constructor16:52
no building problems
when/if the compiler is updated, you can just remove the java classes and use the parent16:53
<alexgreif>I have to go now :((( my plane!! I will see the logs and discuss your suggestion.
* alexgreif leaves
<bonniot>class NiceClass { String nonNullField; }16:54
in Java
class JavaClass extends NiceClass {
JavaClass() { super(null); //or a value if you can supply one 16:55
looks like a good temporary solution
* alexgreif joins16:57
no log file for today :(((( I see none
daniel: can you mail me the discussion?
* alexgreif leaves16:58
<bonniot>alex: it is in the file dated from yesterday (they are merged)17:00
<arjanb>can't you split the log by hand and reparse it?17:05
<bonniot>i have alredy fixed the bug17:06
i don't think it matters much for this day
but maybe i will, it's 10 seconds job :-)
<arjanb>enums commited18:09
i think the next step should be to handle serialization properly18:31
are you aware of this question?
<arjanb>heard of it but i don't know the details18:36
but i have to eat now18:37
<arjanb>I'm back18:59
the problem is with serializing objects that have an enum as field right?19:01
<bonniot>even serializing a single enum value should work20:30
i suppose serializing a object with a field enum value will come as a consequence
the problem is that by default deserialization will create a new object
so you loose the identity of the enum values20:31
i commit a testcase
i put it in testsuite/enums/...
syntax/ is only for syntactic issues, so the other testcases should also be moved in that directory, in an appropriate file (dispatch.nice, ...)20:32
<arjanb>yes the organization of the testsuite files is a bit chaotic20:34
that testcase you commit i don't think that it ever will pass20:46
<bonniot>why not?
it should
(i should have marked it as BUG, sorry for that)20:47
all enum classes should be serializable automatically
and they should deserialize correctly to the enum values
<arjanb>so enums should implement the serializable interface?20:49
that's also part of the spec for tiger
maybe you should read it20:50
i have to go cooking, it's my turn ;-)20:51
actually, it would be best if you could serialize enums in Nice, and deserialize inJava, or the opposite20:58
i don't know if the spec is precise en?ugh yet to be sure of that20:59
it might be possible to use the prototype to test that
but be very careful, because sun releases some things with a license that forbids you to work on "competing products", which Nice might be21:00
i think it's only if you look at the source, but that should be checked
in doubt, don't do it!
<arjanb>so when 1.5 is out the enums in Nice should be compatible with the enums in Nice?21:04
i don't see that as a priority21:05
2e Nice == Java21:06
* alexgreif joins21:56
hi back!
<alexgreif>Im reading your irc log...
<arjanb>you found it concatted to yesterday?22:02
<alexgreif>yes :)) I did not see that the mod date has changed, thought, the log creates a new file every day. but daniel changed this, I saw.22:03
<arjanb>did you have time to read the manual?22:06
the super construct is not mentioned
<arjanb>other things missing or unclear?22:07
<alexgreif>in chapter "value dispatch" you say :22:09
String booleanToYesNo(boolean bool);
booleanToYesNo(true) = "yes";22:10
<bonniot>hello alex
<alexgreif>is this the same as booleanToYesNo(true){return "yes";} ?
it is the same
it's just shorter and looks nicer :-)
don't you think?22:11
<alexgreif>ok, do I call it like: booleanToYesNo(myBoolVariable);
just like any other method
<alexgreif>yes ist good! for clarification we should write call in the manual too
<alexgreif>I thought is was handled differently as genaral methods.22:12
I already told arjan, that "super" is not declared in the manual.22:13
<bonniot>how would that look like?
ok, that should be fixed
there is some doc in wiki about super22:14
<alexgreif>boolean myBool = ...; println(booleanYesOrNo(myBool));
<bonniot>how is that different?
this looks correct too
<arjanb>the = expression construct may need to be clarified because it's not a part of java
<alexgreif>I just to expand the example in the manual with it. 22:15
<bonniot>arjanb: for the dispatch? now we are speaking about calls
with this example you just gave?
<alexgreif>only the last line to show how to use the syntax;22:16
boolean myBool = ...; println(booleanYesOrNo(myBool));
I would add this to to manual.
<bonniot>that's just like any other method
<alexgreif>maybe its clear, but I had to look at it twice :)22:17
<alexgreif>another thing:
<bonniot>arjanb: the log being together with yesterday is a bug. i fixed it already
that was meant for alex :-)
<alexgreif>example 6.1: requires !isfull():"not full"... 22:18
should this not be: requires !isfull():"ISfull"...
<bonniot>arjanb: yes, compatibility with java for enum serialization is not the highest priority, but it would be nice, unless there is a good reason not to do it22:19
alexgreif: not because there is !
<alexgreif>the syntax is <boolean expr> : <error message>
<alexgreif>so it requires that its not full, other wise assert "is full"
and not "not full"
<bonniot>well, the message could be: "The buffer should not be full"22:21
"The buffer is full, but it should not be full"
<alexgreif>is the same as "is full" :))
<arjanb>the error you get is nice.lang.AssertionFailed: not full
<bonniot>it's a question of point of view22:22
i agree a more clear message should be better
<alexgreif>ok, the we should write: "buffer must not be full" its more clear
<alexgreif>chapter 9 : "Other aspects": Its possible to declare a Java subclass of a Java class22:24
it should be Nice :)
well, that was not false either ... :-)22:25
btw, did you read my idea for the plugin in Nice and the constructors?
<alexgreif>yes, I tried to compile it , it works
shall we change the compiler?22:26
... anyway?
<arjanb>change what
<bonniot>probably, but it's not urgent, then
adding a constructor with less arguments
<alexgreif>for option 3) that if every field has a default value set, then the compiuler inserts a noarg constructor22:27
a noarg constructor would be sufficient
<bonniot>but you should follow 2), right?
<alexgreif>yes I will follow 2)22:28
<bonniot>alexgreif: yes, but having fields with no default values parameters of the constructor is the best design
if you need a noarg constructor, you can always give them values
alexgreif: anything else about the manual?22:29
<alexgreif>but if all fields have default values then we can use reflection without peoblems22:33
<bonniot>yes, that's the plan22:34
<alexgreif>are you correcting the manual or who will do it?
<bonniot>i just did
it is already in CVS, and i will send it to the web in a few minutes
anything else about the manual?
<alexgreif>ok, when will the plan be reality?
... Im looking22:35
<bonniot>not sure. this is not so important, is it? we have a simple workaround for now
<alexgreif>ok, but afterwards we have to change the xml files
<bonniot>yes, is that a problem?22:36
<alexgreif>the java example in example 9.1:
<bonniot>sent the new manual
<alexgreif>please write System.out.println(...) instead of println(...)
in the same example you import my.nice.pkg.*; so you could write display(p) and leave the fully qualif class anme away22:38
<bonniot>it would not be confusing?22:39
<alexgreif>we can leave one and comment the other
<bonniot>i left if away for the classes, but not for the methods
<alexgreif>I mean dispatch.display(...)
and fun.isRich()22:40
<bonniot>but not change all of them?
<alexgreif>instead of my.nice.pkg.fun.isRich()
we can change all of then
<alexgreif>I saw 2 typos, but I dont find them :(22:41
<bonniot>didn't you makr them?
<alexgreif>no :(
abstract interfaces: we could write that with that users can implement new functions to existing Java classes22:42
in the jdk; its mentioned but we should emphasize it22:43
<bonniot>they can do it even with normal methods
<alexgreif>because ist a perfect trick.
String skipTwoChars(String s) = s.substring(2);22:44
<alexgreif>every java programmer will get wet eyes if he sees a good example it
<bonniot>i just added a new method to String
doesn't the log example do that?
<alexgreif>in dylan its nothing new but for java
yes its good, 22:45
I would have needed it at work for swing classes
so use Nice at work ;-)
Bryn is already doing it22:46
<alexgreif>should I held a speech about Nice?
at work?
<bonniot>inside your company?
<bonniot>if you feel it is appropriate, it could be a good idea
<alexgreif>next week Im talking about tcsh
<bonniot>not as sexy as Nice, is it? :-)22:47
<alexgreif>but also quite useful :)
<bonniot>Bryn told me that he started writing some utilities in Nice at his workplace
<bonniot>tell us if you make a speach!22:48
in the manual there is "foreach" like C#...
you tekll that is currently for StringBuffer, Collection...
how can I foreach on a StringBuffer???
is there an implicit tokenizer?22:50
<bonniot>it's each character
<alexgreif>ah, so not eyery word
maybe we should make this clear22:51
<bonniot>If you have suggestions about the manual (more than typos), you can send them to Bryn, he is working on it most now
did you change "const" to "let" ?
<bonniot>in the compiler?22:52
<alexgreif>in the syntax
<alexgreif>for constants
<bonniot>because const might be used in the future for constant (immutable) objects22:53
<bonniot>that is, a reference to an object, with no right to modify the object (change its fields, ...)
like in C++
in chapter 8: "function calls" : the centence before [2] should be explained a bit22:54
for the dummies :)
we have no example for a function/method as a class field
... set by a constructor or a setter method22:56
class NiceClass {String s = "";}
class JavaClass extends NiceClass {public JavaClass() {}}
why do I need super(..) in the JavaClass constructor?
test/JavaClass.java:4: cannot resolve symbol
symbol : constructor NiceClass ()
location: class test.NiceClass
public JavaClass() {}
1 error
<bonniot>you need super because the constructor wants the value of the string23:00
<alexgreif>but it has a default value23:01
<bonniot>this is what will be changed eventually (there will be two constructors)
<alexgreif>ok. so its 3)
<alexgreif>you see, now I have a bone to byte on :-))
<alexgreif>I mean I will ask you more times when you will implement 3)23:03
its not so urgent
<bonniot>about the function calls, i agree this could be explained more gently
ok :-)
<alexgreif>congrats to you both, the manual is fine!!!!!23:04
<alexgreif>but dont forget enums and super :)
<bonniot>actually it is Bryn who has done much of the work on the manual recently
<alexgreif>ok, I will go to bed, hav a nice rest too!23:05
<arjanb>more typos
chapter 2: independantly->independently
chapter 4 namedparameters writting->writing
chapter 8 tuples groupment->grouping
example 8.2 explicitely->explicitly
chapter 9 optiontypes suposes->supposes
chapter 9 optiontypes responsability->responsibility
<bonniot>jo ejszakat, alex23:06
<alexgreif>jo ejt, daniel and arjan
* alexgreif leaves
<bonniot>ok, thanks arjan, all fixed23:08
did you find out about serialization?23:31
<arjanb>no in the 1.5 specs are the details of the implementation not mentioned23:33
<bonniot>i remember there is something about how an enum is serialized23:35
The serialized form of an enum constant consists of its name. If deserialization is attempted and no constant of the correct type exists with the serialized name, deserialization fails with an InvalidObjectException. Deserialization will not be compromised by reordering of enum constants, addition of enum constants, or removal of unused enum constants.23:36
<arjanb>i have seen that23:40
<bonniot>"The serialized form of an enum constant consists of its name" sounds like a spec, which might be enough to guarantee interoperability23:41
you might also be able to find on the net articles about how to properly serialize the "typesafe enumeration pattern"23:43
<arjanb>yes i will look at that later23:50
<arjanb>are you here tomorrow morning?00:27
btw you have reply http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NiceConstructors00:32
I away for the weekend so is there anything that i should do before i leave?00:34
<bonniot>yes, i will be here00:35
yes, i have replied. didn't you read this morning, when i was asking for comments?
i think you did comment, actually
no, i don't see anything specific that you must do00:36
when do you leave?
<arjanb>there is now a reply to what you wrote this morning
<bonniot>ah, i did not know
<arjanb>around 1 pm
<bonniot>i can't find Bryn's article linked to from LtU00:43
oh i do00:44
<arjanb>only on forum
<arjanb>how far should field replaced by method go?00:52
now is x.foo() foo(x) and x.foo equivalent but why not00:53
x.bar = i x.bar(i) and bar(x,i)00:54
<bonniot>yes, writing access must also be interchangeable00:57
only is bar(i) intuitive?
or should it be setBar(i) ?
<arjanb>not really00:59
maybe should both be possible
<bonniot>not really intuitive?
is that what you meant?01:00
i'm not sure having both is a good idea
can be confusing
<arjanb>having a different name can also be confusing01:01
and if there is no difference between fields and methods how should that be handled from the constructor point of view01:03
class X {01:07
void setFoo(int i) {}
let x = new X(foo: 5);
is this then valid code?
<bonniot>fields and methods are not the same01:09
the idea is to hide the difference to clients
but it's true we have to think about the influence to the default constructor
one possibility is that if you change a field to a method, you will need to write a custom constructor to replace the default one, to keep the same interface01:10
but maybe this could be valid code too. this needs more thinking01:11
<arjanb>class X {01:12
char foo;
void setFoo(int i) {
foo = char(i);
let x = new X(foo: 5);01:13
just an idea overloading of the setter to do conversion
just replied on the wiki
i will leave soon
<arjanb>i will leave too01:15