[Pharo-users] Re: SmaCC: Adding conditions to production rules

[Thierry Goubier]

Dear Konrad,

the answer to your question is : it isn't pssoble as is in SmaCC (it
breaks the underlying tcomputation heory).

In practice, there are various ways to do so, depending on the kind of
grammar you are building (and whether or not your grammar has
conflicts). Cleanest way is to do a check at the end of the action
(check that all  are equal in the action, reject if
this is not the case). You can use, if your grammar has conflicts, the
GLR mode and select the right interpretation or reject the input.

Another approach is to change the state of the scanner based on your
actions, and so trigger the right production rule by emitting
different tokens for example (such as a  following
an . Again, different ways to do that; SmaCC offers an
easy path to scanner specialisation that is fully compatible with
SmaCC code generation (i.e. no fear to loose your customisation).

Hope this helps,

Thierry

Le lun. 23 mai 2022 à 01:01, Konrad Hinsen
 a écrit :
>
> Hi everyone,
>
> I am stuck with a problem in SmaCC (of which I am a newbie user). Hoping
> for suggestions from experts, any kind of pointer is welcome!
>
> I have a production rule for infix operators:
>
>   Term
> : NonInfixTerm 'arg' ( 'opName' NonInfixTerm 'arg') * 
> {{InfixOpTerm}}
> | NonInfixTerm
> ;
>
> According to the syntax rules of my language, infix terms are valid only
> if all s are equal. Otherwise parentheses must be used to
> disambiguate, as the language has no precedence rules.
>
> How can I do this with SmaCC? I don't see how I could do it using the
> basic features, but maybe with some tweaking on the Pharo side.
>
> Thanks in advance,
>   Konrad.

Re: [Pharo-users] shape file reading

[Thierry Goubier]

Hi Hans,

Roassal has support for loading OSM raw data and OSM tiles (map
backgrounds) (WGS84 projection). See
https://www.youtube.com/watch?v=6zoGIsQaGUo&t=429s. We've also
experimented with animations as well:
https://www.youtube.com/watch?v=sMB7DG-lbiU; we've also tried in the
past to work out of GRASS-produced rasters for complex geographic
analysis, such as runoff flooding, projected on osm tiles.

Regards,

Thierry

Le ven. 5 juin 2020 à 14:27, Baveco, Hans  a écrit :
>
> Well, it appears that simple direct downloading does not download the real 
> shapefile. Taking care to actually get a shapefile, the result loads without 
> problems.
>
> ne_110m_populated_places.shp is a PointShape with 243 shapes (points). If you 
> display it on a Form (#displayMorphic) you won’t see much (243 hardly visible 
> dots).
>
>
>
> With an application for vector graphics (Roassal?) that can read & display 
> the vector data we would get much nicer maps...
>
>
>
> Hans
>
>
>
> From: Baveco, Hans 
> Sent: vrijdag 5 juni 2020 12:44
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] shape file reading
>
>
>
> Hi Hernan
>
>
>
> I downloaded this shapefile directly via the browser. Indeed it won’t load, 
> the type of shape file returned is
>
> self longAt: 33 bigEndian: false -> 577660194
>
>
>
>
>
> where it should have answered an Integer between 0 and 31
>
>
>
> shapeType
>
>  "position 32, Integer between 0 and 31, Little Endian"
>
>
>
>  ^shpBytes longAt: 33 bigEndian: false
>
>
>
>
>
> No idea what could be the cause – apparently the header of the file (the 
> first 100 bytes) is not ok...
>
>
>
> Hans
>
>
>
>
>
>
>
>
>
> You mean some types are missing? Because I get this error when I try to read 
> some SHP files: "Types > 20 are not yet accounted for"
>
>
>
> I wrote this script to reproduce:
>
>
>
>  | shpE legend urlRoot urlESRIFilePrefix urlESRIFileShp urlPath response 
> fileRef |
>
> " Download Shapefile resources "
> urlRoot := 
> 'https://github.com/nvkelso/natural-earth-vector/blob/master/110m_cultural/'.
> urlESRIFilePrefix := 'ne_110m_populated_places'.
> urlESRIFileShp := urlESRIFilePrefix , '.shp'.
> urlPath := urlRoot , urlESRIFilePrefix.
>
> #('.shx' '.dbf' '.shp') do: [ : ext |
> | url |
> url :=  (urlPath , ext , '?raw=true') asZnUrl.
> (response := ZnEasy get: url) isSuccess
> ifFalse: [ self error: 'Cannot download file' ].
> fileRef := FileSystem disk workingDirectory / (urlESRIFilePrefix , ext).
> fileRef writeStreamDo: [ : stream |
> stream nextPutAll: ((ZnByteEncoder newForEncoding: 'koi8r') decodeBytes: 
> response contents ) ] ].
>
>
>
> Once downloaded:
>
>
>
> | urlESRIFilePrefix urlESRIFileShp shpE |
> urlESRIFilePrefix := 'ne_110m_populated_places'.
> urlESRIFileShp := urlESRIFilePrefix , '.shp'.
>
> " Load and display it in Morphic "
> shpE := ShapeEnsemble fromFile: urlESRIFileShp.
>
>
>
> Maybe it's related with the fact they are encoded as koi8r?
>
> I checked with Zinc downloading first from the browser:
>
>
>
> | shpFile |
> shpFile := 'ne_110m_admin_0_countries.shp' asFileReference.
> [ shpFile binaryReadStreamDo: [ : in |
> (ZnCharacterEncoder detectEncoding: in upToEnd) identifier ] ]
> on: ZnCharacterEncodingError
> do: [ nil ].
>
>
>
>
>
> Cheers,
>
>
>
> Hernán
>
>
>
>

Re: [Pharo-users] Find/Replace class scoped

[Thierry Goubier]

Hi Vitor,

I got it to work (integrated it as a command into my IDE, and wrote
the auto-detect part for the permutation), with the following
algorithm (I've removed the IDE-specific part):

| aClass aSel newSel ast aMap |
aClass := RefactoringReformatExample.
aSel := #with:doThis:
newSel := UIManager default
request: 'Enter the new selector and arguments'
initialAnswer: (aClass >> aSel) ast selectorAndArgumentNames.
(newSel isNil or: [ newSel isEmpty ])
ifTrue: [ self inform: 'Cancelled'.
^ self ].
ast := aClass compiler parse: newSel.
aMap := ast argumentNames
collect: [ :e |
(aClass >> aSel) ast argumentNames
indexOf: e
ifAbsent: [ self error: 'Incorrect argument name: ' , e.
^ self ] ].
(RBRenameMethodRefactoring
renameMethod: aSelector
in: aClass
to: ast selector
permutation: aMap) execute

If your initial method is 'with: arg1 doThis: arg2', you write the new
selector as 'doThis: arg2 with: arg1' and it will pick up the
permutation map for you.

Thierry

Le mar. 26 mai 2020 à 17:05, Vitor Medina Cruz  a écrit :
>
> Will wait then.
>
> I tried to use the RB classes but with no success. There are few docs and 
> test code are hard to understand (still not sure if I should use transform ou 
> primitiveExecute). I did this:
>
> (RBRenameMethodRefactoring new
> renameMethod: #with:doThis:
> in: RefactoringReformatExample
> to: #withh:doThis:
> permutation: #(1 2)) primitiveExecute
>
> and
>
> (RBRenameMethodRefactoring new
> renameMethod: #with:doThis:
> in: RefactoringReformatExample
> to: #withh:doThis:
> permutation: #(1 2)) tranform
>
> but nothing happens... It is really odd, I expected an error at least.
>
> I am assuming permutation means the change of params order.
>
>
> On Fri, May 22, 2020 at 3:50 AM Stéphane Ducasse  
> wrote:
>>
>> we are working with sebastian jordan on a better rewriter.
>>
>> S.
>>
>> On 21 May 2020, at 17:17, Vitor Medina Cruz  wrote:
>>
>> Interesting, I will have a look at it.
>>
>> On Thu, May 21, 2020 at 11:52 AM Thierry Goubier  
>> wrote:
>>>
>>> Hi Vitor,
>>>
>>> as a matter of fact, the infrastructure for doing what you're looking
>>> for is already there.
>>>
>>> The algorithm is the following:
>>>
>>> - create a scope (something based on RBBrowserEnvironment, such as
>>> RBClassEnvironment or based on regexes and AND / OR operations:
>>> RBAndEnvironment, RBNotEnvironment, which allows for virtually
>>> anything, such as all #printString methods in the package X that do
>>> not belong to class Y)
>>>
>>> - create a refactoring command: if it is not a pre-existing command
>>> such as rename class, etc..., then writing a pattern matcher is
>>> possible with RBTreeRewriter.
>>>
>>> - execute the refactoring command on the environment, changing only
>>> for the subset of code visible in the environment.
>>>
>>> Normally, the system browser or the search tools should automatically
>>> setup the environment for you, and scope accordingly most of the
>>> refactoring commands. As far as I know, there isn't yet a shell giving
>>> you the full pattern matching rewrite power, but some work was
>>> underway (GUI tools).
>>>
>>> Going with the source files as you did also work...
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>> Le jeu. 21 mai 2020 à 15:30, Vitor Medina Cruz  a 
>>> écrit :
>>> >
>>> > Well, as it seems, there is no way of find/replacing other than inside a 
>>> > single method.
>>> >
>>> > As a workaround, I did the following:
>>> >
>>> > 1- Committed all my image work in progress;
>>> > 2- Opened the project structure in an external tool (notepad++ in this 
>>> > case) and did the find/replace there;
>>> > 3- Committed it using git command line;
>>> > 4- Back to the image, I did a repair repository from iceberg checking out 
>>> > and ignoring changes to the image (safe because I did commit everything 
>>> > before)
>>> >
>>> > If there are many places to change, it is worth.
>>> >
>>> > Regards,
>>> > Vitor
>>> >
>>> > On Tue, May 19, 2020 at 12:56 PM Vitor Medina Cruz  
>>> > wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> Is there a way to make find replace in a class scoped way? I can do that 
>>> >> with finder, but I figured only with package scoping. I wanna to change 
>>> >> the name of a variable in multiple methods, and also I would like to 
>>> >> regex replace an expression also in multiple methods.
>>> >>
>>> >> Regards,
>>> >> Vitor
>>>
>>
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Aurore Dalle
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>

Re: [Pharo-users] Find/Replace class scoped

[Thierry Goubier]

Hi Vitor,

as a matter of fact, the infrastructure for doing what you're looking
for is already there.

The algorithm is the following:

- create a scope (something based on RBBrowserEnvironment, such as
RBClassEnvironment or based on regexes and AND / OR operations:
RBAndEnvironment, RBNotEnvironment, which allows for virtually
anything, such as all #printString methods in the package X that do
not belong to class Y)

- create a refactoring command: if it is not a pre-existing command
such as rename class, etc..., then writing a pattern matcher is
possible with RBTreeRewriter.

- execute the refactoring command on the environment, changing only
for the subset of code visible in the environment.

Normally, the system browser or the search tools should automatically
setup the environment for you, and scope accordingly most of the
refactoring commands. As far as I know, there isn't yet a shell giving
you the full pattern matching rewrite power, but some work was
underway (GUI tools).

Going with the source files as you did also work...

Regards,

Thierry

Le jeu. 21 mai 2020 à 15:30, Vitor Medina Cruz  a écrit :
>
> Well, as it seems, there is no way of find/replacing other than inside a 
> single method.
>
> As a workaround, I did the following:
>
> 1- Committed all my image work in progress;
> 2- Opened the project structure in an external tool (notepad++ in this case) 
> and did the find/replace there;
> 3- Committed it using git command line;
> 4- Back to the image, I did a repair repository from iceberg checking out and 
> ignoring changes to the image (safe because I did commit everything before)
>
> If there are many places to change, it is worth.
>
> Regards,
> Vitor
>
> On Tue, May 19, 2020 at 12:56 PM Vitor Medina Cruz  
> wrote:
>>
>> Hello,
>>
>> Is there a way to make find replace in a class scoped way? I can do that 
>> with finder, but I figured only with package scoping. I wanna to change the 
>> name of a variable in multiple methods, and also I would like to regex 
>> replace an expression also in multiple methods.
>>
>> Regards,
>> Vitor

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Thierry Goubier]

Hi Esteban,

Le lun. 7 oct. 2019 à 12:26, Esteban Maringolo  a écrit :
>
> On Mon, Oct 7, 2019 at 12:07 PM Esteban Lorenzano  wrote:
> > > On 7 Oct 2019, at 11:55, Esteban Maringolo  wrote:
>
> > >> So I’m wondering when the Pharo GUI will snap as well as VW.
> > >
> > > Maybe with native widgets there will be a significant speedup,
> > > although I don't know whether the lag comes from rendering time or
> > > from something else.
> >
> > Morphic + Glamour sometimes + bad UI/algorithms design put us in a bad 
> > place concerning UI speed.
>
> Pharo 5 was the turning point when it comes to that, and it correlates
> with the introduction of the Glamour-based tools.
>
> > We are working to fix it, but this is not straightforward.
>
> I know, and the effort put into that is really appreciated.
>
> I haven't used your latest "native widgets" (GTK) build, but as long
> as the UI isn't programmed to be as async as possible, then any non-UI
> related event will slowdown or micro-block the UI, causing the noticed
> latency.
>
> I know I'm speaking the obvious to you here, but if you look at things
> like Android Architecture there is a lot to learn from, because mobile
> users expect significantly faster, non-blocking UIs that desktop, and
> not to mention web (although this is is changing too).

I would recommend that reference:

https://danluu.com/input-lag/

to make sure we have a baseline to evaluate GUI responsiveness. In
part because some objectives may be unrealistic, given the software
and hardware layers involved.

Thierry

> Regards,
>
> Esteban A. Maringolo
>

Re: [Pharo-users] Read and parse maildir (offlineimap) files

[Thierry Goubier]

It's a common shell script lab assignment to be able to parse this
format (RFC 822). Unix 101 level. A bit tricky in practice, because
the format has a strong dependency on the blank line between the
header part and the email content...

Technically, maildir only refers to the directory/files organisation,
not the format of an email inside each file.

Emails with attachments can create headaches for quick and dirty scan,
because they appear as text files containing binary data a few MBs
long... If you happen to have a backtracking RE or parser on it,
you'll kill your image.

Thierry

Le ven. 8 mars 2019 à 16:23, Alistair Grant  a écrit :
>
> Hi Cédrick,
>
> On Fri, 8 Mar 2019 at 16:12, Cédrick Béler  wrote:
> >
> > Hi Alistair,
> >
> > This looks like what I’d like to have (parsing emails). I’d better like an 
> > IMAP Client but using offlinmap might be an option.
> >
> > Will look at it.
> >
> > Do you have an exemple of milder format files ?
>
> Attached is the email you sent.
>
> I found https://github.com/codeZeilen/SMailDir but it is written for
> Squeak and doesn't load cleanly in Pharo (I haven't actually done
> anything with it yet).
>
> Cheers,
> Alistair
>
>
> > > Le 8 mars 2019 à 15:49, Alistair Grant  a écrit :
> > >
> > > Hi Everyone,
> > >
> > > I'd like to be able to parse and read the mail files as saved by
> > > offlineimap, i.e. in maildir format (one message per file).
> > >
> > > Does anyone know of any existing libraries in Pharo?
> > >
> > > Thanks very much,
> > > Alistair
> > >
> >
> >

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

[Thierry Goubier]

Hi Serge, Albrecht,

loading OSProcess directly with the following expression works:

Metacello new
configuration: 'OSProcess';
repository: 'http://www.squeaksource.com/MetacelloRepository';
load

There is still some work to be done on OSProcess adaptation to Pharo
7, but they are in rarely used parts.

Regards,

Thierry

Le mar. 19 févr. 2019 à 12:19, Albrecht Baur via Pharo-users
 a écrit :
>
> I need to execute OS commands from within a x64 pharo 7.01 image on centos7 
> (for example: 'zip -r 123.zip zipme/').
>
> I found these 3 tools: OSProcess, OSSubprocess, LibC uniqueInstance
>
> But I did not find any docu on which one to use for which use case.
>
> OSProcess is in the catalog browser but fails loading because of 
> ByteArray>>ifNotNilDo:
> -> So OSProcess is not to be used with p7 ?
>
> OSSubprocess loads via catalog browser and the following snippet works (even 
> though 64 bit):
>
> OSSUnixSubprocess new
> command: 'zip';
> arguments: #('-r' '123.zip' 'zipme');
> redirectStdout;
> runAndWaitOnExitDo: [ :process :outString  |
> outString inspect
> ]
>
> So is it ok to use OSSubprocess with 64 bit even though documented as 32 bit 
> only ? (here: 
> https://github.com/pharo-contributions/OSSubprocess#installation)
>
> LibC uniqueInstance system: 'zip -r 123.zip zipme/'
> ... works, but I don't know if its the right tool for this.
>
> Is there somewhere more info on which tool to use for which use case ?
>
> Thanks in advance!
>
> Albrecht
>
> PS.: I need to use zip as os process only because of this issue: 
> https://github.com/pharo-project/pharo/issues/2584

Re: [Pharo-users] Non-greedy RegEx?

[Thierry Goubier]

The Regex engine inside SmaCC allows for non-greedy REs. But it's
integrated as a parser first stage, not as an independent RE engine.

Regards,

Thierry

Le mar. 5 févr. 2019 à 08:34, Esteban Lorenzano  a écrit :
>
> Hi,
>
> Yes, Pharo regex implementation is very naive.
> We will be moving to a PCRE binding to match outside world standards but we 
> have not had the time to work on it :(
>
> Esteban
>
> > On 5 Feb 2019, at 00:27, Manuel Leuenberger  
> > wrote:
> >
> > Hi,
> >
> > I just noticed that the Pharo regexes do not understand non-greedy matches. 
> > A regex engine to be PCRE is kind of essential, not having '.*?' to be a 
> > parseable and working regex is a bummer. Are there any more powerful regex 
> > engines around for Pharo? I could not find any.
> >
> > Cheers,
> > Manuel
> >
> >
>
>

Re: [Pharo-users] Library to use multi-core in Pharo?

[Thierry Goubier]

Oh well, sorry. I checked and ... it seemed taskit could do it, but
now it seems to be a future extension.
However OSProcess can do it: look at #forkSqueak.

Thierry

Le mer. 9 janv. 2019 à 21:36, Thierry Goubier
 a écrit :
>
> Hi Alexandre,
>
> look at taskit: (https://github.com/sbragagnolo/taskit). I think it
> can do what you are looking for. I think that OSProcess is also able
> to do that via fork calls.
>
> Having minimal, light weight images without complex loading
> preferences and whatever would help, otherwise simply forking your
> current image could be faster.
>
> Thierry
>
> Le mer. 9 janv. 2019 à 19:42, Alexandre Bergel via Pharo-users
>  a écrit :
> >
> > Hi!
> >
> > Is there an effort to easily use multi-core or native processes in Pharo?
> > I am thinking about a library that offer a construct like:
> >
> > future := Runner runInDifferentProcess: [ “This block is run in a different 
> > OS process” ]
> >
> > That would save the image under a different name, use OSSubProcess to 
> > launch a new Pharo with no UI.
> >
> > Is there a library available?
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >

Re: [Pharo-users] Library to use multi-core in Pharo?

[Thierry Goubier]

Hi Alexandre,

look at taskit: (https://github.com/sbragagnolo/taskit). I think it
can do what you are looking for. I think that OSProcess is also able
to do that via fork calls.

Having minimal, light weight images without complex loading
preferences and whatever would help, otherwise simply forking your
current image could be faster.

Thierry

Le mer. 9 janv. 2019 à 19:42, Alexandre Bergel via Pharo-users
 a écrit :
>
> Hi!
>
> Is there an effort to easily use multi-core or native processes in Pharo?
> I am thinking about a library that offer a construct like:
>
> future := Runner runInDifferentProcess: [ “This block is run in a different 
> OS process” ]
>
> That would save the image under a different name, use OSSubProcess to launch 
> a new Pharo with no UI.
>
> Is there a library available?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

[Thierry Goubier]

Le ven. 30 nov. 2018 à 10:31, Marcus Denker  a écrit :
>
>
>
> > On 29 Nov 2018, at 12:55, Thierry Goubier  wrote:
> >
> > Le jeu. 29 nov. 2018 à 11:15, Marcus Denker  a 
> > écrit :
> >>
> >>
> >>
> >>> On 29 Nov 2018, at 10:45, Thierry Goubier  
> >>> wrote:
> >>>
> >>> Hi Manuel,
> >>>
> >>> would that extend to testing what happens if you add many, many
> >>> metalinks in a method?
> >>>
> >>
> >> yes, it would be nice to test that.
> >>
> >>
> >>> I tried to rewrite the automated code tracer I had to use metalinks,
> >>> and I gave up once I discovered that going over a certain number of
> >>> metalinks in a method would stop working.
> >>>
> >>
> >>
> >> If you add a lot of code, you need to use the new byte code set as the old 
> >> one is extremely limited for everything (number of temps, jump offset…)
> >
> > Well, it failed before that limit; once the context was complex
> > enough, it would fail in various ways, such as being unable to bind to
> > the proper temporary, writing incorrect byte sequences, and so on
> >
>
> I think the changes we did will make that better…
>
> > As anyway, it was injecting the same code that my tracer was already
> > doing, but in a less debuggable way, so I sort of gave up and kept
> > MetaLink use to simpler things, such as a type checker that inject
> > type checks on arguments based on the type inferred from arguments
> > names.
> >
> > Now, when I see how you're improving metalinks in this thread, I'd be
> > interested in a higher view (source-level) of the transformations
> > you're doing for implementing metalinks: I think they then could be
> > reused in different contexts (i.e. refactorings, for example), or
> > generalised outside Smalltalk itself. It may probably already been
> > expressed that way, but I haven't looked into the metalink code
> > itself.
> >
>
> For now it is implemented as a special compiler (with “self emitAfter: 
> aNode”) added in overriden methods of the main compiler.
>
> I made the mistake of doing some stuff (after links, for example) directly in 
> the IR level, that did not work.
>
> Now this is fixed for all but the links for Sequences (to be done later).
>
> Steven did a version that is based on AST transformation only, we will 
> explore that direction further in the future.

Interesting, so this would be the one I'd like to see (because I
implemented with AST transforms). Would you have a link to his work?
Mine is on github, and the version I did at UBO was on the VisualWorks
AST.

Thierry

> Marcus

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

[Thierry Goubier]

Le jeu. 29 nov. 2018 à 11:15, Marcus Denker  a écrit :
>
>
>
> > On 29 Nov 2018, at 10:45, Thierry Goubier  wrote:
> >
> > Hi Manuel,
> >
> > would that extend to testing what happens if you add many, many
> > metalinks in a method?
> >
>
> yes, it would be nice to test that.
>
>
> > I tried to rewrite the automated code tracer I had to use metalinks,
> > and I gave up once I discovered that going over a certain number of
> > metalinks in a method would stop working.
> >
>
>
> If you add a lot of code, you need to use the new byte code set as the old 
> one is extremely limited for everything (number of temps, jump offset…)

Well, it failed before that limit; once the context was complex
enough, it would fail in various ways, such as being unable to bind to
the proper temporary, writing incorrect byte sequences, and so on

As anyway, it was injecting the same code that my tracer was already
doing, but in a less debuggable way, so I sort of gave up and kept
MetaLink use to simpler things, such as a type checker that inject
type checks on arguments based on the type inferred from arguments
names.

Now, when I see how you're improving metalinks in this thread, I'd be
interested in a higher view (source-level) of the transformations
you're doing for implementing metalinks: I think they then could be
reused in different contexts (i.e. refactorings, for example), or
generalised outside Smalltalk itself. It may probably already been
expressed that way, but I haven't looked into the metalink code
itself.

Thierry

>
> Marcus

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

[Thierry Goubier]

Hi Manuel,

would that extend to testing what happens if you add many, many
metalinks in a method?

I tried to rewrite the automated code tracer I had to use metalinks,
and I gave up once I discovered that going over a certain number of
metalinks in a method would stop working.

Thierry

Le jeu. 29 nov. 2018 à 09:03, Marcus Denker  a écrit :
>
>
>
> > On 28 Nov 2018, at 21:37, Manuel Leuenberger  
> > wrote:
> >
> > Awesome, thanks for the effort Marcus!
> >
> > I was wondering if it would be useful to use matrix-testing for MetaLinks. 
> > I imagine having example methods which employ all features of the Smalltalk 
> > syntax (syntax on a postcard?), for which all intermediate results of 
> > expressions are known, then apply MetaLinks in all possible combinations 
> > (arguments x control) and check the reifications and side-effects against 
> > the oracle. Then the tests would generate a matrix of which combinations 
> > work and which don't. This should cover most of the possible executions.
> >
>
> Yes, that would be nice.
>
> Marcus
>
>

Re: [Pharo-users] Installing SmaCC

[Thierry Goubier]

Le 17/10/2018 à 07:36, H. Hirzel a écrit :

The successor of Ni is 'Spry'

https://github.com/gokr/spry
http://sprylang.se/

"Spry borrows homoiconicity from Rebol and Lisp, free form syntax from
Forth and Rebol, the word of different types from Rebol, good data
structure literal support from JavaScript and the general coding
experience and style from Smalltalk. It also has a few ideas of its
own, like an interesting argument passing mechanism and a relatively
novel take on OO."

--Hannes

On 10/17/18, Ben Coman  wrote:

Have you looked at Ni?  (I only read about it)
http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/


Went there and ended up far more interested by Nim than by Spry ;)

Thanks for the links!

Thierry


cheers -ben

On Wed, 17 Oct 2018 at 03:45, Dimitris Chloupis 
wrote:


Thank you Thierry , that was exactly what i was looking for :)

On the subject of syntax, StrongTalk looks far more advanced compared to
what I am aiming which is basically writting C code with Smalltalk like
syntax. I am looking at this

http://bracha.org/nwst.html

Which describes some really impressive features. So I am aiming only for
source to source compiler and not implementation of complex systems for
incremental compilations , optional type system etc.

On parsing strange code that is not much of an issue cause the project I
am working on has pretty reasonable code and will probably offer a way to
inline c code in case the parser fail. In any case my goals are small ,
cause I dont have resources for complex implementations. Its also a
language that will be designed solely for my needs and be offered open
source for anyone else that may find it useful. In any case I am sure I
will have many questions to ask :)

I was looking into ANTLR , since the book I am reading on language design
is using ANTLR but I rather implement this in Pharo. I used SmaCC when I
was working for my Python bridge and I really liked it , mostly because
it
offers ready made syntax definitions for most popular languages. Which
makes my life a lot easier.


On Tue, Oct 16, 2018 at 9:45 PM Thierry Goubier

wrote:


Hi Dimitris,

Le 16/10/2018 à 19:39, Dimitris Chloupis a écrit :

yes i already said that i followed the instructions in the github repo


Yes, by default that installation of SmaCC does not load all parsers
(some of them are fairly large). However, most of them are in the
downloaded repository, so you can load them independently.

Otherwise, loading that way, should load everything:

Metacello new
baseline: 'SmaCC';
repository: 'github://SmaCCRefactoring/SmaCC';
load: #('Tools' 'Examples' 'Examples-Extra')

Regarding your language question, I'd suggest two things:

- Look at StrongTalk for a way to write Smalltalk with type
declarations...

- C parsers able to parse most strange C code one may encounter takes
some work...

Regards,

Thierry


On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel mailto:hannes.hir...@gmail.com>> wrote:

 Refers to
 https://github.com/SmaCCRefactoring/SmaCC

 which says

   This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6.


 Installing a Development version of Pharo for the latest Pharo
(with
 no guarantees):

 Metacello new
  baseline: 'SmaCC';
  repository: 'github://SmaCCRefactoring/SmaCC';
  load

 On 10/16/18, H. Hirzel mailto:hannes.hir...@gmail.com>> wrote:
  > What about trying
  >
  >
  > Metacello new
  > baseline: 'SmaCC';
  > repository: 'github://ThierryGoubier/SmaCC';
  > load
  >
  > This worked in Pharo 6.1 in November 2017
  >
  > On 10/16/18, Dimitris Chloupis mailto:kilon.al...@gmail.com>> wrote:
  >> thanks for the info Peter , will give it a try :)
  >>
  >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch
 mailto:pe...@pbkresearch.co.uk>>
  >> wrote:
  >>
  >>> Dimitris
  >>>
  >>>
  >>>
  >>> If you download the latest Moose Suite 6.1, you will have
Pharo
 6.1 with
  >>> lots of extra packages, including SmaCC. The SmaCC includes
 compilers
  >>> for
  >>> C, Smalltalk and Java, among others, but with little or no
  >>> documentation.
  >>> I
  >>> am not a SmaCC expert, so I can’t say whether it will do what
 you want,
  >>> but
  >>> at least it will give you a start. Moose also includes
 PetitParser and
  >>> PP2,if you want to try other parsing approaches. Of course,
the
 Windows
  >>> version is 32-bit only, for reasons explained elsewhere in
this
 thread.
  &g

Re: [Pharo-users] Installing SmaCC

[Thierry Goubier]

Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis
 a écrit :
>
> About your last part on platforms, I will be providing a way to inline C code 
> so one can you use C macros to detect the platform and generate code 
> accordingly. Or this could happen via a pragma too, it should not be an 
> issue. This also a reason why I previously talked about an "in place" 
> annotation and why specially named variables was my first choice instead of 
> pragmas. I am also not a big fan of pragmas syntax which for me at least 
> deviates from standard smalltalk syntax style. But as I said I am not against 
> their usage at all.
>
> Generally because this is no an afternoon project obviously, I will be 
> relying on C code inling at first for special corner cases and then I will 
> implement them as annotations the more the project moves forward.

Having a way to do the same as what asm inline is in gcc, but for
hand-written C inside your Smalltalk derivative is cool: remap
variable names, etc, so that your C generator handles all the
interface between the inlined C and the surrounding Smalltalk.

Same if you also add platform-dependent customisation for generation.

Thierry

> On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis  
> wrote:
>>
>> Hello Allistair
>>
>> I have used Slang only once and it was generating code that was indeed 
>> readbale but my aim is for more finer control over the output. Lets say I 
>> want import a specific C header file or I want a string to map to custom C 
>> type I created etc. So yes Slang is by no mean a bad tool at all its just is 
>> not designed with making source output that is undetectable as autogenerated 
>> by a human. But I will have to give it a more serious try because it may be 
>> closer than I initially thought.
>>
>> I am not against the usage of pragmas, and indeed are an excellent way to 
>> annotate stuff , my only concern is when I may want to annotate in place for 
>> some weird reason , but that may be doable with pragmas as well too.
>>
>> Smalltalk code that is 100% smalltalk should be able to execute , you 
>> mention however the execution of external C functions , problem is that in 
>> my case that code does not live in DLLs but in an executable so no I am not 
>> amaing to that level of execution.
>>
>> Also I have an easier solution for this too, when I made the CPPBridge, 
>> which is a Pharo library that allows the usage of C++ libraries from Pharo, 
>> I used a shared memory bridge to communicate back to Pharo giving the 
>> ability of both function calls and callbacks. If I really want to capture 
>> execution I can do it like this which is the exact opposite of what you do, 
>> instead of the VM capturing the executable it will be the executable 
>> capturing the VM if that makes any sense. This makes things far easier. As a 
>> matter of fact not only my CPPBridge does this it also allows to extend the 
>> pharo image file because it uses memory mapped files for the shared memory 
>> which like pharo image files are memory dumps. So there is a lot potential 
>> in that department.
>>
>> However my main goal is to use Smalltalk code execution to make sure the 
>> prototype works on a basic level, there will be a C cide in this project 
>> obviously which will act like a runtime that will provide live coding 
>> features. This is also a library I made in C that does this through the 
>> usage of DLLs that rebuilds and reloads dynamically.
>>
>> So I dont really need the VM to execute my code to check that is working 
>> cause the C compiler and the live coding runtime can handle this. I could 
>> even hook in the Pharo debugger, I have done this with my Atlas library that 
>> allows to use Python library from Pharo by sending the python error back to 
>> Pharo debugger where it triggers an error and the debugger pops to allow you 
>> to do your usual live coding magic and basically resends the code back to 
>> python. Because of my C livecoding library I can do this with C too. My only 
>> concern is how the C/C++ compiler reports errors because obviously it known 
>> that it kinda sucks on this. But hey I cannot make C better :D
>>
>> Generally speaking the tools I am making are not designed for general 
>> consuption but designed to solve my own problems. Of course I like to share 
>> them because there is always the chance for someone to find them useful as 
>> it has happened with Atlas for example. Plus as happened with Atlas one can 
>> take my code and adjust it to his or her personal needs.
>>
>> On Wed, Oct 17, 2018 at 1:04 PM Alistair Grant  wrote:
>>>
>>> Hi Dimitris,
>>>
>>> As someone currently learning to use Slang (i.e. not an expert), I've
>>> added my 2c below...
>>>
>>> On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis  
>>> wrote:
>>> >
>>> > Thierry you have done it !!! you just gave a very easy solution to my 
>>> > problems.
>>> >
>>> > Yeap Slang is quite close to what I am thinking, unfortunately Clement 
>>> > told me to stay away f

Re: [Pharo-users] Installing SmaCC

[Thierry Goubier]

ge that will be designed solely for my needs and be offered open
>> >> source for anyone else that may find it useful. In any case I am sure I
>> >> will have many questions to ask :)
>> >>
>> >> I was looking into ANTLR , since the book I am reading on language design
>> >> is using ANTLR but I rather implement this in Pharo. I used SmaCC when I
>> >> was working for my Python bridge and I really liked it , mostly because
>> >> it
>> >> offers ready made syntax definitions for most popular languages. Which
>> >> makes my life a lot easier.
>> >>
>> >>
>> >> On Tue, Oct 16, 2018 at 9:45 PM Thierry Goubier
>> >> 
>> >> wrote:
>> >>
>> >>> Hi Dimitris,
>> >>>
>> >>> Le 16/10/2018 à 19:39, Dimitris Chloupis a écrit :
>> >>> > yes i already said that i followed the instructions in the github repo
>> >>>
>> >>> Yes, by default that installation of SmaCC does not load all parsers
>> >>> (some of them are fairly large). However, most of them are in the
>> >>> downloaded repository, so you can load them independently.
>> >>>
>> >>> Otherwise, loading that way, should load everything:
>> >>>
>> >>> Metacello new
>> >>>baseline: 'SmaCC';
>> >>>repository: 'github://SmaCCRefactoring/SmaCC';
>> >>>load: #('Tools' 'Examples' 'Examples-Extra')
>> >>>
>> >>> Regarding your language question, I'd suggest two things:
>> >>>
>> >>> - Look at StrongTalk for a way to write Smalltalk with type
>> >>> declarations...
>> >>>
>> >>> - C parsers able to parse most strange C code one may encounter takes
>> >>> some work...
>> >>>
>> >>> Regards,
>> >>>
>> >>> Thierry
>> >>>
>> >>> > On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel > >>> > <mailto:hannes.hir...@gmail.com>> wrote:
>> >>> >
>> >>> > Refers to
>> >>> > https://github.com/SmaCCRefactoring/SmaCC
>> >>> >
>> >>> > which says
>> >>> >
>> >>> >   This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6.
>> >>> >
>> >>> >
>> >>> > Installing a Development version of Pharo for the latest Pharo
>> >>> > (with
>> >>> > no guarantees):
>> >>> >
>> >>> > Metacello new
>> >>> >  baseline: 'SmaCC';
>> >>> >  repository: 'github://SmaCCRefactoring/SmaCC';
>> >>> >  load
>> >>> >
>> >>> > On 10/16/18, H. Hirzel > >>> > <mailto:hannes.hir...@gmail.com>> wrote:
>> >>> >  > What about trying
>> >>> >  >
>> >>> >  >
>> >>> >  > Metacello new
>> >>> >  > baseline: 'SmaCC';
>> >>> >  > repository: 'github://ThierryGoubier/SmaCC';
>> >>> >  > load
>> >>> >  >
>> >>> >  > This worked in Pharo 6.1 in November 2017
>> >>> >  >
>> >>> >  > On 10/16/18, Dimitris Chloupis > >>> > <mailto:kilon.al...@gmail.com>> wrote:
>> >>> >  >> thanks for the info Peter , will give it a try :)
>> >>> >  >>
>> >>> >  >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch
>> >>> > mailto:pe...@pbkresearch.co.uk>>
>> >>> >  >> wrote:
>> >>> >  >>
>> >>> >  >>> Dimitris
>> >>> >  >>>
>> >>> >  >>>
>> >>> >  >>>
>> >>> >  >>> If you download the latest Moose Suite 6.1, you will have
>> >>> > Pharo
>> >>> > 6.1 with
>> >>> >  >>> lots of extra packages, including SmaCC. The SmaCC includes
>> >>> > compilers
>> >>&g

Re: [Pharo-users] Installing SmaCC

[Thierry Goubier]

Hi Dimitris,

Le 16/10/2018 à 19:39, Dimitris Chloupis a écrit :

yes i already said that i followed the instructions in the github repo


Yes, by default that installation of SmaCC does not load all parsers 
(some of them are fairly large). However, most of them are in the 
downloaded repository, so you can load them independently.


Otherwise, loading that way, should load everything:

Metacello new
  baseline: 'SmaCC';
  repository: 'github://SmaCCRefactoring/SmaCC';
  load: #('Tools' 'Examples' 'Examples-Extra')

Regarding your language question, I'd suggest two things:

- Look at StrongTalk for a way to write Smalltalk with type declarations...

- C parsers able to parse most strange C code one may encounter takes 
some work...


Regards,

Thierry

On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel > wrote:


Refers to
https://github.com/SmaCCRefactoring/SmaCC

which says

      This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6.


Installing a Development version of Pharo for the latest Pharo (with
no guarantees):

Metacello new
     baseline: 'SmaCC';
     repository: 'github://SmaCCRefactoring/SmaCC';
     load

On 10/16/18, H. Hirzel mailto:hannes.hir...@gmail.com>> wrote:
 > What about trying
 >
 >
 >     Metacello new
 >     baseline: 'SmaCC';
 >     repository: 'github://ThierryGoubier/SmaCC';
 >     load
 >
 > This worked in Pharo 6.1 in November 2017
 >
 > On 10/16/18, Dimitris Chloupis mailto:kilon.al...@gmail.com>> wrote:
 >> thanks for the info Peter , will give it a try :)
 >>
 >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch
mailto:pe...@pbkresearch.co.uk>>
 >> wrote:
 >>
 >>> Dimitris
 >>>
 >>>
 >>>
 >>> If you download the latest Moose Suite 6.1, you will have Pharo
6.1 with
 >>> lots of extra packages, including SmaCC. The SmaCC includes
compilers
 >>> for
 >>> C, Smalltalk and Java, among others, but with little or no
 >>> documentation.
 >>> I
 >>> am not a SmaCC expert, so I can’t say whether it will do what
you want,
 >>> but
 >>> at least it will give you a start. Moose also includes
PetitParser and
 >>> PP2,if you want to try other parsing approaches. Of course, the
Windows
 >>> version is 32-bit only, for reasons explained elsewhere in this
thread.
 >>>
 >>>
 >>>
 >>> HTH
 >>>
 >>>
 >>>
 >>> Peter Kenny
 >>>
 >>>
 >>>
 >>> *From:* Pharo-users mailto:pharo-users-boun...@lists.pharo.org>> *On Behalf Of
 >>> *Dimitris
 >>> Chloupis
 >>> *Sent:* 16 October 2018 15:40
 >>> *To:* Any question about pharo is welcome
mailto:pharo-users@lists.pharo.org>>
 >>> *Subject:* [Pharo-users] Installing SmaCC
 >>>
 >>>
 >>>
 >>> Hey guys
 >>>
 >>>
 >>>
 >>> I downloaded the latest Pharo 6.1 64bit for Windows and tried
to install
 >>> SmaCC through the catalog browser but it failed
 >>>
 >>>
 >>>
 >>> I did manage to install it following the instruction in the
github repo
 >>> but I see that I am missing most parser packages.
 >>>
 >>>
 >>>
 >>> The languages I am interested are Smalltalk (which is included)
and C
 >>> (if
 >>> possible C++ too) cause I will be creating a new language which
will be
 >>> a
 >>> cross between C and Smalltalk (very similar to smalltalk syntax
but with
 >>> the addtion of C types and no GC and dynamic typing and also a
partial
 >>> implementation of OOP that is quite diffirent). My goal is
compilation
 >>> of
 >>> my language to readable C code so the ability to parse also
existing C
 >>> code
 >>> is needed.
 >>>
 >>>
 >>>
 >>> Any help is greatly appreciated , thanks :)
 >>>
 >>
 >

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

[Thierry Goubier]

2018-06-15 8:19 GMT+02:00 Esteban Lorenzano :

>
>
> On 15 Jun 2018, at 08:11, Norbert Hartl  wrote:
>
>
>
> Am 14.06.2018 um 13:12 schrieb Thierry Goubier  >:
>
> Hi Norbert, Tim,
>
> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>
>>
>>
>> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>>
>> Hi - yes I’m pleased you check out the entire tree, although currently
>> it’s a bit confusing that you do (fortunately this does give the
>> possibility that we can checkout images and other resources that an Pharo
>> application might rely on - without having to resort to the Seaside
>> FileLibrary trick).
>>
>> However my concrete case was that I have a gitlab ci pipeline and next to
>> my src directory in my project I have a config directory that has some
>> Nginx config for my teapot app. If I add a teapot route, I also need to
>> adjust that config and check both changes in together. I can’t easily do
>> that now?
>>
>> I can modify /config/app.nginx either in another app (intellij) or even
>> in the simple Pharo text editor, and the I can add my new route in my
>> DemoApp>>createRoutes method but how do I check them in together so my
>> pipeline will build atomically?
>>
>> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
>> do a commit, and iceberg ignores the parallel /config directory (that it
>> checked out). So it’s a catch 22.
>>
>> This is why I suggested maybe we could specify safer (textual)
>> directories that iceberg might also checkin? OR we have a Stage command in
>> iceberg that does everything that commit does up to the point of actually
>> writing to the repo - then I could jump to IntelliJ and do the final commit
>> there and use its tools to manage non Pharo stuff (until we can build more)?
>>
>> Does this make sense?
>>
>> I don’t understand why you are so eager to have everything into one
>> commit. Usually the tension is rather have small commits. What is the
>> problem of having two commits for this?
>>
>
> A single commit allow one to make sure that both the smalltalk code and
> the external resource are well in sync, and that you may not ending up in a
> situation were at commit j has data format v1 and smalltalk code for format
> v2, because it is in commit j+1 that you rewrote the data in format v2.
>
> Yes, sure but that is only a problem if you lost control over which commit
> goes into action. I think the problem is in the deployment then. Putting
> integrity constraints on commits is IMHO the wrong level deployment
> granularity
>
>
> +1
> git favours many small commits.
>

.. and suggests you use rebase, squash and etc... to make sense of those
many small commits.

Thierry


>
> Esteban
>
>
> Norbert
>
> I had that issue recently with a Pharo / FPGA project with a Pharo package
> generating state machines to be integrated in a Verilog FPGA design with C
> code for the drivers, the softcore in the FPGA, and test programs, and both
> Pharo and the C/FPGA working out of the same test data... And that whole
> thing getting regularly out of sync.
>
> IMHO: I'd model a concept of "multi-lingual projet" for that sort of
> things, where one can list, in Pharo, Monticello packages and external
> files or directories. Whatever the technology you use (OSProcess, libgit,
> whatever...) it is easy then to commit all this in a single pass. On a
> per-package basis, I'd see the package manifest as a suitable place for
> listing external resources. On a per-project basis, a possible place could
> be the manifest for the BaselineOf the project.
>
> Thierry
>
>
>>
>> Norbert
>>
>> As an aside - I’d really like to checkin in the play-xxx directories (the
>> .ph files) as there is often useful playground stuff I’d like to access on
>> my home computer. We can’t do that easily at the moment either.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 14 Jun 2018, at 09:12, Guillermo Polito 
>> wrote:
>>
>> Just to complement Esteban's answer:
>>
>> - Iceberg checks out in disk more than the src directory because you
>> **may** want to edit files from the command line, and after long
>> discussions we did not want to forbid that.
>> Actually, just to put everybody in perspective, at first the idea was to
>> not have a working copy in disk at all, but just hit to the blob.
>> Imagine is nowadays we are a bit alien, that would have been worst :)
>>
>> - About checking in files. I'd like to understand what you mean exactly.
>>   - Do you w

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

[Thierry Goubier]

2018-06-15 8:11 GMT+02:00 Norbert Hartl :

>
>
> Am 14.06.2018 um 13:12 schrieb Thierry Goubier  >:
>
> Hi Norbert, Tim,
>
> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>
>>
>>
>> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>>
>> Hi - yes I’m pleased you check out the entire tree, although currently
>> it’s a bit confusing that you do (fortunately this does give the
>> possibility that we can checkout images and other resources that an Pharo
>> application might rely on - without having to resort to the Seaside
>> FileLibrary trick).
>>
>> However my concrete case was that I have a gitlab ci pipeline and next to
>> my src directory in my project I have a config directory that has some
>> Nginx config for my teapot app. If I add a teapot route, I also need to
>> adjust that config and check both changes in together. I can’t easily do
>> that now?
>>
>> I can modify /config/app.nginx either in another app (intellij) or even
>> in the simple Pharo text editor, and the I can add my new route in my
>> DemoApp>>createRoutes method but how do I check them in together so my
>> pipeline will build atomically?
>>
>> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
>> do a commit, and iceberg ignores the parallel /config directory (that it
>> checked out). So it’s a catch 22.
>>
>> This is why I suggested maybe we could specify safer (textual)
>> directories that iceberg might also checkin? OR we have a Stage command in
>> iceberg that does everything that commit does up to the point of actually
>> writing to the repo - then I could jump to IntelliJ and do the final commit
>> there and use its tools to manage non Pharo stuff (until we can build more)?
>>
>> Does this make sense?
>>
>> I don’t understand why you are so eager to have everything into one
>> commit. Usually the tension is rather have small commits. What is the
>> problem of having two commits for this?
>>
>
> A single commit allow one to make sure that both the smalltalk code and
> the external resource are well in sync, and that you may not ending up in a
> situation were at commit j has data format v1 and smalltalk code for format
> v2, because it is in commit j+1 that you rewrote the data in format v2.
>
> Yes, sure but that is only a problem if you lost control over which commit
> goes into action. I think the problem is in the deployment then. Putting
> integrity constraints on commits is IMHO the wrong level deployment
> granularity
>

That may be.

But I'm not used to consider co-working on the same branch with my HW
engineer as "deployment"...

Thierry


>
> Norbert
>
> I had that issue recently with a Pharo / FPGA project with a Pharo package
> generating state machines to be integrated in a Verilog FPGA design with C
> code for the drivers, the softcore in the FPGA, and test programs, and both
> Pharo and the C/FPGA working out of the same test data... And that whole
> thing getting regularly out of sync.
>
> IMHO: I'd model a concept of "multi-lingual projet" for that sort of
> things, where one can list, in Pharo, Monticello packages and external
> files or directories. Whatever the technology you use (OSProcess, libgit,
> whatever...) it is easy then to commit all this in a single pass. On a
> per-package basis, I'd see the package manifest as a suitable place for
> listing external resources. On a per-project basis, a possible place could
> be the manifest for the BaselineOf the project.
>
> Thierry
>
>
>>
>> Norbert
>>
>> As an aside - I’d really like to checkin in the play-xxx directories (the
>> .ph files) as there is often useful playground stuff I’d like to access on
>> my home computer. We can’t do that easily at the moment either.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 14 Jun 2018, at 09:12, Guillermo Polito 
>> wrote:
>>
>> Just to complement Esteban's answer:
>>
>> - Iceberg checks out in disk more than the src directory because you
>> **may** want to edit files from the command line, and after long
>> discussions we did not want to forbid that.
>> Actually, just to put everybody in perspective, at first the idea was to
>> not have a working copy in disk at all, but just hit to the blob.
>> Imagine is nowadays we are a bit alien, that would have been worst :)
>>
>> - About checking in files. I'd like to understand what you mean exactly.
>>   - Do you want to load them into memory?
>> This would be the "more consistent" way to do it, followin

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

[Thierry Goubier]

2018-06-14 15:39 GMT+02:00 Tim Mackinnon :

> Yes - I’m a fan of small checkins (not always great at it, but I strive
> for it) - and yes, the issue I’ve had is the same as what Thierry mentions
> - my Smalltalk code is tied to an external file which has some rewrite
> rules that depend on the classes I have in my image. I could possibly
> generate them from the Smalltalk code (this is something Sean does) - but I
> can see all kinds of reasons to atomically checkin code together.
>
>
And generating is not allways possible.


> It haven’t tried it - but I’m guessing if I stick non smalltalk things in
> my src directory, that might work (ugly and potentially confusing, but it
> might do the trick). OR I’ve just learned about #addFilesToIndex: which
> might help me in this case.
>

I wouldn't put things in the src directory. FileTree, for one, is
implemented by "I erase everything on-disk, then I write back my package",
which has a non-negligeable chance of erasing non-Smalltalk data in there.

The addFilesToIndex: should work, but the question becomes what is the hook
to automatically call it when saving your project with Iceberg.


>
> But as a more general (and easier to understand) solution - working well
> in a polyglot arena and checking other stuff in would be very handy. Hence
> my “staging” proposal (if it would work?).
>

Probably, yes.


>
> Alternatively, I will try and see what happens if I commit locally
> (without push) and then use my external tool to commit other files and then
> do the final push t(talking about it here helped me spot what could be an
> easy workaround). Still, I do hope we can keep working on the tools to get
> to something a bit more sophisticated - as the full atomic commit is the
> obvious end goal.
>

Consider using git squash, then. And calling git squash could be automated.

One run the risk of turning Iceberg in a complete language-agnostic git
client, which could make it too big to be sustainable in the long term.

Thierry


>
> Tim
>
>
> On 14 Jun 2018, at 12:12, Thierry Goubier 
> wrote:
>
> Hi Norbert, Tim,
>
> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>
>>
>>
>> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>>
>> Hi - yes I’m pleased you check out the entire tree, although currently
>> it’s a bit confusing that you do (fortunately this does give the
>> possibility that we can checkout images and other resources that an Pharo
>> application might rely on - without having to resort to the Seaside
>> FileLibrary trick).
>>
>> However my concrete case was that I have a gitlab ci pipeline and next to
>> my src directory in my project I have a config directory that has some
>> Nginx config for my teapot app. If I add a teapot route, I also need to
>> adjust that config and check both changes in together. I can’t easily do
>> that now?
>>
>> I can modify /config/app.nginx either in another app (intellij) or even
>> in the simple Pharo text editor, and the I can add my new route in my
>> DemoApp>>createRoutes method but how do I check them in together so my
>> pipeline will build atomically?
>>
>> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
>> do a commit, and iceberg ignores the parallel /config directory (that it
>> checked out). So it’s a catch 22.
>>
>> This is why I suggested maybe we could specify safer (textual)
>> directories that iceberg might also checkin? OR we have a Stage command in
>> iceberg that does everything that commit does up to the point of actually
>> writing to the repo - then I could jump to IntelliJ and do the final commit
>> there and use its tools to manage non Pharo stuff (until we can build more)?
>>
>> Does this make sense?
>>
>> I don’t understand why you are so eager to have everything into one
>> commit. Usually the tension is rather have small commits. What is the
>> problem of having two commits for this?
>>
>
> A single commit allow one to make sure that both the smalltalk code and
> the external resource are well in sync, and that you may not ending up in a
> situation were at commit j has data format v1 and smalltalk code for format
> v2, because it is in commit j+1 that you rewrote the data in format v2.
>
> I had that issue recently with a Pharo / FPGA project with a Pharo package
> generating state machines to be integrated in a Verilog FPGA design with C
> code for the drivers, the softcore in the FPGA, and test programs, and both
> Pharo and the C/FPGA working out of the same test data... And that whole
> thing getting regularly out of sync.
>
> IMHO: I'd model a concept of "multi-lingual pro

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

[Thierry Goubier]

Hi Norbert, Tim,

2018-06-14 11:33 GMT+02:00 Norbert Hartl :

>
>
> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>
> Hi - yes I’m pleased you check out the entire tree, although currently
> it’s a bit confusing that you do (fortunately this does give the
> possibility that we can checkout images and other resources that an Pharo
> application might rely on - without having to resort to the Seaside
> FileLibrary trick).
>
> However my concrete case was that I have a gitlab ci pipeline and next to
> my src directory in my project I have a config directory that has some
> Nginx config for my teapot app. If I add a teapot route, I also need to
> adjust that config and check both changes in together. I can’t easily do
> that now?
>
> I can modify /config/app.nginx either in another app (intellij) or even in
> the simple Pharo text editor, and the I can add my new route in my
> DemoApp>>createRoutes method but how do I check them in together so my
> pipeline will build atomically?
>
> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
> do a commit, and iceberg ignores the parallel /config directory (that it
> checked out). So it’s a catch 22.
>
> This is why I suggested maybe we could specify safer (textual) directories
> that iceberg might also checkin? OR we have a Stage command in iceberg that
> does everything that commit does up to the point of actually writing to the
> repo - then I could jump to IntelliJ and do the final commit there and use
> its tools to manage non Pharo stuff (until we can build more)?
>
> Does this make sense?
>
> I don’t understand why you are so eager to have everything into one
> commit. Usually the tension is rather have small commits. What is the
> problem of having two commits for this?
>

A single commit allow one to make sure that both the smalltalk code and the
external resource are well in sync, and that you may not ending up in a
situation were at commit j has data format v1 and smalltalk code for format
v2, because it is in commit j+1 that you rewrote the data in format v2.

I had that issue recently with a Pharo / FPGA project with a Pharo package
generating state machines to be integrated in a Verilog FPGA design with C
code for the drivers, the softcore in the FPGA, and test programs, and both
Pharo and the C/FPGA working out of the same test data... And that whole
thing getting regularly out of sync.

IMHO: I'd model a concept of "multi-lingual projet" for that sort of
things, where one can list, in Pharo, Monticello packages and external
files or directories. Whatever the technology you use (OSProcess, libgit,
whatever...) it is easy then to commit all this in a single pass. On a
per-package basis, I'd see the package manifest as a suitable place for
listing external resources. On a per-project basis, a possible place could
be the manifest for the BaselineOf the project.

Thierry


>
> Norbert
>
> As an aside - I’d really like to checkin in the play-xxx directories (the
> .ph files) as there is often useful playground stuff I’d like to access on
> my home computer. We can’t do that easily at the moment either.
>
> Tim
>
> Sent from my iPhone
>
> On 14 Jun 2018, at 09:12, Guillermo Polito 
> wrote:
>
> Just to complement Esteban's answer:
>
> - Iceberg checks out in disk more than the src directory because you
> **may** want to edit files from the command line, and after long
> discussions we did not want to forbid that.
> Actually, just to put everybody in perspective, at first the idea was to
> not have a working copy in disk at all, but just hit to the blob.
> Imagine is nowadays we are a bit alien, that would have been worst :)
>
> - About checking in files. I'd like to understand what you mean exactly.
>   - Do you want to load them into memory?
> This would be the "more consistent" way to do it, following the "the
> image it its own working copy" metaphore.
> This would allow us to, for example, share an image and transparently
> share resources with it (without requiring to clone).
> But this would have some impact in memory consumption and add stress
> to the GC, right?
>
>   - Or do you mean to ask like any other Git client and show you the file
> differences between the working copy and the git index?
> The problem with this approach is that we will have some treatment for
> pharo code and some different treatment for non-code...
> If I do a change to a class, the change is kept in the image. But if I
> do a change to a file, that change is not kept in the image!
>
> Also, as Esteban says, having an IDE with support for files would mean
> that we would need good tools to edit in-memory files (not only text files,
> right? but also any kind of binary file...)
>
> So far we cover the bare minimum that allows us to *not lose* changes :)
>
> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon  wrote:
>
>>
>> > yeah… but is a lot of work and no time just right now.
>> > long term, it would be cool to manage everything from 

Re: [Pharo-users] Loading Local Repositories with Iceberg

[Thierry Goubier]

2018-06-05 16:24 GMT+02:00 Norbert Hartl :
>
>
>> Am 05.06.2018 um 16:13 schrieb Stephan Eggermont :
>>
>> Norbert Hartl  wrote:
>>
>>> Ok, but where is the problem?
>>
>> - needs to work on different filesystems, with tricky behavior
>> - git itself did not get the behavior right
>> - git used to be non-reentrant. Did that change?
>>
> Ok, now we know about problems git should solve. What should we be doing?

Avoid sharing a git repository between Pharo images / processes.
Consider that git is a slightly unsafe way to store files in a single
place; use git distributed nature (even in the same machine) as a way
to cope with its limitations.

Or switch to Fossil, whose use of sqlite seems safer from that viewpoint.

Regards,

Thierry

> Norbert
>
>

Re: [Pharo-users] metacello and github under a custom domain

[Thierry Goubier]

2018-06-04 10:42 GMT+02:00 Cyril Ferlicot D. :
> On 03/06/2018 16:42, Tudor Girba wrote:
>> Hi,
>>
>
> Hi,
>
>> I am working with a GitHub enterprise installation that resides under a 
>> custom domain (e.g., github.example.com).
>>
>> I can clone the repository using Iceberg and ssh: 
>> g...@github.example.com:user/repo.git
>>
>> How can I tell Metacello to load a baseline from that repository?
>>
>
> Currently it's not possible in Metacello to support custom urls :(

GitFileTree provides for custom url in Metacello. Doru request would be:

Metacello new
baseline: 'Example';
repository: 'gitfiletree://github.example.com/user/repo';
load

I've been using various git entreprise installation with that scheme
for the past 3 or 4 years, via ssh mostly, but https.

I believe there is a discussion underway to do the same with, maybe
tonel:// urls.

Regards,

Thierry

> There was some discussions about extending Metacello but until now
> nobody got the time to begin an implementation of it.
>
> See: https://groups.google.com/forum/#!topic/metacello/QbpngL6Jhg8
>
>> Cheers,
>> Doru
>>
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "To lead is not to demand things, it is to make them happen."
>>
>>
>>
>>
>>
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>

Re: [Pharo-users] im using pharo in wayland system.

[Thierry Goubier]

Le 24/05/2018 à 18:16, peter yoo a écrit :

thank you. Thierry :D


Ok, I checked again, now that I'm back with a 18.04 system.

I have SourceCodePro and SourceSansPro as fonts.

Thierry

Re: [Pharo-users] im using pharo in wayland system.

[Thierry Goubier]

Le jeu. 24 mai 2018 16:23, peter yoo  a écrit :

> to Guillermo > where can download pharo 7? cannot find from google.
>
> to Thierry > hm... same now... install font and fc-cache later is same.
> and im using nouveau driver. using wayland now :D
>

Oh, ok, maybe it's a nouveau driver constraint.

I installed two fonts. I need to check again.

Thierry

>

Re: [Pharo-users] im using pharo in wayland system.

[Thierry Goubier]

Hi Peter,

I've seen the same error on a fresh 18.04 system I have installed last
week, and the solution was to add the Open Sans fonts to the user
folder (~/.fonts) and rebuild X font cache.

By the way, Ubuntu 17.10 was Wayland, Ubuntu 18.04 is not Wayland, as
far as I know. And I had Pharo working on both.

Regards,

Thierry

2018-05-24 14:06 GMT+02:00 peter yoo :
> hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run.
>
> look a attached png then know the problem. cannot using wirh wayland system
> now?
>
> maybe guess because freetype have a solution then help to me please.
>
> --
> http://lookandwalk.com  http://looknw.com | http://onionmixer.net
> peter yoo(Jonghwa Yoo). ROK

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

[Thierry Goubier]

Hi Mariano,

2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck :
>
>
> On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris 
> wrote:
>>
>> David T. Lewis wrote
>> > FFI based solutions work at a different level of abstraction than
>> > VM plugins, and there is a role for both.
>>
>> Thanks for the context, David. Now that we understand the different
>> niches,
>> the main problem is that they can not be loaded in the same image without
>> breaking :/
>>
>
> The problem is to find a solution that works for both, Squeak and Pharo as
> well as for OSProcess and OSSubprocess.
>
> I guess one possibility is to modify both, OSProcess and OSSubprocess
> initialization of the child reaper so that they install the same "generic"
> child reapear. Aside from initializating the child repear, they should be
> added into an "observer list". When, when it comes the second project to get
> loaded it which check that a child reaper is already registered..in which
> case he just register itself as "observer".
>
>  This child reaper should be generic enough (cannot be coupled to WHAT to do
> when the semaphore is signaled). Using Announcements (or other mechanisim
> that would work for Pharo and Squeak) we could simply "notify" the
> registered observers and each observer would do whatever is needed (what is
> actually now hardcoded in each child reaper)
>
> Maybe that works...just an idea.

I think that looks like a nice design. Just one question: do we need
to track down whether the child reaper event should be directed to
OSProcess or to OSSubprocess? Wondering if there is an issue with one
of them trying to close the other one's resource (but I haven't
checked, so I may be wrong).

Thierry

>
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Thierry Goubier]

2018-05-23 15:28 GMT+02:00 Peter Uhnák :
>
>
> On Wed, May 23, 2018 at 6:42 AM, Ben Coman  wrote:
>>
>>
>>
>> On 22 May 2018 at 23:23, Tim Mackinnon  wrote:
>>>
>>> Hi - when trying out the new Iceberg with a bunch of developers and
>>> explaining the challenges of integrating git and files into a smalltalk
>>> realm of the image - there was a lot of interest in how this works.
>>>
>>> When you clone - you obviously see a series of files (in Tonel - nice)
>>> that are then brought into your image. If you edit a file like Readme.md
>>> (using a markdown editor) you will notice that git status will show you that
>>> this file has changed. However if you then edit some methods - and then look
>>> in the file system - git status doesn’t show these? This in retrospect
>>> possibly feels weird - or does it? I’m not sure anymore - and was wondering
>>> if there was a specific reason behind not mirroring code changes back to the
>>> file system as they happen?
>>
>>
>> I guess the conceptual model they have might be of Pharo as a text editor
>> directly changing the files.
>> Its interesting to consider how that would operate.  Changes are
>> immediately reflected in Epcia files,
>> and used to be immediately written to ".changes" file, so it seems
>> possible.
>
>
> This is indeed valuable when things go wrong.

At a point, I was considering using git as the changes file (every
method save and compile in Pharo -> a commit in git)

Didn't try to see if git would handle the load.

>> More interesting is what to do if the text file is edited outside Pharo.
>> If Pharo could observe this and then recompile the new file,
>> we might suddenly have a workable "external editor" workflow,
>> lack of which is a common complaint by some.
>
>
> I don't believe that it should be Pharo's concern to waste effort on
> supporting external editors -- it is throwing so much value of Pharo.
>
> That being said, until git conflicts can be resolved inside Pharo, it is
> necessary to be able to edit the files by hand. The ability to run the
> hand-resolved code without committing it (to verify it still works/compiles)
> seems like a worthwhile feature.

Good point.

>> However if you then edit some methods - and then look in the file system -
>> git status doesn’t show these? This in retrospect possibly feels weird - or
>> does it?
>
>
> With Iceberg you have two separate working copies. It is not weird from git
> perspective, however it is a rather unique setup -- even seasoned git users
> might say... "You can do that? :-o" :) (And yes, it adds some extra cost,
> but nothing is perfect.)

I considered eliminating one of the working copy when in Pharo, by
cloning repositories in RAW mode (without working tree). What you
wrote (the git fast-import layer) allows you to do that. But, to be
able to pull, you need to be able to be able to do a merge (and
resolve conflicts)... in Pharo memory.

Thierry

> Peter

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

[Thierry Goubier]

Le 04/05/2018 à 21:13, Denis Kudriashov a écrit :


2018-05-04 21:10 GMT+03:00 Richard Sargent 
>:


On Fri, May 4, 2018 at 1:04 PM, Denis Kudriashov
mailto:dionisi...@gmail.com>> wrote:


2018-05-04 19:45 GMT+03:00 Sean P. DeNigris
mailto:s...@clipperadams.com>>:

Ramon Leon-5 wrote
> And my point made; I don't even know what that means.

Ha ha, I googled it and even after seeing the definition
still didn't
understand - we must be getting old ;-)

Regarding the use of acronyms - while I agree with you as a
general
principle, I wonder about this case. Since the argument IIUC
is that "a
general user won't know the domain well enough to understand
the acronym",
would they understand "abstractSyntaxTree"?! 



Now I am wonder: is it really correct to call syntax tree as
abstract when it is really implemented?
AST is very known term but now when I read it word by word I
have such questions :).


In computer science, an*abstract syntax tree*(AST), or just *syntax
tree*, is a*tree*representation of the*abstract syntactic *structure
of source code written in a programming language.
[Wikipedia]


I know it. But my stupid question is why it's still called abstract 
while it is implemented for concrete language?


This is to make the difference between the parse tree (or concrete 
syntax tree) and the transformation of that parse tree into an abstract 
syntax tree (where a bunch of syntax tree nodes created by the parsing 
are removed or made absent... they are not needed to represent the code 
structure). Hence the abstract: the abstract syntax tree is an 
abstraction of the parse tree, even if it represent an exhaustive view 
of a concrete piece of code.


https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/lectures/02/Slides02.pdf, 
slide 159 onward.



That, to me, is as opaque as
the acronym for one not acquainted with the domain, and may
buy us little at
the cost of a good amount of extra typing. Maybe keep the
acronym and add a
good method comment…



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

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

[Thierry Goubier]

signed long is now specified as:

 Capable of containing at least the [−2,147,483,647, +2,147,483,647] range;

so at least 32 bits;

and signed long long

Capable of containing at least the [−9,223,372,036,854,775,807,
+9,223,372,036,854,775,807] range [C99]

so at least 64 bits;

and long long size >= long size

So a 32 bits long is legal, as well as a 64bits long, and as well as a
256bits long :)

2018-04-19 10:30 GMT+02:00 Andres Valloud :
> The relevant spec does not state 'long' is of any particular size.
>
> On 4/19/18 1:24 , Serge Stinckwich wrote:
>>
>>
>>
>> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich
>> mailto:serge.stinckw...@gmail.com>> wrote:
>>
>> I try to understand differences between 32 bits and 64 bits FFI
>> support for C structures.
>>
>> I build a class called MyStruct subclass of FFIExternalStructure.
>> and define a layout for this structure like this one :
>>
>> MyStruct class>>fieldsDesc
>> "self rebuildFieldAccessors"
>>
>> ^ #(
>> int index ;)
>>
>> and then I generate automatically the field accessors.
>>
>> If I use a 32 bit VM, the following method is generated to access
>> the index field :
>>
>> index
>> "This method was automatically generated"
>> ^handle signedLongAt: OFFSET_INDEX
>>
>> and if I use a 64 bits VM, the same method is generated ...
>>
>> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32
>> bits VM, they have different for 64 bits VM (sizeof(int) = 4 and
>> sizeof(long) = 8).
>>
>> Someone to explain me or this is a bug ?
>>
>>
>> Ok I have understood ...
>>
>> signedLongAt: method does not return a long as the name seems to
>> indicate but in fact a 32 bits integer.
>> So it works in both 32 and 64 bits VM.
>>
>> Maybe signedInt32At: would have been a better name :-)
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."
>>
>> http://www.doesnotunderstand.org/
>
>

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

[Thierry Goubier]

2018-04-19 10:24 GMT+02:00 Serge Stinckwich :

>
>
> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> I try to understand differences between 32 bits and 64 bits FFI support
>> for C structures.
>>
>> I build a class called MyStruct subclass of FFIExternalStructure.
>> and define a layout for this structure like this one :
>>
>> MyStruct class>>fieldsDesc
>> "self rebuildFieldAccessors"
>>
>> ^ #(
>> int index ;)
>>
>> and then I generate automatically the field accessors.
>>
>> If I use a 32 bit VM, the following method is generated to access the
>> index field :
>>
>> index
>> "This method was automatically generated"
>> ^handle signedLongAt: OFFSET_INDEX
>>
>> and if I use a 64 bits VM, the same method is generated ...
>>
>> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM,
>> they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8).
>>
>> Someone to explain me or this is a bug ?
>>
>>
> ​Ok I have understood ...
>
> signedLongAt: method does not return a long as the name seems to indicate
> but in fact a 32 bits integer.
> So it works in both 32 and 64 bits VM.
>
> Maybe signedInt32At: would have been a better name :-) ​
>

Maybe this is because long in C does not guarantee 64bits, only long long
does.

Thierry



>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>

Re: [Pharo-users] Where do we go now ?

[Thierry Goubier]

Le sam. 14 avr. 2018 10:46, Hilaire  a écrit :

> Le 13/04/2018 à 19:49, Stephane Ducasse a écrit :
> > We know where we go (we have a roadmap) and this is always the same
> > and we are getting there. Tell me one smalltalk that is bootstrapped.
> I don't see we are there yet. At least from my humble point of view the
> bootstrap still looks like WIP.
>

However, for pragmatic software deployments, working out of the minimal
image is a nice improvement. The best of both world: full featured when
needed, concise when needed.

Thierry


>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Failure with GitFileTree commiting changes in Traits

[Thierry Goubier]

Done.

Thierry

Le 05/04/2018 à 20:47, Thierry Goubier a écrit :

Beware, I have not yet ported the fixes on the pharo7.0_dev branch.

Will do it now.

If I manage to get the zero-conf script to work...

Thierry

Le 05/04/2018 à 17:12, Sean P. DeNigris a écrit :

Rafael Luque wrote

This is what I call an express super support service.


:)



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

Re: [Pharo-users] Failure with GitFileTree commiting changes in Traits

[Thierry Goubier]

Beware, I have not yet ported the fixes on the pharo7.0_dev branch.

Will do it now.

If I manage to get the zero-conf script to work...

Thierry

Le 05/04/2018 à 17:12, Sean P. DeNigris a écrit :

Rafael Luque wrote

This is what I call an express super support service.


:)



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

Re: [Pharo-users] Failure with GitFileTree commiting changes in Traits

[Thierry Goubier]

2018-04-05 15:53 GMT+02:00 Rafael Luque :
> Thierry, it work like a charm.
>
> This is what I call an express super support service.

> Thank you!!

Thank you as well for testing it :)

Thierry


> 2018-04-05 12:28 GMT+00:00 Thierry Goubier :
>>
>> Hi Raphaël,
>>
>> I've pushed a fix on the first count (ConfigurationOfGitFileTree
>> refers to the stable pharo6.0 branch) and I've
>> added a fix on the pharo6.0_dev branch (which is an almost complete
>> rewrite of the metadata-less filetree
>> write, with probably significant performance gains).
>>
>> Just tell me if it works for you.
>>
>> Thierry
>>
>> 2018-04-05 14:03 GMT+02:00 Thierry Goubier :
>> > Hi Raphaël,
>> >
>> > I'll have a look and change the branch to be the pharo6.0 (and non
>> > _dev for now).
>> >
>> > Regards,
>> >
>> > Thierry
>> >
>> > 2018-04-05 11:58 GMT+02:00 Rafael Luque :
>> >> Hello all,
>> >>
>> >> I'm getting the below error each time a try to commit changes in Traits
>> >> in a
>> >> project that uses GitFileTree and Pharo 6.0.
>> >>
>> >> I've noticed that ConfigurationOfGitFileTree loads (for Pharo 6.0)
>> >> FileTree
>> >> from:
>> >>
>> >> github://dalehenrich/filetree:pharo6.0_dev/repository/
>> >>
>> >> If I update to use the "pharo6.0" branch instead of "pharo6.0_dev" then
>> >> I
>> >> can commit the changes without error.
>> >>
>> >> By the way, should not the "stable" version of GitFileTree depends on
>> >> an
>> >> stable branch of FileTree, instead of the development branch?
>> >>
>> >> This is the stack trace of the error I get:
>> >>
>> >> =
>> >>
>> >> UndefinedObject(Object)>>doesNotUnderstand: #select:thenCollect:
>> >> MCTraitDefinition(MCClassDefinition)>>selectVariables:
>> >> MCTraitDefinition(MCClassDefinition)>>instVarNames
>> >> MCGitFileTreeWriter>>buildClassDefinition:
>> >> MCGitFileTreeWriter>>writeClassDefinition:in:
>> >> [ :each |
>> >> self
>> >> writeClassDefinition: each
>> >> in: aPackagePath , '/' , each className , '.class' ] in
>> >> MCGitFileTreeWriter>>writeClassDefinitions:in:
>> >> OrderedCollection>>do:
>> >> MCGitFileTreeWriter>>writeClassDefinitions:in:
>> >> [ :job |
>> >> job title: 'Building snapshot'.
>> >> orderedDefinitions := MCDependencySorter
>> >> sortItems: aSnapshot definitions.
>> >> job progress: 0.1.
>> >> classDefinitions := orderedDefinitions
>> >> select: [ :e | e isKindOf: MCClassDefinition ].
>> >> traitDefinitions := orderedDefinitions
>> >> select: [ :e |
>> >> (e isKindOf: MCTraitDefinition)
>> >> or: [ e isKindOf: MCClassTraitDefinition ] ].
>> >> classAndTraitNames := (classDefinitions , traitDefinitions
>> >> collect: [ :e | e className ]) asSet.
>> >> job progress: 0.2.
>> >> methodDefinitions := orderedDefinitions
>> >> select: [ :e |
>> >> (e isKindOf: MCMethodDefinition)
>> >> and: [ classAndTraitNames includes: e className ] ].
>> >> extensionMethodDefinitions := orderedDefinitions
>> >> select: [ :e |
>> >> (e isKindOf: MCMethodDefinition)
>> >> and: [ (classAndTraitNames includes: e className) not ] ].
>> >> organization := orderedDefinitions
>> >> select: [ :e | e isKindOf: MCOrganizationDefinition ].
>> >> extensionClasses := (extensionMethodDefinitions
>> >> collect: [ :e | e className ]) asSet.
>> >> job progress: 0.3.
>> >> self outputFileDelete: aPackagePath.
>> >> self writePackageGitPropertiesIn: aPackagePath.
>> >> self writeOrganization: organization in: aPackagePath.
>> >> job progress: 0.4.
>> >> self writeClassDefinitions: classDefinitions in: aPackagePath.
>> >> self writeTraitDefinitions: traitDefinitions in: aPackagePath.
>> >> job progress: 0.5.
>> >> self writeMethodDefinitions: methodDefinitions in: aPackagePath.
>> >> job progress: 0.6.
>> >> self writeExtensionClassDefinitions: extensionClasses in: aPackagePath.
>> >> self

Re: [Pharo-users] Failure with GitFileTree commiting changes in Traits

[Thierry Goubier]

Hi Raphaël,

I've pushed a fix on the first count (ConfigurationOfGitFileTree
refers to the stable pharo6.0 branch) and I've
added a fix on the pharo6.0_dev branch (which is an almost complete
rewrite of the metadata-less filetree
write, with probably significant performance gains).

Just tell me if it works for you.

Thierry

2018-04-05 14:03 GMT+02:00 Thierry Goubier :
> Hi Raphaël,
>
> I'll have a look and change the branch to be the pharo6.0 (and non
> _dev for now).
>
> Regards,
>
> Thierry
>
> 2018-04-05 11:58 GMT+02:00 Rafael Luque :
>> Hello all,
>>
>> I'm getting the below error each time a try to commit changes in Traits in a
>> project that uses GitFileTree and Pharo 6.0.
>>
>> I've noticed that ConfigurationOfGitFileTree loads (for Pharo 6.0) FileTree
>> from:
>>
>> github://dalehenrich/filetree:pharo6.0_dev/repository/
>>
>> If I update to use the "pharo6.0" branch instead of "pharo6.0_dev" then I
>> can commit the changes without error.
>>
>> By the way, should not the "stable" version of GitFileTree depends on an
>> stable branch of FileTree, instead of the development branch?
>>
>> This is the stack trace of the error I get:
>>
>> =
>>
>> UndefinedObject(Object)>>doesNotUnderstand: #select:thenCollect:
>> MCTraitDefinition(MCClassDefinition)>>selectVariables:
>> MCTraitDefinition(MCClassDefinition)>>instVarNames
>> MCGitFileTreeWriter>>buildClassDefinition:
>> MCGitFileTreeWriter>>writeClassDefinition:in:
>> [ :each |
>> self
>> writeClassDefinition: each
>> in: aPackagePath , '/' , each className , '.class' ] in
>> MCGitFileTreeWriter>>writeClassDefinitions:in:
>> OrderedCollection>>do:
>> MCGitFileTreeWriter>>writeClassDefinitions:in:
>> [ :job |
>> job title: 'Building snapshot'.
>> orderedDefinitions := MCDependencySorter
>> sortItems: aSnapshot definitions.
>> job progress: 0.1.
>> classDefinitions := orderedDefinitions
>> select: [ :e | e isKindOf: MCClassDefinition ].
>> traitDefinitions := orderedDefinitions
>> select: [ :e |
>> (e isKindOf: MCTraitDefinition)
>> or: [ e isKindOf: MCClassTraitDefinition ] ].
>> classAndTraitNames := (classDefinitions , traitDefinitions
>> collect: [ :e | e className ]) asSet.
>> job progress: 0.2.
>> methodDefinitions := orderedDefinitions
>> select: [ :e |
>> (e isKindOf: MCMethodDefinition)
>> and: [ classAndTraitNames includes: e className ] ].
>> extensionMethodDefinitions := orderedDefinitions
>> select: [ :e |
>> (e isKindOf: MCMethodDefinition)
>> and: [ (classAndTraitNames includes: e className) not ] ].
>> organization := orderedDefinitions
>> select: [ :e | e isKindOf: MCOrganizationDefinition ].
>> extensionClasses := (extensionMethodDefinitions
>> collect: [ :e | e className ]) asSet.
>> job progress: 0.3.
>> self outputFileDelete: aPackagePath.
>> self writePackageGitPropertiesIn: aPackagePath.
>> self writeOrganization: organization in: aPackagePath.
>> job progress: 0.4.
>> self writeClassDefinitions: classDefinitions in: aPackagePath.
>> self writeTraitDefinitions: traitDefinitions in: aPackagePath.
>> job progress: 0.5.
>> self writeMethodDefinitions: methodDefinitions in: aPackagePath.
>> job progress: 0.6.
>> self writeExtensionClassDefinitions: extensionClasses in: aPackagePath.
>> self
>> writeExtensionMethodDefinitions: extensionMethodDefinitions
>> in: aPackagePath.
>> job progress: 0.7.
>> self writeInitializers: methodDefinitions in: aPackagePath ] in
>> MCGitFileTreeWriter>>writeSnapshot:in:
>> BlockClosure>>cull:
>> [ ^ block cull: self ] in [ self prepareForRunning.
>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run
>> [ activeProcess psValueAt: index put: anObject.
>> aBlock value ] in CurrentJob(DynamicVariable)>>value:during:
>> BlockClosure>>ensure:
>> CurrentJob(DynamicVariable)>>value:during:
>> CurrentJob class(DynamicVariable class)>>value:during:
>> [ self prepareForRunning.
>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run
>> BlockClosure>>ensure:
>> Job>>run
>> MCGitFileTreeWriter>>writeSnapshot:in:
>> [ :each |
>> | packageDir |
>> packageDir := subDirectoryString , each package name , '.package'.
>> aWriter writeSnapshot: each snapshot in: packageDir.
>> aWriter
>> outputFile

Re: [Pharo-users] Failure with GitFileTree commiting changes in Traits

[Thierry Goubier]

Hi Raphaël,

I'll have a look and change the branch to be the pharo6.0 (and non
_dev for now).

Regards,

Thierry

2018-04-05 11:58 GMT+02:00 Rafael Luque :
> Hello all,
>
> I'm getting the below error each time a try to commit changes in Traits in a
> project that uses GitFileTree and Pharo 6.0.
>
> I've noticed that ConfigurationOfGitFileTree loads (for Pharo 6.0) FileTree
> from:
>
> github://dalehenrich/filetree:pharo6.0_dev/repository/
>
> If I update to use the "pharo6.0" branch instead of "pharo6.0_dev" then I
> can commit the changes without error.
>
> By the way, should not the "stable" version of GitFileTree depends on an
> stable branch of FileTree, instead of the development branch?
>
> This is the stack trace of the error I get:
>
> =
>
> UndefinedObject(Object)>>doesNotUnderstand: #select:thenCollect:
> MCTraitDefinition(MCClassDefinition)>>selectVariables:
> MCTraitDefinition(MCClassDefinition)>>instVarNames
> MCGitFileTreeWriter>>buildClassDefinition:
> MCGitFileTreeWriter>>writeClassDefinition:in:
> [ :each |
> self
> writeClassDefinition: each
> in: aPackagePath , '/' , each className , '.class' ] in
> MCGitFileTreeWriter>>writeClassDefinitions:in:
> OrderedCollection>>do:
> MCGitFileTreeWriter>>writeClassDefinitions:in:
> [ :job |
> job title: 'Building snapshot'.
> orderedDefinitions := MCDependencySorter
> sortItems: aSnapshot definitions.
> job progress: 0.1.
> classDefinitions := orderedDefinitions
> select: [ :e | e isKindOf: MCClassDefinition ].
> traitDefinitions := orderedDefinitions
> select: [ :e |
> (e isKindOf: MCTraitDefinition)
> or: [ e isKindOf: MCClassTraitDefinition ] ].
> classAndTraitNames := (classDefinitions , traitDefinitions
> collect: [ :e | e className ]) asSet.
> job progress: 0.2.
> methodDefinitions := orderedDefinitions
> select: [ :e |
> (e isKindOf: MCMethodDefinition)
> and: [ classAndTraitNames includes: e className ] ].
> extensionMethodDefinitions := orderedDefinitions
> select: [ :e |
> (e isKindOf: MCMethodDefinition)
> and: [ (classAndTraitNames includes: e className) not ] ].
> organization := orderedDefinitions
> select: [ :e | e isKindOf: MCOrganizationDefinition ].
> extensionClasses := (extensionMethodDefinitions
> collect: [ :e | e className ]) asSet.
> job progress: 0.3.
> self outputFileDelete: aPackagePath.
> self writePackageGitPropertiesIn: aPackagePath.
> self writeOrganization: organization in: aPackagePath.
> job progress: 0.4.
> self writeClassDefinitions: classDefinitions in: aPackagePath.
> self writeTraitDefinitions: traitDefinitions in: aPackagePath.
> job progress: 0.5.
> self writeMethodDefinitions: methodDefinitions in: aPackagePath.
> job progress: 0.6.
> self writeExtensionClassDefinitions: extensionClasses in: aPackagePath.
> self
> writeExtensionMethodDefinitions: extensionMethodDefinitions
> in: aPackagePath.
> job progress: 0.7.
> self writeInitializers: methodDefinitions in: aPackagePath ] in
> MCGitFileTreeWriter>>writeSnapshot:in:
> BlockClosure>>cull:
> [ ^ block cull: self ] in [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in CurrentJob(DynamicVariable)>>value:during:
> BlockClosure>>ensure:
> CurrentJob(DynamicVariable)>>value:during:
> CurrentJob class(DynamicVariable class)>>value:during:
> [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run
> BlockClosure>>ensure:
> Job>>run
> MCGitFileTreeWriter>>writeSnapshot:in:
> [ :each |
> | packageDir |
> packageDir := subDirectoryString , each package name , '.package'.
> aWriter writeSnapshot: each snapshot in: packageDir.
> aWriter
> outputFileModify: packageDir , '/monticello.meta/package'
> with: '(name ''' , each package name , ''')'.
> aWriter writeDependencies: each dependencies in: packageDir ] in
> MCGitFileTreeWriter class>>fileOutAll:on:
> OrderedCollection>>do:
> MCGitFileTreeWriter class>>fileOutAll:on:
> MCFileTreeGitRepository>>fiStoreVersions:
> MCFileTreeGitRepository>>fiStoreVersion:
> MCFileTreeGitRepository>>basicStoreVersion:
> MCFileTreeGitRepository(MCRepository)>>storeVersion:
> MCFileTreeGitRepository(MCFileBasedRepository)>>storeVersion:
> MCWorkingCopyBrowser>>storeVersion:in:
> [ self
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository ] in [ [ self
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository ]
> ensure: [ (MCVersionInspector new version: newVersion) show ] ] in
> MCWorkingCopyBrowser>>basicSaveVersionIn:
> BlockClosure>>ensure:
> [ [ self
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository ]
> ensure: [ (MCVersionInspector new version: newVersion) show ] ] in
> MCWorkingCopyBrowser>>basicSaveVersionIn:
> BlockClosure>>ensure:
> CursorWithMask(Cursor)>>showWhile:
> MCWorkingCopyBrowser>>basicSaveVersionIn:
> [ self basicSaveVersionIn: self repository ] in
>

Re: [Pharo-users] Slower

[Thierry Goubier]

Le 04/04/2018 à 19:31, Hilaire a écrit :
It is already animated :) 
https://twitter.com/GNUDrGeo/status/981583820037160961


But canvas get slow when I push to 500 montecarlo iterations, for example.


Can you profile a refresh / a redraw?

We've seen many times Morphic being qualified as slow, and the culprit 
were very badly programmed widgets.


Thierry



Le 04/04/2018 à 19:03, Stephane Ducasse a écrit :

Hilaire

do you want to see an animation?

Stef

Re: [Pharo-users] Howto BaselineOf

[Thierry Goubier]

2018-04-03 16:31 GMT+02:00 Hilaire :
> Probably, but my hands are already full.

Mine as well :(

I still believe a "release" kind of script could help, associated with
a project: update the baselineOf, save everything with a nice commit,
tag the commit, done.

I would need one for OSProcess, and for the GitFileTree-MergeDriver.

But it's kind of specific to the way you package DrGeo, so no single
command would fit.

Thierry

>
>
>
> Le 03/04/2018 à 15:52, Thierry Goubier a écrit :
>>
>> Couldn't you call a bazaar routine to get that information?
>>
>> Writing a specific method with the version number on each release is a
>> bit of a pain, to have practised that before.
>> Unless you write a release command that adds the code and do the
>> necessary stuff to package the release.
>>
>> Thierry
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Howto BaselineOf

[Thierry Goubier]

2018-04-03 15:25 GMT+02:00 Hilaire :
> I don't use github. I will just use a class method returning a version
> number.

Couldn't you call a bazaar routine to get that information?

Writing a specific method with the version number on each release is a
bit of a pain, to have practised that before.
Unless you write a release command that adds the code and do the
necessary stuff to package the release.

Thierry


>
> Le 03/04/2018 à 14:14, Thierry Goubier a écrit :
>>
>> Normally, you should do it via the repository url. If you use tags in
>> your repository management and integration
>> into Monticello (like filetree and gitfiletree), you can retrieve a
>> branch or tag name by scanning the repository
>> url: for example, github://XX/DrGeo:18.06/src.
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Howto BaselineOf

[Thierry Goubier]

Hi Hilaire,

2018-04-03 12:40 GMT+02:00 Hilaire :
> Ok, adding the package names was needed in the baseline and resolved the
> remaining errors:
>
> spec package: 'DrGeoII-core'; package: 'DrGeoII-Polymorph'; etc.
>
> Now I would like to insert in the BaselineOf a version number more
> meaningfull than 
>
> I want to extract from 'BaselineOfDrGeo project version' an object with a
> DrGeo release number (aka 18.06, etc.)
>
> How can I insert it in the BaselineOfDrGeo?

Normally, you should do it via the repository url. If you use tags in
your repository management and integration
into Monticello (like filetree and gitfiletree), you can retrieve a
branch or tag name by scanning the repository
url: for example, github://XX/DrGeo:18.06/src.

Thierry

>
>
> Le 03/04/2018 à 12:20, Hilaire a écrit :
>>
>> Moving the BaselineOfDrGeo out of the ConfigurationOfDrGeo package in the
>> file based tonel helps to get over this error. More error followed but need
>> to be examined.
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Howto BaselineOf

[Thierry Goubier]

Hi Hilaire,

try

Metacello new
baseline: 'DrGeo';
repository: 'tonel://', SmalltalkImage current imageDirectory
pathString, '/src';
load

Thierry


2018-04-03 10:34 GMT+02:00 Hilaire :
> Hi,
>
> I have this enclosed BaselineOfDrGeo which I think contains mostly all I
> need.
>
> How should I load it? This code bellow does not work:
>
> (BaselineOfDrGeo project version: #development) load.
>
> By the way the PharoDebug log file is not recorded along the image, but at
> the user root directory. Is it  wished?
>
> ...
>
>
> --
> Dr. Geo
> http://drgeo.eu
>

Re: [Pharo-users] unsolicited package-cache use

[Thierry Goubier]

Hi Hilaire,

a BaselineOf is the same as a baseline method in a ConfigurationOf: a 
list of packages with their prerequisites and groups.


What the BaselineOf does not contain are methods describing versions 
with package versions and author names; instead, what a BaselineOf says 
is: fetch the latest(*) version(**) of each package I have listed in my 
baseline from the repository you found me in(***).


Thierry

(*) if there is more than one. With git, only one, with smalltalkhub, 
more than one.


(**) a repository is supposed to contain package versions, even if that 
version is -cypress.1 (metadata-less filetree).


(***) A repository here is a http one (i.e. smalltalkhub), a directory 
in a branch in git, a tag in git, a directory on disk, a ftp directory, 
etc...


PS: the power of Baselines + Git comes from the fact that you get a 
repository per branch / per tag.


PS2: it is possible to have multiple repositories, and rewrite as 
"latest version ... in the repositories... ". I have a use case or two 
for that feature.


Le 02/04/2018 à 15:46, Hilaire a écrit :

Hi Dale,

Sorry to reply very lately to your help email, I am getting slow on 
Pharo those those days.


I am afraid to be a bit out of sync: what is a BaselineOf? I only have a 
ConfigurationOfDrGeo and baseline methods into.


Hilaire


Le 18/01/2018 à 16:10, Dale Henrichs a écrit :


Hilaire,

Have you included a method in your BaselineOf that looks like this:

    projectClass

        ^ MetacelloCypressBaselineProject

if not, then what looks like a package-cache problem could be that you 
haven't told Metacello that you are using a metadataless 
filetree/tonel repository.


Metacello has an internal rule to not load Monticello packages of the 
same version, since they are already loaded. However, when using 
metadataless repositories the filetree/tonel Monticello package 
readers typically generate a package name using the author/version 
`-cypress.1`, which make Metacello think that the versions are the 
same and the package is not loaded ... by including the above method 
in your baselineof, Metacello will know to ignore the Monticello 
author/version of the package and always load it


Of course, because Monticello only installs changed definitions when 
loading a package, "loading the same package over and over again" 
costs a little bit in loading the _definitions_ into the image from 
disk, but doesn't end up compiling any new methods or creating new 
classes ...


Dale

On 1/18/18 6:49 AM, Hilaire wrote:
It was a month ago; I don't remember the details but from what I can 
recover from my memory the scenario was:


- From my dev. environment I saved code through Tonel, in the DrGeo 
used CVS.


- When building, I specifically ask the code saved thought Tonel to 
be installed but the package-cache code version was used instead. It 
could be out of sync.



Le 18/01/2018 à 15:22, Dale Henrichs a écrit :

Hilaire,

Metacello just uses Monticello for loading and it is Monticello that 
is using the package-cache ... if there were a way to turn of the 
package-cache for Monticello I don't think that Metacello would know 
the difference.


But, I am curious why you care whether or not package is used?

Is there a specific problem that you are having?

Dale 

Re: [Pharo-users] What are RBPattern* classes in the AST?

[Thierry Goubier]

Hi Steven,

Le 31/03/2018 à 20:36, Steven Costiou a écrit :

Hi,

i was browsing the classes of the AST and i am curious about the 
RBPattern* classes.



What are they used for?


They represent metavariables in pattern trees when you use refactorings. 
Each pattern node specify a type of AST subtree that may be in that 
place when you match some smalltalk source code against a refactoring 
pattern. Once matched, an unification is done so that you can refer to 
that metavariable content by name (for example, retrieve the top node of 
that variable subtree).


The RBPatternParser's comment says that it is used "to search and 
transform source code".


Exactly.

After looking a bit in the senders and class refs, it seems it is used 
for refactorings and other stuff.


Refactorings and searches.


But is that used at some point in code compilation?


No. But they could be used... if you do source to source transformations 
when compiling, for example, you could use such patterns to rewrite the 
code before compiling it; SmaCC for one uses that (create generic 
methods, then scan all methods with a set of refactorings to rewrite an 
optimised version of the code, such as merging contiguous character 
equality tests).


For reference, have a look at:

https://www.slideshare.net/pharoproject/smack-behind-the-refactorings

Slide 31 describes the RB specifics, and the rest of the slides describe 
more in detail where those pattern nodes are found and used.


Regards,

Thierry




Steven.

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Thierry Goubier]

2018-03-20 13:20 GMT+01:00 Henrik Sperre Johansen
:
> EstebanLM wrote
>>> On 20 Mar 2018, at 12:56, Henrik Sperre Johansen <
>
>> henrik.s.johansen@
>
>> > wrote:
>>>
>>> This is great!
>>> And, +1 on the need for some more convenience constructors...
>>>
>>> Word of warning (which would be nice to mention in the guide); using
>>> writeStreamDo: and manually constructed buffered writers will not #flush
>>> the
>>> buffered stream automatically on close, so it's crucial this is done
>>> manually.
>>
>> well… in fact it should flush it, isn’t?
>>
>>>
>
> The binary filestream flushes to disk on each write operation iirc (or, at
> least when it is being closed), but it has no way to know it is wrapped by a
> buffered stream which also needs to be flushed to actually write the
> remaining buffer contents to file.

Could a binary filestream that has flush requirements (and close
requirements as well) be made aware of the presence of the buffered
stream above it to ensure a close / flush is done correctly?

Could structures where you have multiple buffered streams concurrently
opened on a single binary file stream considered as not exactly
correct?

Thierry

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

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

[Thierry Goubier]

2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe :
>
>
>> On 9 Feb 2018, at 06:40, Thierry Goubier  wrote:
>>
>> Le 09/02/2018 à 00:46, Arturo Zambrano a écrit :
>>> I used Roassal + OSM and worked perfectly (2 year ago at least). Although I 
>>> think there is no support for something like a tiles cache.
>>
>> We did the OSM support with an in-image tiles cache, but limited to the 
>> current map section being viewed.
>>
>> It would be easy to add an on-disk cache to that code.
>>
>> Thierry
>>
>>> On Thu, Feb 8, 2018 at 7:46 AM, Cédrick Béler >> <mailto:cdric...@gmail.com>> wrote:
>>>Hello,
>>>I would like to have a representation of a map in the image to show
>>>(my) GPS coordinates.
>>>I haven’t really tried nor searched yet but I’ve seen Roassal
>>>examples that could do the job, especially the Open Street Map
>>>integration.
>>>So does people here have advices on how to to that (having a morph
>>>that shows a map and positions) ?
>>>Ideally I would like to have it work offline (meaning I download
>>>first tiles…or a vectorized map would do the job too).
>>>TIA,
>>>Cédrick
>
> Thierry,
>
> Where are the load instructions ? Does it still work for Pharo 7 ?

It should still be part of Roassal, with some issues with the data
sources used to retrieve cities coordinates (they went offline!).

I haven't started working with Pharo 7 yet, so I can't say.

Thierry

> Sven
>
>

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

[Thierry Goubier]

Le 09/02/2018 à 00:46, Arturo Zambrano a écrit :
I used Roassal + OSM and worked perfectly (2 year ago at least). 
Although I think there is no support for something like a tiles cache.


We did the OSM support with an in-image tiles cache, but limited to the 
current map section being viewed.


It would be easy to add an on-disk cache to that code.

Thierry

On Thu, Feb 8, 2018 at 7:46 AM, Cédrick Béler > wrote:


Hello,

I would like to have a representation of a map in the image to show
(my) GPS coordinates.

I haven’t really tried nor searched yet but I’ve seen Roassal
examples that could do the job, especially the Open Street Map
integration.

So does people here have advices on how to to that (having a morph
that shows a map and positions) ?
Ideally I would like to have it work offline (meaning I download
first tiles…or a vectorized map would do the job too).

TIA,

Cédrick

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Thierry Goubier]

Hi Stef,

it's the one done with Damien, 3 or 4 years ago.

Thierry

2018-01-11 8:23 GMT+01:00 Stephane Ducasse :

> Hi Thierry
>
> One of these days I think that I will have to have a look at it :)
>
> Stef
>
> On Wed, Jan 10, 2018 at 2:35 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>>
>>
>> 2018-01-10 14:26 GMT+01:00 Serge Stinckwich :
>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 2:23 PM, Julien 
>>> wrote:
>>>
>>>> Hello Serge,
>>>>
>>>> Do you mean pieces of code you wrote in Python using Numpy that you
>>>> want to transform to Smalltalk code using PolyMath?
>>>>
>>>> It’s kind of the other way around of this project. :-)
>>>>
>>>>
>>> ​yes this is exactly the opposite :-(​
>>> ​I guess I need a Python parser and after that I can do AST
>>> transformation ...
>>>
>>
>> Hi Serge,
>>
>> there is a Python2.7 parser with AST that could be used.
>>
>> Thierry
>>
>>
>>> Or using regex I can do basic stuff ...​
>>>
>>> --
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (IRD/UPMC/UY1)
>>> "Programs must be written for people to read, and only incidentally for
>>> machines to execute."http://www.doesnotunderstand.org/
>>>
>>
>>
>

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Thierry Goubier]

2018-01-10 14:41 GMT+01:00 Serge Stinckwich :

>
>
> On Wed, Jan 10, 2018 at 2:35 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>>
>>
>> 2018-01-10 14:26 GMT+01:00 Serge Stinckwich :
>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 2:23 PM, Julien 
>>> wrote:
>>>
>>>> Hello Serge,
>>>>
>>>> Do you mean pieces of code you wrote in Python using Numpy that you
>>>> want to transform to Smalltalk code using PolyMath?
>>>>
>>>> It’s kind of the other way around of this project. :-)
>>>>
>>>>
>>> ​yes this is exactly the opposite :-(​
>>> ​I guess I need a Python parser and after that I can do AST
>>> transformation ...
>>>
>>
>> Hi Serge,
>>
>> there is a Python2.7 parser with AST that could be used.
>>
>
>
> ​yes I might have a look ... where is the code ?
>

SmaCC on github. Look for SmaCC-Python and SmaCC-Python-Tests.If you're
using Moose,
you should be able to import just SmaCC-Python from the github repository.
There is even a
BaselineOfPythonParser, but I haven't used it.

Thierry


> ​
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Thierry Goubier]

2018-01-10 14:26 GMT+01:00 Serge Stinckwich :

>
>
> On Wed, Jan 10, 2018 at 2:23 PM, Julien 
> wrote:
>
>> Hello Serge,
>>
>> Do you mean pieces of code you wrote in Python using Numpy that you want
>> to transform to Smalltalk code using PolyMath?
>>
>> It’s kind of the other way around of this project. :-)
>>
>>
> ​yes this is exactly the opposite :-(​
> ​I guess I need a Python parser and after that I can do AST transformation
> ...
>

Hi Serge,

there is a Python2.7 parser with AST that could be used.

Thierry


> Or using regex I can do basic stuff ...​
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>

Re: [Pharo-users] Metacello with Git

[Thierry Goubier]

Hi Pierce,

Le 20/12/2017 à 17:17, Pierce Ng a écrit :

On Tue, Dec 19, 2017 at 07:07:16PM -0800, Dale Henrichs wrote:

I am under the impression that iceberg is able to authenticate with
SSH keys  I am not a pharo/iceberg user myself, but it seems
that iceberg should be able to fill that gap.


Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys.


does command line git work with those ED25519 keys?

Regards,

Thierry



Pierce

Re: [Pharo-users] Catching EOF in SmaCC

[Thierry Goubier]

Hi Andrew,

Le 17/11/2017 à 12:26, Prof. Andrew P. Black a écrit :



On 17 Nov 2017, at 14:10 , Thierry Goubier  wrote:


there is an 'E O F' token generated by SmaCC; I haven't tried to use it in a 
parser yet.


I tried patching the tokenActions table to trap on this, but the token id for E 
O F is outside of the range of the table.   The Python example that you pointed 
me to is a little different.  It overrides scannerError, and explicitly adds a 
newline token if there is an error at the end of the file.  It doesn’t actually 
use the E O F token, but it is probably a pattern that I can steal.


In all honesty, I wasn't thinking about that, but instead to be able to 
write '' in the grammar itself to terminate statements.


The Python approach is necessary because you may have to emit additional 
dedent tokens at the end of a file (this is a typical issue of those 
meaningfull identation whitespace languages: an idea used in the very 
beginning of programming languages, then considered harmfull, then 
coming back up again...).




In the meantime, I made the final StatementSeparator ( or ";") 
optional in all the productions.  The grammar is a bit ugly, but the parser is cleaner.


Which is the cleanest way to do it (at least, like that, you have a 
documented way around that instead of carrying around a grammar + hacks 
in the scanner)(*)



I also gave up trying to eliminate intermediate parseTree nodes.  Instead, I 
eliminated intermediate productions form the grammar.  This makes the grammar 
more ugly (it has several repetitions where I inlined the intermediate 
productions), but the
tree construction is a lot more straightforward.


Sorry for having been unable to answer your questions on that :( I'm 
happy to learn you've found a way around it.


Thierry

(*) Which is still way better than a hand-written, recursive descent 
parser where any line can hide a hack...



Andrew

Re: [Pharo-users] Catching EOF in SmaCC

[Thierry Goubier]

Hi Andrew,

there is an 'E O F' token generated by SmaCC; I haven't tried to use it 
in a parser yet.


The second is used in the Python2 parser. See:

https://github.com/ThierryGoubier/SmaCC/blob/master/SmaCC-Python.package/PythonScanner2.class/instance/scannerError.st

Regards,

Thierry

Le 17/11/2017 à 04:11, Prof. Andrew P. Black a écrit :

Is there a way, in SmaCC, or either

- writing a grammar production that involves EOF (end of file)
- or, writing a scanner action that is executed when EOF is read.

Andrew

Re: [Pharo-users] RB refactoring rewrite variable to a symbol

[Thierry Goubier]

Hi Peter,
Hi Peter,

you should try {:node :dic | ... } to handle that.

Something like:

RBParseTreeRewriter new
replace: '`@var `{:node :dic | dic at: #varName put: node name} := 
`@arg'
with: 'self write: `@arg into: `{:dic |
RBParser parseExpression: ''#'', (dic at: #varName) }'.

You need to adjust, I haven't checked if this is correct ;).

Thierry


Le 11/11/2017 à 17:17, Peter Uhnák a écrit :

Hi,

how can I rewrite a(n instance) variable to a symbol?

E.g.

[IN]
something: aSomething
     something := aSomething

[OUT]
something: aSomething
     self write: aSomething into: #something


I can capute the input just fine... ``@var := ``@arg
but I have no idea how to convert the var into a symbol (or string).

Thanks,
Peter

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

[Thierry Goubier]

Hi Steff,

Le 10/11/2017 à 19:17, Stephane Ducasse a écrit :

Hi thierry

we are working and soon we will have a much simpler installation and
everything :)


Out of a minimal image? That would be very cool.


Now just commit and I will check and fix :)


I committed, created a pull request and merged. It should be Ok apart from:

- can hyphenating be desactivated in ==sequences==? It is allways 
strange to see a class name or a method name split by a hypen, like in 
SmaCC-Parser


- how does one writes a reference to a section or a chapter?

Thierry



Stef

On Fri, Nov 10, 2017 at 6:47 AM, Thierry Goubier
 wrote:

Le 09/11/2017 à 21:02, Stephane Ducasse a écrit :


Yes thierry :) your turn now :)



That's will be harder than I expected. I have issues in the LaTeX setup used
by the booklet.

Thierry




Stef

On Thu, Nov 9, 2017 at 8:41 PM, Thierry Goubier
 wrote:


Le 09/11/2017 à 20:15, Federico.Balaguer a écrit :



I am following this tutorial



http://files.pharo.org/books-pdfs/booklet-Smacc/2017-05-05-Smacc-Spiral.pdf

I typed the first example and when I try to compile either LR(1) or
LALR(1)
there is a pop-up saying that both clases where not specified. I also
tried
adding the classes for the scanner and parser manually but I got the
result.




Yes. I changed the GUI and that means I need to update the booklet.

This part:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Click on the Scanner class and type ExpressionScanner.
– Click on the Parser class and type ExpressionParser.
• press either Compiler LR(1) or Compiled LALR(1) buttons.

Should now be:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Type ExpressionParser and return in the text field left of Parser:.
• press either Compiler LR(1) or Compiled LALR(1) buttons.


There are a couple other things in the tutorial at the very start that
didn't add up. I can send an annotated pdf if that is of any help




Yes, that would be very helpfull!

Thanks,

Thierry




Thanks!!

Federico



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

Re: [Pharo-users] SmaCC UI Problem solved but only when breakpoint was added

[Thierry Goubier]

Hi Frederico,

I think what is happening is one needs to accept (press return) in the
scanner and parser test fields, for the names to be taken into account.
Otherwise, they keep that non-accepted status (the orange triangle
appearing in top-right of the text fields). Can you check if it was the
case?

I will see to add either a warning or a way to trigger an accept (or an
auto-accept) on those text fields.

Regards,

Thierry




2017-11-10 13:09 GMT+01:00 Federico.Balaguer :

> Hello
>
> I am progressing with my use of SmaCC and I think a found the source of the
> problem that makes it impossible to generete the classes for the parser and
> scanner.
>
> Scenario
> 1)  I gave the name for both classes: the parser and the scanner.
> 2) I copy the very simple first part of the tutorial
> 3) I clicked on the Compile LR(1) button and a window popped up with the
> label: "Both classes are not specified"
>
> Problem:
> At the time the method SmaCCDevelopmentUI>>compile: was invoked the
> expression self parserClassString returns an empty string (although I
> entered the name of a class on the UI)
>  I found that the "parserClassMorph" did not hold the name of the class
>
> Then I breakpointed the method SmaCCDevelopmentUI>>addParseClass: and I
> entered a new name for the class of my parser and I follow with the
> debugger
> the execution that follows the invocation of the method. Everything works
> as
> expected.
>
> I changed the name again but the method SmaCCDevelopmentUI>>addParseClass:
> (the one with a breakpoint) was not called again.
>
> I think it is a problem related to Morph . I am a complete ignorant on
> Morph
> (among other things) so it is hard for me to fix the problem.
>
> I hope this message helps fix the issue
>
> Federico
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

[Thierry Goubier]

Le 09/11/2017 à 21:02, Stephane Ducasse a écrit :

Yes thierry :) your turn now :)


That's will be harder than I expected. I have issues in the LaTeX setup 
used by the booklet.


Thierry



Stef

On Thu, Nov 9, 2017 at 8:41 PM, Thierry Goubier
 wrote:

Le 09/11/2017 à 20:15, Federico.Balaguer a écrit :


I am following this tutorial


http://files.pharo.org/books-pdfs/booklet-Smacc/2017-05-05-Smacc-Spiral.pdf

I typed the first example and when I try to compile either LR(1) or
LALR(1)
there is a pop-up saying that both clases where not specified. I also
tried
adding the classes for the scanner and parser manually but I got the
result.



Yes. I changed the GUI and that means I need to update the booklet.

This part:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Click on the Scanner class and type ExpressionScanner.
– Click on the Parser class and type ExpressionParser.
• press either Compiler LR(1) or Compiled LALR(1) buttons.

Should now be:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Type ExpressionParser and return in the text field left of Parser:.
• press either Compiler LR(1) or Compiled LALR(1) buttons.


There are a couple other things in the tutorial at the very start that
didn't add up. I can send an annotated pdf if that is of any help



Yes, that would be very helpfull!

Thanks,

Thierry




Thanks!!

Federico



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

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

[Thierry Goubier]

Le 09/11/2017 à 20:15, Federico.Balaguer a écrit :

I am following this tutorial

http://files.pharo.org/books-pdfs/booklet-Smacc/2017-05-05-Smacc-Spiral.pdf

I typed the first example and when I try to compile either LR(1) or LALR(1)
there is a pop-up saying that both clases where not specified. I also tried
adding the classes for the scanner and parser manually but I got the result.


Yes. I changed the GUI and that means I need to update the booklet.

This part:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Click on the Scanner class and type ExpressionScanner.
– Click on the Parser class and type ExpressionParser.
• press either Compiler LR(1) or Compiled LALR(1) buttons.

Should now be:

• Edit the definition the pane below the compile LR(1) buttons.
• Once you are done:
– Type ExpressionParser and return in the text field left of Parser:.
• press either Compiler LR(1) or Compiled LALR(1) buttons.


There are a couple other things in the tutorial at the very start that
didn't add up. I can send an annotated pdf if that is of any help


Yes, that would be very helpfull!

Thanks,

Thierry



Thanks!!

Federico



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

Re: [Pharo-users] Unable to load SmaCC on pharo6 (or pharo5)

[Thierry Goubier]

Hi Frederico,

could you try in a Pharo6.1 image

Metacello new
baseline: 'SmaCC';
repository: 'github://ThierryGoubier/SmaCC';
load

SmaCC has a fairly complex set of dependencies, so loading it via the 
baseline should be the preferred way.


Don't hesitate to ask if you have questions on SmaCC.

Regards,

Thierry



Le 09/11/2017 à 19:06, Federico.Balaguer a écrit :

I would like to check if I need to use SmaCC for a project. I tried to
install it on Pharo 6.1 32bits with iceberg but I was not able to do it.

Then I tried to get SmaCC on an Pharo5 and Pharo6  images with "Catalog
Browser" but I was not able to do it neither. The tool did pop up a message
saying that Smacc was not tested for Pharo6 which was nice.

Then I tried to clone the git repository to my local machine,  I pointed
iceberg to that local repository and then I loaded each package by hand. I
was able to load BaselineOfSmaccBrowser but SmaCC-Rewrite-Engine failed to
load with a debugger with a list of classes and methods that are missing
(they are listed at the end of this message).

Could some give an idea how to fix this?

Thanks. Federico


This package depends on the following classes:
   SmaCCStringInterval
   SmaCCParseNodeVisitor
   SmaCCScanner
   SmaCCParseNode
   SmaCCParser
   SmaCCString
You must resolve these dependencies before you will be able to load these
definitions:
   SmaCCAnnotatedString
   SmaCCAnnotatedString>>#addAnnotationTo:
   SmaCCAnnotatedString>>#intervalClass
   SmaCCAnnotatedString>>#newIntervalFor:
   SmaCCAnnotatedString>>#node
   SmaCCAnnotatedString>>#node:
   SmaCCAnnotatedString>>#removeInterval:
   SmaCCAnnotatedString>>#rule
   SmaCCAnnotatedString>>#rule:
   SmaCCAnnotatedStringInterval
   SmaCCAnnotatedStringInterval>>#addAllAnnotations:
   SmaCCAnnotatedStringInterval>>#addAnnotation:
   SmaCCAnnotatedStringInterval>>#annotations
   SmaCCAnnotatedStringInterval>>#annotations:
   SmaCCAnnotatedStringInterval>>#canBeMergedWith:
   SmaCCAnnotatedStringInterval>>#postCopy
   SmaCCCodeReplaceExpression
   SmaCCCodeReplaceExpression>>#acceptVisitor:
   SmaCCCodeReplaceExpression>>#code
   SmaCCCodeReplaceExpression>>#code:
   SmaCCCodeReplaceExpression>>#evaluateInContext:
   SmaCCCodeReplaceExpression>>#method
   SmaCCCodeReplaceExpression>>#tokenVariables
   SmaCCCompositeReplaceExpression
   SmaCCCompositeReplaceExpression>>#acceptVisitor:
   SmaCCCompositeReplaceExpression>>#compositeNodeVariables
   SmaCCCompositeReplaceExpression>>#evaluateInContext:
   SmaCCCompositeReplaceExpression>>#expressions
   SmaCCCompositeReplaceExpression>>#expressions:
   SmaCCCompositeReplaceExpression>>#initialize
   SmaCCNodeReplaceExpression
   SmaCCNodeReplaceExpression>>#acceptVisitor:
   SmaCCNodeReplaceExpression>>#addPostfixTo:inContext:
   SmaCCNodeReplaceExpression>>#addPrefixTo:inContext:
   SmaCCNodeReplaceExpression>>#afterPostfix
   SmaCCNodeReplaceExpression>>#afterPostfix:
   SmaCCNodeReplaceExpression>>#afterWhitespace
   SmaCCNodeReplaceExpression>>#afterWhitespace:
   SmaCCNodeReplaceExpression>>#beforePrefix
   SmaCCNodeReplaceExpression>>#beforePrefix:
   SmaCCNodeReplaceExpression>>#beforeWhitespace
   SmaCCNodeReplaceExpression>>#beforeWhitespace:
   SmaCCNodeReplaceExpression>>#evaluateInContext:
   SmaCCNodeReplaceExpression>>#name
   SmaCCNodeReplaceExpression>>#name:
   SmaCCNodeReplaceExpression>>#postfix
   SmaCCNodeReplaceExpression>>#postfix:
   SmaCCNodeReplaceExpression>>#prefix
   SmaCCNodeReplaceExpression>>#prefix:
   SmaCCNodeReplaceExpression>>#tokenVariables
   SmaCCReplaceExpression
   SmaCCReplaceExpression>>#acceptVisitor:
   SmaCCReplaceExpression>>#evaluateInContext:
   SmaCCReplaceExpressionParser
   SmaCCReplaceExpressionParser>>#cacheId
   SmaCCReplaceExpressionParser>>#definitionComment
   SmaCCReplaceExpressionParser>>#scannerClass
   SmaCCReplaceExpressionParser>>#startingStateForExpression
   SmaCCReplaceExpressionParser>>#reduceActionForCodeReplace1:
   SmaCCReplaceExpressionParser>>#reduceActionForExpression1:
   SmaCCReplaceExpressionParser>>#reduceActionForNodeReplace1:
   SmaCCReplaceExpressionParser>>#reduceActionForPostfixModifiers1:
   SmaCCReplaceExpressionParser>>#reduceActionForPrefixModifiers1:
   SmaCCReplaceExpressionParser>>#reduceActionForPrefixModifiers2:
   SmaCCReplaceExpressionParser>>#reduceActionForRewriteExpression3:
   SmaCCReplaceExpressionParser>>#reduceActionForRewriteExpressions1:
   SmaCCReplaceExpressionParser>>#reduceActionForRewriteExpressions2:
   SmaCCReplaceExpressionParser>>#reduceActionForStringReplace1:
   SmaCCReplaceExpressionParser>>#reduceActionForSwitchStateToCode1:
   SmaCCReplaceExpressionParser>>#reduceActionForSwitchStateToDefault1:
   SmaCCReplaceExpressionParser>>#reduceActionForSwitchStateToExpression1:
   SmaCCReplaceExpressionParser>>#reduceTable
   SmaCCReplaceExpressionParser>>#symbolNames
   SmaCCReplaceExpressionParser>>#symbolTypes
   SmaCCReplaceExpressionParser>>#transitionTable
   

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

[Thierry Goubier]

Hi Steffen,

in fact, I considered B) directly, but not up to the point of building onto
C) and D) (with an obvious A, but that one is a given in Pharo
implementation of strings).

Thanks for the explanation, then.

Regards,

Thierry

2017-11-08 14:21 GMT+01:00 Steffen Märcker :

> I see. How about the following (sketched) solution to avoid looping over
> all characters? It might be very well the case that you already considered
> (and dismissed) that path.
>
> A) Assumption
> In order to allow any meaningful matching, the input to the scanner is
> normalized according to the unicode spec.
>
> B) Abstraction
> Treat each character and character group of an regex as a set of intervals
> in the unicode code points. Lets call them "character tests" and lift the
> common set operations union, intersection and difference to them.
>
> C) Construct NFA
> NFA has potentially overlapping character tests at the transitions of each
> state.
>
> D) Construct DFA
> Given a product state s in the DFA and two transitions t1, t2 from the
> original NFA, add three new transitions to the DFA:
> - a transition labeled with the character test of t1 minus the character
> test of t2
> - a transition labeled with the intersection of the character tests of t1
> and t2
> - a transition labeled with the character test of t2 minus the character
> test of t1
>
> E) Extension
> Instead of sets of unicode intervals we could also use test-functions,
> e.g. blocks. Then, in step D), the set operations are translated to boolean
> operations:
> - difference t1 - t2 becomes: t1 && not t2
> - intersection of t1 and t2 becomes: t1 && t2
> This would allow to use optimized test functions, e.g., bdds, instead of
> relying on charcter tests only.
>
>
> Cheers,
> Steffen
>
>
>
>
>
> Am .11.2017, 23:16 Uhr, schrieb Thierry Goubier  >:
>
> Le 07/11/2017 à 23:00, Steffen Märcker a écrit :
>>
>>> I am not familiar with the literature on scanners. May I ask you about
>>> some details on the "for all characters" algorithms you are referring to?
>>>
>>
>> The two main ones available, from the typical Aho/Ullman textbook, are:
>>
>> - NFA to DFA conversion (i.e. build a NFA with your regular expressions,
>> then convert it to a DFA)
>>
>> - Direct regular expression to DFA construction
>>
>> Both of them have loop of the type:
>>
>> for (each input symbol a) {
>> ...
>>
>> Building a (or connecting to) a BDD library would be fun, indeed. But
>>> within that time frame it seems not realistic. Anyway, after finishing my
>>> thesis, I'd like to come back to that idea.
>>>
>>
>> It would certainly be interesting. Please contact us again when you'll
>> have time :)
>>
>> Regards,
>>
>> Thierry
>>
>> Ciao, Steffen
>>>   Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn <
>>> aglyn...@gmail.com>:
>>>      A possible way to accomplish it would be to use an object graph with
>>> an incremental query engine, such as EMF/CDO with Viatra or
>>> something similar.  You could then put different character sets in
>>> connected objects and query only as far as you need to.
>>>  Andrew Glynn
>>>  Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>  *From: *Thierry Goubier <mailto:thierry.goub...@gmail.com>
>>> *Sent: *Tuesday, November 7, 2017 7:17 AM
>>> *To: *Any question about pharo is welcome
>>> <mailto:pharo-users@lists.pharo.org>
>>> *Subject: *Re: [Pharo-users] Binary Decision Diagram Package in
>>> Smalltalk
>>>  Hi Andrew, Steffen,
>>>  2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black >> <mailto:bl...@cs.pdx.edu>>:
>>>> On 28 Oct 2017, at 17:37 , Steffen Märcker >> <mailto:merk...@web.de>> wrote:
>>>  >
>>>  > Does that mean the sets/bdd would be constructed mainly at
>>> comile time? Anyway, Andrew, feel free to contact me, I might
>>> help you with this.
>>>  >
>>>  Thanks for the offer, Steffen!  The problem is that I need to
>>> use SmaCC for my current project, and really do not have a month
>>> to take off and re-design the way that it builds its scanner.
>>>  I’ve talked to Thierry Goubier about, and he doesn’t have time
>>> either!  It would be a f

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

[Thierry Goubier]

Le 07/11/2017 à 23:00, Steffen Märcker a écrit :
I am not familiar with the literature on scanners. May I ask you about 
some details on the "for all characters" algorithms you are referring to?


The two main ones available, from the typical Aho/Ullman textbook, are:

- NFA to DFA conversion (i.e. build a NFA with your regular expressions, 
then convert it to a DFA)


- Direct regular expression to DFA construction

Both of them have loop of the type:

for (each input symbol a) {
...

Building a (or connecting to) a BDD library would be fun, indeed. But 
within that time frame it seems not realistic. Anyway, after finishing 
my thesis, I'd like to come back to that idea.


It would certainly be interesting. Please contact us again when you'll 
have time :)


Regards,

Thierry


Ciao, Steffen


Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn :

A possible way to accomplish it would be to use an object graph with
an incremental query engine, such as EMF/CDO with Viatra or
something similar.  You could then put different character sets in
connected objects and query only as far as you need to.

Andrew Glynn

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
    Windows 10

    *From: *Thierry Goubier <mailto:thierry.goub...@gmail.com>
*Sent: *Tuesday, November 7, 2017 7:17 AM
*To: *Any question about pharo is welcome
<mailto:pharo-users@lists.pharo.org>
*Subject: *Re: [Pharo-users] Binary Decision Diagram Package in
Smalltalk

Hi Andrew, Steffen,

2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black mailto:bl...@cs.pdx.edu>>:


 > On 28 Oct 2017, at 17:37 , Steffen Märcker mailto:merk...@web.de>> wrote:
 >
 > Does that mean the sets/bdd would be constructed mainly at
comile time? Anyway, Andrew, feel free to contact me, I might
help you with this.
 >

Thanks for the offer, Steffen!  The problem is that I need to
use SmaCC for my current project, and really do not have a month
to take off and re-design the way that it builds its scanner. 
I’ve talked to Thierry Goubier about, and he doesn’t have time

either!  It would be a fun project, though, and it ought to be
fairly separate from other parts of SmaCC.  I’ve spent a fair
bit of time thinking about how to do it, but don’t think that I
will be able to actually focus on it.

Yes, this is the essence of the issue. There are a few alternatives
about it, but none we have the time to pursue.


An alternative approach, which Thierry has suggested, is to make
SmaCC work on the UTF-8 representation of the Unicode.  Then we
could represent character sets as prefix trees.  But the core
problem would still exist: you can’t run an algorithm that
repeatedly executes

                 for all characters in the alphabet do:

when there are 2^21 characters in the alphabet!

The main issue is that `for all characters`... All the literature on
scanner building uses 'for all characters do'.

Thierry


         Andrew

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

[Thierry Goubier]

Hi Andrew, Steffen,

2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black :

>
> > On 28 Oct 2017, at 17:37 , Steffen Märcker  wrote:
> >
> > Does that mean the sets/bdd would be constructed mainly at comile time?
> Anyway, Andrew, feel free to contact me, I might help you with this.
> >
>
> Thanks for the offer, Steffen!  The problem is that I need to use SmaCC
> for my current project, and really do not have a month to take off and
> re-design the way that it builds its scanner.  I’ve talked to Thierry
> Goubier about, and he doesn’t have time either!  It would be a fun project,
> though, and it ought to be fairly separate from other parts of SmaCC.  I’ve
> spent a fair bit of time thinking about how to do it, but don’t think that
> I will be able to actually focus on it.
>

Yes, this is the essence of the issue. There are a few alternatives about
it, but none we have the time to pursue.


>
> An alternative approach, which Thierry has suggested, is to make SmaCC
> work on the UTF-8 representation of the Unicode.  Then we could represent
> character sets as prefix trees.  But the core problem would still exist:
> you can’t run an algorithm that repeatedly executes
>
> for all characters in the alphabet do:
>
> when there are 2^21 characters in the alphabet!
>

The main issue is that `for all characters`... All the literature on
scanner building uses 'for all characters do'.

Thierry


>
> Andrew
>
>
>
>
>

Re: [Pharo-users] perspective request for those earning alivingfromSmalltalk

[Thierry Goubier]

Hi Andrew,

Le 06/11/2017 à 19:59, Andrew Glynn a écrit :
I /suspect/ that a (mostly repressed) underlying sense that a reliable, 
inexpensive platform, if popular, would have been more detrimental to 
IBM than to its smaller competitors. The same goes for the VisualAge 
family -> Smalltalk (sold now by Instantiations at v. 9.0), Java, C++ 
and COBOL.  One of the (largely unthought) reasons for Smalltalk’s 
difficulties in the 1990’s, when hardware could run it decently, was 
that it took a fair number of resources/time to write a decent version, 
while using it would have been a bigger advantage to smaller companies 
than to the companies with the money to develop one.  The result was 
that only a few, very expensive versions were publicly available.  VA 
Smalltalk still retails at ~$8500 / seat.


Those kinds of hazy (because not admitted to oneself) reasons for doing 
things end up resulting in apparently contradictory actions such as 
spending large amounts writing something, releasing it, then failing to 
support it with any sales or marketing push, and even actively 
undermining it.  Nobody wants to fully admit that inefficiencies are 
actually to their advantage, which is the reason it’s repressed 
(implying both known /and/ not known, simultaneously).


I’m totally speculating of course and may be dead wrong, but it fits 
with other IBM actions and non-actions.  IBM is a strange company that 
sees itself, partly for good reason, as a business that must make money 
/and/ as an international resource that must continue to exist. Though 
the latter depends to a degree on the former, they don’t always imply 
the same specific decisions.


Interestingly, to prove the scalability of a VM based system IBM wrote 
“RVM” (originally meaning “Renaissance VM”), and proved near linear 
scaling to 1024 cores, but RVM is a VM for Squeak and earlier versions 
of Pharo, not IBM Smalltalk (the source is available, on GitHub I believe).


https://github.com/smarr/RoarVM

I wouldn't say it is IBM, instead that it is David Ungar work (of Self 
and a few other things)...


Has probably ties to the Jikes RVM as well.

Arca Noae (meaning “New Box”), the company that released v.5.0 in June, 
was set up because too many big customers can’t migrate crucial apps 
from OS/2 to anything else.  The new version looks more modern, 
borrowing icons and other things from Linux, mainly KDE.  It can run a 
fair number of Win32 apps, and supports virtually all modern hardware, 
scaling to 128 threads and 16GB RAM, though it’s still 32 bit in most 
senses.


As you can imagine, given the base requirements are a Pentium Pro with 
64MB RAM, on an average laptop today it flies.


I'm not nostalgic, but the object model and how it was handling 
versionning was cool.


Anybody remember Taligent?

Thierry



Andrew

Sent from Mail  for 
Windows 10


*From: *Richard Sargent 
*Sent: *Monday, November 6, 2017 11:55 AM
*To: *'Any question about pharo is welcome' 

*Subject: *Re: [Pharo-users] perspective request for those earning 
alivingfromSmalltalk


Andrew,

I worked with OS/2 in the early 90s and really liked it; I adopted it 
for my personal use as well. I really enjoyed reading the details you 
provided earlier.


I have a hypothesis that when IBM tried to sell OS/2 (Warp) via a retail 
channel that it "hurt". A company whose DNA was channel sales would find 
dealing with retail issues to be entirely different from everything they 
knew. So, I speculate that there were enough people to felt (and argued) 
that OS/2 wasn't "worth it".


Any thoughts you would care to share on that supposition would be 
appreciated.


*From:*Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On 
Behalf Of *Andrew Glynn

*Sent:* November 6, 2017 04:18
*To:* Any question about pharo is welcome
*Subject:* Re: [Pharo-users] perspective request for those earning a 
livingfromSmalltalk


Thank you.  I will see if I can get to it today or tomorrow.

Andrew

Sent from Mail  for 
Windows 10


*From: *Davorin Rusevljan 
*Sent: *Monday, November 6, 2017 4:17 AM
*To: *Any question about pharo is welcome 

*Subject: *Re: [Pharo-users] perspective request for those earning a 
livingfromSmalltalk


On Sat, Oct 28, 2017 at 7:59 PM, Andrew Glynn > wrote:


Your history is accurate, but there’s a few things I’d  like to add,
due to having been employed by IBM at exactly that period working
specifically on VisualAge, not only for Smalltalk, but for Java, C++
and Cobol as well.  (my NDA’s finally having expired also helps
😉).  It’s not a correction or contradiction, but a complement to
your description, providing a relevant but different perspective.

Andrew,

please find a way to write an arti

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

[Thierry Goubier]

2017-10-27 11:28 GMT+02:00 Cédrick Béler :

>
> Hi Cedric,
>
> a short answer: some of what you're trying to do has been traditionnally
> handled by object databases - multiple images retrieving and updating
> objects on a central store ensuring lots of good properties : see Gemstone.
>
>
> Yes , I’d like to avoid this centralized approach.
>

I mean that they have already some of the mechanisms in place, even if
centralized.


>
>
> Another answer, since you're looking at content-addressable distributed
> file systems. You can resolve the offline mode with object duplications
> (duplicate all objects in the images using them), and, when coming back
> online, have a merge approach to reconcile changes between versions of
> shared objects. Content-based hashes as identifiers in a distributed store
> have very nice properties for that purpose, because, if image C has
> modified object 0xcdaff3, then that object has in fact become object
> 0xee345d for that image (and the unmodified object is still 0xcdaff3 for
> images A and B).
>
>
> You nailed it. This is what I’d like to reproduce.
>
> Existing implementations out there seems to uses whatever nodes on the
> network to replicate the information.
>

Yes, because that makes them decentralized :)


>
> I’d like to control nodes where it is replicated. My nodes (all my app
> instances + nodes of person I’m exchanging information with + eventually
> friend of friend).
>

We've done recent work on capability-based content adressing, but, first
it's very slow (so you use a two level cryptosystem: the crypted header
contains the key to decrypt the content, and the crypted header can only be
decrypted if your private key has the right level of capabilities on the
data item.


>
> What hash function would you use ?
>

Anything that is fast, bonus points if it uses CPU special instructions
(that you can't use from Pharo, of course ;)), and has the right
cryptographic properties. Unless you go into a specific cryptosystem, I'd
say that it is not important.


>
> To get something compatible with ipfs, I’d need something like:
> https://github.com/multiformats/multihash
> It looks to me quite universal as self describing. But any (existing) hash
> method compatible with content hashing would do the job.
>

Interesting, but it looks like a minor issue in the overall scheme. Makes
some of your system robust to evolution in the hash used, but, since first
bytes are not well distributed, can you use it safely to build a multi-hash
function system? Probably not.


>
>
> I wouldn't be against a slightly higher granularity when dealing with
> object transfers, however.
>
>
> You mean at the pharo level ? Higher granularity means having more control
> on the exchange/merge ?
>

No, just that the content-based address scheme is costly... and that a
practical implementation would probably look to provide addresses only to
large enough entities (a page containing objects, for example, or a large
objects containing smaller ones). So that you donc create an address for
each character of the string object describing the name of a person, say).

Regards,

Thierry


>
> Cheers,
>
> Cédrick
>

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

[Thierry Goubier]

Hi Cedric,

a short answer: some of what you're trying to do has been traditionnally
handled by object databases - multiple images retrieving and updating
objects on a central store ensuring lots of good properties : see Gemstone.

Another answer, since you're looking at content-addressable distributed
file systems. You can resolve the offline mode with object duplications
(duplicate all objects in the images using them), and, when coming back
online, have a merge approach to reconcile changes between versions of
shared objects. Content-based hashes as identifiers in a distributed store
have very nice properties for that purpose, because, if image C has
modified object 0xcdaff3, then that object has in fact become object
0xee345d for that image (and the unmodified object is still 0xcdaff3 for
images A and B).

I wouldn't be against a slightly higher granularity when dealing with
object transfers, however.

Regards,

Thierry

2017-10-27 10:43 GMT+02:00 Cédrick Béler :

>
> Nothing complex about two images exchanging messages, its not even complex
> to transmit objects via fuel, you even transmit a debugger or any part of
> the live environment or even make an "internet" of images that join objects
> together. Sky is the limit. Pharo already provides you will all the
> tools/libraries to do this.
>
>
> Yes. That’s why I asked for better practices.
>
>
> A streamsocket (not to be confused with regular sockets) will delay the
> messages (a collection of bytes) until they arrive to the receiver or until
> they have reached the timeout period. Offline mode is pretty much
> obligatory even for plain old internet web apps because of drops in
> connection or the plain fact a connection can become slow.
>
>
> Offline mode is to me of first importance.
>
> Let’s say I have a sets of Pharo app (nodes).
> Each one are independent running on different devices/computers.
>
> I want to exchange information between  them according to some kind of
> contracts and also on connection availability.
>
> What I find different from usual message exchanges between two images is
> that I want to have full control on it. Plus I consider images offline by
> default (meaning two images have different versions of the same info). So
> conflict is the norm.
>
> Also, I don’t want to send message remotely (with behavior), I just want
> to send/share an information and sync them (when possible).
>
> Connection between 2 images can be through a network but eventually
> through a serial connection (usb cable, Bluetooth,...).
>
> So what I try to do as a proto is having connection controlled by my apps
> (I put the app offline (not by switching off wifi but by switching
> logically). I can see nodes availability and activate connexion manually
> then see if conflict resolution is ok, + I log every connecitions changes
> and exchanges).   This is my plans for now but it may change ! ^^
>
>
> I used streamsockets in my Pharo to Python bridge (Atlas) because the
> execution was not necessary synchronous , I was sending Python command to a
> 3d application from Pharo and I had to make sure that the bridge was
> working even in the case of a command that could take hours to execute like
> a rendering process.
>
>
> I’ll look  at stream sockets and mq stuffs.
>
>
> Cheers,
>
> Cédrick
>
>
> One cool trick I did was to send the Python errors back to Pharo and
> trigger them as Pharo's regular MessageNotUnderstood , this is a nice way
> to make sure that you can fix a wrong message after it has been executing
> without going to the image that is executing it.
>
> The limitation with sockets which what every frameworks uses because AFAIK
> they are the only means to communicate remotely is that they are not top
> performance so that mean that you can send long loops but executing
> communication inside long loops will either slow you down considerably or
> simply timeout your socket. Sockets can timeout from both ends if they feel
> that for some reason they lost communication with the other side and
> reached their timeout period. Timeout period is customization.
>
> This is a problem I did not tackle with my implementation because I dont
> think there can be an actual practical solution better than avoiding this
> scenario.
>
> Only shared memory seems to overcome this but it can be used only locally
> and not remotely (aka on same computer) .
>
> On Wed, Oct 25, 2017 at 4:41 PM Cédrick Béler  wrote:
>
>> I had a look and this is not (natively) possible.
>>
>> The idea of the off-line mode would be to delay messages that are sent to
>> the peer until a connection is established.
>>
>> I think I have to try to do it by myself (like having a list of
>> information exchange that wait until a connexion is established).
>>
>> What I try to do is not as complex as two general image exchanging
>> messages on objects (like on TelePharo).
>>
>> I just want a repository of information (mainly a collection of static
>> information/data versions) on both peers 

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Thierry Goubier]

Hi Kilon,

then the discussion is a bit different. As your example points out, the
syntax is already there, but the notion of a module is still open and ties
into the package management.

I've played a bit with Metacello to have a working "project" concept
synchronized with Metacello, and I could imagine providing module like
objects (the baseline itself?) giving access to more generic names instead
of the internal, prefixed ones.

One suggestion maybe: what about trying it for yourself with one of your
projects? With a kind of overall class which has the name of the module,
and automatically adding methods to it (or a #doesNotUnderstand: that
handles those) for all the classes in the module, removing from the class
name the prefix? It would allow an experiment, to see how the code looks
like and if it is understandable, or if a special syntax is necessary.

Thierry


2017-10-13 11:51 GMT+02:00 Dimitris Chloupis :

> to be more specific what I mean because apparently I may know nothing
> about namespaces , I was talking in terms of Python's module and package
> system
>
> even though python uses special syntax "import" to import a module, a
> source file, the real functionality is actually a method but of an object
> dealing with the handling of modules and packages , packages are basically
> file directories containing mutliple modules
>
> as soon as you do the import the syntax is the usual object syntax
>
> so
>
> Dog.bark()
>
> can be anything
> 1) A class method call, Dog being the class
> 2) A instance method call, Dog being the instance
> 3) or a function call, Dog being the function , which is also an object
> (methods in python are basically function object taking the reference to an
> instance as first argument, hence why the weird syntax of adding self as
> first argument when we define instance method) and Dog is the module
> imported.
>
> of course in case (3) you can collapse the module "name" so you can do
> only bark() if you import via "from Dog import *" which means from module
> Dog import every object.
> But from import is frown upon in the python world because obviously it
> makes it easier to have name collision which is what the module system try
> to avoid in the first place.
>
> So the equivelant of pharo would be
>
> MyModule MyInstance myMessage:
>
> or if you include packages as well
>
> MyPackage MyModule MyInstance myMessage:
>
> which follows pharo syntax and OO design. That's my general idea at least.
>
> Please enlighten me :)
>
> On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis 
> wrote:
>
>> On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :
>>>
>>>> fair enough you think namespaces are not the right solution, what you
>>>> think is the right solution then ?
>>>>
>>>
>>> I told you. Namespaces are a solution, but they come with issues.
>>>
>>>
>>
>> Then I misunderstood you but I am geniouly interested in what those
>> problems are and I think the infromation is something others will find
>> interesting as well.
>>
>> No. In the HPC world, a common held position is that Fortran code is 30%
>>> faster than C++.
>>>
>>
>> Cannot even rememeber the last time a 3d graphics developers mentioned
>> Fortran.I occasional frequent forums and mailing lists plus keeping in
>> contact with Blender developers.
>>
>> I have heard that Fortran can outperform C++ in numeric computation
>> around the percentage you mentioned but first time I heard that its
>> generally faster.
>>
>> Language Benchmark seems to strongly disagree
>>
>> http://benchmarksgame.alioth.debian.org/u64q/compare.php?
>> lang=ifc&lang2=gpp
>>
>> of its widely criticized but then what benchmark is not
>>
>>
>>> Remember that part of my job is to write compilers.
>>>
>>>
>> I knew that you write compilers (SmaCC) I did not realise you are a pro
>> and especially on ones that generate highly optimised machine code
>>
>>
>>> I'm also consider a guy to talk to when someone has deep issues with
>>> some of the new features of C++... even if I don't do C++, I can often
>>> reframe what the feature means in the overall scheme of programming
>>> languages.
>>>
>>
>> On other hand I have close to zero experience on compilers
>>  .
>>
>>
>>> I find it very interesting. I consider that current compilers are very
>>> good opti

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Thierry Goubier]

2017-10-13 10:12 GMT+02:00 Dimitris Chloupis :

> fair enough you think namespaces are not the right solution, what you
> think is the right solution then ?
>

I told you. Namespaces are a solution, but they come with issues.


>
> As much I hate C++ , no I will have to disagree with your there, bad
> language design sure, but many of the "bad design" choices they make are
> based on the fact that this is a pure performance orientated language. Oh
> and we still wait for the real C++ alternative. Rust people claim they are
> close, D people claim they are close, everyone claims its very close, but
> still no alternative. Well I dont count C becaue its not OO, even if you
> claim C++ an abomination of OOP. I can guarantee that the dude that will
> come up with a language as fast as C++ and much better design he is going
> to make a fortune. In the mean time , those that have to use C++ will
> continue to use C++ and wait for the extemely remote competition to catch
> up. In the mean time C++ is the undisputed king in its speciality.
>

No. In the HPC world, a common held position is that Fortran code is 30%
faster than C++.

Remember that part of my job is to write compilers.

I'm also consider a guy to talk to when someone has deep issues with some
of the new features of C++... even if I don't do C++, I can often reframe
what the feature means in the overall scheme of programming languages.


>
> Unfortunately coming up with a top performance language is a lot more than
> language design, live coding and OOP. Took ages for C and C++ to get to the
> level of optimisation they are nowdays. That's no easy feat even if you or
> I dont find interesting.
>

I find it very interesting. I consider that current compilers are very good
optimising code that is written in a language that obscures the developper
intent in the first place.


>
> So yes the modules that C++ will come up with, will be as ugly as hell,
> templates that suppose to be there as an alternative to dynamic typing etc
> are ugly as hell, but I dont see much protest in getting them removed. And
> there cases you cannot even use these "improvements" because ... well
> performance issues. While other languages worry how many times slower they
> are compared to C++, C++ worries about how much percentage of performance
> it loses with each added feature. C++ exits in a diffirent universe than
> the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one.
>

As I told you, I work in a world where performance is paramount and C++ is
strongly criticized for the fact its incidental complexity makes it very
very hard to reach or maintain performance levels (compared to Fortran,
say).

Thierry


>
> On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Kilon,
>>
>> disclaimer: I've used Parcplace Smalltlk without namespaces, then
>> VisualWorks with namespaces.
>>
>> 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis :
>>
>>> Personally I dont get it, we find the path to bootstrap the pharo image
>>> clear and we cannot see the path to namespaces ?
>>>
>>
>> Because namespaces, by essence, come with serious issues. I won't take
>> someone seriously on namespaces until he can cite those faithfully.
>>
>>
>>>
>>> it makes zero sense to me
>>>
>>> Plus what you say, countless and countless of implementation of
>>> namespaces out there. And again what you say about perfection.
>>>
>>> If C++ can improve, If C++ can dream of namespaces planning the
>>> introduction of modules(in future version) in replacement (not removal) of
>>> his awful header file format I think we got the excuse to be confident
>>> we can come up with something decent.
>>>
>>
>> C++ is about adding incidental complexity to the development process,
>> i.e. how to make something complex where it could be done in a simpler way.
>>
>> So I'd be very wary of any innovation coming from that direction.
>>
>>
>>>
>>> We develop a freaking IDE for crying out loud.
>>>
>>> No it wont be a walk in the park, no it wont get done in one or next
>>> version, and no it cannot be an individual our outside effort. But we have
>>> the community super qualified to do it.
>>>
>>
>> And qualified enough maybe to also see it doesn't make that much of sense.
>>
>> Please remember that the design of a programming language consists not
>> just in a laundry list of features, but also in making judicious choices of
>> what to *omit* and, more importantly, in establ

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Thierry Goubier]

Hi Kilon,

disclaimer: I've used Parcplace Smalltlk without namespaces, then
VisualWorks with namespaces.

2017-10-13 9:08 GMT+02:00 Dimitris Chloupis :

> Personally I dont get it, we find the path to bootstrap the pharo image
> clear and we cannot see the path to namespaces ?
>

Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.


>
> it makes zero sense to me
>
> Plus what you say, countless and countless of implementation of namespaces
> out there. And again what you say about perfection.
>
> If C++ can improve, If C++ can dream of namespaces planning the
> introduction of modules(in future version) in replacement (not removal) of
> his awful header file format I think we got the excuse to be confident
> we can come up with something decent.
>

C++ is about adding incidental complexity to the development process, i.e.
how to make something complex where it could be done in a simpler way.

So I'd be very wary of any innovation coming from that direction.


>
> We develop a freaking IDE for crying out loud.
>
> No it wont be a walk in the park, no it wont get done in one or next
> version, and no it cannot be an individual our outside effort. But we have
> the community super qualified to do it.
>

And qualified enough maybe to also see it doesn't make that much of sense.

Please remember that the design of a programming language consists not just
in a laundry list of features, but also in making judicious choices of what
to *omit* and, more importantly, in establishing design principles that are
easy to understand [Steele, 2003]

Thierry


> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman  wrote:
>
>> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris 
>> wrote:
>>
>>> horrido wrote
>>> > Having separate namespaces would be really good.
>>> > VisualWorks has them. Why not Pharo?
>>>
>>> I can't remember ever hearing disagreement on this subject. It seems the
>>> only questions have been: 1) how to do them *right*,
>>
>>
>> The default position would be leveraging someone else's experience, so
>> this begs the question, what is wrong in namespace implementations in VW,
>> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin,
>> SmalltalkX, other languages)
>> Are there been any research papers around comparing these?
>>
>> I found the "Pharo on Gemstone VM" talk impressive.  The "develop on
>> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's
>> commercial future.  So a naive approach would be to do namespaces just like
>> Gemstone.  Maybe its not the best, but would it be "good enough" --
>> perfection being the enemy of done and all that jazz.
>>
>> cheers -ben
>>
>>
>>> and 2) where they fall on the endless prioritized todo list
>>>
>>

Re: [Pharo-users] "Building-With versus Building-on"

[Thierry Goubier]

Hi Andrew, Stephane,

thanks for the read. It was interesting, albeit a bit confusing at times. I
do like your evaluation of the thesis.

2017-10-12 23:10 GMT+02:00 Stephane Ducasse :

> Thanks Andrew I read it fast and I will reread it. It is really
> interesting to me because I never took the time to understand "worse
> is better".
>

Reading through "worse is better", and the follow-up "worse is better is
worse" by the same author, I'm not sure there is much to understand ;)

Apart if you want to study how a misunderstood quote can become a driving
force in software development...

Thierry


>
> On Thu, Oct 12, 2017 at 5:50 PM, Andrew Glynn  wrote:
> > https://medium.com/@dasein42/building-with-versus-building-
> on-c51aa3034c71
> >
> >
> > This is an article not specifically about Pharo, rather on the state of
> the
> > industry
> > in general and how it got that way, but positing Pharo as a way to learn
> > building-on rather than building-with, where in the latter case on
> > every project you start at essentially the same place.
> >
> >
> > As a result it does put in front of people a fair amount of info on
> Pharo,
> > and challenges them to try it.
> >
> >
> > cheers
> >
> > Andrew Glynn
>
>

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

[Thierry Goubier]

2017-10-12 15:05 GMT+02:00 Guillermo Polito :

>
>
> On Thu, Oct 12, 2017 at 2:49 PM, Julien 
> wrote:
>
>> Normally, it should be possible.
>>
>> Libusb can be compiled for 64bits architectures. I don’t know if it
>> changes something in the UFFI binding side?
>>
>
> It should not, besides the library's location.
>
>
That was the first hurdle. Easily solved.


> And, if you find a case where the binding does not work on 64 bits it is
> either:
>  - a UFFI bug in the type mappings (e.g., a wrong mapping between a type
> name and the correct 32/64 bit size and marshalling)
>  - or a bug in the bindings using the wrong types (e.g., using long
> instead of void*)
>

And the first FFI call fails (the lib init).

Thierry


>
>
>>
>> Julien
>>
>> Le 12 oct. 2017 à 14:41, Thierry Goubier  a
>> écrit :
>>
>> Very cool. Would that be doable to adapt for a 64bits version?
>>
>> Thierry
>>
>> 2017-10-12 13:29 GMT+02:00 Julien :
>>
>>> Hello,
>>>
>>> A bit late, there is a Libusb [1] binding (using UFFI) and support for
>>> the Human Interface Device [2] (that uses the binding but is written in
>>> pure Smalltalk) for Pharo.
>>>
>>> Everything is on the github repository [3]. « Install »  and « Quick
>>> start »  sections give you all you need to start using the project.
>>>
>>> One could also have a look at the wiki [4].
>>>
>>> It works on Linux but hasn’t been tested on Mac OS nor Windows (it
>>> should work since libusb library works on these platforms).
>>>
>>> Do not forget to install the 32 bits versions of libusb on your computer.
>>>
>>> The purpose of this library is to provide the ability to use USB devices
>>> directly from Pharo.
>>>
>>> For example, one could get data from a PS3 controller, a mouse, a
>>> keyboard, an Arduino device, etc…
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>> PS: I realised this project during an internship in TaMère SCRL company
>>> [5]. Thanks to them!
>>>
>>> Links:
>>> [1]: http://libusb.info
>>> [2]: https://en.wikipedia.org/wiki/Human_interface_device
>>> [3]: https://github.com/tamerescrl/libusb-pharo
>>> [4]: https://github.com/tamerescrl/libusb-pharo/wiki
>>> [5]: http://tamere.eu
>>>
>>
>>
>>
>
>
> --
>
>
>
> 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 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

[Thierry Goubier]

Very cool. Would that be doable to adapt for a 64bits version?

Thierry

2017-10-12 13:29 GMT+02:00 Julien :

> Hello,
>
> A bit late, there is a Libusb [1] binding (using UFFI) and support for the
> Human Interface Device [2] (that uses the binding but is written in pure
> Smalltalk) for Pharo.
>
> Everything is on the github repository [3]. « Install »  and « Quick
> start »  sections give you all you need to start using the project.
>
> One could also have a look at the wiki [4].
>
> It works on Linux but hasn’t been tested on Mac OS nor Windows (it should
> work since libusb library works on these platforms).
>
> Do not forget to install the 32 bits versions of libusb on your computer.
>
> The purpose of this library is to provide the ability to use USB devices
> directly from Pharo.
>
> For example, one could get data from a PS3 controller, a mouse, a
> keyboard, an Arduino device, etc…
>
> Cheers,
>
> Julien
>
> PS: I realised this project during an internship in TaMère SCRL company
> [5]. Thanks to them!
>
> Links:
> [1]: http://libusb.info
> [2]: https://en.wikipedia.org/wiki/Human_interface_device
> [3]: https://github.com/tamerescrl/libusb-pharo
> [4]: https://github.com/tamerescrl/libusb-pharo/wiki
> [5]: http://tamere.eu
>

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[Thierry Goubier]

What about a seaside-based system browser oriented towards code
documentation? That would fit both paradigms: html-like reference + live
browsing.

You could even make it buzzword compliant: have a REST interface to
documentation and code.

Note how the panes in a system browser could make for a nice URI: just look
for

pharo://Kernel/Number/mathematical%20functions/raisedTo:

And we could even include version numbers, etc

pharo://6.1/Kernel/Number/mathematical%20functions/raisedTo:

Not very different from the github url for the pharo project relevant
file...

https://github.com/pharo-project/pharo/blob/development/src/Kernel.package/Number.class/instance/raisedTo..st

Thierry

2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com>:

> Yes. I know them. I mean API docs as static files. I don't really sold on
> them compared with a live system and I don't think static API docs are
> critical for Pharo success.
>
> Cheers,
>
> Offray
>
> On 11/10/17 09:52, Dimitris Chloupis wrote:
>
> Ah and my static website was built with Pillar and Bootstrap, using
> bootstrap templates was easy because Pillar supports mustache that makes
> html manipulation much easier
>
> http://www.kilon-alios.com
>
> Pillar of course is not made for generating websites but it’s an awesome
> Pharo library that allows for great degree of freedom so I thought , why
> not ?
> On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis 
> wrote:
>
>> Docs are available in static online html format , at least the book I was
>> working on
>>
>> Pharo By Example
>>
>> You can find those links here
>>
>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample
>>
>> Our documentation system , Pillar , outputs pdf , html and markdown
>> files.
>>
>> If the book in question is built like PBE with CI of Inria where most
>> Pharo related official projects are built then it should have at least pdf
>> and html with online access so you can easily link to.
>>
>> Don’t quote me on this but I think the html output of pillar generate
>> links even for paragraphs you can do an even more process linking to the
>> documentation.
>> On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas <
>> offray.l...@mutabit.com> wrote:
>>
>>> The more I use Pharo, the less I use web documentation. For me seems
>>> pretty suboptimal compared to live environment with code browser and
>>> GT-Spotter. Regarding the comment on Medium, it also took me little to find
>>> #raisedTo:, so the millage can vary. What I was missing was proper books
>>> for particular domains, but Pharo books are covering that. I don't know if
>>> a Q&A site could improve search-ability for newbies (certainly you can find
>>> little stuff in Stack Overflow).
>>>
>>> My bet is about trying to create more "end user" tools (Grafoscopio is
>>> kind of this), besides tools for developers. There is a broad community of
>>> people who can be active contributors and members of the community, welcome
>>> Pharo and live coding a lot and don't complain that much about stuff that
>>> is not already pretty similar to what they already know (being that only
>>> English MOOC or online static html docs).
>>>
>>> Cheers,
>>>
>>> Offray
>>>
>>> On 11/10/17 07:34, Dimitris Chloupis wrote:
>>>
>>> for me it is a yes and no situation, yes its very coold to have your
>>> entire system in your fingertips but Pharo has serious issues with code
>>> organisation and I find the lack of namespaces quite inconvenient. You have
>>> to be careful how to name your classes which does not sound to me very OOP
>>> friendly.
>>>
>>> Also the IDE does not handle spaggetification very well, sure you can
>>> find implementors , senders etc but if the execution chain is complex ,
>>> welcome to spaggeti hell. But that is a problem with most other IDEs if not
>>> all as well. Problem is in this case that we have the very good rule of
>>> using sort methods which multiplies this problem and makes navigation even
>>> harder. Code becomes much easier to read per method and messages but much
>>> harder to understand in a bird eye view.
>>>
>>> Some of that pain has been aleviated with the introduction of GTSpotter
>>> which I have praised quite a lot and I will continue to do so. But yeah
>>> there are more needed to be done in the department to make Pharo code
>>> navigation a more comfortable task.
>>>
>>> On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz 
>>> wrote:
>>>
 I dunno, maybe I’m weird, but I find the System Browser a fantastic way
 to explore the class library. If you find a class or method that isn’t well
 documented, write a comment and send a change request. Stef told me this
 ages ago. I might add, if you find a bug you should write a test that
 exercises the bug and submit it on fogbugz (the bug tracking system).


 I will reference of response of mine to a similar opinion made by
 Richard: https://medium.com/@vitormcruz/i-disagree-it-is-
 much-harde

Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems

[Thierry Goubier]

Le 01/10/2017 à 09:26, Hilaire a écrit :
All these difficulties are good argument to get the appropriate 
libcairo/libpng shipped with the Linux VM, as done with Windows and 
MacOSX VM


This cause surprising problems in Pharo integration with the platform: 
for example, if you use a system library or an external command with 
Pharo as it is set now, that command will use Pharo libpng instead of 
the one it was compiled with (because pharo use of LD_LIBRARY_PATH will 
be inherited).


Took me a while for example to understand that, when using the snap 
version of Pharo, Python3 scripts called from Pharo would be unable to 
import libraries such as numpy. But that works fine with the zeroinstall 
version of Pharo.


Thierry


Hilaire


Le 30/09/2017 à 21:58, Igor Stasenko a écrit :

Sure. But i didn't done much, so there's nothing to appriciate yet :)
But i want to help, if it won't require reinstalling OS, because i 
need my machine in working condition almost 24/7.. so i cannot take 
too much risk with it :(

Re: [Pharo-users] How to include DeployUtils in a Configuration?

[Thierry Goubier]

Hi Hernán,

I think what is happening is you're not including completely the
DeployUtils baseline. You need to write something like:

spec baseline: 'DeployUtils' with: [
spec repository: 'github://fstephany/DeployUtils/repository'];
import: 'DeployUtils'.

And have one of the packages (or groups?) of DeployUtils listed as
dependency of one of your packages.

Regards,

Thierry

2017-09-25 20:19 GMT+02:00 Hernán Morales Durand :

> I am trying to include DeployUtils in a ConfigurationOf (Pharo 6.1)
> following instructions at:
>
> https://github.com/fstephany/DeployUtils
>
> If I include the dependency as suggested:
>
> spec baseline: 'DeployUtils' with: [
> spec repository: 'github://fstephany/DeployUtils/repository'].
>
> then when I load the configuration I get:
>
> Error: Unable to resolve project package for 'DeployUtils'. It is
> likely that that the configuration referencing this project will not
> validate properly (see MetacelloToolBox
> class>>validateConfiguration:).
>
> If I include the dependency as:
>
> spec
> project: 'DeployUtils' with: [
> spec
> className: #DeployUtils;
> versionString: 'baseline';
> repository: 'github://fstephany/DeployUtils/repository'
> ];
>
> Then I get DU multiple missing dependencies:
>
> This package depends on the following classes:
>   StringStreamLogger
>   Log
>   StdoutStreamLogger
> You must resolve these dependencies before you will be able to load
> these definitions:
>   DUFileLogger
>   DUFileLogger>>#withFileLocator:
>   DUFileLogger>>#addLogHook:
>   DUFileLogger>>#defaultFormatter
>   DUFileLogger>>#defaultStream
>   DUFileLogger>>#fileLocator:
>   DUStdoutStreamLogger
>   DUStdoutStreamLogger>>#addLogHook:
>   Log>>#debug:tag:
>   Log>>#info:tag:
>   Log>>#warning:tag:
>
> And finally a MNU with
>
> #loader: was sent to nil
>
> (also when I try to inspect I got a #gtInspectorProjectsIn: was sent to
> nil)
> Any ideas?
> Cheers,
>
> Hernán
>
>

Re: [Pharo-users] Pharo 7 license question

[Thierry Goubier]

2017-09-22 10:27 GMT+02:00 Hilaire :

> The appropriate and neutral term to describe GPL licence is "recursive".
>
> GPL licence was designed to build a better computing community, where
> freedom is 1st consideration, even at the expense of a lower acceptance.
>

And the little technical fact that you can't link code in the Smalltalk
world, only create a derivative work, has nothing to do with the community
stance on MIT versus GPL.

Thierry


>
> Hilaire
>
>
> Le 20/09/2017 à 21:30, Jimmie Houchin a écrit :
>
>> So my question to you. What words would you use instead of viral and
>> infection that equally describe that characteristic of the GPL and variants?
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

[Thierry Goubier]

Hi Tim,

2017-09-01 13:39 GMT+02:00 Tim Mackinnon :

> Thanks Thierry - this is proving an interesting problem domain ...
>
> I too am using #bestNodeFor: although I don't find it always gives the
> best node (it does if you are clearly in the target range, but if you are
> on the outer boundary like the next position after a selector or next to a
> "." or ";" it favours the parent and not the closest node. So in usage I
> find I need to tweak it a bit.
>

Yes, when you are on a boundary, then finding the right node may be
difficult. When developping the ancestor to smart suggestion, I considered
#bestNodeFor: as good enough, but I considered looking into "up" and "down"
ast navigation at a time, and I wasn't alone (I think it was active in the
Pharo editor at a point).


>
> I'll look at smacc though - also there is that experimental setting to
> allow parse errors, I don't know if it helps in any way.
>

There is a general question there, which is how you try to parse as much as
possible while jumping over the error, making the error area as small as
possible (that would be really great for syntax highlighting, by the way).

The problem is that in hand-written parsers, you need to hard-code the
error management in the parser. With a table-driven parser (as is SmaCC),
then you can explore in a systematic way what are the possible states that
would allow the parsing to continue correctly after making the error area
as small as possible.

This would make for a very nice internship subject...


> All this said, I think I have a workable suggestion that is not much code
> that might be open to scrutiny from those wiser than me.
>
> Looking at the keyboard handling in the system - it's quite sprawling and
> tricky to follow. I think there is lots of room for refactoring.
>

It is very easy in Pharo to implement a nice and clean keyboard handling;
all the necessary components have been in place for years, and we already
have implementations (using the KM API).

Now, most Pharo developpers just jump into hardcoding keyboard handling
instead.

Thierry


>
> I'm also not sure if I like the pragma usage either - I find it quite
> difficult to follow what's calling what.
>
> Tim
>
> Sent from my iPhone
>
> On 1 Sep 2017, at 09:18, Thierry Goubier 
> wrote:
>
> Hi Tim,
>
> The RB ast has a specific method for finding the right node: in
> AltBrowser, I use ast bestNodeFor: aTarget selectionInterval.
>
> For the second case (parse what is selected), you may want to look into
> SmaCC: it has specific entry points (used for refactoring) to try all
> possible starts in a parser for a given piece of text and returning all the
> possible correct asts. As a hand-writen parser, the RBParser can't do that
> unless you add the necessary entry points by hand and hack around the error
> handling, because most of the parse attempts end on an error (as they
> should).
>
> Regards,
>
> Thierry
>
> 2017-09-01 8:50 GMT+02:00 Tim Mackinnon :
>
>> Marcus - I'd be interested in how you thought to solve this.
>>
>> My solution seems to work - but it's not the most elegant. Retrying lots
>> of different ways like I show, smacks a bit of desperation (this said, it
>> is quite compact).
>>
>> Apart from that - I was actually interested in thoughts on the parse
>> method - the onError naming is a bit misleading compared to other methods
>> in the image. I wonder if it should be called something like
>> "onErrorMerge:"  to signal that it's going to reuse the results?
>>
>> Stef - with regards to broken source, my proposed solution reuses what is
>> already there - thus if you highlight specific code, it reverts to the
>> original strategy and tries to compile just that code. This bugs me however
>> - so if you highlight nothing, it tries to compile the source multiple
>> ways, I drop down to chopping the source up to where your cursor is - which
>> seems like a decent cheap strategy.
>>
>> I don't know if our parser is able to recover from simple errors and just
>> have error nodes in the ast, and whether the #bestNodeFor method then
>> ignored error nodes... this is what I think Dolphin used to do.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> > On 31 Aug 2017, at 19:11, Marcus Denker  wrote:
>> >
>> >
>> >> On 31 Aug 2017, at 19:07, Stephane Ducasse 
>> wrote:
>> >>
>> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon 
>> wrote:
>> >>> I’m looking for some feedback on the usage of
>> RBParser>>#parseMethod:onError:.
>> >>>
>

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

[Thierry Goubier]

Hi Tim,

The RB ast has a specific method for finding the right node: in AltBrowser,
I use ast bestNodeFor: aTarget selectionInterval.

For the second case (parse what is selected), you may want to look into
SmaCC: it has specific entry points (used for refactoring) to try all
possible starts in a parser for a given piece of text and returning all the
possible correct asts. As a hand-writen parser, the RBParser can't do that
unless you add the necessary entry points by hand and hack around the error
handling, because most of the parse attempts end on an error (as they
should).

Regards,

Thierry

2017-09-01 8:50 GMT+02:00 Tim Mackinnon :

> Marcus - I'd be interested in how you thought to solve this.
>
> My solution seems to work - but it's not the most elegant. Retrying lots
> of different ways like I show, smacks a bit of desperation (this said, it
> is quite compact).
>
> Apart from that - I was actually interested in thoughts on the parse
> method - the onError naming is a bit misleading compared to other methods
> in the image. I wonder if it should be called something like
> "onErrorMerge:"  to signal that it's going to reuse the results?
>
> Stef - with regards to broken source, my proposed solution reuses what is
> already there - thus if you highlight specific code, it reverts to the
> original strategy and tries to compile just that code. This bugs me however
> - so if you highlight nothing, it tries to compile the source multiple
> ways, I drop down to chopping the source up to where your cursor is - which
> seems like a decent cheap strategy.
>
> I don't know if our parser is able to recover from simple errors and just
> have error nodes in the ast, and whether the #bestNodeFor method then
> ignored error nodes... this is what I think Dolphin used to do.
>
> Tim
>
> Sent from my iPhone
>
> > On 31 Aug 2017, at 19:11, Marcus Denker  wrote:
> >
> >
> >> On 31 Aug 2017, at 19:07, Stephane Ducasse 
> wrote:
> >>
> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon 
> wrote:
> >>> I’m looking for some feedback on the usage of  RBParser>>#parseMethod:
> onError:.
> >>>
> >>> I am looking at ways of improving the way we edit code - and making
> things work (as least for me - but maybe for everyone) a bit more like
> IntelliJ where they have some great code operations and very good keyboard
> support. We are certainly close, but at times feel a bit clumsy - which is
> a shame as we have far better infrastructure to support equivalent
> features. So I thought I would have a go.
> >>
> >> Excellent!!!
> >>
> >>
> >>> Anyway - step one (which I think I’ve come close on), was to teach
> senders/implementors to look at the AST so you don’t have to highlight
> exactly what you want to search on - instead it can infer from your cursor…
> however my next step was to improve how we can select code to ease
> refactoring, bracketing etc…
> >>
> >> Yes but we have to handle broken code then.
> >> Did you check how smart suggestions did it for code that compiled?
> >>
> >
> > I looked some weeks ago and made some notes what to do… but I fear this
> has to wait for next week,
> > there is no way that I can do anything till ESUG…
> >
> >Marcus
>
>
>

Re: [Pharo-users] How to create a minimal image ?

[Thierry Goubier]

2017-08-28 14:41 GMT+02:00 Pavel Krivanek :

> It is not that simple. The baseline expects that you will have a pharo
> repository clone in a folder named 'pharo-core' in your working directory.
> Then you need data  like files or icons.
>
> set -e
> wget http://files.pharo.org/sources/PharoV60.sources
> unzip pharo-core/resources/fonts/BitmapDejaVuSans.fuel -d .
> mkdir icon-packs
> cd icon-packs
> wget http://github.com/pharo-project/pharo-icon-packs/archive/idea11.zip
> cd ..
> pharo Pharo7.0-metacello-32bit-82ecd43.image --no-default-preferences
> eval --save "Metacello new baseline: 'UI';repository:
> 'filetree://pharo-core/src'; load"
>

Thanks.


>
> Unfortunatelly the resultant image is not usable - it immediately falls
> into the emergency evaluator - because of the dependencies on translation
> and fast table. We need to provide some care to it again because it is not
> generated regularly -> it gets quickly broken.
>

Understood. I think it may have an overall huge benefit by making the
system far more modular once done. But maybe, for it to work effectively,
one needs to have a usable minimal image with the GUI and very simple core
tools.

Regards,

Thierry


>
> -- Pavel
>
>
> 2017-08-28 13:47 GMT+02:00 Thierry Goubier :
>
>> Hi Pavel,
>>
>> what would be the expression for building such an intermediate image out
>> of the minimal image? This?
>>
>> Metacello new
>>   baseline: 'BasicTools';
>>   repository: 'github://pharo-project/pharo:master/src';
>>   load
>>
>> Regards,
>>
>> Thierry
>>
>>
>> 2017-08-28 13:24 GMT+02:00 Pavel Krivanek :
>>
>>> What do you expect from such minimal image? Because we can produce
>>> several intermediate steps on the way to the standard full Pharo image
>>> (BaselineOfMorphicCore, BaselineOfMorphic, BaselineOfUI,
>>> BaselineOfBasicTools...)
>>>
>>> -- Pavel
>>>
>>> 2017-08-28 13:17 GMT+02:00 Dimitris Chloupis :
>>>
>>>> oh , then its not what I am thinking as minimal image. Pity, oh well ,
>>>> I will wait for bootstrap to mature then :)
>>>>
>>>> On Mon, Aug 28, 2017 at 2:09 PM Pavel Krivanek <
>>>> pavel.kriva...@gmail.com> wrote:
>>>>
>>>>> The minimal image is headless image without any GUI. It is useless to
>>>>> try to open it this way.
>>>>>
>>>>> -- Pavel
>>>>>
>>>>> 2017-08-28 13:03 GMT+02:00 Dimitris Chloupis :
>>>>>
>>>>>> hmm does not work for me, it open the icon of pharo on macos sierra
>>>>>> dock and it stays there doing nothing
>>>>>> right clicking on it and choosing quit does nothing, so I am have to
>>>>>> use force quit to make it close
>>>>>>
>>>>>> I have downloaded pharo 6.1 from the website, default download, 32
>>>>>> bit, minimal 32 bit image. I drag and drop image on top of pharo.
>>>>>>
>>>>>> On Mon, Aug 28, 2017 at 10:29 AM Pavel Krivanek <
>>>>>> pavel.kriva...@gmail.com> wrote:
>>>>>>
>>>>>>> 2017-08-26 19:31 GMT+02:00 Dimitris Chloupis 
>>>>>>> :
>>>>>>>
>>>>>>>> I remember that the website used to link to a minimal image
>>>>>>>> download but it does not seem there is one anymore
>>>>>>>>
>>>>>>>> Is still minimal image maintained ?
>>>>>>>>
>>>>>>>
>>>>>>> yes, as part of the bootstrap process
>>>>>>>
>>>>>>>
>>>>>>>> Are there ways to make a image minimal ?
>>>>>>>>
>>>>>>>
>>>>>>> it is created in bootstrap/scripts/build.sh under
>>>>>>> name Pharo7.0-metacello-* and saved on files.pharo.org as
>>>>>>> http://files.pharo.org/image/70/latest-minimal-32.zip or
>>>>>>> http://files.pharo.org/image/70/latest-minimal-64.zip
>>>>>>>
>>>>>>> So you do not need to do it by yourself.
>>>>>>>
>>>>>>> -- Pavel
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>

Re: [Pharo-users] How to create a minimal image ?

[Thierry Goubier]

Hi Pavel,

what would be the expression for building such an intermediate image out of
the minimal image? This?

Metacello new
  baseline: 'BasicTools';
  repository: 'github://pharo-project/pharo:master/src';
  load

Regards,

Thierry

2017-08-28 13:24 GMT+02:00 Pavel Krivanek :

> What do you expect from such minimal image? Because we can produce several
> intermediate steps on the way to the standard full Pharo image
> (BaselineOfMorphicCore, BaselineOfMorphic, BaselineOfUI,
> BaselineOfBasicTools...)
>
> -- Pavel
>
> 2017-08-28 13:17 GMT+02:00 Dimitris Chloupis :
>
>> oh , then its not what I am thinking as minimal image. Pity, oh well , I
>> will wait for bootstrap to mature then :)
>>
>> On Mon, Aug 28, 2017 at 2:09 PM Pavel Krivanek 
>> wrote:
>>
>>> The minimal image is headless image without any GUI. It is useless to
>>> try to open it this way.
>>>
>>> -- Pavel
>>>
>>> 2017-08-28 13:03 GMT+02:00 Dimitris Chloupis :
>>>
 hmm does not work for me, it open the icon of pharo on macos sierra
 dock and it stays there doing nothing
 right clicking on it and choosing quit does nothing, so I am have to
 use force quit to make it close

 I have downloaded pharo 6.1 from the website, default download, 32 bit,
 minimal 32 bit image. I drag and drop image on top of pharo.

 On Mon, Aug 28, 2017 at 10:29 AM Pavel Krivanek <
 pavel.kriva...@gmail.com> wrote:

> 2017-08-26 19:31 GMT+02:00 Dimitris Chloupis :
>
>> I remember that the website used to link to a minimal image download
>> but it does not seem there is one anymore
>>
>> Is still minimal image maintained ?
>>
>
> yes, as part of the bootstrap process
>
>
>> Are there ways to make a image minimal ?
>>
>
> it is created in bootstrap/scripts/build.sh under
> name Pharo7.0-metacello-* and saved on files.pharo.org as
> http://files.pharo.org/image/70/latest-minimal-32.zip or
> http://files.pharo.org/image/70/latest-minimal-64.zip
>
> So you do not need to do it by yourself.
>
> -- Pavel
>

>>>
>

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

Hi Stephan,

2017-08-28 10:50 GMT+02:00 stephan :

> On 26-08-17 18:38, Thierry Goubier wrote:
>
> For me, it has the same effect: the editor isn't in a single place
>> anymore. You may consider it doesn't matter; IMHO it does matter (and it
>> makes for me the Newspeak editor slightly less efficient; the same that the
>> Smalltalk system browser seemed more effective than the Self in-place
>> method edit, for having used both).
>>
>
> A concrete problem with the Newspeak editor/browser is the invisibility of
> multiple open edits when editing a large class. There might be changes
> scrolled away. What it misses is an efficient way of looking only at the
> open edits. That could be achieved by having a view collapsing all
> non-edited code.


Would a class-level save work? One could trigger the collapse there as well.

Thierry



>
>
> Stephan
>
>
>

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

2017-08-28 9:15 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 27, 2017, at 7:13 PM, Thierry Goubier 
> wrote:
> >
> > Hi Doru,
> >
> > thanks for the explanation...
> >
> > I'll end up with three questions:
> >
> > - What makes Bloc different compared to the InterViews and Amulet
> toolkits? And Unidraw?
>
> Bloc is a low level GUI framework. The widgets and the interaction model
> for building complete applications belongs to a layer above it. This is
> what Brick is supposed to be. We are right now at the level of building
> widgets and did not yet decide on the concrete the interaction model. That
> is why to make it useful, we use the editor embedded inside a Morphic-based
> interface.
>

What do you mean by the interaction model? Because, even at low-level, Bloc
has already chosen a interaction model (probably a thread per window
dispatching events to components arranged in a tree model by bounding boxes
+ a focus for input, and propagation of damage events upstream).

Do you means something like MVC or PAC-Amodeus?


>
> I did not know Amulet, but Interviews and Unidraw I read about more than a
> decade ago and even then I did not manage to get my hands on a working
> copy. Unidraw is a high level component-based engine for building
> applications that bares more similarities with something like Glamour.
> Nevertheless, I never saw Unidraw in practice and from the documentation
> that is available it is hard to distinguish the details, and details matter
> a lot.
>

The InterViews code (and UniDraw) is easy to find; it has been maintained
for open source system under the name ivTools. In it, iDraw is a fine
example of UniDraw, and it's GUI (the way it shows scrolling without
scrollbars is typical of the visualisation community). Another example is
TkInetd.

Something that is not usually built in ivTools, but which I think is an
absolute must study item for anybody doing GUI toolkits, is Doc. The source
is available, probably in the InterViews 3.0 source distribution. Doc is
also described in the book Design Pattern.


>
> So, perhaps the most important difference is that Bloc works now in Pharo.
> This does not mean that it is the best possible framework, only that it is
> the best we could do. We are confident it is quite good, but it remains to
> be seen whether it will be enough to be practical.
>

I agree about that: works in Pharo. I expect it to be good, on the level of
those toolkits from the 90's, which means probably as good as anything
commercially available today, and perfectly suited to Pharo needs.


>
>
> > - Will some of your workflows enables exploration of parallel,
> non-deterministic programs?
>
> This is certainly an area of interest, although not an easy one. We
> already used logging that collected signals from multiple processes and
> explored them inside GT Inspector, but certainly more is needed.


>
> > - Will we be able to have non-linear execution paths and explorations
> through examples and documentation?
>
> I am not sure what you mean by execution paths, but when it comes to
> exploration, this is exactly one of the things we are after: there are
> multiple contexts one might want to “consume" code in and most of these are
> unforeseen. For example, showing a method inside a piece of documentation
> provides an entry point that invites a kind of navigation that is
> orthogonal to the default code structure. The whole idea behind humane
> assessment is that we should craft tools to match the current context of
> interest and this implies new angles of exploration, and this is what GT
> offers. Last year at ESUG I provided some examples of such exploration
> paths:
> https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA


Well, the question arise because I think one of the thing you seems to be
targeting for documentation is iPython, and iPython is sequential (the flow
of statements through the document) and well suited to its purpose. And the
GTExamples pragmas looks like a poor man's graph of dependents examples.

At the same time, I see the GT concrete realisation as working often with a
single object; that is a single GT inspector showing two panes on a screen
(or a playground, which means a single object and a script).

So I wonder if that restriction is significant.


> But, I am not sure I actually addressed your question.
>

I'm not sure I know what I am looking for exactly myself. So that make that
question difficult to answer?

I'm starting to piece around what I would need for this, one item at a
time. It's not important however; it does not has enough research value,
just that it could be interesting.

Regards,

Thierry


>
> Cheers,
> Doru
>
> > Regards,
> >
> >

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

Hi Doru,

thanks for the explanation...

I'll end up with three questions:

- What makes Bloc different compared to the InterViews and Amulet toolkits?
And Unidraw?

- Will some of your workflows enables exploration of parallel,
non-deterministic programs?

- Will we be able to have non-linear execution paths and explorations
through examples and documentation?

Regards,

Thierry

2017-08-27 13:37 GMT+02:00 Tudor Girba :

> Hi Thierry,
>
> Indeed, you noticed correctly that we stayed away from the code browser.
>
> We found several years ago that Morphic  was too limiting. During the
> Spotter implementation we found ourselves having to construct a
> mini-Morphic in order to do what we wanted to do. With text we had several
> prototypes for a different kind of editing experience, but we hit a wall.
> The interface from the GTInspector is the most rudimentary solution we
> could put in place, and it is there mostly as a placeholder to get over the
> bridge.
>
> This is why we joined the Bloc project and we focused all our tool
> development effort on it. The goal is to be able to build interfaces that
> do not yet exist and that enable workflows that are radically different. We
> showed can do that once we have an infrastructure, and we will continue to
> do it until we have a full development experience.
>
> We did not start from the experience of writing code explicitly. That is
> because the IDE should encompass all activities including the way we
> understand a system, and we think that focusing on reading is to be left
> for the previous century. So, we started from the inspector and debugger
> and we are making our way towards the writing part.
>
> Writing code is certainly of deep interest to us. However, the system
> browser is the least interesting of the places where we want to write code.
> That is because we want to code against live objects, not against dead
> text. The main use case the system browser is good for is to organize code
> and to find a starting place for getting to a living object. For the rest
> of the use cases, there are other solutions that are better. For example,
> even with the current Playground, we have people spending more time in
> there than in the code browser. That says something given that the
> Playground is quite bare at the moment.
>
> We do not think in terms of tools, but the overall workflows we want to
> support. It’s not a race against features, but a reimagining of what an
> experience can be like. For example, let’s take documentation: right now,
> both producing and consuming documentation happens mostly outside of the
> environment. So, the I in the IDE is failing in this respect. We want to
> make both of these activities more attractive inside the environment and
> the demo you see here is a step in that direction. There is no name for
> this tool yet because we tend to not phrase the problem like that.
>
> Related to other editors, there are indeed WYSWIG tools, but they are
> typically not dynamic. There are viewers that are dynamic, but they tend to
> not scale well and not be editable. There are tools that scale, but they
> are not too visual. And even when there exist some, they are not in an IDE.
> So, yes, there are pieces that already exist, but the way we apply them is
> novel.
>
> As for syntax highlighting, it is tied to text and attributes but only to
> the extent we wanted it to be. The current implementation is 2k lines of
> code. In comparison, just the core of Rubric is 5.5k. But, the rendering is
> not related to text whatsoever. Word and adornments are just element that
> conform to a layout. So, this means that people can build something else at
> a much smaller costs should they want to.
>
> Cheers,
> Doru
>
>
> > On Aug 27, 2017, at 10:43 AM, Thierry Goubier 
> wrote:
> >
> > Hi Doru,
> >
> > 2017-08-27 9:24 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > > On Aug 27, 2017, at 12:06 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
> > >
> > > Hi Tim,
> > >
> > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon :
> > > I think you pose some interesting design challenges - but it's worthy
> of experimentation.
> > >
> > > I share Denis' enthusiasm to build something better - but it's true
> it's not an easy problem space.
> > >
> > > I'm a big fan of GTInspector, but sometimes I slide across and lose my
> context (not always, and not for all types of problems).
> > >
> > > I think you may be on the key issue, the loss of context when
> navigating through the code. In the 90's, that was called the 'lost in
> hyperspace' problem linked with h

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

Hi Doru,

2017-08-27 9:24 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 27, 2017, at 12:06 AM, Thierry Goubier 
> wrote:
> >
> > Hi Tim,
> >
> > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon :
> > I think you pose some interesting design challenges - but it's worthy of
> experimentation.
> >
> > I share Denis' enthusiasm to build something better - but it's true it's
> not an easy problem space.
> >
> > I'm a big fan of GTInspector, but sometimes I slide across and lose my
> context (not always, and not for all types of problems).
> >
> > I think you may be on the key issue, the loss of context when navigating
> through the code. In the 90's, that was called the 'lost in hyperspace'
> problem linked with hypertexts and hypermedia.
> >
> > I'm not sure it was ever resolved (I stopped following that research
> community during my PhD), apart from considering that google solved it for
> the web. At least, this would be the choice made by Newspeak: consider that
> the code is like the web, and build a system web browser.
> >
> >
> > For unique extractions - inlining is a no brainer (it's just like code
> folding in many editors). For non-unique, maybe something in the gutter
> might let you easily flip... I don't know, but I'm not convinced our
> current way is always optimal.
> >
> > Agreed. I have changed the way I code to reduce the context needed to
> understand it.
> >
> >
> > Still, the whole moldable idea is to make it easy to experiment - and
> that's the cool bit. That's where we thrive.
> >
> > Smalltalk has allways been open to that sort of experiment. The moldable
> bit may make it easier, or at least not more complex than it was when
> Smalltalk systems were a lot smaller. Now, is that moldable implementation
> really that free, or has it sacrificed certain freedoms to make moldable
> things easier?
>
> Please let me intervene briefly :).
>
> Smalltalk was always indeed open. However, we noticed that regardless of
> the application domain, tools essentially looked the same for these
> systems. All Smalltalkers I asked extended Object at least once, but before
> the GTInspector, most of them never extended the inspector. Our language
> was extremely dynamic, but our tools less so. That is a conceptual problem
> that we address with what we call moldability.
>

Hum. From 1992 to now, I would make the same statement in the Smalltalk
world, mostly talking a certain conservatism first (look at how much the
system browser has evolved over the years), but also some questions about
efficiency of alternative forms.

For example, the code view of the GTInspector remain for me as one of the
clumsiest, worse view I've ever seen in the Smalltalk world for editing
code.


>
> The goal of moldability is to make it inexpensive to customize. To this
> end, we approach the IDE as a language and the moldability is captured in
> the operators that language provides. Of course, there are limitations to
> what can be doable inexpensively. However, it turns out that if you do
> manage to bring the cost to a radical low cost, you get much more
> extensions and experimentations going on.
>

I'm a bit missing where the moldability of the IDE went, in that context.
You seem to stear very clear from anything related to the system browser...


>
> All infrastructures make certain things easier and others less so. The
> value of all this does depend on what are the operators and how deep in the
> infrastructure they are placed. For example, the moldable editor shows
> these expandable elements as part of syntax highlighting. Syntax
> highlighting existed since a long time, so making it also able to show
> other things is quite powerful and requires nothing hardcoded. In fact, I
> do not know of any other editor that can do that while still having the
> performance we get.
>

? Especially that last statement.

Adding non text elements in an editor has allways been a fairly easy
endeavour in ST, as long as I could remember (1993?).

Performance on long texts is orthogonal to Bloc, right? It is present in
all editors that do formatting on long documents since the first WYSIWIG
editors appeared in the 80's.

And, so far, the examples you're showing means that editor isn't as capable
as Doc (in 1989/1990?) was.

I a bit worried about that syntax highlighting approach. It seems to me
very tied to a text + attributes representation instead of an object
representation, and I find that API in Pharo horribly clumsy and
ineffective, for the apparent benefit of slightly reducing object storage
size with a kind of RLE compression.


>
> But, even more impor

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

Hi Tim,

2017-08-26 23:27 GMT+02:00 Tim Mackinnon :

> I think you pose some interesting design challenges - but it's worthy of
> experimentation.
>
> I share Denis' enthusiasm to build something better - but it's true it's
> not an easy problem space.
>
> I'm a big fan of GTInspector, but sometimes I slide across and lose my
> context (not always, and not for all types of problems).
>

I think you may be on the key issue, the loss of context when navigating
through the code. In the 90's, that was called the 'lost in hyperspace'
problem linked with hypertexts and hypermedia.

I'm not sure it was ever resolved (I stopped following that research
community during my PhD), apart from considering that google solved it for
the web. At least, this would be the choice made by Newspeak: consider that
the code is like the web, and build a system web browser.


>
> For unique extractions - inlining is a no brainer (it's just like code
> folding in many editors). For non-unique, maybe something in the gutter
> might let you easily flip... I don't know, but I'm not convinced our
> current way is always optimal.
>

Agreed. I have changed the way I code to reduce the context needed to
understand it.


>
> Still, the whole moldable idea is to make it easy to experiment - and
> that's the cool bit. That's where we thrive.
>

Smalltalk has allways been open to that sort of experiment. The moldable
bit may make it easier, or at least not more complex than it was when
Smalltalk systems were a lot smaller. Now, is that moldable implementation
really that free, or has it sacrificed certain freedoms to make moldable
things easier?

Regards,

Thierry


>
> Tim
>
> Sent from my iPhone
>
> On 26 Aug 2017, at 18:38, Thierry Goubier 
> wrote:
>
>
>
> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov :
>
>> No Thierry, Newspeak do not allow it. And it not looks similar to what I
>> want.
>>
>
> Hum, you would still get the same overall approach: editor inside editor
> (or view inside view). Now, you can say it is not the same, up to you.
>
> For me, it has the same effect: the editor isn't in a single place
> anymore. You may consider it doesn't matter; IMHO it does matter (and it
> makes for me the Newspeak editor slightly less efficient; the same that the
> Smalltalk system browser seemed more effective than the Self in-place
> method edit, for having used both).
>
>
>>
>> Now command+click on selector opens implementors window. In past it moved
>> browser to single implementor. It was nice and it is how other IDEs are
>> working.
>>
>
> You miss the past behaviour? Why not adding it again?
>
>
>> But as Tim notice it always loses context. And it is quite difficult to
>> browse long call chain which include many small methods.
>>
>
> I'm not sure it would solve that one.
>
> Either it is a long call chain with a fan-out of one, in which case the
> developper is creating many useless single line methods because it is "the
> right way"(tm), or it has a fan-out greater than one (your typical
> polymorphic code) and then each time you open, you have half a dozen
> implementors.
>
> For that, you already have the flow browser.
>
>
>> So with new editor command+click will be able expand implementor just in
>> place. I think it will be big improvement for IDE.
>>
>
> As I said, with Calypso and Nautilus handling badly long methods, then a
> method inside a method just makes the top level method longer... I'd like
> to see you do that on Metacello or SmaCC code, where important methods
> easily go over 50 lines before you expand anything.
>
> I'd say there that the GTInspector approach would work better -> expand on
> the right, with the ability to keep two side by side, and overlaid with
> lines clearly showing what has been expanded (for that "context" thing).
>
> Regards,
>
> Thierry
>
>
>>
>> 2017-08-26 14:59 GMT+02:00 Thierry Goubier :
>>
>>>
>>>
>>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov :
>>>
>>>>
>>>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon :
>>>>
>>>>> Denis - that's a very cool idea if I've understood you - expand in the
>>>>> source code of the current method, literally inline? So you could scroll 
>>>>> up
>>>>> and down to view the context as you expand it out?
>>>>>
>>>>
>>>> Yes, exactly.
>>>>
>>>
>>> Then that would look a bit like the NewSpeak code browser, if you would
>>&g

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

2017-08-26 15:44 GMT+02:00 Denis Kudriashov :

> No Thierry, Newspeak do not allow it. And it not looks similar to what I
> want.
>

Hum, you would still get the same overall approach: editor inside editor
(or view inside view). Now, you can say it is not the same, up to you.

For me, it has the same effect: the editor isn't in a single place anymore.
You may consider it doesn't matter; IMHO it does matter (and it makes for
me the Newspeak editor slightly less efficient; the same that the Smalltalk
system browser seemed more effective than the Self in-place method edit,
for having used both).


>
> Now command+click on selector opens implementors window. In past it moved
> browser to single implementor. It was nice and it is how other IDEs are
> working.
>

You miss the past behaviour? Why not adding it again?


> But as Tim notice it always loses context. And it is quite difficult to
> browse long call chain which include many small methods.
>

I'm not sure it would solve that one.

Either it is a long call chain with a fan-out of one, in which case the
developper is creating many useless single line methods because it is "the
right way"(tm), or it has a fan-out greater than one (your typical
polymorphic code) and then each time you open, you have half a dozen
implementors.

For that, you already have the flow browser.


> So with new editor command+click will be able expand implementor just in
> place. I think it will be big improvement for IDE.
>

As I said, with Calypso and Nautilus handling badly long methods, then a
method inside a method just makes the top level method longer... I'd like
to see you do that on Metacello or SmaCC code, where important methods
easily go over 50 lines before you expand anything.

I'd say there that the GTInspector approach would work better -> expand on
the right, with the ability to keep two side by side, and overlaid with
lines clearly showing what has been expanded (for that "context" thing).

Regards,

Thierry


>
> 2017-08-26 14:59 GMT+02:00 Thierry Goubier :
>
>>
>>
>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov :
>>
>>>
>>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon :
>>>
>>>> Denis - that's a very cool idea if I've understood you - expand in the
>>>> source code of the current method, literally inline? So you could scroll up
>>>> and down to view the context as you expand it out?
>>>>
>>>
>>> Yes, exactly.
>>>
>>
>> Then that would look a bit like the NewSpeak code browser, if you would
>> like to try the concept.
>>
>> There are disadvantages to that paradigm. One of those is that the system
>> browser in Pharo is ill-suited to long methods.
>>
>> Thierry
>>
>>
>>>
>>>
>>>> One of the complaints around refactoring is that you lose context of
>>>> surrounding code - intelligent in place expansion would be the best of both
>>>> worlds...
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 26 Aug 2017, at 11:40, Denis Kudriashov 
>>>> wrote:
>>>>
>>>> This is really cool. It opens so many possibilities.
>>>>
>>>> I imaging method editor where message sends can be expanded to
>>>> implementors just in place.
>>>>
>>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba :
>>>>
>>>>> Hi,
>>>>>
>>>>> We are really pleased to announce another major advancement in the
>>>>> development of the moldable editor, and most of it was enabled because of
>>>>> one new feature: expandable elements. We think this will impact
>>>>> significantly our day to day interactions.
>>>>>
>>>>> To exemplify what we mean, we will make use of two more alpha projects
>>>>> that we did not announce yet: GT Documenter (a set of documentation tools
>>>>> based on Pillar and GT Examples) and GT Mondrian (the graph visualization
>>>>> engine), both of which are being implemented in Bloc.
>>>>>
>>>>> Please take a look at the following pictures showing the documentation
>>>>> Pillar file that ships together with GT Mondrian. What stands out are the
>>>>> two embedded pictures. These are actually not pictures, but
>>>>> visualizations rendered live during the viewing of the document out of a
>>>>> referenced GT Example.
>>>>>
>>>>>
>>>>> Now, GT Examples are likely also new for most p

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Thierry Goubier]

2017-08-26 14:46 GMT+02:00 Denis Kudriashov :

>
> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon :
>
>> Denis - that's a very cool idea if I've understood you - expand in the
>> source code of the current method, literally inline? So you could scroll up
>> and down to view the context as you expand it out?
>>
>
> Yes, exactly.
>

Then that would look a bit like the NewSpeak code browser, if you would
like to try the concept.

There are disadvantages to that paradigm. One of those is that the system
browser in Pharo is ill-suited to long methods.

Thierry


>
>
>> One of the complaints around refactoring is that you lose context of
>> surrounding code - intelligent in place expansion would be the best of both
>> worlds...
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 26 Aug 2017, at 11:40, Denis Kudriashov  wrote:
>>
>> This is really cool. It opens so many possibilities.
>>
>> I imaging method editor where message sends can be expanded to
>> implementors just in place.
>>
>> 2017-08-26 1:03 GMT+02:00 Tudor Girba :
>>
>>> Hi,
>>>
>>> We are really pleased to announce another major advancement in the
>>> development of the moldable editor, and most of it was enabled because of
>>> one new feature: expandable elements. We think this will impact
>>> significantly our day to day interactions.
>>>
>>> To exemplify what we mean, we will make use of two more alpha projects
>>> that we did not announce yet: GT Documenter (a set of documentation tools
>>> based on Pillar and GT Examples) and GT Mondrian (the graph visualization
>>> engine), both of which are being implemented in Bloc.
>>>
>>> Please take a look at the following pictures showing the documentation
>>> Pillar file that ships together with GT Mondrian. What stands out are the
>>> two embedded pictures. These are actually not pictures, but
>>> visualizations rendered live during the viewing of the document out of a
>>> referenced GT Example.
>>>
>>>
>>> Now, GT Examples are likely also new for most people. We introduced them
>>> a couple of years ago based on the original idea of Markus Gaelli. These
>>> are a kind of tests that return an object and that can be built out of
>>> other examples. The nice thing is that they are always executable and
>>> testable. So, of course, if you see the resulting object,  you can also see
>>> the code that created it, and if you see the code, you can even execute it
>>> live, right in place (notice the preview of the second snippet).
>>>
>>> 
>>>
>>> Perhaps the most controversial part of GT Examples is that they offer a
>>> mechanism to define static dependencies via pragmas. Please, let’s leave
>>> this debate to another occasion, but please also notice that tools can use
>>> that static information to unfold the code of the referenced method (notice
>>> the nested code editors).
>>>
>>> A side note: if you look closer at the list with three items at the top
>>> of the Tutorial section, you will notice numbering next to #. That is
>>> actually syntax highlighting and so is the mechanism that embeds the
>>> expandable elements. It’s really cool.
>>>
>>> Taking step back, when we introduced the editor a few weeks ago, we
>>> called it moldable because we said we can make it take different shapes
>>> easily. GT Documenter with everything you see in the above screenshots has
>>> currently ~500 lines of code, and all this while still having an editor
>>> that is highly scalable.
>>>
>>> We think that Bloc and Brick will change dramatically face of Pharo and
>>> now we can start to get a glimpse of what is possible. For example, the use
>>> case presented above is more than a technical tool, and we think this will
>>> change both the way we write documentation and the way we consume it.
>>>
>>> All these will be presented at ESUG both during presentations and at the
>>> Innovation Awards competition. In the meantime, those that want to play
>>> with it can execute the following in both Pharo 6.1 and Pharo 7.0:
>>>
>>> Iceberg enableMetacelloIntegration: true.
>>> Metacello new
>>>baseline: 'GToolkit';
>>>repository: 'github://feenkcom/gtoolkit/src';
>>>load.
>>>
>>> And then inspect:
>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar'
>>> asFileReference
>>>
>>> Cheers,
>>> The feenk team
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Innovation comes in the least expected form.
>>> That is, if it is expected, it already happened."
>>>
>>>
>>
>

Re: [Pharo-users] Loading and saving packages to filetree repos

[Thierry Goubier]

Hi Luke,

ok, it's a high tech solution, this is more because I could not on the 
spot remember what you would need as a script (and also because your 'no 
metadata' requirement makes the filetree solution problematic).


But I'd suggest still one bit of advice that is implicit in my solution: 
create at least a baseline for your project (covering say all packages 
in your repository); instead of hacking around with Monticello and 
FileTree, it will allow you to use a simple Metacello command to load 
everything and prepare correct, long term use of your project.


And you will have the save everything as well.

Regards,

Thierry

Le 20/08/2017 à 10:36, Luke Gorrie a écrit :

Hi Thierry,

I am really looking for a "low-tech" solution here - five line 
Monticello code snippet - that will be easy for me to understand (as a 
newbie) and also easy for new contributors to my project to understand 
(who will have no prior exposure to Pharo.)


I don't know what AltBrowser is, but just as a user I need to get a bit 
more "winnage" before I am ready to take another iteration at learning 
more tools. The tools currently represent barriers in the way of solving 
my problems. I am sure this will change over time with more gradual 
learning and experience.



On 18 August 2017 at 16:28, Thierry Goubier <mailto:thierry.goub...@gmail.com>> wrote:


Hi Luke,

if you use gitfiletree with AltBrowser and configurations/baselines,
then you'll see that you have a command to do the writing for you,
without metadata and with a single git commit.

Regards,

Thierry


Le 17/08/2017 à 13:25, Luke Gorrie a écrit :

Hoi,

I want to have a quick "cheat mode" for loading and saving the
Smalltalk packages in my project. This is to make life easy for
newbies who are not very familiar with Monticello and Metacello.

The "cheat" is to assume that there is one filetree://
repository that contains all of the relevant packages, and all
we need to do is load or save each of those packages in that
repository.

I have the loading part working already:

  repo := MCFileTreeRepository new directory: '/foo/bar/baz'
asFileReference.
  repo allFileNames do: [ :file |
  (repo versionFromFileNamed: file) load.
].

but now I am wondering how to do the saving part? That is, given
a path to a filetree repo like '/foo/bar/baz', how do I save
each package in that repo i.e. export the code in the image?

Ideally I would like the same operation to skip metadata that is
likely to cause conflicts when the code is checked into Git
later e.g. package timestamps and versions.

Tips would be appreciated :).

Re: [Pharo-users] Loading and saving packages to filetree repos

[Thierry Goubier]

Hi Luke,

if you use gitfiletree with AltBrowser and configurations/baselines, 
then you'll see that you have a command to do the writing for you, 
without metadata and with a single git commit.


Regards,

Thierry

Le 17/08/2017 à 13:25, Luke Gorrie a écrit :

Hoi,

I want to have a quick "cheat mode" for loading and saving the Smalltalk 
packages in my project. This is to make life easy for newbies who are 
not very familiar with Monticello and Metacello.


The "cheat" is to assume that there is one filetree:// repository that 
contains all of the relevant packages, and all we need to do is load or 
save each of those packages in that repository.


I have the loading part working already:

 repo := MCFileTreeRepository new directory: '/foo/bar/baz' 
asFileReference.

 repo allFileNames do: [ :file |
 (repo versionFromFileNamed: file) load.
   ].

but now I am wondering how to do the saving part? That is, given a path 
to a filetree repo like '/foo/bar/baz', how do I save each package in 
that repo i.e. export the code in the image?


Ideally I would like the same operation to skip metadata that is likely 
to cause conflicts when the code is checked into Git later e.g. package 
timestamps and versions.


Tips would be appreciated :).

Re: [Pharo-users] Cloning code from GitHub using Iceberg

[Thierry Goubier]

Le 24/07/2017 à 21:55, Hernán Morales Durand a écrit :

2017-07-24 4:29 GMT-03:00 Alistair Grant :

Hi Hernan,

On Sun, Jul 23, 2017 at 06:22:52PM -0300, Hern??n Morales Durand wrote:

Hi guys,

I am trying to import code - in Pharo 6 - from a GitHub repository:
https://github.com/jigyasa-grover/CORMAS-Pharo. The repository doesn't
include a Baseline, and so it is not loadable using a Metacello
expression right?

I've tried to clone it with Iceberg with Remote URL:
https://github.com/jigyasa-grover/CORMAS-Pharo.git

I ended with a "Repository CORMAS-Pharo is invalid" so I wonder what's
exactly is invalid? I can browse the history but I don't know if any
code from that repository was already loaded in my image.

The URL should be specified as the ghost text suggest? Currently the
ghost text is: g...@github.com:user/project.git

Should I fill the "Code subdirectory" field?


I just:

1. opened Icerberg
2. pressed "Clone repository"
3. Entered https://github.com/jigyasa-grover/CORMAS-Pharo.git as the URL
4. Left the subdirectory blank (opening the repository in a browser you
can see that the packages are in the top level directory)
5. Clicked Create repository
6. Selected the repository, the packages tab and loaded the
ConfigurationOfComas

without any problem.

Pharo 6.0
Latest update: #60501



Thank you! This worked also in 6.1.


Is there an easy way to tell which version of Iceberg I have loaded?
I'm sure it is 0.5.x, but not what the x is.


It would be nice to have something like

(RPackage organizer packageNamed: 'Iceberg') version


This information is available via Metacello, if it was properly loaded 
via a configuration.


(MetacelloProjectRegistration registry
registrationForExactClassNamed: ConfigurationOfIceberg
ifAbsent: [  ]) ifNotNil: [:r | r printString]

See MetacelloProjectRegistration>>#printOn: for the details of querying 
the spec of the project.


Baselines have no version information; if there is (like in git-based 
scenario), it is in the repository url and one has to decrypt it.


Thierry


Cheers,

Hernán



Cheers,
Alistair

Re: [Pharo-users] Why do we separate class/instance methods in the browser?

[Thierry Goubier]

Le 23/07/2017 à 18:58, Attila Magyar a écrit :

Maybe if the protocol list was a tree instead of a list then it would make
sense to include the class methods there. This would also make easier to
move methods from class side to instance side or vica versa with simple drag
and drop (without relying on the refactor/move to class side option).


The AltBrowser has been providing that tree view for a few years.

That view is very convenient when you want to see class methods names 
while writing an instance method (and the reverse).


Never thought of that need for the drag and drop feature. Maybe I'll add 
it (or simply check how it currently behaves for that use case).


Thierry





--
View this message in context: 
http://forum.world.st/Why-do-we-separate-class-instance-methods-in-the-browser-tp4956231p4956439.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Why do we separate class/instance methods in the browser?

[Thierry Goubier]

Hi Tim,

if you're looking for experiments, you may want to look for the already 
existing (or past) experiments on alternative systems browsers.


There are a few floating around, and some of them already have an answer 
for what you are considering (change the way class side and instance 
side methods are shown). Since you're interested in GTInspector as well, 
maybe adding GT extensions to a class could let you experiment on that.


Regards,

Thierry

Le 23/07/2017 à 17:04, Tim Mackinnon a écrit :

I think my thread is misunderstood - I’m not saying change how methods work, 
class methods are fine, instance methods are fine - I’m just saying I don’t 
think its ideal anymore to see them so separately in our UI. It was really 
driven home watching great programmers struggle (sure Smalltalk is a bit 
different - and there are many elegant things we have, but class methods are 
pretty normal in many languages) - and I have a similar frustration in that I 
find it a straight jacket that we have to click that class button just because 
we want to write what is effectively a constructor that occurs to us when we 
are writing an instance method. Its very jarring and breaks your flow to 
“switch mode” to type one in.

I think Pharo is an environment to experiment with how we think about 
programming (in Smalltalk as well as other languages) - GTInspector is 
marvellous, that is something that really shows how thinking about the problem 
differently can make such a difference. While, I think our standard code 
browsers are ok - they are stuck in a rut that we need to break. Calypso is a 
hint at what is possible, but I want GTinspector type thinking more prevalent… 
with similar types of ideas that inspire us to code better.

Anyway, it seems like I need to take this away and try some experiments by 
myself.

Tim



On 23 Jul 2017, at 12:45, Stephane Ducasse  wrote:

Hi subbu

I used the same metaphor :)

Stef


On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu  wrote:

On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:


The one that stuck out for me (and is actually mentioned in another
thread this week) was the class/instance method difference. They
conceptually understood the difference coming from other languages
but our UI is tricky to understand with the Class button toggle we
have, and if you get methods on the wrong side, like with a test,
it's quite confusing.



It is an easy mistake to make and I have often seen this confusion in
beginners. With the attention on the methods panel and text input, it is
easy to overlook the class toggle button :-(.

An easy fix is to switch background color to differentiate between class and
instance methods in both code and input panels. A better way would be to use
tabs (like in Inspector).

BTW, I use the metaphor of toys (objects), moulds (classes) and mould
factory (metaclass). A mould is an object from the perspective of the mould
maker. Therefore operations on classes are 'methods' from the maker's
perspective (note the recursion!).


Anyway - this got me thinking - why do we bother having a toggle in
our UI for this these days? Of course we know there is a class and a
metaclass but given that we have icons for methods now (and also have
a Protocol pane ) why don't we just show all the methods we have in
one list and let you filter them or even see them all? It seems much
easier and way more efficient to rapidly code this way.



This perspective comes from the traditional way - code and compile. In
Pharo, we code one method at a time and sources are held in an external file
and a pointer stored in each method, so displaying all methods in one panel
would result in multiple file reads.


The only question then would be how to create methods of the right
type - whether to have a button to create the right template (and put
the  browser code pane in the right context) or whether to indicate
it by convention of the method name when creating it like + new:
aSize etc. (Or even: class new: aSize etc).

The more I think about it, the more it seems like something we should
consider trying both for making ourselves more efficient (I'll bet
everyone has written a method on the wrong side by mistake) and also
helping newcomers.



Such mistakes are part of the learning curve and decrease with time.

Regards .. Subbu

Re: [Pharo-users] get output of a forked process on windows

[Thierry Goubier]

Hi Christophe,

You have to use ProcessWrapper.

Metacello new
  configuration: 'ProcessWrapper';
  repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main';
  load

(as extracted from the baseline of GitFileTree for Pharo4)

Regards,

Thierry


2017-07-18 15:34 GMT+02:00 Christophe Demarey :

> PharoConsole.exe is only available for image versions > 50.
> I need a solution that works on older image versions.
>
> Thanks for the advice,
> Christophe
>
> Le 18 juil. 2017 à 14:26, Guillermo Polito  a
> écrit :
>
> Have you checked the Console version of the windows VM?
>
> On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi,
>>
>> I would like to evaluate a Smalltalk expression in a forked process (i.e.
>> something like OSProcess thisOSProcess waitForCommandOutput: 'pharo
>> Pharo.image eval "SystemVersion current dottedMajorMinor"').
>> It is doable on linux/mac with OSProcess but not on Windows. Is there
>> another way to do that on Windows? I would prefer to avoid to write to a
>> file.
>>
>> Thanks,
>> Christophe
>>
>
>
>
> --
>
> Guille Polito
>
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>

Re: [Pharo-users] 2 questions around gitlab, gitfiletree, BaselineOf

[Thierry Goubier]

Hi Sabine,

I have a slightly different script, a Makefile, which uses another 
trick: put everything into a pharo/ subdirectory. Like that, just rm -rf 
pharo/ erases everything before rebuilding.


I think I would implement the support you need for you to simply be able 
to write:


Metacello new baseline: \'RKA24\'\; repository: 
\'gitfiletree://192.168.1.61:3/SPF/Spesenfuchs.gitspf:1.0?protocol=http\'\;load


so that the clone + Metacello over filetree isn't necessary.

(at the moment, I'm just pretty sure GitFileTree doesn't handle http and 
the port number, but that wouldn't be hard to add)


Regards,

Thierry


Le 11/07/2017 à 12:43, Sabine Manaa a écrit :

After several questions and trials I ended with a script like this:

cd /Applications/Pharo5.0-7.app/Contents/Resources
rm Pharo.image
rm Pharo.changes
curl get.pharo.org/50  | bash
rm -rf spfClonedGitlabRepository
git clone http://192.168.1.61:3/SPF/Spesenfuchs.git 
 --branch 1.0 
spfClonedGitlabRepository
Pharo Pharo.image --no-default-preferences eval --save "(CatalogProvider 
projectNamed: 'GitFileTree') installVersion: #stable. Metacello new 
baseline: 'RKA24'; repository: 'filetree://spfClonedGitlabRepository';load."


It creates a local clone (of a certain version) of my gitlab repository 
(deleting old stuff before) and starts with a new image, loading the 
given branch.


With this, I can always start with a new image, loading exactly the 
version I want from gitlab.


For pushing into gitlab I use the MCFileTreeGitRepository browser and push.

Big thank you for all who helped me, here and in discord.

2017-07-08 18:31 GMT+02:00 Pierce Ng-3 [via Smalltalk] <[hidden email] 
>:


On Fri, Jul 07, 2017 at 06:48:50AM -0700, Sabine Manaa wrote:

> 1) For loading my own code, I currently have a bad solution 
> I would like to load it within my baseline like this below but I dont know

> what to write in the fileTreeRepository method...
>
> baseline: spec
>
>spec
>for: #common
>do: [ spec blessing: #baseline.
>spec repository: ##self fileTreeRepository##.
  ^^^
Here I use 'http://127.0.0.1:20080/', where the http server serves
my filetree
repo directory. The easiest way (for me on Linux/Mac) to get the
http server
running is 'python3 -m http.server 20080'.

This method works for a directory full of .mcz files too.

Pierce




If you reply to this email, your message will be added to the
discussion below:

http://forum.world.st/2-questions-around-gitlab-gitfiletree-BaselineOf-tp4953877p4954007.html



To start a new topic under Pharo Smalltalk Users, email [hidden
email] 
To unsubscribe from Pharo Smalltalk Users, click here.
NAML







View this message in context: Re: 2 questions around gitlab, 
gitfiletree, BaselineOf 

Sent from the Pharo Smalltalk Users mailing list archive 
 at Nabble.com.

Re: [Pharo-users] How to specify metacello package dependencies in a git world?

[Thierry Goubier]

Hi Tim,

Le 09/07/2017 à 10:31, Tim Mackinnon a écrit :
Hi - I am trying to specify a simple package dependency(NeoJSON) for a 
hello world type simple project and I’m hitting problems.


I’ve been reading the DeepIntoPharo chapter and have looked at the blog 
post by Uko 
(http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.html)


But I’m hitting some simple issues and I’m hoping someone can put me 
straight.


My first attempt was the following (my Package is “Lambda” and has been 
versioned and put into GitHub using iceberg defaults).


baseline: spec


spec for: #common do: [
spec
package: 'Lambda' with: [ spec requires: 'NeoJSON' ].
spec
  project: 'NeoJSON'
  with: [
 spec
className: 'ConfigurationOfNeoJSON';
version: #stable;
repository:
   
'https://github.com/svenvc/NeoJSON/tree/master/repository' ]

].


This url won't work: you can access a github repository either with a 
github: url, or a gitfiletree: url (or an iceberg url?)


github://svenvc/NeoJSON:master/repository

or:

gitfiletree://github.com/svenvc/NeoJSON:master/repository

(You may want to use a tag instead of master).

My first question is, what should the repository URL be? No-one seems to 
talk about this in the git world where the gitfile tree info can be in 
different places per project (some put it in the root of the repo, other 
src, others repository or packages etc.). Am I right in thinking this 
url should be where the .package file is located?


Yes. There are repositories where you have a directory with the main 
packages, and other directories with secondary packages. For example, 
FileTree has a main repository/ directory with the packages, and many 
secondary repositories with test packages.


So you need to indicate where the .package are.


When I try the above example by trying:

(BaselineOfLambda project version: 'baseline') load.

  I get a talkback - Could not resolve: ConfigurationOfNeoJSON 
[ConfigurationOfNeoJSON] in 
/Users/macta/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache 
https://github.com/svenvc/NeoJSON/tree/master/repository


(Strangely, that file path is wrong as its pointing to some other 
directory on my filesystem - and I’ve posted a question about this on 
the thread about the working directory implementation, as it looks like 
MCCacheRepository uniqueInstance is getting the wrong default directory).


I don't know, but maybe that could be linked. Would you have preferences 
pointing to the wrong place ?


Anyway - as the above didn’t work, I tried to find an example of someone 
else using Neo and of course Sven had and example but his looks like this:


baseline: spec


spec for: #common do: [
spec configuration: 'NeoJSON' with: [
spec
versionString: #stable;
repository: 'http://mc.stfx.eu/Neo' ].
spec
package: 'Lambda' with: [ spec requires: 'NeoJSON' ].
].

I dan’t seen anyone mention spec configuration before (is this a better 
way?) - although looking at this directory, it seems this is where 
normal Mcz files are, so is it because of that you use this other method?


Anyway , when I try the above - I get a similar error to the above, but 
now it fails loading my Lambda package (presumably because if the 
filesystem error?).


Am I on the right track with the above?


I think you are...


Tim



Regards,

Thierry

Re: [Pharo-users] 2 questions around gitlab, gitfiletree, BaselineOf

[Thierry Goubier]

Hi Sabine,

as far as I remember when I implemented it, the use of a config file 
shouldn't be an issue, because GitFileTree rewrites exactly the 
git@SPF_GITLAB the way you would expect, as long as it manages to 
identify correctly the parts in the URL (and to identify those parts, it 
relies on Zinc).


Now, have you tried with:

gitfiletree://SPF_GITLAB/SPF/Spesenfuchs

?

Zinc correctly identifies SPF_GITLAB as the host, but it writes it 
non-capitalized (spf_gitlab), which may makes it miss your .ssh/config

entry.

In that case, could you add the spf_gitlab entry as well in your config 
file ?


Thierry

Le 07/07/2017 à 21:32, Sabine Manaa a écrit :

Hi Thierry, Gabriel and Peter,

thank you very much. First I had a look at this because it would be nice 
to load directly from Gitlab (with then generating a local repository 
automatically):


spec repository: 
'gitfiletree://gitlab.intra.example.com/ANiceLib:master/ 
placeWhereAreThePackages';


I did not manage to use it because I would need to give a port as 
parameter (we do  not use port 22). I chatted in discord with Peter Uhnak.


It seemed that this is not yet possible because of my case that i do not 
use port 22 and I use a config file.


On the command line, this command succeeds with cloning my repository 
from gitlab:


git clone git@SPF_GITLAB:SPF/Spesenfuchs.git


There is a config file which defines my host:

host SPF_GITLAB
HostName 192.168.1.61
Port 30001

I try to write my baseline with this

spec repository: 'gitfiletree://SPF_GITLAB:SPF/Spesenfuchs.git'.


This did not work in the beginning.

I played around and found out that there are 2 points where I had to 
change the system to make this work:


1) ZnUrl>>parseHostPort:
stream atEnd
ifFalse: ["portNumber := Integer readFrom: stream ifFail: [ 
ZnPortNotANumber signal ].
(portNumber between: 1 and: 65535) ifFalse: [ DomainError signalFrom: 1 
to: 65535 ]."

self port: 30001 "portNumber" ] ]
->> here, it is assumed that there is always a port integer after the :
If i set it hard to my port I skip this problem

2) MCFileTreeGitRepository>>basicFromUrl: aZnUrl
here I changed the code also hard from

repo remoteUrl: 'git@' , aZnUrl host , ':' , path
to
repo remoteUrl: 'git@SPF_GITLAB:SPF/Spesenfuchs.git'

->> here, aUZnUrl host is in lowercase but my name is in uppercase
:SPF is missing

the existing code would make this:
git@spf_gitlab:Spesenfuchs.git
instead of
git@SPF_GITLAB:SPF/Spesenfuchs.git

With this 2 changes, my code could load.

So my question: Are this 2 points issues to fix or should I create my 
own workaround (create my own loader, not making THIS changes )?


Regards
Sabine





2017-07-07 16:06 GMT+02:00 gcotelli [via Smalltalk] <[hidden email] 
>:


Hi Sabine,
for your own baseline you don't need to specify a repository. Just
load it with something like:

Metacello new
baseline: 'RLA24';
repository: 'filetree://disklocation/repository';
load: 'Group To Load'

Also you can have local copies of your dependencies in case you
don't want to use an internet connection for dowloading, just use
the lock command of Metacello to "overwrite" the repository
definitions. For example take a look at:

https://gist.github.com/gcotelli/d4521656358786ae2aca12a70478980f


Regards,
Gabriel


On Fri, Jul 7, 2017 at 10:48 AM, Sabine Manaa <[hidden email]
> wrote:

Hi,

we have our own gitlab running now and I succeeded to move our
code from
sthub to it.
I can push my new code into it from Pharo. All fine.
I also created a Baseline (based on my former configurationOf).
Loading the code from others (e.g. seaside) with this baseline
is also fine.

There are 2 Points where I am sure it could be better (it is worse)
1) For loading my own code, I currently have a bad solution
It is in the postLoadBaseline and does this:

 | gitRepository |
 gitRepository := MCFileTreeRepository new
 directory:
'/Applications/Pharo5.0-7.app/Contents/Resources/spf-gitlab/repository'
asFileReference.
 {'RKA24-Model' . 'RKA24-System' . 'RKA24-Translator' .
'RKA24-View' .
'RKA24-Test' . 'RKA24-Report' . 'RKA24-Overwrites'}
 do: [ :each |
 Gofer it
 repository: gitRepository;
 package: each;
 load ].

I would like to load it within my baseline like this below but I
dont know
what to write in the fileTreeRepository method...

baseline: spec
 
 spec
 

Re: [Pharo-users] 2 questions around gitlab, gitfiletree, BaselineOf

[Thierry Goubier]

Hi Sabine,

I have makefiles to do the sort of thing you describe automatically (build
an image from local, git managed repositories) and a baseline: I write
stuff like

./pharo-cli pharo/Pharo.image --no-default-preferences eval --save
Metacello new baseline: \'MyProject\'\;
repository:\'gitfiletree://`pwd`/../src/\'\; load

(works once gitfiletree has been loaded)

notice the `pwd` embedded in there which allows you to put your local git
clone anywhere you like.

One thing I can't do, however, is having a dependency in
BaselineOfMyProject to a locally hosted project (say BaselineOfANiceLib
stored in ~/Project2017/ClientX/) because when I write the baseline, I
can't be sure where it will be on-disk.

If you're ok with gitfiletree doing the clone from gitlab on its own, one
could still write a direct access to your internal gitlab server, in the
baseline of MyProject, like that:

spec repository: 'gitfiletree://
gitlab.intra.example.com/ANiceLib:master/placeWhereAreThePackages';

The oldest such scripts I have are for Pharo3.

Does that answer your questions ?

Thierry

2017-07-07 15:48 GMT+02:00 Sabine Manaa :

> Hi,
>
> we have our own gitlab running now and I succeeded to move our code from
> sthub to it.
> I can push my new code into it from Pharo. All fine.
> I also created a Baseline (based on my former configurationOf).
> Loading the code from others (e.g. seaside) with this baseline is also
> fine.
>
> There are 2 Points where I am sure it could be better (it is worse)
> 1) For loading my own code, I currently have a bad solution
> It is in the postLoadBaseline and does this:
>
> | gitRepository |
> gitRepository := MCFileTreeRepository new
> directory:
> '/Applications/Pharo5.0-7.app/Contents/Resources/spf-gitlab/repository'
> asFileReference.
> {'RKA24-Model' . 'RKA24-System' . 'RKA24-Translator' .
> 'RKA24-View' .
> 'RKA24-Test' . 'RKA24-Report' . 'RKA24-Overwrites'}
> do: [ :each |
> Gofer it
> repository: gitRepository;
> package: each;
> load ].
>
> I would like to load it within my baseline like this below but I dont know
> what to write in the fileTreeRepository method...
>
> baseline: spec
> 
> spec
> for: #common
> do: [ spec blessing: #baseline.
> spec repository: ##self fileTreeRepository##.
> "here I load all the the oher stuff"
> spec
> package: 'RKA24-Model';
> package: 'RKA24-System';
> package: 'RKA24-Translator';
> package: 'RKA24-View';
> package: 'RKA24-Test';
> package: 'RKA24-Report';
> package: 'RKA24-Overwrites' ]
>
> 2) Also, when I take a new Image, I have to do several steps
>
> load gitfiletree from catalog
> add/open my gitfiletree repository from Monticello
> load BaselineOfRKA24 manually with
> (BaselineOfRKA24   project map at: 'baseline') load
>
> I think this is not the best way, I would like to make it right.
>
> Can anyone give me some hints how to improve this two steps?
> I use Pharo 5 and I don't want to go to Pharo 6 right now.
> I develop on mac and production server is on windows.
>
> Regards
> Sabine
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/2-
> questions-around-gitlab-gitfiletree-BaselineOf-tp4953877.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] ANTLR4 to SmaCC

[Thierry Goubier]

Hi Henrique,

Le 31/05/2017 à 17:03, Henrique Rocha a écrit :

Hello,

I was trying to convert a ANTLR4 grammar specification to SmaCC. After many
unsuccessful tries that made me question my sanity I wondered: maybe someone
has a solution. Grammar conversion is something that can be automated.


Sort of.

LL(*) brings itself to entirely different hacks to play with the tokens 
and lexical analysis that LR() grammars, and most of the hard work on 
parsers is in that area.


I haven't looked if the reversed recursion in ANTLR is hard to convert.

The use of the + * ? [ ] symbols is nice because it hides effectively on 
which side the recursion happens (left recursion in LR, right recursion 
in ANTLR)



My question is if anyone has done something to convert an ANTLR4 grammar to
a SmaCC grammar?


Write a ANTLRv4 grammar syntax grammar in SmaCC would do the trick.

Apart from semantic actions of course.

Regards,

Thierry


Thanks and farewell,

- Henrique



--
View this message in context: 
http://forum.world.st/ANTLR4-to-SmaCC-tp4948738.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] YAML parser (2017)

[Thierry Goubier]

Hi Peter,

If you have a BNF of YAML, then a SmaCC parser with AST generation is at
most a day of work. I can help.

Thierry

2017-05-29 9:15 GMT+02:00 Peter Uhnak :

> Hi,
>
> do we have a working parser for YAML?
>
> There's PPYAMLGrammar (in PetitParser), however it doesn't seem to work in
> Pharo 6 at all (not even tests pass).
> In Pharo 5 the tests are green, but using it on YAML content still
> fails... with small fix I managed it to "pass", however the output seems to
> be a very fine-grained AST decomposition and not the expected output
> (dictionaries/arrays).
>
> So do we have some else/working?
>
> YAML specs have BNF descriptions, so maybe SmaCC can generate it? (I don't
> know SmaCC, so maybe this is not how it works.)
>
> Thanks,
> Peter
>
>

Re: [Pharo-users] Moving Class to a Package programmaticaly

[Thierry Goubier]

2017-05-27 14:45 GMT+02:00 Denis Kudriashov :

>
> 2017-05-27 14:15 GMT+02:00 Thierry Goubier :
>
>> Will:
>>
>> #MyPackage asPackage definedClasses do: [:each | each tagWith: #MyPackage]
>>
>> put the classes in the #MyPackage or in the #MyPackage-MyPackage system
>> category?
>>
>
> #tagWith: not touches package of class. It only adds receiver into package
> tag.
> I not understand the question about system category because I don't know
> what it is exactly in current system.
>

The package and tag names are translated into a 'PackageName-TagName'
system category.

But: the tag #PackageName has a special meaning in RPackage (for now). It
means : what is defined in the package, and not in any other tag.


> Now in class definition we have "package: " part. And it will be modified
> with new tag-suffix. It will become "package: 'ActualPackageName-TagName'"
>

Just like it is now in system category then.


>
>
>>
>> Will that API stay the same when we will be able to put a class in
>> multiple categories (or a method in multiple protocols)?
>>
>
> Yes but #tagWith: will add extra tag into class/method. It will not remove
> existing tags.
> But in Pharo6 it is only new API. Multiple tags are not supported and
> #tagWith: removes existing tag.
>
> The problem I foresee is that at a certain point in the future, not
advertised, that semantic will change to not mean 'remove existing tag'.

If I start using that API, I'll need to add a test in my stuff that will
flag that API semantic change without name change.

Thierry

Re: [Pharo-users] Moving Class to a Package programmaticaly

[Thierry Goubier]

2017-05-27 13:58 GMT+02:00 Denis Kudriashov :

>
> 2017-05-26 19:22 GMT+02:00 Thierry Goubier :
>
>>
>> This should work:
>>
>> org := (RPackageOrganizer default packageNamed: 'MyPackage').
>> tag := org addClassTag: #Classes.
>> org definedClasses do: [ :aClass |
>> aClass category: tag categoryName   ].
>
>
> In Pharo 6 there is new tag API for classes:
>
> #MyPackage asPackage definedClasses do: [:each | each tagWith: #Classes]
>
>
Will:

#MyPackage asPackage definedClasses do: [:each | each tagWith: #MyPackage]

put the classes in the #MyPackage or in the #MyPackage-MyPackage system
category?

Will that API stay the same when we will be able to put a class in multiple
categories (or a method in multiple protocols)?

Regards,

Thierry