March 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] json parse problem

by Roelof Wobben

Op 16-3-2019 om 22:24 schreef Sven Van Caekenberghe: > imageUrl1 := levelsJson detect: [ :item | item name = 'z4' ]. > imageUrl := imageUrl1 tiles first url. Thanks I used NeoJsonReader. After chancing it to NeoJsonObject It worked. I think I can do the same here : json := NeoJSONReader fromString: (ZnEasy get: url) contents. Â Â Â artObjectJson := json at: #artObject. Â Â Â painter := ((artObjectJson at: #principalMakers) at: 1) at: #name. Â Â Â title := artObjectJson at: #title. and here (json at: #artObjects) Â Â Â Â Â Â do: [ :eachArtObject | Â Â Â Â Â Â Â Â Â | painting | Â Â Â Â Â Â Â Â Â painting := Painting new. Â Â Â Â Â Â Â Â Â painting objectNumber: (eachArtObject at: #objectNumber). Â Â Â Â Â Â Â Â Â paintings addPainting: painting ]. Â Â Â ^ paintings I will try that tomorrow. Now time to sleep here Roelof

March 16, 2019

Re: [Pharo-users] A strange iceberg/Monticello loading issue that has appeared in 7.0.2?

by Tim Mackinnon

Hmmm - hang on a second, something very weird is going on - looking at how to track where files get written on OSX and using: touch ~/timestamp find -x / -newer ~/timestamp >~/changedfiles.txt The result is that when I do my zero conf install - my files now seem to be going to the 7.0.2 install that I did on Thursday, and not to the local directory where I am running. I think Is it possible that this new release has change something. - WTF? How can this happen? /Users/macta/Dev/Smalltalk/Pharo/Pharo 7.0 - 64bit (7.0.2)/pharo-local/iceberg/exercism/pharo-smalltalk/.git /Users/macta/Dev/Smalltalk/Pharo/Pharo 7.0 - 64bit (7.0.2)/pharo-local/iceberg/exercism/pharo-smalltalk/.git/refs/heads /Users/macta/Dev/Smalltalk/Pharo/Pharo 7.0 - 64bit (7.0.2)/pharo-local/iceberg/exercism/pharo-smalltalk/.git/index /Users/macta/Dev/Smalltalk/Pharo/Pharo 7.0 - 64bit (7.0.2)/pharo-local/iceberg/exercism/pharo-smalltalk/.git/FETCH_HEAD /Users/macta/Dev/Exercism/pharo7e3 /Users/macta/Dev/Exercism/pharo7e3/Pharo.changes /Users/macta/Dev/Exercism/pharo7e3/pharo-local /Users/macta/Dev/Exercism/pharo7e3/pharo-local/iceberg /Users/macta/Dev/Exercism/pharo7e3/pharo-local/iceberg/credentials.fuel /Users/macta/Dev/Exercism/pharo7e3/pharo-local/ombu-sessions /Users/macta/Dev/Exercism/pharo7e3/pharo-local/ombu-sessions/Pharo7.0.2-0-32bit-890f474.c1wfkijoa7470az0raz1zczo0.ombu /Users/macta/Dev/Exercism/pharo7e3/icon-packs /Users/macta/Dev/Exercism/pharo7e3/icon-packs/idea11.zip Tim > On 16 Mar 2019, at 21:50, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Sean - thanks for chipping in: > > Yes - the correct packages are loading, the baseline is fine (and its a baseline Iâve been using without issues for a while) - its simply just not loading the same source as if I do a clone by hand via git in a separate directory? > > Itâs like iceberg just doesnât want to load the lates stuff and wants me to do a manual âpullâ in the image to catch up? > > Thinking that maybe my master branch was weird - I did a hard reset in a separate copy, and update the readme.md and committed that, and pushed it. > > Now when I go back to my pharo zero, conf - and clear out the iceberg directory, and run my command line/or playground script again - it now loads and says I need to pull 5 new commits (prior to this, it said 4 commits). > > The is what Iâm not understanding - why isnât it just pulling in all of those commits in a fresh load? Iâve never seen this before, and am at a loss why this is suddenly happening? > > If I open the settings, and check software config management - the share repoâs setting is unchecked. However - the weird thing is that I donât see anything in the pharo-local/iceberg directory (making me think that something must have got flipped - but Iâve not knowingly done anything in the few hours between when it last worked and suddenly stopped). > > Grrrrâ¦ just as I was starting to get the hang of things, its all fallen apart again. > > Tim > >> On 16 Mar 2019, at 17:34, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tim Mackinnon wrote >>> Can anyone think of what might cause this? Iâm really confused. >> >> Am I understanding correctly that your load script is loading the correct >> packages, but not the latest versions? >> >> If so, just a few initial thoughts: >> - What does the local clone look like after the load (i.e. does it show the >> missing commit(s)? >> - It is possible that shared repo location is enabled? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

March 16, 2019

Re: [Pharo-users] A strange iceberg/Monticello loading issue that has appeared in 7.0.2?

by Tim Mackinnon

Hi Sean - thanks for chipping in: Yes - the correct packages are loading, the baseline is fine (and its a baseline Iâve been using without issues for a while) - its simply just not loading the same source as if I do a clone by hand via git in a separate directory? Itâs like iceberg just doesnât want to load the lates stuff and wants me to do a manual âpullâ in the image to catch up? Thinking that maybe my master branch was weird - I did a hard reset in a separate copy, and update the readme.md and committed that, and pushed it. Now when I go back to my pharo zero, conf - and clear out the iceberg directory, and run my command line/or playground script again - it now loads and says I need to pull 5 new commits (prior to this, it said 4 commits). The is what Iâm not understanding - why isnât it just pulling in all of those commits in a fresh load? Iâve never seen this before, and am at a loss why this is suddenly happening? If I open the settings, and check software config management - the share repoâs setting is unchecked. However - the weird thing is that I donât see anything in the pharo-local/iceberg directory (making me think that something must have got flipped - but Iâve not knowingly done anything in the few hours between when it last worked and suddenly stopped). Grrrrâ¦ just as I was starting to get the hang of things, its all fallen apart again. Tim > On 16 Mar 2019, at 17:34, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> Can anyone think of what might cause this? Iâm really confused. > > Am I understanding correctly that your load script is loading the correct > packages, but not the latest versions? > > If so, just a few initial thoughts: > - What does the local clone look like after the load (i.e. does it show the > missing commit(s)? > - It is possible that shared repo location is enabled? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

March 16, 2019

Re: [Pharo-users] json parse problem

by Sven Van Caekenberghe

> On 16 Mar 2019, at 21:17, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Op 16-3-2019 om 18:16 schreef Sven Van Caekenberghe: >> imageUrl1 := levelsJson detect: [ :item | item name = 'z4' ]. >> imageUrl := imageUrl1 tiles first url. >> > > > nope, > > when I do this I see this error messsage : > > MessageNotUnderstood: Dictionary>>name > > Roelof Yes, but you have to parse your JSON differently, either doing NeoJSONObject fromString: .. or, alternatively you have to set the #mapClass, like this (NeoJSONReader on: string readStream) mapClass: NeoJSONObject; propertyNamesAsSymbols: true; next. I don't know how you invoke NeoJSON right now, but you have to change that slightly.

March 16, 2019

Re: [Pharo-users] json parse problem

by Roelof Wobben

March 16, 2019

Re: [Pharo-users] Calypso question: adding a context menu item

by Sean P. DeNigris

Juraj Kubelka wrote > To implement a context menu item Just in case someone stumbles on this thread with a similar problemâ¦ Much has changed in Calypso and dependencies, making this snippet obsolete. After struggling to port to latest, API, the easiest way to find out how to do this seems to be to dig down via Morphic halos into an existing Calypso command that is close to what you want. More generally, one could browse senders of #classAnnotation, the current pragma, but there are lots of senders. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 16, 2019

Re: [Pharo-users] A strange iceberg/Monticello loading issue that has appeared in 7.0.2?

by Sean P. DeNigris

Tim Mackinnon wrote > Can anyone think of what might cause this? Iâm really confused. Am I understanding correctly that your load script is loading the correct packages, but not the latest versions? If so, just a few initial thoughts: - What does the local clone look like after the load (i.e. does it show the missing commit(s)? - It is possible that shared repo location is enabled? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 16, 2019

Re: [Pharo-users] 7.0.2 and the font glitch - seems far worse than 7.0.1

by Sean P. DeNigris

Tim Mackinnon wrote > it seems that this smallish combination of projects really triggers it > quickly and reliably Can you share the load script? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 16, 2019

Re: [Pharo-users] json parse problem

by Sven Van Caekenberghe

> On 16 Mar 2019, at 16:32, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sat, 16 Mar 2019 at 23:29, Roelof Wobben <r.wobben(a)home.nl> wrote: > oke, > > how do I then get the url of the line where the name is z4. > > I haven't directly tested, but probably... > imageUrl1 := levelsJson detect: [ :item | (item at: #name) = 'z4' ]. > imageUrl := ((imageUrl1 at: #tiles) at: 1) at: #url If you are not using mapping, you get Dictionary and Array instances back. You can substitute Dictionary for NeoJSONObject, which is a Dictionary subclass that behaves more like a JavaScript object (which is good or bad, depending on your point of view). obj := NeoJSONObject fromString: '{"foo":1,"bar":-2}'. Given the above, you can do obj foo obj bar It is as if each key has an accessor (and mutator as well). If there is no such key, nil is returned, duh. So you could write Ben's code as imageUrl1 := levelsJson detect: [ :item | item name = 'z4' ]. imageUrl := imageUrl1 tiles first url. Which you might like more. > cheers -ben > > I need that because I need that line and then the tiles part which is also a collection and then the url part which also is a part of a collection > > Roelof > > > > Op 16-3-2019 om 16:24 schreef Ben Coman: >> >> >> On Sat, 16 Mar 2019 at 17:05, Roelof Wobben <r.wobben(a)home.nl> wrote: >> Thanks, >> >> With your hint I solved it this way : >> >> imageUrl1 := levelsJson select: [ :item | (item at: #name) = 'z4' ]. >> imageUrl := (((imageUrl1 at: 1) at: #tiles) at: 1) at: #url >> >> Cool. Minor tweak... if you use #detect: instead of #select: >> which returns the first matched item rather than a collection >> so you wont need ....(imageUrl1 at: 1).... part. >> >> cheers -ben >> >> >> Roelof >> >> >> >> Op 16-3-2019 om 01:04 schreef Ben Coman: >>> >>> >>> On Sat, 16 Mar 2019 at 04:21, Roelof Wobben <r.wobben(a)home.nl> wrote: >>> Hello, >>> >>> I try to parse a json that differs some times >>> >>> after parsing with neojson I see something like this >>> >>> "an Array(a Dictionary('height'->3640 'name'->'z0' 'tiles'->an Array(a Dictionary('url'->'http://lh3...TItQ4wwXk80sCHkqSS3JgTgmehYP-OItkO4hMwqH1agr-LfNRnxUCRSJKc_VQ=… >>> ' 'x'->0 'y'->0 )) 'width'->404 ))" >>> >>> >>> is there a way I can filter out a dictonary where the name is equal to z4 >>> >>> >>> Because of cultural differences, I'm not sure by "filter out" whether you mean include or exclude >>> but when filtering any collection type, #select: #detect and #reject: are you main go to messages. >>> If you inspect your dictionary and on the meta tab filter for ...*select*... >>> you'll find #associationsSelect: >>> which works like this... >>> >>> d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). >>> d associationsSelect: [ :asn | (asn key = 1) and: (asn value = 2) ] >>> d inspect. ==> Dictionary [1 item] (1->2 ) >>> >>> I notice there is not a similar #associationsReject: >>> so if needed you could add your own considering... >>> d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). >>> d associations select: [ :asn | (asn key = 1) and: (asn value = 2) ] >>> d inspect. ==> Array [1 item] (1->2) >>> >>> d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). >>> d associations reject: [ :asn | (asn key = 1) and: (asn value = 2) ] >>> d inspect. ==> Array [2 items] (5->6 3->4) >>> >>> cheers -ben >> >

March 16, 2019

Re: [Pharo-users] A strange iceberg/Monticello loading issue that has appeared

by Tim Mackinnon

OK - I can rule out 7.0.2 for the iceberg loading, as doing it in a 7.0.1 image has the same issue - it doesnât load the full repo that is showing in GitHub - and leaves me needing to do an extra pull? I donât understand why I need the extra pull step? I think there is something obvious that is eluding me, but I just donât understand what? Any git/iceberg gurus that could advise? Tim > On 16 Mar 2019, at 11:52, Tim Mackinnon <tim(a)testit.works> wrote: > > Mulling this over - I have a few more experiments to try > 1 - try loading from the playground and not the cmd line > 2 - dig out a previous 7.0.1 zero conf image (that previously worked with an older master branch), clean out iceberg-local and see if itâs something in the new master that causes this > > If anyone can think of an obvious thing Iâm missing, I would appreciate the input > > Tim > > Sent from my iPhone > >> On 16 Mar 2019, at 09:20, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Iâm really struggling a bit with new images in 7.0.2. Now it may be that itâs not .2âs fault - but as Iâve been doing lots of repeatable things in Pharo 6 and 7a and 7.0.1, you notice when things change. >> >> Iâd really appreciate some thoughts on an iceberg/Monticello issue i suddenly hit last night. >> >> I merged a large PR in my project and then tested it in a new zero conf 7.0.2 image and directory from master (via that github pr) with the following command line (which Iâve always used): >> >> ./pharo-ui Pharo.image eval " >> Metacello new >> baseline: 'Exercism'; >> repository: 'github://exercism/pharo-smalltalk:master'; >> load. >> >> The first time it seemed to work, but I found some bugs, and so I fixed them and merged 2 more tiny prâs. When I delete everything (rm -rf), and load it again, it doesn't load everything? Those commits are missing. When look in my image my fixes aren't there in the code (but they show do in github master) - and when I open up an iceberg window in that fresh image it shows 4 incoming pull requests? Why didnât it load everything? >> >> It never used to do this from a clean image using Metacello? >> >> Can anyone think of what might cause this? Iâm really confused. >> >> Tim >> >> Sent from my iPhone >> > >

March 16, 2019