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

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

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

by Nicolai Hess

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 29, 2016

Re: [Pharo-users] Issue with NeoCSVReader

by Sven Van Caekenberghe

> On 29 Jun 2016, at 09:45, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > > 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 So yes, CSV is only defined for records that are all the same size. NeoCSVReader can however deal with shorter records. The first record (or header, or convertors) define the number of fields for the whole file. Obviously, only empty fields at the end are supported. Here is an example: (NeoCSVReader on: '1,2,3\5\3,2,1' withCRs readStream) emptyFieldValue: #empty; upToEnd. => #(#('1' '2' '3') #('5' #empty #empty) #('3' '2' '1')) The second line/record contains only one value, empty ones are added automatically. The #emptyFieldValue is optional and defaults to nil. Sven

June 29, 2016