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

* alexgreif leaves00:03
* arjanb leaves03:09
* arjanb joins11:54
* arjanb leaves14:00
* arjanb joins14:03
* alexgreif joins19:34
hi19:35
<arjanb>hi19:37
any news?19:46
* bonniot joins21:04
hello
<arjanb>hello21:06
i think the latest bug report is up to you to solve
it's caused by the addition of the minimal argument constructor21:07
<bonniot>ok, i will look at it21:08
apart from that, we could release a version soon
my only concern is that if we decide to change the syntax for anonymous functions, then we will need a transition period, so -> should not be added as an operator21:09
<arjanb>but you don't want to change the syntax in 0.9.0 ?21:11
<bonniot>not if we release it tonight
i would like to consult a few more people
<arjanb>i'm not so sure about the change to ->
<bonniot>why?21:12
<arjanb>because now is the syntax for function types and creation different21:13
<bonniot>and you think that is good?21:14
i would think it can be confusing
i changed the syntax for tuple types, precisely so that it would be the same for expression and types21:15
<arjanb>that was before my time21:16
<bonniot>anyway, now for tuples, (_, .., _) is used in both cases21:17
<arjanb>how about making a list of undecided issues and plans / goals for this summer and post it to nice-info21:18
<bonniot>yes, such a list can be useful
* alexgreif leaves21:21
<arjanb><T> String `+`(String s, T o) = s.concat(String.valueOf(o));
<!T> String `+`(T o, String s) = o.toString().concat(s);
why not the first not null too?21:22
<bonniot>because it has been like that from the begining. we could change it later, but i did not feel like breaking things just now21:23
<arjanb>ok21:24
<bonniot>so why do you think => can be good?21:26
<arjanb>it's a matter of taste i think
<bonniot>yes, it will take some time to get used to the new syntax21:28
another argument is that => is the usual symbol for logical implication21:29
<arjanb>but you don't use that often
<bonniot>so? this is the operator you added, so I suppose you find it useful :-)21:30
<arjanb>i get didn't get methods for enum working so you don't wait for that for 0.9.021:35
<bonniot>ok
did you make mesures about the optimisations in typing.lowlevel?21:47
<arjanb>yes from no difference in small sources to about 10% for nice-swing21:52
<bonniot>ok, that's good!21:53
i'm double checking at the moment to be sure the code is strictly equivalent...
ah, one thing you did several times:21:54
changing private methods into final private
that should not make any difference, since a private method cannot be overriden anyway
<arjanb>i know21:55
<bonniot>so why the change?
<arjanb>just to have final everywhere21:56
<bonniot>i don't see the advantage
<arjanb>:-(22:01
i just recompile nice-swing and since the last tests after the optimization the compile time has almost dubbled22:02
flow4j now 20% slower22:03
* alexgreif joins22:05
hi,
sorry arjan i had a timeout..... no news
<arjanb>daniel: so some change in the last 3 weeks has hurt the typesystem22:07
the increase of compile time is caused by the tc generation part for dispatch tests22:24
when compiling nice-swing cloning and garbage collection take both 25% of the time22:30
<bonniot>so it's a change since your optimization of typing.lowlevel?22:41
<arjanb>after22:42
the strange thing is i don't see a change could caused this slowdown22:44
<alexgreif> Im going now, cu22:45
* alexgreif leaves
<arjanb>cu
<bonniot>cannot it be the change in Dispatch about value disptch?23:08
<arjanb>no if there are no value dispatch then that part isn't used23:11
has there anything changed related to constraint recently?23:14
<bonniot>that can be checked by looking at the archives of the nice-commit list23:15
i don't understand how the change to BitVector can be correct23:19
in case where the bit is bigger that the current capicity, your new version does nothing...
<arjanb>which method23:20
<bonniot>BitVector.set
<arjanb>i don't see the problem23:25
<bonniot>in an empty bitvector, a set(65) will have not effect in your new code23:27
<arjanb>ensurecapacity creates the array23:29
<bonniot>but you don't call it
while the previous code called it23:30
<arjanb>???
can you copy past that method
btw i didn't even change the set method then23:31
<bonniot>sorry, i was badly interpreting the diff23:33
it is in the clear method, so I have to reread it
<arjanb>yes i see the diff that's generate is a bit messy
* dagobert joins23:41
hi together, i'm only looking round23:43
<arjanb>hi
<dagobert>how can i read the log23:44
<bonniot>hello dagobert
<dagobert>hi arjanb
hi bonniot
<bonniot>there is a link to the log from the website23:49
<arjanb>http://pauillac.inria.fr/~bonniot/nice@freenode/ 23:50
<dagobert>thankyou23:52
hi, i have just read the log (...arjanb wrote: flow4j now 20% slower ), and i have a question about the performance between java and nice. is ther any test up to now?00:00
* arjanb leaves00:09
* arjanb joins
i can't find it back00:14
<bonniot>arjan's note was about compilation time, not running time00:16
<dagobert>excuse me, i don't understand "i can't find it back" - in respect of what?
ok, that was a mistake of me00:17
<arjanb>found: http://pws.prserv.net/dlissett//ben/exp/bench.htm00:22
<bonniot>Nice is normally very similar to Java in performance00:24
<arjanb>currently it's about 10 to 20 % slower but that can improve00:26
<dagobert>thanks, i just write a peace of sentences in preparation for send,00:27
i'm to slowly in formulation
<bonniot>it's ok!00:28
<dagobert>i have just read the log of 2003-07-16 and the part of license, i have told rubberduck my opinion of the licence and about the latent ambiguity00:33
by Sun. There was a text about the accurate legal ultimate opinion several weeks ago.
the result was like
if you don't change anything about the existing source and
you don't change about the correct behavior as meaning of Sun,
the code is free
but i hope i can find the article00:34
<bonniot>what could it mean to change the behaviour without changing the source?
arjanb: why do you think the bug is related to the minimal constructor?
<dagobert>it's a good question, because the article was only about the behaviour of jvm00:35
<arjanb>because the default value isn't typechecked before compilation
<dagobert>this was the conflict between microsoft and sun and the add-on of microsoft00:36
<bonniot>dagobert: i don't think this is related to the issue of reading or not the source included in the JDK00:37
<arjanb>daniel the class included the minimal constructor is compiled when the package with the newexp is compiled00:39
<dagobert>in this moment i think too, rubberduck is to carefully, because i have it often " in demand "
so, my time is up, i wish a good night00:44
<bonniot>bye!
<dagobert>so long
* dagobert leaves
<arjanb>do you see the problem of that bug now?00:45
<bonniot>yeah, i'm testing a fix at the moment00:47
i was actually asking why you thought it was in that area, but you had more: a diagnostic :-)00:48
this could only happen for circularly dependant packages00:49
in a circle, i'm now first typechecking all the packages, then compiling all of them00:51
it solves the problem
i'm waiting to check that no bug is introduced
(thanks to your change, the new testcase is run first :-)00:52
<arjanb>:-)00:55
<bonniot>all passed01:05
<arjanb>should i remove `->` now?01:09
<bonniot>no, I have already done it, just not commited yet01:10
maybe it would make sense if the implication was a lazy operator (like || and &&)01:15
<arjanb>yes
<bonniot>for now, it will be possible to use `=>` (not lazy)01:16
I used | instead of ||
since both booleans are already computed anyway, I think it is faster01:17
since || involves a conditional, with | does not
<arjanb>yes
are -> and => switched already?01:18
<bonniot>no
-> is just disabled, so that we don't need to support it01:19
<arjanb>ok
<bonniot>i asked Bryn
he said that he agreed, but he was worried that some syntax could be hard to read01:20
like
[ `+`, `*`, `-`, `/`].map( (int,int) -> int func -> func(4,5));
[ `+`, `*`, `-`, `/`].map( ((int,int)->int func) -> func(4,5));01:21
could be ok I think
and it's a convoluted example...01:22
<arjanb>this is indeed confusing01:23
said bryn anything about the stdlib?01:24
<bonniot>no, I was asking about the syntax of anon funs...01:25
<arjanb>from wiki: " I think there's room for a lot more collections methods in the standard library - in fact I'm working on some now, hopefully I'll be ready to circulate them for comments some time in the next two weeks. -- BrynKeller - 11 Jun 2003 "01:28
i'm curious to what these addition will be01:34
<bonniot>you should ask him :-)01:35
is everything in the changelog?01:37
<arjanb>-> should be removed01:38
and the list of bugfixes doesn't name everything but that's not important01:40
<bonniot>agreed
should we release now, or do you want to investigate the compilation slow-down first?01:41
<arjanb>i think we can release that compilation slow down is only visible with larger sources01:42
<bonniot>ok01:44
you could try to find out what introduced the slowdown, by checking out copies from different dates between the last benchmark and now01:45
<arjanb>i already have looked at some profiler data and couldn't find an indication of where the slowdown is caused by01:48
<bonniot>but do you know precisely what change in the code caused the slowdown?01:49
<arjanb>no01:50
i only know that the slowdown is in the linking phase and the method that are heavily used are in typing.lowlevel01:51
<bonniot>i you use different checkouts from cvs, you can find out precisely what change caused it01:52
i think this is the first step
<arjanb>yes i have some idea how to find it out but it will take some time01:54
other topic: since most methods where anonumous functions are used, the first argument is a list or something and the second the anon functions.01:58
i was thinking of providing a more convenience syntax for that case.
no concrete idea yet but i just read something about the plans Guide van Rossum has for python 3.0 : "The ability to use map and filter to process lists will disappear, being replaced by list comprehensions. "02:03
<bonniot>yes, list comprehensions can be convenient in some cases02:12
<arjanb>java and lglp: http://article.gmane.org/gmane.comp.jakarta.poi.devel/590002:13
lgpl02:14
this doesn't make to licencing stuff clearer to me02:26
i think i have the first download of 0.9.002:35
<bonniot>it seems this thing about the lgpl has been widely misunderstood03:06
what it means is just the the lgpl applies in Java as in C
you can use a lgpl library in a closed-source program03:07
you need to allow a newer version of the library to be used, that's all
<arjanb>ok why can't they just make simple licences that fit on less than a page03:09
<bonniot>some people do03:12
but the reason they wrote those clauses in the *gpl is that they thought without it, the licenses could be abused by ill-willing people
i'll go to bed now03:13
<arjanb>me too good night03:14
<bonniot>are you planning to restart the visibility library?
<arjanb>first i want to figured out where that strange error with the visibility class comes from03:15
<bonniot>ok03:16
<arjanb>if i'm proceding with the visibility things is that after the weekend
cu tomorrow03:17
<bonniot>bye03:18
* arjanb leaves
* bonniot leaves03:20

Generated by Sualtam