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

Using timezone: Central European Time
<bonniot>arjanb: good thing done ;-)00:25
<CIA-3>03bonniot * 10Nice/src/bossa/syntax/niceMethod.nice: Don't compile methods into classes imported from a different package.00:28
<bonniot>arjanb: actually there were already two tests with packages in field-override.testsuite00:41
i'm sure your tests cover more situations
but that could be rearranged
what was completely missing was pure value override
and I don't see that in your tests either00:42
<arjanb>maybe i overlooked a few things00:48
* mpupu joins02:53
* mpupu leaves
<CIA-3>03bonniot * 10Nice/ (src/nice/tools/unit/console/main.nice NEWS): Added niceunit --jar10:27
* bonniot leaves11:11
* bonniot joins11:12
* ArtemGr joins13:21
<bonniot>how is it going?
<ArtemGr>better. thanks.13:34
<ArtemGr>i think i'll try, on sunday, to make niceMethod.nice generate package methods both in the class and in the dispatch class.13:36
<bonniot>what do you call package methods?13:37
<ArtemGr>sorry, on the contrary - non-package methods. currently they're put into dispatch, but it is ok to put them in classes too, while still using dispatch locally.13:38
<bonniot>what do you call non-package methods? ;-)13:39
<ArtemGr>methods skipped by "receiver.definition.module.pkg != def.module.pkg"13:40
<bonniot>i see
is this feature important for you at this point?13:41
<ArtemGr>for me - no13:42
<bonniot>then maybe this can wait until we have a clear global picture13:43
i don't think it's a feature relied on yet, since it's sort of too high tech ;-)13:45
<ArtemGr>what's with the clear global picture?13:46
<bonniot>i'm not sure yet if having such double location for dispatch methods is the ideal solution13:47
<ArtemGr>'woot' - what dos that mean?
i'll try to work on testcases then...13:52
<bonniot>i just wrote the basic framework for writing testcases in Nice itself, and it works!
woot is meant as an exclamation of joy, not sure if it's correct...
<ArtemGr>fine, i can test-drive it on sunday, then13:53
it's just about 70 lines of framework ;-)
<ArtemGr>in Nice?13:54
the testcase for the bug we found with jars looks like this:13:55
DSL/embedding is a very powerful idea. feels great to work on it. fun to see the compiler compiling the testcase, then niceunit running the test code, which calls the compiler ;-)13:58
<ArtemGr>fine. how about "package" instead of "pkg" and "import" instead of "imp"?14:01
will we have "#!/bin/nicec" Nice scripts? ; )
<bonniot>cannot use those names, they are keywords
let's be reasonable and settle for #! /usr/bin/nicec ;-)14:02
<ArtemGr>: )
<bonniot>i think this is an interesting distinction:14:11
with a hard-coded DSL like the current testengine, if you miss some feature, it's easy to think: ah, I cannot do that14:12
with a "soft" DSL like this one, you have complete control, so extending the framework is just adding or modifying a method. it's more immediate, so I think you'll more easily take that step14:13
<ArtemGr>ant if extending method is good, it is just moved to the engine14:14
<bonniot>(i wonder if there is a fixed terminology for this distinction)
the engine is just an imported library
it's a much more lightweight approach
ArtemGr: do you understand the regression test is failing on your machine?15:18
<ArtemGr>i thought it is somehow connected with RFE 1076945.15:19
or with the curent workaround i use by patching JDK.15:20
<bonniot>wrong rfe id...
<bonniot>ah, the encoding?
(my mistake)15:22
yes, that sounds quite possible
<ArtemGr>yes. it is the unicode character in the source which is failing. don't know wy, though, becouse my JDK uses UTF-8 by default.
<bonniot>but the source is ascii, not UTF-8, no?15:23
\ u ...
in any case, it would help to implement the feature ;-)
<ArtemGr>source code have a non-ascii character, which, i think, JDK doesn't understand becouse it expect UTF-815:25
<bonniot>ah ok
<ArtemGr>will be fixed by specifying correct encoding after RFE 1076945 is implemented.15:26
* fcb joins15:29
<bonniot>hi frank!
how's it going
<bonniot>great! and you?
<fcb>very well, thankyou
thanks for fixing that bug in bossa.syntax
<CIA-3>03bonniot * 10Nice/src/gnu/bytecode/Field.java: 15:31
Don't write ConstantValue attributes for the default value, since that's
<bonniot>ArtemGr: not sure if you met, frank is the nicedoc author
<ArtemGr>hi, frank15:32
<ArtemGr>do you think nicedoc is better then javadoc?
in it's presentation format, i mean15:33
<bonniot>(Artem, NiceTee author ;-)
(got to love those online introductions ;-))
<fcb>certainly not. it is far worse. my development is progressing very slowly because I work fulltime and have a 3 month old baby)
<ArtemGr>yeah, NiceTee is Nice templates (like JSP in it's basic form) used in CMS.15:34
is it possible to write javadoc plugin for Nice?
CMS? (woops)15:35
<ArtemGr>CMS - Content Management System
for web-sites
<fcb>ok, cool
um, javadoc plugin... what did you have in mind?15:36
<ArtemGr>that is, make javadoc do the presentation, while feeding it with Nice data.
<bonniot>i'm not sure if it's puggable in that way
the backend is (output format)
haven't heard about that for the front end, but that should be checked15:37
<ArtemGr>if javadoc backend is pluggable, perhaps take the default javadoc backend and feed Nice data into it?15:38
nicedoc will be compatible with doclets then?
<bonniot>doclets are the backend plugins, no?
yeah, that might be technically possible, but not sure if Sun's license allows it15:39
<ArtemGr>if javadoc backend is pluggable, perhaps there are free open-source doclets?
<bonniot>yes, that should be investigated15:40
there is an open source "javadoc", gjdoc
not sure how much it implements (doclets or not)
<ArtemGr>i use javadoc to generate documentation for my system, which i give to users. moving application to Nice have currently created black holes in documentation. and i want to document NiceTee templates automatically too. so i'm interesting to help with nicedoc if i can.15:42
it would be nice if nicedoc could generate documentation both for the Java and Nice, so that documentation is not split. how about it?15:43
<fcb>sounds good
<bonniot>one step further in integration ;-)15:44
gjdoc supports doclets15:45
generated by gjdoc
<ArtemGr>ok, i'll try to look further into GNU Classpath::Tools::Programs (where gjdoc is)15:48
<bonniot>i guess nicedoc could be the basis for a gjdoc frontend15:49
<fcb>presumably, this means that the current attempt at nicedoc is dead and buried?15:50
<ArtemGr>i think we should try if gjdoc default doclet can be plugged into the current nicedoc15:51
don't know about Java intergration, though
perhaps we can later merge information from nicedoc and gjdoc?15:52
this can be optional, working only when gjdoc is present.
nicedoc -> gjdoc doclet15:53
nicedoc + gjdoc -> gjdoc doclet
<fcb>I think I need to understand more about doclets before I comment
<ArtemGr>i too : )15:54
<bonniot>fcb: in all cases we need special treatment to call the nice compile to gather information about the nice source files
that part is already in nicedoc, and should be reusable
<ArtemGr>frank, do you read nice-devel?
i can write there if i have any news.
<fcb>I think I need to subscribe 15:57
rather poor that I'm not on there
<ArtemGr>i am subscribed, but have the actual email sending turned off. instead, i use gmane to read it.15:58
<fcb>anyway, now I'm subscribed15:59
that is a good form of communication for me because of the difference in timezone16:00
bonniot: Shall I pause work on nicedoc until the direction is decided?16:01
<bonniot>makes sense. hopefully we should have an idea soon16:04
i'm discussing with a gjdoc hacker on #classpath right now
<fcb>ok, I need to go now - good to talk to you all. I think it would be good if this gjdoc thing works - please keep me informed.16:05
come back soon! ;-)
<fcb>bye :)
* fcb leaves
<bonniot>seems the current implementation of gjdoc is not easily modularizable in the frontend16:12
<ArtemGr>i don't think it worth it to modify gjdoc.16:13
the doclets interface is stable, and we can probably implement doclet api in nicedoc and plugin gjdoc doclet into nicedoc.
then we can implement our own doclet, plug it into gjdoc, and use it to merge Java and Nice documentation together...16:14
<bonniot>gjdoc is only pluggable in the backend, without modifying it...
<ArtemGr>why we would need to modify it? for Nice documentation we use only it's backend.16:15
for Java documentation we use plain gjdoc with our own backend.
what would our java backend do?16:17
why not the standard one?
one thing to look at is whether the doclet api is righ enough
<ArtemGr>our java backend will be used to merge Java documentation into the Nice one.
there is alread --link, which might or might not be enough16:18
if doclet api, is rich enough, then all the best
otherwise, it means we need to extend it, but we can take the current implementations as a starting point
<ArtemGr>yes, we should definitely see the doclet api first. : )16:19
<bonniot>do you have any issue with moving towards compiling inside jars by default? say when no -d is given16:28
ArtemGr: you missed the discussion about gjdoc on #classpath: http://rafb.net/paste/results/CZDhD139.nln.html16:33
<ArtemGr>currently i put my application, consisting of several packages, into a single jar. i have already a package which imports all other packages used.
i am not sure, currently, whether nicec will put all used classes into the generated jar or only modified ones?
normally a generated jar should be self-contained
doesn't have Java generated parts for mixed projects, though16:35
<ArtemGr>should be no problem with that, as i have Java classes compiled into a different folder already.16:36
so, nicec put used classes from all Nice libraries into the jar, and all i need is that single jar?16:37
that's the current behaviour of -jar
<ArtemGr>ok, i have no problem with that. thanks for ascing. : )16:38
<bonniot>my change idea is that each package would be compiled to its own jar, with Class-Path entries for imported jars16:39
so there would not be a master jar with all the code anymore
we could provide an option for that ("static linking") if requested, of course16:40
<ArtemGr>no problem with that too. makes more sence, as i can rsync or gcj-compile libraries independently from the application.16:41
all jars should be put in the same dir16:44
. by default i guess
<ArtemGr>what about nice* classes, will you bundle them into jars as before?16:46
<bonniot>a question is: do we need --jar at all then? that would be the static linking option?
ah, good question
in the static link, surely16:47
what could be done is to generate one nice.lang.jar in ., like all other packages
since nice.lang is imported16:48
<ArtemGr>yes, i think "--jar" behaviour could remain the same for compatibility16:49
yes, it would be okay to generate nice.lang.jar if it isn't fresh already
<bonniot>but then, do we copy any package that's not in . ?16:50
or just those that come out of nice.jar ?
<ArtemGr>you mean, if some Nice package is on the classpath, then we copy it into destination directory and include into Manifest.mf class-path? the "-d" option could mean the directory with jars, then. okay.16:54
<bonniot>yes. seems somewhat wasteful to copy, though...16:55
<ArtemGr>the Manifest.mf class-path thingy could be optional. if it is on, then it makes sence to copy used packages near. it it is off, then user is responsible to construct classpath in the correct order...16:57
we can recommend the correct classpath order then
<bonniot>recommend how? println?
<ArtemGr>yes, print after the compilation. thus user will be always aware that classpath order is important.16:59
<bonniot>yes, if we copy it should surely be optional
actually it doesn't really hurt to write the Class-Path entry in any case, no?17:00
<ArtemGr>the user might have it's own manifest, he often will
<bonniot>yes, in which case he overwrites it anyway17:01
<ArtemGr>okay, then. there will be dangling references in the Class-Path (for packages that weren't copied)?17:02
<bonniot>yes, those are ignored
it's just another chance to see the proper order, even after compilation
and it might be that the user moves around the jars later in some custom way, and can use java -jar to run17:04
but this could be taken care of in a later step17:05
first, the change could simply be to used jars instead of dirs as a way to store compiled packages17:06
<ArtemGr>it will be easy to release specific libraries with static compilation, like17:53
nicec --jar socks.jar ru.glim.socks
<bonniot>that should already work17:54
<ArtemGr>(which will use at least ru.glim.string and ru.glim.util.digest)
a reason to keep it : )17:55
but then you have a problem if you want to use two libraries that import a third one, possibly a different version
that's what the package repository is designed for
will go. bye. : )18:02
* ArtemGr leaves
<bonniot>uh? testsuite/compiler/native/visibility.nice ??18:42
<arjanb>where does that come from?18:44
<bonniot>it's in the testsuite18:52
<CIA-3>03bonniot * 10Nice/testsuite/compiler/native/ (visibility.testsuite visibility.nice): Renamed visibility.nice (a mistake) into visibility.testsuite18:59
* ArtemGr joins20:03
I've checked the doclet API. Don't see any problems in implementing it, yet.20:05
* Bluelive joins20:10
<ArtemGr>wov, new Eclipse have a general "File association" configuration. i've discovered it only now.21:03
Java highlighting works fine with .nice files.
(Eclipse 3.1.0)21:04
<bonniot>implementing the doclet api?21:39
isn't it that we need to use it? and use an existing implementation?21:40
<ArtemGr>we need to provide it. doclet will use it.21:41
<bonniot>isn't a doclet a backend that produces output?
<ArtemGr>doclet api is an abstract view of packages classes and methods being docummented.
doclet takes it and produce the documentation from it.21:42
or, perhaps, http://java.sun.com/j2se/1.4.2/docs/tooldocs/javadoc/21:44
so, nicedoc need only to implement this API and run (standard) doclet on that implementation.21:49
<Bluelive>if you can fit it all inside the primitives a doclet context provides21:52
<bonniot>ok, i see21:53
is there another api for output? (HTML/XML/whatever)
<ArtemGr>no, the doclet IS the output. XML doclet, PDF doclet, etc.21:54
the doclet itself might have output api's. perhaps MIF doclet does.
* ArtemGr leaves22:34
* ArtemGr joins22:36
* ArtemGr leaves23:57
* Bluelive leaves00:57

Generated by Sualtam