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

Using timezone: Greenwich Mean Time
<bonniot>i wrote a classloader that loads from directories, that should solve your problem02:17
<arjanb>it less worse than i thought02:19
<arjanb>24m in stead of 15m normal
<bonniot>that's still quite bad02:20
i commited the new classloader code02:56
can you test it and tell me if it goes back to normal performance on Windows?
i'll stop now. goodnight02:57
* bonniot leaves03:05
<arjanb>it's working normally again :-)03:11
* arjanb leaves04:42
* bonniot joins09:33
hi Bl09:34
* arjanb joins11:47
<bonniot>hi arjan11:59
<bonniot>did you check that enum families work with multiple packages?12:03
<bonniot>that would be good, since the implementations of family are generated in a special way12:05
(which is quite clever :-)
<arjanb>tested and committed12:09
<arjanb>did you found why pre/postcondition disappears now?12:10
<bonniot>yes. i think they always did, it's not a regression12:11
<arjanb>but what crashed that testcase now?12:12
<bonniot>it's just that with the old testengine class loader, the wrong version of the dispatch was picked up, which worked in that case
there is no crash, just a loop, right?
<bonniot>i'm working on that12:13
the bad news is that adding contracts in package.nicei works, but slows down things a bit12:14
so i'm also working on an improvement of loading methods to compensate :-)
<arjanb>quite odd that every change the last days does break something12:17
<bonniot>this one does not break something, just reveals a previous bug12:18
changing the regeneration of constructors was quite a fundamental change, so it's not too surprising it has such consequences12:19
<arjanb>i see
<bonniot>so is the implementation of enums working now as far as you know?12:20
<bonniot>great work!12:21
<arjanb>only a static field and method are missing12:22
<bonniot>which ones?
<arjanb>a field with the list of all element of the enum and a method that finds the corresponding enum element to a string12:24
<bonniot>isn't the first what family does?12:25
the second could be used in readResolve, right?12:26
<arjanb>true but that's not very efficient and i want to make the usage of enums the same as in java12:27
<bonniot>is it supposed to be Color.FAMILY ?12:31
<bonniot>ok, we can think about this, but I don't see it as urgent12:32
<bonniot>what do you think about allowing12:35
foo(Bar b) { ... }12:36
as a synonim for
foo(b@Bar) { ... }
<arjanb>i prefer the syntax of second one12:38
<bonniot>it's very surprising to most new users
and it's purely a convention12:39
<arjanb>multimethod are new to most users too12:44
Bar b differs from style of the other dispatch patterns12:45
i like the obvious difference between implementation and declaration12:46
<bonniot>which other dispatch patterns?12:49
<arjanb>b#Bar b=5 b>012:51
<bonniot>b=5? is that a legal pattern? why not just 512:52
for b#Bar the new form could be #Bar b
this is discussed a bit on http://forums.cookienest.com/viewtopic.php?t=1494&postdays=0&postorder=asc&start=3312:58
@ is confusing to new users, and I think it will make many say: what is this weird language?13:03
<arjanb>i'm not sure about changing things only for new users13:04
<bonniot>the new syntaxs allows you to think in terms of specialization of an existing method
as if Java overloading was resolved at runtime, like it should :-)13:05
i agree an implementation should always look different from a declaration, and it will
no return type, some arguments can have no type13:06
<arjanb>how would @Type patterns look than?13:07
<bonniot>and later, we could allow the keyword 'override', especially if you want to specialize the return type
<bonniot>what is @Type?13:10
<arjanb>anonymous version of x@Type
<bonniot>there are several options:13:11
Type _13:12
Type (if this is not the name of the parameter, look it up as a type)13:13
or not support it
<arjanb>existing: b b@Bar b#Bar @Bar #Bar 10 b>0 b<xyz b@Bar:tc b@Bar(Foo)
new: b Bar b #Bar b ?? ?? 10 b>0 b<xyz ?? ??13:14
<bonniot>missing ones: Bar #Bar Bar:tc b Bar(Foo) b13:16
one other good point is that it is more consistent with the rest of the language (var declarations, method types) where the type information always comes before the name
<arjanb>just Type in steadof @Type is not a good idea13:18
<arjanb>then you have 3 different things that just an identifier could be
<bonniot>yes, but they are stongly checked by the compiler (argument name, existing type, constant)13:20
a typo wuld have no consequence
and visually, a type is normally starting with a capital, so it's clear13:21
that said, i would not mind Type _ too much13:22
what do you think?13:28
<arjanb>Type _ isn't better as just Type13:36
<bonniot>why? (please give your arguments when you claim something, or it's difficult to argue :-)13:38
<arjanb>because _ will probably used for something else and if Types start with capital letters it doesn't improve readability13:41
<bonniot>yes, _ could also be used in expressions, but then there is noambiguity since at this point it is only a name expected13:42
it could still be questionable to overload _ like this, but not sure13:43
so you are saying Type alone is fine? :-)
it does not need to be implemented straight away
fix for contracts commited13:51
and lazy loading :-)14:00
could you look at parsing the new syntax for implementations?14:11
<arjanb>implemented testing now, only anonymous Type patterns are missing14:12
<bonniot>great! anonymous patterns are not urgent at all14:13
running the testsuite is now a bit faster, even with contracts implemented, thanks to lazy loading :-))14:24
<arjanb>new patterns commited14:39
<bonniot>look good :-)14:42
<arjanb>the 3rd open bug report is a feature request i think14:45
<arjanb>the changelog is lagging behind16:11
<bonniot>about what?16:14
<arjanb>enums, bugfixes, syntax, reduced mem usage16:15
<bonniot>enums and syntax, that's you :-)16:16
mem usage is mostly important for the testsuite16:17
but yes, it's also for ant or eclipse plugin
see you later17:46
* bonniot leaves17:47

Generated by Sualtam