September 2015 - Pharo-dev - lists.pharo.org

When I drag and drop a method between two classes and two nautilus browser

by stepharo

When I drag and drop a method between two classes and two nautilus browser. I get a DNU isDefault because package returns nil This is due to the execution of RBUnpackageCOdeRule isUnpackaged: anEntity ^ anEntity package isDefault https://pharo.fogbugz.com/f/cases/16474/When-I-drag-and-drop-a-method-betwe…

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Dale Henrichs

+1 for an ANSICompatibility package ... ANSI shouldn't hold Pharo back, and an ANSICompatibility package allows for cross-dialect code sharing which was the aim of the ANSI standard in the first place. Dale On 9/3/15 5:51 PM, Ben Coman wrote: > On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> I've second Sven here. In case anybody wants the old method put it in some >> ANSICompatibility package to ease porting packages from ANSI-compliant >> Smalltalks. >> >> On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> We went through a lot of effort/pain to move to substring, I think for >>> good reasons. >>> >>>> On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> >>>> wrote: >>>> >>>> why not both ? >>> Because the proper English spelling is with lowercase > +1. As a consequence, its the form that has won industry wide. > Aligning on this provides a small part of an accumulation of items > that lower the friction of adoption from the wider industry. On the > flip side, even though are potentially more non-Smalltalkers who may > adopt Pharo, others from existing Smalltalker dialects may be more > likely to transfer, so its good to not alienate them. So it may be > useful to have an ANSICompatibility package available in the Catalog > Browser that you can point people to - a box to tick on the checklist > to reduce the barriers to entry. > > cheers -ben > >>> https://duckduckgo.com/?q=define%3A+substring&ia=definition >>> >>>> On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo(a)free.fr> wrote: >>>> *) It appears that Pharo is removing subString: in favor of >>>> substring:. The ANSI standard defines subString:. >>>> >>>> I was not aware of it. In fact ANSI is bad and totally incomplete >>>> (for example we studies strings and this is a mess and totally >>>> incomplete). >>>> Now we should probably add it. I will send the mail to the >>>> mailing-list and let people decide. >>>> >>>> >>>> >>>> >>>

Sept. 4, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Ben Coman

On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > I've second Sven here. In case anybody wants the old method put it in some > ANSICompatibility package to ease porting packages from ANSI-compliant > Smalltalks. > > On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> We went through a lot of effort/pain to move to substring, I think for >> good reasons. >> >> > On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> >> > wrote: >> > >> > why not both ? >> >> Because the proper English spelling is with lowercase +1. As a consequence, its the form that has won industry wide. Aligning on this provides a small part of an accumulation of items that lower the friction of adoption from the wider industry. On the flip side, even though are potentially more non-Smalltalkers who may adopt Pharo, others from existing Smalltalker dialects may be more likely to transfer, so its good to not alienate them. So it may be useful to have an ANSICompatibility package available in the Catalog Browser that you can point people to - a box to tick on the checklist to reduce the barriers to entry. cheers -ben >> >> https://duckduckgo.com/?q=define%3A+substring&ia=definition >> >> > On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo(a)free.fr> wrote: >> > *) It appears that Pharo is removing subString: in favor of >> > substring:. The ANSI standard defines subString:. >> > >> > I was not aware of it. In fact ANSI is bad and totally incomplete >> > (for example we studies strings and this is a mess and totally >> > incomplete). >> > Now we should probably add it. I will send the mail to the >> > mailing-list and let people decide. >> > >> > >> > >> > >> >> >

Sept. 4, 2015

Re: [Pharo-dev] [squeak-dev] FFI callbacks

by Eliot Miranda

Hi Craig, you need Alien-eem.24 Here's Alien class>>exampleCqsort "Call the libc qsort function (which requires a callback)." "Alien exampleCqsort" "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / 100.0" | cb rand nElements sizeofDouble values orig sort | rand := Random new. values := Alien newC: (nElements := 100) * (sizeofDouble := 8). 1 to: values dataSize by: sizeofDouble do: [:i| values doubleAt: i put: rand next]. orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values doubleAt: i]. cb := Callback signature: #(int (*)(const void *, const void *)) block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. (Alien lookup: 'qsort' inLibrary: Alien libcName) primFFICallResult: nil with: values pointer with: nElements with: sizeofDouble with: cb thunk. sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values doubleAt: i]. values free. ^orig -> sort The above example uses Alien to make the callout. To use it with the FFI simply pass cb pointer as the argument as is done above. Implementation: The way that it works is in two parts - the VM passes up a pointer to a structure from which all arguments, stacked and in registers (because the VM has copied the register args into the struct) can be accessed, and through which the result can be returned. - the image level provides marshalling methods that match the signature in the callback So e.g. with a callback of Callback signature: #(int (*)(const void *, const void *)) block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] the marshalling methods are in Callback's signature protocol: Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien <signature: #(int (*)(const void *, const void *)) abi: 'IA32'> ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5))) where spAlien is an Alien pointing to a VMCallbackContext32. For ARM support we would add Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien intRegArgs: regsAlien <signature: #(int (*)(const void *, const void *)) abi: 'ARMV5'> ^callbackContext wordResult: (block value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) Basically the idea is that the selector of the method doesn't matter except for the number of arguments. What's important is the pragma which defines the signature and the ABI for which this is a valid marshalling method. When the callback is instantiated, Callback introspects to find the marshalling method that matches the signature. If one doesn't already exist you can write one. Hopefully we'll write an ABI compiler that will automatically generate these marshalling methods according to the platform's ABI, but for now its a manual process. But at least it's open and flexible. When the callback is invoked the evaluator is performed with the current callbackContext and pointer(s) to the arguments. There is a 32-bit and a 64-bit callback context, and it can have a stack pointer, integer register args and floating point register args. So it's general enough for any callback. To pass back the result, a value is assigned into the struct via the accessor in the marshalling method and control returns to teh point where teh callback comes in, and this uses a primitive to return. Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive longjmp's back to the entry point in the VM which extracts the result and the code for the kind of result and returns: Callback class>>invokeCallbackContext: vmCallbackContextAddress "<Integer>" "^<FFICallbackReturnValue>" "The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. Return via primReturnFromContext:through:. thisContext's sender is the call-out context." | callbackAlien type | callbackAlien := (Smalltalk wordSize = 4 ifTrue: [VMCallbackContext32] ifFalse: [VMCallbackContext64]) atAddress: vmCallbackContextAddress. [type := Callback evaluateCallbackForContext: callbackAlien] ifCurtailed: [self error: 'attempt to non-local return across a callback']. type ifNil: [type := 1. callbackAlien wordResult: -1]. callbackAlien primReturnAs: type fromContext: thisContext On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta <craig(a)netjam.org> wrote: > > Hi all-- > > I'd like to use a C shared library via FFI from Squeak or Pharo. > Specifically, I want to call a C function which takes as one of its > parameters a pointer to an array of callback function addresses. Does > one of the FFI approaches floating around handle that, and provide a > relatively pleasant mapping between Smalltalk block closures and C > callback function addresses? > > I was doing this so far in GemStone, but apparently its FFI only > supports passing callback function addresses one at a time as direct > parameters of C callouts. I suppose I could write a wrapper C library > around the one I really want to use, that provides the callback setup > interface that GemStone expects, but whenever I have to write actual C > code I start to think "Hm, why don't I just use a Smalltalk VM for which > I have the source?" :) All the fancy distributed object-database stuff > that my project also wants can wait for a bit. > > > thanks! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > -- _,,,^..^,,,_ best, Eliot

Sept. 3, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Gabriel Cotelli

I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks. On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > We went through a lot of effort/pain to move to substring, I think for > good reasons. > > > On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > why not both ? > > Because the proper English spelling is with lowercase > > https://duckduckgo.com/?q=define%3A+substring&ia=definition > > > On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo(a)free.fr> wrote: > > *) It appears that Pharo is removing subString: in favor of > > substring:. The ANSI standard defines subString:. > > > > I was not aware of it. In fact ANSI is bad and totally incomplete > > (for example we studies strings and this is a mess and totally > > incomplete). > > Now we should probably add it. I will send the mail to the > > mailing-list and let people decide. > > > > > > > > > > >

Sept. 3, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Sven Van Caekenberghe

We went through a lot of effort/pain to move to substring, I think for good reasons. > On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > why not both ? Because the proper English spelling is with lowercase https://duckduckgo.com/?q=define%3A+substring&ia=definition > On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo(a)free.fr> wrote: > *) It appears that Pharo is removing subString: in favor of > substring:. The ANSI standard defines subString:. > > I was not aware of it. In fact ANSI is bad and totally incomplete > (for example we studies strings and this is a mess and totally > incomplete). > Now we should probably add it. I will send the mail to the > mailing-list and let people decide. > > > >

Sept. 3, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Dimitris Chloupis

why not both ? On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo(a)free.fr> wrote: > *) It appears that Pharo is removing subString: in favor of > substring:. The ANSI standard defines subString:. > > I was not aware of it. In fact ANSI is bad and totally incomplete > (for example we studies strings and this is a mess and totally > incomplete). > Now we should probably add it. I will send the mail to the > mailing-list and let people decide. > > > > >

Sept. 3, 2015

Need a decision on subString: vs substring:

by stepharo

*) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:. I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

yes but first name out :) Le 2/9/15 14:08, Peter UhnÃ¡k a Ã©crit : > > Off the top of my head, in the worst case implementing #name on the > class-side can be fatal. > > > TBH using generic names (for both variables and methods) on class side > is like running through a mine field. > I blew up my image more than once. > > From UX perspective the system should warn the user if he is trying to > override some system method or variable, but that is perhaps issue of > its own. > > Peter >

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

Yes we know but first we should just make sure that the system is still working without this $#%^^&*^(&)*%^& method. Le 2/9/15 10:29, Esteban Lorenzano a Ã©crit : > but if we deprecate, that means we need to remove it from the system. > deprecated is for external users, not for Pharo it self. > > Esteban > > ps: We *can not* remove #name from the system just like that. It is > too widely use, we need to give users time to adapt. Doing otherwise > is not professional and expect a lot of people yelling (and with > reason, in this case). > >> On 02 Sep 2015, at 10:21, Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> wrote: >> >> The problem is if (like in the past) name is extensively used by some >> library we depend upon (like... let's say morphic), a deprecation >> that raises an exception may turn the system unusable. It's not that >> it is not doable, but we should do it gently and with love. >> >> El miÃ©., 2 de sept. de 2015 a la(s) 9:30 a. m., Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> escribiÃ³: >> >>> On 02 Sep 2015, at 09:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com >>> <mailto:i.uhnak@gmail.com>> wrote: >>> >>> On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de >>> <mailto:nicolaihess@web.de>> wrote: >>> >>> How can we find out, which external projects depend on this? >>> >>> >>> Is #name in any way special? Why not just deprecate it like any >>> other method change or removal? (And then remove it in Pharo 6) >> >> +1 >> thatâs the way to do it :) >> >>> >>> Peter >> >

Sept. 3, 2015