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

d: I thought about the percentage/proportion problem, I found a more fitting term : "ratio". what do you think?09:00
<bonniot>hi alex09:01
n : the relative magnitudes of two quantities (usually expressed
as a quotient)
yes, that seems to fit :-)
<alexgreif>huh, thanks
<bonniot>well, actually proportion seems more accurate:09:02
n 1: the quotient obtained when the magnitude of a part is
divided by the magnitude of the whole [syn: {proportionality}]
<alexgreif>in which lexocon do you search ?
<bonniot>man dict :-)
<alexgreif>a deban package?09:03
<bonniot>dict is a utility, that searches several dictionaries from the internet
<alexgreif>I see.
<bonniot>apt-get install dict, then! :-)
<alexgreif>another thought: could you assign the frquent users in irc a hardcoded color in the log file?09:04
<bonniot>so 5/3 is a ratio, but not a proportion
<bonniot>this is very picky, but why not use the right word?
is proportion too long?09:05
<alexgreif>I read ratio in a context where there was a number from 0..1
ratio is ok, I think
<bonniot>sure it is ok. proportion is just better :-)09:06
<alexgreif>I dont mind :)
<alexgreif>another thought: could you assign the frquent users in irc a hardcoded color
in the log file?
<bonniot>yes, that would be good
<alexgreif>sould I do it or do you have the time?09:07
<bonniot>i see that this small program is going to grow, with feature requests like this :-)
<alexgreif>its written in nice :-)
<bonniot>i will do it. it is a small program, but i know how it works, since i just wrote it (in nice, of course)
i also use it to test eclipse and your plugin09:08
and you should focus on the plugin and the wiki
<alexgreif>ok. so can define for us three hard coded colors, and the other users still are visible in alterating grey and black
<bonniot>that's an option09:09
<alexgreif>you have another?
<bonniot>one thing i thought of, was to assign a color to *every* user, but to reset it each time a new log starts
it is more general, since it works for any number of users09:10
and what is really important is that you can guess from the color who is writing, consistently in a log file
<alexgreif>then it can be that I have different colors in different logs. thats ok too. How many colors do you want to define? 10 for the start
<bonniot>of course you could combine the two ideas, and also have permanent colors09:11
<alexgreif>the frequent users should have permanent colors
<bonniot>well, it should be possible to use a mathematical formula
so we can use 2**24 colors :-)
but start by picking different ones09:12
i am not sure how good it will look, though. flashy, probably!
<alexgreif>yes but the color choosing algorithmy should be clever enough to crete different colors like red blue green, and not lightgrey, lightblue lightgreen09:13
<bonniot>but start by picking different ones
<alexgreif>flashy is ok, better to differentiate the users
I see you understand what I mean :)
<bonniot>although i think lightgrey lightblue lightgreen ... would also be differentiable
<alexgreif>but not so well
<bonniot>you'll see, in ten years, this program will have per-viewer customisation of the color scheme, ...
you'll be able to chat from the current log, ...09:15
<alexgreif>I know :) but in ten montrh already , not years
<bonniot>and of course you will be able to read your email from it :-)
<alexgreif>Its not a wit, but I thought about it yesterday
<bonniot>which one?
<alexgreif>when I could not log in but say your log entries
<alexgreif>cahtting via log html
<bonniot>well, i don't think i want to implement those
but i plan to release it under the GPL, so maybe somebody will :-/09:17
<alexgreif>I know but it would be possible :) and maybe somebody whant to play with nice, and implement it further
<bonniot>but i forbid you to do it, until the eclipse plugin has refactoring support and automatic completion :-)))
<alexgreif>you can check it in maybe in the exmaples section of the nice project09:18
<bonniot>yes, or maybe provide a link to the project homepage and to the source
<alexgreif>you realized that Im interested in it? :)
<bonniot>we could have a list of applications, flow4j being one (the biggest as far as I know)09:19
<alexgreif>but the plugin has prio, the proto. and after the proto I want to rewrite it without copy paste parts
<bonniot>can you work on it during the week, or only on week-ends?09:20
<alexgreif>on the plugin?
<alexgreif>I can work on it in the evenings, if Im not too tired09:21
<alexgreif>during the wee and on weekends
the tricky partt is that I first have to understand how the copy pasted core is working :) some parts are loke woodoo09:22
when do you think you can add the classpath option?
<alexgreif>if you have kids, the you have no more spare time for your hobbies :((
<alexgreif>classpath option will be the next (still in the proto)09:23
<bonniot>wdym still in the proto?
<alexgreif>we have to define what should be in the proto, after this I will rewrite it
wdym ?
<bonniot>wdym = what do you mean
i'm not sure anybody else uses it09:24
if not, then i invented it (and the log is a proof :-)
<alexgreif>the proto is the version im working on, still the moment when I will rewrite it wothout copy paste parts
<bonniot>do you want to restart from scratch, or progressively replace parts?
<alexgreif>progressively will be hard, because so many parts depend on each other. I still dont know. FirstI have to analyze the current proto and clear my mind, how to make it better that the current proto09:26
<bonniot>yes, a clear mind is very important before starting coding
<alexgreif>and thats what I dont have now :( I still add functionality, and it works:)) but I dont understand everything what I add :) thats why im reading the userguide every night :)09:27
<bonniot>did you print it out?
<alexgreif>yes, I alsoread it in the plane09:28
150 pages
<bonniot>good. so you *will* become an eclipse plugin expert ;-)
<alexgreif>but it covers very much, so its very good stuff
I hope so, otherwise, I cannot answer your curious questions like, "is it possible to do this and that..." :-))09:29
<bonniot>about the log: do you think it should include the arrival and departure of users?09:30
<alexgreif>yes, so we can see the lurkers09:31
<bonniot>or people who came when nobody was there...09:32
<alexgreif>and see how often Im kicked out by my company's connection :(
<bonniot>maybe we should not print when alex*greif comes and goes, not to fill the logs ;-)09:33
<alexgreif>but the you have to make different symbols or thext for coming and leaving
<alexgreif>I saw the "*" sing that is used currently for coming and leawing. Ist it?09:34
in the logs.
<bonniot>no, it is for actions, like:
* bonniot makes an example
<alexgreif>the todays log begins with <alexgreif> hi...09:35
and not with alexgreift entered the chanel09:36
<bonniot>yes, it is not implemented. that's why i was asking if you thought it should be included!
<alexgreif>Ah, Ok, I thought it was already implemented.09:37
then I saw yesterday something else
Ill be away now for reading a spec (work) :(09:39
* alexgreif 09:41
what command did you use when you left?09:42
<alexgreif>I used : /away ...; and after this I made a /me09:43
wdya = why do you ask?
<bonniot>i guessed what it ment :-)09:44
<alexgreif>I sometimes make a /me to keep the connection alive, but I can also type some characters, so dont have to clutter the log with *alexgreif :)
<bonniot>because when I leave it says "bonniot is away: ..." for for you it just says "alexgreif"
you should not need the /me09:45
but something like /away i'm working
i think you could do a command that does not output anything for that
<alexgreif>yes, just typing one character :)09:46
<bonniot>without sending it? will it go though the connection? oh yes, because it is local *to my machine*, but it goes through ssh, right?
<alexgreif>yes, it should be enough09:47
only may companie's ssh needs a kick
<bonniot>ok. aren't you working? :-)
<alexgreif>I hate this spec, its for volkswagen09:48
<alexgreif>is it ok that the plugin proto will include the classpath feature, and the I begin rewriting, the plugin?
it shoul be rewritten as sonn as possible
<bonniot>yes, if that's the way you feel10:06
<alexgreif>yes, I feel thats the best for me and the plugin.
<bonniot>it's good to get classpath soon, because it is badly needed. maybe the archive name too (should not be much more work, should it?)
<alexgreif>archive name ? the name of the jar file?
<bonniot>yes, the one to produce
<alexgreif>ok, and the location is the oroject folder (hard coded, not configurable). that should be sufficient for the proto10:08
<bonniot>actually you you take a string, and pass it to the compiler
if is is foo.jar, yes it will go in the current directory10:09
it could be /foo/bar/tux.jar, in which case it will go there :-)
you don't need to worry about it
<alexgreif>yes but its possible to make a choose button. But I would leave that for the final version
<bonniot>hello arjan
have you read the log to know what's up? :-)
<arjanb>doing now10:15
about that that wrong cvslog message i have said here that i forgot the use a new message10:16
<bonniot>ok i see. no problem
<arjanb>exponentiation is right associative in most languages10:34
<alexgreif>hi Arjan.10:35
<arjanb>i haven't updated the grammar on wiki because it's quite a lot of work but there is already an operator table at http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/NiceExpressions10:36
hi alex
daniel have you seen the testcase for the new bug in the tuples?10:38
<bonniot>about expo: ok, that's what i thought too10:42
<arjanb>now we have 3 open bugs in tuples :-(
<bonniot>arjanb: ou should put links between the two wiki pages
<bonniot>I'm fixing one a bryn's bugs at the moment10:43
<arjanb>I can't reproduce the lastest bug reported by rohan10:51
<bonniot>did you try to execute it?10:57
blanche ~/Nice java -jar tmp/test.jar [10:56 17/06/03]
Exception in thread "main" java.lang.VerifyError: (class: test/fun, method: main signature: ([Ljava/lang/String;)V) Illegal type in constant pool
<arjanb>which jvm do you use10:58
<bonniot>Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-02b-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.1_02b-FCS, mixed mode)
i also tried with 1.4.1
blanche ~/Nice /usr/local/opt/j2sdk1.4.1/bin/java -jar tmp/test.jar
Exception in thread "main" java.lang.VerifyError: (class: test/fun, method: main signature: ([Ljava/lang/String;)V) Illegal type in constant pool
i'll run a verifier on the bytecode
<arjanb>I have no problem using: Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)10:59
Instruction invokevirtual[182](3) 24 constraint violated: Indexing a constant th
at's not a CONSTANT_Methodref but a 'CONSTANT_InterfaceMethodref[11](class_index
= 20, name_and_type_index = 23)'.
<alexgreif>tell me if I should test something on my Mac JDK1.4.1, to localize JDK problems
<bonniot>it looks like a bug in my new feature i told you about, arjan11:01
can you try the development version?
<arjanb>I will try11:02
<bonniot>it has the feature, while CVS doesn't :-/
<arjanb>I get missing return statement error's11:04
Nice compiler version 0.9.0 prerelease (build 2003.06.15, 19:01:52 UTC)11:05
Don't you have a more up to date development version?
<bonniot>on what source do you get these errors? on the bug's source?11:06
<arjanb>yes but it means the development version has the broken tuple thing 11:07
from the diff and not the final version11:08
<bonniot>does it matter for this case?
what version can rohan be using?
<arjanb>no idea then11:09
I see that the bytecode is also incorrect but my jvm does just run so it's not caused by your change to gnu.bytecode11:12
<bonniot>well, the change produces incorrect bytecode. that's abug11:13
<arjanb>42 invokevirtual #22 <Method java/lang/Object.equals (Ljava/lang/Object;)Z>
<bonniot>i don't think it is incorrect
<arjanb>certainly not11:14
<bonniot>with my change, it becomes 42: invokevirtual #24=<InterfaceMethod java.util.List.equals (java.lang.Object)
whic is not
<arjanb>so methods defined in java.lang.object need special treatment?11:15
<bonniot>no, why?11:16
blanche ~/Nice java -jar tmp/test.jar [11:17 17/06/03]11:18
and how looks the bytecode?
<bonniot>should be like before
what happened is that the "more precise method" found that there is an equals method in List11:19
which is "more precise" than the one in object
there were two choices: either pick this new one11:20
but then the bytecode should be change from invokevirtual to invokeinterface
or to reject more precise methods, when their are interface methods, and the original one is in a class
<arjanb>I see11:21
<bonniot>i chose the second one, because this will be more efficient
i have bryn's code working :-)12:39
I'm still doubting about enum's
intuively i like making 2 different classes for enum's better14:02
one for the thing that contains all the enum elements and the other an enum element14:03
<bonniot>xou have to explain your intuitions :-)14:04
why is a class better than a simple method returning the list of elements?
<arjanb>because you can easily add methods the to enum container and you can define methods doing something with that enum container14:06
if the only thing in the container is the list of values, then you can define those methods on that list of values14:08
<arjanb>not yet I'm now writing out my ideas
<bonniot>if this aspect is an issue, then you can start with 'plain-enums', without the feature of listing all the values of an enum type14:09
that is already quite useful, and it can be a good basis to think about the next steps14:10
<arjanb>that is a good idea14:11
<bonniot>i have a question about the implementation of **14:14
after the move that e > 0 is checked by a requires contract, and given the current implementation (for longs)14:17
if assertions are disabled, and ** is called with a negative exponent, the computation will loop for ever
one could think this is ok, because the code is buggy. that's a price to pay if you decide not to check assertions (and thus improve speed)14:19
i thought about changin e != 0 into e > 0, but that would just make the function return with a wrong value, which is probably worse than not returning at all...
so the question is: is it ok not to check when assertions are off?14:20
<arjanb>we can change the precondition to:14:23
long `**`(long x, long e) {14:24
`alwaysAssert`(e >= 0);
I don't think performance of ** is not that important
<bonniot>but then it is not a precondition anymore
for instance, it is not part of the method signature14:25
i thought about14:26
strongly requires e >= 0 ... :-)
<arjanb>but making a difference between contracts you can disable or not is not a good idea i think14:28
<bonniot>i agree
although having different levels could make sense, i suppose
the question is then, should we check everything twice?14:29
for every precondition, it can be a problem if it is violated, and the code might do anything, from a wrong result to infinite loop to throwing an exception14:30
<arjanb>I agree infinte loop is not desirable
but in general if you violate the contract the behavior is undefined14:32
<bonniot>well, it's actually better than a wrong result
if there is an infinite loop, you can notice it
a wrong result might just be used later, and never be noticed
<arjanb>so should always run with assertions enabled14:37
<bonniot>yes, unless speed is critical14:38
but this policy poses a problem:
what if there is a complex precondition, but it takes 1 minute to check it?
maybe i want it to be run in a special debug mode, but not most of the time14:39
especially if this is an interactive program
<arjanb>yes another level of assertion is usefull
<bonniot>hum, maybe you could handle this case by:14:40
<arjanb>"debug" in addition to "assert" ?
<bonniot>requires normalAssertionMode || veryLongCondition()14:41
where normalAssertionMode is a boolean in your program, than you can set to choose the mode
so the theory stays clear and simple, and you can handle this kind of situation like that14:42
<arjanb>yes but debuging is mostly done at the implementations and not the declarations14:43
<arjanb>maybe is shorthand wanted for assert normalAssertionMode || ...14:45
<bonniot>maybe, but that does not sound urgent, now that we know there is an existing solution14:47
we can reconsider when the contracts have been in use for soe time
are you planning to start the plain-enums?14:48
<arjanb> should we make assertion on be default?
<bonniot>well, on JDK 1.4 it is the jvm that decides the default
with sun's, it happens to be false, which is bad...14:49
but i don't think there is anyway to know if assertions are disabled because the user chose too, or because it was the default
<arjanb>yes so I suggest you can only turn them of using explicit -Dassertion=false or something like that14:50
<bonniot>the only solution would be to use an incompatible way to specify assertions, but i'm not sure it's a good idea14:51
<bonniot>so if the user starts with
java --disableAssertions, the assertions would still be enabled???
java -disableassertions is the exact syntax14:52
it's possible, but it's *very* confusing...14:53
<arjanb>yes but at the moment nice programs are mostly run without assertions on I think14:54
<bonniot>but they are also without assertions, I think :-/14:55
the point might be, that people who use assertions should be warned that sun's default is false14:56
on kaffe, the default is true, for instance
actually, it is already said in the manual:14:58
By default, assertions and contracts are not used at runtime.14:59
They are discarded by the just-in-time compiler, and should
cause no slow-down.
They can be turned on when starting the JVM.
<section><title>JDK 1.4 and later</title>
The mechanism is the same as for Java assertions.
Checking can be enabled at runtime with
<userinput>java -ea ...</userinput>.
so that should be enough15:01
<arjanb> a point is that many people see assertions as a debug only thing and that is wrong so I see use in making assertion on by default 15:02
<bonniot>i don't see a good way to do that15:03
turning assertions on and off is the job of the jvm, not the compiler15:04
now you could bug Sun so that they make the next version use assertions by default :-)
or more likely, explain people why assertions are useful, and should be on most of the time15:05
<arjanb>it's possible to detect the jvm version at runtime
<bonniot>if they see it as debug, they would turn it off even if the default was on
yes, but you cannot know if the user specified on, off, or nothing15:06
<arjanb>but if they forget to turn off then they might notice that's usefull to have it on
this is just not the compiler's job to decide this question15:07
<arjanb>maybe assertions on must be strongly recommanded in the manual15:08
<bonniot>maybe. although if we just say "you should really turn them on" then only people who know why will do it, and they would have anyway15:10
if we start to explain, this will lead into subjects that have little to do with Nice itself, which should be the subject of the manual15:11
<arjanb>isn't there a good article explaining this where the manual could link to?15:12
<bonniot>i don't know one
* bonniot is away: for about one hour15:47
* bonniot is back (gone 01:06:19)16:53
<arjanb>do you have any idea why they didn't put an unsigned int in java?17:03
half to the time when the int is used for some sort of index it shouldn't be below 017:06
<bonniot>i suppose it is for simplicity reasons17:11
i'm not sure if an unsigned int would help you much there though
since 0 - 1 == 2 ** 32 - 117:12
you would get the same kind of indexoutofbounds exceptions
now if you can type integer ranges, that's another story17:13
but that's not trivial
<arjanb>many methods with int arguments require int >= 0 so have if you an unsigned int then the method signatures becomes simpler and the compiler can automatic insert >= 0 checks17:15
<bonniot>what would be the semantics of this code:17:17
var uint x = 0;
x = x - 1;
<arjanb>int `-`(uint, uint)17:18
so typing error or automatic insertion of >= 0 check17:19
<bonniot>if this is a typing error, then uint are almost unusable i think17:20
<arjanb>only a typing error if the internal interpreter can evaluate it
<bonniot>can be sure it is an error, you mean?17:25
<bonniot>again, that's difficult
<arjanb>yes it's just an idea what i want to try out when i have to much free time.
something for an experimental extension after 1.0
<bonniot>then i think it might be worth to have interval types, which are more general17:42
but yeah, this is not a current concern
<arjanb>I have another feature request that should make this code do what i expect:17:52
class X {
int i = 5;
class Y extends X {
int i = 3;
void main(String[] args){
Y y = new Y();17:53
X x = y;
I found it strange that the jvm doesn't have problem with the generated code17:54
<bonniot>iirc, you can declared fields with the same name in a subclass17:55
in the jvm and in java
<arjanb>then I want to write this:
class X {
int i = 5;
class Y extends X {
i = 3;
<bonniot>i see17:56
it should not be hard to implement
<arjanb>i think it makes only sense for non final fields
<bonniot>did you need it in practice?
<arjanb>no just an idea
<bonniot>i don't think so
5 and 3 are just the default value of the fields, if none is given in the constructor17:57
so the semantics could be that new Y().i == 3 and new X().i == 5,
<arjanb>you're right
<bonniot>but new Y(i: 42) == new X(i: 42).i == 42
we must also implement default values of fields depending on previous ones17:58
<arjanb>yes but the combination can be tricky
<arjanb>class X {
int i = 5;
int j = i;
class Y extends X {
i = 3;
new Y().j == ???18:00
<bonniot>new Y().j == 3
because new X(i: 3).j == 3
if you wanted 5 as the default value for j, you would write 518:01
if you write i, it means the value of i for this instance, which could be anything
<arjanb>i think in nice should fields with the same name as in the superclass not be allowed18:04
i find it very confusing
<bonniot>it should be allowed at least for private fields, and non-public fields if the subclass is in a different package18:05
otherwise, adding a private field to a class can break subclasses, while the interface won't change, which is not good
so the rule could be that you cannot define a field with the same name as a visible field18:06
<arjanb>yes it's probably an mistake if you define a field with the same name as a visible field18:07
<bonniot>for this, we will need the visibility library first...18:08
<arjanb>a whole library? one class and some static methods should enough18:12
<bonniot>that's an implementation detail ;-)
the idea is that it should be developed as a separate, reusable package
<arjanb>maybe I will look at that next week18:13
<bonniot>that'd be nice
are you working on an assignment now, or on nice?18:14
<arjanb>I'm away because it's my turn to cook today
so what shall you cook?18:15
<arjanb>I'm back19:21
any luck with finding bugs?19:22
<bonniot>oh, i fixed and closed two open bug reports, several hours ago :-)19:36
don't you get notifications?
<arjanb>only of the bugreports I replied in
can I get a notification of every new bug that's reported?19:38
<bonniot>yes, this can be set in the "Admin" section for the bug tracker19:39
<arjanb>I see that bryn and i do have a role/position here http://sourceforge.net/project/memberlist.php?group_id=1278819:40
I would like the receive a notification of every new tracker item
<bonniot>do not, you mean?
I don't know if it makes any difference
<bonniot>you have a role now :-)19:42
i will add you to be notified of new bug reports19:43
<bonniot>i'm going for dinner now...
it seems there can be only one email adress to receive notification on new reports20:48
so I put nice-devel for it instead of my adress20:49
what are bryn's plan with the standard library? is the addition of operators(like for range) discussed?21:33
<bonniot>you should ask him!21:34
i think you are the one who came up with range21:35
<arjanb>i was hoping he would pop up here some time21:42
<bonniot>maybe he's busy21:44
actually, i don't remember where he is from (timezone question...)
the next version of the log has join and leave notification, so we can find out if people came when nobody was there21:46
have you started working on emuns?22:01
<bonniot>how is it going?22:06
<arjanb>I don't because I have nothing I can test yet22:08
btw have you looked at the diff of class constraint thing i send yesterday?22:17
<bonniot>no sorry, i didn't take the time yet22:25
i will look tomorrow
<arjanb>sourceforge.net does have maintenance very often :-/22:45
since they have made the plublic cvs server a backup the automatic test fail every day22:58
<bonniot>today's failure was due to the bootstrap compiler being too recent23:18
wdym about maintenance?23:19
<arjanb>the sourceforge.net is down very often down compared to other sites though it's mostly very short23:22
<bonniot>what sites do you compare it to?23:23
<arjanb>all i regular visit but that might be not fair because i don't visit any site of the same kind as sourceforge23:28
<bonniot>yeah, it is quite huge, with high constraints on bandwidth, cvs servers, download mirrors, ...23:29