April 2018 - Pharo-users - lists.pharo.org

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

Re: [Pharo-users] UFFI and autoRelease

by Serge Stinckwich

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. 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] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Denis Kudriashov

2018-04-25 14:26 GMT+02:00 Richard O'Keefe <raoknz(a)gmail.com>: > (aSortFunction value: x value: y) returns a Boolean; > (aSortFunction value: x value: x) returns true. > So you can already set up a SortedCollection using > a SortFunction. So yes, that would work. > Yes. It was original goal to introduce them. I created another thread in dev list "SortedCollection based on SortFunction". > But there is no reason why #reversed (or my preference, > #converse) could not work on sortBlocks. > It will. But I think it is bad approach. Because any time you will need new kind of sort operation you will be forced extend BlockClosure. In general reversed/converse has no meaning for block. With SortFunction only simple extension #asSortFunction is required. > > > On 25 April 2018 at 23:27, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hi Richard. >> >> I agree with your proposal. >> But it force me to think that we should completely move to >> SortFunction's. >> In that case SortCollection will have sortFunction variable instead of >> sortBlock. And for your scenario reverse operation will be simple >> expression: "sortFunction := sortFunction reversed". >> >> >> >> 2018-04-23 3:09 GMT+02:00 Richard O'Keefe <raoknz(a)gmail.com>: >> >>> Test case: >>> #(1 2 4) asSortedCollection reverse add: 3; yourself >>> <print it> >>> The answer *should* be aSortedCollection(4 3 2 1) >>> but *is* aSortedCollection(4 2 1 3). >>> This works in Squeak. >>> The problem is that SortedCollection does not define >>> #reverse[d] but simply inherits it(them), and the >>> inherited code pays no attention to the sortBlock. >>> >>> I propose adding the following two methods to >>> SortedCollection: >>> >>> reverseInPlace >>> |a z| >>> a := firstIndex. >>> z := lastIndex. >>> [a < z] whileTrue: [array swap: a with: z. a := a + 1. z := z - 1]. >>> sortBlock := sortBlock >>> ifNil: [[:x :y | y <= x]] >>> ifNotNil: [[:x :y | sortBlock value: y value: x]]. >>> ^self >>> >>> reversed >>> ^self copy reverseInPlace >>> >>> The ANSI method is #reverse, not #reversed, but Pharo >>> defines #reverse to call #reversed, and OrderedCollection overrides >>> #reversed, so SortedCollection *must* override #reversed. >>> >>> #reverseInPlace is the name Squeak uses for the other >>> method. It also has a definition in SequenceableCollection, which is >>> not but is >>> equivalent to >>> >>> reverseInPlace >>> |a z| >>> a := 1. >>> z := self size. >>> [a < z] whileTrue: [self swap: a with: z. a := a + 1. z := z - 1].l >>> ^self >>> >>> r >>> >>> >> >

April 25, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

(aSortFunction value: x value: y) returns a Boolean; (aSortFunction value: x value: x) returns true. So you can already set up a SortedCollection using a SortFunction. So yes, that would work. But there is no reason why #reversed (or my preference, #converse) could not work on sortBlocks. On 25 April 2018 at 23:27, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Richard. > > I agree with your proposal. > But it force me to think that we should completely move to SortFunction's. > In that case SortCollection will have sortFunction variable instead of > sortBlock. And for your scenario reverse operation will be simple > expression: "sortFunction := sortFunction reversed". > > > > 2018-04-23 3:09 GMT+02:00 Richard O'Keefe <raoknz(a)gmail.com>: > >> Test case: >> #(1 2 4) asSortedCollection reverse add: 3; yourself >> <print it> >> The answer *should* be aSortedCollection(4 3 2 1) >> but *is* aSortedCollection(4 2 1 3). >> This works in Squeak. >> The problem is that SortedCollection does not define >> #reverse[d] but simply inherits it(them), and the >> inherited code pays no attention to the sortBlock. >> >> I propose adding the following two methods to >> SortedCollection: >> >> reverseInPlace >> |a z| >> a := firstIndex. >> z := lastIndex. >> [a < z] whileTrue: [array swap: a with: z. a := a + 1. z := z - 1]. >> sortBlock := sortBlock >> ifNil: [[:x :y | y <= x]] >> ifNotNil: [[:x :y | sortBlock value: y value: x]]. >> ^self >> >> reversed >> ^self copy reverseInPlace >> >> The ANSI method is #reverse, not #reversed, but Pharo >> defines #reverse to call #reversed, and OrderedCollection overrides >> #reversed, so SortedCollection *must* override #reversed. >> >> #reverseInPlace is the name Squeak uses for the other >> method. It also has a definition in SequenceableCollection, which is not >> but is >> equivalent to >> >> reverseInPlace >> |a z| >> a := 1. >> z := self size. >> [a < z] whileTrue: [self swap: a with: z. a := a + 1. z := z - 1].l >> ^self >> >> r >> >> >

April 25, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

As I pointed out yesterday, #sort and its immediate relatives are not alone. Look at #isSortedBy: . When do you want (#(1 1 1) asSortedCollection: b) isSortedBy: b to answer false? There are several reasons for sorting. One is so that you can use binary search. It's rather disconcerting that the binary search offered in Squeak and Pharo has nothing to do with sortBlocks. In several other Smalltalks it does. It is not terribly hard to write a binary search using a sortBlock that acts like #<=. It is not terribly hard to write a binary search using a sort block that acts like #<. It is harder than it needs to be to write a binary search that can tolerate either, and the one Smalltalk I know that does this copes by calling the sortBlock twice as often as it would need to if it knew one way or the other. As it happens, my own Smalltalk library lets me do sortBlock := sortBlock converse, which makes it easy to do the right thing. It is possible to implement this so that the result is as cheap to call as the original.

April 25, 2018