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

Using timezone: Central European Time
<CIA-4>03arjanb * 10Nice/src/bossa/syntax/ (analyse.nice tools.nice TypeMaper.java): Converted TypeMaper.00:40
<arjanb>hmm stuck00:58
<bonniot>by what?01:05
<arjanb>can't find a class to convert next01:06
the *Java* classes are possible but Luc is doing that01:08
<bonniot>have you ever tried eclipse?01:09
* hjq98 joins
* hjq98 leaves
<arjanb>only half an hour..01:10
why do you ask?01:15
i can do some bughunting instead01:19
the odd bug in ast.nice has changed shape :(01:25
changing the findelements() method to an initializer causes seemingly unrelated errors01:36
* zzorn_afk leaves01:40
<bonniot>what odd bug?01:56
<arjanb>now i get F:\Nice\src\bossa\syntax\ast.nice: line 52, column 28:01:58
No possible call for getDeclaration.
Arguments: (bossa.syntax.DefaultMethodImplementation)
Possibilities:
?gnu.expr.Declaration getDeclaration(VarSymbol)
?gnu.expr.Declaration getDeclaration(Expression)
if i made findselements() an initializer
a few weeks ago it compiled but generated code throwing a NPE on a Class.isInstance() call02:00
<bonniot>isn't this related to a (possibly implicit) 'this' ?02:01
sorry, i have to go now, see you soon
good night
<arjanb>g'night
* bonniot leaves02:02
* lucp joins02:59
<arjanb>hi03:07
<lucp>good evening.
you've done a lot today
<arjanb>only small classes..03:08
can you bootstrap? i'm not sure if a makefile change is needed03:10
<lucp>i will try it tonight.. i'm about to go prepare dinner. i will let you know by email.
<arjanb>ok03:11
<lucp>~/workspace/Nice2/src/bossa/syntax/customConstructor.nice: line 114, column 18:04:22
No possible call for substitute.
Arguments: (bossa.syntax.FormalParameters, nice.lang.Map<java.lang.String, bossa.syntax.Monotype>)
Possibilities:
bossa.syntax.Monotype[] substitute(nice.lang.Map<TypeIdent, bossa.syntax.Monotype>, nice.lang.Array<bossa.syntax.Monotype>)
nice.lang.List<bossa.syntax.Monotype> substitute(nice.lang.Map<TypeIdent, bossa.syntax.Monotype>, nice.lang.Collection<bossa.syntax.Monotype>)
bossa.syntax.Monotype substitute(bossa.syntax.Monotype, nice.lang.Map<TypeIdent, bossa.syntax.Monotype>)
<arjanb>hmm why haven't i seen this04:30
<lucp>i dont know. a retyping will solve the problem
i added this line:04:38
void substitute(bossa.syntax.FormalParameters, nice.lang.Map<java.lang.String, bossa .syntax.Monotype> = native void FormalParameters.substitute(Map);
<arjanb>it would mean the map is used with 2 different types of keys :/
<lucp>really?04:39
there does not appear to be any other build problems04:41
<arjanb>you used an older version to build right?04:42
<lucp> 0.9.10 prerelease (build 2004.11.22, 23:31:29 UTC)04:43
<arjanb>that's one without the unknowntype default retyping04:44
that explains i didn't get an error04:45
<lucp>i see..
i must go now.. good night04:46
* lucp leaves
<CIA-4>03arjanb * 10Nice/src/bossa/syntax/tools.nice: Missing retyping.05:09
* arjanb leaves05:42
* CIA-4 leaves07:32
* CIA-4 joins07:33
* zzorn joins08:16
* arjanb joins13:47
* CIA-4 leaves15:42
* CIA-3 joins15:44
* bonniot joins17:12
hi
<arjanb>hi17:33
<bonniot>i'm looking at #108455917:36
<arjanb>do you know what the type of key of the map of Monotype.substitute() is?17:41
i found usage of both String and TypeIdent17:42
<bonniot>where is String used?17:43
<arjanb>in CustomConstructor and TypeIdent
TypeIdent is used in MonotypeConstructor17:44
<bonniot>if this is correct, then the type is Object ;-)
<arjanb>then it's odd that TypeIdent is a key while it hasn't implemented equals and hashcode17:46
<bonniot>i think it might only be needed for identity17:47
you could check to see if removing that usage breaks anything17:48
<arjanb>ok17:50
<bonniot>the bug is about methods defined inside a class with less params than its parent18:05
<arjanb>yes18:06
<bonniot>i guess that wasn't tried before18:07
i think i have the solution
by the way, CVS does not compile:18:09
~/projets/Nice-CVS/src/bossa/syntax/customConstructor.nice: line 38, column 9:18:10
Class bossa.syntax.dispatch has no method with 3 arguments and named createConstructorCallSymbol
<zzorn>hello
<bonniot>hi
<zzorn>is there any plans for adding Nice support for the Bean Scripting Framework? ( http://jakarta.apache.org/bsf/ )18:11
<arjanb>that 'dispatch.' on that line shouldn't be there
strange that Luc nor i noticed that..18:12
<bonniot>zzorn: not that I know. nice is not really a scripting language, don't know if this matters18:15
<arjanb>i have no idea for what Bean Scripting Framework can be used
<bonniot>did you see the recent post on nice-info?
<zzorn>BSF basically offers a simple way for applications to add scripting support.. An application integrates with BSF, and can later drop in any programming language that has a BSF binding.18:16
<bonniot>the post was from somebody you wrote a small template engine based on Nice
sounds cool18:18
<zzorn>There's a section in http://jakarta.apache.org/bsf/manual.html about adding BSF support for a scripting language. It doesn't look too complex18:19
<arjanb>daniel: i removed the use of the map with TypeIdent as key and it doesn't have effect on the testsuite18:20
so either a getName() is missing on the tc or the tc doesn't need to be substituted18:22
<bonniot>arjanb: in MonotypeConstructor, the map is queried with a TypeIdent. did you check when maps are created?18:24
<arjanb>as far as i found only String's are put in as key18:25
<bonniot>zzorn: yes. looks like a good project! are you interested? ;-)
<zzorn>I might be :)
<bonniot>arjanb: are you converting MonotypeConstructor?
zzorn: cool18:26
<arjanb>it's converted already
<zzorn>I was just adding Nice scripting capabilities to a small application. I might look into creating a BSF binding once I get a bit more familiar with how integrating Nice with Java works.18:27
s/adding/about to add
<bonniot>what's your application?18:29
<zzorn>Just the starts of a terrain generator
<arjanb>long ago the code was tc.substitute(map) instead of map.get(tc)18:30
<zzorn>I want users to be able to specify small scripts that invoke a sequence of operations that create a terrain heightmap18:31
<bonniot>is the goal to generate pictures of the terrain?18:33
<zzorn>No, just heightmaps initially, with greyscale values corresponding to some height at each point.18:34
<bonniot>ok
arjanb: i removed 'dispatch', but the bootstrap still fails somewhere else18:36
~/projets/Nice-CVS/src/bossa/syntax/defaultMethod.nice: line 102, column 22:
Arguments (?bossa.syntax.MonoSymbol, bossa.util.Location) do not fit:
bossa.syntax.Expression createSymbolExp(VarSymbol symbol, Location loc)
<CIA-3>03bonniot * 10Nice/src/bossa/syntax/customConstructor.nice: Removed an explicit use of the 'dispatch' class in Nice code.18:38
<arjanb>what version do you use to bootstrap?18:39
maybe it's from before the new default array retyping..18:40
<bonniot>i'll try the latest dev version
yes, that's possible18:41
I have fixed the bug
i just need to transpose it to the latest version18:42
zzorn: don't hesitate to ask for help if you need it18:44
<zzorn>Okay, thanks
<bonniot>arjanb: you were right, it seems to fly now :-)18:45
<arjanb>:-)18:48
*away for dinner18:53
i tried replacing the code with tc.substitute(map) but no effect on the testsuite19:18
<bonniot>if commenting it out did not reveal any bug, that's not surprising19:19
where are such maps created?19:21
<arjanb>one in customconstructor19:23
and a trivial one in nicemethod19:26
the substitute in MonotypeConstructor isn't even reached when running the testsuite19:30
<bonniot>ah, that means there is no relevent testcase then19:50
there might be in regtest
i see there was already a bug testcase for the same case. that's two fixes ;-)20:00
<arjanb>i can't find a testcase to reach substitute in monotypeconstructor20:03
i'm pretty sure the current code is wrong20:09
so i can either replace it with the more logical tc.substitute(map) or make that method body an internal error hoping someone will find a testcase20:11
<bonniot>i'll see if regtest exercises this code, after I commit my fix20:25
<arjanb>ok20:26
now you're looking at type params, could you review my fix for bug #106906021:01
<bonniot>where is your fix?21:04
<arjanb>was committed about 4 weeks ago21:05
it's the catch in lowlevelmonotype() in typedef.nice21:16
<CIA-3>03bonniot * 10Nice/ (4 files in 2 dirs): 21:45
Fix methods declared inside classes with less type parameters than their
parents (fixes bug #1084559).
<arjanb>i think we need another type of pattern because of maybe types in overrides21:52
void foo(?A x) {}21:54
override void foo(?B x) {}
atm this yields an error about foo(?b) not covering null21:55
maybe type patterns could make sense for normal method implementations too21:59
the top 2 bug reports can be closed i think22:12
1200 testcase now, that was 300 2 years ago22:17
do you agree with adding a 'maybe type' pattern?22:40
<bonniot>what is foo(?b) ?23:46
<arjanb>i meant the override method23:48
The implementation test failed for method nice.lang.void foo(?B x):23:50
no alternative matches (null)
<bonniot>well, surely this is not desirable
what do you propose?
<arjanb>adding a pattern '?Type' that matches both on Type and null23:51
atm patterns in an override become at type patterns23:53
<bonniot>couldn't it be simply that foo(?B) is attached a default implementation that matches everything?
it's a question when foo(null) is called: which impl is chosen?23:55
it looks like it does not really make sense to define foo(?B)23:56
maybe only foo(B) should be allowed
<arjanb>the problem is that the kind of pattern depends on whether it's an override or not23:57
foo(null) would call the most specific foo thus foo(?b)23:58
if it doesn't make sense to define foo(?B) then the override detection needs to be changed23:59
i'm not sure what makes the most sense00:01
<bonniot>what if there is foo(?A), foo(?B) and foo(?C) with B extends A and C extends A00:02
it looks like an override should never include null
<arjanb>then foo(?B) and foo(?C) are ambigious thus need addition of foo(null)00:03
overriding on maybe types is a little odd but can easily happen when changing code00:11
void foo(X, ?A) and void foo(Y, B) then changing foo(Y, B) to foo(Y, ?B) would break the override..00:16
<bonniot>but that's changing the override. so it's no pb if a change to it breaks it00:20
<arjanb>hmm what if void foo(Y, ?B) is in another independent package?00:24
<bonniot>it's not clear what you mean00:49
it seems that you change something, and that breaks that thing. that's normal
<arjanb>if foo(Y, B) is some method in library used and that one is changed too foo(Y, ?B)00:51
changing thing might breaks thing but unnecessary breaks should be avoided and changes shouldn't change program behaviour in unexpected ways00:53
<bonniot>but the thing changed and the thing broken are the same, right?01:17
<arjanb>yes01:18
<bonniot>so that's not unexpected. the pb is when you change on thing, and it breaks something else01:19
<arjanb>right01:23
the question is how far to go with extending things in other packages, for example generalizing methods01:24
* Vurlix joins02:17
* lucp joins02:21
* Vurlix leaves02:22
<arjanb>hello02:24
do you know about method overrides?02:29
<lucp>a little.02:30
<arjanb>class A {} class B extends A {}02:31
void foo(?A x) {}
void foo(?B x) {}
should the second method override the first or not?02:32
<bonniot>hi luc02:35
<lucp>imo.. the second should override the first.02:37
brb
<arjanb>what should happen if you do foo(null); ?02:38
<lucp>that is a good question.02:47
it would have to be rejected by the compiler as ambiguous..02:49
what is the current behavior?02:52
<arjanb>the current behavior is a bug and says foo(?B x) isn't implemented for null02:53
the problem is to find the behavior that makes the most sense02:54
<lucp>is the problem the same if B does not extend A?02:56
<arjanb>no because then it can't be an override02:57
<lucp>the only options is to make a compiler error, stating that a null call is ambiguous, or using the first base method.. what if a class C extends A as well, and has its own function?02:59
<arjanb>3 possibilities 1) void foo(?B x) doesn't override void foo(?A x) 2) it does override but is ambigious for null 3) override and for null the second one is called03:00
i ask you because my opinion maybe tainted by thinking about nice for a long time03:02
if there's a void foo(?C x) too then option 3 would be ambigious03:04
<bonniot>4) override foo(?B) is an error, you should write override foo(B)
foo(null) is already covered03:05
foo(?B) without override is OK, but you will get the override warning03:06
<lucp>i agree, only one implementation should cover the null case.03:07
<arjanb>that implies not option 303:13
* arjanb goes looking for some dice03:14