loading Coral from SmalltalkHub

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

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 :

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

On 4 June 2015 at 20:08, stepharo <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
<[hidden email]> wrote:
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
<[hidden email]> 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.

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?