- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Never-ending computations and cmd-dot

by Stephane Ducasse

Hi hernan Indeed it would be nice to have a solution for such case. Now we did not look at it. Stef On Tue, Sep 26, 2017 at 5:58 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Tim, > > Yes, I am aware of such menu item. However I would like to know if > someone is working in a more architectural solution. > Because I guess this would imply to hook message sends into the main > feedback loop. > > Cheers, > > HernÃ¡n > > > 2017-09-25 20:08 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >> Its not quite what you are asking for, but if you right click on one of those windows, someone has helpfully added a âclose all windows to rightâ option, which does let you rapidly get rid of them. >> >> Tim >> >>> On 25 Sep 2017, at 23:16, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> Hi, >>> >>> Guys I have the situation you will recognize in the attached picture: >>> A never-ending recursive computation which generate zillions of >>> pre-debug windows when cmd-dot key is pressed. >>> >>> Is there any setting, or any way to put a monitor to detect that >>> cmd-dot is creating too many windows so will pop-up just one or two? >>> Maybe someone researched this issue, does it makes sense? >>> >>> Cheers, >>> >>> HernÃ¡n >>> <rw.png> >> >> >

Sept. 27, 2017