September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Denis Kudriashov

So it is integrated it Pharo 7 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I did pull request for issue 20426 > <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>. > > Interesting that Iceberg uses pinning in couple of places. I not touch it > because it would not be single commit. And I have no idea how contribute in > that case. I thing we are still in process to decide it. > Anyway old messages are deprecated and users will continue work with auto > transformation. > > 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hello. >> >> I guess we are agree to rename. I will prepare pull request for Pharo. >> And Squeak is up to you. >> >> Here is the new messages: >> - pinInMemory >> - unpinInMemory >> - isPinnedInMemory >> - setPinnedInMemory: >> >> What was decision about #pinInMemoryDuring: ? Do we need it? >> >> I understand Eliot in a way that there is no real point in unpinning >> objects. Hence pinDuring: is basically never useful and therefor adding a >> selectir has rather a negative impact >> >> >> +1 >> >> >> Norbert >> >> 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >> >>> +1 for pinInMemory >>> >>> It explains what it does. >>> >>> On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > Hi Norbert, >>> > >>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> >>> wrote: >>> >> >>> >> >>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda < >>> eliot.miranda(a)gmail.com>: >>> >>> >>> >>> Hi Denis, >>> >>> >>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < >>> dionisiydk(a)gmail.com> >>> >>> wrote: >>> >>>> Hi Eliot. >>> >>>> >>> >>>> I know and I only talk about new messages. I am not trying to >>> rethink >>> >>>> full meta model of Smalltalk. >>> >>>> By the way #class is very common message and it is handy to use >>> short >>> >>>> name. But pinning messages will be used rarely in very specific >>> >>>> applications. So no much sense to preserve them in short version. >>> >>> >>> >>> Agreed. So we have to decide whether to go with pinInMemory or >>> >>> pinObject, pinObject being suggested by Norbert because it matched >>> >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you >>> feel >>> >>> strongly about pinObject et al? >>> >>> >>> >> No I don't. It feels only good to me if there is a requirement not to >>> >> implement selectors that are likely to be used in user code. I'm ok >>> with >>> >> pinInMemory although I asked myself where can it be pinned elsewhere >>> if >>> >> not in memory. So the suffix in memory doesn't add anything but also >>> moves >>> >> the selector out of user space. >>> > >>> > Well I think Denis' point is that pinInMemory removes ambiguity with >>> pin for >>> > other uses and I agree. So I for one am happy to change it to >>> pinInMemory >>> > et al. >>> > >>> >> >>> >> Norbert >>> >> >>> >>>> >>> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>>> Hi Denis, >>> >>>>> >>> >>>>> >>> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov < >>> dionisiydk(a)gmail.com> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>> I am really wonder guys. I thought you are not big funs of Object >>> >>>>>> protocol. >>> >>>>>> Current pinning messages are a new set of very generic messages >>> in the >>> >>>>>> Object. >>> >>>>> >>> >>>>> Yes, and that's because this is a fundamental property of all >>> >>>>> non-immediate objects. Do you object to the #class message? >>> Should it >>> >>>>> be #classObject because it might conflict with #class used in an >>> >>>>> educational or socioeconomic model? All objects other than >>> immediates >>> >>>>> can move. Pinning stops that movement. It applies generally. So >>> the >>> >>>>> protocol belongs in Object. >>> >>>>> >>> >>>>> >>> >>>>>> >>> >>>>>> About Norbert idea. >>> >>>>>> - bePinnedObject is not bad convention. But I would prefer the >>> memory >>> >>>>>> suffix because it reflects the low level behaviour. >>> >>>>>> >>> >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com >>> >: >>> >>>>>>> yes, me :) >>> >>>>>>> >>> >>>>>>> I do not see a reason to change them, tbh. >>> >>>>>>> for me they are comprensible as they are now and it does not adds >>> >>>>>>> more information pinInMemory or pinMemory. >>> >>>>>>> >>> >>>>>>> Esteban >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov < >>> dionisiydk(a)gmail.com> >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> Anybody else? >>> >>>>>>>> >>> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>> >>>>>>>> <pavel.krivanek(a)gmail.com>: >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>> >>>>>>>>> <dionisiydk(a)gmail.com>: >>> >>>>>>>>>> Hi. >>> >>>>>>>>>> >>> >>>>>>>>>> We now have very generic message names: >>> >>>>>>>>>> - pin >>> >>>>>>>>>> - unpin >>> >>>>>>>>>> - setPinned: >>> >>>>>>>>>> - isPinned >>> >>>>>>>>>> >>> >>>>>>>>>> Problem that they collide with possible domain related names. >>> >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I >>> found >>> >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it >>> with >>> >>>>>>>>>> different names. >>> >>>>>>>>>> Probably menus also uses pin word but without overrides >>> >>>>>>>>>> >>> >>>>>>>>>> What you think about renaming pinning messages? Something >>> like: >>> >>>>>>>>>> - pinMemory >>> >>>>>>>>> >>> >>>>>>>>> I would use pinInMemory >>> >>>>>>>>> >>> >>>>>>>>> -- Pavel >>> >>>>>>>>> >>> >>>>>>>>>> - unpinMemory >>> >>>>>>>>>> - isMemoryPinned >>> >>>>>>>>>> - setPinnedMemory: >>> >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >>> >>>>>>>>>> >>> >>>>>>>>>> I think it is easy to do now because not much code uses >>> pinning >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> _,,,^..^,,,_ >>> >>> best, Eliot >>> >> >>> > >>> >>> >> >

Sept. 28, 2017

[Pharo 7.0-dev] Build #160: 20426-Better-pin-messages

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #160 was: SUCCESS. The Pull Request #285 was integrated: "20426-Better-pin-messages" Pull request url: https://github.com/pharo-project/pharo/pull/285 Issue Url: https://pharo.fogbugz.com/f/cases/20426 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 28, 2017

Re: [Pharo-dev] Call for little tasks for GCI

by HernÃ¡n Morales Durand

Hi Stef 2017-09-26 16:08 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi guys > > We want to compete to a competition for newbies programming. > We need to have at least 50 tasks. > Right now the tasks are quite difficult to me :) > > Please help to get some tasks. > > I can be taken from exercisism.io or other little math problems. > > - Grab the Pharo logo from url and display it > - We can turn some of the mooc challenges into tasks. > http://mooc.pharo.org > > I have some ideas but I need your help because I want to finish the > new chapter and book. So the idea is to create exercises that newbie programming students should resolve. Like the ones in https://codegolf.stackexchange.com/ ? Do the problems need a time constraint? > > https://github.com/jigyasa-grover/GCI-2017-with-Pharo > That link gave me 404 error > Stef >

Sept. 28, 2017

Iceberg Contribution Barrier

by Sean P. DeNigris

I wanted to make a fix to Iceberg. I downloaded a fresh Pharo 7.0 image via Launcher, and pasted the Iceberg updating script from the GH readme [1]: #('Iceberg-UI' 'Iceberg-Plugin-GitHub' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGit') do: [ :each | each asPackage removeFromSystem ]. Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg'; load. I got "Instance of AnObsoleteIceMetacelloRepositoryAdapter did not understand #isValid" 1. https://github.com/seandenigris/iceberg ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 28, 2017

Re: [Pharo-dev] Non-deterministic ombu errors

by Stephane Ducasse

tx martin. On Mon, Sep 25, 2017 at 1:07 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> > On 23 Sep 2017, at 22:42, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: >> > >> > Hello >> > >> > I am having very similar errors from time to time when manually loading >> > code >> > into Pharo from filetree (gitfiletree), but only in one of my projects >> > which >> > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very same >> > reason >> > (not able to find why sometimes the error is there and sometimes is >> > not), I >> > did not report it yet, but it is quite annoying. Retrying loading the >> > package helps every time. >> >> I think was reported before. I believe Ombu somewhere takes an arbitrary >> chunk of bytes out of an UTF-8 encoded file (like the last 100 of something >> like that) and then starts reading that. With UTF-8, a variable length >> encoding, that can be dangerous because you could end up in the middle of a >> character, not between encoded character boundaries. This would also explain >> the randomness, as it is highly dependent on the contents. >> >> ZnUTF8Encoder>>#backOnStream: can be used to make sure you are really at >> the start of an encoded character. > > > > Hello > > This issue was reported as: > > https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail-while-reading-non-a… > > My apologies for the bug... I introduced that code as an i/o optimization > but wasn't properly tested. > > Thnks Sven, but I finally used stream's #basicNext (as Henrik suggested in > fogbugz) which skips forward. > > > Martin >

Sept. 27, 2017

Re: [Pharo-dev] Scraping HTML chapter 2 (soon chapter 3 coming)

by Stephane Ducasse

Hello Cedric > > Iâm using Soup from time to time. I use it also with student this semester > to do a small app that get leboncoin adds programmatically to send alerts > (leboncoin is a French web site to sell/buy stuff between people). > cool I want it because I'm looking for Games on leboncoin > I think it should be updated to reflect HTML5 important new tags. For > instance I needed to add the section tag in the Â« nestableBlockTags Â» â¦ > Itâs in SoupParserParameter initializeNestableBlockTags (see the screenshot > - I donât have my image here sot itâs just the method). Without this tag, I > could properly get the classified ads). > > I can publish it if you want but I think there are more important HTML5 > tags to include in this parameters class. As Soup is an "incomplete > parser Â» (as far as I understand), there is no need to include all html5 > tags. But beside <section>, do other people think there are tags to include > there ? > Please publish it. What you can do also is to write a chapter showing how you script leboncoin with Soup. You are welcome. > > > > Cheers, > > CÃ©drick > > > > Le 27 sept. 2017 Ã 09:25, Stephane Ducasse <stepharo.self(a)gmail.com> a > Ã©crit : > > I came with the idea of this booklet thank to Peter Kenny that kindly > answered a question on the Pharo mailing-list. > To help, Peter showed to a Pharoer how to scrap a web site > using XPath. In addition, some years ago > I was maintaining Soup a scraping framework because I was scraping > magic web sites and I wanted an application to manage my magic cards. > Since then I always wanted to try XPath and in addition I wanted to > offer this booklet to Peter. Why because I asked Peter > if he would like to write something and he told that he was at a great > age where he would not take any commitment. > I realised that I would like to get as old as him and be able to hack > like a mad in Pharo with new technology. > So this booklet is a gift to Peter, a great and gentle Pharoer. > > Stef > <scrapingChap2-min.pdf> > > >

Sept. 27, 2017

Re: [Pharo-dev] STON question :)

by Stephane Ducasse

Hi henrik I do not understand everything you mention but let me comment. In the past and until now we used CDIF, then XML with XMI (ugly). and we stopped and built MSE as specified in the moose web site http://themoosebook.org/book/index.html#h1importingandexportingmodels to exchange models. So we have experience on that. It means that people that wanted to use Moose and connect it with their tools in any language were forced to write an MSE exporter. Which is simpler than to use XMI :) Now we do not want to force people to write a STON outputter but to reuse JSON since in any language like there is a JSON library like there is a XML library. For the Schema we are not that dull and know that the syntax is nothing when you do not have the metamodel :) <arg>18610159</arg> is the example I used to show the difference between form and contents when I asked people to get my birth date out of this wonderfully readable <arg> node :). So we have the meta model it is Famix. The point is not for us to port STON to Java, Ada, C#, ... . The point is that people out there in their own language should have a JSON outputer and we want to use JSON to communicate with them. Stef On Wed, Sep 27, 2017 at 3:38 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Stephane Ducasse-3 wrote >> On Tue, Sep 26, 2017 at 1:15 PM, Sven Van Caekenberghe < > >> sven@ > >> > wrote: >>> Stef, >>> >>>> On 24 Sep 2017, at 12:26, Stephane Ducasse < > >> stepharo.self@ > >> > wrote: >>>> >>>> Hi Sven >>>> >>>> For Moose we are wondering if we can use STON to save/load models >>>> instead of MSE. >>>> - I'm sure we can :) >>>> >>>> Now my little friends would like to kill two or three birds with the >>>> same stone :) >>>> >>>> Would it be possible to use STON to handle cycles but to generate JSON >>>> compatible >>>> in the following sense: >>>> >>>> Class { >>>> "id": 123, >>>> "name" : "A" >>>> } >>>> >>>> => >>>> >>>> { >>>> "id": 123, >>>> "type" : "Class", >>>> "name" : "A" >>>> } >>>> >>>> It means that we could be able to output an extra field and when we >>>> read that the materialiser >>>> would create an entity based on the type field for example. >>>> >>>> Am I thinking something totally wrong? >>> >>> I am not sure how to answer. >>> >>> It should be possible to use STON as it is, no ? >> >> No because they want to have JSON syntax >> ie. >> >> { >> "id": 123, >> "type" : "Class", >> "name" : "A" >> } >> >> and not >> >> Class { >> "id": 123, >> "name" : "A" >> } >> >> >>> JSON is different, as you know. NeoJSON was not designed to work with >>> such dynamic types, its optional mapping mechanism works with a static >>> type map. >>> STON is a format with an implementation, it is not designed as a general >>> purpose object visitor. >> >> To me STON is nearly what we need >> - handling cycles >> - nearly JSON >> >> But else we will have to redo our own way to handle cycles again so >> this is why if we could avoid it would be good. >> >>> >>> Sven >>> >>>> Stef >>> > > I would ask myself a second, and quite likely a third, time what JSON is > supposed to give you. > "It's JSON! Anyone can parse it!", is about as useful as an XML file without > a defined schema. > In most cases (static/non-reflective languages excluded) it'll be simpler to > just port STON, compared to building an arbitrary object materializer in > whatever language you intend as a target on top of a stock JSON parser. > Plus, the syntax of the text files will be nicer :) > (And, if you're serious about cross-language object interchange formats, > there's really no way around the static type map approach, even if the > on-disk format happens to be JSON) > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 27, 2017

Re: [Pharo-dev] STON question :)

by Henrik Sperre Johansen

Stephane Ducasse-3 wrote > On Tue, Sep 26, 2017 at 1:15 PM, Sven Van Caekenberghe < > sven@ > > wrote: >> Stef, >> >>> On 24 Sep 2017, at 12:26, Stephane Ducasse < > stepharo.self@ > > wrote: >>> >>> Hi Sven >>> >>> For Moose we are wondering if we can use STON to save/load models >>> instead of MSE. >>> - I'm sure we can :) >>> >>> Now my little friends would like to kill two or three birds with the >>> same stone :) >>> >>> Would it be possible to use STON to handle cycles but to generate JSON >>> compatible >>> in the following sense: >>> >>> Class { >>> "id": 123, >>> "name" : "A" >>> } >>> >>> => >>> >>> { >>> "id": 123, >>> "type" : "Class", >>> "name" : "A" >>> } >>> >>> It means that we could be able to output an extra field and when we >>> read that the materialiser >>> would create an entity based on the type field for example. >>> >>> Am I thinking something totally wrong? >> >> I am not sure how to answer. >> >> It should be possible to use STON as it is, no ? > > No because they want to have JSON syntax > ie. > > { > "id": 123, > "type" : "Class", > "name" : "A" > } > > and not > > Class { > "id": 123, > "name" : "A" > } > > >> JSON is different, as you know. NeoJSON was not designed to work with >> such dynamic types, its optional mapping mechanism works with a static >> type map. >> STON is a format with an implementation, it is not designed as a general >> purpose object visitor. > > To me STON is nearly what we need > - handling cycles > - nearly JSON > > But else we will have to redo our own way to handle cycles again so > this is why if we could avoid it would be good. > >> >> Sven >> >>> Stef >> I would ask myself a second, and quite likely a third, time what JSON is supposed to give you. "It's JSON! Anyone can parse it!", is about as useful as an XML file without a defined schema. In most cases (static/non-reflective languages excluded) it'll be simpler to just port STON, compared to building an arbitrary object materializer in whatever language you intend as a target on top of a stock JSON parser. Plus, the syntax of the text files will be nicer :) (And, if you're serious about cross-language object interchange formats, there's really no way around the static type map approach, even if the on-disk format happens to be JSON) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 27, 2017

Re: [Pharo-dev] Scraping HTML chapter 2 (soon chapter 3 coming)

by CÃ©drick BÃ©ler

Hi StÃ©phane and all, Iâm using Soup from time to time. I use it also with student this semester to do a small app that get leboncoin adds programmatically to send alerts (leboncoin is a French web site to sell/buy stuff between people). I think it should be updated to reflect HTML5 important new tags. For instance I needed to add the section tag in the Â« nestableBlockTags Â» â¦ Itâs in SoupParserParameter initializeNestableBlockTags (see the screenshot - I donât have my image here sot itâs just the method). Without this tag, I could properly get the classified ads). I can publish it if you want but I think there are more important HTML5 tags to include in this parameters class. As Soup is an "incomplete parser Â» (as far as I understand), there is no need to include all html5 tags. But beside <section>, do other people think there are tags to include there ? Cheers, CÃ©drick > Le 27 sept. 2017 Ã 09:25, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > I came with the idea of this booklet thank to Peter Kenny that kindly > answered a question on the Pharo mailing-list. > To help, Peter showed to a Pharoer how to scrap a web site > using XPath. In addition, some years ago > I was maintaining Soup a scraping framework because I was scraping > magic web sites and I wanted an application to manage my magic cards. > Since then I always wanted to try XPath and in addition I wanted to > offer this booklet to Peter. Why because I asked Peter > if he would like to write something and he told that he was at a great > age where he would not take any commitment. > I realised that I would like to get as old as him and be able to hack > like a mad in Pharo with new technology. > So this booklet is a gift to Peter, a great and gentle Pharoer. > > Stef > <scrapingChap2-min.pdf>

Sept. 27, 2017

Re: [Pharo-dev] Scraping HTML chapter 2 (soon chapter 3 coming)

by Tudor Girba

Nice work! Doru > On Sep 27, 2017, at 9:25 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I came with the idea of this booklet thank to Peter Kenny that kindly > answered a question on the Pharo mailing-list. > To help, Peter showed to a Pharoer how to scrap a web site > using XPath. In addition, some years ago > I was maintaining Soup a scraping framework because I was scraping > magic web sites and I wanted an application to manage my magic cards. > Since then I always wanted to try XPath and in addition I wanted to > offer this booklet to Peter. Why because I asked Peter > if he would like to write something and he told that he was at a great > age where he would not take any commitment. > I realised that I would like to get as old as him and be able to hack > like a mad in Pharo with new technology. > So this booklet is a gift to Peter, a great and gentle Pharoer. > > Stef > <scrapingChap2-min.pdf> -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Sept. 27, 2017