October 2017 - Pharo-users - lists.pharo.org

Techtalk today: AI

by Marcus Denker

Hello! The tech talk starts in 20 minutes (17h europe time). Slides (pdf) can be downloaded here <https://github.com/AgileArtificialIntelligence/AgileArtificialIntelligence.…>. Invite for Discord (for Q&A after): http://discord.gg/Sj2rhxn <http://discord.gg/Sj2rhxn> The talk will be on Youtube, follow this link: https://www.youtube.com/c/AlexandreBergel/live <https://www.youtube.com/c/AlexandreBergel/live>

Oct. 17, 2017

SpecColumnLayout not behaving as expected

by Steven R. Baker

Heya folks, I'm sure I'm doing something wrong, I just don't know what it is. I have the following: defaultSpec Â Â Â ^ SpecColumnLayout composed Â Â Â Â Â Â newColumn: [ :col | Â Â Â Â Â Â Â Â Â col Â Â Â Â Â Â Â Â Â Â Â Â add: #sideBar; Â Â Â Â Â Â Â Â Â Â Â Â add: #listView ]; Â Â Â Â Â Â yourself In the resulting window, I get the widgets stacked one on top of the other, and I expected them to be next to each other (two columns in a row.) What am I missing? Thanks! -Steven

Oct. 17, 2017

[ANN] Pharo Consortium New Bronze Member: OSOCO

by Marcus Denker

The Pharo Consortium is very happy to announce that OSOCO has joined the Consortium as a Bronze Member. About - OSOCO: https://osoco.es - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Oct. 17, 2017

Re: [Pharo-users] Mocketry willGenerateValueFrom: (was: Re: How do you mock http?)

by Denis Kudriashov

2017-10-17 14:49 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > Denis Kudriashov wrote: > >> I would hide the tricks even more: >> >> ZnClient stubRequests: [ :request | >> request uri = >> ('https://onesignal.com/api/v1/players/{1}?app_id={2} >> <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' format: { >> self uidy: 'Q7'. appId }) asZnUrl >> and: [ #(GET HEAD) includes: request method ] ] >> byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. >> > > This would be nice, but it would need cooperation of Zinc (unless I hide > mocketry use under extension method). > Why not? I think it could be a good library. Try to publish it as is. Then people can contribute with their own cases. I remember other people looked for similar tool in past. So it could be good start. > > And maybe with set of more simple cases: >> >> ZnClient >> stubGET: ('https://onesignal.com/api/v1/players/{1}?app_id={2} >> <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' format: { >> self uidy: 'Q7'. appId }) asZnUrl >> byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. >> > > Well, I actually send HEAD in production code, as I only need to know if > it is 2xx or 4xx (of course using #isSuccess and not testing status code > myself) and I want be nice. But GET is good as well. Now what? :-) > > Or better: >> >> ZnClient >> stubGET: ('https://onesignal.com/api/v1/players' asZnUrl / (self >> uidy: 'Q7') >> withParams: {'app_id' -> appId } >> byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. >> > > Yes, we're getting where nock library is on node. I didn't want to make > full http mocking dsl (would be nice, though). You can be the man who starts the process :). Not necessary to implement full version. > Actually asked if there is one is the original thread. :-) > > Herby > > >> >> >> 2017-10-17 14:22 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>>: >> >> Denis Kudriashov wrote: >> >> Hi Herby. >> >> There is message #will: which accepts the block with possible >> arguments >> (if needed). >> >> ZnClient stub new will: [ ZnMockClient ...] >> >> But generally your approach looks bad to me. You put too many >> details on >> your tests which just duplicate Zinc API used in the domain code. >> It >> makes tests brittle and tightly coupled. And they looks quite >> unreadable. >> >> >> BTW, made it shorter and probably more readable as a result (by also >> shortening the test condition): >> >> ZnClient stub new will: [ ZnMockClient >> whenRequest: [ :request | >> request uri = >> ('https://onesignal.com/api/v1/players/{1}?app_id={2} >> <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' >> format: { self uidy: 'Q7'. appId }) asZnUrl >> and: [ #(GET HEAD) includes: request method ] ] >> thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') >> ] ]. >> >> The reason why I could not test uri as is, is Zinc adding ':443' to >> it. But as mentioned, the previous was very unreadable; with asZnUrl >> it is probably better. >> >> Herby >> >> >> >

Oct. 17, 2017

[ANN] feenk upgraded to Gold Membership

by Marcus Denker

The Pharo Consortium is very happy to announce that feenk has upgraded to Gold Member status. About - feenk: http://feenk.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Oct. 17, 2017

Re: [Pharo-users] Mocketry willGenerateValueFrom: (was: Re: How do you mock http?)

by Herby VojÄÃk

Denis Kudriashov wrote: > I would hide the tricks even more: > > ZnClient stubRequests: [ :request | > request uri = > ('https://onesignal.com/api/v1/players/{1}?app_id={2} > <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' format: { > self uidy: 'Q7'. appId }) asZnUrl > and: [ #(GET HEAD) includes: request method ] ] > byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. This would be nice, but it would need cooperation of Zinc (unless I hide mocketry use under extension method). > And maybe with set of more simple cases: > > ZnClient > stubGET: ('https://onesignal.com/api/v1/players/{1}?app_id={2} > <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' format: { > self uidy: 'Q7'. appId }) asZnUrl > byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. Well, I actually send HEAD in production code, as I only need to know if it is 2xx or 4xx (of course using #isSuccess and not testing status code myself) and I want be nice. But GET is good as well. Now what? :-) > Or better: > > ZnClient > stubGET: ('https://onesignal.com/api/v1/players' asZnUrl / (self > uidy: 'Q7') > withParams: {'app_id' -> appId } > byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. Yes, we're getting where nock library is on node. I didn't want to make full http mocking dsl (would be nice, though). Actually asked if there is one is the original thread. :-) Herby > > > > 2017-10-17 14:22 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>>: > > Denis Kudriashov wrote: > > Hi Herby. > > There is message #will: which accepts the block with possible > arguments > (if needed). > > ZnClient stub new will: [ ZnMockClient ...] > > But generally your approach looks bad to me. You put too many > details on > your tests which just duplicate Zinc API used in the domain code. It > makes tests brittle and tightly coupled. And they looks quite > unreadable. > > > BTW, made it shorter and probably more readable as a result (by also > shortening the test condition): > > ZnClient stub new will: [ ZnMockClient > whenRequest: [ :request | > request uri = > ('https://onesignal.com/api/v1/players/{1}?app_id={2} > <https://onesignal.com/api/v1/players/%7B1%7D?app_id=%7B2%7D>' > format: { self uidy: 'Q7'. appId }) asZnUrl > and: [ #(GET HEAD) includes: request method ] ] > thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') > ] ]. > > The reason why I could not test uri as is, is Zinc adding ':443' to > it. But as mentioned, the previous was very unreadable; with asZnUrl > it is probably better. > > Herby > >

Oct. 17, 2017

Re: [Pharo-users] Roassal2 in recent Pharo 7 causes DNU #asTraitComposition

by Alexandre Bergel

Hi! How can I update GT Example? I have produced a new version of the configuration ConfigurationOfRoassal2-AlexandreBergel.115 It loads the latest version of Roassal2GT. Does this solve the problem? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Oct 17, 2017, at 8:58 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > @Alexandre I can make a new stable version with the current version of roassal + gt examples > >

Oct. 17, 2017

Re: [Pharo-users] Mocketry willGenerateValueFrom: (was: Re: How do you mock http?)

by Denis Kudriashov

I would hide the tricks even more: ZnClient stubRequests: [ :request | request uri = ('https://onesignal.com/api/v1/players/{1}?app_id={2}' format: { self uidy: 'Q7'. appId }) asZnUrl and: [ #(GET HEAD) includes: request method ] ] byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. And maybe with set of more simple cases: ZnClient stubGET: ('https://onesignal.com/api/v1/players/{1}?app_id={2}' format: { self uidy: 'Q7'. appId }) asZnUrl byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. Or better: ZnClient stubGET: ('https://onesignal.com/api/v1/players' asZnUrl / (self uidy: 'Q7') withParams: {'app_id' -> appId } byResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. 2017-10-17 14:22 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > Denis Kudriashov wrote: > >> Hi Herby. >> >> There is message #will: which accepts the block with possible arguments >> (if needed). >> >> ZnClient stub new will: [ ZnMockClient ...] >> >> But generally your approach looks bad to me. You put too many details on >> your tests which just duplicate Zinc API used in the domain code. It >> makes tests brittle and tightly coupled. And they looks quite unreadable. >> > > BTW, made it shorter and probably more readable as a result (by also > shortening the test condition): > > ZnClient stub new will: [ ZnMockClient > whenRequest: [ :request | > request uri = ('https://onesignal.com/api/v1/players/{1}?app_id={2}' > format: { self uidy: 'Q7'. appId }) asZnUrl > and: [ #(GET HEAD) includes: request method ] ] > thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. > > The reason why I could not test uri as is, is Zinc adding ':443' to it. > But as mentioned, the previous was very unreadable; with asZnUrl it is > probably better. > > Herby >

Oct. 17, 2017

Re: [Pharo-users] How do you mock http?

by Herby VojÄÃk

Herby VojÄÃk wrote: > Hello! > > I felt the need to mock http api (like nock in node, that is, mock http > request-response itself on low-level part, leaving aside the question of > what wrapper / library one uses to get to that http; in node it mocks > basic http layer, here I tackled ZnClient), but struggled for a time how > to grasp it. Finally I used something like this (with help of Mocketry, > `1 to: 10` to mean "enough to actually be used even if there are more > unrelated uses", it could as well be `1 to: 100`): > > ZnClient stub new willReturnValueFrom: > ((1 to: 10) collect: [ :i | ZnMockClient > whenRequest: [ :request | > { request uri scheme. request uri authority. request uri > pathPrintString. request uri query associations asSet } > = { #https. 'onesignal.com'. '/api/v1/players/{1}' format: { UUID > fromString36: 'Q7' }. { 'app_id' -> appId } asSet } > and: [ #(GET HEAD) includes: request method ] ] > thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]). Actually, cleaned it up a bit, now I use shorter: ZnClient stub new will: [ ZnMockClient whenRequest: [ :request | request uri = ('https://onesignal.com/api/v1/players/{1}?app_id={2}' format: { UUID fromString36: 'Q7'. appId }) asZnUrl and: [ #(GET HEAD) includes: request method ] ] thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. > with the help of this class (garbled utf not my fault, iceberg metacello > integration does it): > > 'From Pharo6.0 of 13 May 2016 [Latest update: #60512] on 17 October 2017 > at 12:05:38.908634 pm'! > ZnClient subclass: #ZnMockClient > instanceVariableNames: 'conditionBlock responseBlock' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame-Tests'! > !ZnMockClient commentStamp: 'HerbyVojcik 10/16/2017 16:43' prior: 0! > I am a mock ZnClient. > > I am created with ZnMockClient whenRequest: whenBlock thenResponse: > thenBlock. > > Upon execution of the request, when (whenBlock cull: request) is true, > response is set to (thenBlock cull: request). Otherwise, behaviour is > delegated to super.! > > > !ZnMockClient methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 10/17/2017 > 12:00:27'! > conditionBlock > ^ conditionBlock! ! > > !ZnMockClient methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 10/17/2017 > 12:00:27'! > responseBlock: anObject > responseBlock := anObject! ! > > !ZnMockClient methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 10/17/2017 > 12:00:27'! > conditionBlock: anObject > conditionBlock := anObject! ! > > !ZnMockClient methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 10/17/2017 > 12:00:27'! > responseBlock > ^ responseBlock! ! > > > !ZnMockClient methodsFor: 'private protocol' stamp: 'HerbertVojÃÂÃÂk > 10/17/2017 12:00:27'! > executeRequestResponse > ^ (self conditionBlock cull: self request) > ifTrue: [ response := self responseBlock cull: self request. response > contents ] > ifFalse: [ super executeRequestResponse ]! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > ZnMockClient class > instanceVariableNames: ''! > > !ZnMockClient class methodsFor: 'instance creation' stamp: > 'HerbertVojÃÂÃÂk 10/17/2017 12:00:27'! > whenRequest: aBlock thenResponse: anotherBlock > ^ self new > conditionBlock: aBlock; > responseBlock: anotherBlock; > yourself! ! > > Question 1: Is there a better way? > > Question 2: If not, would ZnMockClient be good addition to Zinc itself, > to ease testing for others? > > Herby >

Oct. 17, 2017

Re: [Pharo-users] Mocketry willGenerateValueFrom: (was: Re: How do you mock http?)

by Herby VojÄÃk

Denis Kudriashov wrote: > Hi Herby. > > There is message #will: which accepts the block with possible arguments > (if needed). > > ZnClient stub new will: [ ZnMockClient ...] > > But generally your approach looks bad to me. You put too many details on > your tests which just duplicate Zinc API used in the domain code. It > makes tests brittle and tightly coupled. And they looks quite unreadable. BTW, made it shorter and probably more readable as a result (by also shortening the test condition): ZnClient stub new will: [ ZnMockClient whenRequest: [ :request | request uri = ('https://onesignal.com/api/v1/players/{1}?app_id={2}' format: { self uidy: 'Q7'. appId }) asZnUrl and: [ #(GET HEAD) includes: request method ] ] thenResponse: [ :request | ZnResponse ok: (ZnEntity json: '{}') ] ]. The reason why I could not test uri as is, is Zinc adding ':443' to it. But as mentioned, the previous was very unreadable; with asZnUrl it is probably better. Herby

Oct. 17, 2017