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

Using timezone: Central European Time
* bonniot joins10:42
* arjanb joins11:27
the other override bug is not easy to fix because patterns of overrides depends on the overriden domain13:05
<bonniot>can you explain?
<arjanb>void foo(?int x) {} void foo(int x) {} here is a notNull pattern needed13:07
<bonniot>yes...
<arjanb>void bar(Object a, int x) {} void bar(String a, int x) {} using a notNull pattern in this case break things13:08
second methods are overrides
<bonniot>why does it break?
<arjanb>i don't know yet13:10
<bonniot>isn't it that the comparison of NotNull and int is incorrect?13:11
<arjanb>i don't think that part is used when finding the implementation of methods13:14
<bonniot>correct, but isn't the bug about coverage test?13:15
<arjanb>the error message is from coverage test:
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)
but this error can only happen if sortedAlternatives.size()==013:16
<bonniot>ok, so it must be a bug about when a pattern matches a certain type
does NotNull matches int?13:17
<arjanb>yes13:18
hmm reading a NotNull pattern from bytecode was never implemented13:37
<bonniot>can you commit a testcase for that?13:43
<arjanb>this one is triggered by superfluous NotNull patterns i generate now13:46
any idea for a testcase that doesn't depend on that?13:48
<bonniot>no. it's possible that NotNull is never written at the moment, so there is no bug14:01
* cm_ joins14:42
hello
<arjanb>hello
<bonniot>hi14:49
<CIA-3>03arjanb * 10Nice/ (3 files in 2 dirs): Fixed bug in creating patterns for method overrides.14:56
<bonniot>sowhat was it after all?14:57
<arjanb>missing notnull pattern reading and 2 if statements in the wrong order14:58
<bonniot>is the new TODO important? an optimization?15:09
otherwise the patch looks good
<cm_>Regarding the package repository proposal. Is the file nice.versions included in package A using package B, ie the package name and version of B is included in nice.versions in A.15:10
<arjanb>it causes every override with primitives to generate dispatch code like if (new Integer(x) != null)15:11
<bonniot>arjanb: ouch15:23
arjanb: what about changing the code generation to do nothing in this case?15:24
cm_: if I understand your question correctly, yes15:25
cm_: what do you have in mind?15:26
<arjanb>changing the code generation is tricky because it depends on whether autoboxing happens15:28
<cm_>bonniot: Ok, I was thinking about "linking" in Java. I think the classpath variable type of linking is not a good idea as no specific package name file is referred, compare to ld-linking. Anyway, if that information is included in nice.versions could linking be based on eg filenames or some other naming scheme instead of, a priori, having to set up your classpath. Crystal clear?15:29
I guess that the package rep. is working similar but it would be great as a general linking method - not just for downloaded and cached files. The ext-mechanism in Java is ok even if I would prefer explicit linking.15:32
<bonniot>use the package cache for running too, not just for compiling, is that the idea?15:36
i'm wondering if the best model for distributing an app is not to do "static linking", ie put everything in one jar15:38
<cm_>Yes, a better linking method. The process of having to set up classpath could be very tedious. There is a mechanism to include .jar depencencies in the MANIFEST-file. But this only works for applicaions started with "java -jar myapp.jar".
<bonniot>what do you think about that?15:42
<cm_>bonniot: Example: Starting program with the required foo.jar excluded would refer in a ClassNotFound exception. The problem is that foo.jar can include classes named with no similarity to the .jar filename then it is hard to know which .jar to include.15:43
bonniot: "Static" linking is a great option even if not generally applicable.15:44
<bonniot>why not?
<cm_>refer -> result
For the same reason why dynamic link libraries was introduced in Unix I guess15:46
<bonniot>that would need to be investigated
i see two reasons: saving space and allowing to upgrade the lib without upgrading the app15:47
the first one is very weak with current storage
upgradability is useful, but then it can only work in certain cases (if you don't break the api)15:48
and that causes lots of problems
if the api is not broken, you could simply recompile anyway and it will work15:49
which can be automated (and will be in the repository)15:50
any other reasons for dynamic linking?
<cm_>Scaleability I guess. My suggestion is that it would be nice to have a linking scheme as for binary files. .NET has a similar mechanism15:53
<bonniot>it's an option15:54
but I would like to see precisely how that would not scale
when you ship, in any case you can't assume much libs to be installed, especially at a standard place, can you?15:55
so you'll end up distributing several jars
<cm_>Independent release cycle. A static scheme could trigger upgrading a lot of packages. Example: Imaging a web-browser component embedded in applications from company X. X discover a security problem in their component and distribute it to their customers. In the static case would every program using X has to be recompiled and redistributed.15:56
<bonniot>but currently, is there any way Java apps use shared libraries?15:57
if a lib you use issues a security fix release, then you should be able to produce a minor release of your own product automatically15:58
<cm_>bonniot: Yes thats the case today. But you could apply the static linking scheme for every app. Should xedit be statically linked with glibc and X11?
<bonniot>no, i agree with that15:59
these are very basic components. in the same way, the JRE is also shared among java apps16:00
<cm_>The problem for the Java case is market share. If jar-files would be included in major distributions and used then you would have a similar problem as for the .so case.
<bonniot>yes
<cm_>And nice is going to conqueror the world so .. ;-)16:01
<bonniot>true. good we still have a few month to think it over before that ;-)
<cm_>The problem is in fact related to Java and not to nice.16:02
<bonniot>yes, I would think so too
we could still design a specific solution for Nice packages if it turned out to be necessary, but I think it's not urgent16:03
it will be interesting to start to get experience with the repository
<cm_>Yes, have you thought of strong names?16:04
<bonniot>?
<cm_>The def: A strong name is made up of information used to identify an assembly and includes the assembly's text name, four-part version number, culture information (if provided), a public key, and a digital signature stored in the assembly's manifest that contains the assembly's metadata and is embedded in one of the files of the assembly.16:06
<arjanb>daniel: 2 other problems with overrides, it's not checked whether the pattern of override are dispatchable and it's not consistent with method implementations16:08
void bar(?int x) {}
override void bar(int x) {} // valid
void foo(?int x) {}
foo(int x) {} // but this is not atm
<bonniot>cm_: yes, such things should be provided in the jar manifest. i think signatures are already standard16:09
arjanb: do you have testcases where this causes a bug?16:10
<arjanb><T> boolean bar(T x) = true;16:20
override boolean bar(int x) = false;
long a = 3;
assert bar(a);
<bonniot>that doesn't pass?16:22
<arjanb>indeed
it fails at the assert but it should give an error at the override16:23
<bonniot>i don't know. the override makes it possible to call bar on expressions of static type int, in which case I guess it works well16:24
<arjanb>it should be a normal overload in that case16:26
<bonniot>strange, I have a link error on your case, although I just recompiled with the latest version16:30
isn't there already code that does not take primitives into account when looking for overrides?16:32
<arjanb>i don't know you wrote that part16:33
what's the error you get?
<bonniot>(recompiling...)16:36
[nicec] The implementation test failed for method <T> nice.lang.boolean bar(T x):
[nicec] ambiguity for parameters of type (nice.lang.void)
that's with cvs head as far as i know16:37
are you working inside a cvs checkout?16:38
* bonniot is away: ...16:54
<arjanb>that's odd i just compiled again from cvs and i don't get that error17:02
* bonniot is back (gone 00:17:49)17:12
// PASS
long a = 3;
assert bar(a);
/// Toplevel
<T> boolean bar(T x) = true;
override boolean bar(int x) = false;
on this case?
<arjanb>yes17:19
is the dev jar up to date?17:23
with the development version i get assertionfailed17:26
<bonniot>you can do --version to find out17:27
<arjanb>Nice compiler version 0.9.9 (build 2004.09.15, 14:29:03 UTC)
<bonniot>sorry, my mistake, i was putting a previous version on the classpath17:46
<cm_>Is the cvs currently unstable? 17:50
<bonniot>no, it should be fine
<cm_>ok17:53
Are you hunting bugs for the 0.9.9 release?
<bonniot>yes :-)17:54
<arjanb>they always turn up just before you want to do a release
<bonniot>by murphy's law ;-)17:55
<cm_>Exactly :-)17:57
"A working program is one that has only unobserved bugs"18:01
<arjanb>for overrides there is check for things that aren't dispatchable because they only differ in type params but i can't find a check for primitives18:02
<bonniot>there must be one though because the following is detected:18:08
boolean bar(long x) = true;18:09
override boolean bar(int x) = false;
but in the long term, it might be that for methods with polymorphic types (<T>) where we need to wrap anyway, we could implement proper dispatch based on the minimal type of the value (does it fit in an int or not?)18:11
<arjanb>this one shouldn't delay 0.9.9 because it only seem to happen with a primitive overriding a polymorpic type18:14
<cm_>Is the ambiguity bug related to using functions as arguments going to be fixed for 0.9.9. eg app(println,...)18:16
<bonniot>agreed, and it's not a regression
cm_: not likely. bryn said he would look at it
arjanb: i'm worried about if (new Integer(x) != null) though. it what cases is it generated?18:17
<cm_>bonniot: Is this only related to cases similiar to the one mentioned? I guess it has to do type inference. No other implications?18:18
<bonniot>cm_: what Bryn wants to do has to do with overloading resolution (there are several methods called println, the compiler must find out which one you mean)18:20
<arjanb>daniel: it's generated for all primitives in overrides18:25
<cm_>bonniot: So ordinary overloading resolution works by resolving top-to-down using the arguments? Are not there cases where resolution has to be done more general, ie. both top-down and buttom-up?
<bonniot>arjanb: which only happens when the parent is non-primitive, right?18:26
cm_: that's exactly the question at hand
<arjanb>no it happens too with a primitive parent
<bonniot>at the moment it's arguments first, and the proposal is to perform it globally18:27
arjanb: testcase? it seemed to me that this case was rejected by the compiler
<arjanb><T> boolean bar(Object a, int x) = true;
override boolean bar(String a, int x) = false;
<bonniot>arjanb: OK. it's bad, then18:28
<cm_>bonniot: Isn't it possible to describe dependencies in a graph - globally? My guess is that ml-compilers works like that. Some expressions results in ambiguity when expressed interactively but are resolved when compiled and used in a context.18:32
<bonniot>ML does not have overloading. Well, at least OCaml doesn't18:34
but yes, Haskell behaves somewhat like that too
i remember some ML have overloaded numeric operations, right?18:35
<cm_>Overloaded numberic operators is a hack
<bonniot>yes
<cm_>No but I was referring to type inference. Sometimes you have to define the exact type to avoid ambiguity
Like f : Int -> Int.
<bonniot>but if you use f in a context where only int->int is expected, then you don't need to18:36
that's the idea :-)
<cm_>But this ambiguity is sometimes resovled when the unit is compiled, ie usage patterns are used for the inference
<bonniot>well, that's the context thing, isn't it?18:37
<cm_>The f example was stupied :)
guess so. My gutt feeling is that you would have to describe it in a graph and traverse... 18:38
But on the other hand I am only a computer scientist amateur :-)18:39
<bonniot>overloading resolution is different from type inference, because in the first you need only to pick out of a finite number of combinations18:40
of course they interract
<cm_>Yes, true. For generic methods? 18:44
<bonniot>when you try do to inference and you use an overloaded symbol, there will naturally be an ambiguity, that's when you need to annotations18:45
<cm_>What are annotations in this context?18:47
<bonniot>declaring explicitely the type of a local variable18:48
<cm_>ok
I guess it simplyfies things that methods always are annotated - at least the definition of it.18:53
<bonniot>it's needed for other reasons, but yes that helps
<cm_>What about this: <T> void printList(List<T> l) = app(println,l). Then which overloaded println to use could not be inferred using the definition. It is dependent of the usage.18:55
<bonniot>yes. but the method declaration helps because you know the type of l18:57
<cm_>Yes but you still have to compile specific versions of printList dependent of the usage I guess.
<bonniot>no, only one version18:58
(unless you want to avoid wrapping for primitives, but that's a different question)
<cm_>So you would always use the void println(Object) then?18:59
That works due that String toString() is overloaded but what about other cases19:00
<bonniot>if there is a more specialized version it will be called, but that's done by dispatch at runtime (as usual in OO)
for the code to be type-correct, it must work in the general case, so there is no problem19:01
<cm_>Is nice using all the argumnet for dispatching? Java doesn't. The specific method is always resolved at compile time.19:02
<bonniot>yes, nice uses all the arguments
that's one of the main features!
that's what Multi-methods do19:03
<cm_>Yeah - I thought so too ;-) I'm just a bit confused
I haven't used the features of multi-methods at all in fact. I have read the visitor pattern though - nice.19:05
pattern example19:06
<bonniot>yep
<cm_>I guess that multi-methods are local. Example: B adds a method to a class defined in A but this is only visible to B and doesn't change the semantics of the class in A.19:14
What happends if B is compiled against version 1.0 of A but at run-time is 1.1 used where another method was added to a class in A.19:16
That is more specific and should be used if B was compiled to 1.119:17
Hmm this might be true but you would have the same problem with Java.19:19
<bonniot>methods are global19:21
yes, it's like Java: there are certain things you can do without recompiling, but in general it's safer to recompile19:27
<cm_>Ok, so if you find out at compile time that there is only one candidate is no dispatching performed at run-time apart from on "self"19:29
<bonniot>there is this kind of optimization if you used 'override' statements but not for simple method implementations19:30
with override, you will probably not even dispatch on self because the JIT can optimize that out19:32
arjanb: about the simplification of the generate code: isn't it enough to check if the type on the top of the stack is a primitive type? if yes, you are sure it is not null19:35
<arjanb>i can try that19:39
<CIA-3>03bonniot * 10Nice/stdlib/nice/lang/ForInIters.nice: 19:44
Simplification of the type of forIterator:
<T | T <: int, int <: T> is useless, one can directly use int instead of T
in that case.
03arjanb * 10Nice/stdlib/nice/lang/inline/ReferenceOp.java: Optimization for codegeneration of NotNullPattern on primitives.20:14
<arjanb>other things todo before 0.9.9?20:25
<bonniot>i'm fixing something about bryn's new Range system21:03
but it's ready
<CIA-3>03bonniot * 10Nice/ (3 files in 2 dirs): Make sure that finite literal ranges have a static subtype of List.21:17
03bonniot * 10Nice/debian/control: Suggest gcj 3.422:39
<cm_>arjanb, bonniot: If I can be of any help by testing or something similar let me know22:45
<bonniot>thanks for the proposal22:53
i think you've been tracking cvs, which is always useful in case you find something that is not tested yet22:54
otherwise, since you are interested in the repository project, you could start a package to beta-test the system22:55
can you think of a library that you need and that would be of general interest?22:56
<cm_>Where in the cvs is the rep. system? Btw, is nicedoc testable? It would help browsing stdlib to find things that are missing and etc23:01
<bonniot>yes, nicedoc is testable23:02
the repository has it's own project on sourceforge
the idea is to make development there independent of the core compiler, so it helps to separate them clearly23:03
http://sourceforge.net/projects/packages
there will be web pages automatically generated for each package too23:04
something like:
http://packages.sourceforge.net/info/nice.swt/project-info.html
<cm_>Is there a make target for nicedoc in nice (for stdslib etc)23:08
<bonniot>there is a target to build nicedoc (make nicedoc)23:09
but not to build the docs ;-)
./bin/nicedoc --sourcepath stdlib --outdir docs nice.lang23:10
<cm_>Btw, compiling nice could be simplyfied by either including the nice.sf.net/nice.jar or by downloading it with wget (at least on linux)23:13
<bonniot>nice-bootstrap.jar is included in the source distribution (made for each release)
but I don't think it should be in CVS
i agree a script could get it if needed (it's done for javacc already)23:14
the thing is that if you have nicec in your path, it might work (and then it's better not to download anything more), or it might fails because it's not recent enough23:15
<cm_>Ok, first time I compiled nice was the included jar obsolete.
<bonniot>that would be surprising. are you sure it was not CVS that you were trying to compile?23:16
<cm_>Yes, the cvs
Minor issue however
<bonniot>then there is no included jar ;-)
<cm_>Aha, right, the released nice compiler was obsolete (or the libraries)23:17
<bonniot>yes, that happens
<cm_>Chicken and the egg ;-)
<bonniot>but you see my point? it's hard to automate it without downloading more than necessary
<cm_>Yes and it might hence be better to relase compiled snapshots now and then perhaps23:18
<bonniot>http://nice.sf.net/nice.jar is the snapshot23:19
<cm_>Ok, hmm I used it to compile the cvs. Not gaining much there23:20
<bonniot>you can be ahead by up to two hours ;-)23:24
<cm_>heh
<bonniot>and if there is at least one regression then nice.jar is not updated
but yes, using a recent nice.jar is usually being very close from development23:26
<cm_>Btw, you can't use the builtin jar command building nice. This results in an error where org.gnu.. is not found when retrying with the jdk jar in path. 23:27
<bonniot>unless you want to test a change we just commited ;-)
what builtin jar command?
<cm_>Due to that the jar is only a subset of the intended one
(-u is used)
From gcj23:28
Even though updating should be supported
I don't think that it matter, in principal, besides that the subsequent error message is hard to deduce23:30
It is if cource solved with a make clean23:31
Should I add something to CLASSPATH in order to run nicedoc?23:35
./bin/nicedoc --sourcepath stdlib --outdir docs nice.lang
Exception in thread "main" java.lang.NoSuchMethodError: bossa.modules.Compilation.generate(Ljava/lang/String;Ljava/io/File;)V
at nice.tools.doc.fun.main(main.nice:78)
at nice.tools.doc.dispatch.main(dispatch.nice)
<arjanb>this isn't a classpath problem23:38
<bonniot>ah, fastjar (from gcj) not implementing -u, it's a pain23:39
try 'make nicedoc archive'
nicedoc should be fine in the development version23:40
when you build by hand, it depends of the order of what you build. the fix would be to build nicedoc in its own jar23:41
<cm_>Thats why you have to issue "make nicedoc archive".23:42
<bonniot>yes23:45
does nicedoc work after that?
<cm_>Yep
<bonniot>ok
what target did you use before to build?
<cm_>No methods are listed when browsing a class though23:46
just make
The univeral one ;-)
<bonniot>:-)classes
normal, classes do not contain methods ;-)
frank is working on the grouping by source file, so the navigation should be easier soon23:47
<cm_>That could be more foreseeable
Why not group when by first argument?23:48
And by package
Ie, every method compiled to class X is in X23:49
<bonniot>yes. i think there should be several indexes
<cm_>And category grouping perhaps. You could introduce a new doc-keyword, eg @group ArrayAccess for all get(.) and set(.)23:53
<bonniot>hum, strange. why would you see all the array access methods?23:55
<cm_>True, just the generic one? They are all listed though23:56
I guess that there are other and better cases when grouping is applicable23:57
<bonniot>?
<cm_>In nicedoc:23:58
get: <T> (T[], nice.lang.int) -> T
get: (nice.lang.byte[], nice.lang.int) -> nice.lang.byte23:59
and so forth
In the resulting nicedoc
<bonniot>i don't understand00:00
<cm_>The resulting nicedoc htmlfile contains all get methods. I understand that they all are defined for performance reason but should you list them all?00:01
<bonniot>ah
well, nicedoc has no specific knownledge about certain methods. it just does it jobs dutifully ;-)00:02
<cm_>A grouping example: Arithmetic operators, comparsion operators, etc. For foreseeable reasons00:04
Ok, a hide keyword would perhaps?
s/would/''00:05
<bonniot>i think grouping is done naturally by placing related stuff in the same file00:07
<cm_>Very true
<bonniot>@hide, yes, that might be useful00:08
<cm_>And fairly simple to implement too ;-)00:09
<bonniot>i guess so. nicedoc is one of the few parts in the code I barely know at all00:10
<cm_>About some generic functions. Generic stream combinator functions perhaps? Like filter, app etc for streams
<bonniot>have you looked at nice.functional?00:11
<cm_>Yes but it was a while ago.
<bonniot>there are generators, with map, compose, filter, ...00:12
i think it's what you want00:13
a generator being a function ()->SomeType
<cm_>Ok, eg filter(() => myinputtream.read(), ...)
Very generic :)00:14
<bonniot>probably we should move nice.functional to the repository someday00:15
so back to nicedoc, if you want to get some idea remembered, you can submit a RFE with the 'nicedoc' category00:16
<cm_>Ok, I think that nice.functional should be an integral part of nice.00:17
<bonniot>where's the distinction?00:18
<cm_>I thought you meant moving it out?
<bonniot>to packages.sf.net, so it can be developed independently. that does not necessarily mean it's less of a part of nice than before00:19
but if a new feature is ready, why should it wait for the next release of the compiler?00:21
<cm_>Ahh ok. If it isn't shipped you could end up with 294 different incompatible libraries ;-) We don't want to repeat the c++ by not having a standard set of datastructures. 00:22
<bonniot>yes, it's a problem. but the centralized JDK with a release every second year is also bad, for different reasons00:23
with the packages.sf.net I think we can have a golden middle: independent release, but a central repository, where you can see what already exists, discuss naming, ...00:24
<cm_>True, as long as the libraries are shipped with the ndk. 00:26
Some of them at least
Those regarded as "core"
So "packages" is related to maeven?00:27
You could solve some dependencies issues by having compiled releases. Such as: Program X requires ndk 2.0 instead of ndk2.0 and nice.func. 1.242 and foo.bar 3.23...00:30
<bonniot>maven is just a tool that can be used to generate summary pages about the packages00:44
what do you mean? isn't this what nice.versions does?00:45
<cm_>Given that link static - yes00:46
Isn't maven more than that?00:47
From the web page:
The Big Picture:
The intent of Maven is to make intra-project development highly manageable in the hopes of providing more time for cross-project development. You might call it cross-project pollination or the sharing of project development knowledge, this is what Maven attempts to encourage.
I thought that you could use maven to, among others, build subproject automatically 00:50
With automatic download or check out
<bonniot>yes, maven has more than that00:53
but that's how I plan to use it on packages.sf.net
last time I tried, the dependency management was very lacking (not even recursive)00:54
so I dropped the idea on relying on maven for the whole repository idea
adding this feature to nicec was not hard
but there is a nice plugin for maven, still, if you like it00:55
<cm_>ok, I haven't used it so a have no preference. Jakarta projects tend also to be quite bloat00:56
<bonniot>yes, I had this impression00:58
<cm_>As the mozilla project that implemented a major infrastructure prior to their webbrowser. A huge undertaking but the result is impressive.01:01
A kernel and an office suite and you have a complete operating system distribution :-)01:02
<bonniot>well, you need GNU too... :-)01:03
<cm_>he01:04
<bonniot>good night01:19
<arjanb>good night
* arjanb leaves
<cm_>good night01:21
* cm_ leaves
* bonniot leaves01:27

Generated by Sualtam