Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Thierry Goubier]

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.



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).


Thierry


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]

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 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 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 the baseline ... in addition to the baseline itself ...
and then do your git commit when completed ...



Also I'm hoping 

Re: [Pharo-users] [ANN]Windows previewer / switcher for Pharo

[Merwan Ouddane]

Argh i was so thrilled by this ! But it doesn't seem to work on windows :/

Ctrl+tab gives the focus to the front window or makes an "inspect it" on 
the current editor line...


Thank you anyway !

On 28/06/2016 14:51, Julien Delplanque wrote:

Also, here is a screenshot (I forgot to attach it to the preceding mail).

Julien


On 28/06/16 11:06, Julien Delplanque wrote:

Hello,

This mail to announce you that I am working on a windows previewer / 
switcher for

Pharo [1].

It is still in early stage of development but it is usable.

To install it:

|Metacello new repository: 
'github://JulienDelplanque/WindowsPreviewer/repository'; baseline: 
'WindowsPreviewer'; load|


See the README for details on activation/shortcuts.

Please, if you have some ideas or critics let me know!

Also, a better name than "Windows Previewer" would be cool but I have
no other idea :-)...

Regards,

Julien

Links:
[1]: https://github.com/juliendelplanque/WindowsPreviewer

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] Issue with NeoCSVReader

[Sebastian Heidbrink via Pharo-users]

--- Begin Message ---

Hi Alexandre,

I do not have access to a pharo image right now. But I had a look into 
your csv file.
There are rows that do not include any or to few data. I think 
NeoCSVReader can not handle that and expects a "proper" file


I will check tonight, in case nobody else comes up with additional 
information by then.


To be continued
Sebastian



Am 28.06.2016 um 14:41 schrieb Alexandre Bergel:

Hi!

I have a simple use of NeoCSVReader, but I get a rollback.

-=-=-=-=-=-=-=-=-=
content := (ZnEasy get: 
'https://github.com/sudar/pig-samples/raw/master/data/tweets.csv') contents 
readStream.
lines := (NeoCSVReader on: content)
skipHeader;
upToEnd.
-=-=-=-=-=-=-=-=-=

The url points to a .csv file with a header. No idea why the code .

I loaded the csv reader using:
Gofer new
smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo';
package: 'ConfigurationOfNeoCSV'; load.
(Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge.

Alexandre




--- End Message ---

[Pharo-users] Issue with NeoCSVReader

[Alexandre Bergel]

Hi!

I have a simple use of NeoCSVReader, but I get a rollback.

-=-=-=-=-=-=-=-=-=
content := (ZnEasy get: 
'https://github.com/sudar/pig-samples/raw/master/data/tweets.csv') contents 
readStream. 
lines := (NeoCSVReader on: content)
skipHeader;
upToEnd.
-=-=-=-=-=-=-=-=-=

The url points to a .csv file with a header. No idea why the code .

I loaded the csv reader using:
Gofer new 
smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo';
package: 'ConfigurationOfNeoCSV'; load.
(Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Thierry Goubier]

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,

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:(


No, this was just that.


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


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.



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 

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]

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 when completed ...



Also I'm hoping that in metadataless mode I stop scanning the entire
known repository universe for package versions 

Re: [Pharo-users] [ANN]Windows previewer / switcher for Pharo

[Offray Vladimir Luna Cárdenas]

No, I tried on Gnu/Linux.


On 28/06/16 14:30, Mariano Martinez Peck wrote:

Hi,

Did you try it with OSX? Does not seem to work for me with cmd + tab.

On Tue, Jun 28, 2016 at 12:54 PM, Offray Vladimir Luna Cárdenas 
> wrote:


Thanks Julien. Testing it. It looks pretty cool and seems really
useful for my clutter windows usage that Pharo / Smalltalk tends
towards. See:

or full screen at:

https://offray.withknown.com/2016/windows-preview-on-pharo-by-julien-delplanque

Cheers,

Offray


On 28/06/16 07:51, Julien Delplanque wrote:

Also, here is a screenshot (I forgot to attach it to the
preceding mail).

Julien


On 28/06/16 11:06, Julien Delplanque wrote:

Hello,

This mail to announce you that I am working on a windows
previewer / switcher for
Pharo [1].

It is still in early stage of development but it is usable.

To install it:

|Metacello new repository:
'github://JulienDelplanque/WindowsPreviewer/repository';
baseline: 'WindowsPreviewer'; load|

See the README for details on activation/shortcuts.

Please, if you have some ideas or critics let me know!

Also, a better name than "Windows Previewer" would be cool but I
have
no other idea :-)...

Regards,

Julien

Links:
[1]: https://github.com/juliendelplanque/WindowsPreviewer








--
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] How do I convert a FileTree project to Metadataless GitFileTree project?

[Thierry Goubier]

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.


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.

At the moment what would work is to save the baselineOf with all the 
baseline packages as dependencies.


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.


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



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


Thanks,

Dale

Re: [Pharo-users] Pharo Launcher

[Damien Cassou]

Christophe Demarey  writes:
> Pharo launcher is now shipped with both vm (pre-spur and spur). The
> cog-spur vm now powered PharoLauncher and should be used to run spur
> images. If not, maybe you have a wrong setting for it. If you remove
> settings for both VM it should work. Maybe I should remove these
> settings since both VMs are now shipped with the launcher app. I do
> not know if it is relevant to some of you to use another VM than the
> default ones.

it is at least relevant for me because I cannot use the shipped VMs: I
have to use the ones of my Linux distribution.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-users] [ANN]Windows previewer / switcher for Pharo

[Offray Vladimir Luna Cárdenas]

Thanks Julien. Testing it. It looks pretty cool and seems really useful 
for my clutter windows usage that Pharo / Smalltalk tends towards. See:


or full screen at: 
https://offray.withknown.com/2016/windows-preview-on-pharo-by-julien-delplanque


Cheers,

Offray


On 28/06/16 07:51, Julien Delplanque wrote:

Also, here is a screenshot (I forgot to attach it to the preceding mail).

Julien


On 28/06/16 11:06, Julien Delplanque wrote:

Hello,

This mail to announce you that I am working on a windows previewer / 
switcher for

Pharo [1].

It is still in early stage of development but it is usable.

To install it:

|Metacello new repository: 
'github://JulienDelplanque/WindowsPreviewer/repository'; baseline: 
'WindowsPreviewer'; load|


See the README for details on activation/shortcuts.

Please, if you have some ideas or critics let me know!

Also, a better name than "Windows Previewer" would be cool but I have
no other idea :-)...

Regards,

Julien

Links:
[1]: https://github.com/juliendelplanque/WindowsPreviewer

Re: [Pharo-users] accepting method without creating variable and code generation

[Marcus Denker]

> On 28 Jun 2016, at 15:09, Guillermo Polito  wrote:
> 
> Ding dong Marcus!
> 
> 
… is on Holidays… with the option #optionParseErrors you can compile code with 
syntax errors:

method := Smalltalk compiler 
class: UndefinedObject;
options: #(+ optionParseErrors);
compile: 'errorMethod ^1+'.

method valueWithReceiver: nil arguments: #()

This is really compiled to raise a syntax error at runtime. see

OCASTTranslator>>#visitParseErrorNode: anErrorNode  
methodBuilder 
pushLiteralVariable: #error -> anErrorNode 
asSyntaxErrorNotification;
send: #signal.

with

RBParseErrorNode>>#asSyntaxErrorNotification
^SyntaxErrorNotification new
setClass: self methodNode methodClass
category: nil 
code: self methodNode source
doitFlag: false
errorMessage: errorMessage
location: self start


Marcus

Re: [Pharo-users] accepting method without creating variable and code generation

[Thierry Goubier]

Le 28/06/2016 15:03, Nicolas Passerini a écrit :

Still, I think it would be nice to be able to save a method even when it
does not compile.


I believe it would be better to be able to manipulate, inspect and edit 
properly virtual methods (MCMethodDefinition, RB-created methods) given 
that saving a method even if it does not compile is already possible, 
even if not made available in the GUI.


Thierry


On Tue, Jun 28, 2016 at 2:52 PM, Peter Uhnák > wrote:

Yeah I guess that's not such a bad idea, to have a TemplateClass
that would contain just the template methods, so I don't need to
worry about conflicting instance variables.

Peter

On Tue, Jun 28, 2016 at 2:08 PM, Ben Coman > wrote:

On Tue, Jun 28, 2016 at 5:55 PM, Peter Uhnak > wrote:
 > Hi,
 >
 > is it possible to accept a method without creating instance
variable?
 >
 > E.g.
 >
 > ~~
 > Object subclass: #MyObject
 > slots: {  }
 > classVariables: {  }
 > category: 'Category'
 > ~~
 >
 > ~~
 > MyObject>>addValue: aValue
 > container add: aValue
 > ~~
 >
 > Now normally when I would try to compile the method I would
get the "Unknown variable 'container'" warning that will force
me to either create temporary or instance variable; I would like
to somehow ignore that, because the method will actually never
get called.
 >
 > My objective is use this method as a template for code
generation, so I would then take this method, apply some code
transformation and compile it into different object.
 >
 > Of course I could do
 >
 > ~
 > MyObject>>addValueTemplate
 > ^ 'MyObject>>addValue: aValue
 > container add: aValue'
 > ~
 >
 > But then I would lose code highlighting, which is quite
error-prone for more complex snippets.
 >
 > If you have a better approach, I am all ears. :)
 >
 > Thanks,
 > Peter

If you are only templating the method and not the whole class,
why not
add it as an instance variable MyObject?
Or if MyObject is a real domain object with a few template methods,
maybe put the templates on the class side and add a dummy
class-instance-variable there.

cheers -ben

Re: [Pharo-users] accepting method without creating variable and code generation

[Guillermo Polito]

Ding dong Marcus!
Le 28 juin 2016 15:04, "Nicolas Passerini"  a écrit :

> Still, I think it would be nice to be able to save a method even when it
> does not compile.
>
> On Tue, Jun 28, 2016 at 2:52 PM, Peter Uhnák  wrote:
>
>> Yeah I guess that's not such a bad idea, to have a TemplateClass that
>> would contain just the template methods, so I don't need to worry about
>> conflicting instance variables.
>>
>> Peter
>>
>> On Tue, Jun 28, 2016 at 2:08 PM, Ben Coman  wrote:
>>
>>> On Tue, Jun 28, 2016 at 5:55 PM, Peter Uhnak  wrote:
>>> > Hi,
>>> >
>>> > is it possible to accept a method without creating instance variable?
>>> >
>>> > E.g.
>>> >
>>> > ~~
>>> > Object subclass: #MyObject
>>> > slots: {  }
>>> > classVariables: {  }
>>> > category: 'Category'
>>> > ~~
>>> >
>>> > ~~
>>> > MyObject>>addValue: aValue
>>> > container add: aValue
>>> > ~~
>>> >
>>> > Now normally when I would try to compile the method I would get the
>>> "Unknown variable 'container'" warning that will force me to either create
>>> temporary or instance variable; I would like to somehow ignore that,
>>> because the method will actually never get called.
>>> >
>>> > My objective is use this method as a template for code generation, so
>>> I would then take this method, apply some code transformation and compile
>>> it into different object.
>>> >
>>> > Of course I could do
>>> >
>>> > ~
>>> > MyObject>>addValueTemplate
>>> > ^ 'MyObject>>addValue: aValue
>>> > container add: aValue'
>>> > ~
>>> >
>>> > But then I would lose code highlighting, which is quite error-prone
>>> for more complex snippets.
>>> >
>>> > If you have a better approach, I am all ears. :)
>>> >
>>> > Thanks,
>>> > Peter
>>>
>>> If you are only templating the method and not the whole class, why not
>>> add it as an instance variable MyObject?
>>> Or if MyObject is a real domain object with a few template methods,
>>> maybe put the templates on the class side and add a dummy
>>> class-instance-variable there.
>>>
>>> cheers -ben
>>>
>>>
>>
>

Re: [Pharo-users] accepting method without creating variable and code generation

[Cyril Ferlicot Delbecque]

On 28/06/2016 15:03, Nicolas Passerini wrote:
> Still, I think it would be nice to be able to save a method even when it
> does not compile.
> 

I think Marcus added the possibility to do that in Pharo 6 as a Setting.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] accepting method without creating variable and code generation

[Nicolas Passerini]

Still, I think it would be nice to be able to save a method even when it
does not compile.

On Tue, Jun 28, 2016 at 2:52 PM, Peter Uhnák  wrote:

> Yeah I guess that's not such a bad idea, to have a TemplateClass that
> would contain just the template methods, so I don't need to worry about
> conflicting instance variables.
>
> Peter
>
> On Tue, Jun 28, 2016 at 2:08 PM, Ben Coman  wrote:
>
>> On Tue, Jun 28, 2016 at 5:55 PM, Peter Uhnak  wrote:
>> > Hi,
>> >
>> > is it possible to accept a method without creating instance variable?
>> >
>> > E.g.
>> >
>> > ~~
>> > Object subclass: #MyObject
>> > slots: {  }
>> > classVariables: {  }
>> > category: 'Category'
>> > ~~
>> >
>> > ~~
>> > MyObject>>addValue: aValue
>> > container add: aValue
>> > ~~
>> >
>> > Now normally when I would try to compile the method I would get the
>> "Unknown variable 'container'" warning that will force me to either create
>> temporary or instance variable; I would like to somehow ignore that,
>> because the method will actually never get called.
>> >
>> > My objective is use this method as a template for code generation, so I
>> would then take this method, apply some code transformation and compile it
>> into different object.
>> >
>> > Of course I could do
>> >
>> > ~
>> > MyObject>>addValueTemplate
>> > ^ 'MyObject>>addValue: aValue
>> > container add: aValue'
>> > ~
>> >
>> > But then I would lose code highlighting, which is quite error-prone for
>> more complex snippets.
>> >
>> > If you have a better approach, I am all ears. :)
>> >
>> > Thanks,
>> > Peter
>>
>> If you are only templating the method and not the whole class, why not
>> add it as an instance variable MyObject?
>> Or if MyObject is a real domain object with a few template methods,
>> maybe put the templates on the class side and add a dummy
>> class-instance-variable there.
>>
>> cheers -ben
>>
>>
>

Re: [Pharo-users] Pharo Launcher

[Christophe Demarey]

Hi Tim,

> Le 27 juin 2016 à 22:12, Tim Mackinnon  a écrit :
> 
> Hi guys - I finally got some free time to take a look at Pharo-5 and wanted 
> Launcher back as well - I just downloaded it on my mac and I’m wondering if 
> something is wrong?
> 
> The UI doesn’t look right (compared to the older 4.x version) - the top panel 
> is white, and there is a grey run button next to the green one (the triangle) 
> that seems to be missing transparency - so it all looks quite ugly. Have I 
> downloaded something that is wrong?

No, is the current state of Pharo Launcher UI. I did not touch to this part 
but, yes, could be improved.

> I also notice, that when I go to create a new image from a template - the 
> name prompt isn’t as good as the old version which used to include the parent 
> node in the suggested name so you got something like “Pharo 6.0 (beta) 
> 123455” as a descriptive name - it now just seems to offer “1234456” as the 
> name now?

I did this change after a small survey on pharo launcher users that were, like 
me, bothered with previous proposed names: in most cases, they only want the 
name of their project. That could be discussed but now, in your example, you 
get 60121 that is still descriptive. Here, we should find the best proposition 
for most users, will not for to all.

> I don’t understand the how the paths work now - it seems that my old images 
> launch fine, but a 5.x image doesn’t? Do I set the spur path for this - or is 
> it the other way around (vm-path should be the new vm)? The floating help 
> isn’t very descriptive on this.

Pharo launcher is now shipped with both vm (pre-spur and spur). The cog-spur vm 
now powered PharoLauncher and should be used to run spur images. If not, maybe 
you have a wrong setting for it. If you remove settings for both VM it should 
work. Maybe I should remove these settings since both VMs are now shipped with 
the launcher app. I do not know if it is relevant to some of you to use another 
VM than the default ones.

Thanks for the feedback.
Christophe

> 
> Thanks,
> 
> Tim
> 
> 
> 
> Sent from my iPhone
>> On 17 Jun 2016, at 13:10, Christophe Demarey  
>> wrote:
>> 
>> Now fixed. I replaced the DMG on files.pharo.org.
>> Thanks for the report
>> 
 Le 17 juin 2016 à 13:34, Christophe Demarey  
 a écrit :
 
 
 Le 17 juin 2016 à 12:00, Serge Stinckwich  a 
 écrit :
 
 On Fri, Jun 17, 2016 at 10:22 AM, Christophe Demarey
  wrote:
> Hi,
> 
> I just updated Pharo Launcher. A new version 0.2.11 is available.
> Here are the change log:
 
 Great ! Thank you for the update.
 
> move Pharo Launcher to the latest stable pharo image: pharo 5.0. It 
> implies
> That Pharo Launcher is now shipped with Spur VM.
> allow an easy download of the new beta image: pharo 6.0
> the Launcher now comes with 2 VMs:
> 
> Spur VM (pharo 5.0 and Pharo 6.0)
> Non-Spur VM (to be able to run old images)
 
 I dl the mac version. I was not able to run non-spur VM images: the
 launcher crash or do nothing ...
>>> 
>>> Indeed, I think it’s a side effect of latest changes I did after testing on 
>>> Windows.
>>> I take a look at it now
> 
> 
> 

Re: [Pharo-users] accepting method without creating variable and code generation

[Peter Uhnák]

Yeah I guess that's not such a bad idea, to have a TemplateClass that would
contain just the template methods, so I don't need to worry about
conflicting instance variables.

Peter

On Tue, Jun 28, 2016 at 2:08 PM, Ben Coman  wrote:

> On Tue, Jun 28, 2016 at 5:55 PM, Peter Uhnak  wrote:
> > Hi,
> >
> > is it possible to accept a method without creating instance variable?
> >
> > E.g.
> >
> > ~~
> > Object subclass: #MyObject
> > slots: {  }
> > classVariables: {  }
> > category: 'Category'
> > ~~
> >
> > ~~
> > MyObject>>addValue: aValue
> > container add: aValue
> > ~~
> >
> > Now normally when I would try to compile the method I would get the
> "Unknown variable 'container'" warning that will force me to either create
> temporary or instance variable; I would like to somehow ignore that,
> because the method will actually never get called.
> >
> > My objective is use this method as a template for code generation, so I
> would then take this method, apply some code transformation and compile it
> into different object.
> >
> > Of course I could do
> >
> > ~
> > MyObject>>addValueTemplate
> > ^ 'MyObject>>addValue: aValue
> > container add: aValue'
> > ~
> >
> > But then I would lose code highlighting, which is quite error-prone for
> more complex snippets.
> >
> > If you have a better approach, I am all ears. :)
> >
> > Thanks,
> > Peter
>
> If you are only templating the method and not the whole class, why not
> add it as an instance variable MyObject?
> Or if MyObject is a real domain object with a few template methods,
> maybe put the templates on the class side and add a dummy
> class-instance-variable there.
>
> cheers -ben
>
>

Re: [Pharo-users] accepting method without creating variable and code generation

[Ben Coman]

On Tue, Jun 28, 2016 at 5:55 PM, Peter Uhnak  wrote:
> Hi,
>
> is it possible to accept a method without creating instance variable?
>
> E.g.
>
> ~~
> Object subclass: #MyObject
> slots: {  }
> classVariables: {  }
> category: 'Category'
> ~~
>
> ~~
> MyObject>>addValue: aValue
> container add: aValue
> ~~
>
> Now normally when I would try to compile the method I would get the "Unknown 
> variable 'container'" warning that will force me to either create temporary 
> or instance variable; I would like to somehow ignore that, because the method 
> will actually never get called.
>
> My objective is use this method as a template for code generation, so I would 
> then take this method, apply some code transformation and compile it into 
> different object.
>
> Of course I could do
>
> ~
> MyObject>>addValueTemplate
> ^ 'MyObject>>addValue: aValue
> container add: aValue'
> ~
>
> But then I would lose code highlighting, which is quite error-prone for more 
> complex snippets.
>
> If you have a better approach, I am all ears. :)
>
> Thanks,
> Peter

If you are only templating the method and not the whole class, why not
add it as an instance variable MyObject?
Or if MyObject is a real domain object with a few template methods,
maybe put the templates on the class side and add a dummy
class-instance-variable there.

cheers -ben

[Pharo-users] accepting method without creating variable and code generation

[Peter Uhnak]

Hi,

is it possible to accept a method without creating instance variable?

E.g.

~~
Object subclass: #MyObject
slots: {  }
classVariables: {  }
category: 'Category'
~~

~~
MyObject>>addValue: aValue
container add: aValue
~~

Now normally when I would try to compile the method I would get the "Unknown 
variable 'container'" warning that will force me to either create temporary or 
instance variable; I would like to somehow ignore that, because the method will 
actually never get called.

My objective is use this method as a template for code generation, so I would 
then take this method, apply some code transformation and compile it into 
different object.

Of course I could do

~
MyObject>>addValueTemplate
^ 'MyObject>>addValue: aValue
container add: aValue'
~

But then I would lose code highlighting, which is quite error-prone for more 
complex snippets.

If you have a better approach, I am all ears. :)

Thanks,
Peter

[Pharo-users] [ANN]Windows previewer / switcher for Pharo

[Julien Delplanque]

Hello,

This mail to announce you that I am working on a windows previewer / 
switcher for

Pharo [1].

It is still in early stage of development but it is usable.

To install it:

|Metacello new repository: 
'github://JulienDelplanque/WindowsPreviewer/repository'; baseline: 
'WindowsPreviewer'; load|


See the README for details on activation/shortcuts.

Please, if you have some ideas or critics let me know!

Also, a better name than "Windows Previewer" would be cool but I have
no other idea :-)...

Regards,

Julien

Links:
[1]: https://github.com/juliendelplanque/WindowsPreviewer

[Pharo-users] [ANN] Pharo Consortium New Bronze Member: FINWorks

[Marcus Denker]

The Pharo Consortium is very happy to announce that FINWorks 
has joined the Consortium as a Bronze Member.

FINWorks: http://finworks.biz 

FINWorks provides software solutions and automation in the financial 
sector. 
Our main area of focus is investment administration, especially back 
office 
solutions for LISP (Linked Investment Service Provider or Fund 
Supermarkets), 
Benefit Administrators, Unit Trust Companies, Asset Managers, 
Independent 
Financial Advisors (IFA)  and other financial service providers

Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions 
to
support the ongoing development and future of Pharo.
Individuals can support Pharo via the Pharo Association:

- http://association.pharo.org
- https://salt.bountysource.com/teams/pharo