- Pharo-users - lists.pharo.org

Showcasing Pharo, Roassal and Grafoscopio at re:publica 2018

by Offray Vladimir Luna CÃ¡rdenas

Hi, I will be showcasing Pharo, Roassal and Grafoscopio at re:publica 2018, next week. As you may know, re:publica[2] is one of the most important and visible media & digital culture conventions in Europe and is a good scenario for the Pharo community.Â You can find details about my participation at [1] [1] https://18.re-publica.com/en/session/data-clinic-twitter-data-selfies-data-… [2] https://18.re-publica.com/en I will be making intensive refactoring on the Dataviz package to create some usual and unusual data visualizations from data exported from Twitter, so I may be more active those days in the Discord and mailing list channels, is some questions arise. Thanks in advance for the Pharo communities support. I wouldn't be able to be there without it. Cheers, Offray

April 26, 2018

Re: [Pharo-users] UFFI and autoRelease

by Esteban Lorenzano

> On 26 Apr 2018, at 12:09, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > > On Wed, Apr 25, 2018 at 11:07 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > > On 25 April 2018 at 23:08, Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: > I don't understand the default > > finalizeResourceData: handle > handle isNull ifTrue: [ ^ self ]. > handle free. > handle beNull > > > when handle is an ExternaData, free is defined as in ExternalStructure class as: > > free > "Free the handle pointed to by the receiver" > (handle ~~ nil and:[handle isExternalAddress]) ifTrue:[handle free]. > handle := nil. > > Theorectical side thought. I wonder how threadsafe that code for #free is? > Sending two messages between the ~~nil test and nil-assignment > seems to leave the door open for another thread to erroneously pass the ~~nil test. > > IIUC, with an inlined #ifNotNil, the following might be safer (?) > > free > "Save handle so its nil assignment is inlined with its #ifNotNil: test, eliminating possible thread change during message sends" > |savedhandle| > handle ifNotNil: [ > savedHandle := handle. > handle := nil. > savedHandle isExternalAddress ifTrue: [ savedHandle free]. > ]. > > > > âYou don't reply to my original question, Ben :-) > > > I have another concern with UFFI ! > > When I call ffiCall: and the call returns an Opaque Object, an instance of this Opaque object is created, but apparently, > basicNew is called instead of new on the class. What is the â âintention behind ?â basicNew ensures the object is created âvirginâ, since its contents will depend on what comes from outside and not in Pharo. you can then call initialize by yourself if needed, as it happens for example in AthensCairoSurface>>extent:format: Esteban > > âThank you.â > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for machines to execute." > http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

April 26, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Tim Mackinnon

Yep - its that one. Needs fixing as it had me scratching my head in the wrong place â¦ its a bit out of my league. But we are hoping to see if we can fix a few bugs at the next UK Smalltalk meeting. Tim > On 26 Apr 2018, at 08:28, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > Hi, > > It looks you got bit by this issue: > > https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well… <https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well…> > > It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo. > > On Thu, Apr 26, 2018 at 8:44 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > That should be âre-saved â it, the issue went away. > > > Sent from my iPhone > > On 25 Apr 2018, at 23:43, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > >> Hi - I think I had this issue a long while back, but I just hit it again (desperately trying to get back into Pharo again)â¦ >> >> I was trying out Willow - and had a method like this: >> >> initializeContainerView >> >> | behaviorDetails scopeSelection | >> >> behaviorDetails := IdentifiedWebView >> forDivNamed: 'behavior-details' >> containing: WPPagerDutyUserDetailsView new >> applying: [ :div :constants | >> â¦. >> >> Where I had a class reference to: WPPagerDutyUserDetailsView, I deleted that class thinking I didnât need it and then spotted the above method referenced it and so I brought it back via Epicea. >> >> However when I ran my Willow Application, my web page was showing an error message âError, ObsoleteClassWPPagerDutyUserDetailsView does not implementâ¦.â - essentially it seemed like this method was referencing the class I had deleted and not the one I had restored. >> >> When I went back to this method and simply reserved it, everything worked properly. >> >> I recall Marcus (at the time) mentioning that the Opal compiler was supposed to detect these kinds of changes and rebind things properly - but it seems that this isnât the case - or potentially restoring something from Epicea subverts this? >> >> I can raise a bug if its genuine - but Iâm just musing on this at the moment? >> >> >> Tim > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

April 26, 2018

Re: [Pharo-users] UFFI and autoRelease

by Serge Stinckwich

On Wed, Apr 25, 2018 at 11:07 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 25 April 2018 at 23:08, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > >> I don't understand the default >> >> finalizeResourceData: handle >> handle isNull ifTrue: [ ^ self ]. >> handle free. >> handle beNull >> >> >> when handle is an ExternaData, free is defined as in ExternalStructure >> class as: >> >> free >> "Free the handle pointed to by the receiver" >> (handle ~~ nil and:[handle isExternalAddress]) ifTrue:[handle free]. >> handle := nil. >> > > Theorectical side thought. I wonder how threadsafe that code for #free > is? > Sending two messages between the ~~nil test and nil-assignment > seems to leave the door open for another thread to erroneously pass the > ~~nil test. > > IIUC, with an inlined #ifNotNil, the following might be safer (?) > > free > "Save handle so its nil assignment is inlined with its #ifNotNil: > test, eliminating possible thread change during message sends" > |savedhandle| > handle ifNotNil: [ > savedHandle := handle. > handle := nil. > savedHandle isExternalAddress ifTrue: [ savedHandle free]. > ]. > > âYou don't reply to my original question, Ben :-) I have another concern with UFFI ! When I call ffiCall: and the call returns an Opaque Object, an instance of this Opaque object is created, but apparently, basicNew is called instead of new on the class. What is the â âintention behind ?â âThank you.â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

April 26, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Guillermo Polito

Hi, It looks you got bit by this issue: https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well… It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo. On Thu, Apr 26, 2018 at 8:44 AM, Tim Mackinnon <tim(a)testit.works> wrote: > That should be âre-saved â it, the issue went away. > > > Sent from my iPhone > > On 25 Apr 2018, at 23:43, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - I think I had this issue a long while back, but I just hit it again > (desperately trying to get back into Pharo again)â¦ > > I was trying out Willow - and had a method like this: > > initializeContainerView > > | behaviorDetails scopeSelection | > > behaviorDetails := IdentifiedWebView > forDivNamed: 'behavior-details' > containing: *WPPagerDutyUserDetailsView* new > applying: [ :div :constants | > â¦. > > Where I had a class reference to: *WPPagerDutyUserDetailsView, *I deleted > that class thinking I didnât need it and then spotted the above method > referenced it and so I brought it back via Epicea. > > However when I ran my Willow Application, my web page was showing an error > message âError, ObsoleteClassWPPagerDutyUserDetailsView does not > implementâ¦.â - essentially it seemed like this method was referencing the > class I had deleted and not the one I had restored. > > When I went back to this method and simply reserved it, everything worked > properly. > > I recall Marcus (at the time) mentioning that the Opal compiler was > supposed to detect these kinds of changes and rebind things properly - but > it seems that this isnât the case - or potentially restoring something from > Epicea subverts this? > > I can raise a bug if its genuine - but Iâm just musing on this at the > moment? > > > Tim > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 26, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Tim Mackinnon

That should be âre-saved â it, the issue went away. Sent from my iPhone > On 25 Apr 2018, at 23:43, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - I think I had this issue a long while back, but I just hit it again (desperately trying to get back into Pharo again)â¦ > > I was trying out Willow - and had a method like this: > > initializeContainerView > > | behaviorDetails scopeSelection | > > behaviorDetails := IdentifiedWebView > forDivNamed: 'behavior-details' > containing: WPPagerDutyUserDetailsView new > applying: [ :div :constants | > â¦. > > Where I had a class reference to: WPPagerDutyUserDetailsView, I deleted that class thinking I didnât need it and then spotted the above method referenced it and so I brought it back via Epicea. > > However when I ran my Willow Application, my web page was showing an error message âError, ObsoleteClassWPPagerDutyUserDetailsView does not implementâ¦.â - essentially it seemed like this method was referencing the class I had deleted and not the one I had restored. > > When I went back to this method and simply reserved it, everything worked properly. > > I recall Marcus (at the time) mentioning that the Opal compiler was supposed to detect these kinds of changes and rebind things properly - but it seems that this isnât the case - or potentially restoring something from Epicea subverts this? > > I can raise a bug if its genuine - but Iâm just musing on this at the moment? > > > Tim

April 26, 2018

Restoring a class via Epicea didn't recompile a reference?

by Tim Mackinnon

Hi - I think I had this issue a long while back, but I just hit it again (desperately trying to get back into Pharo again)â¦ I was trying out Willow - and had a method like this: initializeContainerView | behaviorDetails scopeSelection | behaviorDetails := IdentifiedWebView forDivNamed: 'behavior-details' containing: WPPagerDutyUserDetailsView new applying: [ :div :constants | â¦. Where I had a class reference to: WPPagerDutyUserDetailsView, I deleted that class thinking I didnât need it and then spotted the above method referenced it and so I brought it back via Epicea. However when I ran my Willow Application, my web page was showing an error message âError, ObsoleteClassWPPagerDutyUserDetailsView does not implementâ¦.â - essentially it seemed like this method was referencing the class I had deleted and not the one I had restored. When I went back to this method and simply reserved it, everything worked properly. I recall Marcus (at the time) mentioning that the Opal compiler was supposed to detect these kinds of changes and rebind things properly - but it seems that this isnât the case - or potentially restoring something from Epicea subverts this? I can raise a bug if its genuine - but Iâm just musing on this at the moment? Tim

April 25, 2018

Re: [Pharo-users] UFFI and autoRelease

by Ben Coman

On 25 April 2018 at 23:08, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > I don't understand the default > > finalizeResourceData: handle > handle isNull ifTrue: [ ^ self ]. > handle free. > handle beNull > > > when handle is an ExternaData, free is defined as in ExternalStructure > class as: > > free > "Free the handle pointed to by the receiver" > (handle ~~ nil and:[handle isExternalAddress]) ifTrue:[handle free]. > handle := nil. > Theorectical side thought. I wonder how threadsafe that code for #free is? Sending two messages between the ~~nil test and nil-assignment seems to leave the door open for another thread to erroneously pass the ~~nil test. IIUC, with an inlined #ifNotNil, the following might be safer (?) free "Save handle so its nil assignment is inlined with its #ifNotNil: test, eliminating possible thread change during message sends" |savedhandle| handle ifNotNil: [ savedHandle := handle. handle := nil. savedHandle isExternalAddress ifTrue: [ savedHandle free]. ]. cheers -ben > > > but beNull is not defined on nil. > > I can define my own finalizeResourceData: but the default one, does not > work apparently. > > > > On Tue, Apr 24, 2018 at 2:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> hi, >> >> there is nothing like that and I do not recommend messing with the >> registry in general. >> butâ¦ you can always extend the classes for your use, is >> around FFIExternalResourceManager. >> >> cheers, >> Esteban >> >> >> On 24 Apr 2018, at 14:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> >> wrote: >> >> >> I'm using autoRelease on some FFIOpaqueObject instances. >> >> I need to test some behavior when I delete explicitly one of these >> objects. âHow to remove these objects from the finalization list, in order >> they are not freed two times. >> >> Something like ignoreFinalization ? >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute."http://www.doesnotunderstand.org/ >> >> >> > > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ >

April 25, 2018

Re: [Pharo-users] TLS/SSL and SocketStreams

by Sven Van Caekenberghe

Hi Eric, > On 25 Apr 2018, at 22:25, Eric Gade <eric.gade(a)gmail.com> wrote: > > Hello, > > In the process of maintaining a small IRC client I have written, I'm trying to add the option to connect over SSL. Of course ensuring valid certificates and the handshake et al is quite complicated. Instead I'm attempting to rely on Zodiac's `ZdcSecureSocketStream` instead of a regular `SocketStream` for the connection. > > Here is where I run into a snag: `ZdcSecureSocketStream` is it's own complete rewrite. And though there are attempts to keep many of the same messages as `SocketStream`, some of the key ones are missing. In particular, I would like to have `#upToAll:` and even `nextLine` if possible. Attempting to subclass and implement them myself has been a disaster, since `ZdcSecureSocketStream` is actually quite complex. > > Can anyone help me with the following: > * Is there a better way to implement an SSL connection over a socket? Not that I know of. > * Who maintains Zodiac? How can I contact them? Me, mostly, but not the plugin part. The Zdc socket streams are binary. If you wrap them with a ZnCharacterReadStream (and a proper encoding) you get #nextLine , #upToAll: and even #match: Sending #asString to a ByteArray is wrong (as it implies a null decoding). Sven > Thanks > > -- > Eric

April 25, 2018

TLS/SSL and SocketStreams

by Eric Gade

Hello, In the process of maintaining a small IRC client I have written, I'm trying to add the option to connect over SSL. Of course ensuring valid certificates and the handshake et al is quite complicated. Instead I'm attempting to rely on Zodiac's `ZdcSecureSocketStream` instead of a regular `SocketStream` for the connection. Here is where I run into a snag: `ZdcSecureSocketStream` is it's own complete rewrite. And though there are attempts to keep many of the same messages as `SocketStream`, some of the key ones are missing. In particular, I would like to have `#upToAll:` and even `nextLine` if possible. Attempting to subclass and implement them myself has been a disaster, since `ZdcSecureSocketStream` is actually quite complex. Can anyone help me with the following: * Is there a better way to implement an SSL connection over a socket? * Who maintains Zodiac? How can I contact them? Thanks -- Eric

April 25, 2018