- Pharo-users - lists.pharo.org

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

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

June 28, 2016

Re: [Pharo-users] Issue with NeoCSVReader

by Sebastian Heidbrink

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

June 28, 2016

Issue with NeoCSVReader

by 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 28, 2016

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

by 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 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 ? 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... >> >> 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. Thierry > 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 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 ... Soooo, my crack about "scanning the entire known universe" was aimed at the behavior I see without GitFileTree loaded in the image .... Dale

June 28, 2016

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

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

June 28, 2016

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

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

June 28, 2016

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

by 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 > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> 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-delpla… > > 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

June 28, 2016