September 2019 - Pharo-users

Re: [Pharo-users] Set >> collect:thenDo:

by Peter Kenny

Two comments: First, the method comment for Collection>>collect:thenDo: is "Utility method to improve readability", which is exactly the same as for collect:thenSelect: and collect:thenReject:. This suggests that the *intention* of the method is not to introduce new behaviour, but simply to provide a shorthand for the version with parentheses. For other kinds of collection this is true; just the deduping makes Set different. If we want the different behaviour, this should be indicated by method name and comment. Second, if we remove asSet from the second snippet, the output is exactly the same. It will be the same as long as the original collection has no duplicates. Somehow the effect is to ignore the asSet. It just smells wrong. Peter Kenny Kasper Osterbye wrote > The first version: > > (#(1 2 3) asSet collect: #odd) > do: [ :each | Transcript show: each; cr ] > > is rather straight forward I believe, as collect: and do: has been around > forever (relatively speaking). > > > #(1 2 3) asSet collect: #odd > thenDo: [ :each | Transcript show: each; cr ] > > > On 8 September 2019 at 09.13.36, Richard Sargent ( > richard.sargent@ > ) wrote: > > I am skeptical of one that relies on a specific implementation rather > than > a specific definition. > > I share your feeling. I am not sure where such a definition would come > from. In Squeak it is defined as: > > collect: collectBlock thenDo: doBlock > > ^ (self collect: collectBlock) do: doBlock > > In pharo as: > > collect: collectBlock thenDo: doBlock > > ^ self do: [ :each | doBlock value: (collectBlock value: each)] > > I might have called the method collect:eachDo:, but we each have slightly > different styles. What I like about the pharo version is that is a > shorthand for something which is not achieved by mere parentheses. > > Best, > > Kasper -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Kasper Ãsterbye

The first version: (#(1 2 3) asSet collect: #odd) do: [ :each | Transcript show: each; cr ] is rather straight forward I believe, as collect: and do: has been around forever (relatively speaking). #(1 2 3) asSet collect: #odd thenDo: [ :each | Transcript show: each; cr ] On 8 September 2019 at 09.13.36, Richard Sargent ( richard.sargent(a)gemtalksystems.com) wrote: I am skeptical of one that relies on a specific implementation rather than a specific definition. I share your feeling. I am not sure where such a definition would come from. In Squeak it is defined as: collect: collectBlock thenDo: doBlock ^ (self collect: collectBlock) do: doBlock In pharo as: collect: collectBlock thenDo: doBlock ^ self do: [ :each | doBlock value: (collectBlock value: each)] I might have called the method collect:eachDo:, but we each have slightly different styles. What I like about the pharo version is that is a shorthand for something which is not achieved by mere parentheses. Best, Kasper

Sept. 8, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Richard Sargent

I don't know the correct answer, but I am skeptical of one that relies on a specific implementation rather than a specific definition. I would like to see and understand the arguments for one interpretation versus another. Prima facie, the expectation that set behaviour propagates through the implementation is appealing. The correct answer is anything but clear cut On Sat, Sep 7, 2019, 23:03 Kasper Ãsterbye <kasper.osterbye(a)gmail.com> wrote: > Feature! > > collect: forms a new collection of the same kind as its receiver. In this > case a set. As the result of your collect: > #(1 2 3) asSet collect: #odd) > is booleans, the resulting set will contain only to elements (the > duplicate odd resulting in true is removed). > > collect: thenDo: applies the collect-block to each element of the > receiver, and then applies the do to each of those results. You can see the > implementation of collect:thenDo: in class Collection. > > Best, > > Kasper > > > On 7 September 2019 at 17.22.03, Herby VojÄÃk (herby(a)mailbox.sk) wrote: > > Hello! > > ---- > (#(1 2 3) asSet collect: #odd) > do: [ :each | Transcript show: each; cr ] > > > true > > false > > ---- > > #(1 2 3) asSet collect: #odd > thenDo: [ :each | Transcript show: each; cr ] > > > true > > false > > true > ---- > > > Bug or feature? > > Herby > >

Sept. 8, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Steffen MÃ¤rcker

Surprise! The selector #collect:thenDo: strongly suggests that it behaves just as #collect: then #do:. But as #collect: usually means map + aggregate in the reveiver type, I'd expect the input to the do block to be deduped already. At least it is an easy to miss source of subtle bugs. Maybe an additional method #map:thenDo: would make sense? Best, Steffen Am 8. September 2019 08:02:30 MESZ schrieb "Kasper Ãsterbye" <kasper.osterbye(a)gmail.com>: >Feature! > >collect: forms a new collection of the same kind as its receiver. In >this >case a set. As the result of your collect: >#(1 2 3) asSet collect: #odd) >is booleans, the resulting set will contain only to elements (the >duplicate >odd resulting in true is removed). > >collect: thenDo: applies the collect-block to each element of the >receiver, >and then applies the do to each of those results. You can see the >implementation of collect:thenDo: in class Collection. > >Best, > >Kasper > > >On 7 September 2019 at 17.22.03, Herby VojÄÃk (herby(a)mailbox.sk) wrote: > >Hello! > >---- >(#(1 2 3) asSet collect: #odd) >do: [ :each | Transcript show: each; cr ] > >> true >> false > >---- > >#(1 2 3) asSet collect: #odd >thenDo: [ :each | Transcript show: each; cr ] > >> true >> false >> true >---- > > >Bug or feature? > >Herby

Sept. 8, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Kasper Ãsterbye

Feature! collect: forms a new collection of the same kind as its receiver. In this case a set. As the result of your collect: #(1 2 3) asSet collect: #odd) is booleans, the resulting set will contain only to elements (the duplicate odd resulting in true is removed). collect: thenDo: applies the collect-block to each element of the receiver, and then applies the do to each of those results. You can see the implementation of collect:thenDo: in class Collection. Best, Kasper On 7 September 2019 at 17.22.03, Herby VojÄÃk (herby(a)mailbox.sk) wrote: Hello! ---- (#(1 2 3) asSet collect: #odd) do: [ :each | Transcript show: each; cr ] > true > false ---- #(1 2 3) asSet collect: #odd thenDo: [ :each | Transcript show: each; cr ] > true > false > true ---- Bug or feature? Herby

Sept. 8, 2019

Set >> collect:thenDo:

by Herby VojÄÃk

Hello! ---- (#(1 2 3) asSet collect: #odd) do: [ :each | Transcript show: each; cr ] > true > false ---- #(1 2 3) asSet collect: #odd thenDo: [ :each | Transcript show: each; cr ] > true > false > true ---- Bug or feature? Herby

Sept. 7, 2019

uFFI Structure Problem

by Georg Hagn

I have to implemet following external structure (extrakt from the german api Doku): typedef struct { /**@brief MUST be always 2. */ uint32_t version; /** @brief Pointer to KeyStore -- Verweis auf den KeyStore, see EricGetHandleToCertificate(). */ EricZertifikatHandle zertifikatHandle; /** @brief PIN fÃ¼r den KeyStore.*/ const char *pin; /** * @brief MUST be NULL in my context Dieser muss ... In allen anderen FÃ¤llen muss hier NULL Ã¼bergeben werden. Der Parameter abrufCode besteht aus 2 x 5 Zeichen, die mit "-" verbunden sind. Beispiel: "K6FG5-RS32P" */ const char *abrufCode; } eric_verschluesselungs_parameter_t; My Problem is, that i have to assign a NULL - value to the attribute abrufCode. I have tried varies possibilities but I get always the error, that the attribute abrufCode must have the value NULL. " Extract from log-file: 019-09-05 17:08:52,257709[0x00007fe036a2f050] ERROR: FÃ¼r die Ã¼bermittelte Datenart ist die Angabe eines Abrufcodes nicht zulÃ¤ssig, daher muss fÃ¼r den Abrufcode der Wert NULL Ã¼bergeben werden. 610001029" How do I assign a NULL value to an attribute in a FFIExternalStructure? Following my last attempt (extracted from the Pharo Booklet Colletion "Calling Foreign Functions with Pharo May 31,2018") I assign values not directly with the generated attributes but with "api???" attributes. FFIExternalStructure subclass: #ERiCVerschluesselungsParameter instanceVariableNames: '' classVariableNames: 'OFFSET_ABRUFCODE OFFSET_PIN OFFSET_VERSION OFFSET_ZERTIFIKATHANDLE' package: 'Bajoras-ERiC'! ERiCVerschluesselungsParameter class >> fieldsDesc [ "ERiCVerschluesselungsParameter rebuildFieldAccessors" ^ #( uint32 version; ERiCZertifikatHandle * zertifikatHandle; char * pin; char * abrufCode; ) ] ERiCVerschluesselungsParameter >> initialize [ self apiVersion: 2; apiAbrufCode: nil; apiPin: 'mySecret'. ] ERiCVerschluesselungsParameter >> accessorMethods for: pin, version, abrufCode, zertifikatHandle ("This method were automatically generated") ERiCVerschluesselungsParameter >> apiAbrufCode: aCode [ | codeSize anAbrufCode | codeSize := 11. anAbrufCode := FFIExternalArray externalNewType: 'char' size: codeSize. 1 to: codeSize do: [ :idx | anAbrufCode at: idx put: Character null ] . aCode ifNotNil: [ aCode doWithIndex: [ :char :i | anAbrufCode at: i put: char ]. ]. self abrufCode: anAbrufCode. ] ERiCVerschluesselungsParameter >> apiPin: aPin [ | newPin | newPin := FFIExternalArray externalNewType: 'char' size: aPin size. aPin doWithIndex: [ :char :i | newPin at: i put: char ]. self pin: newPin. ] ERiCVerschluesselungsParameter >> apiVersion: aVersion [ | cryptoVersion | cryptoVersion := 2. self version: cryptoVersion. ] Thanks, Georg Hagn

Sept. 5, 2019

Re: [Pharo-users] uFFI Structure Problem

by Esteban Lorenzano

> On 5 Sep 2019, at 17:41, Georg Hagn <georg.hagn(a)gmail.com> wrote: > > I have to implemet following external structure (extrakt from the > german api Doku): > > typedef struct { > /**@brief MUST be always 2. */ > uint32_t version; > > /** @brief Pointer to KeyStore -- Verweis auf den KeyStore, see > EricGetHandleToCertificate(). */ > EricZertifikatHandle zertifikatHandle; > > /** @brief PIN fÃ¼r den KeyStore.*/ > const char *pin; > > /** > * @brief MUST be NULL in my context > Dieser muss ... > In allen anderen FÃ¤llen muss hier NULL Ã¼bergeben > werden. Der Parameter abrufCode > besteht aus 2 x 5 Zeichen, die mit "-" verbunden sind. > Beispiel: "K6FG5-RS32P" > */ > const char *abrufCode; > > } eric_verschluesselungs_parameter_t; > > My Problem is, that i have to assign a NULL - value to the attribute abrufCode. > I have tried varies possibilities but I get always the error, that the > attribute abrufCode must have the value NULL. > > " Extract from log-file: > 019-09-05 17:08:52,257709[0x00007fe036a2f050] ERROR: FÃ¼r die > Ã¼bermittelte Datenart ist die Angabe eines Abrufcodes nicht zulÃ¤ssig, > daher muss fÃ¼r den Abrufcode der Wert NULL Ã¼bergeben werden. > 610001029" > > How do I assign a NULL value to an attribute in a FFIExternalStructure? The problem is not that is an structure but that is a char *, which is converted to a String in Pharo. Ideally, a nil should be mapped to NULL in this cases, but this is not working (never implemented). Easiest workaround, just map abrufCode to void * instead char * (pointers are always same size). So you can have: myStryct abrufCode: ExternalAddress null. But of course, that will change the way you put the value there when *it is not* a NULL: myStryct abrufCode: âhelloâ utf8Encoded copyWith 0. (The copyWith: 0 is to ensure the void * will receive something with proper \0 finalisation) Esteban > > Following my last attempt (extracted from the Pharo Booklet Colletion > "Calling Foreign Functions with Pharo May 31,2018") > I assign values not directly with the generated attributes but with > "api???" attributes. > > FFIExternalStructure subclass: #ERiCVerschluesselungsParameter > instanceVariableNames: '' > classVariableNames: 'OFFSET_ABRUFCODE OFFSET_PIN OFFSET_VERSION > OFFSET_ZERTIFIKATHANDLE' > package: 'Bajoras-ERiC'! > > > ERiCVerschluesselungsParameter class >> fieldsDesc [ > > "ERiCVerschluesselungsParameter rebuildFieldAccessors" > > ^ #( > uint32 version; > ERiCZertifikatHandle * zertifikatHandle; > char * pin; > char * abrufCode; > ) > ] > > ERiCVerschluesselungsParameter >> initialize [ > > self > apiVersion: 2; > apiAbrufCode: nil; > apiPin: 'mySecret'. > ] > > ERiCVerschluesselungsParameter >> accessorMethods for: pin, version, > abrufCode, zertifikatHandle ("This method were automatically > generated") > > ERiCVerschluesselungsParameter >> apiAbrufCode: aCode [ > > | codeSize anAbrufCode | > > codeSize := 11. > anAbrufCode := FFIExternalArray externalNewType: 'char' size: codeSize. > 1 to: codeSize do: [ :idx | anAbrufCode at: idx put: Character null ] . > > aCode ifNotNil: [ > aCode doWithIndex: [ :char :i | anAbrufCode at: i put: char ]. > ]. > > self abrufCode: anAbrufCode. > > ] > > ERiCVerschluesselungsParameter >> apiPin: aPin [ > > | newPin | > > newPin := FFIExternalArray externalNewType: 'char' size: aPin size. > aPin doWithIndex: [ :char :i | newPin at: i put: char ]. > > self pin: newPin. > ] > > > ERiCVerschluesselungsParameter >> apiVersion: aVersion [ > > | cryptoVersion | > > cryptoVersion := 2. > self version: cryptoVersion. > > ] > > Thanks, > Georg Hagn >

Sept. 5, 2019

Re: [Pharo-users] Pharo Branding Organization on GitHub

by Torsten Bergmann

stepharo wrote: > thanks for the initiative. > I think that we have more material around, like alternate logo. > It would be nice to collect also the svg versions? > > I know that lusy did also design for mugs The SVG versions for the logo and flat-logo are in already. If you have more then just send it around or put it in directly. I added you to the organization. Unfortunately I do not know who lusy is ... maybe you could contact here so we can also collect here media stuff for the repos. Thanks T.

Sept. 5, 2019

Re: [Pharo-users] Concurrency Best Practices + Tests

by Ben Coman

On Wed, 4 Sep 2019 at 21:32, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi everyone, > > Can I get your input on the following questions : > > - What are your best practices and recommendations for developing and > testing concurrent software? > I haven't any formalized advice, but just a scattering of thoughts: - When the debugger opens, it really disturbs the timing context between threads, so the problem you are looking for disappears. - Tracking down timing-related problems often required interleaved-threads logging to a threadsafe queue so a historical sequence could be reviewed. Sometimes this included exporting it to Excel then manually chopping repeating sectioning into side-by-side columns to see how the order of execution differs between cycles. - Correctly distinguish between your "shared resource" problems and your "work signalling" producer/consumer problems, respectively using mutexes and semaphores. I think the latter is easier to reason about. btw, watch out for Announcements. You will appear to register them for the receiving-thread, but actually they are executed in the context of the sending-thread. - How to discover need for synchronization/critical sections/ when doing > TDD? > First consider whether synchronisation can be avoided using queues with "positive hand-off" http://www.flounder.com/no_synchronization.htm This video I bumped into today touches on the same thing... https://www.youtube.com/watch?v=2yXtZ8x7TXw Not available right now, but along the line "apartment-threading" I have been musing about VM support for "Process-specific-immutability" So an object has an "owner-process" which is the only thread able to mutate it. The existing immutability flag would be turned on, and when triggered the VM would check if the thread-id matched before allowing/blocking an update. For example, in a producer/consumer arrangement there could be a specific system thread dedicated to processing class/code-modifications which could keep that safe without scattering mutexes through that code, but anyone can read it. One thing that wasn't obvious to me until I read it, was that lazy-initialization which is common in TDD is problematic with concurrency. I'm still mulling over the implications, but it seems reasonable that you can get at least double-initialization. So its better to initialize at creation time before it is handed around to other threads. - How to write code to avoid dead-locks? > Here are some bookmarked articles I found enlightening on the differences between between mutexes and semaphores. The last two identify typical problems. 1. https://barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore 2. http://blog.feabhas.com/2009/09/mutex-vs-semaphores-%e2%80%93-part-1-semaph… 3. http://blog.feabhas.com/2009/09/mutex-vs-semaphores-%e2%80%93-part-2-the-mu… 4. http://blog.feabhas.com/2009/10/mutex-vs-semaphores-%e2%80%93-part-3-final-… 5. http://www.smxrtos.com/articles/techppr/mutex.htm You may find some useful patterns in these books... - http://greenteapress.com/semaphores/LittleBookOfSemaphores.pdf - https://pdfs.semanticscholar.org/a51b/40c904add79f590ed887ccd3a78dbe630938.… cheers -ben

Sept. 5, 2019