[Pharo-users] Re: [Esug-list] Re: [Pharo-dev] Re: [ANN] Soil release v1

[Dale Henrichs]

>
> But ground stone is just sand. There’s more than just sand in soil. Soil
> should have the other ingredients needed for growth. :)

I was trying to make a reference to a GemStone *stone *:)

Dale

On Wed, May 8, 2024 at 1:27 PM Norbert Hartl  wrote:

>
>
> Am 08.05.2024 um 16:14 schrieb Norbert Hartl :
>
> 
>
> Am 06.05.2024 um 16:47 schrieb Dirk Nel :
>
> I'll definitely check it out..! and for those who are not in the know...
> what inspired the name? :)
>
>
> - I like the word
> - It has only four letters which qualifies as a class prefix
> - To me as a non-native speaker it means: ground layer you can build/grow
> on
>
> - people having fun with it
>
> Mission accomplished
>
> N.
>
>
> Norbert
>
>
> On Wed, 24 Apr 2024 at 17:47, Tim Mackinnon  wrote:
>
>> That's really exciting news... appreciate you sharing it with the wider
>> community (I know when you mentioned its existence a while back I went and
>> watched the Esug recordings to get more info, and looked at some of the
>> extensive test cases to get a feel on what it looked like - its neat).
>>
>> Having multiple options for persisting data (from simple Fuel up to Soil
>> and Glorp and Gemstone) is very useful.
>>
>> Tim
>>
>> On Wed, 24 Apr 2024, at 12:52 PM, Norbert Hartl wrote:
>>
>> ...we said at last ESUG that there will be a release soonish but as usual
>> it doesn't go that fast.
>>
>> But now we are very happy to announce that Soil has a first public
>> release v1. So what is soil?
>>
>> Soil is an object oriented database in pharo . It is
>> transaction based having ACID transactions. It has binary search
>> capabilities with SkipList and BTree+ indexes. It aims to be a simple yet
>> powerful database making it easy to develop with, easy to debug with, easy
>> to inspect, ...
>>
>> More details at https://github.com/ApptiveGrid/Soil
>>
>> This release is still considered early stage because
>>
>>
>>- although in ApptiveGrid there are over 4000 instances of it and
>>there are other users there isn't a wider range of use cases, yet. So it 
>> is
>>not fully battle tested. This just as reminder when you start compaining I
>>need somewhere to point my finger to and say "I told you!" ;)
>>- there are few things missing that you might expect like garbage
>>collection, etc.
>>
>>
>> So but it is definetely usable and awaiting the brave ones of you to try.
>>
>> Hopy you enjoy it!
>>
>> Norbert & Marcus
>> ___
>> Esug-list mailing list -- esug-l...@lists.esug.org
>> To unsubscribe send an email to esug-list-le...@lists.esug.org
>>
>>
>> ___
>> Esug-list mailing list -- esug-l...@lists.esug.org
>> To unsubscribe send an email to esug-list-le...@lists.esug.org
>>
>
> ___
> Esug-list mailing list -- esug-l...@lists.esug.org
> To unsubscribe send an email to esug-list-le...@lists.esug.org
>
> ___
> Esug-list mailing list -- esug-l...@lists.esug.org
> To unsubscribe send an email to esug-list-le...@lists.esug.org
>

[Pharo-users] Re: [Esug-list] Re: [ANN] Soil release v1

[Dale Henrichs]

>
> To me as a non-native speaker it means: ground layer you can build/grow on


Haha, Soil can also be thought of as "ground up stone" :)

Dale

On Wed, May 8, 2024 at 7:13 AM Norbert Hartl  wrote:

>
>
> Am 06.05.2024 um 16:47 schrieb Dirk Nel :
>
> I'll definitely check it out..! and for those who are not in the know...
> what inspired the name? :)
>
>
> - I like the word
> - It has only four letters which qualifies as a class prefix
> - To me as a non-native speaker it means: ground layer you can build/grow
> on
>
> Norbert
>
>
> On Wed, 24 Apr 2024 at 17:47, Tim Mackinnon  wrote:
>
>> That's really exciting news... appreciate you sharing it with the wider
>> community (I know when you mentioned its existence a while back I went and
>> watched the Esug recordings to get more info, and looked at some of the
>> extensive test cases to get a feel on what it looked like - its neat).
>>
>> Having multiple options for persisting data (from simple Fuel up to Soil
>> and Glorp and Gemstone) is very useful.
>>
>> Tim
>>
>> On Wed, 24 Apr 2024, at 12:52 PM, Norbert Hartl wrote:
>>
>> ...we said at last ESUG that there will be a release soonish but as usual
>> it doesn't go that fast.
>>
>> But now we are very happy to announce that Soil has a first public
>> release v1. So what is soil?
>>
>> Soil is an object oriented database in pharo . It is
>> transaction based having ACID transactions. It has binary search
>> capabilities with SkipList and BTree+ indexes. It aims to be a simple yet
>> powerful database making it easy to develop with, easy to debug with, easy
>> to inspect, ...
>>
>> More details at https://github.com/ApptiveGrid/Soil
>>
>> This release is still considered early stage because
>>
>>
>>- although in ApptiveGrid there are over 4000 instances of it and
>>there are other users there isn't a wider range of use cases, yet. So it 
>> is
>>not fully battle tested. This just as reminder when you start compaining I
>>need somewhere to point my finger to and say "I told you!" ;)
>>- there are few things missing that you might expect like garbage
>>collection, etc.
>>
>>
>> So but it is definetely usable and awaiting the brave ones of you to try.
>>
>> Hopy you enjoy it!
>>
>> Norbert & Marcus
>> ___
>> Esug-list mailing list -- esug-l...@lists.esug.org
>> To unsubscribe send an email to esug-list-le...@lists.esug.org
>>
>>
>> ___
>> Esug-list mailing list -- esug-l...@lists.esug.org
>> To unsubscribe send an email to esug-list-le...@lists.esug.org
>>
>
> ___
> Esug-list mailing list -- esug-l...@lists.esug.org
> To unsubscribe send an email to esug-list-le...@lists.esug.org
>

[Pharo-users] Re: [Pharo-dev] Re: Omnibase/Monibase repository removal

[Dale Henrichs]

Here’s Kurt’s talk from Camp Smalltalk Supreme[1].

Dale

[1] https://www.youtube.com/watch?v=uLF2S6fq5a4

Sent from my iPhone

> On Aug 9, 2022, at 6:53 AM, Dale Henrichs  
> wrote:
> 
> Norbert,
> 
> I won’t be going to ESUG this year … travel to Europe has always been tough 
> for me and at my age ‍靈I want to limit my exposure to COVID… Perhaps next 
> year爛.
> 
> Dale
> 
> Sent from my iPhone
> 
>>> On Aug 9, 2022, at 3:21 AM, Norbert Hartl  wrote:
>>> 
>> Hi Dale,
>> 
>> thanks for the pointer.  I always admired what the GemStone people did and 
>> do. But I'm looking for something more lightweight and more easy to handle 
>> approach this time. Well, from the github page I could not derive what it 
>> really does to be honest.
>> 
>> Hope to see you at ESUG,
>> 
>> Norbert
>> 
>>> Am 08.08.2022 um 18:44 schrieb Dale Henrichs 
>>> :
>>> 
>>> Norbert,
>>> Before you go off and invent a data base, you might take a look at GemStone 
>>> and RemoteServiceReplication[1] ...
>>> 
>>> Dale
>>> 
>>> [1] https://github.com/GemTalk/RemoteServiceReplication
>>> 
>>>> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  wrote:
>>>> To all Omnibase and Monibase users. 
>>>> 
>>>> It turned out that neither of those are open source. The author of the 
>>>> database contacted me clarifying the situation that he has the copyright 
>>>> and never released something open source. This means that I will remove 
>>>> the Omnibase repositories in few weeks from 
>>>> 
>>>> https://github.com/ApptiveGrid/MoniBase
>>>> 
>>>> and 
>>>> 
>>>> https://github.com/pharo-nosql/OmniBase
>>>> 
>>>> I'm very sorry about that but someone just took the code 9 years before, 
>>>> copied it on github and put illegally an MIT license to the repository. We 
>>>> only want free software in our repositories and hence the above will go 
>>>> away.
>>>> 
>>>> As we see it essential to have a good OO database in pharo we will see how 
>>>> much effort it will be build a small and simple OO database that can 
>>>> replace Omnibase. 
>>>> 
>>>> regards,
>>>> 
>>>> Norbert
>> 

[Pharo-users] Re: [Pharo-dev] Re: Omnibase/Monibase repository removal

[Dale Henrichs]

Norbert,

I won’t be going to ESUG this year … travel to Europe has always been tough for 
me and at my age ‍靈I want to limit my exposure to COVID… Perhaps next year爛.

Dale

Sent from my iPhone

> On Aug 9, 2022, at 3:21 AM, Norbert Hartl  wrote:
> 
> Hi Dale,
> 
> thanks for the pointer.  I always admired what the GemStone people did and 
> do. But I'm looking for something more lightweight and more easy to handle 
> approach this time. Well, from the github page I could not derive what it 
> really does to be honest.
> 
> Hope to see you at ESUG,
> 
> Norbert
> 
>> Am 08.08.2022 um 18:44 schrieb Dale Henrichs 
>> :
>> 
>> Norbert,
>> Before you go off and invent a data base, you might take a look at GemStone 
>> and RemoteServiceReplication[1] ...
>> 
>> Dale
>> 
>> [1] https://github.com/GemTalk/RemoteServiceReplication
>> 
>> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  wrote:
>>> To all Omnibase and Monibase users. 
>>> 
>>> It turned out that neither of those are open source. The author of the 
>>> database contacted me clarifying the situation that he has the copyright 
>>> and never released something open source. This means that I will remove the 
>>> Omnibase repositories in few weeks from 
>>> 
>>> https://github.com/ApptiveGrid/MoniBase
>>> 
>>> and 
>>> 
>>> https://github.com/pharo-nosql/OmniBase
>>> 
>>> I'm very sorry about that but someone just took the code 9 years before, 
>>> copied it on github and put illegally an MIT license to the repository. We 
>>> only want free software in our repositories and hence the above will go 
>>> away.
>>> 
>>> As we see it essential to have a good OO database in pharo we will see how 
>>> much effort it will be build a small and simple OO database that can 
>>> replace Omnibase. 
>>> 
>>> regards,
>>> 
>>> Norbert
> 

[Pharo-users] Re: [Pharo-dev] Re: Omnibase/Monibase repository removal

[Dale Henrichs]

Norbert,

Ooops you are right! 

RSR is an object replication framework that replicates objects between Pharo, 
Dolphin, and GemStone images. Kurt Kilpela will be giving a talk at ESUG this 
year so if you are going to ESUG you can get more details right from the 
horse’s s mouth:)

Dale

[1] 
https://downloads.gemtalksystems.com/docs/GemStone64/3.6.x/GS64-GemBuilderforC-3.6.pdf
Sent from my iPhone

> On Aug 9, 2022, at 3:21 AM, Norbert Hartl  wrote:
> 
> Hi Dale,
> 
> thanks for the pointer.  I always admired what the GemStone people did and 
> do. But I'm looking for something more lightweight and more easy to handle 
> approach this time. Well, from the github page I could not derive what it 
> really does to be honest.
> 
> Hope to see you at ESUG,
> 
> Norbert
> 
>> Am 08.08.2022 um 18:44 schrieb Dale Henrichs 
>> :
>> 
>> Norbert,
>> Before you go off and invent a data base, you might take a look at GemStone 
>> and RemoteServiceReplication[1] ...
>> 
>> Dale
>> 
>> [1] https://github.com/GemTalk/RemoteServiceReplication
>> 
>> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  wrote:
>>> To all Omnibase and Monibase users. 
>>> 
>>> It turned out that neither of those are open source. The author of the 
>>> database contacted me clarifying the situation that he has the copyright 
>>> and never released something open source. This means that I will remove the 
>>> Omnibase repositories in few weeks from 
>>> 
>>> https://github.com/ApptiveGrid/MoniBase
>>> 
>>> and 
>>> 
>>> https://github.com/pharo-nosql/OmniBase
>>> 
>>> I'm very sorry about that but someone just took the code 9 years before, 
>>> copied it on github and put illegally an MIT license to the repository. We 
>>> only want free software in our repositories and hence the above will go 
>>> away.
>>> 
>>> As we see it essential to have a good OO database in pharo we will see how 
>>> much effort it will be build a small and simple OO database that can 
>>> replace Omnibase. 
>>> 
>>> regards,
>>> 
>>> Norbert
> 

[Pharo-users] Re: [Pharo-dev] Omnibase/Monibase repository removal

[Dale Henrichs]

Sorry to have interrupted ... I just remember that folks have moved from
OmniBase to GemStone in the past for "performance reasons" and understand
that those aren't the only reasons for having an OmniBase replacement ...

Dale

On Mon, Aug 8, 2022 at 10:22 AM Yanni Chiu  wrote:

> Dale,
>
> It’s not about inventing a “database”, it’s a requirement to persist data
> beyond image start/stop, along with intangibles like having the full source
> code to tune for individual requirements. In my case the top (desired)
> requirements are single directory or file per user (scaling), and no
> additional server process(es) to be monitored for failure mode.
>
> Yanni
>
> On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>> Norbert,
>> Before you go off and invent a data base, you might take a look at
>> GemStone and RemoteServiceReplication[1] ...
>>
>> Dale
>>
>> [1] https://github.com/GemTalk/RemoteServiceReplication
>>
>> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  wrote:
>>
>>> To all Omnibase and Monibase users.
>>>
>>> It turned out that neither of those are open source. The author of the
>>> database contacted me clarifying the situation that he has the copyright
>>> and never released something open source. This means that I will remove the
>>> Omnibase repositories in few weeks from
>>>
>>> https://github.com/ApptiveGrid/MoniBase
>>>
>>> and
>>>
>>> https://github.com/pharo-nosql/OmniBase
>>>
>>> I'm very sorry about that but someone just took the code 9 years before,
>>> copied it on github and put illegally an MIT license to the repository. We
>>> only want free software in our repositories and hence the above will go
>>> away.
>>>
>>> As we see it essential to have a good OO database in pharo we will see
>>> how much effort it will be build a small and simple OO database that can
>>> replace Omnibase.
>>>
>>> regards,
>>>
>>> Norbert
>>>
>>

[Pharo-users] Re: [Pharo-dev] Omnibase/Monibase repository removal

[Dale Henrichs]

Norbert,
Before you go off and invent a data base, you might take a look at GemStone
and RemoteServiceReplication[1] ...

Dale

[1] https://github.com/GemTalk/RemoteServiceReplication

On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  wrote:

> To all Omnibase and Monibase users.
>
> It turned out that neither of those are open source. The author of the
> database contacted me clarifying the situation that he has the copyright
> and never released something open source. This means that I will remove the
> Omnibase repositories in few weeks from
>
> https://github.com/ApptiveGrid/MoniBase
>
> and
>
> https://github.com/pharo-nosql/OmniBase
>
> I'm very sorry about that but someone just took the code 9 years before,
> copied it on github and put illegally an MIT license to the repository. We
> only want free software in our repositories and hence the above will go
> away.
>
> As we see it essential to have a good OO database in pharo we will see how
> much effort it will be build a small and simple OO database that can
> replace Omnibase.
>
> regards,
>
> Norbert
>

[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Dale Henrichs]

Emilio,

Okay ... we're peeling the onion :) ...

At this point it sounds like you need to do a flushCache on your filetree
repository in order to force Metacello to re-download from the github into
the local package-cache.

But if Iceberg is involved, I am not the person to ask ... I am not
familiar with the changes that have been made to Metacello to get it to
work with Iceberg ...

Dale



On Fri, Apr 29, 2022 at 3:16 PM Emilio Oca  wrote:

> Hi Dale
>
> Thanks again, still not working.
> After updating github I am unable to pull the changes into the image.
> So far the only way is to hit Pull button at the "Working copy of
> MyProyect" repo window.
> I wish I could reproduce what that button does.
>
> Even this:
> Metacello new
> repository: 'github://...';
> baseline: 'MyProyect';
> get
> does not update my file system at iceberg/
>
> Best
>
> Emilio
>
> On Thu, Apr 28, 2022 at 3:29 PM Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>> Emilio,
>>
>> I wasn't quite sure whether or not you were concerned about having the
>> BaselineOf refreshed or a reload of the packages managed by the BaselineOf
>> and as Gabriel mentions, the missing #projectClass method is the most
>> common problem ...
>>
>> By default Metacello does not refresh a BaselieOf in your image if it is
>> already present, however, you can force a refresh of a BaselineOf by using
>> the the Metcello #get command:
>>
>>> Metacello new baseline:'MyProject';
>>>   repository: 'github://myUser/MyProject:main/myProject';
>>>   get;
>>>   load.
>>
>> This would be a good pattern to follow when reloading projects after
>> updating from github ... and I am a bit surprised that this question is not
>> asked more often :)
>>
>> Dale
>>
>> On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca  wrote:
>>
>>> Hi Gabriel, Dale!
>>>
>>> My BaselineOf had only #baseline:
>>> Added #projectClass
>>> But is still not working.
>>> It seems to be doing the load, but not the pull before the load.
>>>
>>> I had implemented no more than #baseLine: and now projectClass.
>>>
>>> If I go through the UI and do the pull it works perfectly.
>>> Can I replicate that with a script?
>>>
>>> Best
>>>
>>> Emilio
>>>
>>> On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs <
>>> dale.henri...@gemtalksystems.com> wrote:
>>>
>>>> Emilio,
>>>>
>>>> Are you using a repository without Monticello meta data? If so, then
>>>> you need to change the #projectClass of you your baseline to:
>>>>
>>>>> projectClass
>>>>>   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl |
>>>>> ^ cl ].
>>>>>   ^ super projectClass
>>>>
>>>>
>>>> unless the #projectClass is MetacelloCypressBaselineProject, Metacello
>>>> will think that your package versions are 'cypress.1' and Metacello will
>>>> not load packages with the same version  when the #projectClass is
>>>> MetacelloCypressBaselineProject, Metacello will always load the package and
>>>> let Monticello filter out the changes ...
>>>>
>>>> Dale
>>>>
>>>> On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano 
>>>> wrote:
>>>>
>>>>> mmm, you may be having another problem elsewhere, because what I typed
>>>>> should be working (is how we enforce the load of new versions to run the
>>>>> tests, for example).
>>>>>
>>>>> Esteban
>>>>>
>>>>> On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:
>>>>>
>>>>> Hi Esteban
>>>>>
>>>>> Thanks for the hint.
>>>>> It is still not working.
>>>>> Even if I remove BaselineOfMyProject and MyProject.
>>>>> When it reloads, it doesn't loads the last version of head at github
>>>>> but the one that was already at the image.
>>>>>
>>>>> I just want to update up to what is at gibhub head. Is there another
>>>>> way?
>>>>>
>>>>> Best
>>>>>
>>>>> Emilio
>>>>>
>>>>> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
>>>>> wrote:
>>>>>
>>>>> Hi Emilio,
>>>>>
>>>>> You need something l

[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Dale Henrichs]

Emilio,

I wasn't quite sure whether or not you were concerned about having the
BaselineOf refreshed or a reload of the packages managed by the BaselineOf
and as Gabriel mentions, the missing #projectClass method is the most
common problem ...

By default Metacello does not refresh a BaselieOf in your image if it is
already present, however, you can force a refresh of a BaselineOf by using
the the Metcello #get command:

> Metacello new baseline:'MyProject';
>   repository: 'github://myUser/MyProject:main/myProject';
>   get;
>   load.

This would be a good pattern to follow when reloading projects after
updating from github ... and I am a bit surprised that this question is not
asked more often :)

Dale

On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca  wrote:

> Hi Gabriel, Dale!
>
> My BaselineOf had only #baseline:
> Added #projectClass
> But is still not working.
> It seems to be doing the load, but not the pull before the load.
>
> I had implemented no more than #baseLine: and now projectClass.
>
> If I go through the UI and do the pull it works perfectly.
> Can I replicate that with a script?
>
> Best
>
> Emilio
>
> On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>> Emilio,
>>
>> Are you using a repository without Monticello meta data? If so, then you
>> need to change the #projectClass of you your baseline to:
>>
>>> projectClass
>>>   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^
>>> cl ].
>>>   ^ super projectClass
>>
>>
>> unless the #projectClass is MetacelloCypressBaselineProject, Metacello
>> will think that your package versions are 'cypress.1' and Metacello will
>> not load packages with the same version  when the #projectClass is
>> MetacelloCypressBaselineProject, Metacello will always load the package and
>> let Monticello filter out the changes ...
>>
>> Dale
>>
>> On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano 
>> wrote:
>>
>>> mmm, you may be having another problem elsewhere, because what I typed
>>> should be working (is how we enforce the load of new versions to run the
>>> tests, for example).
>>>
>>> Esteban
>>>
>>> On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:
>>>
>>> Hi Esteban
>>>
>>> Thanks for the hint.
>>> It is still not working.
>>> Even if I remove BaselineOfMyProject and MyProject.
>>> When it reloads, it doesn't loads the last version of head at github but
>>> the one that was already at the image.
>>>
>>> I just want to update up to what is at gibhub head. Is there another way?
>>>
>>> Best
>>>
>>> Emilio
>>>
>>> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
>>> wrote:
>>>
>>> Hi Emilio,
>>>
>>> You need something like this:
>>>
>>>   Metacello new
>>> repository: 'github://pharo-spec/Spec:Pharo10';
>>> baseline: 'Spec2';
>>> onConflict: [ :e | e useIncoming ];
>>> onUpgrade: [ :e | e useIncoming ];
>>> ignoreImage;
>>> load
>>>
>>> ignoreImage, onConflict, onUpgrade.
>>>
>>> BUT if your image already has a baseline for your project then Metacello
>>> will not reload it (hence your project may not be loaded correctly, since
>>> baseline may have changed).
>>>
>>> In that case, I always execute before something like:
>>>
>>> #( 'BaselineOfSpec2' 'BaselineOfSpecCore' ) do: [ :each |
>>> (RPackageOrganizer default packageNamed: each ifAbsent: [ nil ])
>>> ifNotNil: [ :aPackage | aPackage removeFromSystem ] ]
>>>
>>>
>>> I ack this is hacky, but it works :)
>>>
>>> Esteban
>>>
>>> On Apr 23 2022, at 3:21 am, Emilio Oca  wrote:
>>>
>>> Hi List
>>>
>>> I need some help with Metacello, and may be git too
>>>
>>> I would like to be able to, in a running headless image, load the last
>>> commit of a git repo
>>>
>>> Something like
>>> Metacello new baseline:'MyProject';
>>> repository: 'github://myUser/MyProject:main/myProject';
>>> load.
>>> works just once and may open some dialogs
>>>
>>> Something like this
>>> [
>>> [
>>> Metacello new baseline:'MyProject';
>>> repository: 'github://myUser/MyProject:main/myProject';
>>> onConflictUseIncoming;
>>> load.
>>> ] on: MetacelloSkipDirtyPackageLoad do: [ :ex | ex resume: false ].
>>> ] on: MCMergeOrLoadWarning do: [ :ex | ex load ].
>>> Avoids the dialogs and alerts but the code is still not updated.
>>>
>>> My intention is to be able to 'refresh' a running seaside image with its
>>> latest development version from a git repo (avoiding to personally reach
>>> the server and rebuild the docker image)
>>> What am I missing?
>>>
>>> Best
>>>
>>> Emilio
>>>
>>>

[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Dale Henrichs]

Emilio,

Are you using a repository without Monticello meta data? If so, then you
need to change the #projectClass of you your baseline to:

> projectClass
>   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^ cl
> ].
>   ^ super projectClass


unless the #projectClass is MetacelloCypressBaselineProject, Metacello will
think that your package versions are 'cypress.1' and Metacello will not
load packages with the same version  when the #projectClass is
MetacelloCypressBaselineProject, Metacello will always load the package and
let Monticello filter out the changes ...

Dale

On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano  wrote:

> mmm, you may be having another problem elsewhere, because what I typed
> should be working (is how we enforce the load of new versions to run the
> tests, for example).
>
> Esteban
>
> On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:
>
> Hi Esteban
>
> Thanks for the hint.
> It is still not working.
> Even if I remove BaselineOfMyProject and MyProject.
> When it reloads, it doesn't loads the last version of head at github but
> the one that was already at the image.
>
> I just want to update up to what is at gibhub head. Is there another way?
>
> Best
>
> Emilio
>
> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
> wrote:
>
> Hi Emilio,
>
> You need something like this:
>
>   Metacello new
> repository: 'github://pharo-spec/Spec:Pharo10';
> baseline: 'Spec2';
> onConflict: [ :e | e useIncoming ];
> onUpgrade: [ :e | e useIncoming ];
> ignoreImage;
> load
>
> ignoreImage, onConflict, onUpgrade.
>
> BUT if your image already has a baseline for your project then Metacello
> will not reload it (hence your project may not be loaded correctly, since
> baseline may have changed).
>
> In that case, I always execute before something like:
>
> #( 'BaselineOfSpec2' 'BaselineOfSpecCore' ) do: [ :each |
>   (RPackageOrganizer default packageNamed: each ifAbsent: [ nil ])
>   ifNotNil: [ :aPackage | aPackage removeFromSystem ] ]
>
>
> I ack this is hacky, but it works :)
>
> Esteban
>
> On Apr 23 2022, at 3:21 am, Emilio Oca  wrote:
>
> Hi List
>
> I need some help with Metacello, and may be git too
>
> I would like to be able to, in a running headless image, load the last
> commit of a git repo
>
> Something like
> Metacello new baseline:'MyProject';
> repository: 'github://myUser/MyProject:main/myProject';
> load.
> works just once and may open some dialogs
>
> Something like this
> [
> [
> Metacello new baseline:'MyProject';
> repository: 'github://myUser/MyProject:main/myProject';
> onConflictUseIncoming;
> load.
> ] on: MetacelloSkipDirtyPackageLoad do: [ :ex | ex resume: false ].
> ] on: MCMergeOrLoadWarning do: [ :ex | ex load ].
> Avoids the dialogs and alerts but the code is still not updated.
>
> My intention is to be able to 'refresh' a running seaside image with its
> latest development version from a git repo (avoiding to personally reach
> the server and rebuild the docker image)
> What am I missing?
>
> Best
>
> Emilio
>
>

Re: [Pharo-users] Checking baseline before publishing

[Dale Henrichs]

Esteban,

#record _is_ run against the baseline that is in the image if it is 
present. This is true for all of the Metacello commands - if the 
BaselineOf is present it is used, if it is not present it will be 
loaded. The #get command will load a fresh copy of the baseline from the 
repository.


There is an option to ignore image state (#ignoreImage) when running 
#record (or any other command) to simulate loading into an "empty" image 
... depending upon the volume of output, you could read the report to 
determine if the packages/projects that you are expecting to see are 
being loaded and of course if your goal is to expose outright errors 
#record should do that as well ...


Dale

On 8/28/20 10:59 AM, Esteban Maringolo wrote:

Hi Jonathan,

I never thought of SmalltalkCI for that (I use Gitlab) but in essence
it still requires a trial and error approach (of committing the
Baseline and loading it afterwards to see if it works).

Metacello has a "record" operation that basically does a dry run of
the load, but I don't know if there is a way to do it using the
Baseline in the image instead of one in a repository.

Regards!

Esteban A. Maringolo

On Fri, Aug 28, 2020 at 10:10 AM Jonathan van Alteren
 wrote:

Hi Esteban,

You might want to give smalltalkCI a try: https://github.com/hpi-swa/smalltalkCI

I've recently started using it myself, with GitLab CI and GitHub Actions, but 
one of the cool things is that you can use it to test your build locally.

For example, create a .smalltalk.ston file for your project which loads the 
baseline that you want to test, like this:

SmalltalkCISpec {
   #loading : [
 SCIMetacelloLoadSpec {
   #baseline : 'MyProject',
   #directory : 'source',
   #load : [ 'default' ],
   #onWarningLog : true,
   #platforms : [ #pharo ]
 }
   ],
   #testing : {
 #categories : [ 'MyProject-Tests' ]
   }
}

Then clone the smalltalkCI repo locally and open a terminal on its location, 
for example /Users/johndoe/git/smalltalkCI. You can then simply use smalltalkCI 
to build a Pharo image of your baseline, which effectively tests the correct 
working of your baseline:

bin/smalltalkci -s "Pharo64-8.0" /Users/johndoe/git/MyProject/.smalltalk.ston

By default, it will run all tests in the image, but you can change the list of 
tests being run by modifying the .smalltalk.ston file accordingly (see 
https://github.com/hpi-swa/smalltalkCI#testcase-selection).

Hope this helps!

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

jvalte...@objectguild.com
On 27 Aug 2020, 04:12 +0200, Esteban Maringolo , wrote:

Hi,

How can I check that my baseline works without having to publish
everything, check that it fails and then going to the origin, fixing,
etc?

I might be particularly idiot to always miss something, I usually have
to try at least four times (in a blank image) that my Baseline,
dependencies, etc. works as expected.

There must be some other way.

Esteban A. Maringolo

Re: [Pharo-users] smalltalkhub down

[Dale Henrichs]

... and it is still down today ... having smalltalkhub down is starting 
to interfere with builds, hopefully we won't have to wait too long for 
the problem to be resolved ...


Dale

On 7/10/20 2:59 PM, PAUL DEBRUICKER wrote:

https://downforeveryoneorjustme.com/smalltalkhub.com

Re: [Pharo-users] Resources Page

[Dale Henrichs]

I think the free license is contingent upon having contributed to an 
open source project. Also there appears to be free trial version[1].


Dale

[1] https://www.instantiations.com/products/vasmalltalk/download.html

On 1/28/20 5:25 PM, Richard Sargent wrote:

Thanks.

On Tue, Jan 28, 2020, 17:21 horrido > wrote:


Done. I didn't realize there was a free license for GemStone/S.

Too bad VA Smalltalk doesn't offer a free license.


I believe they do.





Richard Sargent (again) wrote
> Thank you, Richard.
>
> Would you be kind enough to annotate the GemStone link to point
out that
> we have a free license that permits commercial use, not only
personal use.
>
> Thanks again for all your hard work!
>
>
> On January 28, 2020 2:24:16 PM PST, Richard Kenneth Eng 

> horrido.hobbies@

>  wrote:
>>I've added a Resources page to my new blog:
>>https://smalltalk.tech.blog/resources/.
>>
>>It is very much a *curated *list. I felt this was needed because
when I
>>visit other Smalltalk resources pages, I get overwhelmed by the
number
>>of
>>links and options. It is possible to have *too many* choices.
>>
>>Moreover, many of those links are either broken, or they point to
>>obscure
>>materials that people may not be interested in.
>>
>>As curator, it is my job to present those links that I believe
will be
>>useful. Of course, this is necessarily very subjective.
>>
>>Also, it is likely that I've overlooked some links that others
feel are
>>useful. However, I am open-minded. If there are Smalltalk links that
>>you
>>believe I should consider, please let me know.





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

Re: [Pharo-users] Old projects in ss3

[Dale Henrichs]

Thanks Carlo ... that will certainly help me solve this problem ... I 
probably won't be able to get ss3 patched until after ESUG :), but now I 
know where to look ...


Dale

On 8/10/19 3:20 PM, sk via Pharo-users wrote:

Hi Dale

Looks like a NumberParser error due to the chrome Accept request 
header including "v=b3".


Chrome sends something like: "
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3"
which seems to break on SS3.
You could try wget and receive the same error: wget --header="Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3" 
 "http://ss3.gemtalksystems.com/ss/GTDImplementation;

If you remove v=b3 or modify it to by v=3 then there is no error.

Somewhat related bug report for a different project: 
https://github.com/emicklei/go-restful/issues/400


Carlo

Re: [Pharo-users] Can I control the location of the PharoDebug.log

[Dale Henrichs]

On 8/7/19 11:32 AM, Torsten Bergmann wrote:

Dale wrote:

I used the double click trick on "Log file name" and followed it to the above 
messages

for the records:

Beside double click you can also right click on a setting and select "Browse" 
to find
where it is implemented. You can then also "Save" the current settings.

The settings framework is described here: 
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Settings.pdf

Bye
T.


Thanks for the additional information Torsten ... now that you point out 
the Browse menu, I see that it and double click do the same thing:


Back when I was looking for help with the my weird local directory 
problem and remembered the "double click trick", I interpreted the 
'browse` menu item to be mean 'browse the local directory' not 'browse 
the code the code that implements the settings' ... my bad:)


Dale

Dale

Re: [Pharo-users] Can I control the location of the PharoDebug.log

[Dale Henrichs]

I've finally been able to answer my own question. Execute the following 
and no more PharoDebug.log and no more stack dump to stdout/stderr (I'm 
not exactly sure which debugger is being used, so I set both for good luck):


    DebugSession logDebuggerStackToFile: false.
    GTGenericStackDebugger logDebuggerStackToFile: false.

While writing this message I found that there does appear to be a 
setting that controls this (I used the double click trick on "Log file 
name" and followed it to the above messages), but I haven't actually 
tested it:):


On 7/31/19 4:58 PM, Dale Henrichs wrote:
It appears that the PharoDebug.log can be dropped into the directory 
from which a Pharo image is launched ... I would have expected it to 
be dropped into the local directory, but that does not appear to be 
the case ...


I've looked in the Settings Browser and there does not appear to be a 
way to influence the location of the PharoDebug.log.


I am currently using the `st` command line handler if that is important.

I've googled for PharoDebug.log to no avail.

Any help will be appreciated,

Dale

Re: [Pharo-users] more fun with System>>Local directory settings

[Dale Henrichs]

Thanks for the sample code! ... I keep forgetting that a scan of 
allInstances is a good way to patch problems like these:) and the fixed 
to relative path snippet is especially useful.


Dale

On 8/1/19 1:50 PM, Sean P. DeNigris wrote:

Dale Henrichs-3 wrote

the act of starting the image automagically populates the System >> local
directory with a full path to a directory in my current directory

This sounds like the same problem I've been having with absolute resolved
paths to local iceberg repos. Here is the script I use to fix them in a way
that survives image moving and renaming. It should be easy to adapt for your
needs. Obviously it would be better if Pharo didn't resolve the paths in
these cases, but at least there is a workaround.

fixIcebergRepoLocations
"E.g. after an image is moved or renamed, its local Iceberg repos become
broken because the locations are stored as static FileReferences instead of
dynamic FileLocations following the image around. Limitation: assumes all
images are stored in flat folders under root"

| imageRoot repos |
imageRoot := FileLocator home / 'Dynabook' / 'Working Images'.
repos := IceLibgitRepository allSubInstances
select: [ :e |
e location isNotNil
and: [ (FileLocator imageDirectory contains: e 
location) not
and: [ imageRoot contains: e 
location ] ] ].
repos
do: [ :e |
| oldPath newPath fixedLocation |
oldPath := e location relativeTo: imageRoot.
newPath := RelativePath withAll: oldPath segments 
allButFirst.
fixedLocation := FileLocator imageDirectory withPath: 
newPath.
e location: fixedLocation ]



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

[Pharo-users] Can I control the location of the PharoDebug.log

[Dale Henrichs]

It appears that the PharoDebug.log can be dropped into the directory 
from which a Pharo image is launched ... I would have expected it to be 
dropped into the local directory, but that does not appear to be the 
case ...


I've looked in the Settings Browser and there does not appear to be a 
way to influence the location of the PharoDebug.log.


I am currently using the `st` command line handler if that is important.

I've googled for PharoDebug.log to no avail.

Any help will be appreciated,

Dale

Re: [Pharo-users] where are system settings stored?

[Dale Henrichs]

On 7/22/19 10:30 AM, Cyril Ferlicot wrote:

FileLocator preferences asFileReference



Thanks Cyril ... I get `File @ /home/dhenrich/.config` and there is a 
pharo directory with some stuff in it ... poking around it seems that 
the system settings are in a pharo/7.0 subdirectory with a 
system-settings.ston file, that when catted looks like the following:


which is of course due to the fact that the file is using CR instead of 
LF ...


After replacing CR's with LF's, there are a bunch of places where 
gci_70_tst show up in the system-settings.ston file and each of those 
places is an absolute path ... which seems to indicate that I will have 
to be creative when trying to share an image file with different users 
to run as a pre-built application ...


Thanks again, Cyril ... This is the pointer that I needed ... I had no 
clue that pharo was stashing stuff in .config and that I was using a 
local-cache directory that was magically created over 6 months ago:)


I will start pulling on this thread and see where it takes me:)

Dale

[Pharo-users] where are system settings stored?

[Dale Henrichs]

I am currently using Pharo 7.0 and I've just discovered that my "local 
directory" is 
/home/dhenrich/rogue/_homes/rogue/_home/dev/clients/gci_70_tst/pharo-local:



This file has to date back to the beginning of the year and i had 
deleted that directory structure a week or so ago before starting on my 
(totally unrelated work) and didn't discover the problem until i tried 
to run an image created locally up on traivs[1], where this bug[2] 
manifested itself and I eventually tracked the source of problem to the 
"local directory" setting ...


Now I would like to know where the pharo settings file is hiding, so 
that I can avoid running into this problem in the future ... ...


I've poked around in the Settings Browser looking for the default 
location of the settings file. There's "Store Settings" and "Load 
Settings", but nothing that allows me to find out/control the location 
of the settings file itself ...


... I only got to this point by tracing back from allinstances of 
OmSessionStore to a class var where the "directory" was stored and then 
got the settings browser by looking at senders ... but now I've run out 
of ideas.


I assume that this is common knowledge, but not quite common enough for me:)

Thanks in advance for the help.

Dale


[1] https://travis-ci.org/dalehenrich/st_launcher/builds/561863077#L603
[2] https://github.com/pharo-project/pharo-launcher/issues/37

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

[Dale Henrichs]

SETT was create based on our understanding (GemTalk Systems) of what the 
tonel disk format was _supposed_ to be and I think that Pharo has 
departed from somewhat from what was understood to be the format.


I've had similar problems trying to use filetree repositories with 
Iceberg that have been readable by the old Monticello/Filetree readers 
for years [1] ... and are readable when loaded through the Monticello 
Browser, but not readable when using Iceberg ...


One of these days, there needs to be agreement as to what the actual 
disk format of tonel and filetree repositories is going to be/has been 
and then stick to them, otherwise these problems are going to continue 
to plague us.


Dale

[1] https://github.com/pharo-vcs/iceberg/issues/1239

On 6/18/19 6:40 AM, Esteban Maringolo wrote:

Hi Guillermo,

Your workaround effectively solved my issue.

About the tonel format, in the .properties file at the sources 
directory there was such setting:
https://github.com/eMaringolo/rbac/blob/9279f22ef5fd1c4149090b5b39a6afa143a6519c/sources/properties.st 



But the .project file was missing at the root of the repository. So 
maybe it is a mix of both conditions.


In any case, I'm glad the workaround works, and that it helped 
spotting a bug.


Thank you!


Esteban A. Maringolo


On Tue, Jun 18, 2019 at 4:35 AM Guillermo Polito 
mailto:guillermopol...@gmail.com>> wrote:


I’ve created an issue:

https://github.com/pharo-vcs/iceberg/issues/1251


El 18 jun 2019, a las 9:30, Guillermo Polito
mailto:guillermopol...@gmail.com>>
escribió:

Hi Esteban,

It seems like a bug in Iceberg. If you click on debug, you’ll see
that although you’ve said the project is in tonel format, it’s
trying to use a Filetree reader



This is due to some missing metadata in the commit (iceberg is
relying on commit information there and not working copy
information).

There is however a simple workaround. If you click in the commit
button you’ll see that Iceberg tries to create and commit the
missing files:



If you commit those files, then you’ll be able to load your packages.

Guille



El 18 jun 2019, a las 2:34, Esteban Maringolo
mailto:emaring...@gmail.com>> escribió:

Hi,

I'm trying to load a package from a Tonel repository[1] that was
created using SETT[2].

The structure seems fine, but when I try to load a package, I'm
getting the message saying that there is no version for the
package in the current commit (which seems wrong at least to the
naked eye).

Eg.


Any idea of how to fix it?

Regards!

[1] https://github.com/eMaringolo/rbac/tree/master/sources/
[2] https://github.com/gemtalk/sett



Esteban A. Maringolo

Re: [Pharo-users] [gemstones] Use case for GsDevKit_home

[Dale Henrichs]

On 5/30/19 11:12 AM, sergio ruiz wrote:

Whew… hefty.. digging into this now..
Haha ... this is why backup and restore functionality has been built 
into tODE:) and GsDevKit_home ...


Dale

Re: [Pharo-users] [gemstones] Use case for GsDevKit_home

[Dale Henrichs]

On 5/30/19 6:58 AM, James Foster wrote:


On May 30, 2019, at 5:44 AM, sergio ruiz > wrote:


...

Also, one thing that I find invaluable in troubleshooting 
applications written using relational databases is to be able to be 
able to just dump the production database and load it up on my local 
machine. Is this possible using gemstones?


Backup and restore?


This would be a valid alternative to doing `bu snapshot` (a form of 
backup) and newExtent ...


In GsDevKit_home, use $GS_HOME/bin/todeBackup and 
$GS_HOME/bin/todeRestore to do a backup and restore ... these are bash 
scripts that call the tODE commands `bu backup` and `bu restore`, you 
will see docs for these commands when do the `man bu` ...


if you are doing regular production backups (which you should be) you 
could simply restore from backup into your sandbox stone, whenever you 
want to start with a fresh extent ...


While we are at it, take a look at the bash script $GS_HOME/bin/todeIt 
that allows you to call tode commands from bash ... a convenient way for 
you to do your deployment scripts, where you can write your own tODE 
command line scripts and then call them from bash ...


With GemStone 3.5.0 (not yet released), it will be practical to write 
topaz/smalltalk/stash[1] bash command line scripts for deployment ... I 
plan to give a talk on stash[1] at ESUG this year:)


Dale

[1] https://github.com/dalehenrich/stash

Re: [Pharo-users] [gemstones] Use case for GsDevKit_home

[Dale Henrichs]

On 5/30/19 5:44 AM, sergio ruiz wrote:


I have another project coming up, and I have free reign over the tech 
stack. I am gonna use Pharo, but I'd like to spend my up front time on 
this project figuring out the things I usually wait until the end to 
do. One of these issues is setting up gemstones.


I would like to use GsDevKit_home, but I want to make sure that the 
use case I am envisioning is in keeping what this package is set up to do.


My vision is something like:
- Deploy a stone to remote production server.
- Develop in the latest version of Pharo on my local machine, keeping 
my project in git.
- When it's time to deploy,  use tODE client to tell the production 
server to grab the latest code, and we're done.
This sounds okay ... I'd be inclined to have you also include a sandbox 
or QA stone in your setup, that is either a copy of the production db, 
or a db filled with test data, that you would use to validate your 
update process/code before each release to production ... better safe 
debugging in a sandbox, than sorry debugging in a production db:)


Does this sound reasonable?

Also, one thing that I find invaluable in troubleshooting applications 
written using relational databases is to be able to be able to just 
dump the production database and load it up on my local machine. Is 
this possible using gemstones?


Good you are thinking along the same lines ... You can take a snapshot 
of an extent in a running stone using the tODE command `bu snapshot` 
(run `man bu` in a tODE shell ) for more details, then using the 
GsDevKit_home bash script, $GS_HOME/bin/newExtent ( 
`$GS_HOME/bin/newExtent -h` for more details) you can install the 
snapshot from production into a local sandbox stone ...


For future questions about GsDevKit_home and GemSTone, please the GLASS 
mailing list[1][2]. There are a number of folks in the wild that are 
using the develop in Pharo, deploy in GemStone model so you'll benefit 
from having those folks weigh in with their approaches as well, without 
cluttering the Pharo newsgroup with GemStone information. Also there are 
few more GemTalk employees that monitor the GLASS list and can weigh in 
with their knowledge as well :)


Dale

[1] http://forum.world.st/GLASS-f1460844.html
[2] https://lists.gemtalksystems.com/mailman/listinfo/glass


Thanks!




peace,
sergio
photographer, journalist, visionary

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

Re: [Pharo-users] [GsDevKit_home] Is this project still the way to set up Gemstone?

[Dale Henrichs]

Sergio,

Also include the SHA of the GsDevKit_home commit that you are using:

   cd $GS_HOME
   git log -1

Dale


On 5/29/19 5:39 PM, Dale Henrichs wrote:


Sergio,

Could you open an issue here[1]. This is purely a GsDevKit_home issue. 
When you submit the issue, could you include details about what 
hardware you are running on and it would help if you included the 
entire install.log in your issue report as I think there is additional 
information in the log file that may help ...


Dale

[1] https://github.com/GsDevKit/GsDevKit_home/issues

On 5/29/19 5:28 PM, sergio ruiz wrote:
I am spending some time learning how gemstone works, and using this 
project as a starting point.


When trying to create a stone using either 3.3.0 or 3.4.0, I get the 
following error at the very end.


This is using the following incantation:

createStone devKit_33 3.3.0 |& tee -a $GS_HOME/install.log

Error on or near line 99 :: devKitCommandLine startstone devKit_33 -N 
:: devKitCommandLine startstone devKit_33 -N
Error on or near line 116 :: startStone -b -N devKit_33 :: startStone 
-b -N devKit_33
Error on or near line 148 :: newExtent -s 
/Users/sergio/Sites/GsDevKit_home/server/stones/devKit_33/product/bin/extent0.seaside.dbf 
devKit_33 :: newExtent -s 
/Users/sergio/Sites/GsDevKit_home/server/stones/devKit_33/product/bin/extent0.seaside.dbf 
devKit_33
Error on or near line 209 :: createStone devKit_33 3.3.0 :: 
createStone devKit_33 3.3.0


Ideas?

Thanks!


peace,
sergio
photographer, journalist, visionary

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

Re: [Pharo-users] [GsDevKit_home] Is this project still the way to set up Gemstone?

[Dale Henrichs]

Sergio,

Could you open an issue here[1]. This is purely a GsDevKit_home issue. 
When you submit the issue, could you include details about what hardware 
you are running on and it would help if you included the entire 
install.log in your issue report as I think there is additional 
information in the log file that may help ...


Dale

[1] https://github.com/GsDevKit/GsDevKit_home/issues

On 5/29/19 5:28 PM, sergio ruiz wrote:
I am spending some time learning how gemstone works, and using this 
project as a starting point.


When trying to create a stone using either 3.3.0 or 3.4.0, I get the 
following error at the very end.


This is using the following incantation:

createStone devKit_33 3.3.0 |& tee -a $GS_HOME/install.log

Error on or near line 99 :: devKitCommandLine startstone devKit_33 -N 
:: devKitCommandLine startstone devKit_33 -N
Error on or near line 116 :: startStone -b -N devKit_33 :: startStone 
-b -N devKit_33
Error on or near line 148 :: newExtent -s 
/Users/sergio/Sites/GsDevKit_home/server/stones/devKit_33/product/bin/extent0.seaside.dbf 
devKit_33 :: newExtent -s 
/Users/sergio/Sites/GsDevKit_home/server/stones/devKit_33/product/bin/extent0.seaside.dbf 
devKit_33
Error on or near line 209 :: createStone devKit_33 3.3.0 :: 
createStone devKit_33 3.3.0


Ideas?

Thanks!


peace,
sergio
photographer, journalist, visionary

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

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

[Dale Henrichs]

clarification embedded below

On 5/20/19 3:43 PM, Dale Henrichs wrote:


| project className |
project := (Rowan projectNamed:'Exercise') asDefinition.
className := 'Acronym'.
packageName := 'Exercise-', className.
((project
addPackageNamed: packageName
toComponentNamed: className
withConditions: 'gemstone'
andGroup: 'core')
addClassNamed: className super: 'Object' category: packageName)
addInstanceMethod: 'foo ^1' protocol: 'accessing.

((project
addPackageNamed: packageName, '-Test'
toComponentNamed: className
withConditions: 'gemstone'
andGroup: 'test')
addClassNamed: className, 'Test' super: 'TestCase' category: 
packageName)
addInstanceMethod: 'test ...' protocol: 'testing.

(project componentNamed: className)
addComponent: 'ExercismDev'.
project export. "to write project to disk"
project load.   "to load the project in the 
image"

'ExercismDev' above and 'ExercismTools' should be the same component 
name ('ExercismDev' ?) ... this is the component name containing the 
required packages ...


RwComponentLoadConfiguration{
#name : 'Acronym',
#version : '0.1.0',
#conditionalPackages : {
[
'gemstone'
] : {
'core' : {
#packageNames : [
'Exercise-Acronym'
]
}
'test' : {
#packageNames : [
'Exercise-Acronym-Test'
]
}

}
},
#componentNames : [ 'ExercismTools' ]
}

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

[Dale Henrichs]

moment, feedback will have a real impact on the end product.


Dale

[1] 
http://forum.world.st/The-baseline-complexity-of-tiny-big-projects-td5099495.html




Tim

Sent from my iPhone

On 20 May 2019, at 20:16, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:



Tim,

I know that this doesn't answer your question, but one of the 
features that I'm building into Rowan is just this capability:


  * project definitions composed of package definitions
  * package definitions composed of class and class extension definitions
  * class and class extensions definitions composed of method
definitions

... there are also definitions that cover what is now handled by 
Metacello: conditional packages, package grouping and project 
dependencies ...


I am intending/hoping that Rowan will eventually be available for 
Pharo:) ... I have to finish Rowan for GemStone first:)


Dale

On 5/19/19 10:23 AM, Tim Mackinnon wrote:

Hi - is there  a way to iterate over all the code in a package (or class or 
baseline) in a generic way (to pretty print out class definitions, and methods 
- including extensions ).

I was kind of hoping that with TonelWriter and Fileout and Critics that we 
would have a generic visitor mechanism but it seems that all of them just 
implemented it again - which misses a big opportunity for refactoring so that 
when you want to reason/print/manipulate code - it would be more straight 
forward.

Is there anything/anyone addressing this ? Or maybe I’ve missed an obvious 
trick somewhere?

Tim

Sent from my iPhone

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

[Dale Henrichs]

Tim,

I know that this doesn't answer your question, but one of the features 
that I'm building into Rowan is just this capability:


 * project definitions composed of package definitions
 * package definitions composed of class and class extension definitions
 * class and class extensions definitions composed of method definitions

... there are also definitions that cover what is now handled by 
Metacello: conditional packages, package grouping and project 
dependencies ...


I am intending/hoping that Rowan will eventually be available for 
Pharo:) ... I have to finish Rowan for GemStone first:)


Dale

On 5/19/19 10:23 AM, Tim Mackinnon wrote:

Hi - is there  a way to iterate over all the code in a package (or class or 
baseline) in a generic way (to pretty print out class definitions, and methods 
- including extensions ).

I was kind of hoping that with TonelWriter and Fileout and Critics that we 
would have a generic visitor mechanism but it seems that all of them just 
implemented it again - which misses a big opportunity for refactoring so that 
when you want to reason/print/manipulate code - it would be more straight 
forward.

Is there anything/anyone addressing this ? Or maybe I’ve missed an obvious 
trick somewhere?

Tim

Sent from my iPhone

Re: [Pharo-users] How to make Metacello ignore package cache?

[Dale Henrichs]

Hernán,

The multiple retrying messages imply that Metacello/Monticello is not 
able to download the ConfigurationOf ... which points to another issue: 
a ConfigurationOf cannot really be used with a git repository ... a 
ConfigurationOf should only be used with a http:// repo  ... you should 
be using a BaselineOf with a git repository ...


Dale

On 4/26/19 11:11 AM, Hernán Morales Durand wrote:

Hi Dale,

El vie., 26 abr. 2019 a las 15:12, Dale Henrichs
() escribió:

I'm not exactly sure why you are getting the error, but the standard way
to deal with a package-cache issue (or at least eliminate the
package-cache as the real culprit) is to clear the package-cage in the
Monticello browser ...

Ok, I will look for a way to do it programatically.


An alternative (or next step) would be to try the following:

Metacello new
  configuration: 'MyConfig';
  repository: 'github://hernanmd/MyPackage/repository';
  get

the `get` forces a reload of ConfigurationOfMyConfig from the source
repository ...

If that doesn't work, please supply a complete Transcript of your
Metacello `get` episode, so that I can try to figure out what is going
wrong ...


The Transcript after get is:

...RETRY->ConfigurationOfGADM
...RETRY->ConfigurationOfGADM
...FAILED->ConfigurationOfGADM

This is the actual script I tried with the get:

Metacello new
  configuration: 'GADM';
  repository: 'github://hernanmd/GADM/repository';
  get.

For this repository : https://github.com/hernanmd/GADM

Cheers,

Hernán



Dale

On 4/26/19 10:40 AM, Hernán Morales Durand wrote:

Hi guys,

Is there any way to tell Metacello to ignore the local package cache
after a failed load?

Say I tried to load:

Metacello new
  configuration: 'MyConfig';
  repository: 'github://hernanmd/MyPackage';
  load.

Then I figure the "repository" path is missing and I add it:

Metacello new
  configuration: 'MyConfig';
  repository: 'github://hernanmd/MyPackage/repository';
  load.

And I get this exception: Could not resolve: ConfigurationOfMyConfig
[ConfigurationOfMyConfig] in
D:\Hernan\Pharo703\pharo-local\package-cache
https://github.com/hernanmd/MyPackage.git[master]

It doesn't matter if I use #onConflictUseIncoming or

MetacelloPlatform current defaultPackageCache flushCache.

I cannot find a way to specify to ignore the cache.
Any ideas?

Cheers,

Hernán

Re: [Pharo-users] How to make Metacello ignore package cache?

[Dale Henrichs]

I'm not exactly sure why you are getting the error, but the standard way 
to deal with a package-cache issue (or at least eliminate the 
package-cache as the real culprit) is to clear the package-cage in the 
Monticello browser ...


An alternative (or next step) would be to try the following:

Metacello new
configuration: 'MyConfig';
repository: 'github://hernanmd/MyPackage/repository';
get

the `get` forces a reload of ConfigurationOfMyConfig from the source 
repository ...


If that doesn't work, please supply a complete Transcript of your 
Metacello `get` episode, so that I can try to figure out what is going 
wrong ...


Dale

On 4/26/19 10:40 AM, Hernán Morales Durand wrote:

Hi guys,

Is there any way to tell Metacello to ignore the local package cache
after a failed load?

Say I tried to load:

Metacello new
 configuration: 'MyConfig';
 repository: 'github://hernanmd/MyPackage';
 load.

Then I figure the "repository" path is missing and I add it:

Metacello new
 configuration: 'MyConfig';
 repository: 'github://hernanmd/MyPackage/repository';
 load.

And I get this exception: Could not resolve: ConfigurationOfMyConfig
[ConfigurationOfMyConfig] in
D:\Hernan\Pharo703\pharo-local\package-cache
https://github.com/hernanmd/MyPackage.git[master]

It doesn't matter if I use #onConflictUseIncoming or

MetacelloPlatform current defaultPackageCache flushCache.

I cannot find a way to specify to ignore the cache.
Any ideas?

Cheers,

Hernán

Re: [Pharo-users] Baseline subclasses

[Dale Henrichs]

Ahhh! Interesting solution to your problem ... funky but using tested 
features!


On 4/25/19 1:23 AM, Norbert Hartl wrote:

Dale,

looking at my code I really like the idea solving my white label 
problem with polymorphism. It makes things much easier IMHO. So ended 
up doing something like having something like this


BaselineOfCoreProduct
…
    spec group: ‚whiteLabel‘ with: #( ‚BaselineOfWhiteLabelProduct‘ )
…

and doing

    Metacello new
       baseline: #CoreProduct
       load: ‚whiteLabel‘;
       baseline: #WhiteLabelProduct;
       load

This way each baseline is still in its own package. The project is not 
for public consumption so we have to do that in our deployment process 
nowhere else.


Norbert


Am 25.04.2019 um 09:51 schrieb Norbert Hartl <mailto:norb...@hartl.name>>:




Am 25.04.2019 um 01:13 schrieb Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>>:



On 4/24/19 3:08 PM, Norbert Hartl wrote:
I don‘t have an idea how to achieve this with a group. It is about 
changing the number of dependencies of one package.


There's load order and there's grouping...

If you are using #linear loads for a BaselineOf then hard 
dependencies (Metacello requires:) dictate load  order and load 
order is important.


If you are using #atomic loads, then load order for packages is not 
important ... for #atomic loads you only need to specify which set 
of packages you want to have loaded together ... so if you have a 
baseline where you don't use #requires: anywhere and simply define 
different groups for each set of package to want to have loaded 
together (one for productA and another for productB) ... you should 
be able to get what you want ...


If this is a public baseline, then you have to warn users of your 
project that the only legally loadable entities are the set of 
groups that you've created, then things should work well ... ... I'd 
think:)




So no way of making Metacello load a package with one name and load 
a baseline with another name?


Not sure what you are thinking about here ... i think I need a 
concrete example of what you mean here…


Sorry, I wasn’t clear. I was talking about the possibility to have a 
basline loaded where the package name and the name of the baseline 
are not the same. So let’s say I have the two baselines in the 
BaselineOfCoreProduct. Then I would need to do something like


Metacello new
  package: „BaselineOfCoreProduct“;
  baseline: #BaselineOfWhiteLabelProduct;
  load

That would be sufficient. Having all the baselines in one package 
would be a smaller problem then.


Norbert

Re: [Pharo-users] Baseline subclasses

[Dale Henrichs]

On 4/24/19 3:08 PM, Norbert Hartl wrote:

I don‘t have an idea how to achieve this with a group. It is about changing the 
number of dependencies of one package.


There's load order and there's grouping...

If you are using #linear loads for a BaselineOf then hard dependencies 
(Metacello requires:) dictate load  order and load order is important.


If you are using #atomic loads, then load order for packages is not 
important ... for #atomic loads you only need to specify which set of 
packages you want to have loaded together ... so if you have a baseline 
where you don't use #requires: anywhere and simply define different 
groups for each set of package to want to have loaded together (one for 
productA and another for productB) ... you should be able to get what 
you want ...


If this is a public baseline, then you have to warn users of your 
project that the only legally loadable entities are the set of groups 
that you've created, then things should work well ... ... I'd think:)




So no way of making Metacello load a package with one name and load a baseline 
with another name?


Not sure what you are thinking about here ... i think I need a concrete 
example of what you mean here...


Dale

Re: [Pharo-users] Baseline subclasses

[Dale Henrichs]

Do I understand you correctly that the BaselineOfWhiteLabelProduct is a 
subclass of BaselineOfCoreProduct?


If so, I have no idea what would happen and it certainly has never been 
tested ... and as I think about this I can see that there would 
definitely be problems ... I think you are lucky that you ran into 
problems right off the bat:)


I know that a BaselineOf is a class and folks have been having fun 
partitioning their BaselineOf "code" into different methods ... but the 
fact that a BaselineOf is a class was a matter of convenience way back 
when the only thing that could be versioned was a package and packages 
only held onto classes ... and with a class, the browser could be 
leveraged as a tool ...


If STON had existed back then and we had been using a disk based SCM, I 
would have chosen STON for project specifications instead of a package 
and a class (as I'm doing today with Rowan) ...


I understand what you are trying to do (I think) and I am (hopefully) 
addressing what you are trying to do in Rowan, but I'm afraid that you 
are just be out of luck trying to do this sort of thing with Metacello ...


You might be able to hack a solution that would _appear_ to work by 
using a shared abstract superclass of both products and include the 
superclass in both packages ... but I'm afraid that this approach would 
more than likely just give you a bit more rope to hang yourself with 
down the road:) ... of course putting the same class in two different 
packages is problematic all by itself ...


I think that your best bet is to create a single BaselieOf and 
differentiate your two products with two groups ... I know it's not 
ideal, but at least this kind of thing has been pretty heavily tested ...


Dale

On 4/24/19 9:24 AM, Norbert Hartl wrote:

I’m trying to customize our current project with multiple baselines meaning 
BaselineOfCoreProduct and BaselineOfWhiteLabelProduct. The latter is a subclass 
of the former. My problem is that I don’t know which way to choose for loading 
because

Metacello new
 baseline: #WhiteLabelProduct
 load

that does not work if BaselineOfCoreProduct is in its own package because that 
is not loaded but the superclass is in there. I saw that I can provide an array 
to baseline: but regardless in which order I put them the wrong is always 
loaded first. So order of the array seem not to matter.


I could still load BaselineOfCoreProduct first and then 
BaselineOfWhiteLabelProduct but I would like to have a better way of doing. I 
could also image putting both baselines in the same package but I don’t know 
how to use Metacello to say it should load a package name and use another named 
Baseline.

Any help appreciated,

Norbert

Re: [Pharo-users] Why doesn't collection have #excludes (the mirror of includes)?

[Dale Henrichs]

Isn't this an "ultimate" goal for Pharo  ... once you've got a stable 
(truly) minimum image, custom class libraries are possible if not 
desirable ...


Dale

On 3/18/19 11:08 AM, Esteban Maringolo wrote:

El dom., 17 mar. 2019 a las 6:33, Sven Van Caekenberghe
() escribió:




On 17 Mar 2019, at 07:56, Richard O'Keefe  wrote:

(1) As it happens, my Smalltalk library *does* have

"my mystery Smalltalk" ;-)

Codename "Unicorn". :)

Jokes aside, I'd love to see such implementation because all software
products developed by only a few minds, if not one at all, have a
level of coherence and parsimony that can't be achieved with a larger
team. I only saw it with Dolphin Smalltalk, and would love to see your
Unicorn Smalltalk as well.

Regards,

Esteban A. Maringolo

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

[Dale Henrichs]

On 3/6/19 8:18 AM, Sean P. DeNigris wrote:

Tim Mackinnon wrote

how is this shared repository supposed to work?

While I initially liked the space efficiency of the shared approach, I
eventually gave up because it created too many (often obscure) problems. It
just doesn't seem to be a good match for git, although you can get away with
it in the simplest cases (read-only, no branch switching).


The use case that I have used for years (tODE and GemStone) is that I am 
sharing 60+ git repositories amongst 60+ images and I want all of the 
images to be sharing the same versions of all of the git projects. When 
I want to do private work I create a clone that is local to the image 
that I'm working in and do my work on a topic branch ... when I'm done 
with the private work, I merge the topic branch back into my commonly 
shared branch and then update the shared git repository so that when I 
do activate one of the images.


I can quickly tell (via tools) that i have not loaded the latest shared 
code into my image ... if I care (like preparing to do development), I 
update to the latest shared code, so that my changes can be shared... if 
I don't care, then I remember not to make any code changes that I want 
to keep:)


The images that I am using are a mix different versions of GemStone, so 
I _do_ make it a practice to ensure that projects I work with are all 
loadable in the different versions of GemStone that I care about via 
baseline changes (I use packages for version-specific code and avoid 
putting version-specific code on different branches or tags) ...


So, when you say it's not "a good match for git", I don't think that it 
is "git" that is the problem, but the use cases themselves are the 
culprit... different tool features are very likely needed to support 
different use cases ...


Dale

Re: [Pharo-users] Trying to understand Developing with Pharo, Deploying with Gemstone/s

[Dale Henrichs]

Hello Sergio,

Sorry for the delay in replying .. too many balls in the air:) I'll 
comment in-line ..


On 2/8/19 7:07 AM, sergio ruiz wrote:


I have an app that is ready to deploy to alpha. I usually do this by 
creating a script that builds a minimal pharo image, and run that on a 
cloud server.


I then use TelePharo to make any live tweaks that need to happen, and 
something like:


|./pharo Pharo.image "/run/the/script" |

to keep run cron jobs, etc.

I would like to start using Gemstone/s.

I got GsDevKit_home up and running, with no problems, but I am having 
a little bit of trouble figuring out how to proceed. I get what tODE 
is doing, but I don’t get how to do the things I normally do:


  * I got Seaside installed in the image, but I need several other
packages in my install: JSON, Soup, AWS S3, etc. How do I go about
installing those?

I assume that you used the following tODE command to install Seaside, 
following these instructions[1]?


   |project install
   --url=http://gsdevkit.github.io/GsDevKit_home/Seaside32.ston|

The url in the command resolves to a project entry for Seaside32, that 
looks like this:


^ TDProjectSpecEntryDefinition new
baseline: 'Seaside3'
  repository: 'filetree://$GS_HOME/shared/repos/Seaside/repository'
  loads: #('Zinc Project' 'Welcome' 'Development' 'Examples');
installScript:
'project clone --https --local Seaside3
  project install --local 
--url=http://gsdevkit.github.io/GsDevKit_home/GsApplicationTools.ston';
gitCheckout: 'master';
status: #(#'inactive');
locked: true;
yourself

The `installScript` is run by the `project install` command and causes 
the two projects to be cloned into your shared git repository area. The 
project entries for both projects are also dropped to a common disk 
location and will show up in your `project list` as unloaded projects in 
all of the stones you create, so the `install` only needs to be done once.


I'm pointing this out because you can use the `project entry` command to 
create project entries in the "common disk location" by using the 
`project entry` command ... here's the man page obtained by doing `man 
project entry` (`man project` will list all of available `project` 
commands):


NAME
  project entry - Create a new project entry

SYNOPSIS
  project entry --baseline= --repo= 
[--loads=] \

  entry --config= [--version=] \
--repo= [--loads=] 
  entry --git= [--repo=] 
  entry --url= 

DESCRIPTION
  The project entry specifies project options used by the `project list` window.

  A project entry can be created for loaded projects or for projects that have
  yet to be loaded.

  There are three basic types of project entry: Git, Metacello, and HTTP.

  Git Project Entries
  ---
  For Git project entries you define the name of the project and the location on
  disk where the git repository is located. For example:

project entry --git=projectHome --repo=$GS_HOME /sys/local/server/projects

  Metacello Project Entries
  -
  For Metacello project entries you define the name of the project, the type of
  the project (baseline or configuration), the repository where the baseline or
  configuration may be found, and (optionally) the package/project/groups to be 
loaded.
  For configurations, you also specify the version of the project to be loaded. 
For example:

project entry --config=External  \
  --version=1.0.0\
  --repo=http://ss3.gemstone.com/ss/external \
  --loads=`#('Core')`  \
  /sys/local/server/projects

project entry --baseline=External\
  --repo=github://dalehenrich/external:master/repository \
  /sys/local/server/projects

  If you don't specify a `--loads` option, the 'default' group is loaded. Once 
you have
  created a project entry, you may change or add attributes. For example, you 
may want to
  change the status to #inactive.

  HTTP Project Entries
  
  For HTTP project entries, you an download an existing project entry from a 
web-site. For
  example:

project entry --url=http://gsdevkit.github.io/GsDevKit_home/Seaside31.ston \
  /sys/stone/projects

  Downloads a project entry from 
http://gsdevkit.github.io/GsDevKit_home/Seaside31.ston
  into the /sys/stone/projects node.

  Once a project is loaded, only changes to the loads specification, locked
  attribute and active attribute may have an effect. The remaining information
  is taken directly from the loaded project itself.

  Any changes you make will take effect after the project list is refreshed.

  If there is already a project with the same project name in your project 
list, the download
  will be skipped.

  If this command is run as a 

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Dale Henrichs]

Esteban,

I'm glad that you are taking SETT for a spin.

I am not familiar with the details of SETT, but if you could submit an 
issue[1] with the SETT project, then someone should be able to start 
looking into it:)


I will ping them that you ran into issues ...

Dale

[1] https://github.com/GemTalk/SETT/issues

On 2/19/19 4:36 PM, Esteban Maringolo wrote:

Dale,

I tried to test SETT to migrate a Package from Store to our repo.

But it fails while initializing the git repository. I set the 
destination config to `isNewRepository := false`, then it works as 
expected.


I'm testing it against the Cincom Public Repository, which being 
remote and full of code (and garbage), limiting by date isn't useful 
if I can't filter by a particular package name/pattern (I couldn't 
find such option).


In any case, it's a helpful tool to ease the migration of code.

Regards,

Esteban A. Maringolo


El mié., 16 ene. 2019 a las 18:18, Dale Henrichs via Pharo-users 
(mailto:pharo-users@lists.pharo.org>>) 
escribió:



On 1/16/19 11:56 AM, Esteban Maringolo wrote:

This is great!

One less fence to move code from one dialect to another. :)

I will follow the examples and try to export code from Store and
load id in Pharo.

Is it mandatory to use Linux?


We've only tested with Linux and it looks like the current code
base is wired to use Unix[1] 

Dale

[1]

https://github.com/GemTalk/SETT/blob/master/StoreImporter.package/SettGitRepository.class/instance/runGitWithArguments..st



Esteban A. Maringolo


El mié., 16 ene. 2019 a las 16:38, Dale Henrichs
(mailto:dale.henri...@gemtalksystems.com>>) escribió:

GemTalkSystems is pleased to announce SETT (Store Export to
Tonel Tools)[1]. SETT is open source project with an MIT license.

SETT (Store Export to Tonel Tools) is a set of tools to
export Smalltalk code from Store and
write into the Tonel file format managed using Git.

SETT is:

  * a Pharo 6.1 application, that
  * connects to a Postgres Database
  * containing source code history in VisualWorks Store
format; and
  * writes to a Git repository
  * in Tonel format
  * maintaining all version history, source code and SCM
metadata.

SETT was developed last year to support one of our commercial
customers in their conversion From Store to Rowan[2]. Rowan
artifacts are produced as part of the output of SETT, but the
Rowan artifacts can be ignored. The important bit is that
SETT converts from Store to Tonel and maintains version
history in git.

Please see the project ReadMe[3] and Wiki[4] for additional
details.

Dale

[1] https://github.com/GemTalk/SETT
[2] https://github.com/GemTalk/Rowan
[3] https://github.com/GemTalk/SETT#overview
[4] https://github.com/GemTalk/SETT/wiki

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Dale Henrichs via Pharo-users]

--- Begin Message ---


On 1/16/19 11:56 AM, Esteban Maringolo wrote:

This is great!

One less fence to move code from one dialect to another. :)

I will follow the examples and try to export code from Store and load 
id in Pharo.


Is it mandatory to use Linux?


We've only tested with Linux and it looks like the current code base is 
wired to use Unix[1] 


Dale

[1] 
https://github.com/GemTalk/SETT/blob/master/StoreImporter.package/SettGitRepository.class/instance/runGitWithArguments..st




Esteban A. Maringolo


El mié., 16 ene. 2019 a las 16:38, Dale Henrichs 
(<mailto:dale.henri...@gemtalksystems.com>>) escribió:


GemTalkSystems is pleased to announce SETT (Store Export to Tonel
Tools)[1]. SETT is open source project with an MIT license.

SETT (Store Export to Tonel Tools) is a set of tools to export
Smalltalk code from Store and
write into the Tonel file format managed using Git.

SETT is:

  * a Pharo 6.1 application, that
  * connects to a Postgres Database
  * containing source code history in VisualWorks Store format; and
  * writes to a Git repository
  * in Tonel format
  * maintaining all version history, source code and SCM metadata.

SETT was developed last year to support one of our commercial
customers in their conversion From Store to Rowan[2]. Rowan
artifacts are produced as part of the output of SETT, but the
Rowan artifacts can be ignored. The important bit is that SETT
converts from Store to Tonel and maintains version history in git.

Please see the project ReadMe[3] and Wiki[4] for additional details.

Dale

[1] https://github.com/GemTalk/SETT
[2] https://github.com/GemTalk/Rowan
[3] https://github.com/GemTalk/SETT#overview
[4] https://github.com/GemTalk/SETT/wiki


--- End Message ---

[Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

[Dale Henrichs]

GemTalkSystems is pleased to announce SETT (Store Export to Tonel 
Tools)[1]. SETT is open source project with an MIT license.


SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk 
code from Store and

write into the Tonel file format managed using Git.

SETT is:

 * a Pharo 6.1 application, that
 * connects to a Postgres Database
 * containing source code history in VisualWorks Store format; and
 * writes to a Git repository
 * in Tonel format
 * maintaining all version history, source code and SCM metadata.

SETT was developed last year to support one of our commercial customers 
in their conversion From Store to Rowan[2]. Rowan artifacts are produced 
as part of the output of SETT, but the Rowan artifacts can be ignored. 
The important bit is that SETT converts from Store to Tonel and 
maintains version history in git.


Please see the project ReadMe[3] and Wiki[4] for additional details.

Dale

[1] https://github.com/GemTalk/SETT
[2] https://github.com/GemTalk/Rowan
[3] https://github.com/GemTalk/SETT#overview
[4] https://github.com/GemTalk/SETT/wiki

Re: [Pharo-users] Updating singletons

[Dale Henrichs]

Konrad,

Did you try what I suggested and did it solve your problem?

Dale

On 1/5/19 2:45 AM, Konrad Hinsen wrote:

Dale,


This looks like a case where you are using a metadata-less repository
... if so you, should add the following method to your baseline class:

Sorry, that's way above my understanding of baselines and repository
handling in general. I started from

   
https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md

and adapted the examples there to my own situation, my project being
hosted on GitHub:

   https://github.com/khinsen/leibniz-pharo/


This mod will cause packages to be unconditionally loaded ... Monticello
does a definition comparison on package load so only changed definitions
are loaded into the image ...

I'd say that a new dependency should be treated like a changed one, but
again I am still very much lost in the jungle of Monticello, Metacello,
Gofer, Iceberg, etc. It's the most opaque aspect of Pharo I have
encountered so far.

Cheers,
Konrad.

Re: [Pharo-users] Updating singletons

[Dale Henrichs]

Konrad,

This looks like a case where you are using a metadata-less repository 
... if so you, should add the following method to your baseline class:


   projectClass
  Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^ cl 
].
  ^ super projectClass

This mod will cause packages to be unconditionally loaded ... Monticello 
does a definition comparison on package load so only changed definitions 
are loaded into the image ...


Hope this helps,

Dale

On 1/4/19 5:12 AM, Konrad Hinsen via Pharo-users wrote:

Subject:
Re: [Pharo-users] Updating singletons
From:
Konrad Hinsen 
Date:
1/4/19, 5:12 AM

To:
pharo-users@lists.pharo.org


H Cyril,


Fetching, loading and post loads should leave a trace during the
execution in the Transcript.

Thanks, that helps to confirm that my postload is never executed when I
update a package + baseline in an image that already had an earlier
version loaded. Nothing at all is shown in the Transcript. Reloading the
package and/or the baseline package doesn't leave any trace either. And
if I add a dependency, then update the package again, the new dependency
is not loaded either.

Hypothesis: baseline changes have no effect for already installed packages.

When I load my modified package + baseline into a fresh image, lots of
actions are shown in the Transcript, including the execution of my
postload action. But in that situation, I don't actually need it.

Cheers,
   Konrad.

Re: [Pharo-users] how to write this without a if then

[Dale Henrichs]

Roelof,

One technique to eliminating the use of #ifTrue:ifFalse: is to use 
double dispatching. There are some good examples of using double 
dispatching in Ralph Johnson's paper "ARITHMETIC AND DOUBLE DISPATCHING 
IN SMALLTALK-80"[1].  you should be able to get the basic idea by 
skimming the smalltalk code examples.


I used double dispatching fairly extensively in Metacello ...

In practice you may not eliminate all use of #ifTrue:ifFalse:, but 
double dispatching works quite well in places where you are tempted to 
do type checking...


Dale

[1] 
https://www.researchgate.net/publication/239578755_Arithmetic_and_double-_dispatching_in_smalltalk-80


On 11/27/18 8:40 AM, Roelof Wobben wrote:

Hello,

Yesterday I had a talk with luc frabresse about using if then.
He said if I understand it right, Its the best to not using a if then 
or a ifTrue/ifFalse.


Can anyone help me figure out how to rewrite this project so I will 
not use the ifTrue in the basement function.


my code so far can be found here : 
https://github.com/RoelofWobben/AOC2015


Roelof

Re: [Pharo-users] Metacello load baselines/configurations only

[Dale Henrichs]

Use the Metacello `get` command:

    Metacello new
        repository: '...';
        get

Just the baseline (or Configuration) will be loaded.

Dale

On 10/02/2018 11:34 PM, Peter Uhnak wrote:

Hi,

is there a way to instruct Metacello to only install 
BaselineOfs/ConfigurationOfs instead of the entire project? For the 
purposes of analyzing dependencies.


Thanks,
Peter

Re: [Pharo-users] How to specify generic (non-github) git dependency?

[Dale Henrichs]

Herby,

Right now there is "no portable way" to specify arbitrary hosts in a 
Metacello spec ... but Esteban and I will be talking about this on 
Monday ... Thierry Goubier seems to have a nice scheme for gitfiletree 
and I think that iceberg might support additional urls and schemes...


Dale


On 01/28/2018 01:52 AM, Herbert Vojčík wrote:

Hi,

I know I can do, for example,

[..snip..]
package: 'Foo' with: [ spec
    requires: #('Mocketry') ];

baseline: 'Mocketry' with: [ spec
    repository: 'github://dionisiydk/Mocketry:v4.0.x' ];
[..snip..]

but when I want to add dependency to a repo which is not on github nor 
on bitbucket, how do I specify (https or scp) git depedency in generic 
way?


Thanks, Herby

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

[Dale Henrichs]

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] unsolicited package-cache use

[Dale Henrichs]

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

On 1/17/18 8:30 PM, Hernán Morales Durand wrote:

Hi Hilaire,

Which Pharo version?
Have you found any solution to this?
In Gofer there was #disablePackageCache, in Metacello I don't know,
maybe experimenting with MetacelloLoaderPolicy but there are no class
comments.
Cheers,

Hernán


2017-12-18 17:24 GMT-03:00 Hilaire :

If understood correctly, when using a tonel file repository to build up an
image, Pharo seems instead to take the sources from some package-cache,
which is out of sync, because the tonel file repo was updated from another
image, with a different cache. I guess I can trick the file system but it is
for the least very annoying, for the worst unreliable.



Le 10/12/2017 à 18:16, Hilaire a écrit :

I am using tonel format to install from and save to a local repository.

How to prevent Monticello/Configuration/Metacello to save packages to the
image package-cache dir?

Even when installing from a configuration with repo on tonel file format,
packages get created in the image package-cache directory.

I have read there and there, Pharo gets confused and uses wrongly the
package-cache versions and not the local repo.


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

Re: [Pharo-users] Metacello with Git

[Dale Henrichs]

On 12/20/17 2:53 AM, Vitor Medina Cruz wrote:


These days, we are getting to the point where I am beginning to
flip the question on it's head and begin thinking that it should
be possible for  a developer to choose to have have the github://
url interpreted as "create a local clone of the remote repository"
instead of "download a tarball of the remote repository" . With
this approach it should be possible to include gitlab url support
as well since the gitlab issue is related to the specific handling
of repository tarballs..


Using  'git clone --depth=1'  don't do the trick and leave the process 
both efficient and general accross all git repos?
At the time that github:// was added (5 years ago now?) git could not be 
counted upon to be installed by the folks who may be interested in 
depending upon a project hosted on github, so the tarball approach was 
used so that those brave souls interested in using git and github could 
do so without forcing everyone else  to start using git ... nowadays 
with git becoming part of the mainstream dev env for Smalltalk, git (or 
libgit2 in the case of pharo) can be counted on to be available ...




On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs 
<dale.henri...@gemtalksystems.com 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


BitBucket is supported with like Github with:
butbucket:///.

With regards to GitLab, their download zip format is/was different
enough from BitBucket/Github to make it difficult to provide the
same level of support. See the series of comments here[1].

When the github:// was first introduced it was done in such a way
that users of projects on GitHub did not have to have git
installed on their local computers ... it was a way to make it
possible for folks to begin using git without requiring everyone
to install git ...

These days, we are getting to the point where I am beginning to
flip the question on it's head and begin thinking that it should
be possible for  a developer to choose to have have the github://
url interpreted as "create a local clone of the remote repository"
instead of "download a tarball of the remote repository" . With
this approach it should be possible to include gitlab url support
as well since the gitlab issue is related to the specific handling
of repository tarballs...

... there are current discussions in this area on these two issues
[2] and [3].

Dale

[1]
https://github.com/Metacello/metacello/issues/287#issuecomment-59815235
<https://github.com/Metacello/metacello/issues/287#issuecomment-59815235>

[2] https://github.com/Metacello/metacello/issues/474
<https://github.com/Metacello/metacello/issues/474>

[3] https://github.com/Metacello/metacello/issues/475
<https://github.com/Metacello/metacello/issues/475>



On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:

Hello,

Using github:/// metacello works fine,
but is there another more general way of refering to a remote
git repo? From BitBucket or Gitlab for example.

Regards,
Vitor

Re: [Pharo-users] Metacello with Git

[Dale Henrichs]

Sean,

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.


Dale


On 12/19/17 7:02 PM, Sean P. DeNigris wrote:

CyrilFerlicot wrote

For bitbucket you can use bitbucket://.
I don't know for gitlab.

Unless something has changed, the cool git URLs only work for public
projects. In any case, it was not possible to authenticate with SSH keys
last time I checked (so I could not use them)…



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

Re: [Pharo-users] Metacello with Git

[Dale Henrichs]

BitBucket is supported with like Github with: 
butbucket:///.


With regards to GitLab, their download zip format is/was different 
enough from BitBucket/Github to make it difficult to provide the same 
level of support. See the series of comments here[1].


When the github:// was first introduced it was done in such a way that 
users of projects on GitHub did not have to have git installed on their 
local computers ... it was a way to make it possible for folks to begin 
using git without requiring everyone to install git ...


These days, we are getting to the point where I am beginning to flip the 
question on it's head and begin thinking that it should be possible for  
a developer to choose to have have the github:// url interpreted as 
"create a local clone of the remote repository" instead of "download a 
tarball of the remote repository" . With this approach it should be 
possible to include gitlab url support as well since the gitlab issue is 
related to the specific handling of repository tarballs...


... there are current discussions in this area on these two issues [2] 
and [3].


Dale

[1] https://github.com/Metacello/metacello/issues/287#issuecomment-59815235

[2] https://github.com/Metacello/metacello/issues/474

[3] https://github.com/Metacello/metacello/issues/475


On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:

Hello,

Using github:/// metacello works fine, but is 
there another more general way of refering to a remote git repo? From 
BitBucket or Gitlab for example.


Regards,
Vitor

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

[Dale Henrichs]

Hernán.

Well I tried to look at this, but the first problem I ran into is that the 
package name is a Symbol (#ConfigurationOfSystemLogger) and the package name is 
supposed to be a String --- I'm trying to look at this from GemStone --- the 
package name is also a Symbol (#DeployUtils), so I cannot actually try to 
execute the Metacello record code to see what might be going wrong ... since 
the Metacello error is that the package is that it cannot resolve the project 
package name #DeployUtils, this might be the root cause of the problem ... the 
error also says that the there are likely to be invalid configurations involved 
as well ...

Your second error gives me a bit more of a clue as to what might be going on ... again 
this points to a problem with the DeployUtils baseline: there are no dependencies 
declared between the DeployUtils package and the SystemLogger project, so Metacello is 
"free to load the two in any order" ... from your second error message it seems 
that in the absence of dependencies, Metacello loaded the package before loading 
SystemLogger ...

Dale


On 09/27/2017 12:53 PM, Stephane Ducasse wrote:

Thierry what is import:
and why should it be recursive?

On Wed, Sep 27, 2017 at 9:41 AM, Thierry Goubier
 wrote:

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] Some Metacello issue

[Dale Henrichs]

On 06/07/2017 03:46 AM, Holger Freyther wrote:

On 7. Jun 2017, at 14:09, Stephan Eggermont  wrote:

Never refer to fixed versions unless you know why (you need to avoid a
specific bug fix).

When wanting to have repeatable builds (e.g. for bugfixes) and in the
absence of other means to lock/define versions externally, I think using
a fixed version is the way to go.



What is most likely is that there is some overconstrained configuration.
Does your ConfigurationOfVoyageMongo or one of the configurations it
pulls in refer to different versions of grease or magritte? Another
issue can be that there are older configurations already loaded that
conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
is broken, refering to a fixed and older version of Grease.
ConfigurationOfVoyageMongo should probably be using #'release3' of
Magritte, but that doesn't break it.

Right. So we have a "OsmocomUniverse" build job that pulls in all the
apps into a single image. This helps to make API modifications and not
forget any of the client code.

The configuration has such dependencies:

ConfigurationOfOsmocomUniverse
-> ConfigurationOfHLR
-> ConfigurationOfVoyageMongo
-> Mongotalk
-> Grease A
-> Magritte3
-> Grease B
-> ConfigurationOfSMPPRouter
-> ConfigurationOfVoyageMongo
-> Mongotalk
-> Grease A
-> Magritte3
-> Grease B

What happens is that somehow "Grease A" gets loaded, then "Grease B" and
when it is time for "Grease A" again.. the system kind of explodes and this
is for Pharo3 and Pharo6. Now the question to me is.. why is this coming
up right now? Did MongoTalk change or Magritte3 or something else?

Is there an easy way for Metacello to try a mirror instead of the original,
e.g. to inject an older ConfigurationOfMagritte3?



I think that the `lock` command[1] is what you are looking for ...

Dale

[1] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking

[Pharo-users] smalltalkhub.com down?

[Dale Henrichs]

http://downforeveryoneorjustme.com/http://smalltalkhub.com/mc/dkh/metacello/main/?C=M;O=D

Re: [Pharo-users] ss3 and gemsource planned downtime today at 1:30 pm PDT (-0700 UTC)

[Dale Henrichs]

server is back online...


On 04/25/2017 05:28 AM, Dale Henrichs wrote:
The server hosting http://ss3.gemtalksystems.com/ and 
http://seaside.gemtalksystems.com/ss will be down for a couple of 
hours today starting at 1:30 pm PDT for maintenance.


Dale

[Pharo-users] ss3 and gemsource planned downtime today at 1:30 pm PDT (-0700 UTC)

[Dale Henrichs]

The server hosting http://ss3.gemtalksystems.com/ and 
http://seaside.gemtalksystems.com/ss will be down for a couple of hours 
today starting at 1:30 pm PDT for maintenance.


Dale

Re: [Pharo-users] [Deploy Application] Where to host using Gemstone/s?

[Dale Henrichs]

Sergio,

The GsDevKit_home project[1] provides a set of tools for installing and 
running GemStone/S.


There is GsDevKit_ansible[2] built on top of GsDevKit_home that provides 
a set of Ansible[3] playbooks for deploying a GemStone server, Nginx, 
daemontools, etc. on Ubuntu. Ansible can be used with AWS or Linode...


For additional help, I suggest that you hop over to he GsDevKit/GLASS 
mailing list and ask additional questions.


Dale

[1] 
https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-gemstones-64-bit-


[2] https://github.com/GsDevKit/GsDevKit_ansible

[3] https://github.com/GsDevKit/GsDevKit_ansible

[4] http://lists.gemtalksystems.com/mailman/listinfo/glass
On 03/22/2017 12:35 PM, sergio ruiz wrote:


I am ready to deploy a live production application, and am exploring 
my options..


I currently host a bunch of other things over at Digital Ocean. I 
would like to use them for this project to, using a new droplet.


Does anyone know if there is a quick and easy way to install 
Gemstone/s on the Digital Ocean server?


I will also need to port Teapot to Gemstone/s.

If I need to install Gemtone/s from scratch on the server, which 
distro would be the recommended for such a thing>


Thanks!



peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.Village-Buzz.com 
http://www.ThoseOptimizeGuys.com 
http://www.coffee-black.com 
http://www.painlessfrugality.com 
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Re: [Pharo-users] Class versions

[Dale Henrichs]

On 03/21/2017 02:06 AM, Norbert Hartl wrote:

Hi Dale,


Am 20.03.2017 um 19:30 schrieb Dale Henrichs <dale.henri...@gemtalksystems.com>:

Norbert.

Are you thinking of GemStone-style class versions for Pharo?


I was thinking of something less elaborate.
The GemStone implementation is not very elaborate ...  the `class 
history` exists pretty much to provide #isKindof: sanity for "two 
versions of the same class".

The first thing that should be possible is that two classes with different 
shape of the same name can co-exist in the image.That might be provided by 
#environment. The next step would be to have something like #migrateTo: in 
GemStone. Meaning that in case of a class/shape change the old instance is 
called with the new shape as parameter so I can intercept the process of object 
migration.

The #history case of GemStone would be nice of it would be modular and could be 
loaded. I think it can be done. But the points above need to be done first.

Norbert


Dale

On 03/19/2017 06:16 AM, Norbert Hartl wrote:

How far are we to support multiple versions of the same class in an image? Are 
there existing approaches?

Norbert




Von meinem iPad gesendet

Re: [Pharo-users] Class versions

[Dale Henrichs]

Norbert.

Are you thinking of GemStone-style class versions for Pharo?

Dale

On 03/19/2017 06:16 AM, Norbert Hartl wrote:

How far are we to support multiple versions of the same class in an image? Are 
there existing approaches?

Norbert




Von meinem iPad gesendet

Re: [Pharo-users] What is the craziest bug you ever face

[Dale Henrichs]

The attached screnshot  illustrates why I like having text instead of 
pngs ... being able to highlight the association value (-5.00->5.00) is 
very useful when identifying the entries in a btree associated with the 
association (the entries at 13, 16,19, and 22)...



On 03/09/2017 11:34 AM, Dale Henrichs wrote:


Stef,

One of the things that I do all of the time when trying to debug 
particularly difficult problems is to keep a "bug notebook".  My "bug 
notebook" is a text file where I record information gleaned from an 
inspector intermixed with comments, code and observations...


I've attached an example from a couple of days ago (bug_notebook.txt).

The particular problem I am working on involves btree nodes being 
improperly updated during index object updates. Each btree node is 
basically a 2000+ element Array ... so there is a lot of data to deal 
with .


In the notebook, I extract the interesting entries from the btree node 
and record the original set of values and then record the updated set 
of values and in this particular case I was able to "see" that after 
the update I had 4 entries that were not properly deleted ...


In addition to recording the interesting chunks of large data 
structures, I often end up with chunks of stacks from the debugger, 
copies of a inspector panes in my "bug notebooks" and chunks of code ...


Over the last several weeks I have been tackling different sets of 
bugs in this same area and I have been keeping a time-stamped log of 
the work that I've done along the way (analysis_notebook.txt) ... in 
this notebook I've bee recording test results and branch/SHA 
information so that I can easily reference different versions of 
methods as I work through fixing bugs and managing regressions ... 
There's  a section in the notebook where I've record performance 
information, so that when I have finished work on this set of bugs, I 
can evaluate how I've impacted performance ... Finally at the very 
bottom of the notebook, I've recorded a simple todo-list ...


The  notebooks are on a shared disk so that I can access and update 
the "bug notebook" when I am working from home on a mac or at work 
from a linux box ...


I rely on the fact that I am working with text and not images ... 
since I like to copy and paste as well as search for particular 
strings in the data from the inspector ... in the bug_notebook  I 
searched for the `victim` string in the text output  from an inspector ...


I have come to really depend upon bug notebooks when addressing 
difficult bugs and I think that support for creating and maintaining 
bug notebooks would be a valuable addition the the debugging arsenal...


Dale

On 03/09/2017 10:50 AM, stepharong wrote:

Thanks you all.

The idea is that we want to see how we cn improve our debugging arsenal.
So it is important that your scenario give use some hints.
It is difficult to convey what we are really looking for :)



Hi guys

During the DSU workshop we were brainstorming about what are the
most difficult bugs we faced and what are the conceptual tools
that would have helped you.

Stef




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] What is the craziest bug you ever face

[Dale Henrichs]

Stef,

One of the things that I do all of the time when trying to debug 
particularly difficult problems is to keep a "bug notebook".  My "bug 
notebook" is a text file where I record information gleaned from an 
inspector intermixed with comments, code and observations...


I've attached an example from a couple of days ago (bug_notebook.txt).

The particular problem I am working on involves btree nodes being 
improperly updated during index object updates. Each btree node is 
basically a 2000+ element Array ... so there is a lot of data to deal 
with .


In the notebook, I extract the interesting entries from the btree node 
and record the original set of values and then record the updated set of 
values and in this particular case I was able to "see" that after the 
update I had 4 entries that were not properly deleted ...


In addition to recording the interesting chunks of large data 
structures, I often end up with chunks of stacks from the debugger, 
copies of a inspector panes in my "bug notebooks" and chunks of code ...


Over the last several weeks I have been tackling different sets of bugs 
in this same area and I have been keeping a time-stamped log of the work 
that I've done along the way (analysis_notebook.txt) ... in this 
notebook I've bee recording test results and branch/SHA information so 
that I can easily reference different versions of methods as I work 
through fixing bugs and managing regressions ... There's  a section in 
the notebook where I've record performance information, so that when I 
have finished work on this set of bugs, I can evaluate how I've impacted 
performance ... Finally at the very bottom of the notebook, I've 
recorded a simple todo-list ...


The  notebooks are on a shared disk so that I can access and update the 
"bug notebook" when I am working from home on a mac or at work from a 
linux box ...


I rely on the fact that I am working with text and not images ... since 
I like to copy and paste as well as search for particular strings in the 
data from the inspector ... in the bug_notebook  I searched for the 
`victim` string in the text output  from an inspector ...


I have come to really depend upon bug notebooks when addressing 
difficult bugs and I think that support for creating and maintaining bug 
notebooks would be a valuable addition the the debugging arsenal...


Dale

On 03/09/2017 10:50 AM, stepharong wrote:

Thanks you all.

The idea is that we want to see how we cn improve our debugging arsenal.
So it is important that your scenario give use some hints.
It is difficult to convey what we are really looking for :)



Hi guys

During the DSU workshop we were brainstorming about what are the
most difficult bugs we faced and what are the conceptual tools
that would have helped you.

Stef




--
Using Opera's mail client: http://www.opera.com/mail/


tMultiEnumeratedIndexUpdateD_ModifyingInstVarAtOffset_to
dkh 3/8/2017 16:14
--
Step one is to understand how things were removed incorrectly ... and then go 
from there
-
victim key value: commonAssoc.
commonAssoc-> -63.00->63.00
commonBinding  -> 63.00
victim -> -60.00->60.00->-63.00->63.00->-60.00->60.00->-63.00->63.00
-
  reachable:
1@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
2@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
3@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
4@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
-
-
dkh 3/8/2017 16:14
--
-
before update:
victim -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
-
73@   -> -60.00->-60.00
74@   -> -60.00
75@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
76@   -> -60.00->-60.00
77@   -> -60.00
78@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
79@   -> -60.00->-60.00
80@   -> -60.00
81@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
82@   -> -60.00->-60.00
83@   -> -60.00
84@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
85@   -> -60.00->60.00
86@   -> -60.00
87@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
88@   -> -60.00->60.00
89@   -> -60.00
90@   -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
---
1507@ -> -60.00->60.00
1508@ -> 60.00
1509@ -> -60.00->60.00->-60.00->-60.00->-60.00->60.00->-60.00->-60.00
1510@ -> -60.00->60.00
1511@ 

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

Oops, wrong project name:

 Metacello image
project: 'Seaside3';
list

I'll send mail to you privately to exchange the image ..

Thanks,

Dale

On 02/21/2017 11:00 AM, Hilaire wrote:

Hi Dale,

Le 21/02/2017 à 18:30, Dale Henrichs a écrit :

Metacello image
 project: 'Seaside';
 list

It returns an empty list in this image.
Can you send me privately your email at hilaire [AT] drgeo.eu so I can
send you a link? (I am reading through gmane news forum and email
address is hidden)

Thanks

Hilaire

Re: [Pharo-users] Loading Seaside via Bootstrap in Pharo 6

[Dale Henrichs]

Torsten,

I don't know whether Pharo uses the latest version of Metacello from 
github when building Pharo6.0 ... historically Pharo has not used the 
latest version from github and this has been  the case for a very long 
time and I've been hoping that eventually this would be solved, but 
perhaps not?


There haven't been any bugfixes to Metacello since November, but perhaps 
they are lagging behind more than that?


Dale


On 02/21/2017 05:24 AM, Torsten Bergmann wrote:

Hi,

regarding the problem Sven mentioned on 
http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2017-February/030542.html

here are my findings:

When I use latest Pharo 6 (Image 60404) and run

   Metacello new
  smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations';
  configuration: 'Seaside3';
  version: #'release3.2';
  load

it loads the latest release 3.2 (which internally loads 3.2.1).  The package is 
"ConfigurationOfSeaside3-JohanBrichau.323.mcz"

This loads fine in Pharo 6 except that after installation the "Tools" -> "Seaside 
control panel" is not working anymore as
"NewListModel" is not found anymore. So the control panel is broken. Dont know 
what the migration path is for UI's
who used the removed "NewListModel" class.

So yes - one can (by using the above script) use Seaside but currently has to 
start the server with a script
until this is fixed. This is good to know - but does not solve the "loading from 
catalog" issue.

-

So (in a fresh image 60404) I loaded "Bootstrap" from catalog and I received 
the error Sven reported.

But ConfigurationOfBootstrap itself is not the problem I guess. Because it is 
also only referencing the
"release3.2" version of Seaside and also 
"ConfigurationOfSeaside3-JohanBrichau.323.mcz" is loaded.


The Transcript shows the following error output:

   Loaded -> ConfigurationOfSeaside3-JohanBrichau.323 --- 
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
   http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/Error: Name 
not found: Seaside-Pharo-Development

Also when you try to open the ConfigurationOfSeaside3 using Versionner I receiver an 
error "Name not found: Seaside-Pharo-Development".

So there must be something wrong with the Seaside config I thought - or (what 
would be worse) with the newer Metacello
version included in Pharo 6. At least the config looks OK and in both situations 
"ConfigurationOfSeaside3-JohanBrichau.323" is used.

Additionally I tried:

  - when I load the Bootstrap config in a fresh Pharo 5.0 image (50769) from 
Catalog all loads fine.
  - when I manipulate the Pharo 6 image to have a version 5 signature
SystemVersion newVersion: 'Pharo5.0'. SystemVersion  current inspect.
and load from catalog afterwards it also does not work. So I guess a Pharo 
5.x specific config rule could not be the cause.


Now I checked how Catalog loads the configs. And in class CatalogProject you 
will notice that for the catalog we still use Gofer for loading

installStableVersion

Gofer it
url: self repositoryUrl;
configurationOf: self name;
loadStable

when I change it to Metacello API

 installStableVersion
  Metacello new
repository: self repositoryUrl, '/',self name;
configuration: self name;
version: #'stable';
load

what a surprise: anything loads fine. I still wonder and do not know about the 
difference why Gofer and Metacello loading in Pharo 6
makes a difference now.

So we could fix it for the catalog ... still I have no glue about the 
Gofer/Metacello API difference ...

https://pharo.fogbugz.com/f/cases/19736/Catalog-should-use-Metacello-API-instead-of-Gofer-for-Configuration-installation

  
Thanks

T.

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

On 02/20/2017 09:08 AM, Hilaire wrote:

Dale,

I try out the lock feature on an archived image, the seaside uprade was
still operating :(
Hmm, do you think it would be possible to share your image with me ... 
it's bad enough that the Seaside is getting updated in a mysterious 
manner, but now that Metacello is ignoring locks that is even stranger ...


I'm imagining that Metacello is guessing wrong about which version of 
Seaside is loaded when the Metacello registry is primed (when the new 
version of Metacello is installed) ... The registry works best when it 
is used for all loads from the very beginning and that is definitely not 
the case in you situation, but there are enough odd things going on that 
I'd like to see the image for myself and at least characterize the 
problems that you are seeing


I updated this image with latest Metacello, then I locked it as:

   Metacello image
 configuration: 'Seaside3';
 version: '3.1.4.2'; "most recent 3.1.x version"
 lock.

It was the version returned by this command:
ConfigurationOfSeaside3 new project currentVersion

By the way it will make sense, and will be easily discoverable to have a
short cut as "ConfigurationOfSeaside3 currentVersion"
#currentVersion is where Metacello is making it's guesses . You can get 
the information from the registry by doing the following:


  Metacello image
project: 'Seaside';
list

I don't remember how I installeed Seaside in the first place, I think it
was from the configuration browser.


Yeah and I don't know what the configuration browser does when it loads ...

I'm hoping that you can share the image with me and I can look at it in 
detail ... The registry is supposed to eliminate all of the guess work, 
but I don't have that much experience with the conversion between the 
old and the new Metaceloo ...


I started working exclusively with the new Metacello about 4 years ago 
and have been waiting for a long time for Pharo to make the conversion 
... I am interested in trying to make it a smooth transition ...


Dale

Re: [Pharo-users] Team programming with Smalltalk

[Dale Henrichs]

On 02/20/2017 03:58 AM, Denis Kudriashov wrote:


2017-02-18 8:53 GMT+01:00 itli...@schrievkrom.de 
 >:


 Sadly this is gone or simply only badly implemented. E.g. in
Pharo you
can select a package - fine, but to know, what has been extended
in this
package ?. The name of the method categories also define in which
package this method is located in. Make a type error and the
method goes
into a different package and you will not recognize it. Solutions born
by the idea: how can we make it simple to have a solution this
evening -
and these solutions survive over the years.


It will be changed in Pharo 7 with Calypso. It already shows packages 
instead of categories with start convension.
You guys should really be thinking in terms of projects not packages 
especially for Pharo7... browse project lets you see all classes 
involved in a project, save project saves all dirty packages in project, 
diff project shows all changes for a project ... etc. etc. ...


Dale

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

On 02/19/2017 11:21 PM, Stephan Eggermont wrote:

On 19/02/17 18:50, Dale Henrichs wrote:

Hilaire,

I mentioned last night that I thought that there was a better solution
to your problem and I think that if you load the latest Metacello and
then lock Seaside3:

  Metacello image
configuration: 'Seaside3';
version: '3.1.5'; "most recent 3.1.x version"
lock.

Then load Voyage, you shouldn't have the problem with Seaside being
updated to 3.2.


Voyage needs a newer Grease, is that backwards compatible (I forgot)?


Don't know if Grease is backwards compatible or not ...

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

Hilaire,

I mentioned last night that I thought that there was a better solution 
to your problem and I think that if you load the latest Metacello and 
then lock Seaside3:


  Metacello image
configuration: 'Seaside3';
version: '3.1.5'; "most recent 3.1.x version"
lock.

Then load Voyage, you shouldn't have the problem with Seaside being 
updated to 3.2. Seaside does not support upgrade across minor version 
numbers like 3.1 to 3.2 ... if the upgrade to 3.2 was allowed, you 
wouldn't have this particular problem.


The Metacello lock command was invented so that a developer could take 
ownership of the version of the projects used in their image. It is not 
always desirable to upgrade to a later version of a project without 
extensive testing (whether or not the actual load to the new version is 
successful), so the lock command allows you to control which versions of 
projects are loaded by Metacello by overriding the choices made by other 
developers ... You can even lock versions of projects that are not yet 
loaded.


I am still curious as to my Seaside and Magritte are linked together --- 
I suspect that somehow the Magritte-Seaside package got loaded and once 
that happened you were off to the races.


Dale

[1] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking



On 2/18/17 7:32 AM, Hilaire wrote:

Dale,

May be you don't want to waste anymore time on that. Thanks for your
effort. I got a way to get Voyage installed in my development image.

Not sure what wrong, because something is wrong[1], but I got the things
installed, first update to Seaside, which break when upgrading  the
Seaside installed from the configuration browser, fix the seaside broken
installation, then install Voyage which went fine. Did not test Voyage
is working though.

Hilaire

[1]The Pharo4 configuration browser's Magritte3 is installing Seaside
update, this should NOT happen.
Now image comes with a Configuration Browser, if I understand correctly
its intend, an user is expected those configurations to work happily
together, but it looks like not, some configurations will request update
breaking package previously installed from this configuration browser.
May be it is more a policy problem on the quality of the configuration
than a tool problem, a lot can be learn from Debian packaging. For
example Debian stable is released only when quality is ok, don't know
the details but they don't like to rush for release and people complain
new stable release take too much time to emerge, the price for quality?
For me Pharo fells too fuzzy, and it makes me very sceptical for
reliability; may be not nice to write and to read but it is how I fell.
I may be biased and I don't mean bad to anyone writing this, I know how
quality is hard to achieve and Pharo teams did great endeavour in many
aspects.




Le 17/02/2017 à 22:15, Dale Henrichs a écrit :

Again, thanks for detailed info ...

The fact that you loaded Seaside3.1.x  is good enough for my purposes
.. the fact that Seaside3.2 is getting installed implies that there is a
hard dependency on Seaside in one of the projects (Magritte3 perhaps?)
... odd that ConfigurationOfSeaside3 wasn't downloaded this time around
--- Can you get the package version of ConfigurationOfSeaside3 that's in
the image after the `Metacello new` loads?... I'll have to dive into the
configurations now ...

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

On 2/18/17 7:32 AM, Hilaire wrote:

Dale,

May be you don't want to waste anymore time on that. Thanks for your
effort. I got a way to get Voyage installed in my development image.

Well I am still curious why you are having trouble ...


Not sure what wrong, because something is wrong[1], but I got the things
installed, first update to Seaside, which break when upgrading  the
Seaside installed from the configuration browser, fix the seaside broken
installation, then install Voyage which went fine. Did not test Voyage
is working though.

I am glad that you've found a formula  ... But I am still curious ...

I've looked at the configurations and I don't see anything odd ... as 
you have observed, without Seaside pre-installed Voyage/Magritte will 
not cause Seaside to get loaded ... In addition if just Seaside is 
installed, there is no reason I can see that Voyage/Magritte would cause 
Seaside to be updated ... UNLESS, Magritte-Seaside is installed.


Below you mention that Magritte3 from ConfigurationBrowser is installing 
Seaside update as well, and that would be consistent with the 
Magritte-Seaside package being loaded for some reason ...


I would be interested to see how you loaded Seaside in the first place. 
Were you loading Magritte first? I am wondering about how 
Magritte-Seaside package is getting installed ...


I have some ideas about better ways to solve your installation problem, 
but I've run out of time tonight ... I will send more mail tomorrow...


Dale

Hilaire

[1]The Pharo4 configuration browser's Magritte3 is installing Seaside
update, this should NOT happen.
Now image comes with a Configuration Browser, if I understand correctly
its intend, an user is expected those configurations to work happily
together, but it looks like not, some configurations will request update
breaking package previously installed from this configuration browser.
May be it is more a policy problem on the quality of the configuration
than a tool problem, a lot can be learn from Debian packaging. For
example Debian stable is released only when quality is ok, don't know
the details but they don't like to rush for release and people complain
new stable release take too much time to emerge, the price for quality?
For me Pharo fells too fuzzy, and it makes me very sceptical for
reliability; may be not nice to write and to read but it is how I fell.
I may be biased and I don't mean bad to anyone writing this, I know how
quality is hard to achieve and Pharo teams did great endeavour in many
aspects.




Le 17/02/2017 à 22:15, Dale Henrichs a écrit :

Again, thanks for detailed info ...

The fact that you loaded Seaside3.1.x  is good enough for my purposes
.. the fact that Seaside3.2 is getting installed implies that there is a
hard dependency on Seaside in one of the projects (Magritte3 perhaps?)
... odd that ConfigurationOfSeaside3 wasn't downloaded this time around
--- Can you get the package version of ConfigurationOfSeaside3 that's in
the image after the `Metacello new` loads?... I'll have to dive into the
configurations now ...

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

Again, thanks for detailed info ...

The fact that you loaded Seaside3.1.x  is good enough for my purposes  
.. the fact that Seaside3.2 is getting installed implies that there is a 
hard dependency on Seaside in one of the projects (Magritte3 perhaps?) 
... odd that ConfigurationOfSeaside3 wasn't downloaded this time around 
--- Can you get the package version of ConfigurationOfSeaside3 that's in 
the image after the `Metacello new` loads?... I'll have to dive into the 
configurations now ...


Dale

On 02/17/2017 12:44 PM, Hilaire wrote:

Hi Dale,

Thanks for your detailed suggestions. I follow instructions, here the
report bellow.

Installed newest Metacello, then Voyage with new style:

Metacello new
   baseline: 'Metacello';
   repository: 'github://dalehenrich/metacello-work:master/repository';
   get.
Metacello new
   baseline: 'Metacello';
   repository: 'github://dalehenrich/metacello-work:master/repository';
   onConflict: [:ex | ex allow];
   load.

"Fetch from voyage repo at github"
Metacello new
 repository: 'github://pharo-nosql/voyage/mc';
 baseline: 'Voyage';
 load: 'mongo tests'.

It still have the same error, do an upgrade of Seaside.
Enclosed is the transcript for both Metacello and Voyage install.

Seaside installed was 3.1.x. I don't know the x digit, it is not
documented in an obvious way :(

Hope it helps

Thanks

Hilaire

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

Hilaire,

Thanks for the detailed information ...

I see that you are using the old-style loading of Voyage 
(`ConfigurationOfVoyageMongo load`) ... when using this style of 
loading, Metacello has to guess about which projects are loaded and what 
version of the project is loaded. I is possible that the behavior you 
are seeing is a direct result of Metacello guessing wrong.


I recommend that you load projects using the new style based on 
`Metacello new`:


  Metacello new
configuration: 'Voyage';
version: '???';
repository: '???';
load

When using this style of loading, Metacello maintains a registry of 
loaded projects and no longer makes guesses what is loaded in the image...


From a cursory glance at the transcript output I see that version 3.2.1 
of Seaside is being loaded and there appears to be a pretty much 
wholesale upgrade of Seaside as a bunch of new package versions are 
being loaded ... Do you happen to know what version of Seaside you 
originally loaded. I assume that you have an older version of Seaside 
loaded -- perhaps even Seaside 3.1?


As to "Why is a Seaside load being triggered at all?", there is nothing 
obvious -- I am suspicious that the old-style loading is causing the 
problem, but I don't have any hard evidence, yet.


I will have to start downloading specific configuration versions to 
complete my analysis and I have limited time left before I have to run 
some errands so I might not have answers until later this afternoon.


If you want to run an experiment in the meantime, you could try using 
the new-style Metacello load, just to see what happens ... if Seaside is 
still upgraded, the Transcript output would be useful as it will give me 
additional information.


If VoyageMongo loads correctly, then you are in business:)

BTW, you should probably load the latest version of Metacello into your 
Pharo4.0 image[1] before using the new-style load.


Dale

[1] 
https://github.com/dalehenrich/metacello-work#pharo30-pharo40-and-pharo50


On 02/17/2017 10:14 AM, Hilaire wrote:

Hi Dale,

At first I was more thinking of a problem in the dependencies of Voyage,
but then it seems not as with unload Seaside, Voyage get load. It did
not help anyway becasue Seaside can't be reinstalled (Obsolete class
syndrom hit there)

Voyage is installed as:

"VoyageMongo EstebanLorenzano.47"
ConfigurationOfVoyageMongo load

The transcript output in the attached document

Thanks

Le 17/02/2017 à 18:54, Dale Henrichs a écrit :

You don't mention how you are loading Voyage. If I had the load
expression and Transcript output from the load, I'd pretty much be able
to tell pretty much what is going on.

I have a couple of theories about what could be going wrong, but without
the load expression and Transcript output, I'd only be guessing and of
course there is the possibility that you've discovered a bug in Metacello:)

If you'd like to get to the bottom of this, send me the load expression
and Transcript output and we'll go from there ...

Re: [Pharo-users] Team programming with Smalltalk

[Dale Henrichs]

On 02/15/2017 02:43 PM, horrido wrote:

In file-based word, the answer is tests and CI. What is the smalltalk way?
And please do not say "It's in the conceptual nature of programming" -- if
the scenario makes no sense in the smalltalk world (maybe you are not
supposed to have 20 people working on the same project?) please say this.

-
Well I think that being able to use git (disk based SCMS) for managing 
Smalltalk code is one step towards making it practical for large teams 
to work together ...


The major piece that I think is still missing is the ability to have a 
declarative formula/specification for the contents of an image ...


The declarative build formula/specification must be something that can 
be shared and versioned.


Today, the closest we can come to this is an ad hoc Smalltalk script and 
that really isn't a good answer


I think that some of the missing building blocks for an image-level 
declarative formula specification are covered in my "Dangerous Liaisons: 
Smalltalk, files, and git "[1] talk, but I really think that there is 
additional work that needs to be done to make it really practical for 
large teams to be able work together on large projects.


Dale

[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git

Re: [Pharo-users] Latest Voyage for Pharo4

[Dale Henrichs]

Hilaire,

You don't mention how you are loading Voyage. If I had the load 
expression and Transcript output from the load, I'd pretty much be able 
to tell pretty much what is going on.


I have a couple of theories about what could be going wrong, but without 
the load expression and Transcript output, I'd only be guessing and of 
course there is the possibility that you've discovered a bug in Metacello:)


If you'd like to get to the bottom of this, send me the load expression 
and Transcript output and we'll go from there ...


Dale

On 02/17/2017 08:56 AM, Hilaire wrote:

Trying to understand this problem:

 From my development image, I uninstalled all seaside, then I installed
Voyage. This time it went fine AND Seaside-core *was not* installed
during the process.

What the heck is going on?

When Seaside was present in my dev. image, installing Voyage make
Seaside-core to be installed/upgraded (it was marked as dirty in
Monticello, but no code change in fact) and it resulted in a broken
Seaside installation??

Is it Metacello voodoo?

Re: [Pharo-users] [Data Modeling] approaches to data persistence

[Dale Henrichs]

On 02/16/2017 11:26 AM, sergio ruiz wrote:

Funny you should mention that.

i ended up removing all the voyage stuff, and just using objects.. as 
soon as i am ready to go live, i am going to use gemstones..


is there a quick and easy setup for heroku or digital ocean?


Probably not as simple as it could be, but GsDevKit_home[1] is pretty 
easy to install (MacOs, Ubuntu, Debian, and Centos installation 
available -- other Linux-based could be added).


Paul Debruicker has provided ansible playbooks[2] for installing 
GsDevKit_home, DaemonTools (gem monitoring), NginX and a few other 
useful utilities.


You mentioned that you are using Teapot for REST. Teapot itself hasn't 
been ported to GemStone, but Zinc _has_, so I assume it would not be a 
big chore to port Teapot to GemStone ... Ping me (the GLASS list[3] is 
best) when you are getting close and I'll help where I can ...


I'm pretty jammed up for the next month or so with GemStone 3.4 work, 
but after that I'll come up for air and start greasing squeaky wheels:) 
So that will be a good time to ping me:)


Dale

[1] 
https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-gemstones-64-bit-
[2] 
https://github.com/GsDevKit/GsDevKit_ansible#administer-gemstone--nginx-on-ubuntu

[3] http://forum.world.st/mailing_list/MailingListOptions.jtp?forum=1460844

Re: [Pharo-users] [Data Modeling] approaches to data persistence

[Dale Henrichs]

Sergio,

If you find that your data set grows large enough, keep in mind that you 
can port your application to GemStone/S[1]. GemStone provides a scalable 
solution for image-based persistence while preserving smalltalkiness:)


Dale

[1] https://gemtalksystems.com/small-business/gsdevkit/

On 02/14/2017 10:13 AM, sergio ruiz wrote:

this is a GREAT answer.. a totally smalltalky answer!

i need to extend this test out to include randomly accessing a million 
records at a time…




On February 14, 2017 at 12:15:28 PM, Ben Coman (b...@openinworld.com 
) wrote:





On Wed, Feb 15, 2017 at 12:29 AM, Ben Coman > wrote:




On Tue, Feb 14, 2017 at 11:01 PM, sergio ruiz
> wrote:

Hey, all..

I have  been working on creating a REST interface using
Teapot. In learning how to handle exceptions, I have been
following along with the library example.

One of the things i noticed was that, in the library example,
they are modeling that data a little differently than i have
been..

to persist a list of items (and easily retrieve them), i just
gave the object an “id”, and store them on a class variable
as an OrderedCollection..

in the library example, I see something i really like. rather
than saving an ordered collection, they save it as a dictionary.

This dictionary goes { id -> object }.. this takes the id out
of the the object (which i really like) and makes the id
generation pretty much irrelevant..

my question.. is there any performance hit either way once
this list grows to tens of thousands of records?



I was curious, so nothing better than to experiment...

myClass := Object subclass: #AA
instanceVariableNames: 'id data'
classVariableNames: ''
package: ''.
myClass compile: 'id: i id:= i'.
myClass compile: 'data: d data:= d'.

N := 10 raisedTo: 7.
o := OrderedCollection new.
d := Dictionary new.
{ Time millisecondsToRun: [
1 to: N do: [:id| o add: (AA new id: id; data: 'blahblah')]].
Time millisecondsToRun: [
1 to: N do: [:id| d at: id put: (AA new data: 'blahblah')]].
} inspect.
o := nil.
d := nil.
Smalltalk garbageCollect.

N=5 ==> "#(5 42)"
N=6 ==> "#(434 839)"
N=7 ==> "#(5733 17208)"

Slight modification to pre-allocate space to ignore dynamic
growth cost...
o := OrderedCollection new: 2 * N.
d := Dictionary new:  2 * N.

N=5 ==> "#(7 33)"
N=6 ==> "#(411 802)"
N=7 ==> "#(5892 15141)"

cheers -ben


Lets also bench Arrays, and be a nicer with cleaning up memory...

N := 10 raisedTo: 7.
a := Array new: 2 * N.
atime := Smalltalk vm totalGCTime + (Time millisecondsToRun: [
1 to: N do: [:id| a at: id put: (AA new data: 'blahblah')]]) - 
Smalltalk vm totalGCTime.

a := nil.
Smalltalk garbageCollect.

o := OrderedCollection new: 2 * N.
otime := Smalltalk vm totalGCTime + (Time millisecondsToRun: [
1 to: N do: [:id| o add: (AA new id: id; data: 'blahblah')]]) - 
Smalltalk vm totalGCTime.

o := nil.
Smalltalk garbageCollect.

d := Dictionary new: 2 * N.
dtime := Smalltalk vm totalGCTime + (Time millisecondsToRun: [
1 to: N do: [:id| d at: id put: (AA new data: 'blahblah')]]) - 
Smalltalk vm totalGCTime.

d := nil.
Smalltalk garbageCollect.

{atime. otime. dtime} inspect.

N=5 ==> "#(2 4 13)"  "#(2 4 13)"  "#(2 5 13)"
N=6 ==> "#(30 48 131)" "#(28 48 131)" "#(29 47 128)"
N=7 ==>  "#(274 470 1313)" "#(259 456 1340)" "#(269 467 1306)"

So insertions into Dictionaries are
two to three  times slower than OrderedCollection, and
five to six times slower than Arrays.

Now this is milliseconds, so even at the 100,000 level Dictionary 
performance

may be a reasonable tradeoff for other benefits.

cheers -ben


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.Village-Buzz.com
http://www.ThoseOptimizeGuys.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

On 02/13/2017 03:28 AM, Peter Uhnák wrote:

> I do not think so but if people show me otherwise I could follow that.

Well, in most languages (their package dependencies) one can just 
specify name of the project and a version. The location/how to load it 
is pulled from a central repository.
So that's why I thought that maybe the MetaRepo could be used in a 
similar fashion.



You are correct that the MetaRepo could accomplish this using a 
ConfigurationOf (the current scheme basically does follow this model), 
but this is a bit of a hack ..


A better solution is to use a "project specification object" --- many 
other languages use their own flavor of "project specification object" 
to define the versions.


Having project specification objects means that a whole host of project 
meta data can be included in the object as first class objects without 
having to hack around with adding methods (by convention) to a 
ConfigurationOf




> In the long term the the MetaRepo should be replaced by a repository 
of project specification objects


That also seems needlessly complex; basically just ConfigurationOf 
separated to parts. I do not want to restrict the users, but with a 
central repo the most common use case shouldn't be 10 lines of 
configuration.
I don't agree that this would be needlessly complex ... the 
implementation I use with tODE leverages gh-pages on github and STON ... 
having first class objects for project specifications, means that tools 
can be built to work directly with these objects, instead of loading a 
ConfigurationOf and hoping that the expected meta data is there ...


Dale

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

Very good to hear ... I have to try to be a bit more patient :)


On 2/12/17 9:37 AM, stepharong wrote:
On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs 
<dale.henri...@gemtalksystems.com> wrote:



Peter,



In the long term the the MetaRepo should be replaced by a repository 
of project specification objects (like this [1]). Each project 
specification would contain the meta data for a project (like 
this[2]) instead of a copy of a ConfigurationOf that is almost always 
out-of-date.


Yes we are working on it.
Now 64bits, FFI, Iceberg, bootstrap got our attention.


ConfigurationOf should really be phased out -- they've been obsolete 
for 3-4 years now... BaselineOf is preferred.


If folks are using something like git/github, with proper branching, 
then a BaselineOf wouldn't be published on the master branch until 
the unit tests are passing (travis-ci).


I want more than just the tests but this is a start.





We will arrive there. Because I want it too.
Now pavel worked on the bootstrap to avoid to lose all the energy that 
guille put on it.




Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] 
https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston

On 2/12/17 4:03 AM, Peter Uhnak wrote:

Hi,

would it make sense to take configurations from metarepos instead 
directly from the source?


And more imporantly: would be considered bad practice for users to 
do it right now?


E.g.

spec
project: 'Magritte'
with: [ spec
className: #ConfigurationOfMagritte3;
versionString: #stable;
repository: 
'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].


v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions 
(combined with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've 
seen project that had copies on SS, STHub, GitHub, and a custom 
location -_-)


cons:
* the ConfigurationOf could differ between various MetaRepo versions 
(if the code is compatible, then two repos have to be updated


Any thoughts?

Peter

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

Peter,



In the long term the the MetaRepo should be replaced by a repository of 
project specification objects (like this [1]). Each project 
specification would contain the meta data for a project (like this[2]) 
instead of a copy of a ConfigurationOf that is almost always out-of-date.


ConfigurationOf should really be phased out -- they've been obsolete for 
3-4 years now... BaselineOf is preferred.


If folks are using something like git/github, with proper branching, 
then a BaselineOf wouldn't be published on the master branch until the 
unit tests are passing (travis-ci).




Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston
On 2/12/17 4:03 AM, Peter Uhnak wrote:

Hi,

would it make sense to take configurations from metarepos instead directly from 
the source?

And more imporantly: would be considered bad practice for users to do it right 
now?

E.g.

spec
project: 'Magritte'
with: [ spec
className: #ConfigurationOfMagritte3;
versionString: #stable;
repository: 
'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ].

v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'


pros:
* the (e.g. Magritte) developer can freely change platforms
* the ConfigurationOf could differ between various MetaRepo versions (combined 
with git it could reduce their complexity)
* users do not have to think about where is the canonical repo (I've seen 
project that had copies on SS, STHub, GitHub, and a custom location -_-)

cons:
* the ConfigurationOf could differ between various MetaRepo versions (if the 
code is compatible, then two repos have to be updated

Any thoughts?

Peter

Re: [Pharo-users] About Git

[Dale Henrichs]

I gave a talk at Smalltalks 2016 entitled: "Dangerous Liaisons: 
Smalltalk, files, and git"[1] and this thread is a perfect example the 
dangers I was thinking about:).


For "history buffs", here's a link for my talk at STIC 2012 entitled 
"Practical Git for Smalltalk"[2].


Dale

[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git

[2] https://www.youtube.com/watch?v=ZIkoBQphtyM


On 1/15/17 8:44 AM, Dimitris Chloupis wrote:
For those that lost track of the purpose of this thread let me provide 
a summary


The discussion started from the Google Visibility where Sven asked me 
why I find the Pharo VCS and Monticello a very problematic implementation


I decided to reply creating a separate thread in order to not hijack 
the other thread


I did reply with precise details what I do not like and what I 
consider bad design for both Pharo VCS and Monticello


I decided not to further the debate because it was clear that Sven 
agreed with my remarks its just he did not find them as a show stopper 
like I do. It was never my intention to debate personal opinion only 
facts.


I have no regrets that I started this discussion, it was a discussion 
I wanted to start ages ago and at the time I did not feel I was 
experienced enough to pass a judgement on the Pharo VCS.


But I was perplexed for some time why I found and still find Pharo VCS 
as a deeply flawed system with many problems that have been annoying 
me since the first day I started using Pharo while there seem to not 
be any serious complaint from the community.


I think now its clear that this happens because:

a) Some people indeed find Pharo VCS easier to use and have little 
interest for the advanced features of Git and Github


b) Other people do not like Git because they have not invested the 
time to learn it and have a very distorted idea of what Git is and how 
it actually works or how non Pharo coders actually use it (for example 
the claim that Git is not good for local repos while this is exactly 
the primary goal of the existence of Git and where it truly shines)


c) For some strange reason people who tried Git or still use it 
partially appear to not use GUI Git client even though Pharo VCS is 
clearly a Graphical  and not a command line based UI.


On the other hand I am glad people love Pharo so much and appreciate 
even more things about it than I do.


On a final note I did not make this thread to complain or bash Pharo 
VCSs mainly because using Git from Pharo never had be an issue for me 
and I have nothing to complain about the whole process apart from the 
fact that I do not like how filetree brakes source code into source 
code files but that is a minor annoyance.


Thank you all for your participation and your opinions its great to 
see another point of view and keep having fun with Pharo VCSs.

Re: [Pharo-users] Unscheduled outage for http://ss3.gemtalksystems.com/ and http://seaside.gemtalksystems.com/ss

[Dale Henrichs]

sites are back on-line ...


On 12/17/16 9:09 AM, Dale Henrichs wrote:
The colo where the hardware is located had announced scheduled 
maintenance for our cluster, but there was not supposed to be any 
downtime ... we are looking into the problem


Dale

[Pharo-users] Unscheduled outage for http://ss3.gemtalksystems.com/ and http://seaside.gemtalksystems.com/ss

[Dale Henrichs]

The colo where the hardware is located had announced scheduled 
maintenance for our cluster, but there was not supposed to be any 
downtime ... we are looking into the problem


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/8/16 11:04 PM, Igor Stasenko wrote:



On 7 November 2016 at 14:28, stepharo > wrote:



[ ... ]


And this one I don't understand. A smooth, git / iceberg oriented
transition over Monticello/Metacello is perfectly doable... As
Dale explained. A nice Iceberg gui reworking / making git usable
is perfect.

But why make the transition so hard? You get Stef angry on a
Sunday morning because he can't find things anymore... even if he
is a strong proponent of the strategy he complains about ;)


No my point was not that.
My point is that it is important to pay attention and not to add
more noise than necessary. Let us take the time and move alltogether.

If you want to get somewhere with this story, you don't want to wait 
till everything will be ready.
Transition will never start unless you force users to enter the 
minefield and let them clear the mines for you. Step by step. Many 
will blow themselves up, while some will manage to pass unhurt..
Because else, it will be always a minefield between you and the 
destination of your journey :)
I think that at the early stages of the transition you have to support 
both approaches ... when the new tools are in place and stabilized then 
one can consider ... the transition has already started so this is not a 
case where you need to force folks to change, but a case where you need 
to support the folks who choose to change ... it can be relatively low 
cost to keep the old tools around for quite awhile ... I would think ...


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/8/16 7:09 AM, Thierry Goubier wrote:

Hi Dale,

2016-11-08 2:03 GMT+01:00 Dale Henrichs 
<dale.henri...@gemtalksystems.com 
<mailto:dale.henri...@gemtalksystems.com>>:


[ snip ... ]


yes I think this is the area where a Metallo Project Browser comes
into play. The technology for committing the dirty packages in a a
ConfigurationOf has been around for quite awhile, but a tool that
unifies the "multi-package" commit for ConfigurationOf and
BaselineOf hasn't popped out of the wood work ...


I'm having some issues with the scripting approach of Metacello, for 
that. Just manipulating a baseline in the Metacello registry (locking 
it) seems to be like writing a compiler code generation item: write a 
Metacello script ;) (Metacello>>#lock contains interesting code).
I think I agree:) ... that is why i am talking about a tool ... 
developers shouldn't have to pass around workspaces to load and 
manipulate projects .. a project tool can partially automate the 
process, but I believe that there needs to be a "load spec" object that 
can be passed around and massaged by code instead of requiring a user to 
edit a Smalltalk workspace ... it's what I do in tODE ... the only times 
I have to write Smalltalk load scripts is when I work in Pharo :)


I will repeat that I don't think Pharo should do exactly what I've done 
with tODE, but a Metacello Project Browser and some sort of "load spec" 
object that is shared amongst a cluster of images is something that 
needs to be seriously considered ...





What is a bit annoying, really, is this talk of rewriting
everything where some of the pieces (the project browsing you're
talkin about, for example) is already there in the image, just
not exposed.

Well I am annoyed as well .. I would say that perhaps we are in
screaming agreement ... I've said that I don't think it's a lot of
work to do the project-centric tool. but a project-centric tool
that encompasses both ConfigurationOf and BaselineOf will expose
the features that "are already there"


I'm trying to code a little something for that... stay tuned for
a screenshot soon.

Cool:)


And here it is! I'm still fighting with the Metacello lock / unlock thing.

Images intégrées 1

If Pharo was more really modular in configurations and baselines, then 
I would see more things into the registry and I could group packages 
based on that (instead of having to prepare a ad-hoc classification 
for my my browser).
Yes this is headed in the right direction ... I am in Argentina this 
week so it isn't easy for me to do much collaboration, but I would love 
to help you with your lock problem next week ... For example ... you do 
not want to directly expose the Metacello registry as there are "hybrid 
projects" where a ConfigurationOf causes a BaselineOf to be loaded, so 
the BaselineOf needs to take precedence (I have code for resolving this) 
and I strongly suggest that the Project Browser not be built-into the 
Class Browser, but be a separate tool like the CataLogBrowser ... but 
this is just a suggestion --- a separate tool dedicated only to loaded 
Projects and unloaded Projects of interest allows one to get a very 
quick overview of what is in the project or not and when version skew 
pops up, one can easily see the affected projects ... embedding this 
kind of information in the code browser can make it hard to get the 
overview and if you choose to live with version skew can be annoying to 
ignore  again these are just my thoughts ..


Regardless I think you are definitely headed in the right direction and 
it isn't all that much work ... yet:)


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 11:42 AM, Nicolas Passerini wrote:


2016-11-07 15:30 GMT+01:00 Thierry Goubier >:


Thierry, If I'm not mistaken, Esteban is referring to the fact
that in FileTree we are still using Monticello to do the load
of the packages and even when we are running metadataless, we
end creating fake meta data to simulate an mcz ... you and I
have had conversations about ways to eliminate this
"requirement" because it is meaningless in a git context ...


Yes, this I understood. I do believe that what I suggested at one
point (have the ability to compare versions with an
'isAncestorOf') would be very nice for that transition (work in
mcz as well as on git with/without metadata).


I would like to listen to your ideas about this topic, but I am not 
sure it is possible to achieve that compatibility. In fact we tried to 
do it for Iceberg and at some point we decided to abort it.


On one side, trying to re-create monticello sequential file numbers in 
git is simply not possible, at least in a reliable way. On the other 
side, loading the graph of package versions and dependencies is really 
slow for big repositories (such as pharo-core), once we removed that 
requirement Iceberg got like 100x faster.
I agree that the git-oriented tools should not go ot of their may to 
conform to the MC model .. as you say it just does not fit ... but many 
of the standard operations that are performed can be performed on both 
git and mcz repositories without forcing both of the models to share 
identical implementations ... in image tools should distinguish between 
mcz and git projects and dispatch the standard operations to the 
appropriate repository --- and this si the spot where the handling 
changes based upon the repository model ...


Dale

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 11:30 AM, Thierry Goubier wrote:

Hi Dale,

2016-11-07 12:03 GMT+01:00 Dale Henrichs 
<dale.henri...@gemtalksystems.com 
<mailto:dale.henri...@gemtalksystems.com>>:




On 11/7/16 7:15 AM, Thierry Goubier wrote:



2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com
<mailto:esteba...@gmail.com>>:



On 7 Nov 2016, at 10:03, Thierry Goubier
<thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>> wrote:

Hi Esteban,

I cut out the rest, because I agree with all your points,
except for...

2016-11-07 9:55 GMT+01:00 Esteban Lorenzano
<esteba...@gmail.com <mailto:esteba...@gmail.com>>:

[ ... ]

Replacing Monticello with git goes in this direction:

[ ... ]


And this one I don't understand. A smooth, git / iceberg
oriented transition over Monticello/Metacello is perfectly
doable... As Dale explained. A nice Iceberg gui reworking /
making git usable is perfect.


Well… I disagree with this.
All my experience says the opposite: this is a convenience
usage that in the long way does not match (the thing that we
simulate mcz packages do not work… and makes things a lot
harder to maintain later).
Nico has worked a lot on this, maybe he has something to say.


I'd like to. Simulating mcz? That I don't get it.

Thierry, If I'm not mistaken, Esteban is referring to the fact
that in FileTree we are still using Monticello to do the load of
the packages and even when we are running metadataless, we end
creating fake meta data to simulate an mcz ... you and I have had
conversations about ways to eliminate this "requirement" because
it is meaningless in a git context ...


Yes, this I understood. I do believe that what I suggested at one 
point (have the ability to compare versions with an 'isAncestorOf') 
would be very nice for that transition (work in mcz as well as on git 
with/without metadata).
II think that the work that you did with gitfiletree was very 
influential in making git a realistic option for the Pharo community and 
I think that the choices you made were excellent, but I think that for a 
transition it is important that git be presented as itself more fully 
and expose some of the features that set git apart 
(project/package/class/method diffs; multi-package commits; etc.) ... 
but I also feel that Monticello does not need to be diluted --- the 
existing Monticello tools should remain in place for the forseeable 
future ...



With the work that Richard Sargent did on the
CypressReferenceImplementation, I would prefer to say that Cypress
can provide an Alternative to Monticello rather than replace it
... the CypressReferenceImplementation includes a package loader
so it isn't necessary to convert Filetree format on disk to Mcz
format in the image --- without all of the ancestry, "latest
version stuff" and package-cache the loading process becomes much,
much simpler...

I think that both Monticello and Cypress can live together in the
image ...


For me, MC is also the code / diff model behind: will Cypress rewrites 
all that too?
Well Cypress is not that much of a rewrite ... Cypress definitions are 
closely based upon the Monticello definition model... snapshots and 
loading based on comparing the snapshot of the repository against the 
snapshot of the image are also closely based on Monticello ... The 
differences are in the fact that Cypress packages do not have ancestry, 
author names or version numbers:

  - the ancestry and author is recorded and managed by git (or svn or hg)
  - there is only one version of a package in a fieltree repo, so there 
is no

 need to sort packages by version number to fine the "latest version"

So Cypress is more of a "take all of the really good parts of Monticello 
while dropping the bits that are handled better  by git" than it is a 
complete _rewrite_ ...



I have created a version of Metacello that uses Monticello OR
Cypress and I expect to eventually (in the next several months ---
it doesn't take that long, but I've got other things on my plate)
to have a version of Metacello that uses Monticello AND/OR Cypress
again I think that smooth transitions (that may take a long time)
are better supported in this fashion than to draw a line in the
sand and force the usage of one OR the other ...


As long as Cypress behaves as a MC repository and fits into the same 
API, I really don't see where is the difficulty. As we are saying now, 
adding a type of repository / emulating the MC overall API is no real 
difficulty in itself and isolates one from all the project management 
issues (because that means Metacello, ConfigurationOf and BaselineOf 
just keep

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 7:36 AM, Esteban Lorenzano wrote:

On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henri...@gemtalksystems.com> wrote:



On 11/7/16 4:52 AM, Esteban Lorenzano wrote:

btw this is pharo-dev discussion, redirecting there.

Esteban


On 7 Nov 2016, at 08:50, Esteban Lorenzano <esteba...@gmail.com> wrote:

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?

The main unifying tool is a Metacello Project Browser (or something like the 
tODE project list).

You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... 
but you know that already:) but once you load a Project into the image with the 
CatalogBrowser it sort of disappears ...

There needs to be a way to see the _projects_ are loaded in the image ... right 
now you can see the package loaded into the image, and you can see the dirty 
packages, but the package is at too low a level

 From the project browser you should be able to commit a project --- which 
saves all of the dirty packages in the project --- in one commit for a git 
project --- all of the dirty packages written in one operation for mcz packages 
...

This project browser can provide the same set of services for an mcz project 
(ConfigurationOf) or a filetree project (BaselineOf):
  - save
  - load-- this is a bit more complicated to explain (I tried at 
the Metacello Dr. talk, but more discussion is needed)
  - diff  -- project level diff over a collection of packages
  - commit log -- For ConfigurationOf, list the commit history of the 
Configuration.
For a BaselineOf list the commit log for the git 
repository

The workflow at the project level is not that different between Mcz and 
Filetree, so it is straightforward to work with …

this is what is provided by iceberg… it still needs some work, but this is 
precisely what is supposed to do :)
(and btw, this is why I disagree with Thierry some mails below).
Well, I don't think that Iceberg is doing package loads and I don't 
think that Iceberg will provide support for mcz repositories so I still 
think there is a need for this Metacello Project Browser ... the 
Metacello Project Browser would delegate to Iceberg for all of the 
services that it does provide.


The Metacello Project Browser would not be a purely git/github tool ... 
Metacello Projects are repository format neutral so svn, hg, etc. would 
be equally supported from the Metacello Project Browser ... the standard 
set of operations: save/load/diff/log are needed for all different 
repository types ...


I don't think it's a lot of work to implement the Metacello Project 
Browser tool and it is important that there be one place to look for and 
manage the projects loaded in image  this is the "unifying" bit ...



The unification comes because you can use one metaphor (project) to work with 
both Mcz and Filetree ... the underlying implementation will ultimately...

The next layer of unified tools is when you look at version history, for a 
method, you need to provide the ability to view the git commit history for the 
method (if stored in git) or the image history ... git commit hisotry can be 
provided at the project/package/class/method ... whereever possible the 
equivalent mcz/git service should be provided so that the two systems are on an 
even par …

also, this is supposed to be provided by iceberg.


The Monticello Browser and Iceberg GUI's don't go away, because it is often 
necessary to do work at the package level, but I think that putting focus on 
the project is the key ingredient to success for integrating git …

Iceberg is not package-oriented. It just show 
repositories/packages/classes/methods… this is a good way to do it and I do not 
thing anything is lost like this.
You need to take a second look at Iceberg :)
Well I am specifically referring to this issue[1] and this comment by 
Guille[2] and Nico[3]. If Iceberg isn't going to load packages, then you 
need a tool that will load a package ...


and as I say above this tool must work with ConfigurationOf and 
BaselineOf for svn, hg, etc. repositories ...


[1] https://github.com/npasserini/iceberg/issues/184
[2] https://github.com/npasserini/iceberg/issues/184#issuecomment-254139549
[3] https://github.com/npasserini/iceberg/issues/184#issuecomment-257865003



Since git repos are persistent on disk and will be shared ... it is important 
that there be a way for developers to easily access the git repos for projects 
that have been cloned locally but not yet loaded in the image itself ... I am 
really struggling with getting how important this point as this is the also a 
point that ties a Catalog Browser and Project Browser together

this is something to think… I do not get what catalog browser  can do here (but 
yes, a way to browse local repositories needs to be provided).
again in tODE, the Metacello Project Browser (aka project list) allows

Re: [Pharo-users] about balkanisation

[Dale Henrichs]

On 11/7/16 7:15 AM, Thierry Goubier wrote:



2016-11-07 11:05 GMT+01:00 Esteban Lorenzano >:




On 7 Nov 2016, at 10:03, Thierry Goubier
> wrote:

Hi Esteban,

I cut out the rest, because I agree with all your points, except
for...

2016-11-07 9:55 GMT+01:00 Esteban Lorenzano >:

[ ... ]

Replacing Monticello with git goes in this direction:

[ ... ]


And this one I don't understand. A smooth, git / iceberg oriented
transition over Monticello/Metacello is perfectly doable... As
Dale explained. A nice Iceberg gui reworking / making git usable
is perfect.


Well… I disagree with this.
All my experience says the opposite: this is a convenience usage
that in the long way does not match (the thing that we simulate
mcz packages do not work… and makes things a lot harder to
maintain later).
Nico has worked a lot on this, maybe he has something to say.


I'd like to. Simulating mcz? That I don't get it.
Thierry, If I'm not mistaken, Esteban is referring to the fact that in 
FileTree we are still using Monticello to do the load of the packages 
and even when we are running metadataless, we end creating fake meta 
data to simulate an mcz ... you and I have had conversations about ways 
to eliminate this "requirement" because it is meaningless in a git 
context ...


With the work that Richard Sargent did on the 
CypressReferenceImplementation, I would prefer to say that Cypress can 
provide an Alternative to Monticello rather than replace it ... the 
CypressReferenceImplementation includes a package loader so it isn't 
necessary to convert Filetree format on disk to Mcz format in the image 
--- without all of the ancestry, "latest version stuff" and 
package-cache the loading process becomes much, much simpler...


I think that both Monticello and Cypress can live together in the image ...

I have created a version of Metacello that uses Monticello OR Cypress 
and I expect to eventually (in the next several months --- it doesn't 
take that long, but I've got other things on my plate) to have a version 
of Metacello that uses Monticello AND/OR Cypress again I think that 
smooth transitions (that may take a long time) are better supported in 
this fashion than to draw a line in the sand and force the usage of one 
OR the other ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 6:42 AM, Norbert Hartl wrote:

Am 07.11.2016 um 10:40 schrieb Dale Henrichs <dale.henri...@gemtalksystems.com>:



On 11/7/16 2:59 AM, Tudor Girba wrote:

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?

You're not the only one :) Yes it would ... Monday is a travel day so Tuesday 
or beyond would work for me …


Would it make sense to make that a group conversation?

I don't mind, but I do have to say that I am struggling in communicated 
some of the "simple concepts" ... My talk last Wednesday was my first 
attempt and I don't think I did a good job of communicating about some 
of the more complicated tasks that come up like: load specs, 
clone/lock/rehome, sharing local clones across multiple images, private 
image clones, etc. ...


My inclination is to have a focused conversation with Doru to help me 
express the key concepts ... then a more public discussion with another 
straw man where we put the ideas out again ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 4:52 AM, Esteban Lorenzano wrote:

btw this is pharo-dev discussion, redirecting there.

Esteban


On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?
The main unifying tool is a Metacello Project Browser (or something like 
the tODE project list).


You have a nice tool with the CatalogBrowser (modulo BaselineOf support) 
... but you know that already:) but once you load a Project into the 
image with the CatalogBrowser it sort of disappears ...


There needs to be a way to see the _projects_ are loaded in the image 
... right now you can see the package loaded into the image, and you can 
see the dirty packages, but the package is at too low a level


From the project browser you should be able to commit a project --- 
which saves all of the dirty packages in the project --- in one commit 
for a git project --- all of the dirty packages written in one operation 
for mcz packages ...


This project browser can provide the same set of services for an mcz 
project (ConfigurationOf) or a filetree project (BaselineOf):

  - save
  - load-- this is a bit more complicated to explain (I 
tried at the Metacello Dr. talk, but more discussion is needed)

  - diff  -- project level diff over a collection of packages
  - commit log -- For ConfigurationOf, list the commit history of the 
Configuration.
For a BaselineOf list the commit log for 
the git repository


The workflow at the project level is not that different between Mcz and 
Filetree, so it is straightforward to work with ...


The unification comes because you can use one metaphor (project) to work 
with both Mcz and Filetree ... the underlying implementation will 
ultimately...


The next layer of unified tools is when you look at version history, for 
a method, you need to provide the ability to view the git commit history 
for the method (if stored in git) or the image history ... git commit 
hisotry can be provided at the project/package/class/method ... 
whereever possible the equivalent mcz/git service should be provided so 
that the two systems are on an even par ...


The Monticello Browser and Iceberg GUI's don't go away, because it is 
often necessary to do work at the package level, but I think that 
putting focus on the project is the key ingredient to success for 
integrating git ...


Since git repos are persistent on disk and will be shared ... it is 
important that there be a way for developers to easily access the git 
repos for projects that have been cloned locally but not yet loaded in 
the image itself ... I am really struggling with getting how important 
this point as this is the also a point that ties a Catalog Browser and 
Project Browser together


I've been using this approach for several years now and once you have 
the tools and can see at a glance what's "going on in your image" it is 
fun to work in a mixed environment ... all of this frustration that is 
bubbling on the list is largely due to not having these missing tools 
and underlying support --- I think ...


I have followed very close your TOdE development… in a moment I was planning a 
migration of it for pure-pharo, just… lack of time as always and then later we 
started iceberg.
Yes, I have intended to do a port of tODE to Pharo, but of time is the 
killer :)

now, we are in the process of defining a process ;) who works for pharo and is the 
moment to build the bridges we need, but in general I think that staying "with 
a foot in two boats” can just work during a very short lapse of time, after that, 
the stream continues going and if you do not finish your jump into one of the boats 
you will be very fast in the water.
Yes but the two boat environment will last years ... it has taken almost 
5 years for filetree to start to be used regularly ... and with the 
Metacello Project Browser approach the transition will not be nearly as 
painful, besides I think that the project-centric tools set is required 
when work with git


What I mean is that we can help any transition, but at the end there is no way 
of having a “nice, coexisting” ecosystem: we will have one OR the other, or 
something that does not works at all, but we will not have seamlessly one AND 
the other (which does not means people using monticello will be forced to use 
git tools or vice-versa, just that you will need to chose one… right now many 
(many for real) of our problems come from the attempt of keeping our git 
support behaving as regular monticello…
As I say, I think that monticello/filetree can be abstracted away at the 
Metacello Project Browser level ... a commit of dirty packages writes 
all the dirty packages for the project in the appropriate repository ... 
BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take 
a whole lot of code to smoothly handle both projects --- as I've said, 

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/7/16 2:59 AM, Tudor Girba wrote:

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?
You're not the only one :) Yes it would ... Monday is a travel day so 
Tuesday or beyond would work for me ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 1:12 PM, Tudor Girba wrote:

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.
Doru, there are also holes in the tool set that are not being addressed 
... there are a number of critical tools that need to be created and I 
don't see anyone working on them 


I went through this transition 5 years ago with my tool set and with the 
proper set of tools approach the difficult transition will be a bit 
easier ...


As it stands Pharo is standing with one foot in two boats ... there are 
the old Monticello tools and the new Git/Filetree tools and what is 
needed is a tool or two that can unify to both tool sets so that the 
transition between the two can be seamless ... these two sets of tools 
are not complicated and there working implementations that can be 
adapted to Pharo or used as a fairly detailed guide ...


The confusion and frustration that I see now is not a surprise to me ... 
I wrote" the emails" at the beginning of this year because I saw that 
Pharo was finally reaching a critical point in its move to integrate git 
into the mainstream development environment and I knew that these types 
of issues were going to come up where Monticello and Git were going to 
create friction --- friction that can be reduced by creating some simple 
"unifying tools" ...


I want to help, I have tried to help and I am still willing to help, but 
I cannot write the tools for Pharo ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 9:05 AM, stepharo wrote:

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(
Stef, I have been working with git/monticello projects for about 5 years 
now and have been using a "mixed system" during that entire time ... My 
message has been consistent that in order to make a smooth transition 
that you need some specific tools, now the fact that you guys are _not_ 
building those tools has been concerning me for some time now ... I sent 
mails at the beginning of this year a) describing the tools to the best 
of my ability and b) offering to help ... it seems that you are somehow 
blaming git/github for this problem ... and as I come to this discussion 
late others are blaming smalltalkhub ...


I don't think it is necessary to move everything to github, as I said, I 
have been using a "mixed system" for 5 years ... and I think that the 
problem lies in the lack of the proper tools ... of course your problems 
with Bloc may be actually totally unrelated to packages, but it is clear 
to me that you are frustrated with the environment ... and that is a 
tools problem!


I can and want to help.

I have had good discussions with the Pharo team, but I am afraid that I 
am not able to get my ... to me ... simple points across ... and it is 
frustrating to me that I am not able to successfully communicate the 
simple solutions that I see ...


I will repeat that Pharo is missing some very critical tools that I 
consider to be absolutely required (in some form) to be able to be 
successful ... the required tools do not take a phd to implement, they 
are very straightforward and simple ... perhaps they are not sexy and 
complicated so noone is interested, but they are required ...


If you want to have a conversation about this I am willing ... now it 
happens that I am in Buenos Aires (soon to be Tucuman) so this week is 
not convenient for me to talk ...


If you don't want to talk to me then look at the series of messages that 
I wrote last winter/spring to this mailing list (or pharo dev) where I 
described what I think you guys are missing ... and then ask me 
questions ...


Dale

Re: [Pharo-users] Keeping data with an application

[Dale Henrichs]

Sergio,

I like the play around part:) Ping me when you find the time!

Dale

On 11/02/2016 07:21 AM, sergio ruiz wrote:


For this project, I want to make progress based on feedback from 
users ... there are lots of different directions that could be taken 
from this starting point and I want to be driven by user feedback ... 
so if you are willing to provide feedback I am willing to work with 
you ...




i think that for my current project, I want to move REALLY quickly. so 
it might not be a good fit, but i would totally like to play around 
with it under different use cases.





peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.Village-Buzz.com
http://www.ThoseOptimizeGuys.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Re: [Pharo-users] Keeping data with an application

[Dale Henrichs]

On 11/1/16 12:28 PM, sergio ruiz wrote:

Okay.. is Voyage ready to rock and/or roll?
Voyage is definitely ready to rock and roll ... Voyage/Tugrik is ready 
to be rocked ... it is functional and passes the tests (on Pharo5.0).


For this project, I want to make progress based on feedback from users 
... there are lots of different directions that could be taken from this 
starting point and I want to be driven by user feedback ... so if you 
are willing to provide feedback I am willing to work with you ...


The only change that I think I need to make is to improve the session 
pool logic ... it works fine, but the session boundary is not quite at 
right level to make the best use of GemStone sessions ...


With "direct access" to the server objects via Voyage Server Blocks I 
think that query api provided by MongoTalk may not be that interesting, 
but this is the kind of information I am looking for from users ...


If MongoTalk _is_ interesting then you should know that I did not try to 
fill out the full MongoDB query language, yet ... I implemented the 
features excercised by tests, so if you hit something that you you find 
lacking then I will plug the gap ... it is relatively straight forward 
to implement the MongoDB query language (except for the bits that rely 
directly on the javascript language:) so it shouldn't take too long to 
fill in holes:)


is today your birthday? for some reason, i got a notification of 
several things on my machine today.. one of those being your birthday..


if so, happy birthday!

Tomorrow is my birthday, thanks:)


if not.. happy un-birthday!



Dale

Re: [Pharo-users] Keeping data with an application

[Dale Henrichs]

Sergio,

You might take a look at the talk I gave on Voyage/Tugrik at 
ESUG(slides[1], video[2]). The project is in a functional, but roughed 
out stage --- but the main idea behind it is that with GemStone as the 
db serve, you are dealing with Smalltalk objects on both the client and 
server ...  Voyage Server Blocks allow you to write code on the client 
that is executed against objects on the server ... STON is used for 
serialization/materialization ... Voyage Server Blocks let you blur the 
lines as to where do the objects live and where does the code execute ...


Currently Tugrik uses MongoTalk as the model for Voyage-style 
interactions between client and server, but Voyage Server Blocks (which 
are not a feature of MongoTalk) may be useful on their own ...


In the talk, I mention that I am looking for partners in pushing 
Voyage/Tugrik forward, because I think that real users with real 
problems are needed to drive the project forward --- I am more 
interested in meeting real developer needs, than building something that 
makes me happy:)


MongoTalk was originally chosen to make it practical for folks already 
using Voyage/Mongo to easily kick the tires on Voyage/Tugrik, but I 
don't think that it is necessary to stay coupled to MongoTalk. Michal 
Balda is looking at something "simpler than Tugrik+MongoTalk+Voyage" and 
I wish that I could be in Zurich to see his presentation next week[3]:) 
as I want to support his efforts ...


Dale

[1] http://www.slideshare.net/esug/tugrik-a-new-persistence-option-for-pharo

[2] https://www.youtube.com/watch?v=YwlUdRaqTwE=youtu.be

[3] 
http://forum.world.st/ANN-Zurich-Smalltalk-Meetup-Nov-8th-2016-tt4919147.html


On 11/01/2016 08:54 AM, sergio ruiz wrote:

Hey, all..

One of the things that I find SUPER necessary when developing an app 
is to be able to grab data from somewhere else and quickly and easily 
work on it from my machine.


For instance, when I get a bug report that smells funny, the first 
thing i sometimes do is run a script that grabs the production data, 
and populates my local database with that data.


i am fleshing out a project that i would really like to use Teapot 
(REST) for. i could then write several front ends in whatever 
framework/language.


I was thinking about using Voyager, but the problem is, the data is 
VERY relational (see below, if interested).. objects are linked to 
each other fairly tightly. I don’t know if this would be the way to 
handle the data, as there would be lots of duplication using mongodb 
as a datastore.


Of course, my first thought is Gemstones, but I don’t know how to grab 
the production data and pull it into my local development system.


Does anyone have any thoughts on this?

For those curious about the data design, i am setting up a REST server 
for an collaborative internet radio application…


- there would be a global pool of stations (just streaming urls with 
metadata, really)

- each user can select from or contribute to the global pool
- users can add tags to stations (or search through the global 
stations based on tags)

- users can attach comments to stations

not complex or intimidating at all, and super easy to model in 
smalltalk, but not sure about how to store data so that I can quickly 
grab production data and troubleshoot if if necessary.


Thanks!



peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.Village-Buzz.com
http://www.ThoseOptimizeGuys.com
http://www.coffee-black.com
http://www.painlessfrugality.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Re: [Pharo-users] SubModules and SubTrees? ..... Was ----> OSProcess missing from Pharo 6 image

[Dale Henrichs]

Guille that would be great ... I am in the process of writing the 
presentation but would make time to talk with you ... lets arrange to 
skype or discord sometime next week ...


Dale


On 10/28/16 7:53 AM, Guille Polito wrote:
I'm not going to smalltalks, but maybe we can do an skype (or a public 
discord) any time soon?


 Original Message 



On 10/28/16 6:05 AM, Guille Polito wrote:



Also, we are starting to see how to move Pharo sources to git, and 
this means we are looking at how we should design Pharo's repository 
so we can smoothly collaborate and synchronize repositories using 
pull requests. For example, these two last week I took some hours to 
evaluate and exercise myself with git subtrees and submodules.  The 
notes I made from this are here:


https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-project-storage-alternatives 



What I mean, adding a package inside the image can bring also a lot 
of problems to package maintainers, so doing it just because "others 
do it" is not a good argument.

Guille,

I looked at trying to use submodules with a project or two back when 
I first started working with git and github[1] -- 5 years ago now.


It seems that using submodules introduces a very tight coupling 
between the individual projects and it was more of a pain than it was 
worth ...


Using Metacello locks and independent clones has worked very well, 
but some structure is needed ...


I spent several years "splashing around" trying to figure out a 
structure for GsDevKit/GLASS and finally settled on the structure in 
GsDevKit_home[2] (about 2 years ago) and the structure there is 
working quite well ...


I am giving a talk at the upcoming Smalltalks where I will be 
describing my thoughts on this structure/organization in detail.


I am certainly willing to share my experience with you guys and maybe 
save you a couple of years of "splashing around" --- if you are 
interested.


Dale

[1] https://github.com/dalehenrich/amber-skeleton
[2] https://github.com/GsDevKit/GsDevKit_home

[Pharo-users] SubModules and SubTrees? ..... Was ----> OSProcess missing from Pharo 6 image

[Dale Henrichs]

On 10/28/16 6:05 AM, Guille Polito wrote:



Also, we are starting to see how to move Pharo sources to git, and 
this means we are looking at how we should design Pharo's repository 
so we can smoothly collaborate and synchronize repositories using pull 
requests. For example, these two last week I took some hours to 
evaluate and exercise myself with git subtrees and submodules.  The 
notes I made from this are here:


https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-project-storage-alternatives

What I mean, adding a package inside the image can bring also a lot of 
problems to package maintainers, so doing it just because "others do 
it" is not a good argument.

Guille,

I looked at trying to use submodules with a project or two back when I 
first started working with git and github[1] -- 5 years ago now.


It seems that using submodules introduces a very tight coupling between 
the individual projects and it was more of a pain than it was worth ...


Using Metacello locks and independent clones has worked very well, but 
some structure is needed ...


I spent several years "splashing around" trying to figure out a 
structure for GsDevKit/GLASS and finally settled on the structure in 
GsDevKit_home[2] (about 2 years ago) and the structure there is working 
quite well ...


I am giving a talk at the upcoming Smalltalks where I will be describing 
my thoughts on this structure/organization in detail.


I am certainly willing to share my experience with you guys and maybe 
save you a couple of years of "splashing around" --- if you are interested.


Dale

[1] https://github.com/dalehenrich/amber-skeleton
[2] https://github.com/GsDevKit/GsDevKit_home

Re: [Pharo-users] How to add a dependency in a baseline

[Dale Henrichs]

On 10/23/2016 11:08 AM, Dimitris Chloupis wrote:


Curious question: let say that the spec configuration in first code 
fragment fails to load for various reason, is there a way for 
metacello to detect the fail and add something to the baseline , let 
say the stable version of pillar, so if it sees that the development 
version of pillar fails to load it falls back to loading the stable 
version instead ?


Essentially I am asking here about metacello exceptions.


Dimitris,

I haven't done any work with respect to dynamically changing the project 
version that is loaded with the exception of lock handling.


If you look at the subclasses of MetacelloScriptNotification and 
MetacelloProjectSpecScriptNotification you will see the notifications 
that are used to implement the fundamentals of lock handling and I 
suppose that it would be possible to build a MetacelloScriptEngine that 
gave a developer some explicit control over project spec lookup, but 
doing so in response to unspecified load errors could be a bit dicey ...


Presumably, one could write an error handler that caught load errors and 
then manipulated the project locks to do something like you are 
suggesting ...


Dale

Re: [Pharo-users] How to add a dependency in a baseline

[Dale Henrichs]

Dimitris,

This is your baseline method and I'm not sure what you consider "an ugly 
hack":


  baseline: spec
  
  spec for: #'pharo' do: [
spec
package: 'Octopus' with: [ spec requires: #('Pillar') ];
configuration: 'Pillar' with: [
  spec
repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main';
version: #'development' ] ]

Is it the fact that you have to include #development instead of #stable 
in your baseline? If so , you can make a pre-load decision to use the 
development version of Pillar by using a Metacello lock:


  Metacello new
configuration: 'Pillar'
version: #development;
repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main';
lock.

Then you can change your baseline back to using #stable or whatever and 
when you load the Octopus project, using 'Metacello new', the 
#development version should be used ...


Or is there something else that you consider "an ugly hack"?

Dale

On 10/23/16 6:46 AM, Dimitris Chloupis wrote:
I have a baseline in my github repo for a tool I am making and I have 
included the pillar development dependency via an ugly hack , whats it 
the proper way of doing this ?


https://github.com/kilon/Octopus/blob/master/BaselineOfOctopus.package/BaselineOfOctopus.class/instance/baseline..st

Re: [Pharo-users] Other format to Filetree

[Dale Henrichs]

This is a good suggestion ... along these lines I've always thought that 
it would make a lot of sense to write a SmalltalkBrowser for Github in 
Amber of PHaroJS that would read Filetree package structure and display 
it the "right way" ... For extra credit one could even edit code in the 
browser:)


And of course, the SmalltalkBrowser shouldn't be limited to just GitHub ...

I wish that I had the spare cycles to do this:)

Dale


On 10/21/16 6:06 PM, Charlie Robbats wrote:


I'd like to suggest you teach people Smalltalk natively, so they don't 
get distracted by the false view of a filetree of classes. One huge 
differentiator of Smalltalk, from any other language out there,  is 
the live object environment. You should use that environment to teach 
from or the nuance will be lost and they may well give up. Consider, 
is there any Java IDE that allows any expression anywhere to be 
evaluated and inspected with a mouse click or shortcut? So host your 
mcz on github but provide an install doc to have them install Pharo 
and load your code, for the lessons. They will look at Smalltalk code 
naturally in Pharo browsers and be exposed to an IDE they have never 
before experienced, as well. In the process you can webinar your 
navigations that they can follow along. Nebraska around? Those who 
consider it worthy will stay. Keep doing what you are doing!


Charlie


On 10/21/2016 8:51 PM, Vitor Medina Cruz wrote:
Thank you for the answers! Actually my question has a rather silly 
reason: I find it difficult to navigate and peek at code in the 
current format. I would like to show ST code to other people through 
GitHub — it is pretty common for me to discuss implementations of 
katas, for example, from multiple platforms only looking at the 
GitHub project —, but the format get in the way. People usually give 
up of looking it because it is hard to navigate through the directory 
tree and understand all the separate pieces as a whole, and so I must 
explain my solution verbally and people get suspicious of ST and 
unwilling to try the environment for the first time. :(


I think I am going to commit a fileout of the project, maybe people 
will find easier to peek at. Do you have other suggestion?


Thanks!
Vitor

On Fri, Oct 21, 2016 at 4:36 PM, Dimitris Chloupis 
> wrote:


Do you have something specific in your mind ?

What are your needs and desires for an alternate Filetree format
? What you want to see changed in Filetreee ?


On Fri, Oct 21, 2016 at 7:02 PM Vitor Medina Cruz
> wrote:

Hello,

I was wondering: is there another format available for Filetree?

Regards,
Vitor

Re: [Pharo-users] How do I debug a MNU in Pharo-6.0

[Dale Henrichs]

Ben,

Thanks for the responses ... I've just tried it again using a freshly 
downloaded Pharo6.0 (60265) and using filetree instead of gitfiletree on 
my mac (my earlier attempt was using on older Pharo6.0 on Linux) --- so 
I had installed gitfiletree into the linux image at some point apparently...


Anyway on the mac, the informs stayed visible long enough for me to grab 
one and here is the message that I'm getting now:


  OmFileStoreWritingError: this store is locked

Oh and I did get a debugger on the mac so I'm in business ...

I tried the linux test again with the same older version of Pharo 
(60208) using filetree:// instead of gitfiletree:// and got the same 
result (no debugger), but running over x from home, the informs did not 
disappear so quickly and here is the message:


  Ombu: Couldn't write entry, since MessageNotUnderstood: receiver of 
"ifTrue:ifFalse:" is nil


I just downloaded 60265 for linux and tried again using filetree:// and 
got a debugger and a slew of informs with the message:


  OmFileStoreWritingError: this store is locked

S, the problem appears to be fixed in the latest Pharo6.0 with the 
exception of the flood of OmFileStoreWritingError messages...


I did try catching Error, but that didn't work either ... the inform: 
was swallowing the error without doing a pass --- perhaps that was the 
fix...


Anyway, thanks for your time and I appreciate your help,

Dale

On 10/20/16 3:03 AM, Ben Coman wrote:

On Thu, Oct 20, 2016 at 5:06 PM, Ben Coman <b...@openinworld.com> wrote:

On Thu, Oct 20, 2016 at 6:35 AM, Dale Henrichs
<dale.henri...@gemtalksystems.com> wrote:

I am trying to debug a problem that showed up loading my version of STON
into Pharo-6.0. ON Travis, I see the error message[1]:

   MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil

The code is loading and passing tests in Pharo-5.0, 4.0, 3.0 and several
versions of GemStone, so I am interested in bringing up a debugger...

I cloned g...@github.com:GsDevKit/ston.git and checked out the gs_port branch
into the directory
/export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston.

But when I run the following code in a Pharo-6.0 image using the Playground
by pressing the green arrow:

   Metacello new
 baseline: 'Ston';
 repository:
'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository';
 load: #( 'UTF8' 'Tests')

I do not get the expected MNU in a debugger -- but I do see a bunch of infos
popping up during the execution but they fade too quickly for me to actually
read them --- there were 8 or more popups --- and I got the impression that
they involved the ifTrue:ifFalse:, but danged if I know how to debug the
problem ...

Alternatively, maybe put a haltOnce in each of the six implementors of #inform:

cheers -ben


I must have missed the memo that tells me how to get a debugger up in
Pharo-6.0 ...

Maybe from commandline try...
[ Metacello new
 baseline: 'Ston';
 repository:
'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository';
 load: #( 'UTF8' 'Tests')
] on: Error do: [ :err | err debug ].

(If I try it myself in Pharo 6 I get ZnUnknownScheme.  I guess I need
to load gitfiletree separately)

cheers -ben

Re: [Pharo-users] How do I debug a MNU in Pharo-6.0

[Dale Henrichs]

It looks like some "Failed magic" is involved here. A bit of the stack 
for your viewing pleasure:


MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil
UndefinedObject(Object)>>doesNotUnderstand: #ifTrue:ifFalse:
STONWriter>>ExecuteUnOptimizedIn:
UndefinedObject(Object)>>mustBeBooleanInMagic:
UndefinedObject(Object)>>mustBeBoolean
STONWriter>>encodeString:

Perhaps this is a Pharo6.0 bug -- triggered by my bug in 
STONWriter>>encodeString:


Travis is running headless and presumably the 
error/notification/exception handling is a bit different running headless?


Dale

On 10/19/2016 03:35 PM, Dale Henrichs wrote:


I am trying to debug a problem that showed up loading my version of 
STON into Pharo-6.0. ON Travis, I see the error message[1]:


MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil

The code is loading and passing tests in Pharo-5.0, 4.0, 3.0 and 
several versions of GemStone, so I am interested in bringing up a 
debugger...


I cloned g...@github.com:GsDevKit/ston.git and checked out the gs_port 
branch into the directory 
/export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston.


But when I run the following code in a Pharo-6.0 image using the 
Playground by pressing the green arrow:


  Metacello new
baseline: 'Ston';
repository: 
'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository';

load: #( 'UTF8' 'Tests')

I do not get the expected MNU in a debugger -- but I do see a bunch of 
infos popping up during the execution but they fade too quickly for me 
to actually read them --- there were 8 or more popups --- and I got 
the impression that they involved the ifTrue:ifFalse:, but danged if I 
know how to debug the problem ...


I must have missed the memo that tells me how to get a debugger up in 
Pharo-6.0 ...


Any advice?

Dale

[1] https://travis-ci.org/GsDevKit/ston/jobs/169029017#L435