Re: [Pharo-users] #ast vs. #parseTree

[Francisco Garau]

There is quite a difference between a compiler book using the AST acronym and a 
message with the #ast selector. 

Whoever starts reading a compiler book already knows about AST. We shouldn't 
assume the same about any Pharo developer. 

- Francisco


> On 3 May 2018, at 20:02, Guillermo Polito <guillermopol...@gmail.com> wrote:
> 
> I don't think so... any compiler book talks about ASTs using acronyms. 
> Acronyms are good when acronyms are good.
> 
>> Le jeu. 3 mai 2018 à 20:48, Esteban A. Maringolo <emaring...@gmail.com> a 
>> écrit :
>> +1 to avoid acronyms.
>> 
>> Esteban A. Maringolo
>> 
>> 2018-05-03 12:47 GMT-03:00 Francisco Garau <francisco.ga...@gmail.com>:
>>> I'd rather be also explicit in the name and avoid acronyms. 
>>> #newAbstractSyntaxTree and #cachedAbstractSyntaxTree
>>> 
>>> - Francisco
> -- 
>
> Guille Polito
> Research Engineer
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

Re: [Pharo-users] #ast vs. #parseTree

[Francisco Garau]

I'd rather be also explicit in the name and avoid acronyms. 
#newAbstractSyntaxTree and #cachedAbstractSyntaxTree

- Francisco


> On 3 May 2018, at 09:59, Guillermo Polito  wrote:
> 
> Ahh explicitness :)
> 
>> On Thu, May 3, 2018 at 10:56 AM, Tudor Girba  wrote:
>> How about: #newAst & #cachedAst?
>> 
>> Cheers,
>> Doru
>> 
>> 
>> > On May 3, 2018, at 9:30 AM, Guillermo Polito  
>> > wrote:
>> > 
>> > method newAst ?
>> > 
>> > On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras 
>> >  wrote:
>> > a "parse tree" is not equal to an "ast"(abstract syntax tree)
>> > but its difficult to find a name for an ast that is not cached.
>> > maybe 
>> > parsedAst
>> > parseAst
>> > 
>> > 
>> > 
>> > On Wed, May 2, 2018 at 3:28 PM, Richard Sargent 
>> >  wrote:
>> > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov  
>> > wrote:
>> > Hi.
>> > 
>> > Maybe #parseSourceCode would be better name for #parseTree. 
>> > 
>> > I've always found it good advice to avoid using a verb phrase to name 
>> > something which does not entail some kind of action.
>> > #parseSourceCode realy reads like something which would parse the source 
>> > code. #parseTree also has that effect, except for the lack of a tree to 
>> > parse.
>> > 
>> >  
>> > 
>> > 2018-05-02 16:33 GMT+03:00 Marcus Denker :
>> > 
>> > 
>> > > On 27 Apr 2018, at 21:36, Sean P. DeNigris  wrote:
>> > > 
>> > > Marcus Denker-4 wrote
>> > >> I will add comments…
>> > > 
>> > > I got confused by this again and created an issue:
>> > > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>> > > 
>> > > And then Peter Uhnak reminded me on Discord about this thread. I'm happy 
>> > > to
>> > > add the comments, but not sure I understand the issue well enough. IIUC 
>> > > #ast
>> > > is cached, but #parseTree is not. What I don't understand is the purpose 
>> > > of
>> > > this difference and when one would use one over the other.
>> > 
>> > the cached #ast is for one interesting for speed (that is, in situations 
>> > where you ask for it often).
>> > 
>> > The other use-case is if you want to annotate the AST and keep that 
>> > annotation around (till the next
>> > image save, but you can subscribe to ASTCacheReset and re-install the AST 
>> > in the cache after cleaning.
>> > (This is used by MetaLinks to make sure they survive image restart).
>> > 
>> > The last thing that it provides is that we do have a quite powerful 
>> > mapping between bytecode/text/context
>> > and the AST. Regardless how you navigate, you get the same object.
>> > 
>> > e.g. even this one works:
>> > 
>> > [ 1+2 ] sourceNode == thisContext method ast blockNodes first
>> > 
>> > > For example,
>> > > when, if ever, would a user want to access a CM's #ast (as opposed to
>> > > #parseTree) and could modifying it create problems?
>> > > 
>> > 
>> > Modification is a problem, yes.. code that wants to modify the AST without 
>> > making sure the compiledMethod is in sync later
>> > should use #parseTree. 
>> > 
>> > Code that does not modify the AST (or makes sure to compile it after 
>> > modification) is free to use #ast. 
>> > or if you want to annotate the AST (which is a modification, after all).
>> > 
>> > This is not perfect (not at all…) but the simplest solution to get (to 
>> > some extend) what you would have if the system would have
>> > a real persistent, first class AST…
>> > 
>> > To be improved. The ASTCache with it’s naive “lets just cache everything 
>> > till the next image save” was done with the idea to see
>> > when it would show that it is too naive… for that it worked amazingly well 
>> > till now.
>> > 
>> > Marcus
>> > 
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> > Bernardo E.C.
>> > 
>> > Sent from a cheap desktop computer in South America.
>> > 
>> > 
>> > 
>> > -- 
>> >
>> > Guille Polito
>> > Research Engineer
>> > 
>> > Centre de Recherche en Informatique, Signal et Automatique de Lille
>> > CRIStAL - UMR 9189
>> > French National Center for Scientific Research - http://www.cnrs.fr
>> > 
>> > Web: http://guillep.github.io
>> > Phone: +33 06 52 70 66 13
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "What is more important: To be happy, or to make happy?"
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

Re: [Pharo-users] loading Coral from SmalltalkHub

[Francisco Garau]

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


 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: 'accesing'.
].
myGen := Generator: 5.
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.

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.

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.

Re: [Pharo-users] loading Coral from SmalltalkHub

[Francisco Garau]

Hi Stef,

On 6 June 2015 at 06:55, stepharo steph...@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


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

 PillarInstructorcompileAllFileIn: 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?

[Point: Object |
| x y |
 [sign |
^ (x sign @ y sign)].
 [dotProduct: aPoint |
^ (x * aPoint x) + (y * aPoint y)].
]


 On 4 June 2015 at 20:08, stepharo steph...@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

Re: [Pharo-users] loading Coral from SmalltalkHub

[Francisco Garau]

Thanks Stefan.

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

On 4 June 2015 at 20:08, stepharo steph...@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

Re: [Pharo-users] Self-removing announcement subscription?

[Francisco Garau]

Just a thought, but wouldn't it better to have a method called 
#subscribeOnce:do: and let it handle the subscription removal?

- Francisco


 On 25 Oct 2014, at 13:42, Jan B. blizn...@fit.cvut.cz wrote:
 
 Hi all
 
 Today I come with a question regarding announcements.
 I would like to make announcement subscription which would remove itself
 after first use.
 Something like...
 
 anObject announcer 
subscribe: TRMouseDragEnd 
do: [ :event | 
self thisMethodWith: differentParameters. 
anObject announcer removeSubscription: ...this one... ].
 
 All I was able to do is write there
 anObject announcer unsubscribe: self.
 which somehow works, but this instance could have multiple subscriptions and
 it would remove even those I don't want to remove, I need to remove only
 this specific one...
 
 Jan
 
 
 
 --
 View this message in context: 
 http://forum.world.st/Self-removing-announcement-subscription-tp4786622.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
 

[Pharo-users] [OT] Block challenge

[Francisco Garau]

There is a missing line that makes the below evaluate to true. Can you spot
it?

[
| pointClass setX setY squared   |
pointClass  :=
[ | x y  |
setX := [ :aNumber | x := aNumber ].
setY := [ :aNumber | y := aNumber ].
squared := [ (x * x) + (y * y) ].
#end.
].
setX value: 3.
setY value: 4.
squared value.
] value = 25