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

Using timezone: Central European Time
<magnus-->I just got a bad cross-dependency between java and nice00:42
my .java file needs classes defined in the .nice file, and vice verse00:43
it's possible to handle that, but it would be simpler to avoid the circular dependency
can't you get rid of the java file? :-)
<magnus-->antlr makes .java:)00:53
and i create an AST using classes defined in .nice
Hmm, I think it can be avoided if I have the main program written in java00:56
and make the .nice code independent
<bonniot>what does the java code look like? would it be legal Nice code by any chance?01:06
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): 01:30
Fixed code generation bug for the version of the constructor omitting
optional parameters in the presence of subclassing.
<magnus-->I don't know if it's valid nice code01:56
<CIA-3>03bonniot * 10Nice/src/nice/tools/code/Import.java: Minor: formatting.01:57
<magnus-->I don't see any type casts in the code01:58
lots of switch/case
<bonniot>nay, no switch in Nice02:07
* arjanb joins
<bonniot>hello arjan
magnus--: seems like you should break the cycle. why does the Nice code call the generated Java?02:08
<magnus-->I have broken the cycle now02:11
<magnus-->Can Java programs create Nice objects?02:12
um yes i suppoes.02:13
<bonniot>the default constructor has all fields declared in the order of declaration
you can also define custom constructors (with the development version)02:21
<magnus-->if some feilds have default values, are they part of the constructor arguments?02:26
<bonniot>there are two versions02:27
one with only required fields
the other will all of them
<magnus-->class Program {02:50
Vector<ClassDecl> classDecls = new Vector<ClassDecl>();
the <ClassDecl> is unexpeced
<bonniot>just leave it out02:52
<arjanb>no type parameters at object creation
<bonniot>the compiler is clever enough to figure that out
why should you need to write the type twice? :-)02:55
nice again
good night!03:00
* magnus-- leaves03:01
<arjanb>good night03:51
<CIA-3>03bonniot * 10Nice/src/nice/tools/ (6 files in 4 dirs): Make the nicec ant task report messages through the ant framework.
* arjanb leaves
* bonniot leaves04:01
* bonniot joins10:32
<CIA-3>03bonniot * 10Nice/src/nice/tools/ant/NiceDoc.java: Report messages using the Ant framework.11:28
03bonniot * 10Nice/web/compilation.xml: Added note about the behaviour of 'java -jar' and fixed typo.
03bonniot * 10Nice/web/install.xml: Fixed location of the emacs mode.11:30
* arjanb joins13:07
Type parameters are not needed in constructor calls
that should be one less FAQ :-)
especially as this is possible/needed in Java 1.5, right?
<arjanb>it's needed in both java 1.5 and C# generics13:30
<bonniot>in all cases?13:31
<arjanb>for constructors yes
<arjanb>C# doesn't use erasure and for java they probably want to keep the possibilities open13:34
and there things you can't do with instantiation but can do with erasure?13:38
<bonniot>it's not clear how you could omit type parameters in all cases with instantiation13:46
there is also a performance cost
i think it's java it's mostly for simplifying the typechecker13:48
i'm dubious that they would change the vm to support instantiation
<arjanb>type params at construction suggests instantiation, i have seen confusion about this many times on java forums14:02
it's about time to change the java vm
<bonniot>bof, assembler instructions have not significantly changed in the last 20-30 years, but you can still compile more and more powerful languages to them14:06
although it's true the jvm gives you less control to do low-level stuff
<CIA-3>03bonniot * 10Nice/src/bossa/parser/ (Parser.jj Loader.java): 14:09
Report a specific error message when type parameters are specified in a
constructor call.
03bonniot * 10Nice/src/gnu/expr/InitializeProc.java: Report verification errors in constructor implementations more nicely.14:11
<bonniot>how are you doing these days?
what are your projects?
<arjanb>i had some other things to do last days but i made a bytecode disassembler in between14:16
<bonniot>for java bytecode?14:17
with support for nice specific attributes but i'm a bit struggling with the formatting of the output14:19
<bonniot>ah, nice to be able to see the Nice attributes14:20
written in Nice I guess?
<bonniot>could you turn it into a library (taking options like a classpath, and printing in a PrintWriter, something like that)?14:22
with a small command line tool that calls the library
<arjanb>that's possible14:24
<CIA-3>03bonniot * 10Nice/regtest/regtest: Put the root directory in the classpath, which is useful for java tests.
<bonniot>one idea would be to make this tool "language neutral"14:26
for the moment it would recognize Nice-specific attributes, but we could encourage authors of other languages to add a part about displaying their own attributes14:27
so you could use one tool with any class file, and it would give meaningful results
it would also encourage some collaboration, so that attributes do not clash14:28
<arjanb>making it language neutral is not goal for me15:00
it's only a small tool15:01
<bonniot>yes, it's just an option15:04
it should be each language team's work to add their part if they wish
my idea is to make it available by CVS, and probably send a few mails to see if people are interested, then it's their business :-)15:05
<arjanb>hmmm then i would have to think about the design
it's only a hackerish bunch of code now meant to be helpfull with debugging nicec generated bytecode and a way to learn the bytecode format for me15:08
i have making a bytecode generation library in mind15:10
<bonniot>why not using bcel?
<arjanb>bcel is designed for bytecode modifiing15:17
<bonniot>not only15:18
The Byte Code Engineering Library is intended to give users a convenient possibility to analyze, create, and manipulate (binary) Java class files
you are analizing :-)15:19
<arjanb>disassembling is not analizing15:22
i think bcel is complex/bloated if you want generation only15:23
<bonniot>well, for diassembling, you need to read the info from the stream of bytes, and then print it. bcel yould do the first half for you, so you can focus on the specific part15:28
never tried bcel, so i don't know what it's like for code generation15:29
<arjanb>btw anything that needs to be done before release?15:41
* magnus-- joins15:53
<bonniot>magnus--: i guess your circularity was because all the code was in the same package, no?16:02
<magnus-->yes you could say so
I'm trying to access the nice classes from java now16:03
<bonniot>you should be able to write the main function in a Nice package a, main calls ant which has generated code in a package b, and inner Nice code is in a package c
c imports b import a
a imports b imports c
magnus--: any pb?
<magnus-->well, heh. yes16:04
<bonniot>arjanb: there are always things to do, but I we could release 0.9.6 now
<magnus-->MiniJavaParser.java:46: cannot resolve symbol
symbol : constructor Program ()
location: class compiler.Program
Program p = new Program();
Program is defined in compiler/ast.nice
MiniJavaParser.java contains import compiler.*16:05
<bonniot>maybe there is no no-arg constructor
what are the fields in Program?
<magnus-->there are similar errors for the member functions of Program also
class Program16:06
Vector<ClassDecl> classDecls;
void addClassDecl(ClassDecl c) {
<bonniot>so the default constructor expects a value for classDecls
(otherwise you would get NullPointerException!)
<magnus-->okay, but yesterday you said the compiler can figure that out automatically
<bonniot>you could give it an initializer
<magnus-->and it didn't need an initializer:)16:07
<bonniot>only if the field has a default value
<magnus-->what should the initializer look like?
<bonniot>the compiler cannot gues what value to put it! ;-)
Vector<ClassDecl> classDecls = new Vector();
<magnus-->aaah, so what you meant was that <ClassDecl> is unnecessary16:08
<bonniot>(btw, the new version of the compiler prints a nicely polished error message if you try to pass type parameters to a constructor call now :-)
<magnus-->not the whole = new etc etc
the new compiler would tell you so, pointing at the opening < character
about member methods:16:09
<magnus-->alright, the constructor works now:)
only members left now
<bonniot>they are not compiled as Java member methods
you can use16:10
and pass "this" as the first argument
<magnus-->I see
<bonniot>it's the biggest annoyance when you call Nice from Java
that will probably be fixed sometime16:11
<magnus-->yay, works:)16:12
thanks again
the new error message is:16:15
Type parameters are not needed in constructor calls
is that clear?
<magnus-->yes I think so
<bonniot>you helped make the language more firendly, then ;-)
<Bluelive>sounds more like a warnng then an error16:16
<magnus-->what if A<B> inherits A<C> or something like that?
and you want A<B> = new A<C>();16:17
<bonniot>magnus--: that works16:19
the compiler is clever enough, don't worry :-)
just say A<B> x = new A();16:20
and A<C> x = new A();
<arjanb>type params do exist only at compile time
<bonniot>new A() is polymorphic
<magnus-->A<B> <= A<C>
A<B> = new A<C>();16:21
<bonniot>arjanb: yes, but it's still non-trivail to type-check new A()
<magnus-->A<B> = new A<B>();
<bonniot>like arjan says, A<B> and A<C> are the same at runtime16:22
<magnus-->there are two possible choices (as long as A<B> can be a superclass of A<C>. Perhaps nice' type system prevents this?)
I see..
<bonniot>most classes are invariant, but you can also declare covariance and contra-variance
<magnus-->So they are not like template parameters
they are more limited than templates?16:23
<bonniot>well, it's only about type-checking, not macro expansion like templates
imo it's bogus to mix the two concepts16:24
<magnus-->mhh could be16:27
I like the way templates can lead to things like www.boost.org
but I have too little experience with other languages' way of doing something corresponding to really know what is the best way to acheive such a thing16:28
<bonniot>we also try to give lots of power for users to write libraries and not handle every thing in the core language16:29
<magnus-->that's good
<bonniot>but templates do so at a quite low level, loosing modular static type checking for instance
are you reading nice-info?16:30
<magnus-->is that a mailing list?
<magnus-->I haven't read it
<CIA-3>03bonniot * 10Nice/debian/control: Nice can move to the main section in Debian.16:32
<bonniot>well, for instance, you can define a method 'using' which is identical to the construct with that name in C#16:33
using(Reader r = ...) {
that's all user code
<CIA-3>03bonniot * 10Nice/debian/changelog: Version 0.9.6, in main.16:35
that indeed looks like you can go a far way extending the language yourself
<bonniot>one plan is to set up a site (packages.sf.net) so that a set of libraries can be developed fairly independently from the core language16:41
will be much more reactive than bundling libraries with the core, like Sun does16:42
<arjanb>daniel: any idea how serious this bug report is: http://sourceforge.net/tracker/index.php?func=detail&aid=892041&group_id=12788&atid=112788
<bonniot>cannot connect16:43
which one is it?16:44
<arjanb>compiler crash with some kind of class constraint16:45
<bonniot>serious in how difficult it is to fix, or how important/urgent it is to fix? ;-)16:48
<arjanb>i have no idea how often this one could be triggered16:49
<bonniot>i did not investigate it yet16:56
seems pretty specific
but yes, we should educate our users to report when a bug is a blocker or not, but setting a priority other than the default 516:57
<CIA-3>03bonniot * 10Nice/distrib/Makefile: Fixed generation of the nice mode files in the tar distribution.17:17
03bonniot * 10Nice/web/research.xml: Link to a PDF version of the article on kinds instead of PS.17:18
03bonniot * 10Nice/NEWS: Dated for 0.9.617:59
<magnus-->Exception in thread "main" java.lang.NoClassDefFoundError: gnu/mapping/WrongType
at compiler.dispatch.addClassDecl(~/smd163/project/compiler/./compiler)18:00
<bonniot>you are missing the runtime18:01
did you put the jar in your classpath?
arjanb: could you write a niceunit.bat?18:02
<magnus-->I stopped using the .jar since there were .class files already
i guess that was a bad idea
<bonniot>nicec adds some classes that are needed at runtime
probably someday it will write exerything in a jar, nothing in directories ;-)18:03
at the moment the classes are used to avoid recompiling a package that is up to date
<magnus-->yes, works now18:05
<arjanb>will make that18:08
<CIA-3>03arjanb * 10Nice/bin/niceunit.bat: niceunit.bat18:34
03bonniot * 10Nice/debian/rules: Build with the Ant jar file from package libant1.5-java18:44
* bonniot is away: for the evening18:56
* CIA-3 leaves20:22
* CIA-3 joins20:23
* CIA-3 leaves20:25
* CIA-3 joins
* CIA-3 leaves20:31
* CIA-3 joins
* CIA-3 leaves20:40
* CIA-2 joins20:41
* magnus-- leaves21:53
* magnus-- joins21:55

Generated by Sualtam