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

Using timezone: Central European Time
* bonniot leaves02:10
* cm_ leaves03:52
* cm_ joins09:20
* bonniot joins10:31
* bonniot leaves12:32
* CIA-5 leaves
* cm_ leaves
* ChanServ leaves
* ChanServ joins12:33
* bonniot joins
* cm_ joins
* CIA-5 joins
* arjanb joins13:36
* fcb joins14:03
<fcb>aaah, hello14:17
I'm trying to do this index thing
and I need to ask questions14:18
<fcb>and btw, I put in an RFE
<bonniot>yes, didn't you get my answer?14:21
<fcb>not yet
I'll have a look
<bonniot>you should get it by email I think14:23
<fcb>yes, very good14:24
do I need to change the status or anything?14:25
<bonniot>of the RFE? no14:26
so, my question:
<bonniot>the general idea is good. my comments were mostly about this particular case
<fcb>from your email that you sent on the first of september, I gather that I'm meant to do something like "d.location().getFile();"14:28
only i don't think you can do getFile on any location, some are not associated with a file
<fcb>but bossa.util.Location doesn't seem to contain a getFile() method
so I need to test to see which type of Location?14:31
in your email you said "...provided it's of type bossa.util.Location.File" but I can't see that class, unless you mean the File class is an inner class of Location?14:38
<bonniot>it is14:39
<fcb>they all seem to be of type bossa.util.Location$Source14:41
<bonniot>that a subclass of Location.File14:42
but Location can also represent the command line, for instance, so there is not always a file associated with it
sorry, but what's the deal with casting? why can't I do this:14:47
<bonniot>you shouldn't need to cast
use dispatch or instanceof on a local variable14:48
(Nice doesn't have Java's syntax for cast. it has a 'cast' operator, but that should be vary rarely needed now)14:49
<fcb>if(d.location() instanceof bossa.util.Location.File) {14:52
File file = d.location().getFile();
causes an error so I wanted to do
if(d.location() instanceof bossa.util.Location.File) {
File file = ((bossa.util.Location.File)d.location()).getFile();
but if there is a more proper Nice way I'll do that
any thoughts?14:55
<bonniot>yes, use a local variable, or a method15:00
<fcb>what is the rationale behind that? (just asking, not criticising)15:02
<bonniot>it would be usafe to use the instanceof with a method call or a field access15:04
haven't you met this before?
so you should do: Location loc = d.location(); assert loc instanceof Location.File; ... // now you can use it as a Location.File15:05
(here I suggest assert, since all definitions should come from a file. if you wanted to handle both cases, use 'if' instead)15:06
<fcb>maybe I have but I couldn't find the info on nice.sourceforge.net/manual.html and I don't have the memory of an elephant15:15
in fact I have a memory like a sieve
you're right, this is not well documented
but we might as well improve the support too, since this bites quite a lot of people15:19
sp, the reason for the unsafety is that consecutive calls to a method or field access can return different results, so the test does not guarantee it will still be true when you use the value again
so, ...15:20
<fcb>yeah, I understand that. I was actually wondering why casts weren't allowed, but I suppose this is because you are trying to avoid ClassCastExceptions15:21
<bonniot>yes, casts are discouraged, but they still exist if you really need. it's just a different syntax15:23
<fcb>can I/you add something to manual.html about this?
<bonniot>if you want to add something, that's great15:24
i'm quite busy with my dissertation at the moment, and I have some bugs to fix on my todo list, so help is welcome ;-)15:25
<fcb>how do I edit that page?15:26
(good luck with your dissertation!)
<bonniot>i thought there was doc for this somewhere, but I can't find it, nor in the Wiki, so I might be mistaken
you should edit the manual.xml page
the format is DocBook
it should be farily easy to see what it's like if you look around the file15:27
<fcb>never heard of that :( but I'll work it out!
<arjanb>fcb: htmlwriter.nice:199 causes that the docstring of a defaultmethodimplementation is not used15:29
<fcb>oh, I couldn't work that one out. welll done15:30
I've been editing my source code - could you give me some context as well as the fine number, pls?15:32
I meant "line number" not "fine number"15:34
arjanb: is it this?
write(DefaultMethodImplementation m, packageName) {
this.write(m.getDeclaration(), packageName);
<bonniot>arjanb: nothing is written about dynamic type inference with fields and method calls?15:37
<arjanb>not that i know15:38
<fcb>ok, I'm might be off now. see you later, and thanks for your help.15:41
<bonniot>see you later. it looks like nicedoc will be really usable soon now :-)15:42
<fcb>yeah, looking forward to it!!!! :)15:43
* fcb leaves
there really is something about it already :-)
* cm_ leaves17:00
<bonniot>i'm looking at the dispatch bug17:52
<CIA-5>03bonniot * 10Nice/src/nice/tools/repository/main.nice: Typos.17:58
03bonniot * 10Nice/src/bossa/syntax/MethodImplementation.java: Cleanup.18:09
<bonniot>it's going to fix this one at the same time:18:12
you commited it. remember where it comes from?
* CIA-5 leaves18:16
* CIA-3 joins18:17
<arjanb>i don't remember that one18:42
* cm_ joins19:14
<arjanb>daniel: is the second one of your testcases fixed too?19:44
<bonniot>no, i think it's a different issue, why?19:53
<arjanb>then i will take a look at it19:55
i'm not commiting yet, because my new version does not bootstrap
but I think they can be fixed independently, the other one is about pattern specificity, no typechecking19:57
i think that one might be about the simplification of patterns based on the type of the implemented method. do you see what i mean?20:01
<bonniot>it's just a feeling, i did not check
* bonniot is away: for the evening20:04
* bonniot is back (gone 03:16:05)23:20
any luck?00:08
<arjanb>it's not in the simplification part00:09
<bonniot>any idea what it is then?00:11
<arjanb>not yet00:13
where are the patterns of overrides created?00:15
<bonniot>same as for a method with default implementation00:17
<arjanb>this works correctly:00:22
<T> void bar(T x) {}
override void bar(String x) {}
but this not:
<T> void bar(T x) {}
override void bar(int x) {}
<bonniot>what happens with the second?00:24
<arjanb>ambiguity because of equivalent patterns in:
D:\Nice\testbug\test.nice: line 17, column 15: bar(x)
D:\Nice\testbug\test.nice: line 16, column 10: bar(x)
<bonniot>there is some special treatment for primitive types because it's not possible to dispatch on them, right? it looks like there might be a link00:27
<arjanb>the patterns get changed somewhere after creation in def method impl but not in Pattern.setDomainEq00:28
found it00:42
it fixes only the second one of your testcases00:43
but there is some check missing in case of:00:44
<T> void bar(T x) {}
override void bar(int x) {}
i think this is invalid code and the current error message comes from the linking phase00:45
<bonniot>but the commited testcase is valid01:07
that one is fixed now except that it breaks the bootstrap01:12
<bonniot>by me?01:13
<arjanb>no my fix for the last testcase in ambiguity.testsuite01:14
strange error:01:15
F:\Nice\classes\nice\lang\package.nicei: line 591, column 18:
Method <T> T[] slice(nice.lang.Array<T> array, int from = 0, int to = `-`(array.length(), 1)) is dec
lared but never implemented:
no alternative matches (nice.lang.Array, nice.lang.int, nice.lang.int)
do you have the same bootstrap problem?01:21
<bonniot>no. isn't it a consequence of your change?
<arjanb>yes but i don't see how01:22
good night01:56
* arjanb leaves
* cm_ leaves02:20
<CIA-3>03bonniot * 10Nice/ (5 files in 3 dirs): 02:45
Take into account nullness when find which method an implementation belongs to.
Always report the precise pattern that prevents an implementation from
belonging to a method, when there is no ambiguity about which method is
* bonniot leaves03:24

Generated by Sualtam