September 2016 - Pharo-users

Re: [Pharo-users] Spec - Display an ICON without dropping to Morphic

by Johan Fabry

Hi Brad, all forms can be shown as part of a Spec UI. Thereâs the ImageModel for that. For example, supposing you have an âiconâ instance variable in your UI, add to initializeWidgets: icon := self newImage. icon image: (#thumbsUp asIcon). HTH -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 12, 2016, at 15:40, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > I want to create a MessagePrompter widget that will display either and error, > warning, or information message. I want to display a different icon > associated with each message type. Is there a way to do this in Spec without > having to drop down into Morphic? > > I do NOT want to have to learn Morphic. It's taking me enough time trying > work my way through Spec. > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-Display-an-ICON-without-dropping-to-Morphic-tp49… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by Esteban A. Maringolo

Who is the author of the to-be announced library? Regards! Esteban A. Maringolo 2016-09-12 15:17 GMT-03:00 stepharo <stepharo(a)free.fr>: > Hi esteban > > I know that there will be an announce about bitcoin library in Pharo so I > can put you in contact with the author. > > Stef > > > Le 12/9/16 Ã 14:42, Esteban A. Maringolo a Ã©crit : > >> 2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: >>> >>> Years ago when Squeaksource was "going away" I made a copy of its >>> Cryptography repo here: >>> http://smalltalkhub.com/#!/~Cryptography/Cryptography >> >> I saw it before posting to the list, but the latest commit is from >> three years go. >> >> I'm reading a book about Bitcoin/Blockchains and I want to follow the >> examples using my favorite language instead of Python. >> Probably not all the algorithms will be there, particularly ECC, but >> at least the ones for hashing should. >> >> Regards! >> >> >> Esteban A. Maringolo >> >> > >

Sept. 12, 2016

Spec - Display an ICON without dropping to Morphic

by Brad Selfridge

I want to create a MessagePrompter widget that will display either and error, warning, or information message. I want to display a different icon associated with each message type. Is there a way to do this in Spec without having to drop down into Morphic? I do NOT want to have to learn Morphic. It's taking me enough time trying work my way through Spec. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Spec-Display-an-ICON-without-dropping-to-Morphic-tp49… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by stepharo

Hi esteban I know that there will be an announce about bitcoin library in Pharo so I can put you in contact with the author. Stef Le 12/9/16 Ã 14:42, Esteban A. Maringolo a Ã©crit : > 2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: >> Years ago when Squeaksource was "going away" I made a copy of its >> Cryptography repo here: >> http://smalltalkhub.com/#!/~Cryptography/Cryptography > I saw it before posting to the list, but the latest commit is from > three years go. > > I'm reading a book about Bitcoin/Blockchains and I want to follow the > examples using my favorite language instead of Python. > Probably not all the algorithms will be there, particularly ECC, but > at least the ones for hashing should. > > Regards! > > > Esteban A. Maringolo > >

Sept. 12, 2016

Re: [Pharo-users] Iceberg and git workflow

by stepharo

Hi Holger I will let nicolas reply detail. Now Iceberg is not equals to git. For that you can already take gitfiletree (whatever is its name) and your command line tool and do what you want. What would be the reason to duplicate git in Pharo? Exposing all the complexity of git to pharo? Iceberg is an abstraction over a distribution source versioning system looking like git. And it offers a process and workflow to manage projects stored in git. Now iceberg should cover main and common scenario. And one complex scenario we have is how to manage changes that cross cut several projects (pharo / RB / GT...). Stef > Hi, > > I am a heavy git user with languages like C, C++, Python, Ruby and even GNU Smalltalk and I hope iceberg will bring the same powerful experience to Pharo. > > Last Friday I started to add a bigger refactoring for a new feature to my software and didn't finish. Sadly today an issue in the code was found and I would like to fix this before fixing my code. I use this as opportunity to ask if Iceberg has some answers for that. > > > With a non-Pharo project I would do: > > a.) If current HEAD is same as origin/master > > $ git stash (stash away my not finished changes) > $ vi code.c fix.. > $ git commit -a -c "subject > > long explanation of fix > reference to bug" > $ git stash apply (and go back to working on my feature) > > > b.) E.g. if I finished n-commits but I am not fully done > > # store my work > $ git commit -a -m "Work In Progress hack.." > $ git checkout -b new-feature-branch > > # go back to master > $ git checkout master > $ git reset --hard origin/master (to restore) > > # work on the fix > $ vi code.c fix.. > $ git commit -a -c "fix..." > > # go back and continue on my fix > $ git checkout new-feature-branch > $ git rebase origin/master > $ git reset HEAD^1 > .. continue to work > > > >

Sept. 12, 2016

Iceberg and git workflow

by Holger Freyther

Hi, I am a heavy git user with languages like C, C++, Python, Ruby and even GNU Smalltalk and I hope iceberg will bring the same powerful experience to Pharo. Last Friday I started to add a bigger refactoring for a new feature to my software and didn't finish. Sadly today an issue in the code was found and I would like to fix this before fixing my code. I use this as opportunity to ask if Iceberg has some answers for that. With a non-Pharo project I would do: a.) If current HEAD is same as origin/master $ git stash (stash away my not finished changes) $ vi code.c fix.. $ git commit -a -c "subject long explanation of fix reference to bug" $ git stash apply (and go back to working on my feature) b.) E.g. if I finished n-commits but I am not fully done # store my work $ git commit -a -m "Work In Progress hack.." $ git checkout -b new-feature-branch # go back to master $ git checkout master $ git reset --hard origin/master (to restore) # work on the fix $ vi code.c fix.. $ git commit -a -c "fix..." # go back and continue on my fix $ git checkout new-feature-branch $ git rebase origin/master $ git reset HEAD^1 .. continue to work

Sept. 12, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Ben Coman

On Mon, Sep 12, 2016 at 6:08 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On 07 Sep 2016, at 5:38 , Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Hi, > > sorry for arriving so late to this, but I was on holidays :) > this is how autoRelease works: > > 1) #autoRelease of an object registers object for finalisation with a > particular executor. Then behaviour is divided: > > 2.1.1) for ExternalAddresses, it just registers in regular way, who will > call #finalize on GC > 2.1.2) finalize will just call a free assuming ExternalAddress was > allocated > (which is a malloc) > > 2.2.1) for all FFIExternalReference, it will register for finalisation what > #resourceData answers (normally, the handle of the object) > 2.2.2) finalisation process will call the object > class>>#finalizeResourceData: method, with the #resourceData result as > parameter > 2.2.3) each kind of external reference can decide how to free that data (by > default is also just freeing). > > An example of this is how CairoFontFace works (or AthensCairoSurface). > > > > At the bottom of FFIExternalResourceExecutor class comment I read... > "Note that in #finalizeResourceData: you cannot > access any other properties of your instance, > since it is already garbage collected." > > But in my experiments it seems okay to access instance variables in > #finalize. > For example... > > CXString >> autoRelease > self class finalizationRegistry add: self > > CXString >> finalize > Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. > self dispose. > Transcript show: ', done!'. > > CXString >>private_flags > "This method was automatically generated" > ^handle unsignedLongAt: 5 > > Libclang getClangVersion autoRelease. > Smalltalk garbageCollect. > "==> Finalizing CXString 1, done! " > > > Is this an unlucky coincidence? Or maybe something changed from NB > to UFFI? (There is a reference to NB there) > > > yes, is a coincidence. > the idea of using #finalizeResourceData: is that you keep minimal > information (in general, just the handle)â¦ this way we ensure instances > will > be collected because we will not have circular references (preventing the > weakregistry to work). > > In general, you can always implement as you did it, but I would prefer the > #finalizeResourceData: approach, even for structures. > The only reason it is not implemented is because I didnât reach the > necessity, then I just skipped it (not in purpose, it was not in my head > :P), but now is a good moment to implement itâ¦ if you want it :) > > > Thanks for the offer, but hold off for the moment. I think I actually > need more than just finalization session management. To get a real > displayable string requires calling the clang_getCString() library > function. I imagine I'd like to call this from CXString>>printOn: -- > but this of course this would break after restarting the image. > > extern "C" { > const char *clang_getCString(CXString string) { > .... > return static_cast<const char *>(string.data); > }} > > typedef struct { > const void *data; > unsigned private_flags; > } CXString; > > So I think I need to register CXString with SessionManager to set *data > <-- 0 > on startup. > > An alternative might be adding a session variable to CXString, > FFIExternalStructure subclass: #CXString > instanceVariableNames: 'session' > classVariableNames: '' > poolDictionaries: 'CXStringFlag' > package: 'Libclang' > > except doing so crashes when calling.... > getClangVersion > ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang > > > So this worked... > > CXString >> resetData > handle unsignedLongAt: 1 put: 0. > > CXString class >> startUp: resuming > resuming > ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. > > CXString class >> initialize > "self initialize" > SessionManager default registerSystemClassNamed: self name > > > Now immediate after a save/restart, doing... > CXString allInstances first getString "==> UndefinedObject(nil)" > instead of crashing the VM. > > Can you see/guess any traps hidden from me? Now I wonder early it is > practical to prioritise such a reset. My first thought is at least > before #printString starts getting called ?? > > > For traps, there's the assumption in resetData that pointer stored in > handle is unsignedLong-sized. > Shouldn't there be auto-generated accessors for #data you can use instead > to change the value to Pointer void? > > Cheers, > Henry > Good point. This is the auto-generated accessor... data: anObject handle pointerAt: 1 put: anObject getHandle. However getHandle is only understood by ExternalObject and FFIExternalArray, and it seems a bit awkward to create a null on of those just to zero the handle. Actually your comment lead me to dicover ExternalAddress>>beNull, which looked promising. However the /handle/ of a FFIExternalStructure is a ByteArray rather than an ExternalAddress (which I guess makes sense). So... 1. maybe push beNull up to ByteArray, and maybe also isNull 2. #beNull implementation is 'self atAllPut: 0' which is understood by ByteArray. In my case I don't care if private_flags is also cleared, so maybe... CXString >> beNull handle atAllPut: 0. cheers -ben

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by phil＠highoctane.be

FYI there is a binding to NaCl in ApplicationSecurity. http://80738163270632.blogspot.be/2014/03/application-security-presentation… It is Pharo 3 (maybe is ok for other versions but I use it on Pharo 3). https://nacl.cr.yp.to/index.html Best, Phil On Mon, Sep 12, 2016 at 2:42 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > > > > Years ago when Squeaksource was "going away" I made a copy of its > > Cryptography repo here: > > http://smalltalkhub.com/#!/~Cryptography/Cryptography > > I saw it before posting to the list, but the latest commit is from > three years go. > > I'm reading a book about Bitcoin/Blockchains and I want to follow the > examples using my favorite language instead of Python. > Probably not all the algorithms will be there, particularly ECC, but > at least the ones for hashing should. > > Regards! > > > Esteban A. Maringolo > > >

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by Esteban A. Maringolo

2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > > Years ago when Squeaksource was "going away" I made a copy of its > Cryptography repo here: > http://smalltalkhub.com/#!/~Cryptography/Cryptography I saw it before posting to the list, but the latest commit is from three years go. I'm reading a book about Bitcoin/Blockchains and I want to follow the examples using my favorite language instead of Python. Probably not all the algorithms will be there, particularly ECC, but at least the ones for hashing should. Regards! Esteban A. Maringolo

Sept. 12, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Henrik Johansen

> On 07 Sep 2016, at 5:38 , Ben Coman <btc(a)openInWorld.com> wrote: > > On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> sorry for arriving so late to this, but I was on holidays :) >>> this is how autoRelease works: >>> >>> 1) #autoRelease of an object registers object for finalisation with a >>> particular executor. Then behaviour is divided: >>> >>> 2.1.1) for ExternalAddresses, it just registers in regular way, who will >>> call #finalize on GC >>> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated >>> (which is a malloc) >>> >>> 2.2.1) for all FFIExternalReference, it will register for finalisation what >>> #resourceData answers (normally, the handle of the object) >>> 2.2.2) finalisation process will call the object >>> class>>#finalizeResourceData: method, with the #resourceData result as >>> parameter >>> 2.2.3) each kind of external reference can decide how to free that data (by >>> default is also just freeing). >>> >>> An example of this is how CairoFontFace works (or AthensCairoSurface). >>> >>> >>> >>> At the bottom of FFIExternalResourceExecutor class comment I read... >>> "Note that in #finalizeResourceData: you cannot >>> access any other properties of your instance, >>> since it is already garbage collected." >>> >>> But in my experiments it seems okay to access instance variables in >>> #finalize. >>> For example... >>> >>> CXString >> autoRelease >>> self class finalizationRegistry add: self >>> >>> CXString >> finalize >>> Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. >>> self dispose. >>> Transcript show: ', done!'. >>> >>> CXString >>private_flags >>> "This method was automatically generated" >>> ^handle unsignedLongAt: 5 >>> >>> Libclang getClangVersion autoRelease. >>> Smalltalk garbageCollect. >>> "==> Finalizing CXString 1, done! " >>> >>> >>> Is this an unlucky coincidence? Or maybe something changed from NB >>> to UFFI? (There is a reference to NB there) >>> >>> >>> yes, is a coincidence. >>> the idea of using #finalizeResourceData: is that you keep minimal >>> information (in general, just the handle)â¦ this way we ensure instances will >>> be collected because we will not have circular references (preventing the >>> weakregistry to work). >>> >>> In general, you can always implement as you did it, but I would prefer the >>> #finalizeResourceData: approach, even for structures. >>> The only reason it is not implemented is because I didnât reach the >>> necessity, then I just skipped it (not in purpose, it was not in my head >>> :P), but now is a good moment to implement itâ¦ if you want it :) >> >> Thanks for the offer, but hold off for the moment. I think I actually >> need more than just finalization session management. To get a real >> displayable string requires calling the clang_getCString() library >> function. I imagine I'd like to call this from CXString>>printOn: -- >> but this of course this would break after restarting the image. >> >> extern "C" { >> const char *clang_getCString(CXString string) { >> .... >> return static_cast<const char *>(string.data); >> }} >> >> typedef struct { >> const void *data; >> unsigned private_flags; >> } CXString; >> >> So I think I need to register CXString with SessionManager to set *data <-- 0 >> on startup. >> >> An alternative might be adding a session variable to CXString, >> FFIExternalStructure subclass: #CXString >> instanceVariableNames: 'session' >> classVariableNames: '' >> poolDictionaries: 'CXStringFlag' >> package: 'Libclang' >> >> except doing so crashes when calling.... >> getClangVersion >> ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang > > So this worked... > > CXString >> resetData > handle unsignedLongAt: 1 put: 0. > > CXString class >> startUp: resuming > resuming > ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. > > CXString class >> initialize > "self initialize" > SessionManager default registerSystemClassNamed: self name > > > Now immediate after a save/restart, doing... > CXString allInstances first getString "==> UndefinedObject(nil)" > instead of crashing the VM. > > Can you see/guess any traps hidden from me? Now I wonder early it is > practical to prioritise such a reset. My first thought is at least > before #printString starts getting called ?? For traps, there's the assumption in resetData that pointer stored in handle is unsignedLong-sized. Shouldn't there be auto-generated accessors for #data you can use instead to change the value to Pointer void? Cheers, Henry

Sept. 12, 2016