Smalltalk › Redline Smalltalk

eclipse-plugin

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Stefan Krecher

eclipse-plugin

Hi,

i started with the eclipse-plugin: https://github.com/StefanKrecher/eclipse-redline-plugin

It is the very first preview but i wanted to release this early to be prepared for any wishes/ commets etc.

On the Wiki-Page are two screenshots: https://github.com/StefanKrecher/eclipse-redline-plugin/wiki

I'm using Xtext for parsing/ syntax highlightning/ code completition etc. So i have to reimplement parts of the parser, but Xtext is very powerful and we can use all the nifty features of the eclipse plugin development environment.

Currently it's only an Editor but it could be enhanced to an own "Perspective" with more Smalltalk-Development Tools, e.g.

- Class Hierarchy Browser (by switching to that perspective all .st-files would get parsed to an ecore-model)

- Debugger (it's already there)

- Transcript (a console, it's already there too)

- a Workspace (we could use something like the eclipse-scrapbook-pages for that)

This Perspective could be packaged as an own RCP-Application so we would have a standalone Smalltalk-IDE ...

Any comments/ wishes regarding the plugin are very welcome!

Some questions came into my mind while i was doing the plugin:

- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

- why didn't you use the "original" file-out-format?

- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

- what is with "Categories"?

regards,

Stefan

James Ladd

Re: eclipse-plugin

Wow this is exciting. I can't wait to get a chance to check it out and respond to your questions.
Well done.

On Tue, Sep 20, 2011 at 9:22 PM, Stefan Krecher <[hidden email]> wrote:

Hi,
i started with the eclipse-plugin: https://github.com/StefanKrecher/eclipse-redline-plugin

It is the very first preview but i wanted to release this early to be prepared for any wishes/ commets etc.
On the Wiki-Page are two screenshots: https://github.com/StefanKrecher/eclipse-redline-plugin/wiki

I'm using Xtext for parsing/ syntax highlightning/ code completition etc. So i have to reimplement parts of the parser, but Xtext is very powerful and we can use all the nifty features of the eclipse plugin development environment.

Currently it's only an Editor but it could be enhanced to an own "Perspective" with more Smalltalk-Development Tools, e.g.
- Class Hierarchy Browser (by switching to that perspective all .st-files would get parsed to an ecore-model)

- Debugger (it's already there)
- Transcript (a console, it's already there too)
- a Workspace (we could use something like the eclipse-scrapbook-pages for that)
This Perspective could be packaged as an own RCP-Application so we would have a standalone Smalltalk-IDE ...

Any comments/ wishes regarding the plugin are very welcome!

Some questions came into my mind while i was doing the plugin:
- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

- why didn't you use the "original" file-out-format?
- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

- what is with "Categories"?

regards,
Stefan

James Ladd

Re: eclipse-plugin

In reply to this post by Stefan Krecher

In reference to your questions - responses inline ....

Some questions came into my mind while i was doing the plugin:

- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

Currently the generated classes are kept in memory as Redline Smalltalk is meant to be highly dynamic. Change a source file (.st) and the
class is re-built in memory. Is there a need to have the classes written out to enable the Eclipse plug-in?

- why didn't you use the "original" file-out-format?

The original file out format is ugly and overly verbose when it comes to being edited by a human.

- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

Not sure - id have to google.

- what is with "Categories"?

Categories can be added to a class definition. However, they currently get ignored.
There is a continuing discussion about what to do with categories, for example, turn them into Annotations.

Stefan Krecher

Re: eclipse-plugin

Am Donnerstag, 22. September 2011 05:01:49 UTC+2 schrieb jamesl:

- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

Currently the generated classes are kept in memory as Redline Smalltalk is meant to be highly dynamic. Change a source file (.st) and the
class is re-built in memory. Is there a need to have the classes written out to enable the Eclipse plug-in?

i guess that wouldn't be a must-have. It's more that developers would expect a builder/ compiler for redline, so errors in the syntax would be detected at compile time. Currently the editor would notify the developer if there are symantic errors. Other plugins (eg the groovy-plugin) have a groovy builder/ compiler and show the errors which were produced at compile time.
This must not be a contrast to a high dynamic. Classes could be changed at runtime - to make the changes persistent one could explicitly save the changes (like a smalltalker would save the image - and that's what it is: saving the bytecode).
It would also be a performance improvement, when you have "precompiled" classes.

- why didn't you use the "original" file-out-format?

The original file out format is ugly and overly verbose when it comes to being edited by a human.

that's a good point - but with xtext we could build a very sophisticated editor with a class-browser to edit classes/ methods. The editor would change the original source immediatly.
Advantage would be that we wouldn't need an Smalltalk-Exporter and that we could use the eclipse-plugin for other smalltalk-dialects too

- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

Not sure - id have to google.

- what is with "Categories"?

Categories can be added to a class definition. However, they currently get ignored.
There is a continuing discussion about what to do with categories, for example, turn them into Annotations.

What would be the benefit of having the categories turned to Annotations?

regards,
Stefan

Robert Roland

Re: eclipse-plugin

My intention for turning categories into annotations was mostly around introspection and a live source browser, like other Smalltalks. A category is essentially metadata and is not really necessary for execution. An annotation seems like an ideal fit there.

On Thu, Sep 22, 2011 at 3:05 PM, Stefan Krecher <[hidden email]> wrote:

Am Donnerstag, 22. September 2011 05:01:49 UTC+2 schrieb jamesl:

- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

Currently the generated classes are kept in memory as Redline Smalltalk is meant to be highly dynamic. Change a source file (.st) and the
class is re-built in memory. Is there a need to have the classes written out to enable the Eclipse plug-in?

i guess that wouldn't be a must-have. It's more that developers would expect a builder/ compiler for redline, so errors in the syntax would be detected at compile time. Currently the editor would notify the developer if there are symantic errors. Other plugins (eg the groovy-plugin) have a groovy builder/ compiler and show the errors which were produced at compile time.
This must not be a contrast to a high dynamic. Classes could be changed at runtime - to make the changes persistent one could explicitly save the changes (like a smalltalker would save the image - and that's what it is: saving the bytecode).
It would also be a performance improvement, when you have "precompiled" classes.

- why didn't you use the "original" file-out-format?

The original file out format is ugly and overly verbose when it comes to being edited by a human.

that's a good point - but with xtext we could build a very sophisticated editor with a class-browser to edit classes/ methods. The editor would change the original source immediatly.
Advantage would be that we wouldn't need an Smalltalk-Exporter and that we could use the eclipse-plugin for other smalltalk-dialects too

- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

Not sure - id have to google.

- what is with "Categories"?

Categories can be added to a class definition. However, they currently get ignored.
There is a continuing discussion about what to do with categories, for example, turn them into Annotations.

What would be the benefit of having the categories turned to Annotations?

regards,
Stefan

SeanTAllen

Re: eclipse-plugin

In reply to this post by Stefan Krecher

Not sure - id have to google.

- what is with "Categories"?

Categories can be added to a class definition. However, they currently get ignored.
There is a continuing discussion about what to do with categories, for example, turn them into Annotations.

What would be the benefit of having the categories turned to Annotations?

Categories are metadata. unfortunately smalltalk didn't have a good metadata system so categories were added as one type and then pragmas were (ab)used for many others. James and I have had a few conversations over the months that basically come down to my saying...

"We should not support categories, they are said, metadata about code/objects in existing smalltalks is in a pretty sad sack state. We can and should do better."

I'd prefer to not support categories until we have a good general metadata system in place so that that can also be used for method categories etc.

James Ladd

Re: eclipse-plugin

Please lets try the eclipse plug-in and give feedback a.s.a.p

On Sun, Sep 25, 2011 at 9:38 AM, Sean T Allen <[hidden email]> wrote:

Not sure - id have to google.

- what is with "Categories"?

Categories can be added to a class definition. However, they currently get ignored.
There is a continuing discussion about what to do with categories, for example, turn them into Annotations.

What would be the benefit of having the categories turned to Annotations?

Categories are metadata. unfortunately smalltalk didn't have a good metadata system so categories were added as one type and then pragmas were (ab)used for many others. James and I have had a few conversations over the months that basically come down to my saying...

"We should not support categories, they are said, metadata about code/objects in existing smalltalks is in a pretty sad sack state. We can and should do better."

I'd prefer to not support categories until we have a good general metadata system in place so that that can also be used for method categories etc.

James Ladd

Re: eclipse-plugin

In reply to this post by Stefan Krecher

Please can we have some information in your wiki on how to install the Eclipse plug-in?
Good documentation is important to Redline.

On Tue, Sep 20, 2011 at 9:22 PM, Stefan Krecher <[hidden email]> wrote:

Hi,
i started with the eclipse-plugin: https://github.com/StefanKrecher/eclipse-redline-plugin

It is the very first preview but i wanted to release this early to be prepared for any wishes/ commets etc.
On the Wiki-Page are two screenshots: https://github.com/StefanKrecher/eclipse-redline-plugin/wiki

I'm using Xtext for parsing/ syntax highlightning/ code completition etc. So i have to reimplement parts of the parser, but Xtext is very powerful and we can use all the nifty features of the eclipse plugin development environment.

Currently it's only an Editor but it could be enhanced to an own "Perspective" with more Smalltalk-Development Tools, e.g.
- Class Hierarchy Browser (by switching to that perspective all .st-files would get parsed to an ecore-model)

- Debugger (it's already there)
- Transcript (a console, it's already there too)
- a Workspace (we could use something like the eclipse-scrapbook-pages for that)
This Perspective could be packaged as an own RCP-Application so we would have a standalone Smalltalk-IDE ...

Any comments/ wishes regarding the plugin are very welcome!

Some questions came into my mind while i was doing the plugin:
- could the redline Compile-class get enhanced to output real java-class-files? It would be great to have an own Smalltalk compiler/ builder in eclipse (that would be available for maven/ ant too)

- why didn't you use the "original" file-out-format?
- in Xtext the source will be parsed and you have access to an ecore-model of the whole Object-Tree - is that possible with the antlr3-model too? Would be good for implementing the CHB

- what is with "Categories"?

regards,
Stefan

Sebastian Nozzi-2

Re: eclipse-plugin

In reply to this post by James Ladd

> The original file out format is ugly and overly verbose when it comes to
> being edited by a human.

Just wanted to say that I absolutely love the source format.

James Ladd

Re: eclipse-plugin

So glad you like the source format.

My goal was to allow you to cut-n-paste from a current Smalltalk code browser and paste into
a file, adding the least amount of keystrokes in the process.

Putting a + / - seems like a win!

On Wed, Nov 9, 2011 at 6:40 AM, Sebastian Nozzi <[hidden email]> wrote:

> The original file out format is ugly and overly verbose when it comes to
> being edited by a human.

Just wanted to say that I absolutely love the source format.