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

Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by Tim Mackinnon

If you forget to initialise a variable which you thought was a Dictionary - you get a confusing error message: "Error: only integers should be used as indicesâ if you try an at:put: This is a consequence of having at:put: defined on Object (which is a bit nasty) Should UndefinedObject at least override this and signal something a bit more obvious? This is a common and easily done thing and we don't support it very well. I just did it in some code, and was scratching my head initially until I read the stack properly and realised it was something much simpler than I thought I had done. Any thoughts on this?

March 12, 2019

Re: [Pharo-users] Pharo OSX bundle in Mojave - how to sign ? (Was Re: OS X bundle, some progress)

by Hilaire

Hi, Today I realized another problem on some Mac OSX. It looks like when you download an app on the net, whenever your run it, OS X re-localizes it on a read only location. A guess a protection measure. It leads to obvious problem. For example, once I download DrGeo and run it, the image location resolve to this place: /private/var/folders/bb/spq6th0s7814jgk9nybbqjrw45hrqn/T/AppTranslocation/D0FEC575-60D6-4F2B-A1C3-3259271B9C92/d/DrGeo.app/Contents/Resources I don't have the global picture and it is hard to understand what's going on. Moving to the Application place seems to resolve the issue. But some users told me they have to move DrGeo from Download, then Application, then back to Download to get it running without RW error. What a strange world. Guys, what about throwing away these Mac, the promise of freedom[1] is longtime twisted :-) Ok just kidding, well half-kidding. Hilaire [1] https://www.youtube.com/watch?v=2zfqw8nhUwA Le 09/03/2019 Ã 10:10, CÃ©drick BÃ©ler a Ã©critÂ : > Hi, > > I tried a bit more to make DrGeo bundle works. > > I have Mojave (10.14) and the problem of corrupted files seems to come from Gatekeeper with prevent unsigned applications (from unknot developper) to open. > > Gatekeeper can be temporary stopped and then the bundle work, even when Gatekeeper is reactivated. But clearly, this is not a friendly user way of installing DrGeo. > > So I guess the actual (old ?) bundle procedure doesnât fit Apple politic on application security. I'm pretty sure PharoLauncher faced this already. > > So my question is: > - how to make a signed bundle for OSX ? > â do we need a real developer account ? Iâve a free one and access to a paid one. Can we do it with a general Â« pharaoh Â» account like for Pharo-Launcher ? > > > Cheers, > > CÃ©drick -- Dr. Geo http://drgeo.eu

March 11, 2019

Re: [Pharo-users] Pharo and FPGA

by Noury Bouraqadi

Hi Norbert, The PhD of Sang (in CC) was about FPGA and Smalltalk. https://lxsang.me/ Noury > On 9 Mar 2019, at 15:31, Norbert Hartl <norbert(a)hartl.name> wrote: > > Iâm trying to collect information about programming in pharo for FPGA. The only things I found are around PharoROS like this [1]. If anyone has more information or is willing to talk about Iâm open ears. > > The background is that we did little things with the PharoThings toolkit and want to research which other combinations like Arduino, ESP32, FPGAs are there to be a good extensions to a Pi. > > Any hint is welcomed! > > Thanks, > > Norbert > > [1] http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20…

March 11, 2019

Re: [Pharo-users] How does the SUnit debug view, highlight lower down in the stack?

by Ben Coman

On Mon, 11 Mar 2019 at 17:31, Tim Mackinnon <tim(a)testit.works> wrote: > Iâve been working on improving some of my testing techniques and the tools > used to do that, and it highlighted something where Iâm not clear on how it > works. > Sometime the debugger highlights a failure lower down in the stack (not > just the stack frame directly below the signaller). > > How does it do it? I canât see what it does to achieve this - however > curiously it differs between types of assert. > > I.e. with: self assert: 2 =3 (it just shows the frame below) > > Yet: self assert: 2 equals: 4 (shows two frames below, and actually > directly shows where in the test failed - with no further clicks which is > brilliant) > > The photos (at the end) demonstrate what I mean - and I can see there is a > defaultAction in TestFailure that pops open the debugger: > > defaultAction > > Processor activeProcess > debug: self signalerContext > title: self description > > > And if I try and do a similar thing for one of my own exceptions - but > wind further down the stack manually (which TestFailure doesât do) like: > > defaultAction > | triggerContext | > triggerContext := self signalerContext findContextSuchThat: > [ :context | context method selector = #doesNotUnderstand: ]. > "Trigger the debugger where the failure happened" > Processor activeProcess > debug: (triggerContext ifNil: [ self signalerContext ]) > title: self messageText > > This gives me a debugger on the line of the failure (which I like), but > the stack above this failure (which in my case was many frames deep) is > gone (presumably as contexts only know their parent, and Iâve backed up > through the parent chain). This is a bit confusing to understand how you > got the error. > > So Iâm left wondering how #assert:equals: ends up highlighting further > down. Iâm missing some concept - and wondering if anyone knows? Itâs not > urgent - but a smalltalkây curiosity about how our environment works. > I haven't dug deeply, but to get you started... using the following as a test case TestCase subclass: #ATest ... ATest >> test1 self assert: 2 =3 ATest >> test2 self assert: 2 equals: 4 If I run each by clicking on their test icons, the pre-debug windows look identical, so the difference occurs after clicking the <Debug> button. Leaving the windows untouched for a moment, and presuming its something to do with identifying the #assert:equals message, use the Finder to search Source for that message and put a "self haltOnce" of all the candidate methods. Then click one <Debug> button, and one of those "self haltOnce"s is triggered. Save that method again to reset the haltOnce, then click the other <Debug> button. Now side-by-side trace through both debuggers looking for differences in execution. cheers -ben

March 11, 2019

Re: [Pharo-users] complex json parsing.

by Ben Coman

On Mon, 11 Mar 2019 at 14:35, Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 11-3-2019 om 00:03 schreef Ben Coman: > > collectionUrl := > > ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > > json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) > > contents. > > paintings := Paintings fromJSON: json. > > Thanks a lot , Ben > > I almost gave it up but I think I see a way to solve this > > The first part gives back exactly the same output as my old code. > For the new one I have to do some trying but I think I can solve it > great !! Now it occurred to me that your approach seemed to be "based from applying functions to manipulate data that happens to be stored in an object", whereas you should invert that philosophy so you are "thinking from inside the object". What data do "I" have and what can "I" do with it. A great read that will help you is "A Mentoring Course in Smalltalk" http://www.lulu.com/au/en/shop/andres-valloud/a-mentoring-course-on-smallta… cheers -ben

March 11, 2019

How does the SUnit debug view, highlight lower down in the stack?

by Tim Mackinnon

Iâve been working on improving some of my testing techniques and the tools used to do that, and it highlighted something where Iâm not clear on how it works. Sometime the debugger highlights a failure lower down in the stack (not just the stack frame directly below the signaller). How does it do it? I canât see what it does to achieve this - however curiously it differs between types of assert. I.e. with: self assert: 2 =3 (it just shows the frame below) Yet: self assert: 2 equals: 4 (shows two frames below, and actually directly shows where in the test failed - with no further clicks which is brilliant) The photos (at the end) demonstrate what I mean - and I can see there is a defaultAction in TestFailure that pops open the debugger: defaultAction Processor activeProcess debug: self signalerContext title: self description And if I try and do a similar thing for one of my own exceptions - but wind further down the stack manually (which TestFailure doesât do) like: defaultAction | triggerContext | triggerContext := self signalerContext findContextSuchThat: [ :context | context method selector = #doesNotUnderstand: ]. "Trigger the debugger where the failure happened" Processor activeProcess debug: (triggerContext ifNil: [ self signalerContext ]) title: self messageText This gives me a debugger on the line of the failure (which I like), but the stack above this failure (which in my case was many frames deep) is gone (presumably as contexts only know their parent, and Iâve backed up through the parent chain). This is a bit confusing to understand how you got the error. So Iâm left wondering how #assert:equals: ends up highlighting further down. Iâm missing some concept - and wondering if anyone knows? Itâs not urgent - but a smalltalkây curiosity about how our environment works. Tim The debugger that pops up for assert: vs. The debugger that pops up for #assert:equals:

March 11, 2019

Re: [Pharo-users] complex json parsing.

by Roelof Wobben

Op 11-3-2019 om 00:03 schreef Ben Coman: > collectionUrl :=Â > 'https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=…'. > Â Â json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) > contents. > Â Â paintings := Paintings fromJSON: json. Thanks a lot , Ben I almost gave it up but I think I see a way to solve this The first part gives back exactly the same output as my old code. For the new one I have to do some trying but I think I can solve it Roelof

March 11, 2019

Re: [Pharo-users] complex json parsing.

by Ben Coman

On Mon, 11 Mar 2019 at 01:09, Roelof Wobben <r.wobben(a)home.nl> wrote: > Op 10-3-2019 om 17:45 schreef Ben Coman: > > > > On Sun, 10 Mar 2019 at 23:40, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> Op 10-3-2019 om 16:19 schreef Ben Coman: >> >> >> >> On Sun, 10 Mar 2019 at 17:55, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> I could do something like this : >>> >>> getImages >>> | json numbers json2 | >>> json := NeoJSONReader >>> fromString: >>> (ZnEasy >>> get: >>> ' >>> https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… >>> ') >>> contents. >>> numbers := self class fromJSON: json >>> numbers do: [each | json := ......... >>> imageData = self class ??? >>> >> >> I'm not sure what "numbers" refers to. It seems a quite non-domain >> related identifier. >> To understand the domain, pasting the json contents of your link above >> into https://jsonformatter.curiousconcept.com/ >> and collapsing objects I see the structure is... >> >> <snip> > > Did you work through this example I provided? Please do so. > In a clean image... > >> Start with only your original code (which was good btw)... >> >> Paintings class >> fromJSON: json >> | instance artObjects | >> instance := self new. >> artObjects := json at: #artObjects. >> artObjects >> do: >> [ :eachArtObject | instance addPainting: (Painting >> fromJSON: eachArtObject) ]. >> ^ instance >> >> > except objectNumber(s) seem associated with each painting, so should be > stored within the painting object, as ADDED here... > > > Painting class >> fromJSON: json > > | instance | > instance := self new. > instance > objectNumber: (json at: #objectNumber); "<<<<<<<<ADDED" > title: (json at: #title); > painter: (json at: #principalOrFirstMaker); > imageUrl: ((json at: #webImage) at: #url). > ^ instance > > Evaluate the following in Playground... > collectionUrl := ' > https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… > '. > collectionJson := NeoJSONReader fromString: (ZnEasy get: > collectionUrl) contents. > paintings := Paintings fromJSON: collectionJson. > paintings inspect. > > then clean the DNU errors as they occur (i.e. click the <Create> button > shown by the debugger, and fill in as follows...) > when you save the methods, choose <Declare new instance variable>" > > Painting >> objectNumber: aString > objectNumber := aString > >> Painting >> title: aString >> title := aString >> >> Painting >> painter: aString >> painter := aString >> >> Painting >> imageUrl: aString >> imageUrl := aString >> >> Paintings >> addPainting: aPainting >> paintings := paintings ifNil: [ OrderedCollection new ]. >> paintings add: aPainting. >> >> and an inspector will appear showing a list of paintings, which you can >> drill down to a painting and see each has the expected data. >> Now just to round things off... >> >> Painting >> title >> ^ title >> >> Painting >> printOn: aStream >> super printOn: aStream. >> aStream << ' (' << self title << ')' >> >> to help distinguish each item in the Inspector. >> >> >> To extend the Playground code to download and display a painting, in >> Playground evaluate... >> >> painting := paintings first. >> imageResponse := ZnEasy get: painting imageUrl. >> image := ImageReadWriter formFromStream: imageResponse entity >> readStream. >> image inspect. >> >> Paintings >> first >> ^ paintings first >> >> Painting >> imageUrl >> ^ imageUrl >> >> and an inspector on the `image` variable displays the painting on the >> Morph tab. >> >> >> Now to mold the IDE to your domain... >> using Spotter to browser gtInspector* methods, a promising find is... >> AbstractFileReference>>gitInspectorJpegIn: >> from which I produced... >> >> Painting >> gtInspectorJpegIn: composite >> <gtInspectorPresentationOrder: 0> >> composite morph >> title: 'Painting'; >> display: [ ImageReadWriter formFromStream: self imageEntity readStream ] >> >> Then inspecting the `paintings` variable and drilling down to a painting >> pops up a DNU #imageEntity, which can be resolved by... >> >> Painting >> imageEntity >> ^ imageEntity ifNil: [ imageEntity := (ZnEasy get: self imageUrl) entity >> ]. >> >> and you get to see the painting shown in the Inspector. >> >> >> Now if I understand your question... "Do I need to make some more object >> to get this working..." >> I'd say... No. You only want one object for each painting. Once you have >> a painting object, it should handle all getting all further data it needs >> for itself. >> You don't want duplicate objects each having half of the data. >> >> >> can I for example name the function fromJson2 or fromJSONFromLink2 ? >>> >> >> By naming convention #fromJson: implies it sits on the class side. >> To get further data for an existing object you want an instance-side >> method, maybe named #getLink2Json. >> >> HTH, >> cheers -ben >> >> >> >> oke >> >> numbers should be the objectNumbers because for the rest I need them >> > > > > >> >> >> I use a instance variable called painting to hold the data. >> >> >> so I can change the call to get data for the painting to : >> >> Painting class >> fromJSON: json >> | instance | >> instance := self new. >> instance >> objectNumber: ((json at: #objectNumber). >> ^ instance >> >> >> so numbers should be a collection of 10 ObjectNumbers >> > > I'm presuming that 10 objectNumbers relate to 10 different paintings, > in which case, No, you should never need to deal with a collection of 10 > objectNumbers. > What you should have is a collection of painting-objects which know their > own objectNumber > and then iterate that collection sending each painting-object the message > "getLink2Json". > > > >> so I should use a loop to make a call to the second api call >> > > In Pharo OO approach, you don't "loop" on the "calls", > you "iterate" on the "objects" asking them to use their own data to do the > stuff they know how to do. > i.e. Let each object take care of itself. > > Which class is getImages defined on? That is really important to > understand your proposed solution. > I'm just presuming its defined on the class side of Paintings since your > are referring to the same URL as before. > >> >> getImages >> | json numbers | >> json := NeoJSONReader >> fromString: >> (ZnEasy >> get: >> ' >> https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… >> ') >> contents. >> numbers painting := self class fromJSON: json >> > > btw, it won't work with two identifiers "numbers painting" to the left of > the assignment symbol. Space here bad. > > > numbers do: [each | json := call to the second url.here I used >> each >> imageData = self class >> getLink2Json >> > json2 := call to the 3th url >> otherData := self class >> getLink3Json >> >> > > no :) the "self class" seems wrong. > getting extra data about a painting should be handled by the instance side > of its painting-object. > > > >> Then I can I hope on every json method fill in the data I need >> >> Do I understand you well >> > > I think not so well yet :) (or else I am missing something) > Keep trying. It will change the way you think about programming. > > Please work though the example I provided. > cheers -ben > > > > > I did and it worked the same as my code > Still I do not see how to use then the objectNumber in a second call to > the api > for example > > lets say we have only 1 objectNumber now > for example > > SK-C-5 > > then I need that one here : https://www.rijksmuseum.nl/api/nl/collection/SK-C-5?key=[API_KEY]&format=js… > so I see a json response of this : > > <snip> > where I at this moment need only artObjects -> makers -> name and artobject -> title > > And I need to do that for all 10 > > But as far as I know I can only have one fromJson > > You can have as many Painting-class>>fromJsonXxxx methods as you like, but you only call one of them once per painting. This has nothing to do with Json and everything to do with your Painting-class>>fromJson method creating a new Painting-object, and you only want *one* Painting-object per Json-painting, so you can only call one. But actually, you don't need any Painting>>fromJSON:. Please delete it !!!! Then modify the other one as follows... Paintings class >> fromJSON: json | instance | instance := self new. (json at: #artObjects) do: [ :artObjectJson | |painting| painting := Painting new. painting objectNumber: (artObjectJson at: #objectNumber); title: (artObjectJson at: #title); painter: (artObjectJson at: #principalOrFirstMaker); imageUrl: ((artObjectJson at: #webImage) at: #url). instance addPainting: painting ]. ^ instance Does... collectionUrl := ' https://www.rijksmuseum.nl/api/nl/collection?key=14OGzuak&format=json&type=… '. json := NeoJSONReader fromString: (ZnEasy get: collectionUrl) contents. paintings := Paintings fromJSON: json. give you the same result as before? so how do I take care that the second one is called and parsed > and the right info is on the Painting object > > That is my question all the time > > As I said before... > What you should have is a collection of painting-objects which know their own objectNumber > and then iterate that collection sending each painting-object the message "getLink2Json". So more generically, add something like... Painting >> getMoreData "or a better name of your own" | url json artObjectJson | url := 'https://www.rijksmuseum.nl/api/nl/collection/' , objectNumber , '?key=[API_KEY]&format=json' Transcript crShow: 'Getting description from ', url. json := (NeoJSONReader fromString: (ZnEasy get: url) contents). artObjectJson := json at: 'artObject. description := artObjectJson at: 'description'. title := artObjectJson at: 'title'. Now in playground, variable paintings holds a collection 10 ten paintings. So lets ask each of them to get more data. paintings do: [ :painting | painting getMoreData ]. cheers -ben

March 10, 2019

Re: [Pharo-users] FUEL serialization to a file

by Konrad Hinsen

Hi Sven, Thanks for all that background information on the history of streams. It makes everything a lot clearer for me. > But first, it would help a lot that you give a self-contained > reproducible snippet that raises your problem, like mine. I tried > reproducing your failure but could not. My bug is difficult to reproduce because it is triggered only when the "right" kind of buffer overflow happens. I didn't succeed yet to provoke it while serializing simple objects such as strings or arrays. I did manage to reduce my code quite a lot, so here is the shortest example I have for the moment that provokes the bug: Metacello new baseline: 'ComputationalDocuments'; repository: 'github://khinsen/computational-documents-with-gtoolkit:minimal-code-for-serialization-bug'; load. And then APLibraryTest new setUp; testScanDirectory Konrad.

March 10, 2019

Re: [Pharo-users] complex json parsing.

by Roelof Wobben

March 10, 2019