- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] json parse problem

by Roelof Wobben

March 16, 2019

Re: [Pharo-users] json parse problem

by Ben Coman

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 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] json parse problem

by Roelof Wobben

March 16, 2019

Re: [Pharo-users] json parse problem

by 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] Why doesn't collection have #excludes (the mirror of includes)?

by Ben Coman

On Sat, 16 Mar 2019 at 17:05, Tim Mackinnon <tim(a)testit.works> wrote: > These are all good suggestions guys - but donât you find it odd that there > isnât the mirror function #excludes: which would make all of them read more > naturally? > > I know we canât have all combinations- but this one really struck me as > odd by its absence (particularly when I was comparing the elegance of my > little coding solution to other languages). > > Should I propose itâs inclusion in Collection? > I'm mostly ambivalent, except simplifying transition from other languages is useful. What are some examples for other languages? cheers -ben > Tim > > Sent from my iPhone > > > On 16 Mar 2019, at 08:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > >> On 15 Mar 2019, at 23:06, Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> aString detect: [:c | ($0 to: $1) excludes: c] ifFound: aBlock. > (Evaluate a block if the string isnât all 0 and 1âs) > > > > (aString allSatisfy: [ :each | '01' includes: each ]) not. > > > > > > >

March 16, 2019