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

Using timezone: Central European Time
<lucp>The implementation test failed for method nice.lang.int getBytecodeFlags(ClassDefinition c):03:16
no alternative matches (bossa.syntax.ClassDefinition$Interface)
there is no ClassDefinition$Interface in my code... it must be getting it from the jar file?
<arjanb>hmm maybe an old retypings is causing problem?03:19
<lucp>i am looking, however i used grep on the whole package and cannot find it.
<arjanb>any retyping on an old class could cause loading it03:20
<lucp>the class was used in an instanceof check.03:26
<arjanb>good night03:49
* arjanb leaves
* insanex joins04:57
hiii!04:58
some one here can help me !!! i have a problem with the jcreator
* insanex leaves05:16
* lucp leaves08:00
* cm__ joins09:59
* cm__ leaves
* cm__ joins10:00
* arjanb joins11:45
<cm__>Is any of you familar with rpm? I don't know how to control the package requirements? 11:59
When building rpms
I found it AutoReqProv: no :-)12:03
* bonniot leaves12:08
* bonniot joins12:21
hi13:35
<arjanb>hi
<bonniot>the nice-eclipse mailing list is created
* fcb joins14:47
hello all14:49
<arjanb>hello
<fcb>ok - before I start coding I would like an opinion on what I'm trying to do14:50
<arjanb>yes?14:53
<fcb>what I want to do is add a whole load more links into it. but can I guarantee that I'm going to be docing all the classes (I don't want a whole load of broken links)14:54
if not, is there an easy way of working out what will be included in nicedoc and what won't?
do you understand what I'm jibbering about?
<arjanb>i think nicedoc should only do nice things which have source available and the rest link only if existing java/nicedoc could referenced14:58
<bonniot>hi frank!15:00
<fcb>hello daniel15:02
yes, I that's exactly right, arjan. Unfortunately, I'm not sure how to work out which ones I have the source for15:03
<bonniot>don't you need to wait anyway before emitting the link to know the target? or do you create the link only based on the name of the method/class ?15:05
<fcb>I can create a link based only the package name and method/class15:07
but it might be a broken link
<bonniot>what if there are homonyms? (possible for methods)15:09
<fcb>I generate a unique code based upon the method arguments15:10
<bonniot>ok
it seems to me you could do it in two passes15:11
but maybe it's simpler just to check if the package is available from source or not
is this what you don't know how to do?15:13
<fcb>yes, the second options sounds good as I would like to avoid a second pass - how can I tell if a package has available source code?
<bonniot>checking...15:14
let pkg = compilation.packages.get(name);15:15
let res = pkg != null && pkg.compiling;15:16
res is what you want, for the package called 'name"
<fcb>right15:18
so if res is true i have the source, if false I don't have it
<bonniot>yes15:19
<arjanb>does nicedoc use -R by default?15:20
<fcb>excellent - that is enough to get me going. super!
<bonniot>arjanb: yes15:21
<fcb>-R?
<bonniot>always load the source, even when a compiled version is also available
fcb: great15:22
<fcb>aha
* arjanb confused15:28
void foo(String[?]) { println("string[?]"); }15:29
void foo(List<String>) { println("List<String>"); }
String[] x = ["abc", "xzy"];
foo(x);
gives:
Ambiguity for symbol foo. Possibilities are :
nice.lang.void foo(nice.lang.List<String>)
nice.lang.void foo(?nice.lang.Array<String>)
<bonniot>yes, that's normal, they are incomparable
the first one is "more precise" because it does not allow null, and the second is "more precise" because Array is more precise than List15:31
<arjanb>i understand but my intuition finds the the type more important than the nullness15:33
well i guess such cases are rare15:39
<CIA-10>03arjanb * 10Nice/src/nice/tools/code/ (Import.java Types.java): Made default retypings of array elements not null, cleanup of related code.15:41
<fcb>I'm going to bed now but thanks for the help - I've got some stuff to do now! see you everyone.15:49
* fcb leaves
* cm__ leaves16:48
* lucp joins17:11
<arjanb>hi17:12
<lucp>good morning... i tried to make a modification to the parser, however i got many LookAheadSuccess errors.17:14
<arjanb>:(17:15
what do want to change?17:16
<lucp>according to the javacc website, it is a bug in 3.2 and it can be fixed by changing ERROR_REPORTING to false
for class definitions, public or private should be after the constraint, not before.17:17
<bonniot>hi luc17:24
<lucp>hi daniel.
<bonniot>is this standard in other languages (like C++)
<lucp>well the compiler accepts: <T> class foo<T>, class foo<T>, public class foo<T> but does not accept <T> public class foo<T>.. in fact this is where it expects the other modifiers (abstract, final)17:26
<bonniot>it accepts 'public <T> abstract class ...' ?17:29
<lucp>yes
<bonniot>i agreee that's weird17:31
they keywords should probably be all together17:32
how is it in C++? <> first, right?
<lucp>yes.17:34
<bonniot>OK, so i think the change is a good idea17:41
<lucp>how well does nicedoc work at the moment?17:44
<bonniot>it basically works. frank is working on improving the links at the moment (you just missed him; different TZ...)17:49
<lucp>what is your opinion on changing ClassDefinition to TypeDefinition and having 2 subclasses ClassDefinition and InterfaceDefinition?17:53
<bonniot>good idea. would that be done at the same time as converting to nice?17:54
<lucp>i'm working on it now :)17:55
the code is converted to nice.. i just need to rearrange the names
<bonniot>isn't the bootstrap posing problems?17:57
<cm_>What is this Nice-thing people talk about? Is it an emerging and future-proof technology?
<arjanb>i have unknowntype typeparams for retyping working except in combination with polymorpic type inference..17:58
<lucp>bonniot: a few.17:59
<arjanb>cm_: ???
let testmap = new HashMap();18:00
let set = testmap.keySet();
<cm_>arjanb: Irony :-)
<arjanb>here it takes the with unknowntype version of keySet() from AbstractMap instead of the retyped one from the Map interface18:01
<bonniot>isn't unknown types only for non-retyped methods?18:02
<cm_>bonniot: I'm browsing the javac/eclipse integration code. Huge amount of code would be an understatement.
<arjanb>daniel: yes
<bonniot>cm_: :-/18:03
by the way, everybody interested in welcome to join the nice-eclipse mailing list
<cm_>bonniot: But probably only a fraction in nice
<bonniot>arjanb: so isn't that the problem? indepently of polymorphic TI18:04
<cm_>bonniot: It is rather well organised at a first glance though
<arjanb>daniel: why doesn't nicec understand the one in AbstractMap implements the one in Map
<bonniot>arjanb: why do you think it doesn't?18:05
<arjanb>because it doesn't take the retyped version from Map18:06
<bonniot>even without your patch? what is the testcase?18:08
<arjanb>without my patch the method in AbstractMap is ignored18:09
<bonniot>so isn't it your patch that introduces the problem?18:10
<arjanb>no the only thing i changed is that when a method has parametric types it's given a default retyping with unknowntype instead of ignoring18:12
*away for meal18:13
<cm_>bonniot: Is it possible to locate source code corresponding to an AST-node18:16
<bonniot>yes, the locations are kept18:17
arjanb: i don't understand, you said "without my patch the method in AbstractMap is ignored"
<lucp>bonniot: nicec would say 'keySet is not declared'18:18
<cm_>great, jdt has a dom type of model as well. A more of a textual model of a program - perhaps unnecessary
<bonniot>lucp: would?
<lucp>yes, it does the same for fields too.18:19
cm: the jdt is a monster.. keep in mind it was written by IBM and not sun.18:20
<bonniot>lucp: ok.18:21
<cm_>lucp: True. The only relaible source of information how to write plug-ins for eclipse is the source code though... I had to index the beast to get a change to locate interesting code.18:22
<lucp>cm: i had scanned through jdt to see if any of it could be reused for nice... i dont know if it would be possible in most cases.18:23
<bonniot>arjanb: the place where non-base methods are ignored is JavaClassses.java:41718:24
luc and cm: did you subscribe to nice-eclipse?
<cm_>lucp: Not directly perhaps but some of the API design could be reused
bonniot: Yes, sure18:25
<lucp>i will today
<cm_>A great eclipse plug-in could differentiate nice from other jvm based languages.18:26
At least in theory ;-)18:27
As not all people choose language based on its features...
<lucp>i do find it strange that they call eclipse 'an extensible IDE for anything and nothing in particular' however only a java IDE is provided by default.18:28
<cm_>bonniot: Any new ideas regarding importing single java classes?18:34
<bonniot>no, I did not get back to that18:35
i suppose it could be done by checking if the name imported is a class or not18:36
<cm_>Could it be ambigious
<lucp>i believe i can fix that problem.. might require a new class loader though.18:37
<bonniot>cm_: no, you can suppose classes and packages have different names18:38
<cm_>ok
<bonniot>lucp: what's your idea?18:39
<lucp>create a class loader like the URLClassLoader which can be queried to check and identify resources instead of relying on a ClassNotFound failure.18:41
<bonniot>you mean with a method boolean exists(String className) ?18:42
<lucp>well, preferably the return type would be one of file, folder, or does not exist.
<bonniot>what about jars?18:43
what is the motivation?18:44
<lucp>well i originally thought about this because imports with a .* are not even checked to see if they are valid.
away for a while.. i have some errands to run.18:48
<arjanb>*back18:59
* cm_ leaves19:00
* cm_ joins19:03
<arjanb>i can't find the problem19:25
debug.overloading shows:19:33
Overloading resolution for
[nice.lang.int size(java.io.ByteArrayOutputStream)
|nice.lang.int size(java.util.HashMap<?, ?>) = native java.util.HashMap.size;
|<K, V> nice.lang.int size(nice.lang.Map<K, V>)
there's something strange with HashMap20:07
these unknowntyped methods get added somehow but not in JavaClasses.fetch20:08
daniel do you have any idea?20:11
<lucp>i'm back20:17
how do i run the testsuite with assertions enabled?20:20
<arjanb>change the makefile and look at the check and check-lib targets20:35
settting ERROR_REPORTING to false solves the javacc bug but it makes parse errors a lot less useful20:55
<lucp>i know :(20:56
i hope javacc 3.3 arrives soon with that bug fixed
<arjanb>or we could use an older version20:59
<lucp>yes, 3.2 is only needed if you want to use java 1.5 code.21:01
<bonniot>lucp: which assertions? assertions in the testcases are always on21:02
arjanb: i'm not following, you did not mention 'size' before
<lucp>the output of javacc before 3.2 cannot be used on java 1.5 at all.21:03
<arjanb>size is just another example where a hashmap method show up and shouldn't
<bonniot>nice.lang.int size(java.util.HashMap<?, ?>) = native java.util.HashMap.size21:04
it looks like a retyping
<arjanb>it's a default retyping21:05
<bonniot>ok
your code is executed for it, since there are ?s, so you should be able to trace where it is called from
i updated to the latest CVS version, and it does not compile:21:07
~/projets/Nice-CVS/src/bossa/syntax/symbol.nice: line 175, column 9:
This function may be null
what's up?
<arjanb>strange21:09
<lucp>i remember that
declaration.type is private needs to be made package visible.. the patch should have corrected it21:10
<bonniot>which patch?21:11
<lucp>PolySymbol and subclasses converted to nice.
<bonniot>that's what I cannot compile
<lucp>MethodDeclaration.java line 106 should be have the private modifier removed.. on the other hand, that error message needs improvement.21:13
<bonniot>can you make a short testcase for that situation?21:14
<arjanb>the change to line 106 is in the patch and in cvs afaics21:15
<lucp>yes, but it cannot be placed in the testsuite because it requires java and nice code.
<bonniot>that's possible, in the regtest suite21:16
otoh if it's just a wrong error message that's not for automatic testing at this point21:17
unless the error location is wrong
i guess with a full bootstrap it will fly21:19
i think i have the bug about anon funs in cust constructors fixed, i'll see with the full tests21:21
<arjanb>:-)21:23
maybe we should do a bugfix release soon, it has been 2 months since 0.9.921:24
<bonniot>right21:44
arjanb: did you try to trace when the methods get added?22:15
<arjanb>not yet22:17
<CIA-10>03arjanb * 10Nice/src/bossa/syntax/dispatch.java.bootstrap: Removed superfluous methods from dispatch.java.bootstrap.22:25
03bonniot * 10Nice/ (2 files in 2 dirs): Do not copy the closure environment in constructors (fixes bug #1070579).22:37
<arjanb>all stacktrace seem to go through either JavaClasses.fetch( or JavaFieldAccess.make(22:56
<bonniot>you saw my message about where non-base methods are skipped?22:59
<arjanb>yes that check looks correct to me23:00
in the other path it's a fieldaccess..23:06
ofcourse that's the problem it's confusing methods with fields with the same name
and fields have priority in overloadsymbolexp so it choosing the wrong one23:08
<lucp>arjanb: is the class B extends A<String> suppose to fail or was it fixed?23:13
<arjanb>which testcase?23:14
<lucp>specialization.testsuite
<arjanb>it should pass23:15
was you ClassDefinition.java up to date before you started conversion?23:16
lowlevelMonotype() should contain a try catch now23:17
<lucp>i'll compare with what is on cvs. thanks.23:18
<arjanb>so my code with unknowntype is correct but we need handling of java fields and nullary methods with the same name..23:20
personally i wouldn't mind reintroducing the distinction between .foo and .foo()23:22
maybe someone has a less invasive solution..23:35
<bonniot>there are fields with name 'size' and 'keySet' ?23:58
<arjanb>size en entrySet yes23:59
at least in Sun's version of HashMap..00:00
right keySet too00:04
added workaround for the testcases00:09
<lucp>away for a while00:20
<CIA-10>03arjanb * 10Nice/ (3 files in 3 dirs): Java methods/fields with parametric types get type parameters with UnknownType instead of being ignored.00:21
<arjanb>i would like another string representation of unknowntype though00:28
maybe '???' or just 'unknown'00:31
<bonniot>why?01:27
<arjanb>because '?' is confusing with nullness01:33
<bonniot>ok, i'll think about it02:07
<lucp>arjanb: sent you mail.02:24
<arjanb>ah another patch :)02:25
hmm rather big..02:34
<lucp>yes... and lots of work too!02:35
<arjanb>daniel what do think of reviewing this patch for cvs access?02:38
<bonniot>have you checked it already?02:44
<arjanb>not applied but read through..02:45
<bonniot>ok02:46
<arjanb>i think it's useful to have someone else comment on the patch and i can't apply the patch automaticly..02:49
luc: shall i forward or ..02:51
<lucp>yes please.02:55
<arjanb>done02:58
<cm_>bonniot: Is the eclipse dev. aware of the new mailing list? Martin was his name?03:03
<bonniot>arjanb: the mail body looks funny, but the patch file looks OK. I'll try to look at it tomorrow
cm_: yes, I emailed him about it
see you tomorrow03:04
* bonniot leaves
<arjanb>email client didn't cooperate :/03:07
<lucp>they rarely do
did you see my comments for the rfe about import leaks?03:10
<arjanb>now yes (rfe updates doesn't get mailed it seems..)03:13