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

Using timezone: Central European Time
* CIA-3 leaves01:06
* CIA-3 joins01:07
* arjanb leaves01:35
* magnus-- leaves03:09
* CIA-3 leaves07:52
* CIA-3 joins
* bonniot joins10:56
* arjanb joins12:25
<bonniot>hello arjan12:26
<arjanb>hi12:27
<bonniot>i'm looking at array issues atm12:28
<CIA-3>03bonniot * 10Nice/NEWS: Typo, and moved 'using' next to the new block syntax.12:40
<bonniot>any plans?12:41
<arjanb>not atm12:43
<bonniot>any time? ;-)12:45
allo?12:51
<arjanb>i will wait for 0.9.6 first12:53
<bonniot>it's always possible to work on a local copy12:55
releases should not stop normal development
btw, the nicec.bat you commited seems to have only \n for end of line. does that work at all under windows? I'd think not12:57
<arjanb>it doesn't seem to matter13:01
<bonniot>it might matter under older versions (win98?). which one did you try13:02
in any case, it would be safer
<arjanb>win2k13:03
<bonniot>the funny thing is that I would expect that since you work under windows, you would naturally create files with \r\n, no?
how come this happened?
<arjanb>hasn't been the cvs version always with /n only? 13:05
<bonniot>no. didn't you look at the diff?
(it seems cvsview ignore the end of lines, but the nice-commit mail shows the whole file changed, which is only because of EOLs)13:08
<arjanb>if i diff the cvs version with dos line ends then i get no diff13:09
<bonniot>with what tool?
<arjanb>cvs
maybe is the win version of cvs trying to be smart13:11
<bonniot>could be. here cvs diff shows the whole file has changed13:12
hum. CVS always stores text files with \n only in the repository13:17
so I suppose if you commit a \r\n file from windows, and I check it out on unix, it will have \n, which is what we see now
if _I_ commit a \r\n file from unix, then it will stay like that in the repository13:18
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): Fix conversion of long arrays inside arrays.13:23
<arjanb>the CIA gets the commit mail much faster13:40
<bonniot>than nice-commit?13:42
<arjanb>yes13:43
<bonniot>it's sent directly to them at the same time as the mail to nice-commit
and sf lists have some delay (how much?)
<arjanb>i thought the mailserver here was slow13:44
<bonniot>at your uni?13:45
<arjanb>yes
<bonniot>possible, because gmane has the message too, and it gets it from the list13:46
but if you subscribed with arjanb@sf, that could be the delay too
i didn't even get your commit of nicec.bat by email!13:47
<arjanb>me neither13:48
<CIA-3>03bonniot * 10Nice/testsuite/compiler/expressions/arrays/compilation.testsuite: More thorough testing of generic array to primitive array conversions.
<bonniot>i checked nicec.bat on win98 inside vmware, and it does not work because of EOL13:58
<arjanb>then have you to commit changes to nicec.bat14:02
<bonniot>done
i think we ran into this problem before14:03
there must be a way to make commits from windows work too
<CIA-3>03bonniot * 10Nice/bin/nicec.bat: Restore DOS-style end of lines, and the Emacs setup section.
<bonniot>one thing would be to set the file as binary, but then I think diff would not work anymore
the time taken to run the testsuite really slows me down...14:59
the wrong line numbers are also annoying17:00
<arjanb>I'm not sure how to continue17:48
<bonniot>continue what?18:02
<arjanb>the size and complexity of all the code is getting in the way for implementing ideas18:03
<bonniot>which part do you find especially complex? what ideas do you have in mind?18:05
<arjanb>too complex to change is the typesystem and the kawa libs part18:06
<bonniot>agreed18:07
<arjanb>and i still doesn't have bossa.syntax.* complete in my mind
<bonniot>the type system is theoretically complex, so that's not surprising
the code generation part could surely be simplified
but it's not obvious if the effort would be worth it18:08
<arjanb>maybe i'm better off doing a new implementation of nicec in paralel starting with bytecode gen and parser18:09
<bonniot>i don't think a new implementation is a good idea, because it would only bring benefits in a very long term18:12
on the other hand, rewriting and simplifying one part of the code can help a lot
have you read this?18:16
<arjanb>yes18:17
<bonniot>http://www.joelonsoftware.com/articles/fog0000000069.html
i meant that link :-)
<arjanb>i have read that some time ago too :-)
<bonniot>good :-)18:18
for features like I was mentioning before, do you think they are hard to do with the current implementation?18:20
<arjanb>typechecking of code needs quite a lot of change when you take assignments in account and doing constructs loops. closure correctly18:23
<bonniot>yes, that part could be reqritten to handle those situations18:24
the features I was refering to were the line numbers and package retyping rules
<arjanb>it was not in reaction to that18:25
<bonniot>ok, understood. but then you did not answer ;-)18:27
<arjanb>to what?18:30
<bonniot>for features like I was mentioning before, do you think they are hard to do with the current implementation?18:31
<arjanb>evaluation of nice code at compile time, (partial) checking of preconditions at compile time, inlining of higher order functions18:33
<bonniot>for optimization?18:34
<arjanb>both optimization and typechecking
<bonniot>in what case is this related to tychecking?18:36
<arjanb>not typechecking but analysis18:37
<bonniot>example?18:38
<arjanb>if (true && false) { ... } 18:39
somelist[-1]
<bonniot>and what is the point?18:40
<arjanb>this are trivial examples but i want to make the compiler give more feedback18:41
<bonniot>you mean, report an error at compile time?18:43
<arjanb>yes
<bonniot>ok18:44
btw, this was still not my question18:45
<arjanb>right i misread the question 18:46
for retypings i have no idea how to get that done18:48
<bonniot>i think it's not hard18:50
the rule declaration would store information, which the class nice.tools.code.Import would use to decide what type to give to each method it imports
<arjanb>for lines number it's just moving the fixup code to nice.lang and insert a try catch around the main method body
<bonniot>yep18:51
i think both are very important, both for users (andres mentioned the line number problem) and for development18:52
<arjanb>moving it stdlib gives bootstrap problems19:00
<bonniot>it should be possible to compile it early, it does not depend on anything in the compiler19:02
(actually, it's even not Nice-specific)19:03
<arjanb>could you create a dev version with source-lines.nice in nice.lang instead of nice.tools.util?19:04
<bonniot>why is that needed?19:05
<arjanb>i don't know but i get:19:06
F:\Nice>call nicec --exclude-runtime -d classes --sourcepath="src;stdlib" --classpath=classes -R bos
sa.modules
nice.lang.reflect: parsing
An exception has occured in the compiler
Please fill-in a bug report at the following webpage:
http://sourceforge.net/tracker/?func=add&group_id=12788&atid=112788
Stack trace:19:07
Exception in thread "main" java.lang.NullPointerException
at mlsub.typing.MonotypeConstructor.<init>(MonotypeConstructor.java:46)
at bossa.syntax.Monotype.sure(Monotype.java:291)
at bossa.syntax.NiceFieldAccess.<init>(NiceFieldAccess.java:37)
at bossa.syntax.NiceClass$Field.<init>(NiceClass.java:146)
at bossa.syntax.NiceClass$Field.<init>(NiceClass.java:136)
at bossa.syntax.NiceClass$NewField.<init>(NiceClass.java:217)
at bossa.syntax.NiceClass$NewField.<init>(NiceClass.java:211)
at bossa.syntax.NiceClass.makeField(NiceClass.java:125)
at bossa.parser.Parser.getField(Parser.java:1041)
at bossa.parser.Parser.classDefinition(Parser.java:1218)
at bossa.parser.Parser.definition(Parser.java:2442)
<bonniot>you did not put in in prelude.nice, did you?19:09
<arjanb>no
<bonniot>and that goes away if you remove source-lines.nice?19:10
<arjanb>yes19:11
<bonniot>i don't think a version which already has the methods in nice.lang would change anything19:12
<arjanb>it seems to have something to do with dependency on nice.lang.reflect
<bonniot>it looks like sureTC is null
<arjanb>*away for meal*
<bonniot>yes, it surely does!19:13
code in nice.lang should no depend on another package
<arjanb>*back*19:28
shouldn't nice.lang be split in two parts19:29
one that needs to be processed first and may not depend on anything19:30
other just everything else that should be imported implicitly for all nice source
<bonniot>the first part is prelude.nice19:35
i'll look if one can handle the case where nice.lang imports something
<arjanb>in this case it's not needed 19:40
only one method i use from nice.lang.reflect
next problem:20:01
F:\Nice>call nicec --exclude-runtime -d classes --sourcepath="src;stdlib" --classpath=classes -R nic
e.tools.compiler.console
nice.lang: parsing
mlsub.compilation: parsing
bossa.modules: parsing
nice.lang.reflect: parsing
nice.tools.util: parsing
line 4, column 8:
nice.tools.util must be compiled, but no source code is available.
The source path is: src;stdlib
<bonniot>just remove 'import nice.tools.util' from nice.tools.compiler20:02
i wonder what should be done in the catch, after printing the stack20:08
System.exit is not good because it will stop the whole JVM (for instance the test engine starts main and catches its exceptions)20:09
but if we rethrow the exception, it will be printed again (and wrong)
one solution would be to make <pkg>.dispatch the main class in jar, and to catch exceptions in dispatch.main and then System.exit(1)20:15
but applications can still call fun.main and catch the exception themselves
<arjanb>what about rethrowing a special exception that overrides the output printing20:18
<bonniot>sounds good20:19
the only problem is if the app wants to know what class of exception was thrown
i suppose you could create a subclass of the exception's class on the fly, except if it's final20:20
but that's more work...
<CIA-3>03arjanb * 10Nice/ (3 files in 3 dirs): Moved source line fixup to nice.lang.20:21
<bonniot>catching in dispatch.main is simpler and will give the same results as a special exception, no?
<arjanb>i think so
chained exceptions are supported in java 1.420:22
<bonniot>but we cannot rely on 1.4, especially for generated code20:23
you think dispatch.main is better?
<arjanb>yes20:25
<bonniot>i think i'm getting somewhere with the arrays...20:28
* magnus-- joins21:12
<bonniot>hello magnus21:16
<magnus-->hello21:21
I am thinking of using Nice to implement a univ project compiler21:22
just wanna check if you think it's a wise idea
<bonniot>yes, sounds interesting
what kind of project is it?
<magnus-->It's just a compiler construction course
to make a compiler for the MiniJava language21:23
<bonniot>and you are free to choose any language to implement in?
<magnus-->yes
<bonniot>lucky ;-)
<arjanb>only problem is that there exist no parser generators for nice21:24
<bonniot>yes, but there are for java!
<magnus-->I could use one for java I was thinking
although I don't know if there are practical problems with that
<bonniot>it should be ok21:25
<arjanb>using java->nice is less smooth than using nice->java
<magnus-->what does Nice itself use for parsing?
<bonniot>JavaCC
arjanb: when you create instances, which is the basic operation in a parser, it's the same21:26
<arjanb>another good one for java is ANTLR
<bonniot>a java source can use 'new MyClass(a,b,c)' to instantiate a Nice class21:27
<magnus-->cool, yes that should be very useful
<bonniot>one interesting aspect of using multi-methods in a compiler is that you can isolate passes in different packages21:29
so your compiler is very modular
<magnus-->this is exactly what made me interested in nice:)
for the project
<bonniot>ok, i see you know the subject :-)
<magnus-->i learned it from the nice pages actually
<bonniot>anonymous functions should be useful too21:30
i bet you will have half the LOC of those that will choose Java/C++
<magnus-->hope so:)21:31
<bonniot>how much time do u have?21:37
<magnus-->March 1121:41
<bonniot>and you have to compile MiniJava to java bytecode?21:46
<magnus-->yes21:52
<bonniot>and can you use any lib?
<magnus-->can use lexer generators and parser generators21:53
We haven't got the details for the parts after that yet
<bonniot>but you must generate the bytecode by hand?
ok
there is bcel for instance which seems very used
<Bluelive>first choose seems to be the parser javacc or antlr seem to be the best options21:54
<bonniot>we use javacc so we can help more, but i think antlr seems more sexy21:55
<Bluelive>i use antlr, but it can be used in different modes, ADC or not for example, i think its error messages can be a bit cryptic21:56
ehmz
AST
personally i dont use the ast stuff, but at that time i didnt really understand it 21:57
<bonniot>that is that it generates your classes for you?
<Bluelive>yups21:58
<magnus-->checking out antlr22:00
<bonniot>and what happens if you started modifying the classes and then you the change the parser?22:03
<Bluelive>dont know i dont use it like that22:05
<arjanb>by default antlr using a single class to represent ast trees
<bonniot>???22:06
is that usable?
<arjanb>for toy languages22:07
<Bluelive> z:ALIAS type a:IDENT SEMI { Context.addAlias(z, Context.consumeType(), new Identifier(a), Context.currentNamespace(), Context.consumeModifier(), Context.consumeMetadata()); }22:08
<bonniot>the same class represents an integer, a function application, a class definition,...?
<arjanb>yes it contains fields with the kind of the node the subnodes and the token it represents22:09
javacc and antlr are quite similar and they have both some rough details22:16
antlr has better intergrated the ast creation and treewalking stuff but if you don't need that i would prefer javacc22:18
<Bluelive>my main reason for antlr is that it seems pretty easy to retarget (for example to alpha ;)22:20
<bonniot>or Nice ;-)23:07
wasn't the retargettting supposed to be for a future release? Or that one already happened?
<Bluelive>well i saw that some one easily changed the java generator into a c# generator, so i assumed i could do the same trick againg23:12
but i wont tocuh that for a few months i guess

Generated by Sualtam