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

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. If the UI Process is using the Socket and it's using a blocking connection method, then - no surprise - it will be blocked. This won't affect other processes. If you were right, the following would block the UI Process for 100 seconds, but it doesn't block it at all, just try it: Transcript open. [ 10 timesRepeat: [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. s waitForConnectionFor: 10 ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. s isConnected ifTrue: [ Transcript show: 'Connected.'; cr. ]. s close ] ensure: [ s ifNotNil: [ s destroy ] ] ] ] fork. What do you mean by "servers"? ConnectionQueue? Levente > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 22, 2010 9:55 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> the one running the gui > > In that case, you're wrong. The UI Process will be able to run, because > other processes using Sockets will wait on Semaphores and not because of > "time limits". So I just convinced myself (and hopefully you too) about > that using Socket instances will not hang the entire image, just the > Process that uses the Socket. Therefore the SocketPlugin is as good as > possible. > > > Levente > >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 10:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >> >> Where? In the Socket class? And what's the "main thread"? >> >> >> Levente >> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 8:13 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Levente, >>>> >>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>> >>> I guess you're using Socket>>#connectTo:port: which uses >>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>> implement your own low level method which waits on semaphore until it's >>> signaled. If you want to terminate the connection attempt, just signal the >>> semaphore yourself, like here: >>> >>> s := Socket newTCP. >>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>> s semaphore waitTimeoutMSecs: 1000. >>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>> >>> And for ConnectionQueue, simply don't use it if you don't like it. It >>> doesn't have to poll at all, AFAIK it's just implemented that way. >>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>> don't block the image at all. But correct me if I'm wrong. >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 7:01 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Guillermo, >>>>> >>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>> >>>> When does a Socket block the image? >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>> >>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>> >>>>> Guille >>>>> >>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>> >>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>> where you can add any properties to object >>>>> on the fly, without need of adding a methods or declaring additional >>>>> instance variable in class... >>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>>> hi guys >>>>>>> >>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>> So we should really have a way to specify silent ui action. >>>>>>> Does anybody have an idea how I could do that? >>>>>>> >>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>> >>>>>> >>>>>> use morph propertyAt: #borderStyle >>>>>> so you don't have to break your head with it :) >>>>>> >>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>> them even don't using any >>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>> style etc should belong to root classes >>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>> properties (which is currently sits in morphic >>>>>> extensions are more appropriate storage for them). The only problem is >>>>>> that accessing them is much slower than ivars. >>>>>> >>>>>>> Stef >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Levente, Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Wednesday, September 22, 2010 9:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > the one running the gui In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible. Levente > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, September 20, 2010 10:14 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. > > Where? In the Socket class? And what's the "main thread"? > > > Levente > >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 8:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >> >> I guess you're using Socket>>#connectTo:port: which uses >> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >> the default timeout, use #connectTo:port:waitForConnectionFor: or >> implement your own low level method which waits on semaphore until it's >> signaled. If you want to terminate the connection attempt, just signal the >> semaphore yourself, like here: >> >> s := Socket newTCP. >> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >> s semaphore waitTimeoutMSecs: 1000. >> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >> >> And for ConnectionQueue, simply don't use it if you don't like it. It >> doesn't have to poll at all, AFAIK it's just implemented that way. >> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >> don't block the image at all. But correct me if I'm wrong. >> >> >> Levente >> >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 7:01 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Guillermo, >>>> >>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>> >>> When does a Socket block the image? >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>> Sent: Sunday, September 19, 2010 10:56 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>> >>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>> >>>> Guille >>>> >>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>> >>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>> where you can add any properties to object >>>> on the fly, without need of adding a methods or declaring additional >>>> instance variable in class... >>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>> hi guys >>>>>> >>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>> So we should really have a way to specify silent ui action. >>>>>> Does anybody have an idea how I could do that? >>>>>> >>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>> >>>>> >>>>> use morph propertyAt: #borderStyle >>>>> so you don't have to break your head with it :) >>>>> >>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>> them even don't using any >>>>> kind of borders. That's makes me wonder if anything like color, border >>>>> style etc should belong to root classes >>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>> properties (which is currently sits in morphic >>>>> extensions are more appropriate storage for them). The only problem is >>>>> that accessing them is much slower than ivars. >>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] HashedCollection showstopper :(

by Levente Uzonyi

On Wed, 22 Sep 2010, Igor Stasenko wrote: > Unfortunately, when preparing new finalization stuff, i got stuck with > HashedCollection > which is not yet integrated to Pharo. > (Sets with nils also depending on that). > > In Squeak, old WeakRegistry does the trick by setting a #finalizer: to > WeakKeyDictionary instance. > > Levente, can i ask you to give me a bits, (changesets or mcz packages), > which contain HashedCollection refactorings. I could extract them from the Squeak trunk, but it wouldn't be usable for Pharo, because these rely on previous changes done to Sets/Dictionaries in Squeak. Even if those are extracted it's still very hard to add them to Pharo, because there were serveral changes applied to Sets/Dictionaries in Pharo. The most important are: - AndrÃ©s' changes were integrated with additional stuff to change #identityHash -> #basicIdentityHash and #scaledIdentityHash -> #identityHash. - WeakKeyDictionaries were replaced with another implementation (http://code.google.com/p/pharo/issues/detail?id=1565 ) Levente > > Or, we can follow an easier path, just extract the delta from two packages, > which i found in mail archives: > --- > I uploaded two packages which contain this change. To load it evaluate > the following: > > (Installer squeakfoundation project: 'inbox') > install: 'Collections-ul.310.mcz'; > install: 'Collections-ul.311.mcz' > --- > > these are only related to WeakKeyDictionary, made by Levente to > speedup old finalization. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Schwab,Wilhelm K

Sig, The examples that make sense depend on what NativeBoost wants to be when it grows up. Is it a full competitor to FFI and/or Alien? If so, then it would be nice to see a rich set of calls to functions with different parameter types; ideally it would be in the form of something useful that gets added to Pharo using NativeBoost. That does a couple of things, providing both proof of concept and examples in one shot. With tongue firmly in cheek, looking at your indexing example, my stack might pop before the machine's :) However, it looks like it should settle down quickly enough, and things like that go on in the vm all the time; you are arguably just brining it into the image. Where would #readDoubleFrom: be in the class hiearchy? One of the reasons I asked about indexing an external array is that FFI is not good at such things. If you can provide ways to copy, fill, etc. blocks of memory and do it quickly, you gain ground, assuming you want to compete with FFI. Do callbacks, and you gain a lot of ground. Make calls on separate threads, and you gain a LOT of ground. That assumes that you can make it simple enough for a mildly above-average C programmer to understand how to use and ideally extend it. I will look at your example package on Squeak Source. One thing that drives me nuts with the Linux vm is that it looks for things where it wants to look, and gives no feedback about what it tried to do or even that it failed (except that handle is still zero). Your callout pragmas take a module name; is there any way to see inside of that or to provide a full path to the library? It is nice to be able to confirm loading of a library w/o having to call something, since there won't always be something "safe" (free of side effects) to call as a test. At the risk of seeming difficult, everything is academic until we have a Linux plugin or at least can build same. Alien has that problem. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, September 22, 2010 10:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Fair enough :) The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Beyond some list traffic, I found this: > The work for supporting Linux and Mac is in progress. > http://code.google.com/p/nativeboost/wiki/NativeBoost > > Is there other documentation somewhere? Build instructions? You can find all existing documentation, installation instructions on wiki pages at the above site. There is no other place for it. http://code.google.com/p/nativeboost/wiki/Installation - installation instructions. > You have a block copy, which is good. What about indexing, such as getting floats or doubles out of external memory? This is just a piece of cake. ;) readDoubleFrom: address " This method loads the double from given external address. an address can be an instance of NBExternalAddress, or simple ByteArray with at least 8 bytes long, which holds a double floating value" <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> "We are using a pseudo-function prototype and supplying own assembler code, instead of making a call to external function. In given example, an address argument , after coercion is pushed on stack. " ^ NBFFICallout cdecl: #( double ( void * address) ) " A pseudo-function takes 1 argument, and returns double value. Under cdecl call convention, all floating point return types is returned in fp(0) CPU register" emitCall: [:gen | | asm | asm := gen asm. "Here , we expecting that an address value is already pushed on stack" asm pop: asm EAX; "load an address value into EAX register by popping a stack" fld: (asm EAX ptr64). "load a floating point value from memory, at base address, held in EAX register into fp(0) register, we are using #ptr64, to indicate that memory operand size is 64bits long" " return value set, we are done. A code generator will take care for emitting code, which converts a double floating point value into smalltalk object. " ] I just uploaded this example and also how to write doubles from/to memory. See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. > I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Are there examples to follow? Tell me, what examples you would like to see. I will gladly provide them. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, September 22, 2010 6:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] DoubleArray > > On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Henry, >> >> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >> >> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >> > > The main reason, why they are not here, that VM needs an additional > set of primitives, which working with them. > > <sellsman hat on> > I can only say that with NativeBoost, you could be able to implement > it quite easily in image and ship it in image, > without a need to change VM or use external plugin. > <sellsman hat off> > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >> Sent: Wednesday, September 22, 2010 5:23 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] DoubleArray >> >> On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>> Squeak, deliberately, does not have a double array class. Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >> If the goal is to pass it as a parameter to an external function, one >> way would be to subclass WordArray, storing(and reading) each Float in >> two elements, and have the endianness decided by Smalltalk endianness. >> Probably want a startUp method for the class to swap instances >> endianness if the platform has changed as well. >>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>> >>> Bill >> More likely because no one has actually had a need for one. >> It's definitely not _needed_ in base, where normal arrays of floats >> would do the same job just as well, if not better. >> IMHO, if someone makes one, it so should probably be part of a package >> related to external interfacing. >> >> Cheers, >> Henry >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] Metacello repositories in the future

by HernÃ¡n Morales Durand

Hi Mariano, 2010/9/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. I don't like to loose my time of ESUG answering/reading emails, but a > summary was that we can implement something like #latestVersion or > #lastVersion but called #stableVersion > which could be something like this: > > ConfigurationOfXXX >> stableVersion > Â Â Â Â for: #pharo10 do: [Â ^ self version: '1.35.5' ] > > Â Â Â for: #pharo11 do:Â [Â ^ self version:Â '3.23' ] > > Â Â Â Â for: #pharo12 do: [Â self error: 'Not yet supported' ] > Maybe you could implement some form of forGreaterThan: #pharo12 do: [ ... ] ? so developers do not have to monitor new Pharo versions and update their configurations. Does it makes sense? Cordialement, > > Then the user can do something like: > > ConfigurationOfXXX project stableVersion load. > > And Metacello will load the stable version for the current Pharo version you > are running in. And he will apply and use probably the same for the > different Gemstone versions. > > In addition, even if not needed, we could commit this confs (with this new > #stableVersion) into the 3 different MetacelloPharo repositories. With this, > it is easier to know which confs work for each pharo versions. > > Finally, we thought I could do a test of implementing all those #stable > methods in all the confs of the PharoDevÂ andÂ Â try to recreate a Pharo1.0 > dev and a Pharo 1.1 dev, using the correct core but using this "stable" > version and see if it works. > > Cheeers > > Mariano > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Sept. 23, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Levente Uzonyi

On Tue, 21 Sep 2010, Hilaire Fernandes wrote: > Le 20/09/2010 23:30, Levente Uzonyi a Ã©crit : >> On Mon, 20 Sep 2010, Hilaire Fernandes wrote: >> >>> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>>> >>>>> Really I don't understand CUIS long term objective, why this work is >>>>> not >>>>> done in Pharo? They share the same vision. >>>> >>>> You could ask the same question with Pharo and Squeak instead of Cuis >>>> and Pharo, couldn't you? >>> >>> No, I can't. >>> >>> Pharo provides me a clear vision I can thrust: a Smalltalk environment >>> to build third party applications (ie makes my developer life easier). >>> Squeak does not provide me this thrust nor indication of that direction. >> >> When was the last time you used Squeak? > > In may, when I ported back istoa artifact with Etoys scripting. It was > quite pleasant to update these code within Squeak. > >> >>> You can object it is matter of point of view, I will object it is a >>> matter of ressources you can allocate to write an application. Mine are >>> limited: I start writing DrGeo under Squeak, then I continued with >>> Pharo. I can really fell the difference: nice Widgets, cleaner system I >>> can understand, ease to integrate changes/improvements upstream. All in >>> all, I get the job done more nicely from my perspective. >> >> So you're using Pharo because of Polymorph? > > yes, but not only. What are the other reasons? > >>> In the past, project got hudge resources (ie Sophie), this project >>> failed to give back to the community in a proper way. Was it because >> >> I don't really get this, which project are you talking about? > > Sophie. Why can't we have stuff from Sophie back to Squeak/Pharo? - only the Sophie developers are familiar with the code and they are not motivated enough to extract it - the license is BSD, so the code can't be included in Pharo/Squeak Levente > > Hilaire > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Levente Uzonyi

On Mon, 20 Sep 2010, Jimmie Houchin wrote: > On 9/20/2010 5:30 PM, Levente Uzonyi wrote: > On Mon, 20 Sep 2010, Jimmie Houchin wrote: > I presently do not see a Pro-business or even particularly business-friendly vision from Squeak. > > Just my perspective and opinions. > > > Thanks, this is really helpful. The only thing I don't really get is what do you mean by "pro-business" and "business-friendly". What makes > Pharo "pro-business"? The pre-installed tools? The familiar looking default UI? (only for mac users) > > > Hello Levente, > > Pharo the artifact is itself not necessarily more or less pro-business than Squeak. Pharo the vision, goals, leadership and community are. > > Stephane posted a message on the list back in August: > "Poll: missing libraries to support business" > > I have never seen such a post on squeak-dev. Nor in my 10+- years on squeak-dev seen many posts for/about business that received much audience. Now if > you post about the fun things, etoys, midi, robots, mpeg, ... you get a fair amount of response. Many/most Squeakers are very Squeak being multimedia. > I am definitely pro that. But I believe if you support people making money with Squeak/Pharo that the fun stuff is also supported. It has been > reasonably, historically the opinion of many that Squeak equates to multimedia, with a strong educational leaning. If you wanted something else, it > could be tolerated but not well supported. The Seaside guys had to work hard to arrive at their status. As I say, these are my opinions from reading > and lightly participating in the Squeak community for 10+- years. The post in itself may be impressive, but take into account that Stephane asked the question after people being unhappy about ESUG supporting the developement of an XML-RPC library for Pharo/Squeak. > > I have had a very long love/hate relationship with Squeak. I really, really love Squeak. The hate comes in when I find something I can't do in Squeak > but can easily do in Python. That frustrates the heck out of me. Python is very pro-business, very business friendly, and it has a large enough > community to accomplish those goals. Squeak doesn't have the community to accomplish all that Python has. But Squeak/Smalltalk is much more stable > target. Code can last so much longer, be developed much faster. So I believe the community, though smaller, can and will accomplish more and better. At > least I believe I accomplish more, better, faster in Squeak/Pharo than in Python. > > Most often Squeak lost me whenever I have do things outside of Squeak or Python interfacing with the OS or outside libraries. Python has superior > support for databases, etc. > Currently I have a business requirement to interface with a COM dll. So at the moment Python empowers or enables me to do that and Squeak/Pharo do not. > > This is all I have to do in Python. I have this in my Python app which interfaces the COM dll to interface the server to which I need to communicate. > > def make_libraries(self): > Â Â Â """ > Â Â Â Before you can use the libraries inside Python, you have to run once the makepy.py script > Â Â Â (.\Lib\site-packages\win32com\client\makepy.py). > Â Â Â Select "The Desired Library" in the choose box. > Â Â Â This will create a wrapper library usable by Python and in the path. > Â Â Â mylib = win32com.client.Dispatch("DesiredLibraryClass") and use. > Â Â Â """ > Â Â Â # This line should default to the Python being used by this program. > Â Â Â os.system(r"Lib\site-packages\win32com\client\makepy.py") > > And most of the above code is simply to remind me how to use the makepy.py library as I use it so seldom that I don't remember between invocations. > Most of my time is spent using the library it provides which gives me access to the dll. I would love to have this capability in Squeak/Pharo. It > enables/empowers the little guy who has ideas but can't go low level. He can do Python/Smalltalk but not C or system level programming. > > I see more openness for this in Pharo than Squeak. Sure Squeak would accept such a library if it became available. But there isn't much community > desire for such business software. It isn't sexy or fun. But it does get the job done and enables business and commerce. Someone has to write those bindings. If there's no need expressed for such bindings, they won't be written. Btw there's a package named COM on SqueakSource. > > From squeak.org > "Squeak is the vehicle for a wide range of projects from multimedia applications, educational platforms to commercial web application development." > > From pharo-project.org > Pharo's goal is to deliver a clean, innovative, free open-source Smalltalk environment. By providing a stable and small core system, excellent > developer tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical Smalltalk applications. > > Which sounds business oriented, business friendly, pro-business? The first one is the last sentence of Squeak's description from squeak.org. It doesn't tell us the goals of Squeak, it tells us what it is (or was when the text was written). The first two sentence of the description tells a lot more about Squeak: "Squeak is a modern, open source, full-featured implementation of the powerful Smalltalk programming language and environment. Squeak is highly-portable - even its virtual machine is written entirely in Smalltalk making it easy to debug, analyze, and change." The second one describes (reached and unreached) goals of Pharo. It's hard to compare those, because they don't describe the same thing. AFAIK the goals of Squeak are not available on squeak.org, the mailing list and the Board's site give you more information about this. > > Nothing in the Squeak statement sounds like business unless your business is multimedia, education and web apps. Mine is none of those. But I want what > is in the Pharo description. Yes, I know much of what is in that description is also in Squeak the artifact. Which leads back to vision, goals, > leadership and community. Overtime the artifacts will potentially diverge more due to those intangibles. Those elements in Squeak tend towards > primarily multimedia and education and only very secondarily Seaside. Whereas those intangibles in Pharo are seeking to build a community of > businesses, researchers, students and individuals who want to use Smalltalk as the basis for what is important to them. IMHO this is a very important > aspect for building for the future. > > Watching the lists, the players, the discussions and my participation in those has lead to these very subjective opinions. I would be extraordinarily > please for Squeak to prove me wrong. I think that Squeak can as it becomes smaller and more modular. But that's the artifact. The intangibles would > have to be improved also. The intangibles are often as important and sometimes more so than the artifact. And perceptions are a real basis for > decisions. > > I would love Squeak/Pharo to eliminate or at least incredibly reduce any need, requirement or desire to drop down to Python to accomplish any of my > goals or requirements. IMHO you can help this by dropping a note to the mailing lists whenever you have to use Python instead of Pharo/Squeak. > > Hope this helps. Yes, it was helpful, thanks. Levente > > Jimmie > >

Sept. 23, 2010

[Pharo-project] NativeBoost examples (was: Re: DoubleArray)

by Igor Stasenko

On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Fair enough :) Â The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Â Beyond some list traffic, I found this: > The work for supporting Linux and Mac is in progress. > Â http://code.google.com/p/nativeboost/wiki/NativeBoost > > Is there other documentation somewhere? Â Build instructions? You can find all existing documentation, installation instructions on wiki pages at the above site. There is no other place for it. http://code.google.com/p/nativeboost/wiki/Installation - installation instructions. > You have a block copy, which is good. Â What about indexing, such as getting floats or doubles out of external memory? This is just a piece of cake. ;) readDoubleFrom: address " This method loads the double from given external address. an address can be an instance of NBExternalAddress, or simple ByteArray with at least 8 bytes long, which holds a double floating value" <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> "We are using a pseudo-function prototype and supplying own assembler code, instead of making a call to external function. In given example, an address argument , after coercion is pushed on stack. " ^ NBFFICallout cdecl: #( double ( void * address) ) " A pseudo-function takes 1 argument, and returns double value. Under cdecl call convention, all floating point return types is returned in fp(0) CPU register" emitCall: [:gen | | asm | asm := gen asm. "Here , we expecting that an address value is already pushed on stack" asm pop: asm EAX; "load an address value into EAX register by popping a stack" fld: (asm EAX ptr64). "load a floating point value from memory, at base address, held in EAX register into fp(0) register, we are using #ptr64, to indicate that memory operand size is 64bits long" " return value set, we are done. A code generator will take care for emitting code, which converts a double floating point value into smalltalk object. " ] I just uploaded this example and also how to write doubles from/to memory. See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. > I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Â Are there examples to follow? Tell me, what examples you would like to see. I will gladly provide them. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, September 22, 2010 6:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] DoubleArray > > On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Henry, >> >> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. Â It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >> >> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >> > > The main reason, why they are not here, that VM needs an additional > set of primitives, which working with them. > > <sellsman hat on> > I can only say that with NativeBoost, you could be able to implement > it quite easily in image and ship it in image, > without a need to change VM or use external plugin. > <sellsman hat off> > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >> Sent: Wednesday, September 22, 2010 5:23 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] DoubleArray >> >> Â On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>> Squeak, deliberately, does not have a double array class. Â Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >> If the goal is to pass it as a parameter to an external function, one >> way would be to subclass WordArray, storing(and reading) each Float in >> two elements, and have the endianness decided by Smalltalk endianness. >> Probably want a startUp method for the class to swap instances >> endianness if the platform has changed as well. >>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>> >>> Bill >> More likely because no one has actually had a need for one. >> It's definitely not _needed_ in base, where normal arrays of floats >> would do the same job just as well, if not better. >> IMHO, if someone makes one, it so should probably be part of a package >> related to external interfacing. >> >> Cheers, >> Henry >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > the one running the gui In that case, you're wrong. The UI Process will be able to run, because other processes using Sockets will wait on Semaphores and not because of "time limits". So I just convinced myself (and hopefully you too) about that using Socket instances will not hang the entire image, just the Process that uses the Socket. Therefore the SocketPlugin is as good as possible. Levente > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, September 20, 2010 10:14 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. > > Where? In the Socket class? And what's the "main thread"? > > > Levente > >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Monday, September 20, 2010 8:13 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >> >> I guess you're using Socket>>#connectTo:port: which uses >> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >> the default timeout, use #connectTo:port:waitForConnectionFor: or >> implement your own low level method which waits on semaphore until it's >> signaled. If you want to terminate the connection attempt, just signal the >> semaphore yourself, like here: >> >> s := Socket newTCP. >> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >> s semaphore waitTimeoutMSecs: 1000. >> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >> >> And for ConnectionQueue, simply don't use it if you don't like it. It >> doesn't have to poll at all, AFAIK it's just implemented that way. >> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >> don't block the image at all. But correct me if I'm wrong. >> >> >> Levente >> >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 7:01 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Guillermo, >>>> >>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>> >>> When does a Socket block the image? >>> >>> >>> Levente >>> >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>> Sent: Sunday, September 19, 2010 10:56 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>> >>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>> >>>> Guille >>>> >>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>> >>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>> where you can add any properties to object >>>> on the fly, without need of adding a methods or declaring additional >>>> instance variable in class... >>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>> hi guys >>>>>> >>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>> So we should really have a way to specify silent ui action. >>>>>> Does anybody have an idea how I could do that? >>>>>> >>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>> >>>>> >>>>> use morph propertyAt: #borderStyle >>>>> so you don't have to break your head with it :) >>>>> >>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>> them even don't using any >>>>> kind of borders. That's makes me wonder if anything like color, border >>>>> style etc should belong to root classes >>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>> properties (which is currently sits in morphic >>>>> extensions are more appropriate storage for them). The only problem is >>>>> that accessing them is much slower than ivars. >>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] ESUG actions (was: Best Spreading Smalltalk Actions)

by askoh

I think ESUG has been an outstanding success for Smalltalk globally and therefore deserves to be called The Smalltalk Users Group. TSUG. Such a name change will also give a better impression to Smalltalk and is not untrue. All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Best-Spreading-Smalltalk-Actions-tp2542307p2551292.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 23, 2010