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

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] 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] 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]

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 
<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] 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] 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] Using a private git repository with Metacello

[Dale Henrichs]

Julien,

I recently added bitbucket:// support to metacello[1].

If you follow the installation instructions here[2], you can get the
support loaded into Pharo3.0.

Dale

[1] https://groups.google.com/forum/#!topic/metacello/0vOzvQL10cQ
[2] https://github.com/dalehenrich/metacello-work#pharo30

On Wed, Oct 8, 2014 at 1:44 AM, Julien Delplanque  wrote:

> Hello,
>
> Is it possible to use Metacello to load a Pharo project from a private
> git repository hosted on bitbucket for example? If it is, how?
>
> To load project from github I use:
>
> Metacello new
> baseline: 'Project';
> repository: 'github://owner/reponame/repository';
> load.
>
> Is there a prefix for a git repository that is not hosted on github?
>
> Also, I think Metacello use HTTP to download the project, am I right? Is
> it possible to make it use ssh?
>
> Thanks in advance,
>
> Julien
>
>

Re: [Pharo-users] Fwd: REST server helpers for Seaside 3.1 ?

[Dale Henrichs]

Cameron,

The Seaside REST classes do work with GemStone and there is JSON support
built-into Seaside 3.1

Dale

On Tue, Oct 28, 2014 at 5:20 PM, stepharo  wrote:

> Hi cameron
>
> I'm in the US so I will reply a bit and after other people will certainly
> complement.
>
>> Hi All.
>>
>> We need to set up a REST server for certain services and I am wondering
>> what helper classes exist that work with Seaside 3.1.
>>
> with Seaside-Rest you get REST support.
>
>> Additionally, do they work on gemstone?
>>
> I do not know but I would not see why it would not.
>
>> Also, what support tools/frameworks would you recommend for JSON I/O?
>>
> NeoJSON from sven
> There is a chapter in the PharoForTheEntreprise book
>
>>
>> Thanks in advance,
>> Cam
>>
>>
>>
>>
>
>

Re: [Pharo-users] Metacello configuration based on subdirectory of Git repo

[Dale Henrichs]

Rafael,

To get to a git repository use a filetree repository and point to a local
clone of the repo.  I've editted your baseline accordingly:

baseline01: spec

spec
for: #common
do: [
spec blessing: #baseline.
spec repository:
'filetree://full-filesystempath-to-your-pharo-subdirectory'.
spec
package: 'MyPackage'.
. . . ]

If you hafve a project on github or bitbucket you can reference the
repository directly (readonly) with the following url:


github://github_username/github_projectname:branch_SHA_tag/path_to_subdirctory

for bitbucket, you just use bitbucket: instead.

Dale

On Thu, Nov 13, 2014 at 9:21 AM, Rafael Luque 
wrote:

> Hi all,
>
> I'm starting with Pharo and playing with the ways to integrate it with Git.
>
> I've read the "Git and Pharo" chapter on "Enterprise Pharo" book by
> Thierry Goubier and loaded the GitFileTree package.
>
> I'm working on a project with several microservices, one of them will be
> based on Pharo and the other ones in other technologies. The project
> repository is based in our own Git server and each microservice maps with
> one subdirectory in the repo.
>
> My question is if it is possible to define a Metacello configuration to
> load my packages from an specific subdirectory of a Git repository. I have
> tried with the following baseline method, but it fails because does not
> understand repoPath:
>
> baseline01: spec
> 
> spec
> for: #common
> do: [
> spec blessing: #baseline.
> spec repository: 'git@my-git-server:my-project'.
> spec repoPath: 'my-pharo-subdirectory'.
> spec
> package: 'MyPackage'.
> . . . ]
>
> Thank you in advance.
>
>

Re: [Pharo-users] Metacello configuration based on subdirectory of Git repo

[Dale Henrichs]

Rafael,

It looks like in your case that you've got a configuration problem ... and
here's the proper fix (but depending upon which vesion of Metacello you're
using may or may not work):

baseline01: spec

spec
for: #common
do: [
spec blessing: #baseline.
spec repository: 'filetree://full-filesystempath-to-your-pharo-subdirectory
'.
spec
configuration: 'Stamp'
with: [
spec
repository: 'http://smalltalkhub.com/mc/SvenVanCaekenberghe/Stamp/main';
loads: 'Stamp';
version: #stable ].
spec
package: 'MyStompMessaging' with: [ spec requires: #('Stamp') ] ]

if you get an error then the following should work:

baseline01: spec

spec
for: #common
do: [
spec blessing: #baseline.
spec repository: 'filetree://full-filesystempath-to-your-pharo-subdirectory
'.
spec
project: 'Stamp-Core'
with: [
spec
className:
'ConfigurationOfStamp';
repository: 'http://smalltalkhub.com/mc/SvenVanCaekenberghe/Stamp/main';
loads: 'Stamp';
version: #stable ].
spec
package: 'MyStompMessaging' with: [ spec requires: #('Stamp-Core') ] ]

I've also submitted a metacello bug[1] to cover this issue, although I may
have already fixed the bug in a later version of Metacello, I'm going to
double check wihen I get a chance...

Finally, I would be interested to know what errors or warnings you might
get from validating your configuration (inspect the result of
MetacelloToolBox class>>validateConfiguration: with your configuration
class as an argument).

HTH,

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/313


On Thu, Nov 13, 2014 at 12:28 PM, Rafael Luque  wrote:

> Thank you for the responses.
>
> I'll try both of them, but in the meantime I found another problem because
> of my lack of experience.
>
> I'm trying to define in the baseline a dependency with another project, in
> particular the Stamp project by Sven Van Caekenberghe [1] in Smalltalkhub
> in the following way:
>
> baseline01: spec
> 
> spec
> for: #common
> do: [
> spec blessing: #baseline.
> spec repository: 'filetree://full-filesystempath-to-your-pharo-
> subdirectory'.
> spec
> project: 'Stamp-Core'
> with: [
> spec
> repository: 'http://smalltalkhub.com/mc/SvenVanCaekenberghe/Stamp/main';
> loads: 'Stamp';
> version: #stable ].
> spec
> package: 'MyStompMessaging' with: [ spec requires: #('Stamp-Core') ] ]
>
>
> When I evaluate the following in a Workspace:
>
> (ConfigurationOfMyPackage project version: '0.1') load.
>
> I get the followin error:
>
> MessageNotUnderstood: receiver of "ensureLoadUsing:" is nil
>
> In the debugger I see that MetacelloMCProjectSpec>>projectPackage is nil.
>
> In an old thread I found that Dale Henrichs suggests to try this:
>
>   MetacelloProjectRegistration
> resetRegistry;
> primeRegistryFromImage
>
> But in my case It does not solve the problem.
>
>
> Thank you in advance.
>
>
> [1] http://smalltalkhub.com/#!/~SvenVanCaekenberghe/Stamp/packages/Stamp
> [2]
> http://forum.world.st/Sample-metacello-configuration-referencing-a-github-project-td4671054.html
>
> 2014-11-13 19:07 GMT+01:00 Thierry Goubier :
>
>> Le 13/11/2014 18:21, Rafael Luque a écrit :
>>
>>> Hi all,
>>>
>>> I'm starting with Pharo and playing with the ways to integrate it with
>>> Git.
>>>
>>> I've read the "Git and Pharo" chapter on "Enterprise Pharo" book by
>>> Thierry Goubier and loaded the GitFileTree package.
>>>
>>> I'm working on a project with several microservices, one of them will be
>>> based on Pharo and the other ones in other technologies. The project
>>> repository is based in our own Git server and each microservice maps
>>> with one subdirectory in the repo.
>>>
>>> My question is if it is possible to define a Metacello configuration to
>>> load my packages from an specific subdirectory of a Git repository. I
>>> have tried with the following baseline method, but it fails because does
>>> not understand repoPath:
>>>
>>
>> Yes, it is possible to fix a specific subdirectory, with a gitfiletree:
>> url, via a dir=aRelativePath.
>>
>> baseline01: spec
>> 
>> spec
>> for: #common
>> do: [
>>  spec blessing: #baseline.
>>  spec repository: 'gitfiletree://my-git-server/my-project&dir=my-pharo-
>> subdirectory'.
>>  spec
>>package: 'MyPackage'.
>>   . . . ]
>>
>> You can have a look at the ConfigurationOfAltBrowser in the configuration
>> browser to see how it triggers downloading the GitFileTree support.
>>
>> Thierry
>>
>>
>>  baseline01: spec
>>> 
>>> spec
>>> for: #common
>>> do: [
>>> spec blessing: #baseline.
>>> spec repository: 'git@my-git-server:my-project'.
>>>  spec repoPath: 'my-pharo-subdirectory'.
>>> spec
>>> package: 'MyPackage'.
>>>  . . . ]
>>>
>>> Thank you in advance.
>>>
>>>
>>
>>
>

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

With classic Metacello (using the `(ConfigurationOfxxx project version: 
'xxx') load` pattern) you can only downgrade via an explicit load of a 
particular version of the project. When loading projects indirectly via 
a project reference from another project Metacello is biased towards 
upgrade.


With the Metacello Scripting API[1], you may include an 
#onDowngradeUseIncoming: clause to selectively permit downgrades:


  Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

For additional downgrade options see[2].

Since you are interested in using a specific version of a project you 
may also be interested in locking the project[3][4]. With a `lock` 
Metacello will not upgrade or downgrade the project but always `honor` 
the lock unless an #onLock: clause is used ...


Note that for `locking` to work, you must use the Metacello Scripting 
API to do all of your project loads ...


Dale

[1] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#metacello-user-guide
[2] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#downgrade
[3] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
[4] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-command-reference


On 12/19/2014 07:44 AM, Usman Bhatti wrote:

Hi all,

I am trying to load a specific version of PetitParser in a Moose 
image. A Moose image comes with the latest development version of 
PetitParser. So, I am trying to downgrade to an older version. So, 
when I load the version manually, older versions of the packages are 
loaded:

(ConfigurationOfPetitParser project version: '1.51') load

But when I try to load the same version within my ConfigOf the 
expected packages are not loaded and list of the PetitParser packages 
loaded remains unchanged. Here is how my baseline looks like:


ConfigurationOfDummyParser>>baseline01: spec


spec for: #'common' do: [
spec blessing: #'baseline'.
spec project: 'PetitParser' with: [
spec
className: #ConfigurationOfPetitParser;
versionString: '1.51';
repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/' ]. ].

I also tried creating a version but it didn't help.

ConfigurationOfDummyParser>>version10: spec


spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.0'.
spec author: 'usmanbhatti'.
spec timestamp: '12/19/2014 16:35'.
spec project: 'PetitParser' with: '1.51'. ].

I also had a look at the package the configuration tries to load and 
the list shows correct packages to be loaded (see screenshot).


Does anyone have an idea what may be problematic in my code or that of 
Metacello? I am attaching the code of my ConfigOf for a Moose image.


Thanks in advance.

UsmanInline image 1

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

It is likely that Pharo3.0 is not using the latest version of Metacello. 
You should be able to upgrade to the latest versions following the 
install instructions for Pharo3.0[1].


Dale

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

On 1/2/15 6:23 AM, Usman Bhatti wrote:

Dale,

Thanks for your detailed explanations.

Metacello class in my image does not seem to define the messages 
described in the documentation for handling downgrading and upgrading 
conflicts:

https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#downgrade

I am using Pharo 3.0 with Moose.

Inline image 1

Did I miss something?

regards,
Usman

On Fri, Dec 19, 2014 at 7:00 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Usman,

With classic Metacello (using the `(ConfigurationOfxxx project
version: 'xxx') load` pattern) you can only downgrade via an
explicit load of a particular version of the project. When loading
projects indirectly via a project reference from another project
Metacello is biased towards upgrade.

With the Metacello Scripting API[1], you may include an
#onDowngradeUseIncoming: clause to selectively permit downgrades:

  Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

For additional downgrade options see[2].

Since you are interested in using a specific version of a project
you may also be interested in locking the project[3][4]. With a
`lock` Metacello will not upgrade or downgrade the project but
always `honor` the lock unless an #onLock: clause is used ...

Note that for `locking` to work, you must use the Metacello
Scripting API to do all of your project loads ...

Dale

[1]

https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#metacello-user-guide
[2]

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

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

https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-command-reference



On 12/19/2014 07:44 AM, Usman Bhatti wrote:

Hi all,

I am trying to load a specific version of PetitParser in a Moose
image. A Moose image comes with the latest development version of
PetitParser. So, I am trying to downgrade to an older version.
So, when I load the version manually, older versions of the
packages are loaded:
(ConfigurationOfPetitParser project version: '1.51') load

But when I try to load the same version within my ConfigOf the
expected packages are not loaded and list of the PetitParser
packages loaded remains unchanged. Here is how my baseline looks
like:

ConfigurationOfDummyParser>>baseline01: spec


spec for: #'common' do: [
spec blessing: #'baseline'.
spec project: 'PetitParser' with: [
spec
className: #ConfigurationOfPetitParser;
versionString: '1.51';
repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/'
]. ].

I also tried creating a version but it didn't help.

ConfigurationOfDummyParser>>version10: spec


spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.0'.
spec author: 'usmanbhatti'.
spec timestamp: '12/19/2014 16:35'.
spec project: 'PetitParser' with: '1.51'. ].

I also had a look at the package the configuration tries to load
and the list shows correct packages to be loaded (see screenshot).

Does anyone have an idea what may be problematic in my code or
that of Metacello? I am attaching the code of my ConfigOf for a
Moose image.

Thanks in advance.

UsmanInline image 1

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

On 1/6/15 7:16 AM, Usman Bhatti wrote:

Dale,

I couldn't make it work with the upgraded Metacello and the script you 
provided.


Steps I did:

1. Download moose image:
https://ci.inria.fr/moose/job/moose-5.0/

2. Update my Metacello to the 'full' version:
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

3. File in the ConfigurationOfDummyParser (see the first message in 
the thread).


4.  Run this script to downgrade to PetitParser version 1.51

Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

The desired version is still not loaded, am I missing something here?
Good question, I don't have a lot of time today to spend time trying to 
reproduce your problem, but if you send me a copy of the Transcript 
produced while doing the load I might be able to spot the problem ...


regards,

A question: I always use Metacello with ConfigOf and have never used 
the scripting API myself or saw it being used elsewhere.
Can you provide a link that describes the use cases for both: ConfigOf 
vs. Scripting API?

I've noticed the same thing:)

My "elevator pitch" for the script api goes like this:
  1. The scripting api maintains a registry of the actual project 
versions loaded into the image,
  making #currentVersion obsolete. #currentVersion is bad because 
it does a calculation of
  the current version that can be very slow and sometimes 
completely incorrect.
   2. The old api has rules that it follows when loading projects 
(i.e., newer projects always win) and
   there is no mechanism for altering those rules. The scripting 
api provides mechanisms for
   for bending those rules to fit your needs ... like allowing a 
downgrade of a project.


Part of the reason that people haven't changed has to do with how 
incredibly difficult it is to change the existing inertia. Another part 
of it is that I continue to support the old way of doing things, so 
there is no explicit motivation to change.


If you look back 2-3 years in the archives of the Metacello mailing 
list[1] you should be able to find a number of posts where I make a more 
detailed cases for the scripting api:)


At the end of the day, it isn't important to me to "get people to use 
the scripting api," as I said, I continue to support using the old api. 
I figure that when enough people start asking questions about how to 
"bend the Metacello rules" that folks will begin to use the "new" 
scripting api:)


Dale
[1] https://groups.google.com/forum/#!forum/metacello

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

No, I appreciate your patience:) If creating your own configuration 
works for you then that is a good route to go...


Sharing your image will make it much easier for me to get the bottom of 
this (on my own schedule:), so please send me a link for accessing your 
image and I'll dig into this in more detail when I have time ...


If you find yourself stuck and needing the `downgrade directive` again, 
I'll bump up the priority ...


Dale

On 01/07/2015 09:19 AM, Usman Bhatti wrote:



On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:



On 1/6/15 7:16 AM, Usman Bhatti wrote:

Dale,

I couldn't make it work with the upgraded Metacello and the
script you provided.

Steps I did:

1. Download moose image:
https://ci.inria.fr/moose/job/moose-5.0/

2. Update my Metacello to the 'full' version:
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

3. File in the ConfigurationOfDummyParser (see the first message
in the thread).

4.  Run this script to downgrade to PetitParser version 1.51

Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

The desired version is still not loaded, am I missing something here?

Good question, I don't have a lot of time today to spend time
trying to reproduce your problem, but if you send me a copy of the
Transcript produced while doing the load I might be able to spot
the problem ...


It looks to me that the downgrade command is not working. Whenever I 
point to the version preceding the one loaded, the packages are not 
fetched.


I am attaching here two files.

The first (Transcript-PP151) is the output of the transcript as you 
asked. You can see that PetitParser packages as defined by the version 
1.51 are not fetched. All that is loaded is Glamour because the 
version 1.51 of PetitParser loads the latest packages of Glamour. The 
load works because it is an upgrade from the current version of 
Glamour which is a stable.


When I saw that only Glamour packages are loaded, I thought of testing 
Glamour downgrade too to see if the problem is specific to 
PetitParser. You can see the result in the second file 
(Transcript-downgrade-glamour). No packages of Glamour are fetched 
because the configuration tries to downgrade it (stable is more recent 
than 3.0.0 which I try to load).


In my opinion, downgrade is not working as required. If you want I can 
share my image thru dropbox so that you can have a look to see what 
might be wrong.





regards,

A question: I always use Metacello with ConfigOf and have never
used the scripting API myself or saw it being used elsewhere.
Can you provide a link that describes the use cases for both:
ConfigOf vs. Scripting API?

I've noticed the same thing:)

My "elevator pitch" for the script api goes like this:
  1. The scripting api maintains a registry of the actual project
versions loaded into the image,
  making #currentVersion obsolete. #currentVersion is bad
because it does a calculation of
  the current version that can be very slow and sometimes
completely incorrect.
   2. The old api has rules that it follows when loading projects
(i.e., newer projects always win) and
   there is no mechanism for altering those rules. The
scripting api provides mechanisms for
   for bending those rules to fit your needs ... like allowing
a downgrade of a project.

Part of the reason that people haven't changed has to do with how
incredibly difficult it is to change the existing inertia. Another
part of it is that I continue to support the old way of doing
things, so there is no explicit motivation to change.

If you look back 2-3 years in the archives of the Metacello
mailing list[1] you should be able to find a number of posts where
I make a more detailed cases for the scripting api:)

At the end of the day, it isn't important to me to "get people to
use the scripting api," as I said, I continue to support using the
old api. I figure that when enough people start asking questions
about how to "bend the Metacello rules" that folks will begin to
use the "new" scripting api:)


So, what I learn is that I am trying to bend the rules of Metacello 
which is a rare use case :). I am thinking of avoiding this 
downgrading altogether by forking to create my own Config

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

Thanks for supplying the image ... with that I could diagnose the 
problem. In the final analysis, the onDowngrade: feature just does not 
work[1]. I haven't had a `downgrade` use case in my own work flow, so I 
did not notice that it wasn't working and the test cases that I do have 
are obviously faulty.


Along the way, I discovered that in the Moose image, there is a custom 
MetacelloPlatform class installed (GTMetacelloPlatform) that is not 
compatible with the Scripting API. With that class installed, the 
scripting API will not work. I was able to install the proper platform 
class myself, but it requires manual intervention ...


Also, it turns out the PetitParser 1.10 is the version that is installed 
and your new version 1.51 is not technically a downgrade ... I think 
that the version needs to be named 1.5.1 to be a downgrade ... I changed 
that as well and that's when I was able determine that onDowngrade: 
wasn't functioning correctly.


Basically, the code said "go ahead and downgrade" but when it came time 
to actually load the packages, Metacello went ahead with it's standard 
algorithm of only loading newer versions of each package.


I plan to take a crack at fixing this bug this weekend ... and will let 
you when I have a fix.


Dale

[1] https://github.com/dalehenrich/metacello-work/issues/317

On 1/8/15 12:32 AM, Usman Bhatti wrote:



On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Usman,

No, I appreciate your patience:) If creating your own
configuration works for you then that is a good route to go...


Sharing your image will make it much easier for me to get the
bottom of this (on my own schedule:), so please send me a link for
accessing your image and I'll dig into this in more detail when I
have time ...


Here is the image.
https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip

You just need to execute the script in the workspace/playground to 
reproduce the problem (i.e. launching the directive to load PP 1.51 
and that not happening).



If you find yourself stuck and needing the `downgrade directive`
again, I'll bump up the priority ...


I can still wait till next week. If you could have a look by then, 
it'll be great.

tx.
Usman



Dale


On 01/07/2015 09:19 AM, Usman Bhatti wrote:



On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:


On 1/6/15 7:16 AM, Usman Bhatti wrote:

Dale,

I couldn't make it work with the upgraded Metacello and the
script you provided.

Steps I did:

1. Download moose image:
https://ci.inria.fr/moose/job/moose-5.0/

2. Update my Metacello to the 'full' version:
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

3. File in the ConfigurationOfDummyParser (see the first
message in the thread).

4.  Run this script to downgrade to PetitParser version 1.51

Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

The desired version is still not loaded, am I missing
something here?

Good question, I don't have a lot of time today to spend time
trying to reproduce your problem, but if you send me a copy
of the Transcript produced while doing the load I might be
able to spot the problem ...


It looks to me that the downgrade command is not working.
Whenever I point to the version preceding the one loaded, the
packages are not fetched.

I am attaching here two files.

The first (Transcript-PP151) is the output of the transcript as
you asked. You can see that PetitParser packages as defined by
the version 1.51 are not fetched. All that is loaded is Glamour
because the version 1.51 of PetitParser loads the latest packages
of Glamour. The load works because it is an upgrade from the
current version of Glamour which is a stable.

When I saw that only Glamour packages are loaded, I thought of
testing Glamour downgrade too to see if the problem is specific
to PetitParser. You can see the result in the second file
(Transcript-downgrade-glamour). No packages of Glamour are
fetched because the configuration tries to downgrade it (stable
is more recent than 3.0.0 which I try to load).

In my opinion, do

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

Usman,

Well I don't have an official bugfix yet, but if you filein the attached 
method and run the following, PetitParser will downgrade and get loaded 
correctly (at least it worked for me)...The fist two statements are 
intended to replace GTMetacelloPlatform with MetacelloPharo30Platform 
and initialize the registry correctly ... not sure what impact on Moose 
these changes will have) :


MetacelloPharo30Platform initialize.
  [
  MetacelloProjectRegistration
resetRegistry;
primeRegistryFromImage ]
on: Warning
do: [ :ex |
  Transcript
cr;
show: 'Warning resumed: ' , ex description.
  ex resume ].
Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngrade: [:ex :existing :new |
existing projectName = 'PetitParser'
ifTrue: [
new projectSpec operator: #=.
ex allow ]
ifFalse: [ ex disallow ] ]  ;
load.

The new method will be part of the next Metacello release and has been 
tested[1], but I may take a slightly different approach with the 
official bugfix. Setting the operator achieves the desired result, but 
is not quite how I would like to address the issue.


HTH,

Dale

[1] https://travis-ci.org/dalehenrich/metacello-work/builds/46640819
On 1/8/15 12:32 AM, Usman Bhatti wrote:



On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Usman,

No, I appreciate your patience:) If creating your own
configuration works for you then that is a good route to go...


Sharing your image will make it much easier for me to get the
bottom of this (on my own schedule:), so please send me a link for
accessing your image and I'll dig into this in more detail when I
have time ...


Here is the image.
https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip

You just need to execute the script in the workspace/playground to 
reproduce the problem (i.e. launching the directive to load PP 1.51 
and that not happening).



If you find yourself stuck and needing the `downgrade directive`
again, I'll bump up the priority ...


I can still wait till next week. If you could have a look by then, 
it'll be great.

tx.
Usman



Dale


On 01/07/2015 09:19 AM, Usman Bhatti wrote:



On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:


On 1/6/15 7:16 AM, Usman Bhatti wrote:

Dale,

I couldn't make it work with the upgraded Metacello and the
script you provided.

Steps I did:

1. Download moose image:
https://ci.inria.fr/moose/job/moose-5.0/

2. Update my Metacello to the 'full' version:
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

3. File in the ConfigurationOfDummyParser (see the first
message in the thread).

4.  Run this script to downgrade to PetitParser version 1.51

Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngradeUseIncoming: #('PetitParser');
load.

The desired version is still not loaded, am I missing
something here?

Good question, I don't have a lot of time today to spend time
trying to reproduce your problem, but if you send me a copy
of the Transcript produced while doing the load I might be
able to spot the problem ...


It looks to me that the downgrade command is not working.
Whenever I point to the version preceding the one loaded, the
packages are not fetched.

I am attaching here two files.

The first (Transcript-PP151) is the output of the transcript as
you asked. You can see that PetitParser packages as defined by
the version 1.51 are not fetched. All that is loaded is Glamour
because the version 1.51 of PetitParser loads the latest packages
of Glamour. The load works because it is an upgrade from the
current version of Glamour which is a stable.

When I saw that only Glamour packages are loaded, I thought of
testing Glamour downgrade too to see if the problem is specific
to PetitParser. You can see the result in the second file
(Transcript-downgrade-glamour). No packages of Glamour are
fetched because the configuration tries to downgrade it (stable
is more recent than 3.0.0 which I try to load).

In my opinion, downgrade is not 

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

[Dale Henrichs]

On 1/12/15 1:43 AM, Usman Bhatti wrote:



On Sun, Jan 11, 2015 at 7:14 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Usman,

Well I don't have an official bugfix yet, but if you filein the
attached method and run the following, PetitParser will downgrade
and get loaded correctly (at least it worked for me)...The fist
two statements are intended to replace GTMetacelloPlatform with
MetacelloPharo30Platform and initialize the registry correctly ...
not sure what impact on Moose these changes will have) :


MetacelloPharo30Platform initialize.
  [
  MetacelloProjectRegistration
resetRegistry;
primeRegistryFromImage ]
on: Warning
do: [ :ex |
  Transcript
cr;
show: 'Warning resumed: ' , ex description.
  ex resume ].
Metacello new
configuration: 'DummyParser';
version: '1.0';
repository: '???';
onDowngrade: [:ex :existing :new |
existing projectName = 'PetitParser'
ifTrue: [
new projectSpec operator: #=.
ex allow ]
ifFalse: [ ex disallow ] ]  ;
load.


I tried this script as you told but it didn't load the specific 
version I was expecting. I had this message printed on Transcript:


Warning resumed: Warning: Error finding current version of 
ConfigurationOfMoose. Probably an invalid specification.
Warning resumed: Warning: Error finding current version of 
ConfigurationOfSmallDude. Probably an invalid specification.

Loading 1.0 of ConfigurationOfDummyParser...
Project: PetitParser 1.51
...finished 1.0

I can wait until you do an official release for this bug fix. In the 
meantime, I've created a configOf my own which means I can find 
alternate solutions to replace downgrade. I felt that downgrade is yet 
a must because one would not like to upgrade all the time. And one 
would not like to load packages by hand when configOf is complex. My 
configOf works currently but with downgrade available it'll be much 
more cleaner.


Ah ... sorry ... I had made one other change and forgot to mention 
that:( I did rename the version to 1.5.1 both in petitparser and dummy ...


Ah well, you are functional and you have certainly helped me, so I 
appreciate your help ... My first cut at a fix solves the downgrade but 
introduces other issues, so I still working things out:)


Thanks again!

Dale

Re: [Pharo-users] Hijacking a Configuration for loading a Github Baseline

[Dale Henrichs]

Kilon,

One more point that you might find useful ... If you use tags (i.e., 
v1.0.0, v1.0.1, v1.1.0), you can specify tag wildcards  in the branch 
field of the github repository description.


Using Thierry's example the following resolves the latest commit on the 
master branch (bleeding edge):


  github://ThierryGoubier/SmaCC:master

Using a tag name, you can match the tagged commit:

  github://ThierryGoubier/SmaCC:v1.0.0
  github://ThierryGoubier/SmaCC:v1.1.0

Using a tag wildcard you can specify the latest tag 1.0.*:

  github://ThierryGoubier/SmaCC:v1.0.*

which matches v1.0.1, v1.0.2, whichever is latest, but not v1.0.2.1.

To match the latest tag in the 1.0 family use 1.0.?:

  github://ThierryGoubier/SmaCC:v1.0.?

which matches v1.0.1, v1.0.2  and v1.0.2.1.

There are more examples here[1].

This feature was introduced in Metacello 1.0.0-beta.32.16[2].

Dale

[1] 
https://github.com/dalehenrich/metacello-work/issues/277#issuecomment-58970696
[2] 
https://github.com/dalehenrich/metacello-work/issues?q=milestone%3A1.0.0-beta.32.16+is%3Aclosed


On 1/27/15 1:52 AM, kilon alios wrote:
beautiful it worked like a charm following your instructions , I now 
can brake my project to smaller ones, each one with each own github 
repo and use Baselines to load each one and still allow the user to 
load my Project in one single click from Configuration Browser. Love 
it how Pharo make this all this so easy, with python it was a 
nightmare. Brilliant just Brilliant ! :)


On Tue, Jan 27, 2015 at 11:19 AM, Thierry Goubier 
mailto:thierry.goub...@gmail.com>> wrote:


Hi Kilon,

a simple way to do that is to change your configuration so that it
uses the baseline in your github. The SmaCC configuration for
Pharo 4.0 is written in this way for the stable version.

version204: spec

spec
for: #'pharo4.x'
do: [
spec
blessing: #stable;
author: 'ThierryGoubier';
description: 'SmaCC Smalltalk Compiler Compiler
for Pharo 4.0'.
spec
baseline: 'SmaCC' with: [ spec repository:
'github://ThierryGoubier/SmaCC:master' ];
import: 'SmaCC' ]

Thierry



2015-01-27 10:08 GMT+01:00 kilon alios mailto:kilon.al...@gmail.com>>:

So I have a Configuration in the Meta repo of pharo 4 and 3
that loads the latest version of my project Ephestos.

However I have moved my development to github since I am very
happy with the workflow and since I discovered loading github
repos via a baseline I have little use for smalltalkhub.

So my plan is this, keep the configuration in the meta repo so
people and me can install my project easily with one click via
the wonderful simple configuration browser , but I dont want
anymore to load any versions with it. Instead I want to tell
the configuration "load the github baseline" which  means it
will fetch the code from my github account master branch which
is the stable branch anyway (and the only branch so far) .

That will allow me to never have to update that configuration
again since it will just load the latest code from github repo.
The question is how to do this the easiest and cleanest way
possible ?

Re: [Pharo-users] Hijacking a Configuration for loading a Github Baseline

[Dale Henrichs]

On 1/27/15 7:10 AM, Thierry Goubier wrote:

Hi Dale,

The wildcards on tags, are they available on branch names as well?
The wildcards are only applied to tags ... branch names are not expected 
to look like version numbers with  `.` and `-`  separated "possibly 
numeric" fields.


I wonder about the choice for ? and *, because:

- In RE(s), ? is 0 or 1 occurence, * is 0 or any number of occurences.
- In shells (bash?), ? is any one character, * is 0 or any number of 
characters.


i.e. ? matches less than * in both cases. In Metacello, it is the 
reverse: 1.0.? matches more labels than 1.0.*
I based my sytax on  String>>match:. String>>match: uses `*` for "any 
sequence of characters" and `#` for "any character" which is different 
that RE and shell matching syntax ... `?` was unused so I picked it for 
"match this and subsequent fields".


I'm open to suggestions for alternatives to the `?`:)

Dale

Re: [Pharo-users] Hijacking a Configuration for loading a Github Baseline

[Dale Henrichs]

Kilon,

I don't use tags a lot in my own projects, but if someone is using your 
project in a production situation, then using tags is a good idea (if 
you follow semantic versioning) so that the users can tell when and if 
you have made api-breaking changes...


Since the Smacc project looks like it is on github you have two options 
for doing a "project reference": reference the configuration or 
reference the baseline.


To reference a configuration-based project do something like the 
following (in a baseline):


  spec
configuration: 'SmaCC'
with: [
  spec
versionString: '2.0.4';
repository: 'http://.' ].
  spec
package: 'PackageThatDependsUponSmacc'
with: [ spec requires: #('Smacc') ].

Note that you might want to use a symbolic version (if they are defined 
in the project) so that you can always get the #stable version which 
presumably changes over time ...


To reference a baseline-based project do something like the following 
(in a baseline):


  spec
baseline: 'SmaCC'
with: [ spec repository: 'github://ThierryGoubier/SmaCC:master' ].
  spec
package: 'PackageThatDependsUponSmacc'
with: [ spec requires: #('Smacc') ]

Note that you can use the tag wild cards to achieve a similar effect of 
using symbolic versions with configurations.


Did this answer your question?

Dale
On 01/27/2015 07:21 AM, kilon alios wrote:
No I have not used git tags so far, so I am not familiar with them. 
But I will keep in mind, I am considering not having versions at all, 
I find it a curious concept.


Dale there is one thing I wanted to ask you , would it possible put in 
my github repo installation instructions for installing prerequisites ?


For example I may use Thierry's SmaCC which I currently study to 
figure out how it works.


I could add that to my ConfigurationOfEphestos that I have saved to 
Meta Repo of Pharo 4. But I dont want to touch that repo, ideally I 
would like to do this from the BaselineOfEphestos which is stored in 
my Ephestos github repo. Is that possible ? Can the baseline handle 
installation of dependencies and trigger other configurations ? Or is 
that a job only for Configurations ?


I want not to have to maintain also meta repo 4, I just want to only 
to do all things in my github repo.


On Tue, Jan 27, 2015 at 4:57 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Kilon,

One more point that you might find useful ... If you use tags
(i.e., v1.0.0, v1.0.1, v1.1.0), you can specify tag wildcards  in
the branch field of the github repository description.

Using Thierry's example the following resolves the latest commit
on the master branch (bleeding edge):

  github://ThierryGoubier/SmaCC:master

Using a tag name, you can match the tagged commit:

  github://ThierryGoubier/SmaCC:v1.0.0
  github://ThierryGoubier/SmaCC:v1.1.0

Using a tag wildcard you can specify the latest tag 1.0.*:

  github://ThierryGoubier/SmaCC:v1.0.*

which matches v1.0.1, v1.0.2, whichever is latest, but not v1.0.2.1.

To match the latest tag in the 1.0 family use 1.0.?:

  github://ThierryGoubier/SmaCC:v1.0.?

which matches v1.0.1, v1.0.2  and v1.0.2.1.

There are more examples here[1].

This feature was introduced in Metacello 1.0.0-beta.32.16[2].

Dale

[1]

https://github.com/dalehenrich/metacello-work/issues/277#issuecomment-58970696
[2]

https://github.com/dalehenrich/metacello-work/issues?q=milestone%3A1.0.0-beta.32.16+is%3Aclosed



On 1/27/15 1:52 AM, kilon alios wrote:

beautiful it worked like a charm following your instructions , I
now can brake my project to smaller ones, each one with each own
github repo and use Baselines to load each one and still allow
the user to load my Project in one single click from
Configuration Browser. Love it how Pharo make this all this so
easy, with python it was a nightmare. Brilliant just Brilliant ! :)

On Tue, Jan 27, 2015 at 11:19 AM, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:

Hi Kilon,

a simple way to do that is to change your configuration so
that it uses the baseline in your github. The SmaCC
configuration for Pharo 4.0 is written in this way for the
stable version.

version204: spec

spec
for: #'pharo4.x'
do: [
spec
blessing: #stable;
author: 'ThierryGoubier';
description: 'SmaCC Smalltalk Compiler
Compiler for Pharo 4.0'.
spec
baseline: 'SmaCC' with: [ spec repository:
'github://ThierryGoubier/SmaCC:master' ];

Re: [Pharo-users] Error loading own project from GitHub with Metacello

[Dale Henrichs]

Manfred,

When you use github, you don't need nor do you want to use a 
ConfigurationOf. git manages the versions for you so you don't need to 
define versions in the ConfigurationOf. If you want versions for a git 
repository, use tags.


You still need to specify load order and project dependencies. For an 
example you can look at[1] or download the baseline:


Metacello new
  baseline: 'External';
  repository: 'github://dalehenrich/external:master/repository';
  get.

No need to specify a repository in the baselineOf, since the repository 
is derived from the location of the Baseline itself.


Dale

[1] 
https://github.com/dalehenrich/external/blob/master/repository/BaselineOfExternal.package/BaselineOfExternal.class/instance/baseline..st

On 02/02/2015 01:21 PM, Manfred Kröhnert wrote:

Hi,

sorry for the unfinished email upfront. I accidentially hit the send 
button before I was finished...

So here we go again:

Some time ago I started a small Pharo based project but didn't want to 
announce it before I knew how to load it conveniently.


For versioning I started using GitFileTree and pushed the code to 
GitHub together with a ConfigurationOf created with Versionner.


Only after a more recent email from Kilon on this list I figured out 
that the project should be easily loadable with the following commands:


Metacello new
configuration:'HttpExplorer';
repository:'github://mkroehnert/httpexplorer:master';
get.

Metacello new
configuration:'HttpExplorer';
repository:'github://mkroehnert/httpexplorer:master';
load.

Executing the first command succeeds and the 
ConfigurationOfHttpExplorer appears in the Browser.
But when I try to execute the load command I get the following error 
(unfortunately I don't yet know how to copy a complete stacktrace):


Error: Instances of UndefinedObject are not indexable

This is a result from executing ZnClient>>getConnectionAndExecute 
where 'request url' returns the following address:


http://:80/g...@github.com:mkroehnert/httpexplorer.git/?C=M;O%3DD

I guess that the error is probably in the ConfigurationOf but I am a 
bit lost as to where I should dig further.
It would be great if anyone could point me in the right direction of 
where to look or tell what went wrong.


Thanks in advance,
Manfred

Re: [Pharo-users] Error loading own project from GitHub with Metacello

[Dale Henrichs]

On 2/8/15 4:06 AM, Sven Van Caekenberghe wrote:

On 08 Feb 2015, at 12:03, Manfred Kröhnert  wrote:

Hello Sven,

On Sun, Feb 8, 2015 at 11:32 AM, Sven Van Caekenberghe  wrote:
It is always better to depend on Zinc #stable since it still evolves while 
Pharo 3 does not.

thanks for your advice.
This does mean that I should include the "spec project: 'Zinc-Http' with: [ 
..." lines, correct?

Yes, I think so, I have

project: 'ZincHTTPComponents' with: [
spec
className: 'ConfigurationOfZincHTTPComponents';
repository: 'http://mc.stfx.eu/ZincHTTPComponents';
loads: #('Core' 'Tests' 'REST' 'AWS') ];

which groups you load it up to you, adding the version is OK I guess (I think 
it defaults to stable), I think the className is needed because of the odd 
casing.

But I can't say I am a Metacello expert ...


Sven, for not being a Metacello expert you did a good job. Just two things.

If you don't specify a verionString, the default is #bleedingEdge. If 
you want #stable, then it should be explicitly specified.


Secondly, your zinc spec (except for the versionString is correct. With 
the latest versions of Metacello, you can eliminate the need to specify 
a className by using configuration: or baseline: in place of project: 
like so:


configuration: 'ZincHTTPComponents' with: [
spec
versionString: #stable;
repository: 'http://mc.stfx.eu/ZincHTTPComponents';
loads: #('Core' 'Tests' 'REST' 'AWS') ];

Dale

Re: [Pharo-users] BaselineOf vs ConfigurationOf

[Dale Henrichs]

Martin,

In my work I am moving entirely away from ConfigurationOf ... 
ConfigurationOf was invented because Monticello lacks the ability to 
reason about multi-file versions so virtually all of the meta data in a 
ConfigurationOf is making up for this lack. Of course, the 
ConfigurationOf only partially fills the gap ...


Git handles multi-file versions as well as branches so all of the extra 
meta data in the ConfigurationOf is totally unnecessary once you start 
using git.


The BaselineOf manages the meta data that is still required in the 
presence of git:

  - package load order
  - project dependencies

One can use tags directly in a project reference so configurations can 
be completely eliminated.


Dale
On 2/25/15 7:05 AM, Martin Bähr wrote:

Excerpts from Thierry Goubier's message of 2015-02-25 15:43:39 +0100:

BaselineOf is the same as a #baseline: in a ConfigurationOf. It describes
dependencies, packages and groups for a project, without versions. On
loading, a BaselineOf will behave as a #development version in a
ConfigurationOf which is to load the latest versions of the packages listed
(and whatever dependencies listed).

sounds to me like one should use branches for baseline (since they update)
and tags for versions in configuration (since they stay on the same commit)


Repositories urls which support branches and tags are github:// and
bitbucket:// urls; which support branches (and not tags) are gitfiletree://
urls.

oh, any particular reason, or just work in progress?

greetings, martin.

Re: [Pharo-users] BaselineOf vs ConfigurationOf

[Dale Henrichs]

On 2/26/15 4:41 AM, Ben Coman wrote:
Just a random query (especially since I haven't played with BaselineOf 
and I might misunderstand something)...
should #baseline: be moved out of the ConfigurationOf class so that we 
consistently have a BaselineOf class in both cases: git & monticello.
Haha, you are misunderstanding ... the two classes are separate because 
they are independent classes. One should use one or the other for 
managing a project.


If you have a git-based project then I recommend that you use a 
BaselineOf to manage the packages and dependent projects.


If you are using a Monticello repository (mcz files) then you must use a 
ConfigurationOf ...


That is, the ConfigurationOfXxx.mcz package will contain two classes: 
ConfigurationOfXxx and BaselineOfXxx.



This will not work as you expect:)

Dale

Re: [Pharo-users] Git overriding repo load from different source

[Dale Henrichs]

Peter, sorry for not answering sooner ... I keep an eye out for posts 
with Metacello in the subject line so I missed this one ...


So if i understand your question, you have a GitHub project that you 
normally download like this:


  Metacello new
baseline: 'Sample';
repository: 'github://GsDevKit/sampleProject:master/repository';
load.

now you have cloned the repository to a local git repository:

  cd /opt/git
  git clone g...@github.com:GsDevKit/sampleProject.git

and you can directly load the project like this:

  Metacello new
baseline: 'Sample';
repository: 'filetree:'///opt/git/sampleProject/repository';
load.

but in another configuration (that you may not control) there is 
dependency upon Sample that looks like this:


  spec baseline: 'Sample' with: [ spec repository: 
'github://GsDevKit/sampleProject:master/repository' ].


and you are wondering how you can force you local clone to be used ... 
is that correct?


If so then the trick is to use the Metacello `lock` ... Do the following 
BEFORE loading the project that depends upon you sample project:


  Metacello new
baseline: 'Sample';
repository: 'filetree:'///opt/git/sampleProject/repository';
lock.

Then whenever Metacello finds a dependency upon 'Sample' the local clone 
(the `lock`ed) project will be used instead.


This is use case is the primary reason for the existence of the `lock` 
command. Also note that you need to use the scripting api for all loads 
to make sure that the lock is honored. Finally you can use the onLock: 
message to break the lock in certain cases ... the default Metacello 
load honors all locks (a Warning is dumped to the transcript) ...


As Thierry mentions, you should be using the latest version of Metacello 
on github ...


If I missed the mark here let know ...

Dale



On 3/21/15 6:41 AM, Peter Uhnák wrote:

Hi,

I'm trying to load local package over git one...
basically:

Projects A and B.
A depends on B.
A loads B from its BaselineOfA, the reference points to github.

Now I have also local copy of B git repository, and I would like to
either
a) Override the load of B with local B (so the packages will point to 
local instead of remote).
Currently it fails on MetacelloRepositorySpec>>hasNoLoadConflicts: 
because each (local and git) repo points to different place.
This would be useful if I want to make change to B AFTER the project B 
is already loaded.


b) Add all packages from B to local B repo (same as manually using 
"add to package..." in Monticello Browser")
This will work only if both the repos have the same packages, so 
probably not that useful. (i.e. no code differences)


c) Override the GitHub B repository in the BaselineOfA BEFORE the 
project is loaded.
This would require some mapping in Monticello browser, I've seen 
something like "repositoryOverrides:" but I don't know how it works.
This would be useful if I knew beforehand that I want to make changes 
also to B.


So how would one go about this? Having option "c)" would be probably 
the best; I can live without "a)". :)


Any pointers appreciated,
Peter

Re: [Pharo-users] How to depend on another Github repo from the baseline ?

[Dale Henrichs]

Kilon,

Thierry's solution is the preferred one ... I know that a lot of people 
are inclined to insert arbitrary Smalltalk code into specifications, but 
one should pretty much stick to the spcification-based solution and 
avoid including arbitrary Smalltalk ... including a load like you have 
may "work" but if any issues start showing up (and they are likely to 
eventually) I won't be able to help you ...


If one uses git/github, it should be completely unnecessary to have a 
ConfigurationOf at all ... as the combination of a BaselineOf and git 
covers all of the bases ...


Thierry is correct that a BselineOf can be used with a non-git 
repository, but if you take that approach you will always load the 
bleeding edge and there will be no way to put a stake in the ground with 
respect to a certain fixed version. Git gives you the SHA and tags to 
identify a specific version.


Dale

On 3/17/15 4:55 AM, Thierry Goubier wrote:

Hi Kilon,

I think you can simply do:

baseline: spec

spec
for: #pharo
do: [
spec baseline: 'SmaCC' with: [ spec repository: 
'github://ThierryGoubier/SmaCC' ].

spec package: 'Ephestos' with: [ spec requires: #('SmaCC') ] ]

You can also restrict what you load from SmaCC in this way:

baseline: spec

spec
for: #pharo
do: [
spec baseline: 'SmaCC' with: [ spec repository: 
'github://ThierryGoubier/SmaCC' ].

spec import: 'SmaCC'.
spec package: 'Ephestos' with: [ spec requires: #('SmaCC-Python') ] ]

(i.e. by importing the baseline of SmaCC, you can choose among the 
groups or the packages of SmaCC...)


From what Dale told me, you can only import one baseline this way. But 
you can add from more than one baseline with import: provides:


baseline: spec

spec
for: #pharo
do: [
spec baseline: 'SmaCC' with: [ spec repository: 
'github://ThierryGoubier/SmaCC' ].

spec import: 'SmaCC' provides: #('SmaCC-Python').
spec package: 'Ephestos' with: [ spec requires: #('SmaCC-Python') ] ]

Dale, is that correct? I haven't tested those, so...

Note that any kind of repository can host a baseline this way, 
smalltalkhub, squeaksource, etc...


version05: spec

spec
for: #'pharo4.x'
do: [
spec
baseline: 'GitFileTree'
with: [ spec repository: 
'http://smalltalkhub.com/mc/ThierryGoubier/GitFileTreePharo40/main' ];

import: 'GitFileTree' ]

And of course a baseline can require a configuration...

I'm still exploring all the possibilities this allows (and, more 
important, how configurations may be simplified to defer effective 
loading to a baseline inside the master repository, so that the 
configuration very rarely has to be updated).


Thierry

2015-03-17 12:11 GMT+01:00 kilon alios >:


I have this very simple baseline for Ephestos

baseline: spec

spec
  for: #pharo
  do: [
spec package: 'Ephestos' with: [Metacello new
baseline: 'SmaCC';
repository: 'github://ThierryGoubier/SmaCC';
load] ].

The above code works fine for me. The user can install Ephestos
from configuration browser that has a configuration that loads
this baseline which in turn not only loads the latest code for the
project but also runs this block to make sure Smacc is installed
for Ephestos to use.

The question however how else I can do this and what are the
advantages and disadvantages for those other approaches ?

Re: [Pharo-users] Git overriding repo load from different source

[Dale Henrichs]

On 3/24/15 11:47 PM, Peter Uhnák wrote:
On Sun, Mar 22, 2015 at 11:19 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


I keep an eye out for posts with Metacello in the subject line so
I missed this one ...

I'll keep that in mind next time.

If so then the trick is to use the Metacello `lock` ... Do the
following BEFORE loading the project that depends upon you sample
project:

Combined with onConflict: mentioned by Thierry this works like a 
charm, thanks a lot. :)


(a Warning is dumped to the transcript) ...

I got a warning prompt which I had confirm ("proceed") couple of 
times, but that's just a detail.



Peter,

There's an onWarningLog message that will catch the Warning, log it to 
the Transcript and proceeed ... there's also an onWarning: message that 
lets you customize your response ...


Dale

Re: [Pharo-users] Git overriding repo load from different source

[Dale Henrichs]

On 3/25/15 1:35 AM, Jan B. wrote:

Hello

I was able to get by those warnings automatically by adding onLock: [ :ex |
ex disallow ]; in addition to onConflict

Metacello new
baseline: '...'
repository: 'gitfiletree:///.../repository'
onConflict: [ :ex | ex allow ];
onLock: [ :ex | ex disallow ];
load

I'm not sure whether it couldn't cause any problems, but it seems to be
working.



I'd recommend that you not put in the unconditional onConflict: ... at 
one point in time the onConflict: was required to handle locks, but 
currently the default handler for onConflict: will honor locks and the 
default handler for onLock: will dump signal a Warning and then honor 
the lock.


Putting in onLock: as you've done _is_ a good way to bypass the onLock: 
Warnings ... you can use `honor` instead of `disallow` and `break` 
instead of `allow` for the onLock: notification as those messages read a 
bit better ...


The interesting onConflict: notifications occur when an incoming project 
decides to change the version or repository or configuration type 
(BaselineOf or ConfigurationOf) ... so if you care to know when this 
type of thing happens, then you can _leave off the onConflict:_ and 
you'll get a chance to decide if you want to have that change made to 
your system, before it is loaded rather than discover the change after 
it is loaded ... this is basically why I added the onLock: message - so 
that you weren't tempted to add an uncoditional onConflict: block just 
because you were working with locks:)


Dale

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

and if we remove the method properties from FileTree, then the 
monticello files stored there could not be transparently copied into and 
out of a FileTree repo ... and FileTree is SCM neutral ...


Personally I use 
https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never 
think twice about the properties files ...


Dale
On 04/07/2015 08:48 AM, Thierry Goubier wrote:

Hi Peter,

Le 07/04/2015 17:39, Peter Uhnák a écrit :

Hi,

are "methodProperties.json" files needed?


No.


Every time someone makes even small changes it is accompanied by ten
times more json file changes which is a mess.


Yes, it creates quite some noise on the git logs and diffs.


So is it needed with git? Cannot the information be retrieved from git
commits?


It is not needed for git.

GitFileTree retrieves the information via the git logs.

But, if we remove it entirely, then the repository won't be usable by 
filetree. So GitFileTree keeps writing that metadata to stay compatible.


Thierry

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

Sean,

The primary reason that the method properties.json file exists is to 
preserve the date and timestamp for monticello ... git doesn't need this 
but, to be able to seamlessly copy monticello files from filetree to mcz 
and back again without losing data the information has to be stored 
somewhere ... a pure git repo does not need this information and it can 
be eliminated, but you pay the price of cutting off mcz file 
compatibility ... FileTree is agnostic as to the SCM being used ... it 
is a disk format ... so it cannot leverage the meta data from git ... if 
git is not used to manage the disk ...


I appreciate the fact that folks are coming up with all sorts of ideas 
... but there are constraints as to what is done for FileTree ... 
FileTree is supposed to be cross platform so changing disk formats is 
not as easy as just writing some smalltalk code, unless you want to 
write the smalltalk code for the 4 or 5 different Smalltalk dialects 
that read/write FileTree ...


Thierry has taken the approach of maintaining compatibility with 
FileTree, which is a convenient thing to do ... convenient for all of 
the folks that have been using Filetree for the last 3 years and have 
been living with the limitations and patiently waiting for folks to 
begin adoption ...


the problem with patiently waiting is that I am very busy right now and 
I do not have the time to fiddle with FileTree ... I know that a number 
of you guys don't care about other platforms and don't care about 
backwards compatibility ... but I do and I do not have the free time to 
fiddle around with the fad of the moment ...


I thnk that rather than focus on the disk format which I hardly ever 
actually look at ... that folks should be looking at tools support (like 
Thierry) ... this is where the real work needs to happen ... good tools 
can hide the disk fomat completely so why does the disk format matter ...


BTW, we had some major email wars several years ago and frankly I don't 
have the time to justify decisions that were made 3 years ago every 2 
months 


Dale

On 04/07/2015 04:14 PM, Sean P. DeNigris wrote:

Dale Henrichs-3 wrote

Personally I use
https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never
think twice about the properties files ...

Ooh, intriguing. In other to make it easier to view code on GitHub, I've
been toying with the idea of generating one-class-per-file in addition to
the regular gitfiletree files. Could this be used to make that possible
without complicating Git?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

Peter,

That looks like a bug in the FileTree writer ... wiht one method change 
there should have been only one method property file change ...


Peter and Sean,

If you are interested in contributing code/bugfixes to FileTree, I will 
welcome pull requests ... As I have mentioned in several posts today, I 
do not have the time to fiddle with changes to the FileTree format 
myself, but I welcome contributions.


Damien has started work on an updated version of the FileTree format[2].

I have threatened in the past to add an option to a repository that 
would eliminate the need to store monticello meta data ... Damien is 
working on "starting from scratch" on the new format, because the 
current implementation supports 4-5 different FileTree formats. Damien's 
work could be leveraged to add an "optional Monticello meta data" option 
to FileTree and if your SCM (like git) gives you per method history with 
the proper tools you can leverage that information..


As I ranted in another post ... changing the disk format is the easy 
part ... building and maintaining tools for the 4-5 different Smalltalk 
dialects is a different matter ...


Dale

[1] https://github.com/dalehenrich/filetree/issues
[2] https://github.com/dalehenrich/filetree/issues/144
On 04/07/2015 04:38 PM, Peter Uhnák wrote:
Yeah, I do use the MergeDriver and it saved me a lot of headache, but 
when I see things like this


https://github.com/dynacase/dynacase/commit/90141d63bfdd433e51a768c2191e035b76c5da83

where one five lines long method generated 14 file changes with 180 
additions and 172 deletions... it makes the log on github and pull 
requests incredibly messy.


I don't want to cut branch under myself if I were to remove the 
properties file. So my question now is: how hard would it be to 
regenerate those files?


Or maybe if it was moved to some metadirectory. This reminds me a bit 
of svn which polluted the whole folder tree with .svn files everywhere.


Peter



On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris 
mailto:s...@clipperadams.com>> wrote:


Dale Henrichs-3 wrote
> Personally I use
> https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never
> think twice about the properties files ...

Ooh, intriguing. In other to make it easier to view code on
GitHub, I've
been toying with the idea of generating one-class-per-file in
addition to
the regular gitfiletree files. Could this be used to make that
possible
without complicating Git?



-
Cheers,
Sean
--
View this message in context:

http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233.html
Sent from the Pharo Smalltalk Users mailing list archive at
Nabble.com.

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

Sean,

My mail may have been a bit harsh, so please read my reply to Peter ... 
where I think I take a bit more positive tack:)


I am really pressed for time so I don't have the luxury to blue sky 
ideas ... but I will make the time to review any code contributions that 
folks have ...


Dale

On 04/07/2015 04:52 PM, Dale Henrichs wrote:

Sean,

The primary reason that the method properties.json file exists is to 
preserve the date and timestamp for monticello ... git doesn't need 
this but, to be able to seamlessly copy monticello files from filetree 
to mcz and back again without losing data the information has to be 
stored somewhere ... a pure git repo does not need this information 
and it can be eliminated, but you pay the price of cutting off mcz 
file compatibility ... FileTree is agnostic as to the SCM being used 
... it is a disk format ... so it cannot leverage the meta data from 
git ... if git is not used to manage the disk ...


I appreciate the fact that folks are coming up with all sorts of ideas 
... but there are constraints as to what is done for FileTree ... 
FileTree is supposed to be cross platform so changing disk formats is 
not as easy as just writing some smalltalk code, unless you want to 
write the smalltalk code for the 4 or 5 different Smalltalk dialects 
that read/write FileTree ...


Thierry has taken the approach of maintaining compatibility with 
FileTree, which is a convenient thing to do ... convenient for all of 
the folks that have been using Filetree for the last 3 years and have 
been living with the limitations and patiently waiting for folks to 
begin adoption ...


the problem with patiently waiting is that I am very busy right now 
and I do not have the time to fiddle with FileTree ... I know that a 
number of you guys don't care about other platforms and don't care 
about backwards compatibility ... but I do and I do not have the free 
time to fiddle around with the fad of the moment ...


I thnk that rather than focus on the disk format which I hardly ever 
actually look at ... that folks should be looking at tools support 
(like Thierry) ... this is where the real work needs to happen ... 
good tools can hide the disk fomat completely so why does the disk 
format matter ...


BTW, we had some major email wars several years ago and frankly I 
don't have the time to justify decisions that were made 3 years ago 
every 2 months 


Dale

On 04/07/2015 04:14 PM, Sean P. DeNigris wrote:

Dale Henrichs-3 wrote

Personally I use
https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never
think twice about the properties files ...

Ooh, intriguing. In other to make it easier to view code on GitHub, I've
been toying with the idea of generating one-class-per-file in 
addition to

the regular gitfiletree files. Could this be used to make that possible
without complicating Git?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233.html

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

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

On 04/07/2015 10:24 PM, Thierry Goubier wrote:

Le 08/04/2015 02:05, Dale Henrichs a écrit :
I have threatened in the past to add an option to a repository that
would eliminate the need to store monticello meta data ... Damien is
working on "starting from scratch" on the new format, because the
current implementation supports 4-5 different FileTree formats. Damien's
work could be leveraged to add an "optional Monticello meta data" option
to FileTree and if your SCM (like git) gives you per method history with
the proper tools you can leverage that information..

I would say this could be a reasonable possibility, in that you could 
have two modes of compatibility:


- Complete filetree compatibility for gitfiletree: the current 
situation, with properties and version written to disk.


- Partial filetree compatibility, where that metadata isn't written 
and you rely on gitfiletree to recreate it to export as .mcz.


Partial compatibility has two effects, which need to be considered. 
When using github:// or bitbucket:// urls, filetree will be used and 
your packages will end up having no version number (except .1?), no 
author, no timestamps for methods, etc... And the second one is that, 
if you clone a mcz inside the gitfiletree repository, the mcz ancestry 
of versions and author timestamps on methods will be lost, which is 
something you may not want.
Yes for Metacello some modifications would need to be made because in a 
normal mcz universe Metacello will not load a package if the version is 
older or the same as the one in the image ... and following in the 
tradition of other Monticello tools the UUID is ignored:( .. I was 
working with a pure cypress implementation and have written the 
Metacello code to support these repos ...


A better long term solution is to treat these as a CypressPackage or 
FileTreePackage which has some similarities to Monticello packages ... 
because faking out Monitcello version numbers and users is not much 
different than storing the metadata in FileTree ...


But someone were to add those options to filetree, I think we could 
reduce the overall number of hacks:)


Dale

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

On 04/07/2015 11:47 PM, Peter Uhnák wrote:


I thnk that rather than focus on the disk format which I hardly
ever actually look at ... that folks should be looking at tools
support (like Thierry) ... this is where the real work needs to
happen ... good tools can hide the disk fomat completely so why
does the disk format matter ...

I am personally not really a fan of this; I've been using git for a 
while and I am perfectly content with using command line on the disk 
(maybe I'm rare breed); I have yet to see a GUI/tool that would come 
even close to the power of command line, but I've been using Linux for 
a long time.
I understand and that is a tension point for FileTree ... the source 
_is_ on disk and you do use the GitHub tools (or any other git tools 
independent of those in Smalltalk) that give you a picture of everything 
that changed including the "ugly" meta data ...


I flip around and use vi at times to edit a method and of course the 
github tools for pull requests. But then I use the tODE tools for 
working with git as well ... but as you recognize, the monticello meta 
data is there for compatibility and righ now at least compatibility is a 
good thing ...


As I've said to Thierry some time ago in different thread, I would be 
interested in idea of having everything on disk side and Pharo would 
only somehow refresh it's content (just like a Java IDE / text editor 
would). But that may be a lot o work so I can only dream about it, as 
nobody has time for that (me included).


But to bottom line this thread (for me at least, because I'm getting 
lost):
1. methodProperties.json provide compatibility for FileTree, so I 
don't want to get rid of it (for now)
2. the large amount of file changes is probably a bug (I'll try to be 
more observant about the commits in the future and hopefully some 
pattern will emerge.)

3. I shouldn't want to break things for now at least
4. more people are starting to work on Git
5. I need to learn about FileTree at some point if I want to 
contribute and experiment with (my) ideas (which won't be soon as I'm 
preparing for my finals)



All very good points

Dale

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

On 04/08/2015 12:47 PM, Thierry Goubier wrote:

Hi Dale,

Le 08/04/2015 19:30, Dale Henrichs a écrit :



On 04/07/2015 10:24 PM, Thierry Goubier wrote:

Le 08/04/2015 02:05, Dale Henrichs a écrit :
I have threatened in the past to add an option to a repository that
would eliminate the need to store monticello meta data ... Damien is
working on "starting from scratch" on the new format, because the
current implementation supports 4-5 different FileTree formats. 
Damien's
work could be leveraged to add an "optional Monticello meta data" 
option
to FileTree and if your SCM (like git) gives you per method history 
with

the proper tools you can leverage that information..

I would say this could be a reasonable possibility, in that you could
have two modes of compatibility:

- Complete filetree compatibility for gitfiletree: the current
situation, with properties and version written to disk.

- Partial filetree compatibility, where that metadata isn't written
and you rely on gitfiletree to recreate it to export as .mcz.

Partial compatibility has two effects, which need to be considered.
When using github:// or bitbucket:// urls, filetree will be used and
your packages will end up having no version number (except .1?), no
author, no timestamps for methods, etc... And the second one is that,
if you clone a mcz inside the gitfiletree repository, the mcz ancestry
of versions and author timestamps on methods will be lost, which is
something you may not want.

Yes for Metacello some modifications would need to be made because in a
normal mcz universe Metacello will not load a package if the version is
older or the same as the one in the image ... and following in the
tradition of other Monticello tools the UUID is ignored:( .. I was
working with a pure cypress implementation and have written the
Metacello code to support these repos ...


Ok.

Yes, the version number handling is delicate; even the one used by 
gitfiletree feels unsatisfying, even if it allows Metacello/Monticello 
to work as usual.
The work I had done was at the Metacello level and is in the 
Metacello-Cypress package where I changed the load semantics to 
unconditionally load the package ... the snapshot comparison logic in 
play when loading packages is pretty good so it isn't necessarily a 
penalty to unconditionally compare snapshots when loading a package from 
FileTree ...



A better long term solution is to treat these as a CypressPackage or
FileTreePackage which has some similarities to Monticello packages ...
because faking out Monitcello version numbers and users is not much
different than storing the metadata in FileTree ...


Not sure I understand. I know where the Cypress/FileTree code handles 
the lack of metadata when reading, that's all :)



But someone were to add those options to filetree, I think we could
reduce the overall number of hacks:)


Another solution I'd see possible is a reduced metadata format, where 
just the version number of the current package is stored and retrieved 
(i.e. a version file without ancestry).


It would allow FileTree and Metacello to work exactly as usual.

And, maybe, I could even unify the UUIDs?

There are things in Monticello which needs a rethink to better adapt 
to SCMs like git (or Fossil: it's so similar to git :) ) while keeping 
more or less the same appearance: branches, hashes, tags and semantic 
versionning.


But I don't see yet how to handle that or to propose anything.

I know that it would be great to reduce the cognitive distance between 
MC version and history handling, and the same as seen from Metacello 
baselines and configurations. Branches + baselines are doing a lot to 
simplify, but MC stuff is unaware of that. And MC should delegate 
merging to the underlying repository, as well.


So this "extraneous" Monticello meta data is really related to the 
versioning aspects of the Monticello package ... aspects that really 
needed if you are using "git" (read "git" as svn, hg, git, fossil, 
etc.:) for version control .. in working with "git" the SHA of the 
commit for the repository as a whole is more important than any of the 
package meta data ... from the SHA one can see the commit comment for 
the "git" commit the SHA is related to a project not a package ... the 
project contents is represented by the BaselineOf ... in git one can 
reason about the collection of commits associated with a directory 
(package or class or method) and look at diffs at that level of 
granularity  The primary point being that a "git" package can be 
stripped down to the basic list of definitions and the ancestry and 
version names and method properties can be dropped on the floor instead 
of fabricated ...


What I imagine is a separate software stack for these "git" packages the 
commonality is at the snapshot/definition level and the core definitions 
can 

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

On 04/08/2015 01:11 AM, Thierry Goubier wrote:



2015-04-08 8:47 GMT+02:00 Peter Uhnák >:


I thnk that rather than focus on the disk format which I
hardly ever actually look at ... that folks should be looking
at tools support (like Thierry) ... this is where the real
work needs to happen ... good tools can hide the disk fomat
completely so why does the disk format matter ...

I am personally not really a fan of this; I've been using git for
a while and I am perfectly content with using command line on the
disk (maybe I'm rare breed); I have yet to see a GUI/tool that
would come even close to the power of command line, but I've been
using Linux for a long time.


Agreed and this is in that spirit I did GitFileTree. Dale went a bit 
further and even integrated the git command line access inside 
smalltalk via CommandShell... so that you get the best of both worlds 
without leaving your beloved Smalltalk :)


Actually it is not quite CommandShell based ... the shell is tODE shell, 
where Smalltalk is the scripting language. The tODE git commands  are 
implemented by parsing the command line args, resolving options and args 
to objects, and then calling a Smalltalk git command API that eventually 
does make shell calls (sometimes multiple git commands are folded into a 
single tODE git command ... thus making it possible to ultimately switch 
out the actual `git calls` and use something FFI-based, like libgit2...


This approach also makes it quite feasible to write fairly complicated 
Smalltalk scripts that call the smalltalk git command api directly, 
bypassing the command line interface altogether ...



As I've said to Thierry some time ago in different thread, I would
be interested in idea of having everything on disk side and Pharo
would only somehow refresh it's content (just like a Java IDE /
text editor would). But that may be a lot o work so I can only
dream about it, as nobody has time for that (me included).


Well, as I said elsewhere, Smalltalk doesn't work like that: code has 
to be lived in the image for most tools to work properly... it doesn't 
really have an "editor of file" mindset, but an "object inspector" 
mindset.


What we're looking at in another thread is how to emulate that live 
object approach over dead files, and, thinking of it, I'm not sure we 
will succeed well.


In short, what you want may never work properly because it is not how 
it should be conceptualized.


In tODE I regularly drop off live objects to the file system using STON 
... The tODE shell which allows you to navigate an object-based 
directory also allows you to mount the nodes from the file system and 
when traversing the file system recognizes STON files and presents 
objects to you instead of the dead files:)


I haven't tried taking this approach all the way to source files ... but

Dale

Re: [Pharo-users] Metacello GIT methodProperties.json

[Dale Henrichs]

On 04/08/2015 04:23 AM, Sean P. DeNigris wrote:

Dale Henrichs-3 wrote
Dale Henrichs-3 wrote

I am really pressed for time so I don't have the luxury to blue sky
ideas ...

I understand. I was not suggesting anyone do anything. Also, I agree that
methods seem to be the proper level for SCM versioning as they are in the
Smalltalk image. I was simply asking, in light of the appearance that the
merge driver could seemingly ignore the changes to certain files while still
committing them with Git, if it would be feasible to add read-only
one-class-per files "for viewing on GitHub". This is more of a sanity check
to see if I understood what the merge driver makes possible.


Sean, I think the issue becomes one of "so who makes sure the the 
readonly file matches the rest of the source" ...


I do occasionally edit files directory with vi ... I do regularly merge 
in changes from GemStone and Squeak ... so any package with this kind of 
file has the potential to decay quickly unless the changes were made so 
that they'd work on the supported filetree platforms ...


If you wanted to experiment, you could fork FileTree and try some 
experiments ... if they become something worth sharing, they could be 
merged into the master pharo branch ...


Dale

Re: [Pharo-users] Storing block closure code

[Dale Henrichs]

If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I
would worry about some wiseguy writing malicious code in the block ...

Dale


On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl  wrote:

> I was looking for a solution where I can have a textual grammar for a DSL
> in order to specify filters on objects. I didn't really search the net
> because I know a cute little DSL for that already. It is called smalltalk,
> you might have heard of it.
>
> So what I do is putting the filter spec into the image via an http
> interface, materialize the filter in image and store it in a database to
> have them survive image restart. A filter spec could look like this
>
> [ :value | ( self sectionLabelOf: value ) = 'device'  ]
>
> I want to know if there is any trouble to expect if I'm using plain block
> syntax for that task. As the blocks are injected using an http interface
> there is no environment/context problem. I would have some helper class as
> a facade to ease the filtering let's call it
>
> FilterHelper (would have a class side method #sectionLabelOf:)
>
> So getting the block code via HTTP I could do
>
> block := Smalltalk compiler
> evaluate: request contents
> for: FilterHelper
> logged: false
>
> And I would serialize it into a database as a string again doing
>
> self store: block sourceNode formattedCode
>
>  Are there any possible drawbacks using it this way?
>
> thanks,
>
> Norbert
>
>
>

Re: [Pharo-users] Storing block closure code

[Dale Henrichs]

If *you* are the wiseguy, then Smalltalk is a pretty powerful internal DSL:)

Dale


On Mon, Jul 14, 2014 at 9:09 AM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I
> would worry about some wiseguy writing malicious code in the block ...
>
> Dale
>
>
> On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl  wrote:
>
>> I was looking for a solution where I can have a textual grammar for a DSL
>> in order to specify filters on objects. I didn't really search the net
>> because I know a cute little DSL for that already. It is called smalltalk,
>> you might have heard of it.
>>
>> So what I do is putting the filter spec into the image via an http
>> interface, materialize the filter in image and store it in a database to
>> have them survive image restart. A filter spec could look like this
>>
>> [ :value | ( self sectionLabelOf: value ) = 'device'  ]
>>
>> I want to know if there is any trouble to expect if I'm using plain block
>> syntax for that task. As the blocks are injected using an http interface
>> there is no environment/context problem. I would have some helper class as
>> a facade to ease the filtering let's call it
>>
>> FilterHelper (would have a class side method #sectionLabelOf:)
>>
>> So getting the block code via HTTP I could do
>>
>> block := Smalltalk compiler
>> evaluate: request contents
>> for: FilterHelper
>> logged: false
>>
>> And I would serialize it into a database as a string again doing
>>
>> self store: block sourceNode formattedCode
>>
>>  Are there any possible drawbacks using it this way?
>>
>> thanks,
>>
>> Norbert
>>
>>
>>
>

Re: [Pharo-users] Storing block closure code

[Dale Henrichs]

Ben,

It's not just Global references that you have to worry about ... `self
environment` is an easy way to get direct access to `Smalltalk` ... you can
use `self superclass superclass subclasses...` to navigate to just about
any class in the system ...and this is only with a couple minutes of
thought:)  to be truly safe you have to work a bit harder and construct
a sandbox that is a subset of the standard environment ...

Dale


On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman  wrote:

>  Esteban A. Maringolo wrote:
>
> Are you going to be the end user of this?
>
> I wouldn't let users compile whatever Smalltalk expressions they want.
> You can't scope the globals that can be accessed by the compiler.
>
>
>
> CompilationContext had instance variable /environment/ that contains a
> SystemDictionary(lots of globals).  I wonder how effective it would be, or
> how horribly it would break things, to change that for a limited list.
> cheers -ben
>
>
>  What I would do is model a hierarchy of "Condition" objects used by
> "Filter" objects, which are composable, and know how to translate
> themselves to SQL, Mongo condition, or even Smalltalk expressions to
> apply the conditions to a collection of objects.
>
> The other way is to have a DSL, but that's a longer road if what you
> plan is simply to apply filters.
>
> We've done both in my previous job and worked perfectly.
>
>
> Regards!
>
>
>
> Esteban A. Maringolo
>
>
> 2014-07-14 12:19 GMT-03:00 Norbert Hartl  
> :
>
>
>  I was looking for a solution where I can have a textual grammar for a DSL in 
> order to specify filters on objects. I didn't really search the net because I 
> know a cute little DSL for that already. It is called smalltalk, you might 
> have heard of it.
>
> So what I do is putting the filter spec into the image via an http interface, 
> materialize the filter in image and store it in a database to have them 
> survive image restart. A filter spec could look like this
>
> [ :value | ( self sectionLabelOf: value ) = 'device'  ]
>
> I want to know if there is any trouble to expect if I'm using plain block 
> syntax for that task. As the blocks are injected using an http interface 
> there is no environment/context problem. I would have some helper class as a 
> facade to ease the filtering let's call it
>
> FilterHelper (would have a class side method #sectionLabelOf:)
>
> So getting the block code via HTTP I could do
>
> block := Smalltalk compiler
> evaluate: request contents
> for: FilterHelper
> logged: false
>
> And I would serialize it into a database as a string again doing
>
> self store: block sourceNode formattedCode
>
>  Are there any possible drawbacks using it this way?
>
> thanks,
>
> Norbert
>
>
>
>
>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Norbert,

I've just recently made the decision to start using Pharo3.0 to do all of
the heavy lifting  for my GsDevKit project[1] shell scripts.

I use boilerplate bash code to setup the environment[2] and then call Pharo
CommandLineHandler[3] to do the real work ...

I embed the script repository[4] in the project, so the script code matches
the directory structure and I build the command line pharo image[5] as part
of my installation.

I've been pretty pleased with the results, too. It's pretty straightforward
to run the scripts from within an interactive Pharo for debugging and it
beats the heck out of trying to do *simple things* with bash...

My only wish is that CommandLine had better getopts support - I have a
posix getopts commandline parser implementation that iI use for tODE that
I'd be willing to share ... hint hint:).

Dale

[1]
https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-gemstones-64-bit
[2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone
[3]
https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82
[4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository
[5]
https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L67-93


On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl  wrote:

> What are you using to do jobs on the commandline. I'm sick of doing bash
> and sed,perl,jq,... stuff. What would be the quickest start when using a
> normal image? And what if I want to give coral a start. Does it work in
> 3.0? Best place to load stuff from?
>
> thanks,
>
> Norbert
>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Esteban,

Right now the classes are embedded in my tODE common package (I use the
parser in Pharo and GemStone) ... I'll pull out the classes and tests
(rename them so you can evolve the implementation independent of tODE) and
give you a pointer when I'm done...

Dale


On Thu, Jul 24, 2014 at 7:12 AM, Esteban Lorenzano 
wrote:

>
> On 24 Jul 2014, at 16:07, Dale Henrichs 
> wrote:
>
> Norbert,
>
> I've just recently made the decision to start using Pharo3.0 to do all of
> the heavy lifting  for my GsDevKit project[1] shell scripts.
>
> I use boilerplate bash code to setup the environment[2] and then call
> Pharo CommandLineHandler[3] to do the real work ...
>
> I embed the script repository[4] in the project, so the script code
> matches the directory structure and I build the command line pharo image[5]
> as part of my installation.
>
> I've been pretty pleased with the results, too. It's pretty
> straightforward to run the scripts from within an interactive Pharo for
> debugging and it beats the heck out of trying to do *simple things* with
> bash...
>
> My only wish is that CommandLine had better getopts support - I have a
> posix getopts commandline parser implementation that iI use for tODE that
> I'd be willing to share ... hint hint:).
>
>
> and we would be glad to integrate, if is somewhere :)
>
> Esteban
>
>
> Dale
>
> [1]
> https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-gemstones-64-bit
> [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone
> [3]
> https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82
> [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository
> [5]
> https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L67-93
>
>
> On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl  wrote:
>
>> What are you using to do jobs on the commandline. I'm sick of doing bash
>> and sed,perl,jq,... stuff. What would be the quickest start when using a
>> normal image? And what if I want to give coral a start. Does it work in
>> 3.0? Best place to load stuff from?
>>
>> thanks,
>>
>> Norbert
>>
>>
>>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Esteban,

The commandline parser produces an option dictionary (keys are long option
names and values are the option values) and a collection of arguments. You
provide a specification for the options (short name, whether or not options
are required/optional or not expected) ... quite convenient.

Dale


On Thu, Jul 24, 2014 at 7:16 AM, Esteban A. Maringolo 
wrote:

> 2014-07-24 11:07 GMT-03:00 Dale Henrichs  >:
>
> > My only wish is that CommandLine had better getopts support - I have a
> posix
> > getopts commandline parser implementation that iI use for tODE that I'd
> be
> > willing to share ... hint hint:).
>
> Altough I'm used to Pharo's command line handlers now, it would be
> great to have "standard" command line arguments.
>
>
> Esteban A. Maringolo
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Norbert,

Ah, yes different use case ... for the scripts I'm writing I wanted to
leverage "loaded code" as I've got a whole class hierarchy supporting the
GsDevKit environment and did not relish the idea of doing that all in bash
distributed across a number of different scripts ...

Haha, I live in tODE all the time, where Smalltalk _is_ the scripting
language so I don't feel your particular brand of pain:)

Dale


On Thu, Jul 24, 2014 at 7:33 AM, Norbert Hartl  wrote:

> Dale,
>
> thanks for this extensive explanation. That looks all really good but I
> think I'm looking for the exact opposite. You arrange a lot of pieces in a
> huge environment and you make it bootstrap itself. The environment/project
> is defined and all parts need to work together. I'm looking for help doing
> simple tasks. I have a lot of bash scripts but there is a border of
> complexity where shell scripts become a pain in the spine. And even more
> important I'm faster with smalltalk then with bash so I just need an easy
> entrance to the world/image here.
> I did some of this in the past with preloaded code that can be triggered
> by commandline handlers. But you get easily the problem that you need to
> load new code in the image before you can use it from the commandline which
> somewhat defeats the purpose. I would like something in between: Having
> supporting code in the image but I'm also able to do the same scripts from
> the shell. So you can easily move responsibility of things between
> commandline and image.
>
> Norbert
>
> Am 24.07.2014 um 16:07 schrieb Dale Henrichs <
> dale.henri...@gemtalksystems.com>:
>
> Norbert,
>
> I've just recently made the decision to start using Pharo3.0 to do all of
> the heavy lifting  for my GsDevKit project[1] shell scripts.
>
> I use boilerplate bash code to setup the environment[2] and then call
> Pharo CommandLineHandler[3] to do the real work ...
>
> I embed the script repository[4] in the project, so the script code
> matches the directory structure and I build the command line pharo image[5]
> as part of my installation.
>
> I've been pretty pleased with the results, too. It's pretty
> straightforward to run the scripts from within an interactive Pharo for
> debugging and it beats the heck out of trying to do *simple things* with
> bash...
>
> My only wish is that CommandLine had better getopts support - I have a
> posix getopts commandline parser implementation that iI use for tODE that
> I'd be willing to share ... hint hint:).
>
> Dale
>
> [1]
> https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-gemstones-64-bit
> [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone
> [3]
> https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82
> [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository
> [5]
> https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L67-93
>
>
> On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl  wrote:
>
>> What are you using to do jobs on the commandline. I'm sick of doing bash
>> and sed,perl,jq,... stuff. What would be the quickest start when using a
>> normal image? And what if I want to give coral a start. Does it work in
>> 3.0? Best place to load stuff from?
>>
>> thanks,
>>
>> Norbert
>>
>>
>>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Sven,

I'm using Pharo3.0 and it appears that the .st scripts have to be located
in the same directory as the image and changes files  ... I see that you
are using Pharo4.0 ...

So is it possible to get Pharo3.0 to work on .st files in arbitary
directores?

Dale


On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe  wrote:

>
> On 24 Jul 2014, at 16:34, p...@highoctane.be wrote:
>
> > One question I have is how fast the load of an image and processing by
> an image is when compared with bash.
>
> Obviously, it is slower, there is a whole image that needs to be loaded,
> etc.
>
> $ cat test.st
> #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo
> --headless /Users/sven/tmp/pharo4/Pharo.image st --quit
> FileStream stdout nextPutAll: 42 factorial asString; cr.
>
> $ time ./test.st
> 14050061177528798985431426062445115699363840
>
> real0m0.644s
> user0m0.516s
> sys 0m0.067s
>
> So about half a second overhead.
>
> Sven
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Sven,
Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get
the following (it works if I `cp ./test.st
/Users/daleh/gsDevKitHome/pharo`):

nehalem:junk daleh$ pwd
/Users/daleh/junk
nehalem:junk daleh$ cat test.st
#!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo
--headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit
FileStream stdout nextPutAll: 42 factorial asString; cr.
nehalem:junk daleh$ ./test.st
FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st
FileHandle>>streamError
FileHandle>>readStream
FileSystem>>readStreamOn:
FileReference>>readStream
FileReference(AbstractFileReference)>>readStreamDo:
STCommandLineHandler>>installSourceFile:
STCommandLineHandler>>installSourceFiles in Block: [ :reference | self
installSourceFile: reference ]...etc...
OrderedCollection>>do:
STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [
:reference | self installSourc...etc...
BlockClosure>>ensure:
STCommandLineHandler>>installSourceFiles
STCommandLineHandler>>activate
STCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in
Block: [ aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self
handleArgument: (self arguments ifEmpty: [ ...etc...
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler class>>activateWith: in Block: [ super
activateWith: aCommandLine ]
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
MorphicUIManager>>spawnNewProcess in Block: [ ...



On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe 
wrote:

>
> On 25 Jul 2014, at 21:25, Dale Henrichs 
> wrote:
>
> > Sven,
> >
> > I'm using Pharo3.0 and it appears that the .st scripts have to be
> located in the same directory as the image and changes files  ... I see
> that you are using Pharo4.0 ...
> >
> > So is it possible to get Pharo3.0 to work on .st files in arbitary
> directores?
>
> Are you using the shebang or direct version ?
> In any case, I am always using absolute paths.
> Does that not work for you ?
>
> > Dale
> >
> >
> > On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe 
> wrote:
> >
> > On 24 Jul 2014, at 16:34, p...@highoctane.be wrote:
> >
> > > One question I have is how fast the load of an image and processing by
> an image is when compared with bash.
> >
> > Obviously, it is slower, there is a whole image that needs to be loaded,
> etc.
> >
> > $ cat test.st
> > #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo
> --headless /Users/sven/tmp/pharo4/Pharo.image st --quit
> > FileStream stdout nextPutAll: 42 factorial asString; cr.
> >
> > $ time ./test.st
> > 14050061177528798985431426062445115699363840
> >
> > real0m0.644s
> > user0m0.516s
> > sys 0m0.067s
> >
> > So about half a second overhead.
> >
> > Sven
> >
>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Sven,

It was just that in your example you didn't mention that the .st file had
to be in the image directory and I was sorta hoping that there was a real
solution to that problem ...

It does mean that for gsDevKit I will still need to use bash wrapper files
for all scripts that may be copied to arbitrary locations on disk ... oh
well ...

If that problem gets fixed, I will convert gsDevKit to use pharo-based
scripts for almost everything:)

Dale


On Fri, Jul 25, 2014 at 1:05 PM, Sven Van Caekenberghe  wrote:

> Yes, for some reason, the shebang (#!) machinery passes ./test2.st as
> argument to pharo, which it seems can only be resolved if it is in the
> image directory (as opposed to the current shell directory).
>
> I have no time to look at this now, but I vaguely remember that pharo
> mixed the concept of current working directory and image directory (at
> least in some places).
>
> On 25 Jul 2014, at 21:43, Dale Henrichs 
> wrote:
>
> > Sven,
> > Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I
> get the following (it works if I `cp ./test.st
> /Users/daleh/gsDevKitHome/pharo`):
> >
> > nehalem:junk daleh$ pwd
> > /Users/daleh/junk
> > nehalem:junk daleh$ cat test.st
> >
> #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo
> --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit
> > FileStream stdout nextPutAll: 42 factorial asString; cr.
> > nehalem:junk daleh$ ./test.st
> > FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st
> > FileHandle>>streamError
> > FileHandle>>readStream
> > FileSystem>>readStreamOn:
> > FileReference>>readStream
> > FileReference(AbstractFileReference)>>readStreamDo:
> > STCommandLineHandler>>installSourceFile:
> > STCommandLineHandler>>installSourceFiles in Block: [ :reference | self
> installSourceFile: reference ]...etc...
> > OrderedCollection>>do:
> > STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [
> :reference | self installSourc...etc...
> > BlockClosure>>ensure:
> > STCommandLineHandler>>installSourceFiles
> > STCommandLineHandler>>activate
> > STCommandLineHandler class(CommandLineHandler class)>>activateWith:
> > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in
> Block: [ aCommandLinehandler activateWith: commandLine ]
> > BlockClosure>>on:do:
> > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
> > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
> > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
> > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [
> self handleArgument: (self arguments ifEmpty: [ ...etc...
> > BlockClosure>>on:do:
> > PharoCommandLineHandler(BasicCommandLineHandler)>>activate
> > PharoCommandLineHandler>>activate
> > PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
> > PharoCommandLineHandler class>>activateWith: in Block: [ super
> activateWith: aCommandLine ]
> > WorldState>>runStepMethodsIn:
> > WorldMorph>>runStepMethods
> > WorldState>>doOneCycleNowFor:
> > WorldState>>doOneCycleFor:
> > WorldMorph>>doOneCycle
> > MorphicUIManager>>spawnNewProcess in Block: [ ...
> >
> >
> >
> > On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe 
> wrote:
> >
> > On 25 Jul 2014, at 21:25, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
> >
> > > Sven,
> > >
> > > I'm using Pharo3.0 and it appears that the .st scripts have to be
> located in the same directory as the image and changes files  ... I see
> that you are using Pharo4.0 ...
> > >
> > > So is it possible to get Pharo3.0 to work on .st files in arbitary
> directores?
> >
> > Are you using the shebang or direct version ?
> > In any case, I am always using absolute paths.
> > Does that not work for you ?
> >
> > > Dale
> > >
> > >
> > > On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe 
> wrote:
> > >
> > > On 24 Jul 2014, at 16:34, p...@highoctane.be wrote:
> > >
> > > > One question I have is how fast the load of an image and processing
> by an image is when compared with bash.
> > >
> > > Obviously, it is slower, there is a whole image that needs to be
> loaded, etc.
> > >
> > > $ cat test.st
> > > #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo
> --headless /Users/sven/tmp/pharo4/Pharo.image st --quit
> > > FileStream stdout nextPutAll: 42 factorial asString; cr.
> > >
> > > $ time ./test.st
> > > 14050061177528798985431426062445115699363840
> > >
> > > real0m0.644s
> > > user0m0.516s
> > > sys 0m0.067s
> > >
> > > So about half a second overhead.
> > >
> > > Sven
> > >
> >
> >
> >
>
>
>

Re: [Pharo-users] Commandline

[Dale Henrichs]

Oh! That might just do the trick for me...

Turns out that I've got one more problem in that the gsDevKit pharo vm
and/or gsdevkit image files can be installed in arbitrary locations ... for
this one I guess I need to consider installing pharo and pharo-ui in
/usr/local/ ... will work for Linux and Mac ... for Windows, I'm already
jumping through some ugly hoops...

Thanks Thierry and Sven!

Dale


On Fri, Jul 25, 2014 at 1:53 PM, Thierry Goubier 
wrote:

> You can try to get the current working directory this way:
>
> argumentsAsFileReferences
> |pwd |
> pwd := (Smalltalk os environment at: 'PWD' ifAbsent: [ Smalltalk os
> environment at: 'CD' ]) asFileReference.
> ^ self argumentsWithoutOptions collect: [ :each | pwd resolveReference:
> each asFileReference ]
>
> This works when passing arbitrary files as argument to a shell script
> doing an exec on arbitraryPath/pharo afterwards.
>
> (This is how GitFileTree-MergeDriver handles being called by git with file
> paths).
>
> Now, it would be necessary to fix that on the default .st loading :)
>
> Thierry
>
> Le 25/07/2014 22:05, Sven Van Caekenberghe a écrit :
>
>  Yes, for some reason, the shebang (#!) machinery passes ./test2.st as
>> argument to pharo, which it seems can only be resolved if it is in the
>> image directory (as opposed to the current shell directory).
>>
>> I have no time to look at this now, but I vaguely remember that pharo
>> mixed the concept of current working directory and image directory (at
>> least in some places).
>>
>> On 25 Jul 2014, at 21:43, Dale Henrichs 
>> wrote:
>>
>>  Sven,
>>> Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I
>>> get the following (it works if I `cp ./test.st
>>> /Users/daleh/gsDevKitHome/pharo`):
>>>
>>> nehalem:junk daleh$ pwd
>>> /Users/daleh/junk
>>> nehalem:junk daleh$ cat test.st
>>> #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo
>>> --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit
>>> FileStream stdout nextPutAll: 42 factorial asString; cr.
>>> nehalem:junk daleh$ ./test.st
>>> FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st
>>> FileHandle>>streamError
>>> FileHandle>>readStream
>>> FileSystem>>readStreamOn:
>>> FileReference>>readStream
>>> FileReference(AbstractFileReference)>>readStreamDo:
>>> STCommandLineHandler>>installSourceFile:
>>> STCommandLineHandler>>installSourceFiles in Block: [ :reference | self
>>> installSourceFile: reference ]...etc...
>>> OrderedCollection>>do:
>>> STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [
>>> :reference | self installSourc...etc...
>>> BlockClosure>>ensure:
>>> STCommandLineHandler>>installSourceFiles
>>> STCommandLineHandler>>activate
>>> STCommandLineHandler class(CommandLineHandler class)>>activateWith:
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
>>> in Block: [ aCommandLinehandler activateWith: commandLine ]
>>> BlockClosure>>on:do:
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [
>>> self handleArgument: (self arguments ifEmpty: [ ...etc...
>>> BlockClosure>>on:do:
>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activate
>>> PharoCommandLineHandler>>activate
>>> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
>>> PharoCommandLineHandler class>>activateWith: in Block: [ super
>>> activateWith: aCommandLine ]
>>> WorldState>>runStepMethodsIn:
>>> WorldMorph>>runStepMethods
>>> WorldState>>doOneCycleNowFor:
>>> WorldState>>doOneCycleFor:
>>> WorldMorph>>doOneCycle
>>> MorphicUIManager>>spawnNewProcess in Block: [ ...
>>>
>>>
>>>
>>> On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe 
>>> wrote:
>>>
>>> On 25 Jul 2014, at 21:25, Dale Henrichs >> com> wrote:
>>>
>>>  Sven,
>>>>
>>>> I'm using Pharo3.0 and it appears that the .st scripts have to be
>>>> located in t

Re: [Pharo-users] Managing updates/patches in Pharo with Metacello

[Dale Henrichs]

Esteban,

Take a look at the ConfigurationOfSeaside[1] in particular look at the
`symbolic versions` protocol and note the release* symbolic versions:

  bleedingEdge:
  development:
  release30:
  release31:
  release3:
  stable:

By using a version specific symbolic version you can get your cake and eat
it to.

In you case you would create version 2.1.1 with the bugfix and then update
the
 release2 and release21 symbolic versions to point to 2.1.1.

In you project load specification if you are interested in using the latest
2.1 then use #release21 and you will always get the latest bugfixes.

 On the other hand if you have gone into production with version 2.1 (as
opposed to #release21), then you do not want version 2.1.1 loaded until
you've validated the changes 

It's possible that a user of your project has chosen a different solution
to the bug and your fix would break their fix, so you should never modify a
version that has been released.

Dale

[1] http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main


On Fri, Aug 8, 2014 at 7:14 AM, Esteban Lorenzano 
wrote:

>
> On 08 Aug 2014, at 16:13, Esteban Lorenzano  wrote:
>
>
> On 08 Aug 2014, at 15:31, Esteban A. Maringolo 
> wrote:
>
> I know this is the proper way of doing it according to semantic
> versioning.
> I was afraid of populating the Metacello config with lots of #version21:
> #version211: #version212, etc.
> But I also should be able to load a version with the bug, so I guess this
> is way.
>
> But... how do I load the latest "released" version of 2.1 ?
>
> Ej:
> I have:
> - 2.1.3 (released)
> - 2.2.4 (released)
> - 2.3... (development)
>
> If I want to load the latest released version of 2.1, how do I do it
> without knowing if the latest is 2.1.3 or 2.1.15?
>
>
> mmm… normally, you would move your stable symlink to the newer version.
> or you can load explicitly.
> or you can use something with #latestVersionMatching: and siblings (but
> this one I don’t know, I never used them).
>
>
> forget it:
>
> ConfigurationOfBlah project latestVersion: #release.
>
> that will answer you the latest release version.
>
> Esteban
>
>
> Esteban
>
>
> Regards!
>
>
> Esteban A. Maringolo
>
>
> 2014-08-08 10:09 GMT-03:00 Esteban Lorenzano :
>
>> well… my advice is to use semantic versioning (http://semver.org).
>>
>> in essence:
>> - a package commit is just a commit. The number is a commit number (bah..
>> is a little more complicated because the commit info is author-number, but
>> you got the idea).
>> - metacello configurations work as distribution artifacts, so they should
>> have an unique and unrepeatable number (unless you are using git and
>> baselines, in which case it changes). So you should not change the old
>> version. Instead, you should add a patch number.
>> In your case:
>>
>> 2.1
>> will become:
>> 2.1.1
>>
>> and then you can move the #stable symbolic version to 2.1.1
>>
>> Esteban
>>
>> On 08 Aug 2014, at 14:53, Esteban A. Maringolo 
>> wrote:
>>
>> > Hi,
>> >
>> > How do you manage released versions updates in Metacello?
>> >
>> > E.g.
>> >
>> > I have a version 2.1, with its spec with a dependency to
>> 'PackageA.11.mcz'.
>> > Later I find a bug which requires a new version of PackageA.11.mcz,
>> everything goes ok as in the development/bleedingEdge version, which
>> doesn't specify the file name, but how should I "backport" the change?
>> >
>> > What I am doing now is changing the version spec for '2.1' and updating
>> the reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but I'm afraid
>> this isn't the proper way of doing this.
>> >
>> > How do you manage this?
>> >
>> > In git I'd merge the commit in the 2.1 version branch, and then the CI
>> that depends on such branch would incorporate the change.
>> >
>> > Regards!
>> >
>> > Esteban A. Maringolo
>>
>>
>>
>
>
>

Re: [Pharo-users] How do I trace through implementors in Pharo?

[Dale Henrichs]

Tim,

If there is a colon in one of the arguments (like in a Symbol) then the
selector parser gets confused ...

Dale


On Sun, Aug 10, 2014 at 3:13 PM, p...@highoctane.be 
wrote:

> On Sun, Aug 10, 2014 at 11:33 PM, Tim Mackinnon  wrote:
>
>> As I relearn/learn how to use Pharo, I’m struck by some of the excellent
>> changes and confounded by some of the simple things that boggle me.
>>
>> So, I wanted to follow a path through some message sends - the use of
>> #alert:title: in UIManager specifically.
>>
>> So I browser UIManager, find the method (its subclassResponsiblity) - so
>> I find other implementers (cmd+b, cmd+m) - (I’m really liking that there
>> are more keystrokes in newer Pharo’s but not liking that the same
>> operations don’t have the same bindings in different windows - e.g. in the
>> debugger - its not this!!)
>>
>> Anyway - this gives me an implementors window on TEasilyThemed - great!
>>
>> In the source, there is another msg send - ^self alert:title:configure:
>>
>> So I want to follow its implementers - I hi light the source and
>> cmd+b,cmd+m does nothing? hmmm - right click there and the context menu
>> doesn’t have an obvious way - until I spot (Extended Search…) [which by the
>> way should be shown as a submenu - like it does in the SystemBrowser).
>>
>> In this menu there is “implementers of it” - however this does nothing?
>> (this is in both Pharo 3.0 and Pharo 4.0)
>>
>> So how do you trace through method calls? Am I doing something wrong - or
>> has this been broken for a long time?
>>
>
> A workspace expression and Debug It?
>
> Now, beware of how you select the code chunk, if you do not select
> properly, it will not work.
> I tried in a fresh 3.0 and highlighting in the code pane and asking for
> implementors does work from the extended search menu.
>
> I also use spotlight often.
>
> Phil
>
>
>>
>> Tim
>>
>>
>

Re: [Pharo-users] load directive

[Dale Henrichs]

Usman,

Off topic --- I don't read all of the pharo posts on both pharo lists, 
but if you put Metacello in the subject, I have an email filter that 
alerts me and I read those (more often:) ...


What you are getting with record is what would be loaded in the image, 
so my guess is that in Pharo4.0 there are equivalent or later versions 
of all the packages that would be loaded ...


If you are interested in seeing all of the packages that would be loaded 
(without regard to packages already loaded in image) you can do the 
following:


  ((ConfigurationOfGlamour project version: #stable)
ignoreImage: true)
record loadDirective

Dale

On 09/11/2015 01:44 AM, Usman Bhatti wrote:

Tx for looking.

I did:
(ConfigurationOfGlamour project version: #stable) record loadDirective
in Moose 5.0 (pharo3) and Moose5.1(pharo4).

Here is the difference in the output. And the first (with Pharo3) is 
much more helpful because with a single command one can understand ALL 
the packages loaded. Whereas, in Pharo4, we don't get the complete 
tree and hence one has to see the list of the individual 
configurations to understand.


Pharo3
linear load :
linear load : 2.1 [ConfigurationOfGlamour]
load : ConfigurationOfGrease
atomic load : 2.1 [ConfigurationOfGlamour]
load : Glamour-Announcements-tg.5
load : Glamour-Helpers-TudorGirba.25
long list continues--
linear load : 2.162 [ConfigurationOfMondrian]
load : ConfigurationOfHealthReportProducer
linear load : 2.162 [ConfigurationOfMondrian]
load : ConfigurationOfShapeST80
atomic load : 2.162 [ConfigurationOfMondrian]
linear load : 1.7 [ConfigurationOfHealthReportProducer]
load : ConfigurationOfXMLSupport
atomic load : 1.7 [ConfigurationOfHealthReportProducer]
explicit load : XMLSupport
load : ConfigurationOfXMLSupport-monty.75
load : HealthReportProducer-Ivan_Rojas.13
load : Nile-Base-DamienCassou.81
load : Mondrian-ComplexShape-AlexandreBergel.33
long list continues--

Pharo4
linear load :
linear load : 3.3.0 [ConfigurationOfGlamour]
load : ConfigurationOfMagritte3
atomic load : 3.3.0 [ConfigurationOfGlamour]
linear load : 1.14 [ConfigurationOfRoassal2]
linear load : 11 [ConfigurationOfNeoJSON]
load : Neo-JSON-Tests-SvenVanCaekenberghe.29
linear load : 3.5.0 [ConfigurationOfMagritte3]
load : Magritte-Pharo3-Model
load : CollectionExtensions-TudorGirba.41
load : Glamour-Roassal2-Presentations-TudorGirba.38



regards.

On Thu, Sep 10, 2015 at 8:53 PM, stepharo > wrote:


(ConfigurationOfStore project version: #stable) record loadDirective

linear load :
linear load : 0.10 [ConfigurationOfStore]
linear load : 0.2 [ConfigurationOfGarage]
load : ConfigurationOfTalkFFI
linear load : 0.2 [ConfigurationOfGarage]
load : Store-StephaneDucasse.13

Re: [Pharo-users] load directive

[Dale Henrichs]

On 9/15/15 12:32 AM, Usman Bhatti wrote:
On Fri, Sep 11, 2015 at 11:06 PM, Dale Henrichs 
<mailto:dale.henri...@gemtalksystems.com>> wrote:


Usman,

Off topic --- I don't read all of the pharo posts on both pharo
lists, but if you put Metacello in the subject, I have an email
filter that alerts me and I read those (more often:) ...


Ok :)


What you are getting with record is what would be loaded in the
image, so my guess is that in Pharo4.0 there are equivalent or
later versions of all the packages that would be loaded ...


In the versions prior to Pharo4, the directive showed me all the 
packages regardless.
I would guess that happened because the packages weren't already loaded 
in the image prior to Pharo4.0 ...


During a Metacello load there are two passes made a `fetch` and `load` 
pass ... the `fetch` pass produces a loadDirective and the `load` pass 
executes the loadDirective ... the `record` command (without 
`ignoreImage: true`) simply runs the `fetch` pass and returns the 
loadDirective (it also doesn't bother fetching the packages) I do it 
this way so that the same code is used whether you are doing a `fetch` 
or a `record` and reduces the changes for you to get different results 
from both commands ...


Dale

Re: [Pharo-users] Adding a #development version of a Git project in the catalog

[Dale Henrichs]

On 09/21/2015 06:31 AM, Damien Cassou wrote:

Yuriy Tymchuk  writes:


Can you simply define symbolic version as a normal one?


when I tried I got an error message. Metacello was trying to parse
'development' as a semantic version number
You can implement #versionNumberClass in your configuration or baseline 
to switch version number parser to MetacelloVersionNumber which is less 
picky:)


  versionNumberClass
^ MetacelloVersionNumber

Re: [Pharo-users] Adding a #development version of a Git project in the catalog

[Dale Henrichs]

On 09/21/2015 10:46 AM, Dale Henrichs wrote:



On 09/21/2015 06:31 AM, Damien Cassou wrote:

Yuriy Tymchuk  writes:


Can you simply define symbolic version as a normal one?


when I tried I got an error message. Metacello was trying to parse
'development' as a semantic version number
You can implement #versionNumberClass in your configuration or 
baseline to switch version number parser to MetacelloVersionNumber 
which is less picky:)


  versionNumberClass
^ MetacelloVersionNumber
So using MetacelloVersionNumber does look like you can define the 
following version:


versionDev: spec
  
  spec
for: #'common'
do: [
  spec
baseline: 'Jenkins'
  with: [ spec repository: 
'github://DamienCassou/pharo-jenkins:master/src' ];

import: 'Jenkins' ]

and then use a standard symbolic version definition:

development: spec
  
  spec for: #'common' version: 'dev'

Dale

Re: [Pharo-users] Pharo - database without database

[Dale Henrichs]

Adam,

Keep an eye on the GLASS list[1] for an upcoming (within 2 months - I 
promise:) announcement about GsDevKit_home (not to be confused with 
gsDevKitHome:)... as it will provide much needed support for 
creating/starting/managing multiple GemStone stones If you are 
interested in working with GemStone:)


Dale

[1] http://forum.world.st/GLASS-f1460844.html

On 09/28/2015 12:48 PM, Adam wrote:

Hello,

Yes, I was confused by some old discussion. New licence is different. Thanks
for correction.

Adam.

Dne Po 28. září 2015 12:17:19, Stephan Eggermont napsal(a):

On 27-09-15 18:47, Adam wrote:

1) Object memory limit: Current object memory of Pharo is limited to 4GB.
Free version of GemStone/S is also limited to 4GB, so I would rather
stick with Pharo until I reach this level. And in the future this limit
grow due to 64bit version of VM.

The information on GemStone seems incorrect.
https://gemtalksystems.com/licensing/
What I read there is that the Limited (email address required) license
supports 50 GB of (on-disk) objects, with a 2GB shared page cache.

Stephan

Re: [Pharo-users] Fossil and Filetree

[Dale Henrichs]

This is good to hear 

I am pro-git, because well you have to pick an SCM to talk about and I 
do think that the collaboration tools for open source projects on github 
are superior to anything else...


Git other than that I am glad that folks are finding that FileTree is 
working for other disk-based SCMs --- because that really is the point 
of FileTree:)


It should also be possible to copy packages back and forth between a 
git-managed FileTree repository and a Fossil-managed Filetree repositor...


Dale

On 10/20/2015 02:09 AM, Hilaire wrote:

Hi,

I have been trying Fossil with Filetree, and I was rather please by the
mutuals use of these tools. So I may share a few feedbacks.
Fossil[1] itself is a software to manage source code development. It is
very simple to install and data is saved in a single sqlite database. It
comes with source code management, bug tracker, web interface, wiki and
timeline tools.

I was a bit afraid by the filetree atomic commit (one file per method)
to manage it without much headache with file based VCS. However fossil
comes with a nice command: 'fossil addremove' to add/remove the changed
files in the repo. So it went fine.

So all in all, it is pretty nice if one want to move to a private souce
code management system with very little requirement.

Hilaire

[1] http://www.fossil-scm.org

Re: [Pharo-users] Fossil and Filetree

[Dale Henrichs]

Hilaire, if you are interested in contributing, I would be willing to 
add you to the FileTree project up on GitHub ... Oops, unless you don't 
want to be:)


Dale

On 10/22/2015 01:40 AM, Hilaire wrote:

Le 21/10/2015 22:03, Thierry Goubier a écrit :

Just use the ConfigurationOfGitFileTree available in your
Configuration browser in the image ;)

Or

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

Thierry

Okay, thanks.
Not sure I can handle it right now, there are a lot of know-how about
git and fossil implicated.

Hilaire

Re: [Pharo-users] Fossil and Filetree

[Dale Henrichs]

Thierry and Hilaire,

If you want to work together up on the github repo, that's up to you and 
Hilaire, if you have a github id, let me know and I will add you as a 
contributor on the project so that you two can work together ...


Dale

On 10/24/15 6:55 AM, Hilaire wrote:

Le 22/10/2015 10:47, Thierry Goubier a écrit :

Yes, I guess so.

Still, with all the people interested by Fossil, I think the
motivation is there. And it would be nice to see a bit of refactoring
to decouple the format from the specific commands used for the
specific VCS.

Thierry

I started to look at it creating abstracted super classes. But RB
(refactoring tool I guess) bumped on the middle, try again,  then went
fine, ouf!
Any sandbox where to commit?

Hilaire

Re: [Pharo-users] Fossil and Filetree

[Dale Henrichs]

At the end of the day, I would assume that it would be possible to run 
travis-ci tests against a fossil repository which would be very useful 
to have ... but like I said, I'm fine with whatever you guys decide...


Dale

On 10/24/15 10:12 AM, Thierry Goubier wrote:

Le 24/10/2015 18:56, Hilaire a écrit :

I was not aware filetree need to be modified as well? But wait, I can
use it right now with Fossil, so I am bit lost.


No, no. This is just the development of GitFileTree is integrated 
inside the main FileTree repository.


If you look at 
https://github.com/dalehenrich/filetree/tree/pharo4.0/repository, 
you'll find both MonticelloFileTree-Core and MonticelloFileTree-Git 
(as well as the Tests and the GitTests).


Thierry



Hilaire

Le 24/10/2015 18:44, Thierry Goubier a écrit :

Hilaire, Dale,

the easiest would be to make a fork of filetree on github, and try
from there. But a branch in the main filetree would work just as well,
with the added benefit of the travis CI integration (and gitfiletree
has tests in there). Running tests locally is often necessary, but
setting it up is a bit more involved (but I should have that in a
Makefile somewhere).

Hilaire, if you prefer a Smalltalkhub project, just do so and I'll
make regular merges back into filetree.

Thierry

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

[Dale Henrichs]

Very interesting ... if you put your project up on github, I would fork 
it and port it to tODE as this is something that has been on my todo 
list for awhile:)


Dale

On 11/23/2015 07:25 AM, Skip Lentz wrote:

Hi everyone,

As part of my internship I am creating bindings to the GitHub API in 
Pharo.
As a prototype and demo, I have created a small tool last week to do 
some basic versioning, namely checking out a version, committing a 
version and showing a log of commits along with a branch tree.


Here’s a screenshot: http://i.imgur.com/iMfWOvp.png

The repository of the bindings and the tool is here: 
http://smalltalkhub.com/#!/~Balletie/GitHub 


To load the tool into your image, execute:

(ConfigurationOfGitHub project version: #development) load: #tool

Keep in mind that this is tied to GitHub, since internally it uses the 
API. A nice side effect of this is that everything can be done 
in-memory. That is, there’s no local copy on the filesystem. One does 
not even need git installed.


That being said, feel free to take off with my prototype and make it 
work with e.g. the LibGit bindings in Pharo.


Known bug:
- When selecting a different repository from the dropdown while a 
version is also selected in the log, one gets a DNU. To work around 
this for the time being, just deselect the version before you switch 
repositories.


Let me know what you think and feel free to ask some questions.

Skip

Re: [Pharo-users] Metacello cannot download the latest zip of a github repo if a zip already exists from a previous commit

[Dale Henrichs]

On 12/13/15 6:28 AM, Dimitris Chloupis wrote:

So it looks like that when I do

Metacello new baseline: 'ChronosManager'; repository: 
'github://kilon/ChronosManager';  load


and I have ChronosManager already installed via the same command 
previously , if the repo has changed in the mean time , it wont get 
the latest zip from github and instead will use the existing zip to 
overwrite my image (Not cool at all).


Obviously a bug ?
No it is intended behavior ... to avoid downloading the entire zipped 
repository everytime you reference a project (whether or not there were 
changes up on github), the cache is not flushed unless you do a `get` 
command as follows:


  Metacello new
baseline: 'ChronosManager';
repository: 'github://kilon/ChronosManager';
get;
load

(you probably need to use the latest version of Metacello, as well)

I see that I haven't documented this feature and that is "not cool at 
all"  most of the code and documentation was written about 3 years 
ago, so users have finally caught up with me and it's time to update the 
docs:)


Dale

[1] https://github.com/dalehenrich/metacello-work/issues/380

Re: [Pharo-users] Metacello cannot download the latest zip of a github repo if a zip already exists from a previous commit

[Dale Henrichs]

On 12/13/2015 09:59 PM, Dimitris Chloupis wrote:

Thanks Dale , good news it works on Pharo 5 :)

Is there a way to delete the previous data = delete the previous zip 
file and all its decompressed folders / files ? I can do it manually 
but I was wondering if metacello offers anything similar.


You can delete the github-cache directory anytime you want, and the 
cache should be rebuilt the next time you do a build ... Metacello 
itself does not offer a service for deleting the cache directory ...


Dale

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

[Dale Henrichs]

The datacenter where the sites http://ss3.gemstone.com/ and 
http://seaside.gemtalksystems.com/ss are hosted lost their primary 
router, while the backup router was being repaired ... the machines 
hosting the two sites are up and running, so no data loss is expected.


They are working on getting another router in=place, but no ETA is known 
at this time ...


Dale

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

[Dale Henrichs]

The datacenter  network came back on-line about a 1/2 hour ago ...

Dale

On 1/18/16 3:10 PM, Dale Henrichs wrote:
The datacenter where the sites http://ss3.gemstone.com/ and 
http://seaside.gemtalksystems.com/ss are hosted lost their primary 
router, while the backup router was being repaired ... the machines 
hosting the two sites are up and running, so no data loss is expected.


They are working on getting another router in=place, but no ETA is 
known at this time ...


Dale

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

[Dale Henrichs]

Nooo, make that 2 hours ago:)

On 1/18/16 6:36 PM, Dale Henrichs wrote:

The datacenter  network came back on-line about a 1/2 hour ago ...

Dale

On 1/18/16 3:10 PM, Dale Henrichs wrote:
The datacenter where the sites http://ss3.gemstone.com/ and 
http://seaside.gemtalksystems.com/ss are hosted lost their primary 
router, while the backup router was being repaired ... the machines 
hosting the two sites are up and running, so no data loss is expected.


They are working on getting another router in=place, but no ETA is 
known at this time ...


Dale

Re: [Pharo-users] Pharo + git workflow

[Dale Henrichs]

Norbert,

If you were using a BaselineOf for your project then you could avoid the 
the configuration hack by using the Metacello lock command[1] which was 
designed to address the problem where you want to use a local git clone 
while specifying project references in the configurations using the 
github (or bitbucket) repository url


I understand that BaselineOf support is missing from versionner, but 
until the rest of the tool chain is in place, you will have to trade off 
where you want to "insert hacks" ... it may be easier to hand edit the 
BaselineOf when adding a new package or project dependency, than 
constantly hack configurations because you aren't using a BaselineOf  
--- but then that's up to you:)


Dale

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


On 01/28/2016 09:39 AM, Norbert Hartl wrote:

Finally I got something working for me. It is not generally applicable but at 
the moment I'm happy this works at least. I made it even harder because I store 
the smalltalk code in a sub directory because I want to version web resources 
along with the code. The smalltalk code is in a sub directory st/

development desktop
- - - - - - - - - - - - - - - -

Normal GitFileTree workflow:

- Take a pharo4 image and load the configuration of GitFileTree from the 
Configuration Browser.
- Open Versionner then select GitFileTree and click on development and then 
load version (via context menu). This is IMHO only needed if you want to access 
bitbucket
- Checkout your repository
- Create GitFileTree repository and select directory of checked out repository
- If a ssh key is configured in bitbucket and for the local ssh-agent commit, 
pull, push should work via monticello browser

jenkins
- - - - -

In the jenkins build I like to avoid GitFileTree because I prefer having 
neither GitFileTree nor OSProcess installed in my deployment artefacts

- Configure jenkins git plugin to check out the code repository
- add a shell command consisting

pharo-vm-nox project.image config "filetree://$WORKSPACE/st" 
ConfigurationOfProject --install=bleedingEdge

- this has access to the ConfigurationOfProject but only to this class
- Add

spec repository: 'filetree://st/'

   to the baseline of the ConfigurationOfProject. This way metacello can load 
the rest of the packages.

The good news is that I can have a full powered GitFileTree enabled version for 
developing and a OSProcess-less version for deployment. And I can use 
Versionner as I rely on the ConfigurationOf. But especially the spec repository 
setting in the ConfigurationOfProject is a bad hack. Another solution to this 
would be welcomed. This works only if all packages are in the same git 
repository.
I need to try access that stuff via bitbucket:// url in the metacello baseline. 
Thierry just added support to put credentials in the url so it might work with 
downloading read-only versions of the repository.

Norbert


Am 25.01.2016 um 18:09 schrieb Norbert Hartl :

I'm eager to try a new project with some git repositories. But to be honest I 
don't really get it. Searching the web there is lots to find but nothing actual.

I don't understand if it is ok to use a ConfigurationOf or if it only works 
with a BaselineOf. And how do you specify the repository in a ConfigurationOf 
in order to be able to work locally as well as having jenkins pull everything 
automatically? Same goes for dependent projects.

Are there any insights to this or pointers to an up-to-date documentation?

thanks,

Norbert

Re: [Pharo-users] Huge image

[Dale Henrichs]

David,

I don't have a direct solution, but I have been playing with an analysis 
technique for solving this particular type of problem: scads of Strings 
and a need to "make sense of the reference graph".


If you look at this example[1], you'll see that there are 202K instances 
of String (this example is from a GemStone db). the nodes pointing to 
the String node, show that of the 202K strings, there are 70K instances 
of Array referencing one or more of the 202k strings; 47K instances of 
MCVersionInfo  and 43K MethodVersionRecord instances.


I've found that this approach can help you understand why you have so 
many strings ...


The basic technique is to gather the instances of String, then for each 
instance of string, gather the collection of objects that reference the 
String instance and summarize the reference by class instance count and 
keep an IdentitySet of the instances referencing Strings by class so 
that you can build the next level of references 


 For GemStone, this information is displayed using Roassal2 and the 
calculations are done by scanning a backup of the repository...


You could probably brute force calculate this in Pharo (be sure to 
isolate the objects that you are using in your analysis from the set of 
objects being analyzed otherwise things get out of control ...


HTH,

Dale


[1] 
https://github.com/dalehenrich/obex#class-instance-counts-based-on-selected-set-of-instances

Re: [Pharo-users] Metacello reverse project dependency

[Dale Henrichs]

Peter,

Very good summary ...

First off, Metacello doesn't support circular project dependencies. 
Secondly, there is supposed to be a "cucularity detector" in Metacello 
that avoids going into an infinite loop, but in retrospect, the detector 
has not been tested with Baselines - I have submitted a bug[1]


Presumably in your second scenario all of the packages load correctly, 
except that the extensions methods are not loaded ... is that correct?


I think you should be able to address your problem by using the #atomic 
load type, by adding the following method to each of your baselines:


project
  ^ project
ifNil: [
  project := super project.
  project loadType: #'atomic'.
  project ].

The default #linear load type loads each package individually. The 
#atomic load type loads all of the accumulated definitions at one time 
and missing dependencies like the one you are seeing should be resolved 
by load time ... The accumulation of definitions crosses project boundaries.


I've submitted a bug to make changing the default load type a bit 
easier[2] ... sometimes I wish that I made #atomic load the default, but 
it is hard to change defaults in midstream without causing lots of 
breakage...


Let me know if this addresses your issue.

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/383
[2] https://github.com/dalehenrich/metacello-work/issues/384

On 2/16/16 12:33 AM, Peter Uhnák wrote:

Unfortunately #includes: doesn't seem to matter and I still get errors.

I tried to somehow summarize my findings with minimal code & results 
here http://peteruhnak.com/metacello/


On Mon, Feb 15, 2016 at 11:31 PM, Werner Kassens > wrote:


Hi Peter,
have you looked at metacellos #includes: method?
from
https://code.google.com/archive/p/metacello/wikis/APIReference.wiki :
"When 'Example-AddOn' is loaded, load 'Example-UI'"
includes: #('Example-UI' );
werner

On 02/13/2016 11:26 PM, Peter Uhnák wrote:

Hi,

I have the following situation:

I have ProjectMain, and ProjectPlugin, now normally the Plugin
depends
on Main, however I would like to load Plugin as part of Main.

The problem is that I can't specify to load Plugin after Main
has been
already fully loaded, if I do something like this

BaselineOfMain>>baseline: spec

spec
for: #common
do:
[ spec
baseline: 'Plugin'
with: [ spec
repository: '...';
loads: #('default' OR 'plugin') ].
spec
package: 'Main' with: [ spec requires: #(more stuff) ];
spec group: 'default' with: #('Main').
specgroup: 'complete' with: #('default' 'Plugin') ]

The BaselineOfPlugin has two groups… "default", which loads
also "Main",
and "plugin", which doesn't.

Now the problem is that there is no guaranteed way that Plugin
will load
after Main (in fact the should happen). If I load the plugin's
#default,
then Metacello ends up in an endless loop for some reason, and
if I load
#plugin, then it will load it before the Main which will break it
(because Plugin has dependencies on main).

So my question is:
is it possible to reverse it somehow?
Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and
then in
that method manually load the plugins with Metacello/Gofer? Or
is there
a better way?

Thanks,
Peter

Re: [Pharo-users] another Metacello question

[Dale Henrichs]

Sorry about that Werner ... I had been getting my mail forwarded from 
the Metacello Group to my work email and apparently a year ago, the mail 
(silently) stopped being forwarded, so I was none the wiser until you 
mentioned it just now ... and I've approved your membership request 
along with several others that had queued up ...


It would be easier for me to understand what you are proposing with an 
actual example of spec - the way that you'd like to see it...


Also I don't quite understand what you mean by "no git involved" are you 
using a filetree:// repo or an mcz repository or what ... Metacello 
knows about github:// repos but as far as Metacello is concerned a "git 
repo" is just a filetree repo ...


Dale


On 2/16/16 10:04 AM, Werner Kassens wrote:

Hi Dale,
since you are reading this forum, may i ask you another qestion here 
(btw i asked for access to the metacello forum, i dont know, a year 
ago or so but didnt get it)? assumed i have a project (with a config) 
in a baseline and several packages in that baseline with dependencies 
on specific packages of this project. with that #import: method i 
could model this dependencies of course, but i guess #import: is only 
for git-baselines, or? if this is correct, is there a possibility to 
model these dependencies without making a special project for each of 
these? or simpler: project consists of packA & packB, my baseline 
consists of project (only via its config) and packC & packD, packC 
depends on packB, and packD depends on packA. now i want to load eg 
packD via my baseline and this should of course load also packA but 
not packB. (and no git involved.)

werner

Re: [Pharo-users] another Metacello question

[Dale Henrichs]

Werener,

Here's an example of the use of #import:provides: from my tests that 
might be in the area you are interested in:


 spec
for: #'common'
do: [
  spec description: self name , '>>configuration092Issue63:'.
  spec
baseline: 'External'
  with: [
  spec
repository:
  'github://dalehenrich/external:' , 
MetacelloScriptingResource externalCustomSHA

, '/repository' ];
package: 'GoferBar'
  with: [
  spec
file: 'GoferBar-lr.1';
requires: 'External-Core';
repository: 
'dictionary://Metacello_Gofer_Test_Repository' ];

package: 'GoferFoo'
  with: [
  spec
file: 'GoferFoo-lr.2';
requires: 'External-Tests';
repository: 
'dictionary://Metacello_Gofer_Test_Repository' ];

import: 'External' provides: #('External-Core' 'External-Tests') ]

the feature was create for use with baseline project refs and my test 
cases all involve baselines, but I don't think that the feature is 
necessarily restricted to use with baseline projects ... BTW, the 
#import:provides: was created so that you could import specific 
packages/groups from more than one baseline and to also avoid importing 
group names from a baseline that may already exist in the project ...


Dale

On 2/16/16 10:04 AM, Werner Kassens wrote:

Hi Dale,
since you are reading this forum, may i ask you another qestion here 
(btw i asked for access to the metacello forum, i dont know, a year 
ago or so but didnt get it)? assumed i have a project (with a config) 
in a baseline and several packages in that baseline with dependencies 
on specific packages of this project. with that #import: method i 
could model this dependencies of course, but i guess #import: is only 
for git-baselines, or? if this is correct, is there a possibility to 
model these dependencies without making a special project for each of 
these? or simpler: project consists of packA & packB, my baseline 
consists of project (only via its config) and packC & packD, packC 
depends on packB, and packD depends on packA. now i want to load eg 
packD via my baseline and this should of course load also packA but 
not packB. (and no git involved.)

werner

Re: [Pharo-users] Use Shell Command from Pharo

[Dale Henrichs]

I seem to recall that on the mac there was a system option of some sort 
that "launches apps from a sensible" location --- of course the Apple 
powers that be may have removed that capability recently...


Dale

On 3/19/16 9:41 AM, Damien Pollet wrote:
On 19 March 2016 at 16:45, Peter Uhnák > wrote:


I don't actually see the reason why it should assume root folder
if you don't specify a path… that's stupid on many levels (I blame
mac).


It's root because that's where the system launches applications from, 
when you double-click them in the Finder (or via the open command, I 
think). You'll see that GUI-launched images do not inherit your shell 
environment either.


However, if you run pharo from command-line, you get the usual unix 
behavior.


On Linux you get home, although that's imho also wrong and it
should use the folder of the image… but maybe that's a
misconfiguration of OSProcess.


No, it's the same logic than on Mac (albeit $HOME is arguably a little 
more sensible than the filesystem's root).


I'm not sure what's the correct behavior here, unless there is a way 
to know if pharo was launched from GUI (where working directory is 
meaningless and pharo should probably chdir() to the image directory) 
or from command-line (where the working directory is meaningful and 
should be honored. On OSX, maybe there's a way to pass GUI-specific 
arguments, through the Info.plist file?

Re: [Pharo-users] BaselineOf's and Loose Dependencies

[Dale Henrichs]

First, congratulations!

A baseline is associated with a "git version", so there is no need to 
"pin the version down in a specific version" ... in a "git project" you 
have the option of changing the specific version associated with a 
baseline on "every commit" 


So you would specify the BabyMock project as you would in the baseline*: 
method from your ConfigurationOf and "override" the versionString in place:


 spec
configuration: 'BabyMock'
with: [
  spec
versionString: '1.2';
repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ]

Note, that I'm using the more modern form of project specification 
the above is equivalent to:


  spec
project: 'BabyMock'
with: [
  spec
className: #'ConfigurationOfBabyMock';
versionString: '1.2';
repository ]

Dale

On 3/21/16 8:15 AM, Sean P. DeNigris wrote:

I know this is not technically a Pharo question, but I'm in China on my
honeymoon and can't access the Metacello Google group!

There was a pattern in pre-BaselineOf Metacello where one would define
dependencies loosely in the #baselineXyz:, and then pin them to a specific
version in the #versionAbc:.

For example:
baseline100: spec
...
project: 'BabyMock' with: [
spec
className: #ConfigurationOfBabyMock;
versionString: #'stable';
repository: 
'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ]
...
and then:
version10: spec
...
spec
project: 'BabyMock' with: '1.2'
...

How does one handle this sort of thing with #baseline:import:?

This is what I came up with:
version10: spec
...
baseline: 'BabyPhexample'
with: [
  spec
repository:

'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ];
import: 'BabyPhexample'.
spec
project: 'BabyMock' with: '1.2'
...
But I got this error from the last line: MessageNotUnderstood: receiver of
"fetchUsing:" is nil

Thanks.




-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] BaselineOf's and Loose Dependencies

[Dale Henrichs]

Sean (and others) I don't always keep up-to-date with the posts on the 
pharo list, so if you have a Metacello-related question, put Metacello 
in the subject line and I'll have a better chance of seeing the message ...


Dale

On 3/21/16 8:15 AM, Sean P. DeNigris wrote:

I know this is not technically a Pharo question, but I'm in China on my
honeymoon and can't access the Metacello Google group!

There was a pattern in pre-BaselineOf Metacello where one would define
dependencies loosely in the #baselineXyz:, and then pin them to a specific
version in the #versionAbc:.

For example:
baseline100: spec
...
project: 'BabyMock' with: [
spec
className: #ConfigurationOfBabyMock;
versionString: #'stable';
repository: 
'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ]
...
and then:
version10: spec
...
spec
project: 'BabyMock' with: '1.2'
...

How does one handle this sort of thing with #baseline:import:?

This is what I came up with:
version10: spec
...
baseline: 'BabyPhexample'
with: [
  spec
repository:

'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ];
import: 'BabyPhexample'.
spec
project: 'BabyMock' with: '1.2'
...
But I got this error from the last line: MessageNotUnderstood: receiver of
"fetchUsing:" is nil

Thanks.




-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] BaselineOf's and Loose Dependencies

[Dale Henrichs]

On 3/21/16 9:48 AM, Sean P. DeNigris wrote:

Dale Henrichs-3 wrote

First, congratulations!

Thanks!!


Dale Henrichs-3 wrote

A baseline is associated with a "git version", so there is no need to
"pin the version down in a specific version"

Yes, but I'm not talking about a version of my main project, but a version
of a dependent project.
Right ... but you were also talking about "pinning the version of a 
dependent project in a version of your main project"  each git 
commit is a new version of your main project, the equivalent of a new 
numbered version in a configuration, so to "pin the version of a 
dependent project", you simply change the version of the dependent 
project ... which I did in the example I provided ...



Dale Henrichs-3 wrote

in a "git project" you
have the option of changing the specific version associated with a
baseline on "every commit" 

Again, yes, but what I want to do (and what I understood as best practice in
the past) is to defer the linking to a specific version until I release a
stable version of my main project.
Okay ... in a git environment, the master branch of your project is the 
stable version and you do development on a separate "topic branch"  like 
`dev` or `issue_88`.

That is, while I'm developing, I can be
much looser with my tracking of loose dependencies, e.g. commonly it is
enough to specify that I always want #stable. Of course, symbolic
dependencies are not a good idea for release versions, so I will want to
override the loose dependency with a specific numbered version.
As I've said elsewhere I think that a symbolic version scheme based on 
versions (#release3, #release3.1, #release3.1.2, etc.) is superior to 
#stable for Monticello-based projects (those using ConfigurationOf) and 
it your dependent project used this scheme, there would be no need to 
"override the loose dependency with a specific numbered version".


If the dependent project doesn't use this scheme then you are stuck with 
using "specific numbered versions" ...


That means that on branch `dev` you'll change the version of the project 
to #stable and do your work, when you are preparing to merge your work 
on `dev` into the master branch, you will choose a "specific numbered 
version", replace #stable with the the numbered version, test, merge to 
`master` branch.


The next time you start work on a new topic branch, you can choose to 
use #stable, or simply select the latest numbered version explicitly and 
develop away ... before merging to master in this scheme, just double 
check if there is new version availble and if not, you're good to go ...

Unfortunately, while I'm no longer getting the mentioned error, my override
seems to be ignored - `ConfigurationOfBabyPhexample project stableVersion
record loadDirective.` reports that the #stable version of BabyMock (1.3)
will be loaded instead of the version 1.2 that I specified in my
configuration.
Did you use the example I provided or did you continue to try to use the 
original spec? The spec you provided didn't make sense to me (I figured 
it was copy paste errors)...


I created an issue in my GitHub project where it might be easier to
reference the code (https://github.com/seandenigris/Baby-Phexample/issues/1)
or we can continue to discuss here.

Yeah, it will be much easier to get into specific details on github ...

Dale

Re: [Pharo-users] [Metacello] Apparent loop in before / after ....

[Dale Henrichs]

Hi Stef,

Before we get too far, there is a `false ifTrue: [` statement in the 
middle of 
MetacelloPackagesSpec>>sortPackageSpecs:packageSpec:groupLoops:for:. If 
you change the false to true and then run again with the Transcript open 
to record the information ...


With these loops, you want to look for a repeating pattern near the end 
and/or pass me the output from the Transcript and let me help figure out 
the problem ...


I've started an issue[1] for this problem in case we come up with enough 
information to be able to improve the validation or at least provide 
better info than: edit this method and call Dale :)


Dale

[1] https://github.com/dalehenrich/metacello-work/issues/387

On 03/26/2016 01:56 PM, stepharo wrote:

hi dale

I'm working a pretty large configuration and I got the following error 
messsage (and I do not understand I cannot debug).
Do you have any suggestion because I did not even know that this error 
exist before.
I disabled the validation of the config because it validates packages 
that I cannot modify such as XML or SMark.


Stef

Re: [Pharo-users] [Metacello] about required list

[Dale Henrichs]

Stef,

You don't need to repeat packages in the requires statement. Requiring 
'Math-DistributionGamma' is sufficient to pick up 'Math-Core', 
'Math-DHB-Numerical', 'Math-Series', and 'Math-Core-Distribution' as 
requirements as well ... .


Dale

On 03/26/2016 02:00 PM, stepharo wrote:

Hi

using the dependency analyser I see that may packages have the 
following dependencies


for example

package: 'Math-DistributionGamma' with: [ spec requires: 
#('Math-Core' 'Math-DHB-Numerical' 'Math-Series' 
'Math-Core-Distribution') ];


package: 'Math-DistributionBeta' with: [ spec requires: 
#('Math-DistributionGamma' 'Math-Core' 'Math-Core-Distribution' 
'Math-DHB-Numerical' 'Math-Series') ];


so I wrote the requirement this way


Now does it have an impact on Metacello and should I keep only the 
direct depend.



package: 'Math-DistributionBeta' with: [ spec requires: 
#('Math-DistributionGamma' ) ];


This is annoying because I have 50 packages and doing that manually is 
a pain.


Stef

Re: [Pharo-users] Conditional external dependencies in a Metacello BaselineOf?

[Dale Henrichs]

Damien,

You want to use a a lock[1]. Look at the section on locking a 
`filetree://` repo [2]--- should be similar for locking your gitfiletree 
repo ...


When you load you may want to use `onWarningLog`, because locks do 
generate Warnings telling you the the lock is being honored (i.e., the 
load is taking place from the local clone, not github as specified in 
the baseline) ...


Dale

[1] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-command-reference
[2] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-the-projects


On 04/12/2016 11:18 AM, Damien Pollet wrote:
I have a couple projects that I develop together; the first depending 
on the second, and both managed on GitHub (in separate repositories).


The BaselineOf therefore expresses the dependency using repository: 
'github://…'
However, I'd like to locally change that to gitfiletree:// so that I 
can build new development images from scratch, with both projects 
ready to commit to gitfiletree, with minimal repo juggling and code 
reloading ?


Is there a way to achieve that? Metacello project attributes? a git 
submodule?


--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-users] Conditional external dependencies in a Metacello BaselineOf?

[Dale Henrichs]

Damien,

Peter's got the proper script ... When you lock a Metacello project, you 
are registering a repository with a project name, so no need to "load 
Baseline", the name and local repository are enogh to the job ... then 
do you normal load ... you do have to use the `Metacello new` form of 
project loading for the lock to take effect:


  Metacello new
baseline: '...';
repository: '...';
onWarningLog;
load

Peter's script is a good example ...

Dale

On 4/13/16 1:40 AM, Peter Uhnák wrote:

Yes, I've been using this approach for some time.

https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/dynacaseSettings.st



On Wed, Apr 13, 2016 at 2:24 AM, Damien Pollet 
mailto:damien.pollet+ph...@gmail.com>> 
wrote:


Oh, nice!

Just to be sure, because 2:15am is not the best time to start
playing with code… if I understood correctly, I'd load the
depended-upon baseline from gitfiletree, lock it, and then that
would take precedence over the github:// repo specified in the
baseline of the main project?

I'll try tomorrow, thanks :)

On 13 April 2016 at 00:38, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:

Damien,

You want to use a a lock[1]. Look at the section on locking a
`filetree://` repo [2]--- should be similar for locking your
gitfiletree repo ...

When you load you may want to use `onWarningLog`, because
locks do generate Warnings telling you the the lock is being
honored (i.e., the load is taking place from the local clone,
not github as specified in the baseline) ...

Dale

[1]

https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-command-reference
[2]

https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-the-projects



On 04/12/2016 11:18 AM, Damien Pollet wrote:

I have a couple projects that I develop together; the
first depending on the second, and both managed on GitHub
(in separate repositories).

The BaselineOf therefore expresses the dependency using
repository: 'github://…'
However, I'd like to locally change that to gitfiletree://
so that I can build new development images from scratch,
with both projects ready to commit to gitfiletree, with
minimal repo juggling and code reloading ?

Is there a way to achieve that? Metacello project
attributes? a git submodule?

-- 
Damien Pollet

type less, do more [ | ]
http://people.untyped.org/damien.pollet

Re: [Pharo-users] Error using metacello

[Dale Henrichs]

The following is the cross-platform (Squeak, GemStone and Pharo) way to specify 
a github repository:

  Metacello new
configuration: 'OfNeoCSV';
repository:'github://svenvc/NeoCVS:master/repository';
version: #stable;
load.

Here's a reference for the various cross-platfrom urls that can be used with 
Metacello[1]

Dale

[1] 
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScriptingAPI.md#repository-descriptions


On 5/22/16 1:32 PM, mathias arnaud nkeumo tsombeng wrote:

Hi All,

Am trying to use metacello to install some pakages onmy pharo from
github and smaltalkhub but am having some issue. here is the code am
executing on the playground

Metacello new
 configuration: 'OfNeoCSV';
 repository:'https://github.com/svenvc/NeoCVS/tree/master/repository';
 version: #stable;
 load.

here is the error i obtain.

Could not resolve: ConfigurationOfNeoCSV.

Best Regards.

A Tsombeng

Re: [Pharo-users] library for comparing semver versions

[Dale Henrichs]

The class MetacelloSemanticVersionNumber can be used to compare Semantic 
version numbers ... Note that there is an outstanding bug that 
MetacelloSemanticVersionNumber will read improperly formatted version 
numbers (fix is in the works), so it's not quite as good for validation 
(at the moment), but it should work for properly formed semantic version 
numbers ...


Dale


[1] https://github.com/dalehenrich/metacello-work/issues/392


On 5/27/16 5:21 AM, Peter Uhnak wrote:

Hi,

is there any library available that can compare versions according to
SemVer? http://semver.org/

Thanks,
Peter

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Dale Henrichs]

On 5/29/16 5:28 AM, Thierry Goubier wrote:

Le 29/05/2016 14:04, Peter Uhnak a écrit :

On Sun, May 29, 2016 at 11:21:21AM +0200, Thierry Goubier wrote:

Le 29/05/2016 11:15, Peter Uhnák a écrit :

  > All this is so that my .5 would not conflict with someone else .5

How is this a problem? Because it will be "Me.5" and "You.5", so there
can't be any conflict.


Me.5 and Me.5 are possible...

Think of numbering your own stuff on two different branches.

More, Metacello depends on Me.5 5 to be greater than You.5 5 for 
some of the

baselines / configurations to work properly :)


Can't it use the ancestry to decide?


I suggested that to Dale... Disregard version numbers, only consider 
as newer if the other is in the ancestry chain.
For FileTree repos it is even better to just load the package 
(Monticello does a good job of only loading the changed packages and 
we're looking at packages already on disk) ...  ... I have an extension 
to Metacello for Filetree repos (it's only been around for about 3 
years) that ignores version numbers and "loads" all of the packages from 
the the repo (I mentioned _this_ to Thierry:) ... which for FileTree 
repos is actually the proper behavior ... I happen to be very busy at 
the moment so I don't have time to blow the dust off of that extension 
... the big gotcha is everyone has to have the extension present in 
their image for this kind of thing to work and AFAIK pharo is not kept 
up-to-date with the latest versions that I publish on github, so I'm 
afraid that much breakage would ensure if only a few individuals started 
using this extension ... Seems to be that we're stuck between a rock and 
a had place... I wish there was a better way to keep the Metacello 
distribution up-to-date in images that I have no control over ...


FWIW, I've found that if I manually flush the cache for each package 
before I save it, I don't have to wait the minute or so for all of the 
repos to be refreshed ...


Dale

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Dale Henrichs]

In the Monticello Browser, select the repository that you will be saving 
your package to and use the "Flush cached versions" menu item ... it 
seems that you have to do it before each package save...


Dale

On 6/3/16 12:13 AM, Peter Uhnak wrote:

On Wed, Jun 01, 2016 at 10:28:12PM -0700, Dale Henrichs wrote:

FWIW, I've found that if I manually flush the cache for each package before
I save it, I don't have to wait the minute or so for all of the repos to be
refreshed ...


How can I do that?

Peter

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Dale Henrichs]

On 6/3/16 2:43 AM, Otto Behrens wrote:

For FileTree repos it is even better to just load the package (Monticello
does a good job of only loading the changed packages and we're looking at
packages already on disk) ...  ... I have an extension to Metacello for
Filetree repos (it's only been around for about 3 years) that ignores
version numbers and "loads" all of the packages from the the repo (I
mentioned _this_ to Thierry:) ... which for FileTree repos is actually the
proper behavior ... I happen to be very busy at the moment so I don't have
time to blow the dust off of that extension ... the big gotcha is everyone
has to have the extension present in their image for this kind of thing to
work and AFAIK pharo is not kept up-to-date with the latest versions that I
publish on github, so I'm afraid that much breakage would ensure if only a
few individuals started using this extension ... Seems to be that we're
stuck between a rock and a had place... I wish there was a better way to
keep the Metacello distribution up-to-date in images that I have no control
over ...

FWIW, I've found that if I manually flush the cache for each package before
I save it, I don't have to wait the minute or so for all of the repos to be
refreshed ...

Dale, will you please publish this stuff somewhere, with dust on, as
is? (Or tell us where we can find it).
Well let's see there's the Metacello-Cypress package is in the Metacello 
repo[1] and the following should load the Cypress support into an image 
with Metacello already loaded:


  Metacello image
baseline: 'Metacello';
load: ' Cypress'

To use the Cypress support, implement a #projectClass method in your 
BaselineOf that returns MetacelloCypressBaselineProject:


  projectClass
^MetacelloCypressBaselineProject

and you should be in business ...

IIRC the MetacelloCypressBaselineProject should be usable with any 
BaselineOf. The only difference for Cypress is that Monticello versions 
are ignored when making loading decisions --- at least that's the intent.


Before going full scale, we'd need to add some tests for the Cypress 
project and of course make sure that the Cypress support gets loaded by 
default ...


[1] 
https://github.com/dalehenrich/metacello-work/tree/master/repository/Metacello-Cypress.package 


We've just battled sooo much in this area. I wonder if it is worth it
to think again about this whole git / monticello / metacello thing.
For me, it's just too much to comprehend. As soon as I dig into
something here, I get lost within minutes.

I believe the complexity has to do with trying to maintain too many
different ways of solving the problem. We are trying to keep things
(Monticello / Metacello) working with or without git or filetree or
whatever else people are using.

I would really like to do merging in git and just have a fast and
simple way of loading / compiling into an image (and GemStone). I do
not want a package cache, 3 way merging and all the other things,
because it makes what I end up with unpredictable. But you see, other
people want to work in other ways, which I understand. My perception
is that the result is messy.

We should try to strive more towards *fewer* ways of doing things,
without killing innovation to try different ways. It feels as if there
are enormous, yet very incomplete silos of efforts to solve problems.


I basically agree with everything you say here.

I added the Cypress package support several years ago when Richard 
Sargent wrote a Cypress implementation for the base GemStone[2], so 
we've had the bits a pieces necessary for a cleaner simpler mechanism 
for a while at least for GemStone ...


I would like to distinguish between Cypress and FileTree.

FileTree was created (by you:) to support disk-based repos while 
maintaining full Monticello compatibility. Over the years I've 
(stubbornly) maintained that the Monticello meta data be preserved in 
FileTree repositories. By preserving Monticello meta data, the packages 
can be easily moved between FileTree and SmalltalkHub, etc. while 
faithfully preserving the Monticello ancestry. Maintaining Monticello 
meta data is critical for folks to be able to "dip their toe into the 
git pool" while preserving Monticello ancestry.


When I say "Cypress" (as opposed to FileTree), I think of a stripped 
down implementation of FileTree where Monticello meta data is not stored 
on disk and, perhaps more importantly the package loading code, in-image 
package management and tool support is also stripped down to support a 
simple model where package history and version numbers are non-existent. 
This particular model is aimed at projects that spend their entire lives 
in "git" repos and there is no desire, nor need to keep a parallel 
ancestry in the Monticello meta data and I think that what you are 
asking for ... in fact with Cypress package names do not need any 
package meta data ... the SHA of the commit is all that is needed to 
uniquely identify packages [in tODE 

Re: [Pharo-users] problem getting moose

[Dale Henrichs]

Stef,

One of advantages of using local git repositories is that once you've 
downloaded the git repo you can load code without hitting the network at 
all ... another related advantage of local git repositories is that once 
you have chosen a particular checkout (SHA) to use every single load 
will be identical as the repositories don't change unless you choose to 
change them --- you are completely insulated from the decisions that 
project maintainers may make until you explicitly choose to change your 
checkout ...


Dale

On 6/5/16 1:15 AM, stepharo wrote:

Hi ben

I got some similar behavior when the network is not good.

We should improve the loading of packages but this is simple than 
actually having a bullet proof solution.


It is a couple of years that I think about it: loading in a separate 
environment and on crash do not install


Stef


Le 5/6/16 à 08:18, Ben Coman a écrit :

On Sun, Jun 5, 2016 at 1:34 PM, Ben Coman  wrote:

I wanted to try out Peter's XMI Analyser with Roassal and went to
download Moose but had a couple of problems.

First try...
In the Launcher under Common Tools, I downloaded and Moose 5.1(stable)
fine, but it is Pharo 4, so tried to download Moose 6.0(beta) -- but
got a problem - big pause, no progress bars, the later ZipArchive
reporting "Error: can't find EOCD position"

Second try...
The web site advises for Moose 6.0 to download the Moose code in a
Pharo 5.0 image per...
   Gofer new
  smalltalkhubUser: 'Moose' project: 'Moose';
  configuration;
  loadDevelopment.

Doing that in build 50760 download with the Launcher produced...
Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
/home/ben/.local/share/Pharo/images/Moose6-50760/package-cache
http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
not access http://www.squeaksource.com/phexample: ZnInvalidUTF8:
Illegal leading byte for utf-8 encoding'

Could someone check if they see the same, or maybe my Internet is 
flakey atm?

(preferably someone who doesn't normally use Moose to avoid package
cache differences)

More info..

The repository defined in Monticello is
 MCSqueaksourceRepository
 location: 'http://www.squeaksource.com/phexample'
 user: ''
 password: ''
which I could not open, again getting...
   MCRepositoryError: Could not access
http://www.squeaksource.com/phexample: ZnInvalidUTF8: Illegal leading
byte for utf-8 encoding

I tried changing to...
MCHttpRepository
location: 'http://www.squeaksource.com/phexample'
user: ''
password: ''
with no luck.

But from Monticello I can define and successfully open another 
repository...

MCHttpRepository
 location: 'http://www.squeaksource.com/DavidLightsOut'
 user: ''
 password: ''

The top of stack is...
"a MetacelloFetchingMCSpecLoader(atomic load : 4.4-beta.1 
[ConfigurationOfMoose]

load : Filesystem-tg.85
load : Nile-Base-DamienCassou.81)"

btw,
Phexample-NikoSchwarz.57 (2010-10-26) seems quite old,
with the latest on Squeaksource being 
Phexample-NikoSchwarz.63.mcz2011-08-29;

latest on Smalltalkhub/PharoExtras/Phexample being
Phexample-Core-CamilloBruni.67 (05/03/2013);
latest on Smalltalk/Phexample/Phexample being
Phexample-DenisKudryashov.75 (08/04/2016)

cheers -ben

Re: [Pharo-users] Smalltalkhub & Squeaksource3

[Dale Henrichs]

On 06/15/2016 10:06 AM, Mark Bratcher wrote:

A couple of easy ones:

1) Does smalltalkhub.com  support private 
projects (used, e.g., for CI)? I've seen a couple of posts on random 
forums dating back a couple of years indicating that it did, but when 
I went to create a project, I didn't see an option to make it private.


2) Is Squeaksource 3 (http://ss3.gemtalksystems.com/ss) currently 
maintained? It still says "public alpha" and latest comments anywhere 
or submissions to their tracker are old. Who is the current owner?
SqueakSource3 is hosted by GemTalk Systems and we continue to make daily 
backups and keep the system up and running.


The latest version of SqueakSource3 is being maintained by Tobias Pape 
and is currently in production at HPI.


SqueakSource3 is "frozen as an alpha", because the SS3 alpha was turned 
on a month or so before the plan to create SmalltalkHub was announced at 
which time I stopped development on SS3 expecting SS3 to eventually be 
turned off ... unfortunately SmalltalkHub was late going into production 
and I was asked to please start doing daily backups and make SS3 
available until SmalltalkHub came on-line ... IIRC it took somewhere 
around a year for SmalltalkHub to come on-line and by that time it was 
"too late" to simply turn off SS3.


I have moved on to use Git and GitHub as a public source code repository 
and we at GemTalk Systems continue to run SS3 as a courtesy to the community


There have been periodic plans to either upgrade SS3 or replace SS3 with 
an up-to-date version of SqueakSource over the years, but the user 
community seems to be satisfied with the status quo and the system has 
been pretty stable over the years.


If volunteers step forward to drive an effort to upgrade/replace SS3 I 
would be completely supportive of the effort, but I don't have the 
cycles to lead such an effort.


Dale

Re: [Pharo-users] Metacello

[Dale Henrichs]

Valentin,

For Pharo I use the following pattern to do "automatic loads":

  [ Metacello new ... load . ]
  on: Warning, MetacelloSkipDirtyPackageLoad
  do: [:ex |
(ex isKindOf: MetacelloSkipDirtyPackageLoad)
  ifTrue: [
"Load over dirty packages"
ex resume: false ]
  ifFalse: [
Transcript cr; show: ex description.
ex resume: true ] ].

Dale


On 6/23/16 2:25 AM, Valentin Ryckewaert wrote:

Hello everyone,

I'm currently  using Metacello to download my project on a new image 
very regularly and i'm having some trouble with this message :


You are about to load new versions of the following packages that have 
unsaved changes in the image:

System-SessionManager
If you continue, you will lose these changes:
Load Merge Cancel

I searched for something to prevent it but didn't find it, does 
someone know how I could automaticly do Load in these cases please?


Valentin

Re: [Pharo-users] The myth of a small deployment image using metacello

[Dale Henrichs]

On 6/24/16 6:28 AM, Norbert Hartl wrote:

I have a seaside project that will be installed in a typical fashion headless 
on a server somewhere on the net. The project is in its final stage so I 
started to care about the size of the image. Or better: The size of the image 
is not my main concern but the number of packages installed. The less packages 
you load the better it is, it is that simple.
This time I encountered a problem that I often see but this particular one 
explains in a very good way that how we use metacello can be improved.

In my project I load only Seaside-Core. This has the advantage of loading far 
less packages and I don't have the need to remove a bunch of registered web 
applications that registered themselves when being loaded.
I make use of a bootstrap template bought somewhere on the net. I use magritte 
a lot so I was happy to see that there is a package called BootstrapMagritte. 
The package extends some magritte ui classes and overwrites some methods to add 
specific classes to HTML tags. Basically not very much code.
What happended after I added the package as a dependency to my own project you 
can see here in the load directive of metacello

linear load :
explicit load : 0.2.3 [ConfigurationOfBootstrapMagritte]
linear load : 0.2.3 [ConfigurationOfBootstrapMagritte]
linear load : 3.5.0 [ConfigurationOfMagritte3]
linear load : 1.1.0 
[ConfigurationOfMagritteGlamourForPharo40]
load : 
Glamour-Presentations.issue_1126-SeanDeNigris.178
load : 
Glamour-Morphic-Renderer.issue_1126-SeanDeNigris.325
explicit load : 3.1.5 [ConfigurationOfSeaside3]
linear load : 3.1.5 [ConfigurationOfSeaside3]
explicit load : 0.26 [ConfigurationOfParasol]
linear load : 0.26 [ConfigurationOfParasol]
linear load : 3.2.0 
[ConfigurationOfSeaside3]
load : 
Seaside-Tests-REST-Core-EstebanMaringolo.34

This is wrong in so many ways. I load a little extensions to my web application 
and end up loading _all_ of seaside which loads beach parasol (a ui testing 
framework), _all_ of magritte which in turn loads glamour packages (a ui 
toolkit). So at this point I think WTF?

Why does this happen? Because the "default" group in many projects contains all of the 
packages and dependencies of the project. I thought at first this is wrong but in the meantime I 
think it is right. Whenever a configuration is loaded without additional parameters the 
"default" group gets loaded. This is the best scenario for newcomers (e.g. using the 
catalog to load). They don't know better but want to see what the package has to offer. Fine, we 
should support that.

For managing projects this gets annoying really quick like you can see above. It would always load 
all dependencies and all packages of every project that your own project depends. This is a no-go. 
To circumvent this a lot of people add a "core" group to their configurations (loading 
the essential parts). This is great because in my own project I can add a dependency to a project 
and load only the "core" group. This works if the dependency chain is not very long (at 
best it works in depth 1 ;) ). As soon as a project has two interesting groups the problem gets 
worse. A good example is magritte. It is useful for describing your model as well as it contains 
useful seaside components. The moment I add a dependency from my model package to magritte seaside 
I know it is wrong. I find myself sometimes duplicating dependencies just to mitigate the effect. I 
do something like

project: 'Magritte3Seaside' with: [
spec
className: #ConfigurationOfMagritte3;
versionString: #'stable';
loads: #('Seaside' );
repository: 
'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ];
project: 'Magritte3Core' with: [
spec
className: #ConfigurationOfMagritte3;
versionString: #'stable';
loads: #('Core' );
repository: 
'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ];

and…
package: #'MyProject-Model-Core' with: [
spec requires: #( 'Magritte3Core' ). ];
package: #'MyProject-UI-Core' with: [
spec requires: #( 'Seaside3' 'Magritte3Seaside' 
'BootstrapMagritte'  ). ];


just to be able to put the right dependencies. But this way is cumbersome to do

[Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

Thierry,

I think I tried the obvious:

1. open existing repository with gitfiletree://
2. reload all packages from gitfiletree repo and remove old filetree://
   repo from each package
3. edit .filetree and add `"Metadata" : "false"`

but when I save a package I continue to get metadata created ...

I even tried removing and adding the repo after editting the .filetree 
file 


I have a handful of additional random things that I will try, but I 
think it is also time to find out the proper technique:)


I want to gain experience with GitFileTree; test out the Metacello 
Cypress mode; and perhaps honor the `"Metadata" : "false"` in the 
GemStone version of FileTree ...


With a short time of usage, I would really like to be able to save all 
of the packages in a project (including the BaselineOf) in one commit 
... I often have multi-package units of work that really should be 
committed together and of course if a method is moved across a package 
boundary, the independent commits don't allow git to recognize the move 
as a "rename" ...


Also I'm hoping that in metadataless mode I stop scanning the entire 
known repository universe for package versions that will not be found 
anywhere but in the repositories that I've explicitly associated with 
the the package itself:)


Thanks,

Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

Thierry,

I don't think I can do it at all... I've deleted all of the packages, 
I've removed all traces of the repository and when I add the repository 
and inspect I get hasMetadata false...


I then deleted the metadata directory from every package on disk and 
committed ... I then loaded the packages again from disk and made a 
change and when I commit the change version number increments and voila, 
I have a new monticello meta data directoy on disk free of charge ... 
and yes hasMetadata is still false ...


I looked at the code and it seems that you are extracting the meta data 
from the git repo (once you have meta data you must have meta data 
forever?)


It looks like it is not possible to switch to metadataless which is a 
shame ... all of the repos where I'd use this have monticello meta data 
in the history so you'll find it if you go looking for it:)



additional comments in-lined below ...

On 6/28/16 12:19 PM, Thierry Goubier wrote:

Hi Dale,

Le 28/06/2016 20:49, Dale Henrichs a écrit :

Thierry,

I think I tried the obvious:

 1. open existing repository with gitfiletree://
 2. reload all packages from gitfiletree repo and remove old filetree://
repo from each package
 3. edit .filetree and add `"Metadata" : "false"`

but when I save a package I continue to get metadata created ...


With that sequence, I'm sure the gitfiletree repository in memory has 
still kept the Metadata : true property, and so hasn't taken in 
account the on-disk change. Like FileTree, it only loads the 
repository properties on the very first access to that repository.



I even tried removing and adding the repo after editting the .filetree
file 


And that didn't work ? I suspected it would... unless the gitfiletree 
repository of step 1 above was not garbage collected.



I have a handful of additional random things that I will try, but I
think it is also time to find out the proper technique:)


I haven't provided an API for the switch, really. And I don't know 
where to add that option inside the Monticello gui.
a Smalltalk expression or setting woudl be better than nothing ... 
although it looks like the issue is deeper than simply changing the 
metadata state:(


What I did, in the few cases I did it, was to inspect the in-image 
MCFileTreeGitRepository and change the property in the inspector ;)



I want to gain experience with GitFileTree; test out the Metacello
Cypress mode; and perhaps honor the `"Metadata" : "false"` in the
GemStone version of FileTree ...

With a short time of usage, I would really like to be able to save all
of the packages in a project (including the BaselineOf) in one commit
... I often have multi-package units of work that really should be
committed together and of course if a method is moved across a package
boundary, the independent commits don't allow git to recognize the move
as a "rename" ...


We would need a specific API for that.

yep..


At the moment what would work is to save the baselineOf with all the 
baseline packages as dependencies.
unless there have been radical changes to the way dependencies work, 
this would defeat the purpose of having a baseline, i.e., all packages 
get loaded when the baseline itself is loaded ...


Now, I'd like to be able to query the baseline to know which packages 
it describes, and save all of them in one go.
I have this feature implemented in tODE ... of course in tODE I have 
created a Metacello Project Browser that is used instead of a Monticello 
Package Browser ... tODE still have the ability to manipulate packages 
independent of the project, but the vast majority of the work is done by 
loading and saving projects instead of packages ...


The upshot is that I have code that supports all of the necessary 
functionality, but someone woule need to build a Metacello Project 
Browser in Pharo to make this funcitonality available to users --- and I 
don't have the bandwidth for that ...


Another possibility would be to add an option with a no-commit flag 
(write but do not commit, do not try to update the package version)
and add a button to the window appearing after each written package 
version to do the commit, store temporarily all such "staged" packages 
info in the repository object, and provide a warning if one tries to 
resave a package before a commit...
A poor man's project browser would have some additional menu items for 
the BaselineOf package: save project and load project would probably be 
sufficient. The you would go around a write all of the dirty packages 
associated with the baseline ... in addition to the baseline itself ... 
and then do your git commit when completed ...



Also I'm hoping that in metadataless mode I stop scanning the entire
known repository universe for package versions that will not be found
anywhere but in the repositories that I've expl

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

BTW, I loaded git file tree with the Catalog Browser, so I'm not 
necessarily using the latest code from Github:


  BaselineOfGitFileTree-ThierryGoubier.16

Dale



On 6/28/16 12:55 PM, Dale Henrichs wrote:

Thierry,

I don't think I can do it at all... I've deleted all of the packages, 
I've removed all traces of the repository and when I add the 
repository and inspect I get hasMetadata false...


I then deleted the metadata directory from every package on disk and 
committed ... I then loaded the packages again from disk and made a 
change and when I commit the change version number increments and 
voila, I have a new monticello meta data directoy on disk free of 
charge ... and yes hasMetadata is still false ...


I looked at the code and it seems that you are extracting the meta 
data from the git repo (once you have meta data you must have meta 
data forever?)


It looks like it is not possible to switch to metadataless which is a 
shame ... all of the repos where I'd use this have monticello meta 
data in the history so you'll find it if you go looking for it:)



additional comments in-lined below ...

On 6/28/16 12:19 PM, Thierry Goubier wrote:

Hi Dale,

Le 28/06/2016 20:49, Dale Henrichs a écrit :

Thierry,

I think I tried the obvious:

 1. open existing repository with gitfiletree://
 2. reload all packages from gitfiletree repo and remove old 
filetree://

repo from each package
 3. edit .filetree and add `"Metadata" : "false"`

but when I save a package I continue to get metadata created ...


With that sequence, I'm sure the gitfiletree repository in memory has 
still kept the Metadata : true property, and so hasn't taken in 
account the on-disk change. Like FileTree, it only loads the 
repository properties on the very first access to that repository.



I even tried removing and adding the repo after editting the .filetree
file 


And that didn't work ? I suspected it would... unless the gitfiletree 
repository of step 1 above was not garbage collected.



I have a handful of additional random things that I will try, but I
think it is also time to find out the proper technique:)


I haven't provided an API for the switch, really. And I don't know 
where to add that option inside the Monticello gui.
a Smalltalk expression or setting woudl be better than nothing ... 
although it looks like the issue is deeper than simply changing the 
metadata state:(


What I did, in the few cases I did it, was to inspect the in-image 
MCFileTreeGitRepository and change the property in the inspector ;)



I want to gain experience with GitFileTree; test out the Metacello
Cypress mode; and perhaps honor the `"Metadata" : "false"` in the
GemStone version of FileTree ...

With a short time of usage, I would really like to be able to save all
of the packages in a project (including the BaselineOf) in one commit
... I often have multi-package units of work that really should be
committed together and of course if a method is moved across a package
boundary, the independent commits don't allow git to recognize the move
as a "rename" ...


We would need a specific API for that.

yep..


At the moment what would work is to save the baselineOf with all the 
baseline packages as dependencies.
unless there have been radical changes to the way dependencies work, 
this would defeat the purpose of having a baseline, i.e., all packages 
get loaded when the baseline itself is loaded ...


Now, I'd like to be able to query the baseline to know which packages 
it describes, and save all of them in one go.
I have this feature implemented in tODE ... of course in tODE I have 
created a Metacello Project Browser that is used instead of a 
Monticello Package Browser ... tODE still have the ability to 
manipulate packages independent of the project, but the vast majority 
of the work is done by loading and saving projects instead of packages 
...


The upshot is that I have code that supports all of the necessary 
functionality, but someone woule need to build a Metacello Project 
Browser in Pharo to make this funcitonality available to users --- and 
I don't have the bandwidth for that ...


Another possibility would be to add an option with a no-commit flag 
(write but do not commit, do not try to update the package version)
and add a button to the window appearing after each written package 
version to do the commit, store temporarily all such "staged" 
packages info in the repository object, and provide a warning if one 
tries to resave a package before a commit...
A poor man's project browser would have some additional menu items for 
the BaselineOf package: save project and load project would probably 
be sufficient. The you would go around a write all of the dirty 
packages associated with the baseline ... in addition to the baseline 
itself ... and then do your git commit wh

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/28/16 12:19 PM, Thierry Goubier wrote:

Hi Dale,

Le 28/06/2016 20:49, Dale Henrichs a écrit :


Also I'm hoping that in metadataless mode I stop scanning the entire
known repository universe for package versions that will not be found
anywhere but in the repositories that I've explicitly associated with
the the package itself:)


I don't think it happens there. MCGitFileTreeVersionInfo already 
tracks the repository it comes from, but I'm pretty sure that MC 
doesn't ask the version info for the new data. Maybe add a new type of 
WorkingCopy object?


Thierry,

In Pharo5.0 it seems that the Pharo inbox and several other repositories 
get scanned whenever I do a package diff or do a package save from the 
Monticello Browser ... a few weeks ago, you responded to someone elses 
complaint about this annoying behavior and at this point (after reading 
through a bunch of code trying to get some understanding about why 
metadataless Git Filetree is not working for me) I believe that you were 
claiming responsibility for a problem that is not yours ...


It is true that on every save, you do a refresh for the GitFileTree and 
it is true that this is slightly annoying (but understandable), but the 
truth is that I am seeing this annoying inbox and friends scanning when 
I don't have git file tree loaded in the image ...


S, my crack about "scanning the entire known universe" was aimed at 
the behavior I see without GitFileTree loaded in the image 


Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/28/16 2:16 PM, Thierry Goubier wrote:

Dale,

I'm sure it is possible. Wait, wait! If you have in your .filetree 
"Metadata" : "false" then this is fine and it has switched to the 
metadata-less mode.


To see the changes on disk, you need to save a new version of your 
packages, that should be all.


I just tried and that works.

1- remove the GitFileTree repository from your image
2- write the property "Metadata" : "false" in the .filetree on disk
3- re-add the GitFileTree repository (local)
4- modify then save one of the repository packages
5- look on disk: no more monticello.meta/version!

Note that I had no packages in the image linked to that repository at 
1-, because I'm not sure the simple removal would have really removed 
the repository singleton object.
Sorry, this does not work for me  this is the first thing I tried 
and of course I looked very carefully to ensure that the packages were 
gone and the repository was not referenced anywhere...


I spent a fair amount of time reading the git filetree code to try to 
understand who is creating the monticello.meta directory and reading all 
of your code, I could not find any obvious culprits so I don't think 
that your code is directly responsible for the creation of the metadata 
dir...


However, I just sprayed a bunch of self halts into the code in an 
attempt to find out who might be causing the directory to be created and 
I tripped across MCLazyVersionInfo who I think is the culprit for the 
"scanning the entire known universe" and _might_ be the culprit for 
"lazily" creating the "missing" monticello.meta directory - I haven't 
gotten that far yet.


With regards to "scanning the entire known universe". It looks like any 
sender of #ancestors (which is not an unusual thing during save --- my 
current case or diff another case where I've seen the full scan) to an 
instance MCLazyVersionInfo can end up doing following:


   MCRepositoryGroup default in: [ :r | r versionWithInfo: self ifNone: 
[  ] ]


which literally scans the entire repository universe ... This is part of 
the method #loadAncestorsAndStepChildren which is documented to: "This 
code scans all the repositories to find the exact package version and 
reload the relevant info."


In my image I have 475 instances of MCLazyVersionInfo and 481 instances 
of MCWorkingCopy (without knowing for certain, I'll speculate that the 6 
working copies without MCLazyVersionInfo are the 6 packages that are 
instances of MCGitFileTreeVersionInfo a subclass of  MCLazyVersionInfo) 
... The MCLazyVersionInfo caches the result of the full universe scan in 
a WeakArray ... so if there's an intervening gc (or two) between the 
time that one saves a package, the full repository scan will be re-run 
again ... and again ... and again ..


So I think I now understand why I see so many scans of the pharo inbox 
and presumably all of the repos almost every time I save a package ... 
not very friendly...


This scan was triggered when I tried to save one of the packages that I 
had just loaded and in this case the MCGitFileTreeVersionInfo triggered 
a scan because the repo instance variable was nil ... perhaps this is 
the difference between your run and mine ... in my case the repo was not 
set correctly and in your case it was?


Hopefully someone will do something about this "lazy version info 
problem" personally I would gladly trade off some memory and disk 
consumption to avoid having to wait for the entire repository universe 
to be scanned every time I save a package ...perhaps there is a setting 
somewhere?


I will continue trying to work through meta data directory creation 
problem and see if I can pinpoint the metadata dir creation culprit ... 
right now I know that the packages are loaded without creating the 
directory ...


Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/28/16 2:16 PM, Thierry Goubier wrote:

Dale,

I'm sure it is possible. Wait, wait! If you have in your .filetree 
"Metadata" : "false" then this is fine and it has switched to the 
metadata-less mode.


To see the changes on disk, you need to save a new version of your 
packages, that should be all.


I just tried and that works.

1- remove the GitFileTree repository from your image
2- write the property "Metadata" : "false" in the .filetree on disk
3- re-add the GitFileTree repository (local)
4- modify then save one of the repository packages
5- look on disk: no more monticello.meta/version!

Note that I had no packages in the image linked to that repository at 
1-, because I'm not sure the simple removal would have really removed 
the repository singleton object.


Le 28/06/2016 21:55, Dale Henrichs a écrit :

Thierry,

I don't think I can do it at all... I've deleted all of the packages,
I've removed all traces of the repository and when I add the repository
and inspect I get hasMetadata false...

I then deleted the metadata directory from every package on disk and
committed ... I then loaded the packages again from disk and made a
change and when I commit the change version number increments and voila,
I have a new monticello meta data directoy on disk free of charge ...
and yes hasMetadata is still false ...

I looked at the code and it seems that you are extracting the meta data
from the git repo (once you have meta data you must have meta data
forever?)

It looks like it is not possible to switch to metadataless which is a
shame ... all of the repos where I'd use this have monticello meta data
in the history so you'll find it if you go looking for it:)


This is a vcs, so, anyway, the monticello meta data will stay in the 
history; you just have to checkout an old enough commit to get it :)



additional comments in-lined below ...


More comments below as well.


On 6/28/16 12:19 PM, Thierry Goubier wrote:

Hi Dale,


At the moment what would work is to save the baselineOf with all the
baseline packages as dependencies.

unless there have been radical changes to the way dependencies work,
this would defeat the purpose of having a baseline, i.e., all packages
get loaded when the baseline itself is loaded ...


Yes, but this is the only point where a MC repository sees a bunch of 
packages to write to disk and not a single package.
I understand that ... but for writing out dirty packages in a Metacello 
project this is not a viable alternative...



Now, I'd like to be able to query the baseline to know which packages
it describes, and save all of them in one go.

I have this feature implemented in tODE ... of course in tODE I have
created a Metacello Project Browser that is used instead of a Monticello
Package Browser ... tODE still have the ability to manipulate packages
independent of the project, but the vast majority of the work is done by
loading and saving projects instead of packages ...

The upshot is that I have code that supports all of the necessary
functionality, but someone woule need to build a Metacello Project
Browser in Pharo to make this funcitonality available to users --- and I
don't have the bandwidth for that ...


So, what we would need is a project concept, and packages being loaded 
via a baseline are added to that project, and, when saving, you 
manipulate that project ?
Actually, Metacello has a registry of loaded projects (baselines and 
configurations) and using Metacello it is possible to determine which 
pacakges belong to which projects etc. so it is not necessary to 
"register packages with a project" ... the project registry in Metacello 
is enough ...


Stef, I seem to remember you have planned for someone to work on Git 
integration. I think this would be about the right feature to add, 
combined with versionner...
Yep I agree ... and as I have often said, I've written code in tODE that 
uses Metacello to manage projects with a host of git support features as 
well ... and I would gladly offer advice and assistance to help someone 
adapt the code/lessons that I've larned with tODE to Pharo ... I have 
built a definition model upon which a number of the tools are based, but 
it is probably time for a next generation implementation ...




Another possibility would be to add an option with a no-commit flag
(write but do not commit, do not try to update the package version)
and add a button to the window appearing after each written package
version to do the commit, store temporarily all such "staged" packages
info in the repository object, and provide a warning if one tries to
resave a package before a commit...

A poor man's project browser would have some additional menu items for
the BaselineOf package: save project and load project would probably be
sufficient. The you would go around a write all of the dirty packages
associated with t

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/28/16 2:16 PM, Thierry Goubier wrote:

Dale,

I'm sure it is possible. Wait, wait! If you have in your .filetree 
"Metadata" : "false" then this is fine and it has switched to the 
metadata-less mode.


To see the changes on disk, you need to save a new version of your 
packages, that should be all.


I just tried and that works.

1- remove the GitFileTree repository from your image
2- write the property "Metadata" : "false" in the .filetree on disk
3- re-add the GitFileTree repository (local)
4- modify then save one of the repository packages
5- look on disk: no more monticello.meta/version!

Note that I had no packages in the image linked to that repository at 
1-, because I'm not sure the simple removal would have really removed 
the repository singleton object.
Well I've found the culprit: MCFileTreeWriter>>addString:at:encodedTo: 
ensures that monticello.meta directory exists...


Of course as I reread your comment "no more monticello.meta/version" I 
will have to say that I've only been looking at whether or not the 
monticello.meta directory existed  or not ... I equate "no monticello 
meta data" as no monticello.meta directory and you interpret it as "no 
monticallo version file" ... well I can live with that ... I swore that 
I saw version files being updated in some of my experiments ... but now 
that I know that I should only look at the monticello.meta/version file, 
I will try yet again ...


Thanks for you patience and help ...

Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

Thierry,

Okay ... it is "working" now ... I was also misled by the fact that you 
are continuing to fabricate Monticello version numbers which presumably 
cannot be relied upon in any way.


Tugrik-Help-DaleHenrichs.11 will show up in each branch that includes 
the commit for "Tugrik-Help-DaleHenrichs.10", but the SHA and contents 
would be different for each one of the "Tugrik-Help-DaleHenrichs.11" , 
is that right?


Perhaps using the short SHA in place of the "version number" would be 
safer and provide useful information in the version number slot?


If I support "Metadata" : "false" in GemStone, I do not intend to 
fabricate a "realistic looking Monticello version number" ... but I will 
look into using the short SHA (when in a git repo) and perhaps fall back 
to cypress.1 for non-git repos...


Anyway, I will now be able to move forward with my Metacello Cypress 
experiments and also try to understand how Metacello loads are affected 
by metadtaless, since you _are_ fabricating Monticello version numbers, 
my previous assumptions are not correct ...


Thanks again!

Dale

On 6/28/16 4:11 PM, Dale Henrichs wrote:



On 6/28/16 2:16 PM, Thierry Goubier wrote:

Dale,

I'm sure it is possible. Wait, wait! If you have in your .filetree 
"Metadata" : "false" then this is fine and it has switched to the 
metadata-less mode.


To see the changes on disk, you need to save a new version of your 
packages, that should be all.


I just tried and that works.

1- remove the GitFileTree repository from your image
2- write the property "Metadata" : "false" in the .filetree on disk
3- re-add the GitFileTree repository (local)
4- modify then save one of the repository packages
5- look on disk: no more monticello.meta/version!

Note that I had no packages in the image linked to that repository at 
1-, because I'm not sure the simple removal would have really removed 
the repository singleton object.
Well I've found the culprit: MCFileTreeWriter>>addString:at:encodedTo: 
ensures that monticello.meta directory exists...


Of course as I reread your comment "no more monticello.meta/version" I 
will have to say that I've only been looking at whether or not the 
monticello.meta directory existed or not ... I equate "no monticello 
meta data" as no monticello.meta directory and you interpret it as "no 
monticallo version file" ... well I can live with that ... I swore 
that I saw version files being updated in some of my experiments ... 
but now that I know that I should only look at the 
monticello.meta/version file, I will try yet again ...


Thanks for you patience and help ...

Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/28/16 10:22 PM, Thierry Goubier wrote:

Hi Dale,

Le 29/06/2016 01:50, Dale Henrichs a écrit :

Thierry,

Okay ... it is "working" now ... I was also misled by the fact that you
are continuing to fabricate Monticello version numbers which presumably
cannot be relied upon in any way.

Tugrik-Help-DaleHenrichs.11 will show up in each branch that includes
the commit for "Tugrik-Help-DaleHenrichs.10", but the SHA and contents
would be different for each one of the "Tugrik-Help-DaleHenrichs.11" ,
is that right?


Yes.


Perhaps using the short SHA in place of the "version number" would be
safer and provide useful information in the version number slot?


Maybe. But then you'll have a bunch of stuff expecting version numbers 
that will stop working.
Ah yes, the nasty Monticello version number parsing that is sprinkled 
around the universe... But at the end of the day, these are tools issues 
and we shouldn't let tools limitations stand in the way of progress ...


With that said I certainly understand the issues ... The design of 
Metacello was almost completely driven by "tools issues" and of course 
FileTree was originally written to be completely compatible with the 
Monticello tools ...


But by dropping monticello version data (actually making monticello 
version data optional) we are breaking the tools ... The fabricated 
version numbers that you are currently using do the job of not breaking 
the tools, but they break the semantics of Monticello and fool the 
developer in believing things that aren't true --- which is a bit 
dangerous in my opinion ...


So at the end of the day, if we are really going to _support_ optional 
monticello version data, then we need to make a pass through the tools 
 I built tODE from the ground up so that I could make the tools 
directly git aware ...



If I support "Metadata" : "false" in GemStone, I do not intend to
fabricate a "realistic looking Monticello version number" ... but I will
look into using the short SHA (when in a git repo) and perhaps fall back
to cypress.1 for non-git repos...

Anyway, I will now be able to move forward with my Metacello Cypress
experiments and also try to understand how Metacello loads are affected
by metadtaless, since you _are_ fabricating Monticello version numbers,
my previous assumptions are not correct ...


Please tell how it goes, especially the part with the short SHA, 
because I haven't tried that; I kept creating version numbers to just 
have gitfiletree behaving like filetree (apparently).
I understand the motivation ... the basic theory is that when using 
Baselines and git, the monticello version number is not relevant any 
more ... as you point out above, the SHA will be problematic with 
regards to the handful of places in the system that parse package names 
to extract a version number and solving that problem by itself may not 
be practical -- it remains to be seen ...


The other half of this equation is that new tools should really be built 
to work with git-based repositories ... a Metacello Project Browser as 
the "main focus" would relieve the pressure to be completely compatible 
with the Monticello Browser and open the way for the creation of a 
Cypress Browser for working with git/filetree repos...


Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/29/16 1:05 AM, Thierry Goubier wrote:

Dale,

you're right, the monticello.meta directory is kept, in part because I 
wasn't sure I could get rid of some of the information in some files 
in that directory (dependencies, initializers).


Since those files don't usually create conflicts with git, it seemed Ok.
Makes a ton of sense ... the other information on disk can be fabricated 
on demand, but I am also a fan of "doing the smallest amount needed" 


I got confused because I _expected_ the directory to be gone 

Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/29/16 1:09 AM, Thierry Goubier wrote:

Dale,

Le 29/06/2016 00:55, Dale Henrichs a écrit :




...


Actually, Metacello has a registry of loaded projects (baselines and
configurations) and using Metacello it is possible to determine which
pacakges belong to which projects etc. so it is not necessary to
"register packages with a project" ... the project registry in Metacello
is enough ...


How do one adds a new package to a project in that registry? One can 
create new packages in a repository, and add them to the baseline (by 
editing the baseline method)?
Yes, when you add a new package to the baseline the package becomes part 
of the project ... the exceptions come into play when you add a package 
to a baseline that is not aimed at the current platform :) For example 
when I'm working in GemStone I may add a package to the baseline for 
Pharo and actually create the initial version of the package in the 
GemStone image ... now as far as Metacello is concerned, the pharo 
package is not part of the GemStone baseline ... but this is not a 
common situation and in my case I manually commit the pharo package and 
don't really expect it to be "automatically managed" ...


Do we need to rethink the Kommitter/Versionner stuff to provide a GUI 
to manipulate such things?
I am not (yet) familiar with Kommitter/Versionner, but I imagine that a 
Metacello Project Browser is needed... In tODE the "Metacello Project 
Browser" is called the `project list` and does more than just manage the 
packages and git repo for the project --- there is a one to one 
relationship between a git repo and a baseline that is very nice --- 
From the tODE "Metacello Project Browser" one can open a  browser on 
all of the classes in the project, or all of the categories in the 
project, or all of the packages in the project, or all of the dirty 
packages in the project, or a changes browser that displays all of the 
changes to all of the packages in one place, or open a test browser on 
all of the tests in the project, etc So new tools and extensions to 
existing tools are probably called for ...


Dale

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Dale Henrichs]

On 6/29/16 1:24 AM, Nicolas Passerini wrote:
Hi Dale, Therry, I am working on a libgit-based git integration for 
Pharo and I am facing the same problem about version numbers. So maybe 
I can help you if you are working on that.
I had the same idea as Dale, using short SHAs instead of correlative 
numbers, but I didn't have the time yet to got down that path.


Therry, you said that


 you'll have a bunch of stuff expecting version numbers that will
stop working.

Do you already know which stuff will stop working? That would be realy 
helpful.



Nicolas,

Yes. There are a number of different places in the image where the 
Monticello package name is parsed. GoferVersionReference>>parseName: is 
one such place and I know that Metacello has it's own parser for 
Monticello package names and there are probably a few others that are 
floating around in the Monticello Browser I don't know whether tools 
like Kommitter/Versionner are doing their own parsing or not.


If I'm not mistaken you will probably find all the Monticello name 
parsers by looking for senders of #isDigit which should result in some 
fairly obvious suspects ... then we just need to figure out if we can 
create a parser that will accept a hex version number and go from there ...


If we assume that the short SHA version numbers will only be used with 
Pharo5.0/6.0/GemStone (platforms for which new tools have been created), 
then we might be able to pull this off...


Dale