- Pharo-users - lists.pharo.org

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

by Thierry Goubier

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)? Do we need to rethink the Kommitter/Versionner stuff to provide a GUI to manipulate such things? Thierry

June 29, 2016

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

by Thierry Goubier

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. Thierry Le 29/06/2016 01:11, Dale Henrichs a Ã©crit : > > > 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 ... Yes > Thanks for you patience and help ... > > Dale > > >

June 29, 2016

Pharo Sprint Friday, 29 July

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Friday, 29 July, starting at 10:00am. (Local Time Paris/Berlin/â¦.). Remotely, you can join us on Slack or the IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. Locally, there will be: - Inria Lille, Building B, third floor (RMoD offices). (As the building is not open to the public, please contact us before in case of visiting) - Santiago de Chile (starting a bit later due to time-zone). DCC University of Chile. Marcus

June 29, 2016

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

by Thierry Goubier

Le 29/06/2016 00:55, Dale Henrichs a Ã©crit : > ... >> > I'm pretty certain the MCLazyVersionInfo is the real culprit here ... > while reading the code I recognized that many of the basic patterns were > exactly as I had remembered them from years ago ... however ... > MCLazyVersionInfo this puppy with its "default behavior" to scan the > universe is the real culprit ... I would think that at a minimum the > repository or repository group would/could be know at the time that the > MCLazyVersionInfo was created and a scan of just those repositories --- > already associated with the project --- would not be nearly as bad as > when we have now ... The MCLazyVersionInfo thing is mine too; it was a solution to avoid keeping MBs of version info kept inside the image memory, with the cost of having to reload that information when you access the ancestry. Now, the approach needs to be tuned to avoid spurious "query the world" searches, but, as you point out, I hasn't been too successfull yet. And one of the thing MC lack, is that link between a repository and a working copy. (at the same time, restricting version number determination to a subset of the repositories is against MC principles when numbering versions). Thierry

June 29, 2016

Re: [Pharo-users] Issue with NeoCSVReader

by Joachim Tuchel

Ben, > Ben Coman <btc(a)openinworld.com> hat am 29. Juni 2016 um 09:40 geschrieben: > Your questions are significant. The standard library should not be > complicated by trying to handle undefined missing fields from a row. > Such a file is simply invalid. > cheers -ben I fully agree, I just wanted to give an example of questions that are way more difficult to answer than it might seem in the first place. I wanted to make an argument for not blaming NeoCSV for being unable to parse a file like that. I am surely not asking for NeoCSV to do some magic on invalid CSV files. It would be wrong in at least 50% of the cases anyways, no matter what kind of assumptions it would make. Joachim

June 29, 2016

Re: [Pharo-users] Issue with NeoCSVReader

by Ben Coman

On Wed, Jun 29, 2016 at 3:13 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > I guess Seb is right. > The file cannot be read by Excel as well. So without having analysed this > any further, it seems to me like the number of fields differs from row to > row. NeoCSV does not handle this kind of "edge case". By defintion, each row > in CSV has the same number of fields - even if you could possibly argue > exceptions to this rule could be handled. > OTOH, what does a missing field in a row usually mean? Is it the last one? > One from the middle? is so, which one? Your questions are significant. The standard library should not be complicated by trying to handle undefined missing fields from a row. Such a file is simply invalid. cheers -ben > > So I think you should first check if the file is valid csv and if not, how > you can get a valid one. If not, I guess you have to roll your own parser > that foolows the "omission rules" of that file format. > > Joachim

June 29, 2016

Re: [Pharo-users] Issue with NeoCSVReader

by Joachim Tuchel

I guess Seb is right. The file cannot be read by Excel as well. So without having analysed this any further, it seems to me like the number of fields differs from row to row. NeoCSV does not handle this kind of "edge case". By defintion, each row in CSV has the same number of fields - even if you could possibly argue exceptions to this rule could be handled. OTOH, what does a missing field in a row usually mean? Is it the last one? One from the middle? is so, which one? So I think you should first check if the file is valid csv and if not, how you can get a valid one. If not, I guess you have to roll your own parser that foolows the "omission rules" of that file format. Joachim

June 29, 2016

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

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

June 29, 2016

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

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

June 28, 2016

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

by 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

June 28, 2016