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

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

by Alistair Grant

Hi Andrei, On Tue, Oct 17, 2017 at 01:58:22PM +0200, Andrei Chis wrote: > > > On Tue, Oct 17, 2017 at 1:04 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Tue, Oct 17, 2017 at 09:33:39AM +0000, Alistair Grant wrote: > > On Tue, Oct 17, 2017 at 06:28:05AM +0000, Alistair Grant wrote: > > > Hi All, > > > > > > I'm attempting to load Roassal2 in to Pharo7 and am getting: > > > > > > UndefinedObject(Object)>>doesNotUnderstand: #asTraitComposition > > > > > > > > > It can be reproduced in a clean Pharo7 image, e.g. > > > Pharo7.0-32bit-d1b0e3e.image (downloaded 16 Oct 2017), and executing: > > > > > > Gofer it > > > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > > > configurationOf: 'Roassal2'; > > > loadStable. > > > > > > > > > OS: Ubuntu 16.04. > > > > > > I last rebuilt my image on 3 October without any problems. > > > > > > Any suggestions? I suspect the combination of Monticello and Traits > > > will take me quite a while to figure out. > > > > This could simply be an ordering issue, i.e. maybe Monticello / > > Metacello needs to ensure that the traits are loaded before the classes. > > > > Presumably at some point during the load there is a list of classes that > > are going to be loaded. If someone can point me to the correct location > > it will save some time tracking it down. > > OK, it looks like Roassal has gone through quite a bit of development in > the last couple of months, and that TGTExampleIcon is simply missing > from the repository > (https://github.com/feenkcom/gtoolkit-examples/tree/master/src/ > GToolkit-Examples.package, > I hope) but is still referenced somewhere. > > Using ConfigurationOfRoassal2-AlexandreBergel.111 (the version I loaded > on 3 Oct) loads successfully, while > ConfigurationOfRoassal2-AlexandreBergel.114 fails as described above. > > > I added for now the trait back. Can you check that the loading works? > > But better would be to release a new stable version of roassal that links with > the new version of gtexamples, or update the current version of roassal to load > the gtexample version before the change. > > @Alexandre I can make a new stable version with the current version of roassal > + gt examples > > Cheers, > Andrei Yes, that loads successfully now, thanks! Cheers, Alistair

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 ...] Ah. I had the impression that will: only accepts the MockExpectedXxx instance... will try. Thanks. > 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. > > I usuallyintroduce kind of MyExternalClient intermediatewhich provides Well, yes, like dao I use to communicate with database. I see, but... there is always a but. If I am able to mock communication at lower level, I do not specify which object / library / client must be used to achieve that communication. I often find this a plus. > normal messages to interact with remote system. And it completely hides > overall http communication. > So in tests I stub this guy with simple mocks. > But in addition I write real communication tests specifically for that > object. They can be unstable because it is real network. But idea to > test actual communication in single place and abstract the rest of > system from it. Also it provide good checker for the possible API > changes and general problems with service. I tend to move this way when there is more communication with outside APIs (atm, I only have then one instance). And, as mentioned, I got used to mock things at http level from node, where nock library is great way to do these kinds of tests, so I got a slight bias to use 'mock at http level' approach. > Best regards, > Denis Thanks, Herby > 2017-10-17 12:34 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>>: > > 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 > > > For Denis Kudriashov: would you be willing to add something like > `willGenerateValueFrom: aBlock` to Mocketry, so previous two lines > could be replaced by simpler: > > ZnClient stub new willGenerateValueFrom: [ ZnMockClient > > ? > > If something allowing it is there, I am sorry but I haven't found it. > > Herby > > whenRequest: [ :request | > { request uri scheme. request uri authority. request uri > pathPrintString. request uri query associations asSet } > = { #https. 'onesignal.com <http://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: '{}') > ] ]). > > 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] Roassal2 in recent Pharo 7 causes DNU #asTraitComposition

by Andrei Chis

On Tue, Oct 17, 2017 at 1:04 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Tue, Oct 17, 2017 at 09:33:39AM +0000, Alistair Grant wrote: > > On Tue, Oct 17, 2017 at 06:28:05AM +0000, Alistair Grant wrote: > > > Hi All, > > > > > > I'm attempting to load Roassal2 in to Pharo7 and am getting: > > > > > > UndefinedObject(Object)>>doesNotUnderstand: #asTraitComposition > > > > > > > > > It can be reproduced in a clean Pharo7 image, e.g. > > > Pharo7.0-32bit-d1b0e3e.image (downloaded 16 Oct 2017), and executing: > > > > > > Gofer it > > > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > > > configurationOf: 'Roassal2'; > > > loadStable. > > > > > > > > > OS: Ubuntu 16.04. > > > > > > I last rebuilt my image on 3 October without any problems. > > > > > > Any suggestions? I suspect the combination of Monticello and Traits > > > will take me quite a while to figure out. > > > > This could simply be an ordering issue, i.e. maybe Monticello / > > Metacello needs to ensure that the traits are loaded before the classes. > > > > Presumably at some point during the load there is a list of classes that > > are going to be loaded. If someone can point me to the correct location > > it will save some time tracking it down. > > OK, it looks like Roassal has gone through quite a bit of development in > the last couple of months, and that TGTExampleIcon is simply missing > from the repository > (https://github.com/feenkcom/gtoolkit-examples/tree/master/ > src/GToolkit-Examples.package, > I hope) but is still referenced somewhere. > > Using ConfigurationOfRoassal2-AlexandreBergel.111 (the version I loaded > on 3 Oct) loads successfully, while > ConfigurationOfRoassal2-AlexandreBergel.114 fails as described above. > I added for now the trait back. Can you check that the loading works? But better would be to release a new stable version of roassal that links with the new version of gtexamples, or update the current version of roassal to load the gtexample version before the change. @Alexandre I can make a new stable version with the current version of roassal + gt examples Cheers, Andrei > > Cheers, > Alistair > > >

Oct. 17, 2017

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

by Alistair Grant

On Tue, Oct 17, 2017 at 09:33:39AM +0000, Alistair Grant wrote: > On Tue, Oct 17, 2017 at 06:28:05AM +0000, Alistair Grant wrote: > > Hi All, > > > > I'm attempting to load Roassal2 in to Pharo7 and am getting: > > > > UndefinedObject(Object)>>doesNotUnderstand: #asTraitComposition > > > > > > It can be reproduced in a clean Pharo7 image, e.g. > > Pharo7.0-32bit-d1b0e3e.image (downloaded 16 Oct 2017), and executing: > > > > Gofer it > > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > > configurationOf: 'Roassal2'; > > loadStable. > > > > > > OS: Ubuntu 16.04. > > > > I last rebuilt my image on 3 October without any problems. > > > > Any suggestions? I suspect the combination of Monticello and Traits > > will take me quite a while to figure out. > > This could simply be an ordering issue, i.e. maybe Monticello / > Metacello needs to ensure that the traits are loaded before the classes. > > Presumably at some point during the load there is a list of classes that > are going to be loaded. If someone can point me to the correct location > it will save some time tracking it down. OK, it looks like Roassal has gone through quite a bit of development in the last couple of months, and that TGTExampleIcon is simply missing from the repository (https://github.com/feenkcom/gtoolkit-examples/tree/master/src/GToolkit-Exam…, I hope) but is still referenced somewhere. Using ConfigurationOfRoassal2-AlexandreBergel.111 (the version I loaded on 3 Oct) loads successfully, while ConfigurationOfRoassal2-AlexandreBergel.114 fails as described above. Cheers, Alistair

Oct. 17, 2017

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

by Denis Kudriashov

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. I usually introduce kind of MyExternalClient intermediate which provides normal messages to interact with remote system. And it completely hides overall http communication. So in tests I stub this guy with simple mocks. But in addition I write real communication tests specifically for that object. They can be unstable because it is real network. But idea to test actual communication in single place and abstract the rest of system from it. Also it provide good checker for the possible API changes and general problems with service. Best regards, Denis 2017-10-17 12:34 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > 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 >> > > For Denis Kudriashov: would you be willing to add something like > `willGenerateValueFrom: aBlock` to Mocketry, so previous two lines could be > replaced by simpler: > > ZnClient stub new willGenerateValueFrom: [ ZnMockClient > > ? > > If something allowing it is there, I am sorry but I haven't found it. > > Herby > > 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: '{}') ] ]). >> >> 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

Mocketry willGenerateValueFrom: (was: Re: 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 For Denis Kudriashov: would you be willing to add something like `willGenerateValueFrom: aBlock` to Mocketry, so previous two lines could be replaced by simpler: ZnClient stub new willGenerateValueFrom: [ ZnMockClient ? If something allowing it is there, I am sorry but I haven't found it. Herby > 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: '{}') ] ]). > > 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

How do you mock http?

by Herby VojÄÃk

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: '{}') ] ]). 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] DesktopManaker from Ctrl-D to Ctrl-M help needed!!

by Ricardo Pacheco

Yes, you are right. Thanks a lot!!!! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 17, 2017

Re: [Pharo-users] DesktopManaker from Ctrl-D to Ctrl-M help needed!!

by Alistair Grant

On Tue, Oct 17, 2017 at 02:21:42AM -0700, Ricardo Pacheco wrote: > > PD to the DesktopManager team: Your tool is really cool, thanks a lot; > nevertheless is not nice to hide the Do-It command > I don't use the DesktopManager, but remember seeing a reply some time ago that Do-It has been remapped to Ctrl-D Ctrl-D. HTH, Alistair

Oct. 17, 2017

NeoJSONObject convenience method hint

by Herby VojÄÃk

newFromAccessors: aCollection ofObject: anObject "Performs supplied accessors on anObject and returns my instance with accessor -> result pairs." ^ self newFrom: (aCollection collect: [ :each | each -> (anObject perform: each) ]) "I use it for example in this piece of code: NeoJSONObject newFromAccessors: #(good bad) ofObject: self dao sumOfAllAnswers "

Oct. 17, 2017