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

Using timezone: Central European Time
* CIA-7 joins00:51
* ChanServ leaves04:11
* ChanServ joins04:12
* arjanb leaves04:20
* arjanb joins13:16
* cm_ joins
* fcb joins14:49
* gamsl joins15:21
how's the plugin going?15:23
still no sign of daniel?15:25
<arjanb>no but i think he's reachable by mail15:26
<fcb>yeah, that's cool15:27
<gamsl>hmm ... not much changed since, except that I can launch nice apps via a simple trick15:28
the trick is to give nice projects a java nature, which on the one hand is not very elegant (as it still leads to a lot of cluttering the ui), but on the other hand could prove usefule when developing mixed java and nice projects
<arjanb>most nice projects will contain java libraries..15:30
<gamsl>i don't think we would need to set the javanature to niceprojects because they use java libraries15:32
but nice uses the jvm to launch apps (as it is a jvm based language), so we should reuse all the facilities (core and ui) that eclipse provides to launch java apps15:33
i was in contact with the main developer of the haskell eclipse plugin, and they built a common plugin for functional programming languages. besides that this is a good source to look into, it brought the idea to my mind, that (maybe not only) we could make use of some common JVMLanguage plugin (that of course doesn't exist yet)15:36
<arjanb>that's a good idea15:37
<gamsl>the idea is to factor out the eclipse classes that realize jvm launching and of course the ui representation (all kinds of launch properties you see when launching a java app in eclipse), as most jvm languages can make use of them.15:39
currently this functionality is solely dependant on the eclipse intern javamodel, javaproject, ....15:40
<arjanb>an ide plugin is viewed as minimal requirement by many people and it's a lot of work where new languages are struggling with..
<gamsl>yes i think so too (just happened to hear of a friend of mine's boss, that he thought about using nice, but isn't pleased with the current ide support)15:42
i think "a lot?" of people heard about nice through the article in the german IX magazine15:43
that's good!
<gamsl>i'll keep on pushing my friend to persuade his boss :-)15:44
<arjanb>btw cm_ has some experience with creating eclipse plugins so maybe can he you with the design issues..15:46
* fcb leaves
<gamsl>that would be great15:47
<arjanb>ow we have the mailinglist for that too
<gamsl>yes i know, is it inappropriate to discuss eclipse issues here?15:48
<gamsl>ok puuh :)
<cm_>The nice-list is very quiet though
<gamsl>you mean nice lists in general or the eclipse one?15:50
<cm_>Hmm I meant the nice-eclipse list
cm_: what do you think of factoring out java launching capabilities (along with their ui) from the jdt, and provide some layer for jvm languages to be useful in general?15:54
<cm_>gamsl: Factor out and keep it in java?15:56
<gamsl>you mean write the code in java?
<cm_>gamsl: Is it worth the effort to translate functional code to nice?
gamsl: Are there any problems with having a java/nice nature project?15:57
<gamsl>well the ui is rather cluttered as you have all the settings for java projects and stuff as well, which is necessary when developing mixed java/nice apps, but I guess is annoying when developing pure nice apps (which hopefully should be the regular case :-)15:58
<arjanb>a common code base for jvm languages plugins has to be in java i think15:59
although it's no comon code base for java but for jvm languages
I can't see clear reasons for not writing it in nice .... ??16:00
<cm_>It could also be hard to define and impl. a general layer as several requirements could be unknown?16:01
gamsl: But why not focus on core nice features such as compilation, error correction, refactoring etc first?16:03
<gamsl>hmm ... they would be the most useful of course, but they require a comprehensive model of nice source. actually i thought of tackling the editor when the base infrastructure (compiling, launching, preferences, properties, ...) is ready16:07
<cm_>Ok, have you looked at the AST representation in nice?16:11
<gamsl>not closely yet, and I think I heard from luc that this parts of code will be subject to change (improvement), arjan, is this correct?16:12
<cm_>gamsl: I think so. It is important to get input from the eclipse development in order to make it fit.16:14
<gamsl>i see the point!
<arjanb>we are halfway of the conversion of the ast to nice code and some minor things may changes16:15
<gamsl>ok I think anyway that code that adapts to eclipse better (if necessary) should be written in an own library16:16
<cm_>Ideally should much of the compiler be resued in the plug-in.16:19
<gamsl>i agree, if looking at bossa.syntax now shall I concentrate on the nice files?16:20
<cm_>Error correction and compilation error is related. eg, if the compiler finds that a ';' is missing should that information be extractable.16:21
arjanb: Does the compiler "fix" errors in order to continue compilation in its current state?16:23
<gamsl>basic compiling and error reporting is working via a CompilationListener. What I get there is a bossa.util.Location object and a String message. How can I use Location to grab deeper, or is there another way?16:25
<cm_>gamsl: I guess that well defined error codes should be appropiate in error() and warning().16:31
Another issue is how to modify the code. 16:33
I reckon that JDT has AST and some DOM-like representation of the code.16:35
<gamsl>i can't follow your idea with error codes in error() and warning(), where do they come from? bossa.util.Location doesn't seem to provide them?16:36
yes jdt represents code internally in such structures16:37
<cm_>It was just an idea.
<gamsl>you mean the compiler should provide this information along with the Location object sent to the CompilationListener (or something else)?16:39
<gamsl>and then use them for ... error correction?16:43
If not the information is available somewhere else16:46
<gamsl>I think what is needed is a model of source code that is "filled up" with values during a compilation, with a precise API to read and modify from the plugin, that can be sent back to the compiler for further (incremental) compilation16:47
<cm_>Is it really necessary?16:48
<gamsl>wouldn't it be the most flexible solution? (refactoring, navigation (type hierarchy views, searches) ...). My ideas stick close to the jdt, as I think that people got used to facilites like this and don't want to miss it ...16:51
<cm_>gamsl: If it is done in JDT it is probably a good idea.16:52
<gamsl>i think they do it this way ... but it could mean a lot of work :)16:53
arjanb: what do you think of this?
<cm_>When is this "filling" API used?
I mean, couldn't error correction be done in different phases? 1) Compile 2) Fix errors interactivaly 3) No errors, if not go to 1).16:55
<gamsl>i'm not familiar with the internals of jdt, but when you compile java files, a JavaModel is created that represents the source code, and operations like c
code completion, refactoring, ...16:56
the state of the resource you edit (java file) and the model, are always consistent
updated vice versa
<cm_>Ok, but the modifications are not done during compilation?
Of a single entity16:57
<gamsl>modifications in terms of correction? no interactively, the user modifies code directly or via the model by either typing or using features like completion, .... from the Javaodel
<arjanb>sorry was away..16:58
<gamsl>afterwards it gets incrementally recompiled
which updates the model again ...
<arjanb>the current handling of errors in nicec is that for every pass all errors are collected and the compiler stops before the next pass to avoid indirect errors16:59
it doesn't have any form of error correction17:00
<gamsl>ok but I think this correction should be interactive anyway, based on a few (like java) proposals on what can be done to solve the problem17:01
I think if the source code is not kept in a proper model then automatically generated corrections based on proposals will be difficult?
<cm_>But it could be interactive even if incremental compilation of a single unit isn't supported.17:02
I believe
<gamsl>yep incremental compilation is just a gimmick .. but a nice one :-) Nice - nice ... you see ... :-)
Ok, so error reporting and error corrections seems certainly be something for the nice-eclipse list.17:03
<gamsl>i agree17:04
<arjanb>i don't like error correction inside the compiler because of added complexity17:06
<gamsl>I don't think it's necessary
<arjanb>but completely restarted the compilation is way too slow atm
<gamsl>do you think of internal correction along with incremental compiling?
<arjanb>that would be ideal but it's a hard problem17:08
<gamsl>mhm ... are there other ways to incremental compilation? the info eclipse provides is just Resource.ADDED,REMOVED,CHANGED17:10
on files
<cm_>arjanb: But you could have well defined error codes that could be used. eg SYNTAX_ERROR_MISSING_SEMI for missing ';'. The corrections could then be done by the plug-in.
<arjanb>i think error codes provide not enough information to do error correction17:13
<cm_>Probably not, but it could perhaps be done in a similar fashion
eg, class ClassIsNotImplementingSomeMethods { List<X> getNonImplMethods() }17:14
for classes not conforming to a specific interface.17:15
<gamsl>and along with this in a model we could just offer to write the missing methods out to the source file
<cm_>Through some DOM/AST-model 17:16
<gamsl>cm: do you think of the ClassIsNotImplementingSomeMethods as an extend version of errocode?
that is passed with every error?
<cm_>A class sharing a common subclass like NiceError or something17:17
<arjanb>the plugin needs to be able to read the nice ast anyway..
<cm_>Yes, but you could de facto know what the problem is about in the compiler. Why duplicate the code?17:18
<gamsl>i think an abstraction above AST with tailored api to manipulate it could do the job. Couldn't this be a model of nice source?17:22
<cm_>As long it is possible to go from AST to source17:24
<gamsl>arjanb: is this currently possible?17:33
the ast changes during the compilation so it doesn't always have 1 to 1 relation to the source17:35
<cm_>gamsl: Do you write an email to the list about the discussed issues?17:42
<gamsl>cm: yes I will do that (a bit later)17:44
<gamsl>there still remains the question for me on what to focus. I still think that building on a reliable base would be a good idea, and that advanced editing (as it will be the most complex part) should follow only then ...
<cm_>Imo is the "editing" stuff most important and rather independent to launching and others...17:52
But of course also most challenging17:54
<gamsl>both is true ... but I think that compiling, launching and the basic new wizards are essential! they are small tasks compared to the "editing" stuff which is basically all the rest ...17:58
btw there is no way to invoke nicec on files, right? is the basic compilation unit a package? which means a folder basically18:03
i think the main design issues are: how to represent the source code in the plugin, how to let the plugin run the compiler, reading (later maybe changing) of the ast by the plugin ,how to get the needed info of errors to the plugin
<cm_>gamsl: If it is possible to launch nice apps from a combined java/nice nature project I would vote for going that route to start with.18:05
Writing simple gui oriented stuff is boring - at least from my point of view :-)18:09
<gamsl>i think so too, but the whole thing looks and feels just like a big workaround. some things, like searching for the main type of a class in the java launch wizard doesn't work and other features don't work due to the javaproject that doesn't contain java sources, ...18:11
because it simply is no javaproject18:12
i think this is a good option for mixed source projects, as in this case all options are needed. if the user writes nice apps it just feels awkward
<cm_>So it doesn't search the .class files for the main-method then?
<gamsl>and I like the idea of factoring out a common infrastructure for JVM based languages in eclipse :-)18:13
actually i'm not sure but i think i read somewhere that some operations are performed on the internal source model and some are done on class files, i would need to look that up again .18:14
<cm_>I understand but it is also important to have a well defined scope of the project.
You are writing a thesis - right?
<gamsl>yes diploma thesis although the exact title is not yet decided ... something important around the code :-) ... for me, i want to code :-) although that alone won't be enough. For now (the next months) i only plan to do coding ...18:16
concerning the scope of the project related to the thesis, my primary goal is to make an ide for nice, not to write a thesis18:18
i hope a thesis can be made out of it too .-)
<arjanb>*away for dinner18:23
<cm_>gamsl: I have to leave but we can continue the discussion later and on the mailing list.18:34
* cm_ leaves18:36
* Vurlix joins19:08
<arjanb>hello Vurlix19:13
<arjanb>did you have time to try Nice?19:16
<Vurlix>unfortunately, i haven't had any time to do any programming19:18
<gamsl>arjanb: how can java classes use nice classes with type parameters?21:31
<arjanb>the type parameters don't exist in bytecode21:33
mostly the typeparameters get erased to object21:36
do you have an example of where you want to use a parametric nice class?21:38
<gamsl>class A<T>21:44
T element;
T getContext();
how do i instantiate that in java to say NiceElement
it's not really necessary for me i'm just curious21:45
although it's interesting to know for jvm based languages that can handle .class libraries (like nice) how they can use this code21:46
<arjanb>how nice specific features are compiled is not documented and may change21:54
if you can read bytecode, javap -c on the class may give you an idea21:55
<gamsl>i am not too familiar with bytecode, i was just wandering if the layer that abstracts the launching process and the launching configuration ui for jvm based languages could be written in nice, as this would have a lot of advantages, at least compared to java below 1.521:57
<arjanb>in that case the code would implement java interfaces right?21:59
<gamsl>extend java classes and implement java interfaces22:00
<arjanb>then it should just work for all in java defined methods22:01
<gamsl>i still don't get it, parametric nice classes can't be used from java?22:18
<arjanb>they can be used only they won't have the typeparams22:22
<gamsl>so what does getContext() in the above example return and how can i instantiate A ?22:27
<arjanb>Object new A(someObject) //if element is the only field22:38
<gamsl>aa ok so type params will be treated as Object and contructors are generated .22:40
btw i can't write to eclipse-mailing list now as cm proposed, because my mailer is down since hours ...
<arjanb>not always Object, when there are constraints it can be different22:41
<gamsl>so when there is class A<SomeType T> { T field; } , field will be of type SomeType?23:15
<arjanb>yes though i'm not sure about the details of the type translation23:34

Generated by Sualtam