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

[Guillermo Polito]

method newAst ?

On Wed, May 2, 2018 at 11:03 PM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> 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  gemtalksystems.com> 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-Differen
 ce-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

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

[Marcus Denker]

> On 2 May 2018, at 14:09, Marcus Denker  wrote:
> 
> 
> 
>> On 26 Apr 2018, at 09:28, Guillermo Polito  wrote:
>> 
>> Hi,
>> 
>> It looks you got bit by this issue:
>> 
>> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well-with-Undeclareds
>> 
>> It's not particular to Epicea. There should be a better management of 
>> Undeclareds in general in all Pharo.
>> 
> 
> It can be fixed by moving the binding to undeclared in #removeFromSystem: 
> 
> This is done by adding
> 
>  Undeclared declare: self name asSymbol from: Smalltalk globals.
> 
> before the "forgetClass: self logged:" line.
> 
> What we need to do in addition: Only do that when the class is referenced. 
> #isUsedClass: does that, but it does integrate over all methods in the system.
> 

I did a PR:

https://github.com/pharo-project/pharo/pull/1281 



Marcus

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

[Tudor Girba]

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?"

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

[Guillermo Polito]

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 <
> vonbecm...@gmail.com> 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  gemtalksystems.com> 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

[Pharo-users] Pharo70 session start and silent failures

[Holger Freyther]

I am facing a problem with the new SessionManager>>#snapshot:andQuit: code. I 
have had plenty Pharo70 images that didn't restore anymore as the code is 
waiting for the "wait" semaphore. For sure it is something my code is doing but 
could anyone think of ways to make it more robust and handle failures more 
gracefully? My main concerns are:

* When the failure becomes noticeable it is too late. :(
* It fails silently. Maybe WorkingSession>>#runStartup: shouldn't rely on the 
UIManager doing the right thing (before the UI was fully initialized?)
* Debugging is hard, there is no indication of why it broke, and getting to the 
situation of breakage takes a bit of time (installing the baseline..).

holger

Re: [Pharo-users] Pharo70 session start and silent failures

[Sean P. DeNigris]

Holger Freyther wrote
> I have had plenty Pharo70 images that didn't restore anymore…

+1. I think it has been related to errors in my startup code e.g. classes
renamed/removed since 6.1, but not sure.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Sean P. DeNigris]

Guillermo Polito wrote
> Ahh explicitness :)

+1!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [Ann] Iceberg 0.7.3

[Sven Van Caekenberghe]

Hi Guillermo (et al),

I finally found the time to test this new setup and I found it much easier and 
quite straightforward to make a PR.

The new approach, with the simpler UI and lots more dialogs/explanations (and 
the glossary) is really well done. It felt much better, much higher quality. I 
am sure we are on the right track now.

Thanks for all the hard work.

Sven

> On 25 Apr 2018, at 10:27, Guillermo Polito  wrote:
> 
> Hi all,
> 
> We just introduced Iceberg 0.7.3 into Pharo. This new version solves several 
> issues people had when contributing to Pharo in general and others. I've made 
> a screencast on how to contribute to Pharo, and added some tutorial and 
> glossary in Iceberg's wiki.
> 
> Below the links and the changes log.
> 
> Thanks for making your issue reports ^^. We will schedule a backporting to 
> Pharo6.1 in a couple of weeks, once we have another iteration.
> 
> Cheers,
> Guille
> 
> # Contribute to Pharo with Iceberg 0.7.3
> 
> - wiki page: 
> https://github.com/pharo-vcs/iceberg/wiki/Contribute-to-Pharo-with-Iceberg-0.7.3
> 
> - Screencast: 
> https://www.youtube.com/watch?v=PK2yCu2rWCc&feature=youtu.because
> 
> This screencast shows how to use Iceberg 0.7.3 to contribute to latest Pharo 
> 7, by cloning from scratch your own (potentially outdated) clone.
> 
> This video will guide you through:
>  - solve the "Missing local repository" by cloning
>  - solve the "Fetch required" that appears because the fork is out of date
>  - solve the "Detached working copy" by creating a new branch
>  - use the pharo plugin to create an issue branch
>  - make some changes, commit them and push them to your fork
>  - make a pull request
> 
> If you already have a clone, you can just import an existing repository from 
> your disk. The rest of the instructions should be the same.
> 
> If you don't have a fork, create one before doing anything else.
> 
> New videos to come with more explanations.
> 
> # Iceberg Glossary
> 
> https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary
> 
> # 0.7.3 ChangesLog
> 
>   • #693: fixing problem when the announcement of changes in a package is 
> nil. (bug, important)
>   • #682: update update script (Pharo6-backport)
>   • #681: Author name is not correctly decoded (UI, enhancement)
>   • #680: Repair actions dialog should explain the situation (UI, 
> enhancement, important)
>   • #679: Create branch repair action should show create branch from 
> issue if available (Pharo plugin, UI)
>   • #678: Iceberg does not correctly recognize packages (bug, important)
>   • #677: Unknown commit can only be solved with repair action (Model, 
> bug, important)
>   • #676: Unknown commit state is not properly shown (UI, bug, important)
>   • #667: Merging branches with file deletion doesn't seem possible (bug, 
> important, merge)
>   • #666: Iceberg sometimes add a $ to commit message (Model, bug)
>   • #662: The Pharo plugin has to do the fetch only if required. (Pharo 
> plugin, enhancement)
>   • #660: Add a star badge in the push button in case of a new branch ()
>   • #658: Progress Bar during checkout of Repository. (UI, enhancement)
>   • #657: Confusing UI: Ghost Test maybe should be default? (UI, 
> enhancement)
>   • #656: Typo in Progress Bar (UI, bug)
>   • #651: When pushing a new branch the list of commit is empty (UI, bug)
>   • #650: "Create new branch from issue" is leaving image in detached 
> working copy state ()
>   • #649: The VM is crashing when trying to use Iceberg from a saved 
> image (bug)
>   • #645: IceLibgitRepository should use "utilities" protocol instead of 
> "utils" (clean up)
>   • #644: Unnecessary temp in 
> IceTipGitHubRepositoryPanel>>#getGitHubRepository" (clean up)
>   • #643: LGit_GIT_ERROR: error authenticating: no auth sock variable 
> loading a Tonel based baseline dependency in smalltalkCI (bug, important)
>   • #639: Create pull request fails if branch has not been pushed (Github 
> plugin, bug)
>   • #636: The pull button should have a star badge when it has no 
> upstream (UI, enhancement, important)
>   • #634: Travis is not building Pull Requests (CI, bug, important)
>   • #624: add "add remote" to remote picking on pull/push browsers 
> (enhancement)
>   • #610: Fix for issue #608 and #607. (clean up)
>   • #609: New branch repair action does not refresh dirty packages (UI, 
> bug)
>   • #583: Creating a tonel project does not commit the properties file 
> (Model, bug)
>   • #542: Bug during commit of a new package (Model, bug)
> 
> 
> -- 
>
> 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

[Pharo-users] [Ann] Iceberg 0.7.5

[Guillermo Polito]

Time for the weekly Iceberg update.

Iceberg 0.7.5. will be in the next Pharo build.
Thanks to all brave users, issue reporters and contributors :).

Key improvements:
 - Several improvements in metacello integration. (see #625, #664, #688 +
more tests)
 - For those using CI, we think this release will also fix
https://github.com/pharo-vcs/iceberg/issues/643

Infrastructure improvements:
 - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits
   * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795
 - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits
   * https://travis-ci.org/pharo-vcs/iceberg/builds/374433920
 - In the next release we plan to do a pass on 64 bits

** Pharo 6.1 backport **
 - We plan to backport this version to Pharo 6.1
 - Cyril has been using the development version of Iceberg on Pharo 6.1 for
a couple of weeks now.
 - This plus the green CI encourages us to backport to Pharo 6.1

Detailed ChangesLog:

#625 Non explicit error while loading a project
#758 [Regression] Repair action clone is not setting pharo repository
#756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of IceTipURLLabelMorph
did not understand #addEmphasis:)
#749 Adding repair actions to the code subdirectory missing problem
#655 Rename extension method buildToolbarItem of CommandActivator
#755 Extracting the URL label behavior as a component that we can reuse
#468 Commiting via Iceberg does not commit package removal
#750 Add possibility to see current commit in Repositories/Package view
#754 Showing and coping the Commit ID
#753 Create branch dialog layout is broken
#664 Package wrongly shown with "uncommited changes" status
#752 Add "invalid ssh"
#747 Cloning a Git repository should change the path with the project name.
#738 Remove "pharo" Repository with "also remove from filesystem" gives
error
#746 Make tests run on pharo 6
#735 Issue while registering a new project on Pharo 6.1
#733 Add license file
#740 Fogbugz panel: Improve label, focus order and layout
#549 IceRestoreRepositoryModel should have a class comment
#688 Duplicated project error when loading in a fresh image

Enjoy,
Guille in behalf of all people that contributed :)

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg 0.7.5

[Norbert Hartl]

Will it be too hard to do 6.2? I encourage the backport but it will break stuff 
which is also really annoying.

Norbert


> Am 03.05.2018 um 17:16 schrieb Guillermo Polito :
> 
> Time for the weekly Iceberg update.
> 
> Iceberg 0.7.5. will be in the next Pharo build.
> Thanks to all brave users, issue reporters and contributors :).
> 
> Key improvements: 
>  - Several improvements in metacello integration. (see #625, #664, #688 + 
> more tests)
>  - For those using CI, we think this release will also fix 
> https://github.com/pharo-vcs/iceberg/issues/643 
> 
> 
> Infrastructure improvements:
>  - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits
>* https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 
> 
>  - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits
>* https://travis-ci.org/pharo-vcs/iceberg/builds/374433920 
> 
>  - In the next release we plan to do a pass on 64 bits
> 
> ** Pharo 6.1 backport **
>  - We plan to backport this version to Pharo 6.1
>  - Cyril has been using the development version of Iceberg on Pharo 6.1 for a 
> couple of weeks now.
>  - This plus the green CI encourages us to backport to Pharo 6.1
> 
> Detailed ChangesLog:
> 
> #625 Non explicit error while loading a project
> #758 [Regression] Repair action clone is not setting pharo repository
> #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of IceTipURLLabelMorph 
> did not understand #addEmphasis:)
> #749 Adding repair actions to the code subdirectory missing problem
> #655 Rename extension method buildToolbarItem of CommandActivator
> #755 Extracting the URL label behavior as a component that we can reuse
> #468 Commiting via Iceberg does not commit package removal
> #750 Add possibility to see current commit in Repositories/Package view
> #754 Showing and coping the Commit ID
> #753 Create branch dialog layout is broken
> #664 Package wrongly shown with "uncommited changes" status
> #752 Add "invalid ssh"
> #747 Cloning a Git repository should change the path with the project name.
> #738 Remove "pharo" Repository with "also remove from filesystem" gives error
> #746 Make tests run on pharo 6
> #735 Issue while registering a new project on Pharo 6.1
> #733 Add license file
> #740 Fogbugz panel: Improve label, focus order and layout
> #549 IceRestoreRepositoryModel should have a class comment
> #688 Duplicated project error when loading in a fresh image
> 
> Enjoy,
> Guille in behalf of all people that contributed :)

[Pharo-users] [ANN] ChartJs for Seaside v1.0.0

[Cyril Ferlicot D.]

Hi!

I'm happy to announce the release v1.0.0 of ChartJs for Seaside.

This is a binding of ChartJs v1. We did not got the time to bind v2 of
ChartJs.

v1.0.0 includes:
Creation of 1D charts
Creation of 2D charts
Creation of Boxplots
Callbacks on 1D and 2D charts
Tooltips on charts
Style customization
...

The project can be found at: https://github.com/DuneSt/ChartJs

Demo at: https://demos.ferlicot.fr/ChartJs

-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-users] [ANN] PrismCodeDisplayer for Seaside v1.0.0

[Cyril Ferlicot D.]

Hi!

We just finished the release v1.0.0 of PrismCodeDisplayer for Seaside.

Prism (https://github.com/PrismJS/prism/) is a lightweight, robust,
elegant syntax highlighting library.

The Seaside binding allows to:
Display code
See line numbers
Select code and act on the selection
Customize the style of some text intervals
Add links to text intervals
Add a search feature
Have a dynamic loading of the text content
Copy the text content
Have a minimap

Project can be found at: https://github.com/DuneSt/PrismCodeDisplayer

Demo at: https://demos.ferlicot.fr/PrismDemo

-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-users] [ANN] Heimdall logging manager for Seaside v1.0.0

[Cyril Ferlicot D.]

Hi!

Guillaume Larcheveque begun a simple login manager for Seaside.

I just finished to port it to github and we released the v1.0.0.

It is still experimental and help is welcomed.

Project can be found at: https://github.com/DuneSt/Heimdall

-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg 0.7.5

[Guillermo Polito]

On Thu, May 3, 2018 at 5:25 PM, Norbert Hartl  wrote:

> Will it be too hard to do 6.2? I encourage the backport but it will break
> stuff which is also really annoying.
>

@esteban? :)

I'd really like to have that or a 6.1.1, a way to actually differentiate
them...


>
> Norbert
>
>
> Am 03.05.2018 um 17:16 schrieb Guillermo Polito  >:
>
> Time for the weekly Iceberg update.
>
> Iceberg 0.7.5. will be in the next Pharo build.
> Thanks to all brave users, issue reporters and contributors :).
>
> Key improvements:
>  - Several improvements in metacello integration. (see #625, #664, #688 +
> more tests)
>  - For those using CI, we think this release will also fix
> https://github.com/pharo-vcs/iceberg/issues/643
>
> Infrastructure improvements:
>  - In 0.7.4 we introduced in the build tests againt pharo 6.1 and 64 bits
>* https://travis-ci.org/pharo-vcs/iceberg/builds/372408795
>  - In 0.7.5 all iceberg tests run green on Pharo 6.1 32 bits
>* https://travis-ci.org/pharo-vcs/iceberg/builds/374433920
>  - In the next release we plan to do a pass on 64 bits
>
> ** Pharo 6.1 backport **
>  - We plan to backport this version to Pharo 6.1
>  - Cyril has been using the development version of Iceberg on Pharo 6.1
> for a couple of weeks now.
>  - This plus the green CI encourages us to backport to Pharo 6.1
>
> Detailed ChangesLog:
>
> #625 Non explicit error while loading a project
> #758 [Regression] Repair action clone is not setting pharo repository
> #756 Iceberg dev-0.7 is broken in Pharo6.1 (Instance of
> IceTipURLLabelMorph did not understand #addEmphasis:)
> #749 Adding repair actions to the code subdirectory missing problem
> #655 Rename extension method buildToolbarItem of CommandActivator
> #755 Extracting the URL label behavior as a component that we can reuse
> #468 Commiting via Iceberg does not commit package removal
> #750 Add possibility to see current commit in Repositories/Package view
> #754 Showing and coping the Commit ID
> #753 Create branch dialog layout is broken
> #664 Package wrongly shown with "uncommited changes" status
> #752 Add "invalid ssh"
> #747 Cloning a Git repository should change the path with the project name.
> #738 Remove "pharo" Repository with "also remove from filesystem" gives
> error
> #746 Make tests run on pharo 6
> #735 Issue while registering a new project on Pharo 6.1
> #733 Add license file
> #740 Fogbugz panel: Improve label, focus order and layout
> #549 IceRestoreRepositoryModel should have a class comment
> #688 Duplicated project error when loading in a fresh image
>
> Enjoy,
> Guille in behalf of all people that contributed :)
>
>
>


-- 



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

[Pharo-users] [ANN] TelescopeCytoscape for Seaside v1.0.0

[Cyril Ferlicot D.]

Hi,

Telescope is an engine for efficiently creating meaningful
visualizations. It allow users to create models of visualizations and to
render them via connectors to visualization frameworks.

Until now, it was hosted on SmalltalkHub and we just migrated it to Github.

https://github.com/TelescopeSt/Telescope

We also finished the v1.0.0 of the CytoscapeJs
(http://js.cytoscape.org/) Telescope connector. It is build on top of
Seaside to use visualizations as components.

You can find the project at:
https://github.com/TelescopeSt/TelescopeCytoscape

And a demo at: https://demos.ferlicot.fr/TelescopeDemo

-- 
Cyril Ferlicot
https://ferlicot.fr

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] #ast vs. #parseTree

[Esteban A. Maringolo]

+1 to avoid acronyms.

Esteban A. Maringolo

2018-05-03 12:47 GMT-03:00 Francisco Garau :

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

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

[Guillermo Polito]

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  a
écrit :

> +1 to avoid acronyms.
>
> Esteban A. Maringolo
>
> 2018-05-03 12:47 GMT-03:00 Francisco Garau :
>
>> 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] [Voyage] How to declare an instance variable as transient?

[Alejandro Infante]

Hi Sergio,

You have to add a method to the class side with a pragma. In my case, I wanted 
to set the instance variable “questionReferences” to transient.

myClass class>>mongoQuestionReferences


^VOTransientDescription new
attributeName: 'questionReferences';
yourself

Cheers!
Alejandro

> On Apr 30, 2018, at 3:21 PM, sergio ruiz  wrote:
> 
> Hi, all..
> 
> I have an instance variable that I don’t want to save as part of the full 
> project. I was wondering how to set this up.
> 
> The documentation says:
> Lastly, attributes can be excluded from storage (and hence retrieval) by re- 
> turning a VOMongoTransientDescription instance as the attribute descrip- tor.
> 
> But I am not sure how to set this up in my class.
> 
> thanks! 
> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0 
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com 
> http://www.twitter.com/sergio_101 
> http://www.facebook.com/sergio101 

Re: [Pharo-users] [Voyage] How to declare an instance variable as transient?

[sergio ruiz]

ah! thanks!


On May 3, 2018 at 5:06:18 PM, Alejandro Infante (alejandroinfant...@gmail.com) 
wrote:

Hi Sergio,

You have to add a method to the class side with a pragma. In my case, I wanted 
to set the instance variable “questionReferences” to transient.

myClass class>>mongoQuestionReferences

^VOTransientDescription new
attributeName: 'questionReferences';
yourself

Cheers!
Alejandro

On Apr 30, 2018, at 3:21 PM, sergio ruiz  wrote:

Hi, all..

I have an instance variable that I don’t want to save as part of the full 
project. I was wondering how to set this up.

The documentation says:
Lastly, attributes can be excluded from storage (and hence retrieval) by re- 
turning a VOMongoTransientDescription instance as the attribute descrip- tor.

But I am not sure how to set this up in my class.

thanks! 



peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

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  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  a 
>> écrit :
>> +1 to avoid acronyms.
>> 
>> Esteban A. Maringolo
>> 
>> 2018-05-03 12:47 GMT-03:00 Francisco Garau :
>>> 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

[Ramon Leon]

On 05/03/2018 12:02 PM, Guillermo Polito wrote:
I don't think so... any compiler book talks about ASTs using acronyms. 
Acronyms are good when acronyms are good.


Boo, acronyms bad, virtually always. Jargon is awful when speaking and 
awful when Smalltalk'ing, use words, they're not in short supply.


--
Ramon Leon

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

[Sven Van Caekenberghe]

> On 3 May 2018, at 10:56, Tudor Girba  wrote:
> 
> How about: #newAst & #cachedAst?

Best suggestion yet. +1

> 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?"
> 
> 

Re: [Pharo-users] Saving a Smalltalk Project

[Clément Bera]

That is the answer I would give:

Biggest Smalltalk community in Silicon valley is likely the Lam Research
one (dozens of devs). On my blog post talking about Smalltalk, I have 2k
views per Smalltalk community-wide audience post, so the community is at
least that big. Smalltalk conferences (Smalltalks and Esug) have usually
around 200 attendees.

To hire Smalltalk developers, a job offer mail through esug or pharo
mailing list is one of the best way to get people to apply, other solutions
include giving a 10 min talk at ESUG (Europe) or Smalltalks (Argentina)
conference and say loud and clear you are hiring (people may be able to
move to other countries). Getting a few developers should not be that hard
if you accept remote positions.

Migrating from Squeak to Pharo is something to discuss with the developers
you hire, things like IoT and Magma DB support might not be easy to port,
so it is difficult to tell with the little information provided. Pharo's
community is likely the easiest to hire new Smalltalk developers though,
and you can check the Pharo consortium website for support and success
stories to ease communication with your investors and partners.



On Wed, May 2, 2018, 20:21 horrido  wrote:

> I received the following message:
>
> *We started off doing a small project in conservation in South Africa that
> involved tracking Rhinos in a remote GPS denied environment and ended up
> with some impressive building blocks for a Big Data Platform for IoT. The
> platform includes its own GIS subsystem and parts of an Expert System.
>
> Due to the choice made by my business partner and handful of contractors
> the
> platform ended up being built in Smalltalk on Squeak  VM and the Magma
> Object Database.
>
> We now believe we may have the beginning of a commercial platform however
> its notoriously difficult to find Smalltalk developers so I am in half
> minds
> to migrate to a platform which uses a more mainstream language (Java /
> Python) as I have been getting some strange reactions from Angel Investors
> /
> VCs and mainstream developers.
>
> ...
>
> I wanted to ask you if you have information on how big the Smalltalk
> community is and whether its better to migrate to Pharo from Squeak and
> what
> types of recent industrial projects youve come across that use Smalltalk?
>
> Also I wondered if you know of any active smalltalk group in Silicon Valley
> and what are the best forums for professional SmallTalk development.*
>
> I would very much like to save their project as a Smalltalk project. The
> principal issue seems to be finding enough Smalltalk developers. I don't
> know if they need on-site developers or if remote developers can pass
> muster. I strongly suspect the former.
>
> How hard would it be to find Smalltalkers willing to work in Silicon
> Valley,
> or South Africa?
>
> What is the best response to this person? Thanks.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>