- Pharo-users - lists.pharo.org

Re: [Pharo-users] SpecColumnLayout not behaving as expected

by Steven R. Baker

Oh! I remember fighting with this last week too. Am I the only who who struggled with that? If not, perhaps we could call #add: #addRow: ? -Steven On 17/10/17 18:00, Peter UhnÃ¡k wrote: > Because it is the other way around: in the block ([ :col | ... ]) you > are describing the content of the column. > > So what you are actually doing is you create a Column > (SpecColumnLayout), inside which you create another column > (newColumn), and to that column you add two rows (add:, add:). > > On Tue, Oct 17, 2017 at 4:32 PM, Steven R. Baker > <steven(a)stevenrbaker.com <mailto:steven@stevenrbaker.com>> wrote: > > 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

Re: [Pharo-users] SpecColumnLayout not behaving as expected

by Peter UhnÃ¡k

Because it is the other way around: in the block ([ :col | ... ]) you are describing the content of the column. So what you are actually doing is you create a Column (SpecColumnLayout), inside which you create another column (newColumn), and to that column you add two rows (add:, add:). On Tue, Oct 17, 2017 at 4:32 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > 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

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