- Pharo-users - lists.pharo.org

Re: [Pharo-users] Styling a Pharo UI application

by Tommaso Dal Sasso

I was not complaining about Spec, just reporting my experience with the various UI toolkits in Pharo as a relatively newbie to this area of Pharo. Anyway, as I wrote in my first email, I had difficulties with Spec to go beyond building a standard interface, especially in performing text manipulation (font size) or coloring the background of a string, or encapsulating pieces of text in frames. I tried to understand how to do that, but there is very little documentation on the matter, and the main answer I got was "be prepared to use Morphic". Trying to understand how to access the properties of the elements I found several comments like: [talking about font size in Spec] On 03/10/15 09:24, stepharo wrote: > I think that this part has been completely forgotten by spec. > Normally the layout should take into account the size of the label and font > and I do not see why we could not specify the color and other attributes we want to have but we did not work on this point. > Now we will have to see that in the context of Brick skin. > > Stef Don't get me wrong, I like Spec, it is just unclear to me if it wants to be the default toolkit to build widgets in Pharo (in this case it should probably access more properties of Morphic), or if wants to be completely engine-agnostic, therefore preferring abstraction over expressiveness. Tommaso On 26/06/16 23:39, Offray Vladimir Luna CÃ¡rdenas wrote: > > +1 :) > > Offray > > > On 26/06/16 02:56, stepharo wrote: >> >> + 1 >> >> Stef >> >>> Tommaso, >>> >>> can you give some concrete examples of what it is that you wanted to >>> do to refine your application and that was really hard (or >>> impossible) to do with Spec? >>> >>> As long as we do not know what is wrong, we cannot fix it. >>> >>> As long as we do not know what important things are wrong, we cannot >>> prioritize. >>> >>> -- >>> Does this mail seem too brief? Sorry for that, I donât mean to be >>> rude! Please see http://emailcharter.org . >>> >>> Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> >>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>> University of Chile >>> >>>> On Jun 25, 2016, at 15:54, Tommaso Dal Sasso >>>> <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>> wrote: >>>> >>>> The beauty that I am looking for as a developer for has to do with >>>> the code and the API. I consider important how fast I am able to >>>> prototype a working example --in this Spec is excellent-- and how >>>> much I can extend the code to refine my application --in this Spec >>>> is really hard to use--. >>> >> >

June 30, 2016

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

by Thierry Goubier

Hi Norbert, Le 30/06/2016 08:51, Norbert Hartl a Ã©crit : > > >> Am 30.06.2016 um 01:26 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: >> >> >> >>> On 6/29/16 3:44 PM, Ben Coman wrote: >>> On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>> >>>>> On 6/29/16 1:00 AM, Thierry Goubier wrote: >>>>> 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. >>>> That's not true. Each working copy has repository group where either the >>>> developer has either explicitly declared the set of repositories that are >>>> associated with the working copy and/or the system has recorded the set of >>>> repositories from which the package has been loaded ... you should restrict >>>> the search to the repos in the repository group. >>>>> >>>>> (at the same time, restricting version number determination to a subset of >>>>> the repositories is against MC principles when numbering versions). >>>> In principle, yes, but from a practical point of view, the version number >>>> search was "always" restricted to the set of repositories in the repository >>>> group for the working copy ... keep in mind that putting version numbers in >>>> the package name is a _convention_. I don't think that Monticello ever >>>> defined a package name syntax ... Technically, Monticello is supposed to use >>>> the UUID to disambiguate between to packages with the same name, but as you >>>> and I know, this is not really enforced in the code --- Monticello evolved >>>> to rely on the version number for ordering package versions, but I don't >>>> think that was ever part of the design of Monticello ... if you look at the >>>> older implementations of the tools, there was no enformcement of any >>>> rationale package naming scheme ... >>>> >>>> I agree that today when looking at the point to which Monticello usage has >>>> evolved that the statement: >>>> >>>> "the only way to guarantee a unique version number for a package is to >>>> scan all available repositories" >>> What if rather than being incremental the Monticello number what >>> generated YYMMDDhhmmss? Should be reasonably compatible with that >>> scope creep of version numbers into Monticello tools. >>> >>> Maybe the length is a bit ugly and by convention we can condense it a >>> bit. Does that timestamp in the filename need to be human decodable? >>> YY-->alpha character, e.g. 2016-->F (these sort after existing numeric numbers) >>> MM-->hex e.g. Jan-->1 Oct-->A Dec-->C >>> DD-->extended hex 1-->1, 16-->F, 30-->T >>> hh-->extended hex e.g. 1-->1, 16-->F, 23-->M >>> mm-->standard number >>> ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F >>> >>> Today 2016-06-30 23:15:32 --> F6TM15F >>> e.g. Collections-Native.BenComan.F6TM15F.mcz >> >> Ben, >> >> the "unique version number" was in reference to the current scheme of incrementing the version number ... the truth is that I don't think it is necessary to "guarantee a unique version number" for Monticello purposes ... it is sufficient to take the latest version number or the package from the set of: the image and repositories in repository group... which is the technique that was used for years ... >> >> The bug in MCLazyVersionInfo is that it is scanning all repositories connected to the image, when it is sufficient to scan the repositories in the working copy repository group to get a reasonably unique version number ... >> > Can this be fixed easily? I suspect it is easy to fix... Just make the lazy version info aware of the repository group of the working copy. Thierry > thanks, Norbert >> Dale >> > > >

June 30, 2016

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

by Julien Delplanque

Yes it was one of the idea I already had to make it more sexy and advertise the user that he is using it. Thanks for the feedback. :) Julien On 30/06/16 07:37, stepharo wrote: > Julien > > > it may be good to put all the preview morphs on top of a blurry > translucent morph so that we clearly identify them but still see the > background > > > Stef > > > Le 29/6/16 Ã 23:42, Nicolai Hess a Ã©crit : >> Hi Julien, >> >> yes, finding a shortcut satisfying all users (for all different >> platforms) is not easy, see >> 15546 >> <https://pharo.fogbugz.com/f/cases/15546/alt-tab-does-not-work-correctly> >> alt+tab does not work correctly >> and >> 17924 >> <https://pharo.fogbugz.com/f/cases/17924/Switch-Windows-shortcut> >> Switch Windows shortcut >> >> >> 2016-06-29 0:31 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com >> <mailto:merwanouddane@gmail.com>>: >> >> 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... >> >> >> For windows, to make ctrl+tab working, you need to disable the >> "hasSpecialCTRLKeyValue"-check (I think this check is not needed >> anymore, since we changed the >> windows vm for ctrl+number/tab/space... keystrokes) >> >> >> 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 30, 2016

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

by Julien Delplanque

Hi, Ok then I need to think about a nice solution... Maybe by making the shortcut modifiable by the user in the "Settings browser"? I think it would be good to have Ctrl/Cmd+Tab on all platform but it can be done yet. Julien On 29/06/16 23:42, Nicolai Hess wrote: > Hi Julien, > > yes, finding a shortcut satisfying all users (for all different platforms) > is not easy, see > 15546 > <https://pharo.fogbugz.com/f/cases/15546/alt-tab-does-not-work-correctly> > alt+tab does not work correctly > and > 17924 <https://pharo.fogbugz.com/f/cases/17924/Switch-Windows-shortcut> > Switch Windows shortcut > > > 2016-06-29 0:31 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com>: > >> 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... >> > For windows, to make ctrl+tab working, you need to disable the > "hasSpecialCTRLKeyValue"-check (I think this check is not needed anymore, > since we changed the > windows vm for ctrl+number/tab/space... keystrokes) > > >> 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 30, 2016

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

by Norbert Hartl

> Am 30.06.2016 um 01:26 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > >> On 6/29/16 3:44 PM, Ben Coman wrote: >> On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>>> On 6/29/16 1:00 AM, Thierry Goubier wrote: >>>> 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. >>> That's not true. Each working copy has repository group where either the >>> developer has either explicitly declared the set of repositories that are >>> associated with the working copy and/or the system has recorded the set of >>> repositories from which the package has been loaded ... you should restrict >>> the search to the repos in the repository group. >>>> >>>> (at the same time, restricting version number determination to a subset of >>>> the repositories is against MC principles when numbering versions). >>> In principle, yes, but from a practical point of view, the version number >>> search was "always" restricted to the set of repositories in the repository >>> group for the working copy ... keep in mind that putting version numbers in >>> the package name is a _convention_. I don't think that Monticello ever >>> defined a package name syntax ... Technically, Monticello is supposed to use >>> the UUID to disambiguate between to packages with the same name, but as you >>> and I know, this is not really enforced in the code --- Monticello evolved >>> to rely on the version number for ordering package versions, but I don't >>> think that was ever part of the design of Monticello ... if you look at the >>> older implementations of the tools, there was no enformcement of any >>> rationale package naming scheme ... >>> >>> I agree that today when looking at the point to which Monticello usage has >>> evolved that the statement: >>> >>> "the only way to guarantee a unique version number for a package is to >>> scan all available repositories" >> What if rather than being incremental the Monticello number what >> generated YYMMDDhhmmss? Should be reasonably compatible with that >> scope creep of version numbers into Monticello tools. >> >> Maybe the length is a bit ugly and by convention we can condense it a >> bit. Does that timestamp in the filename need to be human decodable? >> YY-->alpha character, e.g. 2016-->F (these sort after existing numeric numbers) >> MM-->hex e.g. Jan-->1 Oct-->A Dec-->C >> DD-->extended hex 1-->1, 16-->F, 30-->T >> hh-->extended hex e.g. 1-->1, 16-->F, 23-->M >> mm-->standard number >> ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F >> >> Today 2016-06-30 23:15:32 --> F6TM15F >> e.g. Collections-Native.BenComan.F6TM15F.mcz > > Ben, > > the "unique version number" was in reference to the current scheme of incrementing the version number ... the truth is that I don't think it is necessary to "guarantee a unique version number" for Monticello purposes ... it is sufficient to take the latest version number or the package from the set of: the image and repositories in repository group... which is the technique that was used for years ... > > The bug in MCLazyVersionInfo is that it is scanning all repositories connected to the image, when it is sufficient to scan the repositories in the working copy repository group to get a reasonably unique version number ... > Can this be fixed easily? thanks, Norbert > Dale >

June 30, 2016

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

by stepharo

Julien it may be good to put all the preview morphs on top of a blurry translucent morph so that we clearly identify them but still see the background Stef Le 29/6/16 Ã 23:42, Nicolai Hess a Ã©crit : > Hi Julien, > > yes, finding a shortcut satisfying all users (for all different > platforms) is not easy, see > 15546 > <https://pharo.fogbugz.com/f/cases/15546/alt-tab-does-not-work-correctly> > alt+tab does not work correctly > and > 17924 > <https://pharo.fogbugz.com/f/cases/17924/Switch-Windows-shortcut> > Switch Windows shortcut > > > 2016-06-29 0:31 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com > <mailto:merwanouddane@gmail.com>>: > > 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... > > > For windows, to make ctrl+tab working, you need to disable the > "hasSpecialCTRLKeyValue"-check (I think this check is not needed > anymore, since we changed the > windows vm for ctrl+number/tab/space... keystrokes) > > > 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 30, 2016

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

by Ben Coman

On Thu, Jun 30, 2016 at 7:26 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 6/29/16 3:44 PM, Ben Coman wrote: >> >> On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> >>> On 6/29/16 1:00 AM, Thierry Goubier wrote: >>>> >>>> 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. >>> >>> That's not true. Each working copy has repository group where either the >>> developer has either explicitly declared the set of repositories that are >>> associated with the working copy and/or the system has recorded the set >>> of >>> repositories from which the package has been loaded ... you should >>> restrict >>> the search to the repos in the repository group. >>>> >>>> >>>> (at the same time, restricting version number determination to a subset >>>> of >>>> the repositories is against MC principles when numbering versions). >>> >>> In principle, yes, but from a practical point of view, the version number >>> search was "always" restricted to the set of repositories in the >>> repository >>> group for the working copy ... keep in mind that putting version numbers >>> in >>> the package name is a _convention_. I don't think that Monticello ever >>> defined a package name syntax ... Technically, Monticello is supposed to >>> use >>> the UUID to disambiguate between to packages with the same name, but as >>> you >>> and I know, this is not really enforced in the code --- Monticello >>> evolved >>> to rely on the version number for ordering package versions, but I don't >>> think that was ever part of the design of Monticello ... if you look at >>> the >>> older implementations of the tools, there was no enformcement of any >>> rationale package naming scheme ... >>> >>> I agree that today when looking at the point to which Monticello usage >>> has >>> evolved that the statement: >>> >>> "the only way to guarantee a unique version number for a package is to >>> scan all available repositories" >> >> What if rather than being incremental the Monticello number what >> generated YYMMDDhhmmss? Should be reasonably compatible with that >> scope creep of version numbers into Monticello tools. >> >> Maybe the length is a bit ugly and by convention we can condense it a >> bit. Does that timestamp in the filename need to be human decodable? >> YY-->alpha character, e.g. 2016-->F (these sort after existing numeric >> numbers) >> MM-->hex e.g. Jan-->1 Oct-->A Dec-->C >> DD-->extended hex 1-->1, 16-->F, 30-->T >> hh-->extended hex e.g. 1-->1, 16-->F, 23-->M >> mm-->standard number >> ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F >> >> Today 2016-06-30 23:15:32 --> F6TM15F >> e.g. Collections-Native.BenComan.F6TM15F.mcz >> > > Ben, > > the "unique version number" was in reference to the current scheme of > incrementing the version number ... the truth is that I don't think it is > necessary to "guarantee a unique version number" for Monticello purposes ... > it is sufficient to take the latest version number or the package from the > set of: the image and repositories in repository group... which is the > technique that was used for years ... > > The bug in MCLazyVersionInfo is that it is scanning all repositories > connected to the image, when it is sufficient to scan the repositories in > the working copy repository group to get a reasonably unique version number > ... > > Dale > If changing that is sufficient, then cool. My idea was just covering Law Of Unintended Consequence ;) cheers -ben

June 30, 2016

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

by Dale Henrichs

On 6/29/16 3:44 PM, Ben Coman wrote: > On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> On 6/29/16 1:00 AM, Thierry Goubier wrote: >>> 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. >> That's not true. Each working copy has repository group where either the >> developer has either explicitly declared the set of repositories that are >> associated with the working copy and/or the system has recorded the set of >> repositories from which the package has been loaded ... you should restrict >> the search to the repos in the repository group. >>> >>> (at the same time, restricting version number determination to a subset of >>> the repositories is against MC principles when numbering versions). >> In principle, yes, but from a practical point of view, the version number >> search was "always" restricted to the set of repositories in the repository >> group for the working copy ... keep in mind that putting version numbers in >> the package name is a _convention_. I don't think that Monticello ever >> defined a package name syntax ... Technically, Monticello is supposed to use >> the UUID to disambiguate between to packages with the same name, but as you >> and I know, this is not really enforced in the code --- Monticello evolved >> to rely on the version number for ordering package versions, but I don't >> think that was ever part of the design of Monticello ... if you look at the >> older implementations of the tools, there was no enformcement of any >> rationale package naming scheme ... >> >> I agree that today when looking at the point to which Monticello usage has >> evolved that the statement: >> >> "the only way to guarantee a unique version number for a package is to >> scan all available repositories" > What if rather than being incremental the Monticello number what > generated YYMMDDhhmmss? Should be reasonably compatible with that > scope creep of version numbers into Monticello tools. > > Maybe the length is a bit ugly and by convention we can condense it a > bit. Does that timestamp in the filename need to be human decodable? > YY-->alpha character, e.g. 2016-->F (these sort after existing numeric numbers) > MM-->hex e.g. Jan-->1 Oct-->A Dec-->C > DD-->extended hex 1-->1, 16-->F, 30-->T > hh-->extended hex e.g. 1-->1, 16-->F, 23-->M > mm-->standard number > ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F > > Today 2016-06-30 23:15:32 --> F6TM15F > e.g. Collections-Native.BenComan.F6TM15F.mcz > Ben, the "unique version number" was in reference to the current scheme of incrementing the version number ... the truth is that I don't think it is necessary to "guarantee a unique version number" for Monticello purposes ... it is sufficient to take the latest version number or the package from the set of: the image and repositories in repository group... which is the technique that was used for years ... The bug in MCLazyVersionInfo is that it is scanning all repositories connected to the image, when it is sufficient to scan the repositories in the working copy repository group to get a reasonably unique version number ... Dale

June 29, 2016

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

by Ben Coman

On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 6/29/16 1:00 AM, Thierry Goubier wrote: >> >> 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. > > That's not true. Each working copy has repository group where either the > developer has either explicitly declared the set of repositories that are > associated with the working copy and/or the system has recorded the set of > repositories from which the package has been loaded ... you should restrict > the search to the repos in the repository group. >> >> >> (at the same time, restricting version number determination to a subset of >> the repositories is against MC principles when numbering versions). > > In principle, yes, but from a practical point of view, the version number > search was "always" restricted to the set of repositories in the repository > group for the working copy ... keep in mind that putting version numbers in > the package name is a _convention_. I don't think that Monticello ever > defined a package name syntax ... Technically, Monticello is supposed to use > the UUID to disambiguate between to packages with the same name, but as you > and I know, this is not really enforced in the code --- Monticello evolved > to rely on the version number for ordering package versions, but I don't > think that was ever part of the design of Monticello ... if you look at the > older implementations of the tools, there was no enformcement of any > rationale package naming scheme ... > > I agree that today when looking at the point to which Monticello usage has > evolved that the statement: > > "the only way to guarantee a unique version number for a package is to > scan all available repositories" What if rather than being incremental the Monticello number what generated YYMMDDhhmmss? Should be reasonably compatible with that scope creep of version numbers into Monticello tools. Maybe the length is a bit ugly and by convention we can condense it a bit. Does that timestamp in the filename need to be human decodable? YY-->alpha character, e.g. 2016-->F (these sort after existing numeric numbers) MM-->hex e.g. Jan-->1 Oct-->A Dec-->C DD-->extended hex 1-->1, 16-->F, 30-->T hh-->extended hex e.g. 1-->1, 16-->F, 23-->M mm-->standard number ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F Today 2016-06-30 23:15:32 --> F6TM15F e.g. Collections-Native.BenComan.F6TM15F.mcz cheers -ben

June 29, 2016

Re: [Pharo-users] If you have to do web data scraping, what tool would you use?

by PBKResearch

Bernardo Being now retired, I do programing just for intellectual stimulation. Your problem looked as though it would provide more interest than cryptic crosswords or Sudoku, and it touches on areas of Pharo use that I have some experience with. Soâ¦ The attached file, BernardoDemo.st, shows how to use XMLHTMLParser with xPath and NeoJSON to tackle your problem â or at least a large subset of it. I cobbled it together in a Playground, and the easiest way to use it is to copy it into a Playground and âdo it and goâ for each block of code. There are liberal comments, but if anything is not clear come back to me. A few caveats: 1. XPath is a whole other programming language, embedded in Pharo, which takes some learning. I am by no means expert in it, and it may be that I have used it clumsily. One advantage of embedding it in Pharo is that you can intersperse Pharo and XPath, which I do whenever I canât solve something entirely with XPath. Probably most of the places where I use #collect: followed by more XPath could be done entirely in XPath if I knew how. 2. This is the first time I have tried to use NeoJSON, so do not take my code as an example of how to use it. It all works, as far as I can see. I cannot claim more than that. 3. The easiest way to generate an object (or map) in NeoJSON is to start with a Pharo dictionary, which I have done everywhere. However, this means you have no control over the order in which the attributes appear in the JSON file. This is of no importance to a computer, since by definition the attributes are unordered, but it makes it a little odd to a human reader of the JSON. 4. In your spec, the desired output has a lot of unquoted strings for attribute names, for example nbd_no. The code produces these strings with double quotes, which as far as I can see is necessary for legal JSON. 5. Note that all numerical values appear in the output as strings. No doubt they could be converted to numbers, but I was too lazy to find out how. 6. I have done this using Moose 5.1 (Pharo 4.0, build #40613), with versions of XMLHTMLParser and XPath which I downloaded quite a while ago. There are no particularly abstruse uses, so I hope you will be OK if you use more recent versions. Hope this is helpful. Best wishes Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Bernardo Ezequiel Contreras Sent: 27 June 2016 15:17 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] If you have to do web data scraping, what tool would you use? Doru, See attached file, it's a job posting from upwork. On Mon, Jun 27, 2016 at 3:58 AM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> > wrote: Hi, Could you provide more details about the use case? Cheers, Doru > On Jun 26, 2016, at 11:14 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com <mailto:vonbecmann@gmail.com> > wrote: > > Hi, > Imagine that you have to do some data scraping work, what tool would you use? > I know about ZnClient, Soup, NeoCSV, NeoJSON, is there something else that i'm not aware of it? > > thanks. > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. -- www.tudorgirba.com <http://www.tudorgirba.com> www.feenk.com <http://www.feenk.com> "If you can't say why something is relevant, it probably isn't." -- Bernardo E.C. Sent from a cheap desktop computer in South America.

June 29, 2016