Thanks Stefan. I am playing with the Coral image downloaded from the CI site. On 4 June 2015 at 20:08, stepharo <stepharo@free.fr> wrote:

Thanks Stefan

Francisco there is nothing new in Coral we got stalled again because we focused on pillar.

Stef

Le 4/6/15 11:20, Stephan Eggermont a écrit :

On 04-06-15 01:46, Francisco Garau wrote:

...

...

I've tried loading Coral by following the below instructions in its website <http://rmod.lille.inria.fr/coral/getting-started.html> but they failed when trying to load Readline.

Gofer new url: 'http://ss3.gemstone.com/ss/coral'; package: 'ConfigurationOfCoral'; load.

ConfigurationOfCoral loadDevelopment.

Yes, that is an old configuration. I've updated it on smalltalkhub: PharoExtras/Coral, but that was before the release of Pharo4. CDLM, Damien C and Stef have worked on it this year.

As PetitParser still uses the #stable and #development style of symbolic naming, instead of #release5.1, things can break when a new version of Moose is released.

It seems the project was moved to Smalltalk Hub

...

(http://smalltalkhub.com/#!/~PharoExtras/Coral/)

What expressions should I evaluate in a Pharo5 image to get the latest Coral project loaded.

I've added a Pharo 5 build to https://ci.inria.fr/pharo-contribution/job/Coral/ The 4 and 5 builds are green

I've also added a Pharo4 and Pharo5 build to OSProcess https://ci.inria.fr/pharo-contribution/job/OSProcess/ The 4 and 5 builds each have 3 failures

It is possible that some changes to the parser are needed due to improvements in PetitParser. I ran into that last time I tried, and forgot whether that got fixed.

Stephan

On 6 Jun 2015 1:56 pm, "stepharo" <stepharo@free.fr> wrote:

Le 5/6/15 21:37, Francisco Garau a écrit :

...

Thanks Stefan.

I am playing with the Coral image downloaded from the CI site.

ok now again pay attention. The syntax is not important and stable. What is more important is

Coral should let - us interactively access and define environment varibales - write and ***debug*** OS scripts - publish these scripts

Here is typical session I want.

you have a coral scripts - no method - just a bunch of expression - you get a bug - you relaunch the script -db - and you get debugger you fix the script - then your script is regenerate

Now if you need to define a method then you define a class ie PillarInstructor and a couple of method but they should be ***normal***

method and normal class

(just with a better syntax that the ugly code chunk delimiter) and this is why I proposed

PillarInstructor>>compileAllFileIn: aFS [ gkjgkjgkjg kjgkjgkgkgj ]

Stef

I like that syntax. Cheers -ben

...

On 4 June 2015 at 20:08, stepharo <stepharo@free.fr> wrote:

...

Thanks Stefan

Francisco there is nothing new in Coral we got stalled again because we

focused on pillar.

...

...

Stef

Le 4/6/15 11:20, Stephan Eggermont a écrit :

...

On 04-06-15 01:46, Francisco Garau wrote:

...

I've tried loading Coral by following the below instructions in its website <http://rmod.lille.inria.fr/coral/getting-started.html> but

they

...

...

...

failed when trying to load Readline.

Gofer new url: 'http://ss3.gemstone.com/ss/coral'; package: 'ConfigurationOfCoral'; load.

ConfigurationOfCoral loadDevelopment.

Yes, that is an old configuration. I've updated it on smalltalkhub: PharoExtras/Coral, but that was before the release of Pharo4. CDLM, Damien C and Stef have worked on it this year.

As PetitParser still uses the #stable and #development style of symbolic naming, instead of #release5.1, things can break when a new version of Moose is released.

...

It seems the project was moved to Smalltalk Hub (http://smalltalkhub.com/#!/~PharoExtras/Coral/)

What expressions should I evaluate in a Pharo5 image to get the latest Coral project loaded.

I've added a Pharo 5 build to https://ci.inria.fr/pharo-contribution/job/Coral/ The 4 and 5 builds are green

I've also added a Pharo4 and Pharo5 build to OSProcess https://ci.inria.fr/pharo-contribution/job/OSProcess/ The 4 and 5 builds each have 3 failures

It is possible that some changes to the parser are needed due to improvements in PetitParser. I ran into that last time I tried, and forgot whether that got fixed.

Stephan

On Sat, Jun 6, 2015 at 5:47 PM, Francisco Garau <francisco.garau@gmail.com> wrote:

...

I am playing with the Coral image downloaded from the CI site.

ok now again pay attention. The syntax is not important and stable. What is more important is

I understand what you are saying and it's not my intention to push the syntax experiments into Coral. I am just using the existing infrastructure to play a bit with the latest Pharo and see if the ideas I've got could work in practice. As Ben says, it's a itch I need to scratch.

...

Coral should let - us interactively access and define environment varibales - write and ***debug*** OS scripts - publish these scripts

Here is typical session I want.

you have a coral scripts - no method - just a bunch of expression - you get a bug - you relaunch the script -db - and you get debugger you fix the script - then your script is regenerate

Thanks for the explanation. It'd be nice to add this into the Coral website.

...

Now if you need to define a method then you define a class ie PillarInstructor and a couple of method but they should be ***normal*** method and normal class (just with a better syntax that the ugly code chunk delimiter) and this is why I proposed

PillarInstructor>>compileAllFileIn: aFS [ gkjgkjgkjg kjgkjgkgkgj ]

The syntax changes I am thinking about would bring together block and method definitions. I would have thought it is important for your modularity efforts to have a full syntax. Otherwise, how would you be compiling code into a minimal image that hasn't got any UI module?

Your ideas below regarding method definition is interesting, but this class definition seems problematic.

[Point: Object | | x y |

I don't know your Smalltalk background since you are new to the list, so I hope I'm not telling you how to suck eggs, but just checking you know that the class definition is not compiler syntax but a plain message send. Try where you normally define a class to select the definition and "debug it". Also using the normal class definition message-send means you don't have to come up with special compiler syntax for using class variables, slots, traits, etc.

[sign | ^ (x sign @ y sign)].

[dotProduct: aPoint | ^ (x * aPoint x) + (y * aPoint y)]. ]

I can see how that might work technically with the compiler able to recognise the lack of preceding colon to distinguish a method name, but I am thinking: * its a very fine distinction for humans reading code * dropping a colon is very easy * it may lead to ambiguous fail-late errors (better to fail-early) Also *needing* to nest method definitions within the class definition seems constraining. It would be nice for methods to be able to be defined in any order. Consider a common use case where several script files are joined together which each define extensions to the same class. The above points are dealt with by the Class>>method" syntax Stef describes. A really important aspect of this is that its already a widely used convention in documentation. Now pushing that inside the block may be interesting. [ Point>>sign | ^(x sign @ y sign) ]. [ Point>>dotProduct :aPoint | ^ (x * aPoint x) + (y * aPoint y). ] [ Point>>min: aMin max: aMax | ^ (self min: aMin) max: aMax ] However a block that is not assigned to a variable is just thrown away, so possibly a hypothetical message like #define might need to be sent to the block. [ Point>>sign | ^(x sign @ y sign) ] define. cheers -ben

On Sun, Jun 7, 2015 at 7:54 PM, Francisco Garau <francisco.garau@gmail.com> wrote:

Hi Ben,

Thanks for your comments. There's another aspect of the syntax changes I am playing with. The intention is to make more evident the relationship between objects and closures as they could be implemented in terms of each other (see below article from Vassily on the subject).

http://live.exept.de/doc/online/english/programming/humor.html

I'm lost. It seems to me that Vassily's response is a contrived example to get rid of Objects. The url does indicate humour.

...

Your ideas below regarding method definition is interesting, but this class definition seems problematic.

...

[Point: Object | | x y |

I've removed passing the superclass as an argument, that was a mistake. Now a more complete example would be written as:

[Generator: initialValue | | currentValue | currentValue := initialValue. [reset | currentValue := 0 ]. [next | currentValue := currentValue + 1. ^currentValue]. reset category: 'accessing'. next category: 'accessing'. ]. myGen := Generator: 5.

It seems this is how you are creating an instance, and you would be constrained to have only one way to create an instance. How would you handle having two ways to create an instance. For example... Point class >> r:degrees: Point class >> x:y:

myGen next = 6. myGen reset = 0. myGen next = 1.

To highlight that the blocks defining the methods wouldn't be thrown away, I've added a couple of categorization methods.

When are these categorization methods executed? It seems that the "currentValue := initialValue" line might meant be executed each time an instance is created. In that case the two #category message sends would seem to also be sent at each instance creation ???

Notice how close is that from a valid implementation using plain blocks in regular Smalltalk. Almost identical if you ignore the method lookup resolution which is obviously missing from blocks.

Sorry its not obvious. I don't understand that last statement. What would this missing part look like? Maybe part of the problem is I can't help reading the above syntax as blocks, even if they are named blocks aka methods. Sorry its just how I'm wired, and I haven't even been doing Smalltalk long. I found the following example really hard to follow, and I could not do it just reading it. I had to evaluate it piecemeal and inspect each step. Would such a thing ever be used in practice? It strikes me as failing Brian Kernighan's rule: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." So I feel its not a good justification to replace this with your new syntax. Do you have another?

generatorClass := [:initialValue | | currentValue | currentValue := initialValue. Array with: [ currentValue := 0 ] with: [ currentValue := currentValue + 1 ]. ].

myGen := generatorClass value: 5. myGen last value = 6. myGen first value = 0. myGen last value = 1.