- Pharo-users - lists.pharo.org

Re: [Pharo-users] Why doesn't collection have #excludes (the mirror of includes)?

by Sven Van Caekenberghe

> On 17 Mar 2019, at 07:56, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > (1) As it happens, my Smalltalk library *does* have "my mystery Smalltalk" ;-) > #excludes: and #identityExcludes: > (2) The definitions are trivial. > excludes: item > ^(self includes: item) not > identityExcludes: item > ^(self identityIncludes: item) not > > If you want to execute aBlock when aString is not all zeros > and ones, just do > (aString allSatisfy: [:each | each = $0 or: [each = $1]]) > ifFalse: [aBlock value]. > or > (aString anySatisfy: [:each | each ~= $0 and: [each ~= $1]]) > ifTrue: [aBlock value]. > or > ('01' includesAll: aString) ifFalse: [aBlock value]. That last expression wins hands down ! Thank you for bringing that up, I learned something new. > On Sat, 16 Mar 2019 at 11:33, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - in my quest to understand the edgier details of Pharo (and Smalltalk) - and driven by fresh thoughts of completing exercism exercises - I was surprised to find that there is no #excludes: operation on collection to mirror the #includes: operation? > > I was curious about this - its seems a strange omission? > > Of course I can inverse it with not, or do things a different way - but we have ifTrue: mirrored with ifFalse, empty/notEmpty so am I missing something? > > I wanted to write something like > > > aString detect: [:c | ($0 to: $1) excludes: c] ifFound: aBlock. (Evaluate a block if the string isnât all 0 and 1âs) > > > Of course I can write this as: > > (aString reject: [:c | c = $0 | c = $1)) ifNotEmpty: aBlock > > But as recent messages in this vein have shown me (and taught me lots - thanks to those answering), the answer is often not what I thought. > > Tim > >

March 17, 2019

[ANN] Lan.d.s Alpha: All Along the Language Tower

by Nick Papoylias

*Dear friends ! * I am quite excited to announce the availability of an alpha version of my latest work around *Parsing and Programming Languages *at: https://npapoylias.gitlab.io/lands-project/ Accompanied by *~ 30 min of transcribed eye-candy:* https://www.youtube.com/playlist?list=PLIjPQnRzAKVHABG1-oTvwWc3Gj1Z4C91B Backed by* a crowdfunding campaign ! *To get the *book and stable release * successfully out of the door: https://www.patreon.com/lands_project https://npapoylias.gitlab.io/lands-project/Support/ *Click, download, watch, enjoy !* If you like what you see, support the project ! Tiers start *from 5 and 10 euros per chapter for individuals.* Companies supporting the project can get *6 to 12 days of consultancy, on-site workshops and other perks.* ================= *What is all about ??* *Lan.d.s is a new solution for language design.* From *general purpose languages *like *Lise* (short for (list (embedding)) to *Domain-Specific Languages using the MOODs framework*, and everything else in between. Lan.d.s is build around the formalism of *Multi-Ordered Grammars, which are a possible alternative to CFGs and PEGs in wider use today.* Multi-ordered grammars (or simply MOGs) aim for a better exploration of ambiguity, recursion, ordering and associativity during language design. They can be *parsed using the Gray Algorithm. *After parsing in order to ease the production of executable code Lan.d.s introduces the *Abstract Syntax Language (ASL)*, which is an OO solution for compile-time meta-programming. Finally in order to promote language extension and re-use, Lan.d.s employs *GrammarTraits, as units of composition for both MOG rules and ASL actions.* ================= Some random highlights for the impatient: ** Object subclass: #Prediction uses: Future syntax* ** Languages are everywhere, they are all around you, even now in this very sentence.* ** Study SICP with a Xerox flavor, while re-inventing some Bell-labs utilities.* ** TOC-Board, the TOC for your next talk ;)* Enjoy !

March 17, 2019

Re: [Pharo-users] Why doesn't collection have #excludes (the mirror of includes)?

by Richard O'Keefe

(1) As it happens, my Smalltalk library *does* have #excludes: and #identityExcludes: (2) The definitions are trivial. excludes: item ^(self includes: item) not identityExcludes: item ^(self identityIncludes: item) not If you want to execute aBlock when aString is not all zeros and ones, just do (aString allSatisfy: [:each | each = $0 or: [each = $1]]) ifFalse: [aBlock value]. or (aString anySatisfy: [:each | each ~= $0 and: [each ~= $1]]) ifTrue: [aBlock value]. or ('01' includesAll: aString) ifFalse: [aBlock value]. On Sat, 16 Mar 2019 at 11:33, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - in my quest to understand the edgier details of Pharo (and Smalltalk) > - and driven by fresh thoughts of completing exercism exercises - I was > surprised to find that there is no #excludes: operation on collection to > mirror the #includes: operation? > > I was curious about this - its seems a strange omission? > > Of course I can inverse it with not, or do things a different way - but we > have ifTrue: mirrored with ifFalse, empty/notEmpty so am I missing > something? > > I wanted to write something like > > > aString detect: [:c | ($0 to: $1) excludes: c] ifFound: aBlock. (Evaluate > a block if the string isnât all 0 and 1âs) > > > Of course I can write this as: > > (aString reject: [:c | c = $0 | c = $1)) ifNotEmpty: aBlock > > But as recent messages in this vein have shown me (and taught me lots - > thanks to those answering), the answer is often not what I thought. > > Tim > > >

March 17, 2019

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

by Tim Mackinnon

Reported as https://github.com/pharo-project/pharo/issues/2854 <https://github.com/pharo-project/pharo/issues/2854> (although there was a similar issue already from P6, but I donât think it made it clear enough the seriousness of this problem). > On 16 Mar 2019, at 22:08, Tim Mackinnon <tim(a)testit.works> wrote: > > 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 <mailto:tim@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 <mailto:sean@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 <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >>> >> >> >

March 17, 2019

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

by Tim Mackinnon

ARRRGGGGGG - its the damn settings file! I recall now, I changed some of the code formatter settings in the 7.0.2, and was using the blue-ink preview in settings, and must have pressed save. Even thought, it was only formatter settings that I changed - the damn file causes iceberg to break (even though there is not reference to using a shared repo, and loading the settings in any of my images doesnât show this). What a hideous bugâ¦. I will report it, or try and raise its priority if its not reported as this is confusing as hell. Tim > On 16 Mar 2019, at 22:08, Tim Mackinnon <tim(a)testit.works> wrote: > > 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 <mailto:tim@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 <mailto:sean@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 <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >>> >> >> >

March 17, 2019

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