nice-eclipse Mailing List for The Nice Programming Language
Brought to you by:
bonniot
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|
From: Daniel B. <Dan...@in...> - 2004-12-26 06:38:16
|
Hi, Martin, I'm sorry I made the mistake of not subscribing to this list, so I did not see when you posted your introductory message. I must say I globally agree with your goals. I'm also glad to see many things are already working. I think that includes things that were not done in the previous plugin, like running the application inside eclipse! Which brings the question, is there already a beta available? Are you waiting for a rewrite before that? Where is the source code going to be? It would be good if you could let us know how things are progressing from time to time. There are already 6 subscribers to this list, plus gmane, which makes it publicly available. It could also be a good idea for you to post on nice-info to let people know about your project and the existence of this new list. Happy holidays to all of you! I'll be visiting in France, but I should have net access reasonably often. Daniel |
From: Martin G. <ga...@ab...> - 2004-12-03 18:01:20
|
Hi Everyone! As I am just starting to develop a new Eclipse Plugin for Nice, I wanted to share my first ideas and goals concerning features and their realization with the community. Everyone reading this is very welcome to comment on everything that is said here! If you have ideas, feature requests, problems, you think I'm wrong, you think someone else is wrong, you know a better way to do something (maybe because you already have experience in that domain), really whatever comes into your mind concerning the nice-eclipse plugin! Don't be shy, post it here! 1) General Approach One thing I have to say right away is that my general approach to writing this plugin may look a bit "conservative" to some of you, as I do not really plan to rush things and add feature after feature as fast as possible. Instead I'm planning to focus on a solid design that integrates smoothly into eclipse and is flexible enough to handle advanced IDE tasks . Therefore I still need to do extensive studies of eclipse to get more insight into how things are done. I know that it would be hesitating to start implementing cool editor features right away, but I think that without a solid architecture, a project of the size this one will probably have in the end, will be a pain to deal with. One consequence of this approach is, that it may take some time until the first "true features" will be available (as building and running are too basic to be considered true features :-). True Features are probably those that make editing Nice source easier. Another consequence is, that once the underlying architecture is reliable, it should generally be easier and faster to add features. I hope this will work out and provide a nice piece of software. Same as with everything here, comments welcome! 2) Goals The following is by no means a complete list of goals for this project. These are just the ones that came into my mind so far (minus a few I just can't think of right now) 2.1) Long term goals Long term goals haven't been defined exactly yet, but it is definitely an overall goal to provide a full fledged Nice IDE that supports everything programmers coming from java are used to. The general rule should be that if some operation is possible in the (Eclipse) Java IDE, it should be possible to do it in the Nice IDE as well, along with features we come across that are unique to Nice. This is a brave goal, it will take time to achieve it! 2.1) Short term goals As said on page 18 of the german edition of the book "Contributing to Eclipse: Principles, Patterns and Plugins" by Erich Gamma and Kent Beck (maybe suffering from my poor translation abilities): "Entering the world of Eclipse, you will spend more time reading code, than writing code. You first have to get used to those incredibly productive days, where you spend 6 hours on reading and 1 hour on writing code." You probably guessed right, I own this book :-) Anyway, the following is what I will read a lot about, and hopefully also will write enough to make it work. Sections marked as DONE are still subject to refactoring or even rewrite from scratch, as I gain more understanding of the eclipse platform. So if you think almost everything is marked as DONE, why are these still goals? Think of the current implementation as a prototype that anyway will be rewritten in Nice very soon. 2.1.1) User Interface + Nice Perspective DONE + Navigator View showing Nice Project with Resources DONE + Problem View showing Nicec compilation errors DONE + Project Properties Dialog DONE + Add/Remove Java Nature for a Nice Project (current workaround to launch Nice apps) DONE + Add Nice Projects Wizard DONE + Add Nice Packages Wizard DONE + Add Nice Source Files Wizard DONE + Source Outline View TODO + ... + ... 2.1.2) Building + Build Nice Project DONE + Error/Warning reporting in the Eclipse Taskbar DONE + Configure Nicec Sourcepath DONE + Configure Nicec Classpath DONE + Configure Nicec Destination Directory DONE + Configure Nicec Distribution Directory DONE + Configure Nicec Main Package DONE + Configure Nicec Target Jar File DONE + Build Nice Projects depending on other Nice Projects TODO (currently strange behaviour) + Configure Nicec Compilation Flags TODO (GUI is ready) + Error/Warning reporting in the Editor TODO 2.1.3) Launching + Launch Properties using eclipse wizards for configuring Java Project launches with minor modifications WORKING + Launch Nice Applications using eclipse built-in java launching capabilities WORKING 3) Design This is actually the most important goal for now: get an understanding of the eclipse architecture to be able to extend it correctly and get the most out of it. It is very likely that the plugin will be developed in a few subprojects (that map to plugins) to separate logically independent parts from another. Here are two of them I can think of at the moment. 3.1) JVM Based Language Launching As Nice compiles to java bytecode, Nice apps are run like normal Java apps. However, the eclipse code that realizes this functionality depends on the JDT's JavaModel (a set of classes that model java source and - i think to a certain extent - bytecode as well). This leads to the restriction that plugins that want to launch programs using the JVM need always be JavaProjects (working with a JavaModel) in order to make use of the Java launching capabilities. The goal of this subproject should be to provide a way for jvm-based languages to plugin their own type of project, along with their own model, and still use all the functionality and UI that Java programmers use when launching their applications. I think this makes perfect sense, as when it comes to launching, there is really no difference between java and nice (and probably most other jvm-based language). This idea came to my mind when looking at http://eclipsefp.sourceforge.net/ . Those people try to provide a common framework for functional languages (not especially targeted at launching) that should make life easier for plugin writers. Why not try to get something reusable out of a problem we anyway have to tackle? 3.2) A Model for Nice Source Code To do advanced source code editing we need a model that represents Nice sources inside the plugin. This could be a model of source code that is constructed 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) compilation. IMO advanced operations like refactoring, error correction proposals, searching, navigating, ... justify the additional complexity of such a model (and the changes/additions to the compiler that are needed), as they would be a pain to implement with no reliable infrastructure. This model (or API used by the model) could be implemented as a library using Nice AST. This is definitely one of the integral parts of the plugin and will need a lot of discussion, especially with core developers. Although it is no main goal for me at the moment to start implementing this, we should use the time to discuss an architecture both inside and outside the Nice compiler, that would be able to handle these issues. I hope this gives you all a little overview of what I'm planning to do. As mentioned above, feel free to comment on everything! I also added a new page to the eclipse wiki where ongoing discussions that are better made accessible for easier reviewing, can be copied from this list, or started right on the page. Access it at http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NewEclipsePlugin As a start I will copy this message on the page. Unfortunately sourceforge doesn't provide an option to be notified of wiki changes, so just surf by from time to time to see if something has changed. An idea would be to make it a convention that everyone who posts something on the wiki, should write a short notification to this mailing-list? Looking forward to exciting discussions! Martin Gamsjaeger |