May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Saving a Smalltalk Project

by Sean P. DeNigris

horrido wrote > what types of recent industrial projects youve come across that use > Smalltalk? One that immediately comes to mind is Lam Research: https://pharo.org/success/LAMRC ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 2, 2018

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

by Bernardo Ezequiel Contreras

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 < richard.sargent(a)gemtalksystems.com> wrote: > On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > 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 <marcus.denker(a)inria.fr>: >> >>> >>> >>> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> >>> 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.

May 2, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Todd Blanchard

OK, so I'm curious what hardware platforms you guys use for your "things"? Been doing things with Particle lately. Interested to try their new mesh offering. > On May 2, 2018, at 12:30 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon. > > Regards, > > EnvoyÃ© de mon iPad > >> Le 2 mai 2018 Ã 19:21, horrido <horrido.hobbies(a)gmail.com> a Ã©crit : >> >> 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 >> >

May 2, 2018

Re: [Pharo-users] Saving a Smalltalk Project

by Serge Stinckwich

If they are interested, we can get in touch. We are working on IoT for environmental monitoring and Iâm working in Cameroon. Regards, EnvoyÃ© de mon iPad > Le 2 mai 2018 Ã 19:21, horrido <horrido.hobbies(a)gmail.com> a Ã©crit : > > 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 >

May 2, 2018

Re: [Pharo-users] Iceberg Pharo6.1 on Microsoft Windows 7

by Ben Coman

On 2 May 2018 at 22:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Federico, > > I don't think compiling libgit in your box will solve the problem. I think > libgit is correctly compiled (otherwise you'd have another kind of error). > What you probably have is an ssh authentication error. > It would be nice if a test like the following could done, and if failed, some platform specific help information be provided - like that Windows needs "Custom" credentials. https://help.github.com/articles/testing-your-ssh-connection/ cheers -ben > > Could you try cloning using the https url provided by github instead? > > That should generally solve your problem. > > The other thing is that the version of iceberg in pharo 6 is really > outdated. We will soon backport the new version, I'll keep everybody posted > in this mailing list. > > Otherwise, you can test latest Pharo 7, with the latest Iceberg version. > The issue tracker is here: > > https://github.com/pharo-vcs/iceberg/issues > > Tx, > Guille > > On Wed, May 2, 2018 at 2:01 PM, Federico.Balaguer < > federico.balaguer(a)gmail.com> wrote: > >> Hello, >> >> I am trying to help some newbies to Smalltalk to use Iceberg on Pharo6.1 >> on >> Windows 7. >> I have a VirtualBox with Windows 7, I have the PharoLauncher installed >> from >> where I launch the Pharo 6.1 image. >> >> I cannot clone github repositories, I get a debugger: "LGit_GIT_ERROR: >> failed to get server certificate: The handle is in the wrong state for the >> requested operation" >> >> Do I have to compile libgit or libgit2 on the MSWindows virtual machine? >> >> thanks. federico >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > > > -- > > > > 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 > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

May 2, 2018

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

by Richard Sargent

On Wed, May 2, 2018 at 11:06 AM, Denis Kudriashov <dionisiydk(a)gmail.com> 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 <marcus.denker(a)inria.fr>: > >> >> >> > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> >> 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 >> > >

May 2, 2018

Saving a Smalltalk Project

by horrido

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

May 2, 2018

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

by Denis Kudriashov

Hi. Maybe #parseSourceCode would be better name for #parseTree. 2018-05-02 16:33 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> > 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 >

May 2, 2018

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

by Marcus Denker

> On 2 May 2018, at 17:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> (I sometimes wonder if we should not late-bind accesses to globals, that >> is, just compile them as message sends to the environment). > > That would be *great*. This is another one of those little lies where > "everything is a message send" and "late binding everything" breaks down, > like inlining boolean/undefined ops, that can confuse/shock newbies. It > probably made sense given the tech constraints at the time, but it would be > wonderful not only to increase the beauty and simplicity of the system, but > for the possibilities it opens up! > We should really push more in this directionâ¦ the problem is that is is actually not easy to convince especially the âdie hard Smalltalkersâ that a change like that is a good thingâ¦ Marcus

May 2, 2018

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

by Marcus Denker

> On 2 May 2018, at 17:34, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> the cached #ast is for one interestingâ¦ > > Thanks! Very interesting :) > In the end I think what I really would like to have is a Smalltalk with a âfirst classâ and persistent AST (or AST-like data structure)â¦ Another of these lies: âSmalltalk has textual source code, everything is an objectâ.. of course hard to pull odd with the memory and CPU resources of many decades ago, but today one could build that system for real! Marcus

May 2, 2018