December 2017 - Pharo-users

Iceberg is cool!

by Norbert Hartl

I just got back from vacation and prepared a new image to work on the current project. Well, I upgraded iceberg to 0.6.5 and everything works like expected. I can see nicely what my colleagues have done while I was away. I can update everything easily. And most important I can do changes and then cherry pick and commit. So even if people are complaining about missing features (they always do!) I can say that for a basic workflow (for me about 95% of my work) everything seems to be in place. So everyone should feel invited to add the missing pieces. Well done and thank you, Norbert

Dec. 13, 2017

Re: [Pharo-users] FLSerialization>>analysisStep too slow?

by Eno

Thanks Mariano. There is no such method: FLSerializer>>setDebug and FLDebugSerialization class in my 6.1 image. Anyway, my object has an instance variable that save the serialized glamour browser. I deleted that variable, and the saving process became quicker than before. Best regards, eno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 13, 2017

Re: [Pharo-users] Metalinks arguments as Array ?

by Steven Costiou

Ok, i found it digging the mailing list... Working example is in testReifySendArgsAsArray method, where it suffice to use link options: #(argsAsArray). I should try searching in the list before asking...

Dec. 13, 2017

Metalinks arguments as Array ?

by Steven Costiou

Hi, can we somehow provide an array of reifications to a metalink metaobject ? For ex.: link metaObject: [:args| do stuff with args]. link selector: #valueWithArguments:. link arguments: #(object node link receiver sender) So that when the link executes, args in the block would be an array containing all wanted reifications ? This example does not work as is, because the number of reifications (5) is different from the number of arguments taken by the selector (1). The problem is that for blocks, i could use the #value: message, but it is limited to #value:value:value:value:, so 4 arguments. Besides, if i want 10 reifications for example, i would not want to have a selector like #value:value:value:value:value:value:value:value:value:value: ... Any ideas ? Steven.

Dec. 13, 2017

Re: [Pharo-users] Iceberg: Code directory missing

by Stephane Ducasse

I have a lot of "Clarification" wishe list ofr iceberg :) You cannot imagine it. :) On Tue, Dec 12, 2017 at 10:00 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Got it. I didn't realize the code subdirectory wasn't automatically created > by Iceberg if it didn't exist. I deleted the subdirectory name in the repo > config and my code seems to have made it to github. I submitted a pull > request with some clarifications to the iceberg readme. > > Thanks, > Evan > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 13, 2017

Re: [Pharo-users] Pharo intro talk in spanish

by Stephane Ducasse

Thanks a lot. I'm starting to learn spanish (you talk too fast but this is fun to hear). Stef On Wed, Dec 13, 2017 at 1:02 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Thanks Rafael! > > Is good to see more content in native languages and support more > diversity and going away of English as the dominant language monoculture > for science and tech (which reminds me [1]). BTW is a good presentation > with a lot of good points and fighting the balance between the > conceptual and the demo approach (demos with good theoretical background > are hard to build). The only think I miss was a microphone for the ones > making comments and questions in the audience. > > [1] https://aeon.co/essays/how-did-science-come-to-speak-only-english > > Cheers, > > Offray > > > On 12/12/17 11:10, Rafael Luque wrote: >> Hi all, >> >> It has been published the video of the Pharo introduction talk (titled >> "Pharo Smalltalk: Un Entorno de ProgramaciÃ³n Subversiva") we organized >> from Osoco for the Madrid Software Crafters meetup. >> >> Both, video and slides are in spanish: >> https://www.youtube.com/watch?v=SV_KU4u5mTA >> >> Cheers, >> Rafael Luque > >

Dec. 13, 2017

Re: [Pharo-users] Zinc JSON parsing error handling

by Sven Van Caekenberghe

> On 13 Dec 2017, at 10:54, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 13.12.2017 um 10:18 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >>> On 13 Dec 2017, at 10:14, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> To make your core a little bit more reliable you should not catch the general error but a NeoJSONParseError. And you need to guard the dictionary access. There is no guarantee you get something back that inlcudes key success and message. >> >> Yes, indeed. >> >> Also, a better REST API (not something you can change) would not return 200 OK with an error in the payload, but would return a 404 Not Found with a proper error object as payload. >> > I must say that the latter is not a good advize. All HTTP status codes refer to the resource that is specified in the uri. REST is resource based but GET and POST are exceptions beacuse they can address processing entities. It means that the result of the operation is not the entity in the uri. Returning a 404 would mean that the > > https://bittrex.com/api/v1.1/public/getticker > > resource is not available but that is not true and can lead to unwanted behaviour, e.g. that a http stack caches the error and does not try to access that resource again. So the proper status code depends on the definition of the interface. If it is considered to always return an object then the status code needs to be 400 because the specification of the client was invalid. On the other hand you can just return a 200 with an empty result if the search result is optional. > > my 2 cents, Well, yes, you're right. I was too quick and assumed the resource was properly named. That was another remark. The interface does not properly refer to a resource, it is still too procedural, IMHO. I would write it as https://bittrex.com/api/v1.1/public/tickers/LTC A process interface should only be used for, duh, processes that can be identified as such, like a trade that then gets its own unique URI that can be queried for state and so on. REST interface design is a subject we can discuss endlessly, no doubt. > Norbert > >> FWIW, there are a couple of more sophisticated examples, like in NeoJSONMappingTests and NeoJSONExamplesTests, with comments that do various special cases. >> >>> Norbert >>> >>> Am 13.12.2017 um 09:54 schrieb Ben Coman <btc(a)openinworld.com>: >>> >>>> hi Sven, >>>> >>>>> On 13 Dec 2017, at 07:59, Ben Coman <btc(a)openinworld.com> wrote: >>>>> >>>>> >>>>> With... >>>>> Object subclass: #BittrexResponse >>>>> instanceVariableNames: 'success message result' >>>>> classVariableNames: '' >>>>> package: 'Bittrex' >>>>> >>>>> Object subclass: #BittrexMarketSummary >>>>> instanceVariableNames: 'MarketName High Low Volume Last >>>>> BaseVolume TimeStamp Bid Ask OpenBuyOrders >>>>> OpenSellOrders PrevDay Created DisplayMarketName' >>>>> classVariableNames: '' >>>>> package: 'Bittrex' >>>>> >>>>> this code works great when the response holds good data... >>>>> ZnClient new >>>>> url: 'https://bittrex.com/api/v1.1/public/getmarketSummary?market=BTC-LTC'; >>>>> enforceHttpSuccess: true; >>>>> accept: ZnMimeType applicationJson; >>>>> contentReader: [ :entity | |reader| >>>>> reader := (NeoJSONReader on: entity readStream). >>>>> reader for: BittrexResponse do: [:m| >>>>> m mapInstVar: #success. >>>>> m mapInstVar: #message. >>>>> (m mapInstVar: #result) valueSchema: #ResultArray]. >>>>> reader for: #ResultArray customDo: [ :mapping | >>>>> mapping listOfElementSchema: BittrexMarketSummary ]. >>>>> reader mapInstVarsFor: BittrexMarketSummary. >>>>> reader nextAs: BittrexResponse ]; >>>>> get. >>>>> >>>>> i.e. a raw response looking like this.... >>>>> (ZnClient new >>>>> url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=BTC-LTC'; >>>>> get) inspect. >>>>> ==> "'{""success"":true,""message"":"",""result"":[{""MarketName"":""BTC-LTC"",""High"":0.01982450,""Low"":0.01285257,""Volume"":1436429.81313360,""Last"":0.01842000,""BaseVolume"":24841.17217724,""TimeStamp"":""2017-12-13T05:56:25.937"",""Bid"":0.01840001,""Ask"":0.01842000,""OpenBuyOrders"":10140,""OpenSellOrders"":6306,""PrevDay"":0.01439800,""Created"":""2014-02-13T00:00:00""}]}'" >>>>> >>>>> >>>>> But for bad response looking like this... >>>>> (ZnClient new >>>>> url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=INVALID'; >>>>> get) inspect. >>>>> ==> {"success":false,"message":"INVALID_MARKET","result":null} >>>>> >>>>> the JSON handling code fails deep in the call stack with an error >>>>> "NeoJSONParseError: [ expected" >>>>> which is not so friendly for users of the Bittrex library. >>>>> >>>>> What are the different/recommended approaches with Zinc >>>>> for catching JSON errors such that I can pass "message" >>>>> as a higher level Error up the stack to the Bittrex user. >>>>> >>>>> cheers -ben >>>> >>>> >>>> On 13 December 2017 at 15:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> BTW, this is no about Zinc, but about NeoJSON. >>>> >>>> This is what I meant with variability that is hard to capture with a simple static type schema. >>>> >>>> I have no time to try myself right now, but a custom mapping for ivar result (as in a block) might be able to see the difference and act accordingly. >>>> >>>> >>>> okay. So I played around tracing this through the debugger and for anyone else >>>> with a similar need later, I ended up with the following... >>>> >>>> response := (ZnClient new >>>> url: 'https://bittrex.com/api/v1.1/public/getticker?market=INVALID'; >>>> enforceHttpSuccess: true; >>>> accept: ZnMimeType applicationJson; >>>> contentReader: >>>> [ :entity | >>>> [ |reader| >>>> reader := (NeoJSONReader on: entity readStream). >>>> reader for: BittrexResponse do: >>>> [:m| >>>> m mapInstVar: #success. >>>> m mapInstVar: #message. >>>> (m mapInstVar: #result) valueSchema: BittrexTicker >>>> ]. >>>> reader mapInstVarsFor: BittrexTicker. >>>> reader nextAs: BittrexResponse >>>> ] on: Error do: >>>> [ :err | |json| >>>> json := NeoJSONReader fromString: entity contents. >>>> (json at: 'success') >>>> ifFalse: [ self error: (json at: 'message') ] >>>> ifTrue: [ self error: 'UKNOWN ERROR' ] >>>> ] >>>> ]) get. >>>> >>>> >>>> for which I get a nice pre-debug window titled "Error: INVALID_MARKET" >>>> >>>> cheers -ben

Dec. 13, 2017

Re: [Pharo-users] REST client hints

by Stephane Ducasse

https://github.com/RMODINRIA-Blockchain Inria = 200 teams 4000 researchers :) On Sun, Dec 10, 2017 at 9:12 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 10 December 2017 at 15:27, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Tx for your report :) >> >> https://wordpress.com/post/pharoweekly.wordpress.com/2347 >> >> Did you look at SmartShackles? on our inria github repo. Because >> Santiago is extracting information from blockchains. >> > > I would hesitate to call where I'm up to right now as blockchain related. > Its just the trading api of one exchange where the items traded happen to be > bitcoins. > But I have a growing interest in blockchains, so thanks for the tip... > > I didn't see anything relevant here... https://github.com/INRIA > but with that product name I found... > https://github.com/sbragagnolo/SmartShackle > > cheers -ben

Dec. 13, 2017

Re: [Pharo-users] Zinc JSON parsing error handling

by Norbert Hartl

> Am 13.12.2017 um 10:18 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 13 Dec 2017, at 10:14, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> To make your core a little bit more reliable you should not catch the general error but a NeoJSONParseError. And you need to guard the dictionary access. There is no guarantee you get something back that inlcudes key success and message. > > Yes, indeed. > > Also, a better REST API (not something you can change) would not return 200 OK with an error in the payload, but would return a 404 Not Found with a proper error object as payload. > I must say that the latter is not a good advize. All HTTP status codes refer to the resource that is specified in the uri. REST is resource based but GET and POST are exceptions beacuse they can address processing entities. It means that the result of the operation is not the entity in the uri. Returning a 404 would mean that the https://bittrex.com/api/v1.1/public/getticker resource is not available but that is not true and can lead to unwanted behaviour, e.g. that a http stack caches the error and does not try to access that resource again. So the proper status code depends on the definition of the interface. If it is considered to always return an object then the status code needs to be 400 because the specification of the client was invalid. On the other hand you can just return a 200 with an empty result if the search result is optional. my 2 cents, Norbert > FWIW, there are a couple of more sophisticated examples, like in NeoJSONMappingTests and NeoJSONExamplesTests, with comments that do various special cases. > >> Norbert >> >> Am 13.12.2017 um 09:54 schrieb Ben Coman <btc(a)openinworld.com>: >> >>> hi Sven, >>> >>>> On 13 Dec 2017, at 07:59, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>> With... >>>> Object subclass: #BittrexResponse >>>> instanceVariableNames: 'success message result' >>>> classVariableNames: '' >>>> package: 'Bittrex' >>>> >>>> Object subclass: #BittrexMarketSummary >>>> instanceVariableNames: 'MarketName High Low Volume Last >>>> BaseVolume TimeStamp Bid Ask OpenBuyOrders >>>> OpenSellOrders PrevDay Created DisplayMarketName' >>>> classVariableNames: '' >>>> package: 'Bittrex' >>>> >>>> this code works great when the response holds good data... >>>> ZnClient new >>>> url: 'https://bittrex.com/api/v1.1/public/getmarketSummary?market=BTC-LTC'; >>>> enforceHttpSuccess: true; >>>> accept: ZnMimeType applicationJson; >>>> contentReader: [ :entity | |reader| >>>> reader := (NeoJSONReader on: entity readStream). >>>> reader for: BittrexResponse do: [:m| >>>> m mapInstVar: #success. >>>> m mapInstVar: #message. >>>> (m mapInstVar: #result) valueSchema: #ResultArray]. >>>> reader for: #ResultArray customDo: [ :mapping | >>>> mapping listOfElementSchema: BittrexMarketSummary ]. >>>> reader mapInstVarsFor: BittrexMarketSummary. >>>> reader nextAs: BittrexResponse ]; >>>> get. >>>> >>>> i.e. a raw response looking like this.... >>>> (ZnClient new >>>> url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=BTC-LTC'; >>>> get) inspect. >>>> ==> "'{""success"":true,""message"":"",""result"":[{""MarketName"":""BTC-LTC"",""High"":0.01982450,""Low"":0.01285257,""Volume"":1436429.81313360,""Last"":0.01842000,""BaseVolume"":24841.17217724,""TimeStamp"":""2017-12-13T05:56:25.937"",""Bid"":0.01840001,""Ask"":0.01842000,""OpenBuyOrders"":10140,""OpenSellOrders"":6306,""PrevDay"":0.01439800,""Created"":""2014-02-13T00:00:00""}]}'" >>>> >>>> >>>> But for bad response looking like this... >>>> (ZnClient new >>>> url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=INVALID'; >>>> get) inspect. >>>> ==> {"success":false,"message":"INVALID_MARKET","result":null} >>>> >>>> the JSON handling code fails deep in the call stack with an error >>>> "NeoJSONParseError: [ expected" >>>> which is not so friendly for users of the Bittrex library. >>>> >>>> What are the different/recommended approaches with Zinc >>>> for catching JSON errors such that I can pass "message" >>>> as a higher level Error up the stack to the Bittrex user. >>>> >>>> cheers -ben >>> >>> >>> On 13 December 2017 at 15:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> BTW, this is no about Zinc, but about NeoJSON. >>> >>> This is what I meant with variability that is hard to capture with a simple static type schema. >>> >>> I have no time to try myself right now, but a custom mapping for ivar result (as in a block) might be able to see the difference and act accordingly. >>> >>> >>> okay. So I played around tracing this through the debugger and for anyone else >>> with a similar need later, I ended up with the following... >>> >>> response := (ZnClient new >>> url: 'https://bittrex.com/api/v1.1/public/getticker?market=INVALID'; >>> enforceHttpSuccess: true; >>> accept: ZnMimeType applicationJson; >>> contentReader: >>> [ :entity | >>> [ |reader| >>> reader := (NeoJSONReader on: entity readStream). >>> reader for: BittrexResponse do: >>> [:m| >>> m mapInstVar: #success. >>> m mapInstVar: #message. >>> (m mapInstVar: #result) valueSchema: BittrexTicker >>> ]. >>> reader mapInstVarsFor: BittrexTicker. >>> reader nextAs: BittrexResponse >>> ] on: Error do: >>> [ :err | |json| >>> json := NeoJSONReader fromString: entity contents. >>> (json at: 'success') >>> ifFalse: [ self error: (json at: 'message') ] >>> ifTrue: [ self error: 'UKNOWN ERROR' ] >>> ] >>> ]) get. >>> >>> >>> for which I get a nice pre-debug window titled "Error: INVALID_MARKET" >>> >>> cheers -ben >>>

Dec. 13, 2017

Re: [Pharo-users] Zinc JSON parsing error handling

by Sven Van Caekenberghe

> On 13 Dec 2017, at 10:14, Norbert Hartl <norbert(a)hartl.name> wrote: > > To make your core a little bit more reliable you should not catch the general error but a NeoJSONParseError. And you need to guard the dictionary access. There is no guarantee you get something back that inlcudes key success and message. Yes, indeed. Also, a better REST API (not something you can change) would not return 200 OK with an error in the payload, but would return a 404 Not Found with a proper error object as payload. FWIW, there are a couple of more sophisticated examples, like in NeoJSONMappingTests and NeoJSONExamplesTests, with comments that do various special cases. > Norbert > > Am 13.12.2017 um 09:54 schrieb Ben Coman <btc(a)openinworld.com>: > >> hi Sven, >> >> > On 13 Dec 2017, at 07:59, Ben Coman <btc(a)openinworld.com> wrote: >> > >> > >> > With... >> > Object subclass: #BittrexResponse >> > instanceVariableNames: 'success message result' >> > classVariableNames: '' >> > package: 'Bittrex' >> > >> > Object subclass: #BittrexMarketSummary >> > instanceVariableNames: 'MarketName High Low Volume Last >> > BaseVolume TimeStamp Bid Ask OpenBuyOrders >> > OpenSellOrders PrevDay Created DisplayMarketName' >> > classVariableNames: '' >> > package: 'Bittrex' >> > >> > this code works great when the response holds good data... >> > ZnClient new >> > url: 'https://bittrex.com/api/v1.1/public/getmarketSummary?market=BTC-LTC'; >> > enforceHttpSuccess: true; >> > accept: ZnMimeType applicationJson; >> > contentReader: [ :entity | |reader| >> > reader := (NeoJSONReader on: entity readStream). >> > reader for: BittrexResponse do: [:m| >> > m mapInstVar: #success. >> > m mapInstVar: #message. >> > (m mapInstVar: #result) valueSchema: #ResultArray]. >> > reader for: #ResultArray customDo: [ :mapping | >> > mapping listOfElementSchema: BittrexMarketSummary ]. >> > reader mapInstVarsFor: BittrexMarketSummary. >> > reader nextAs: BittrexResponse ]; >> > get. >> > >> > i.e. a raw response looking like this.... >> > (ZnClient new >> > url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=BTC-LTC'; >> > get) inspect. >> > ==> "'{""success"":true,""message"":"",""result"":[{""MarketName"":""BTC-LTC"",""High"":0.01982450,""Low"":0.01285257,""Volume"":1436429.81313360,""Last"":0.01842000,""BaseVolume"":24841.17217724,""TimeStamp"":""2017-12-13T05:56:25.937"",""Bid"":0.01840001,""Ask"":0.01842000,""OpenBuyOrders"":10140,""OpenSellOrders"":6306,""PrevDay"":0.01439800,""Created"":""2014-02-13T00:00:00""}]}'" >> > >> > >> > But for bad response looking like this... >> > (ZnClient new >> > url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=INVALID'; >> > get) inspect. >> > ==> {"success":false,"message":"INVALID_MARKET","result":null} >> > >> > the JSON handling code fails deep in the call stack with an error >> > "NeoJSONParseError: [ expected" >> > which is not so friendly for users of the Bittrex library. >> > >> > What are the different/recommended approaches with Zinc >> > for catching JSON errors such that I can pass "message" >> > as a higher level Error up the stack to the Bittrex user. >> > >> > cheers -ben >> >> >> On 13 December 2017 at 15:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> BTW, this is no about Zinc, but about NeoJSON. >> >> This is what I meant with variability that is hard to capture with a simple static type schema. >> >> I have no time to try myself right now, but a custom mapping for ivar result (as in a block) might be able to see the difference and act accordingly. >> >> >> okay. So I played around tracing this through the debugger and for anyone else >> with a similar need later, I ended up with the following... >> >> response := (ZnClient new >> url: 'https://bittrex.com/api/v1.1/public/getticker?market=INVALID'; >> enforceHttpSuccess: true; >> accept: ZnMimeType applicationJson; >> contentReader: >> [ :entity | >> [ |reader| >> reader := (NeoJSONReader on: entity readStream). >> reader for: BittrexResponse do: >> [:m| >> m mapInstVar: #success. >> m mapInstVar: #message. >> (m mapInstVar: #result) valueSchema: BittrexTicker >> ]. >> reader mapInstVarsFor: BittrexTicker. >> reader nextAs: BittrexResponse >> ] on: Error do: >> [ :err | |json| >> json := NeoJSONReader fromString: entity contents. >> (json at: 'success') >> ifFalse: [ self error: (json at: 'message') ] >> ifTrue: [ self error: 'UKNOWN ERROR' ] >> ] >> ]) get. >> >> >> for which I get a nice pre-debug window titled "Error: INVALID_MARKET" >> >> cheers -ben >>

Dec. 13, 2017