June 2016 - Pharo-users - lists.pharo.org

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

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. > > 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 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? >> >> When working with a metadataless repository why would need to look up >> version info for the package in other repository? >> >> In the past, the Monticello Browser would only look in the repositories >> of the repository group for a package to look for package versions ... >> now it seems that all of the repositoris in the default repository group >> are scanned for versions of the package being committed. > > I'll have a look and see if I can cut that in the case of GitFileTree > packages. > 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 ... Dale

June 28, 2016

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

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

June 28, 2016