- Pharo-users - lists.pharo.org

Re: how the best deal with this

by Roelof Wobben

Sept. 28, 2020

Re: how the best deal with this

by Sven Van Caekenberghe

> On 28 Sep 2020, at 07:28, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello, > > I have this code : > > getMoreData > | url url2 json json2 artObjectJson levelsJson| > url := 'https://www.rijksmuseum.nl/api/nl/collection/' , objectNumber > , '?key=14OGzuak&format=json'. > url2 := 'https://www.rijksmuseum.nl/api/nl/collection/' > , objectNumber , '/tiles?key=14OGzuak'. > "Read the data from the api respons" > json := NeoJSONReader fromString: (ZnEasy get: url) contents. > artObjectJson := json at: #artObject. > painter := ((artObjectJson at: #principalMakers) at: 1) at: #name. > title := artObjectJson at: #title. > "Read the imageUrl from the api respons" > json2 := NeoJSONObject fromString: (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak') contents utf8Decoded. > levelsJson := (json2 at: #levels). > imageUrl := levelsJson at: 1. > > but now I see that somethimes ZnEasy get: url gives a document of zero bytes. > Now can I put the rest in a big ifFalse block or make another function for it or is there a better more smalltalk way of dealing with this "problem". > > Roelof I think it would be good if you ask de rijksmuseum api guys to explain why https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368 is correctly typed with content-type application/json, while https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles has a missing content-type (while it is clearly also application/json). Your code can be improved as well. If you do your parsing via NeoJSONObject, you do not get Dictionaries back, but instances of NeoJSONObject (a subclass of Dictionary). These behave more like JavaScript maps/objects. You can use accessors, as if they exist, and they will turned into #at: accesses, with the additional feature of returning nil when the property is not found. So, for example, at the end, you can say json2 levels. Instead of at: 1 you can use first, together this gives you json2 levels first. The same approach is possible for the first json expression and its subsequent use (but parse via NeoJSONObject fromString:). json artObject principalMarkers first name. Coming back to your problem, 'sometimes' is not a bug report we can work on, it does not sound good. It could be that the server returns an empty response. But normally, if something is wrong, you should get a real error. The API seems cool though, I got a nice painting back retrieving one of the embedded URLs (artObject->webImage->url) using ZnEasy getJpeg: 'https://lh3.googleusercontent.com/N2m90mImdcoLacUybb_rxcktTwtr0LFhtuzxbSE9e…'. If you use the Form tab in the inspector, you can see the image

Sept. 28, 2020

how the best deal with this

by Roelof Wobben

Hello, I have this code : getMoreData Â Â Â | url url2 json json2 artObjectJson levelsJson| Â Â Â url := 'https://www.rijksmuseum.nl/api/nl/collection/' , objectNumber Â Â Â Â Â Â , '?key=14OGzuak&format=json'. Â Â Â url2 := 'https://www.rijksmuseum.nl/api/nl/collection/' Â Â Â Â Â Â , objectNumber , '/tiles?key=14OGzuak'. Â Â Â "Read the data from the api respons" Â Â Â json := NeoJSONReader fromString: (ZnEasy get: url) contents. Â Â Â artObjectJson := json at: #artObject. Â Â Â painter := ((artObjectJson at: #principalMakers) at: 1) at: #name. Â Â Â title := artObjectJson at: #title. Â Â Â "Read the imageUrl from the api respons" Â Â Â json2 := NeoJSONObject fromString: (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak') contents utf8Decoded. Â Â Â levelsJson := (json2 at: #levels). Â Â Â imageUrl :=Â levelsJson at: 1. but now I see that somethimes ZnEasy get: urlÂ Â gives a document of zero bytes. Now can I put the rest in a big ifFalse block or make another function for it or is there a better more smalltalk way of dealing with this "problem". Roelof

Sept. 28, 2020

Re: why is ZnEasy choking on this and languages as c# and ruby not

by Esteban Maringolo

Hi Roelof, As pointed in the Discord chat, and just for others to know, the HTTP response is not correct since it doesn't set any MIME Type, so Zinc (ZnEasy) does the correct thing that it is to assume the content is application/octet-stream, so you get a ByteArray. If you decode such bytearray using UTF8 you'll get the "text" you're expecting. Just out of curiosity, can you show us a snippet of how you do that in C# and Ruby? Regards, Esteban A. Maringolo On Sun, Sep 27, 2020 at 2:35 PM Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello, > > In a project of mine I do this : > > (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak') contents . > > but this is given me a bytearray. > > When I do the same in other languages I know like c# or ruby I get a dictionary like I suspect. > > > Can som one explain to me why this happens with ZnEasy. > > Regards, > > Roelof >

Sept. 27, 2020

Re: why is ZnEasy choking on this and languages as c# and ruby not

by Sven Van Caekenberghe

> On 27 Sep 2020, at 19:34, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello, > > In a project of mine I do this : > > (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak' > ) contents . > > but this is given me a bytearray. > > When I do the same in other languages I know like c# or ruby I get a dictionary like I suspect. > > > Can som one explain to me why this happens with ZnEasy. > > Regards, > > Roelof This website/webservice has an incomplete http 1.1 fallback IMHO, as it does not set the content-type of the response - in that case the default is application/octet-stream, hence a ByteArray. You can see this when you ask curl to use http 1.1 $ curl -v --http1.1 https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak You will see there is no content-type in the response. Now, curl too will seemingly show you the expected text, but that is an assumption it cannot actually make (it does this in a unix tradition). Now, since we know/expect textual JSON data (apparently), you can make the request work as follows: (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak') contents utf8Decoded. When you have NeoJSON load, you can parse as follows: NeoJSONObject fromString: (ZnEasy get: 'https://www.rijksmuseum.nl/api/nl/collection/SK-C-1368/tiles?key=14OGzuak') contents utf8Decoded. Sven

Sept. 27, 2020

why is ZnEasy choking on this and languages as c# and ruby not

by Roelof Wobben

Sept. 27, 2020

Re: exercism bowling challenge

by DavidBajger

Thanks for your reply! Anyway.. wow, 3 lines of code, I'd like to see that! I didn't really get into FLP (except some small howeworks on University and that's alraeady forgotten), so I don't know, what is the advantage here. I thought that Pharo (Smalltalk) can be considered as functional language too, because of blocks. If there wouldn't be any exception handling, would Pharo code be so compact as well (e.g. by using #inject:into:)? ----- David Bajger -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 25, 2020

Re: exercism bowling challenge

by Roelof Wobben

Sept. 25, 2020

Re: exercism bowling challenge

by Richard O'Keefe

It turns out that this problem has appeared elsewhere, at least twice to my knowledge, and I had already solved the version at Programming Praxis over a year ago. I actually wrote two solutions, in different programming languages. One of them was 8 lines. That was the longer. The Haskell version was just 3 lines. The Exercism tasks are what they are. They DO provide drill in using the more conventional aspects of Smalltalk. They DON'T provide good drill in object-oriented DESIGN. This particular problem can be solved clearly and cleanly with a ByteArray and a handful of integers. The fact that the test harness enforces the raising of certain exceptions which are nowhere mentioned in the specification complicates things rather. (As does the fact that the interface enforced by the test harness contradicts the interface required by the specification.) Remember, given a list of rolls, Haskell can do the whole calculation in three straightforward lines. Getting the code to work is tricky, not because the calculations are intrinsically hard, but because the specification is very confusingly worded. On Fri, 25 Sep 2020 at 19:23, David Bajger <bajger(a)gmail.com> wrote: > Hi Richard, > I want to reply to some of your insights here, because I think it is > sometimes a matter of personal preference on a problem solution, so I > want to compete with your opinion here. I might be totally wrong, when I > see your way of solution and tell just 'you were right, your solution is > more elegant'. For me it is an approach discussion. > > > > Ät 24. 9. 2020 v 15:16 odesÃlatel Richard O'Keefe <raoknz(a)gmail.com> > napsal: > >> Since the problem can be solved, and has been solved, in programming >> languages that do not support object-oriented programming, there is >> obviously no unique "right" factoring of this problem into classes. I'll >> be honest with you: this is the only Pharo exercism I have not tackled, and >> the reason is that I just found the problem specification too ugly to care >> about. I had better get over that. >> > > We are using OO language to isolate problems into particular objects and > their responsibility. I would say there is no "ugly problem to care about". > Sometimes it can be the "right" factoring of a problem into classes and > sometimes it is too hard and that is the point. I think this exercise is > about finding the right place to delegate problems in fitting classes > that are small enough. Of course, it can be resolved by one "long method" > with a total of less lines of code. But in general I like more verbosity > over one compact algorithm that wouldn't tell readers too much. This is a > personal preference. > > >> >> The two primary difficulties are >> (a) the game is described one ROLL at a time, but scored one FRAME at a >> time. >> (b) the rolls are recorded from past to future, but the score can only be >> calculated from future to past. >> > > Way of evaluation is definitely relevant. Key thing for me was to realize > "I always need to evaluate the current state of things", the same way, when > you play bowling. > - Each frame should be able to tell, if it is completed from the point of > actual throw. So, why not just pass throws by game into the current frame, > that would tell, if it is completed or not? > - Frame can calculate score immediately, but bonuses can be later. Maybe > it isn't 'the throw thing' to care about. It is a matter of the game, that > can tell when is the right moment to evaluate bonuses. Game can delegate > such information to the passed frames at the right moment (maybe after each > thow, or maybe when the current frame is completed?). But maybe my previous > sentence can be interpreted as: "this is a big hammer for this solution > already". > > > >> The fact that there may be one extra roll at the end which is not >> technically >> part of any of the 10 frames is just icing on the cake. >> >> But this is *algorithmic* trickiness, not *world model* trickiness. >> >> Let's imagine a Frame class. >> - You get the first roll of the frame. Fewer than 10 pins are knocked >> down. >> You cannot complete initialising the Frame yet. >> > > Well, why not just initialize frame by "collection of 1-2 (maybe 3) > throws"? Depending on the actual state of collection, frame just tells the > game "I have enough throws, so you can pass throws to my neighbor". Rules > for completeness can be different, based on circumstances. For me, it is a > matter of frame responsibility to deal with this. > > >> - All 10 pins are knocked down. You cannot determine the *score* of the >> frame yet. This casts some doubt on the idea of the score being part >> of the state of the frame. The score actually depends on the next two >> THROWS (rolls), not the next frame or the next two frames. This casts >> much doubt on the idea of the concept "frame" being useful for the >> analysis. At the very least, you will need to manipulate BOTH frames >> AND throws (rolls). >> > > When bowling in real, you can determine the score of the current frame. > But bonuses are computed later, so maybe the game should tell (after each > throw), when to evaluate bonus. "Hey, my passed frames, I'm passing you > this information, so evaluate your bonus now". > > > >> It looks as though a Frame class may just make things harder. >> Since the only thing there is to know about a Throw is how many pins >> were knocked down, it doesn't look as though a Throw class is much use >> either. This leaves us with a BowlingGame class that just keeps tracks >> of rolls and then runs a moderately complex algorithm when it is asked >> for the score. >> >> Long past my bed-time or I would get stuck into it. >> >> > It depends on how "moderately complex algorithm" will be readable for end > users. Sometimes it is a real struggle to determine "what a hell is going > on here", because the given method just does too many things in one class. > For me, separating throws into frames makes the whole thing more > understandable to readers, because they can imagine something from real > life (real game). Again, this is personal preference. I've seen few times > that "moderately complex algorithms" were extended by other developers into > "severe too-complex algorithms". Problem is that developers don't do > refactoring at the right time (most probably because of lack of time and > time pressure on projects). On the other hand, I understand it isn't a > problem of this artificial exercise and agree that focus should be just > on existing problem statement and not hypothetical problem. > I did this exercise some time ago and when I look at it now, honestly I'm > not satisfied with my solution, especially the way bonuses are stored and > evaluated in normal vs last frame. But here is the thing: it is isolated on > one given place and used on one other place, I can rewrite it maybe more > easily. > > > >> On Thu, 24 Sep 2020 at 23:53, Roelof Wobben via Pharo-users < >> pharo-users(a)lists.pharo.org> wrote: >> >>> Op 24-9-2020 om 13:42 schreef DavidBajger: >>> > Hi Roelof, >>> > I always wonder, what kind of answer you expect from your prior >>> statement. >>> > To your question: "Can this plan be working or is there improvements >>> to this >>> > plan." I can have this answer: Yes, it could be both: working or fail, >>> but >>> > you don't know before you try. >>> > >>> > This exercise is a bit tricky: >>> > 1) I can recommend to use also LastFrame class, which has specific >>> handling >>> > of bonuses in last round of game (subclass of Frame). Bowling game can >>> be >>> > then initialized with array 9 Frame instances and last instance could >>> be >>> > LastFrame. I used specific test methods on frame classes like: >>> > #isFrameComplete, #isLastFrame, #isSpare, #isStrike, #isOpen. >>> > 2) Beware that Bowling game should know only necessary things and >>> delegate >>> > responsibility to its frames. Game itself knows that only if all >>> frames are >>> > completed, game ends. >>> > 3) Total score is sum of all throws+bonuses of individual frames, etc. >>> > >>> > Does it help to start with exercise? >>> > David >>> > >>> > >>> > >>> > >>> > >>> > ----- >>> > David Bajger >>> > -- >>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> Thanks, >>> >>> Maybe I have to make it more clear. >>> What I trying to ask and what you have answered. Do I use the right >>> classes or too much classes there. >>> So if my idea of using these classes are right. >>> >>> What you wrote is what I had in mind with 2 classes but the idea of a >>> lastFrame could also be working. >>> and I also agree with you about the responsibilities of the classes. >>> >>> Roelof >>> >>

Sept. 25, 2020

Re: exercism bowling challenge

by David Bajger

Hi Richard, I want to reply to some of your insights here, because I think it is sometimes a matter of personal preference on a problem solution, so I want to compete with your opinion here. I might be totally wrong, when I see your way of solution and tell just 'you were right, your solution is more elegant'. For me it is an approach discussion. Ät 24. 9. 2020 v 15:16 odesÃlatel Richard O'Keefe <raoknz(a)gmail.com> napsal: > Since the problem can be solved, and has been solved, in programming > languages that do not support object-oriented programming, there is > obviously no unique "right" factoring of this problem into classes. I'll > be honest with you: this is the only Pharo exercism I have not tackled, and > the reason is that I just found the problem specification too ugly to care > about. I had better get over that. > We are using OO language to isolate problems into particular objects and their responsibility. I would say there is no "ugly problem to care about". Sometimes it can be the "right" factoring of a problem into classes and sometimes it is too hard and that is the point. I think this exercise is about finding the right place to delegate problems in fitting classes that are small enough. Of course, it can be resolved by one "long method" with a total of less lines of code. But in general I like more verbosity over one compact algorithm that wouldn't tell readers too much. This is a personal preference. > > The two primary difficulties are > (a) the game is described one ROLL at a time, but scored one FRAME at a > time. > (b) the rolls are recorded from past to future, but the score can only be > calculated from future to past. > Way of evaluation is definitely relevant. Key thing for me was to realize "I always need to evaluate the current state of things", the same way, when you play bowling. - Each frame should be able to tell, if it is completed from the point of actual throw. So, why not just pass throws by game into the current frame, that would tell, if it is completed or not? - Frame can calculate score immediately, but bonuses can be later. Maybe it isn't 'the throw thing' to care about. It is a matter of the game, that can tell when is the right moment to evaluate bonuses. Game can delegate such information to the passed frames at the right moment (maybe after each thow, or maybe when the current frame is completed?). But maybe my previous sentence can be interpreted as: "this is a big hammer for this solution already". > The fact that there may be one extra roll at the end which is not > technically > part of any of the 10 frames is just icing on the cake. > > But this is *algorithmic* trickiness, not *world model* trickiness. > > Let's imagine a Frame class. > - You get the first roll of the frame. Fewer than 10 pins are knocked > down. > You cannot complete initialising the Frame yet. > Well, why not just initialize frame by "collection of 1-2 (maybe 3) throws"? Depending on the actual state of collection, frame just tells the game "I have enough throws, so you can pass throws to my neighbor". Rules for completeness can be different, based on circumstances. For me, it is a matter of frame responsibility to deal with this. > - All 10 pins are knocked down. You cannot determine the *score* of the > frame yet. This casts some doubt on the idea of the score being part > of the state of the frame. The score actually depends on the next two > THROWS (rolls), not the next frame or the next two frames. This casts > much doubt on the idea of the concept "frame" being useful for the > analysis. At the very least, you will need to manipulate BOTH frames > AND throws (rolls). > When bowling in real, you can determine the score of the current frame. But bonuses are computed later, so maybe the game should tell (after each throw), when to evaluate bonus. "Hey, my passed frames, I'm passing you this information, so evaluate your bonus now". > It looks as though a Frame class may just make things harder. > Since the only thing there is to know about a Throw is how many pins > were knocked down, it doesn't look as though a Throw class is much use > either. This leaves us with a BowlingGame class that just keeps tracks > of rolls and then runs a moderately complex algorithm when it is asked > for the score. > > Long past my bed-time or I would get stuck into it. > > It depends on how "moderately complex algorithm" will be readable for end users. Sometimes it is a real struggle to determine "what a hell is going on here", because the given method just does too many things in one class. For me, separating throws into frames makes the whole thing more understandable to readers, because they can imagine something from real life (real game). Again, this is personal preference. I've seen few times that "moderately complex algorithms" were extended by other developers into "severe too-complex algorithms". Problem is that developers don't do refactoring at the right time (most probably because of lack of time and time pressure on projects). On the other hand, I understand it isn't a problem of this artificial exercise and agree that focus should be just on existing problem statement and not hypothetical problem. I did this exercise some time ago and when I look at it now, honestly I'm not satisfied with my solution, especially the way bonuses are stored and evaluated in normal vs last frame. But here is the thing: it is isolated on one given place and used on one other place, I can rewrite it maybe more easily. > On Thu, 24 Sep 2020 at 23:53, Roelof Wobben via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >> Op 24-9-2020 om 13:42 schreef DavidBajger: >> > Hi Roelof, >> > I always wonder, what kind of answer you expect from your prior >> statement. >> > To your question: "Can this plan be working or is there improvements to >> this >> > plan." I can have this answer: Yes, it could be both: working or fail, >> but >> > you don't know before you try. >> > >> > This exercise is a bit tricky: >> > 1) I can recommend to use also LastFrame class, which has specific >> handling >> > of bonuses in last round of game (subclass of Frame). Bowling game can >> be >> > then initialized with array 9 Frame instances and last instance could be >> > LastFrame. I used specific test methods on frame classes like: >> > #isFrameComplete, #isLastFrame, #isSpare, #isStrike, #isOpen. >> > 2) Beware that Bowling game should know only necessary things and >> delegate >> > responsibility to its frames. Game itself knows that only if all frames >> are >> > completed, game ends. >> > 3) Total score is sum of all throws+bonuses of individual frames, etc. >> > >> > Does it help to start with exercise? >> > David >> > >> > >> > >> > >> > >> > ----- >> > David Bajger >> > -- >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> Thanks, >> >> Maybe I have to make it more clear. >> What I trying to ask and what you have answered. Do I use the right >> classes or too much classes there. >> So if my idea of using these classes are right. >> >> What you wrote is what I had in mind with 2 classes but the idea of a >> lastFrame could also be working. >> and I also agree with you about the responsibilities of the classes. >> >> Roelof >> >

Sept. 25, 2020