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

Using timezone: Central European Time
* lucp joins01:22
* Vurlix leaves
* lucp leaves02:03
* lucp joins
<arjanb>i think conversion has no advantage on the short term03:34
it's much work and i only do that when i'm undecided about how to implement real features03:37
<lucp>what are the current short term goals?
<arjanb>getting ready for 1.003:38
<lucp>what is still missing from that release, apart from visibility modifiers?
<arjanb>properties, java 1.5 support and fixing known bugs and annoying details03:40
<lucp>do we have a comprehensive list of bugs?03:42
<arjanb>the bug tracker on sourceforge and bug marked thing in the testsuite03:44
<lucp>sorry i must go again.. i'll return in about 20 minutes.03:46
doesn't nice already add a get and set method for fields? how is this different than properties?04:32
<arjanb>these get and set methods are only bytecode04:33
<lucp>i see..04:36
i was looking at the typechecker last night on how it could be possibly improved.. it seems slow compared to the rest of the compiler on my machine.04:40
<arjanb>yeah it's the slowest part04:41
<lucp>i tried to run a profiler to find where the bottlenecks are, however it is not compatible with my version of gcc04:43
<arjanb>i did some optimizations on it but can't get further with that without understanding how it works.04:44
<lucp>i have a general understanding of how it works..04:45
<arjanb>i found the typesystem very sensitive to changes04:48
<lucp>well it needs more documentation :)04:49
<arjanb>that's true f all of nicec's code..04:51
i guess it's a problem of one person projects04:56
<lucp>i also find it difficult to separate the bossa.syntax package from the mlsub.typing package.. the code jumps between the two in very confusing ways
i agree.. when i write code just for me, the code is hardly documented.04:57
<arjanb>nice started as a parser, typesystem and a bytecode generation lib glued together04:59
bossa.syntax uses mlsub.typing heavingly and it contains the syntactic parts of the types05:01
<lucp>i get that.. i'm just saying that as someone with little experience with the nicec code, its difficult to understand if we are talking about the syntax part or the typesystem part in many areas of the code.05:05
<arjanb>it still confuses me sometimes..05:07
<lucp>i believe the problem stems from the fact that both packages use classes with the same name05:11
<arjanb>maybe they can be postfixed with AST or something05:16
<lucp>ideally, the syntax package would have no functionality on its own, and would only represent a model of the code to be compiled.. the connection to the typesystem would be done at a different place05:18
untangling of bossa.syntax will be easier once most of it is converted05:24
<lucp>i am more familiar with ASTs than type systems and byte code. i have written some parsers and ast generators in the past. this is why i offered help to clean up this package and convert it to nice.05:29
as for the objectives for the 1.0 release, i will probably be of little help..05:33
<arjanb>i understand05:37
there's no problem if you want to do conversion, any help is appreciated05:38
i only wanted to point out there are other things that can be improved with greater visibility to the users05:44
<lucp>definately.. most of those things require lots of knowledge about the system as a whole to work on.05:49
<arjanb>would some overview document help?05:56
<lucp>i'm thinking of creating a separate a new AST as a side project that's independant from the current one. it could then be reused for nicec once we are ready to re-factor the code. an overview would definately be useful.05:58
<arjanb>i don't think a new AST would end very differently from the current one06:02
all compiler passes in one place is the problem06:04
<lucp>that is why i'm suggesting to make a new AST... it would be a good starting point to seperating the compiler passes. it would also be a good excersize for me, and would be very useful to be used in IDEs such as the eclipse plugin.06:08
<arjanb>i mean with AST the class hierachy and the fields each class contains06:12
i don't see what that has to do with seperating passes06:13
<lucp>right.. the class hierarchy would stay essentially the same.. i would be simply extracting the parts that have to do with parsing and syntax, and documenting that code.06:14
of course, the inner classes will need to be seperated.06:15
good night06:22
* arjanb leaves
<lucp>talk to you soon
* lucp leaves08:39
* arjanb joins13:10
* cm_ joins13:55
<cm_>seen fcb lately?
* CIA-10 leaves18:09
* CIA-7 joins18:33
* CIA-7 leaves19:01
* CIA-10 joins
* a---ObI[1]---a joins19:22
* a---ObI[1]---a leaves19:23
* cm_ leaves23:55

Generated by Sualtam