October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] new Cog VM available at...

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 7:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > http://www.mirandabanda.org/files/Cog/VM/VM.r2499/. > > CogVM binaries as per VMMaker.oscog-eem.133/r2499. Tiny performance tweak to > bytecodePrimMultiply. Added findStringBeginningWith: debugging facility. > Fix yet another slip in Cogit>>lookup:for:methodAndErrorSelectorInto: > for cannotInterpret: cases. Fixes Mariano's crash as of 2011/10/03. > > Thanks Eliot! Indeed, it solves both problems I have reported :) thanks a lot > > Add -numextsems command-line argument to set size of external semaphore > table on start-up. > > Enjoy > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by Henrik Sperre Johansen

On 11.10.2011 16:03, John Toohey wrote: > Thats for this explanation. I can't find the #inProduction method, > what class is it in? It's a temporary variable in #maxExternalSemaphores for the moment, as no such global switch exist yet. I'd recommend setting the limit higher and save / run the image for awhile to see if the issue persists before deciding to change it to true though. Even if it does persist, I'd check for whether there are references kept to obsolete Sockets before switching though. Cheers, Henry

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by John Toohey

Thats for this explanation. I can't find the #inProduction method, what class is it in? On Tue, Oct 11, 2011 at 08:17, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 11.10.2011 01:00, John Toohey wrote: >> >> Henrik, >> >> Could you explain this in a little more detail for me? Are you saying >> the socket timeout is really a semaphore problem? >> > Yes, in that Sockets block on Semaphores registered in the vm, which are > then signalled from the external plugin. > The number of objects for which this signalling is done does not grow > automatically, see: > http://code.google.com/p/pharo/issues/detail?id=4505 > for the discussion/rationale behind now raising an error when there's no > free space anymore, instead of silently losing signals. > > The methods (with comments) in image resulting from this issue, and > interesting to read in this context is: > VirtualMachine >> #maxExternalSemaphores: > - you can change inProduction to true, and it will no longer crash, but > write you a warning that you might be losing signals due to too little > default space. > ExternalSemaphoreTable >> Â #collectionBasedOn:withRoomFor: and > #freedSlotsIn:ratherThanIncreaseSizeTo: > - comments should hopefully be useful > > Cheers, > Henry > > -- ~JT

Oct. 11, 2011

Re: [Pharo-project] [update 1.4] #14191

by StÃ©phane Ducasse

Apparently this fixes has a problem so we will have to investigate and I will rollback as soon as I have access to a decent network. (I hope around 10 pm). On Oct 11, 2011, at 3:34 PM, stephane ducasse wrote: > > 14191 > ----- > > Issue 4904: MorphTreeMorph improvements. Thanks Alain Plantec. > - Speed improvement: 10 to 12 times faster ! > the speed is now very near from what is possible with PluggableListMorph. > the TimeProfiler is now very efficient. > > - made MorphTreeModel composable (see MCSliceMaker which is not a MorphTreeModel subclass anymore) > > - Start to use Annoucements instead of change/update (see MorphTreeSelectionChanged announcement) > - no item forgotten when sliding with the mouse for auto multiselection (as in the TestRunner, try to select items with the mouse, some items are not selected if the mouse slides too fast) > - no need for TickList* (8 classes) and no need for a CheckList class > > Stef

Oct. 11, 2011

[Pharo-project] [update 1.4] #14191

by stephane ducasse

14191 ----- Issue 4904: MorphTreeMorph improvements. Thanks Alain Plantec. - Speed improvement: 10 to 12 times faster ! the speed is now very near from what is possible with PluggableListMorph. the TimeProfiler is now very efficient. - made MorphTreeModel composable (see MCSliceMaker which is not a MorphTreeModel subclass anymore) - Start to use Annoucements instead of change/update (see MorphTreeSelectionChanged announcement) - no item forgotten when sliding with the mouse for auto multiselection (as in the TestRunner, try to select items with the mouse, some items are not selected if the mouse slides too fast) - no need for TickList* (8 classes) and no need for a CheckList class Stef

Oct. 11, 2011

[Pharo-project] [update 1.4] #14190

by StÃ©phane Ducasse

14190 ----- update UpdateStreamer to use new version of Zn

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Herby VojÄÃk

Philippe Marschall-2 wrote: > > On 10/11/2011 01:59 PM, Herby VojÄÃk wrote: >>> Without async IO supporting WebSockets does not seem to make much sense. >>> >>> Cheers >>> Philippe >>> >> >> I do not understand the rationale... "async IO" (more correctly, as Ryan >> Dahl often points, is "non-blocking IO", there is nothing async in >> node.js, >> it's single-threaded) is just the alternative model to "threaded, >> blocking >> IO". What does it have in common with sense of making WebSockets work? > > Pharo only supports "threaded, blocking IO", so for each WebSocket (or > long-polling, or forever i-frame) connection we need to have a Process > lingering around. That makes Pharo less than ideal for building a > socket.io server. > > Cheers > Philippe > Thanx. That also answers the question if there is a project/plan for a socket.io server-side library (not, I assume) which I could reuse. So either write one (with knowing there will be lots of Processes involved), or not use Pharo for the server. -- View this message in context: http://forum.world.st/socket-io-tp3891592p3894239.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Herby VojÄÃk

StÃ©phane Ducasse wrote: > > hi herby > > what is specific with socket server? > > Stef > It's socket.io (.io is important), a js library that abstracts server-push technologies into high-level API. What is specific to socket.io server is, well, to able to connect socket.io clients. And having an API similar to the original one (non-blocking "on event do callback" kind of thing). -- View this message in context: http://forum.world.st/socket-io-tp3891592p3894220.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 11, 2011

Re: [Pharo-project] [squeak-dev] Migrating Complex in a separate package

by David T. Lewis

On Mon, Oct 10, 2011 at 08:28:40PM +0200, Nicolas Cellier wrote: > Hi, > > Facts: > - Complex is present in Squeak trunk image but not used in Kernel > - Complex is absent from Pharo image. > This breaks portability of some packages. > > I suggest putting Complex in its own package in squeaksource. This can > work for Pharo alone. > I also suggest to optionally remove Squeak.Complex from trunk. > > There are then other choices: > - the name of the package : can be Complex or Math-Complex (I already > put a few Math-* in squeak source...) > - the name of the class can be Complex or ComplexNumber > Specifically I don't like isComplex, many objects could respond true > because complicated; > isComplexNumber is much more explicit. > We could also think of having complex expressions in a symbolic > algebra, and isComplexNumber would be true only for a literal value.. > > What I could eventually do is publish an old Complex in package > Complex for backard compatibility and an updated ComplexNumber in a > Math-Complex package... > > How many of you use Complex ? > What do you think of these proposals ? I do not use Complex, but I very much like having it in the image because it makes complex arithmetic easy to explore, and makes the system feel more complete. In a way, I think that Complex has more justification for being in the image than Float, because Complex represents fundamental concepts, whereas Float is really just a hardware performance optimization ;) To me it feels natural to have Complex categorized with numbers, but if that makes it harder to support or harder to adopt in other images, then it would not bother me to have it in another package. Changing the name to ComplexNumber would not matter to me, either name would make sense. Thanks! Dave

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by StÃ©phane Ducasse

I just wanted to know if I was correct else I agree with you ;D On Oct 11, 2011, at 2:29 PM, Igor Stasenko wrote: > On 11 October 2011 09:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi igor >> >> I imagine that if the server is not run headless then the screen will be filled up with debuggers and people can try if they succeed to >> connect to the image using a remote tools. Even if I prefer a real headless mode, is my sentence correct? >> > Yes. But read the phrase "filled up with debuggers" again: i bet that > in 99% cases people just closing debuggers and not wasting time > to analyse the cause of every error by opening individual debugger etc. > It makes no sense. What makes sense is to add code which doing this > automatically + some error logging. > >> Stef >> >> >> On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote: >> >>> On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> John, >>>> >>>> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software. >>>> >>> So you prefer leaving an image in some undefined state, potentially >>> leaking system resources, >>> because of unhandled exception which nobody cares to handle? >>> At best what you can have then is, when your critical process will >>> enter an endless error-producing loop >>> is just bogging all system resources or hanging an image, without >>> giving you any idea what's going on. >>> So , if you prefer such kind of punishment for your crimes, just use >>> image prior to 1.3 and be happy :) >>> >>>> Bill >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] >>>> Sent: Monday, October 10, 2011 5:24 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >>>> >>>> The exception is not coming from my code, if it was I could trap it. >>>> Regardless, isn't shutting the VM down a bit of overkill in this case? >>>> >>>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> On 10 October 2011 23:19, John Toohey <jt(a)parspro.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>>>> and invoking the debugger in my headless images. I don't know why a >>>>>> socket timeout is considered exceptional, but I've gotten used to >>>>>> using VNC to log into the server and close the debuger windows. >>>>>> However, I've moved to COG and the latest one-click images, and now >>>>>> the error terminates the VM. >>>>>> >>>>>> My app is a standard Seaside server, using the streaming connector for >>>>>> Comet support. >>>>>> >>>>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>>>> could help me with this problem, as I'm at a loss where to even begin. >>>>>> >>>>> >>>>> So, just put an exception handler, and handle this exception in a >>>>> manner you want >>>>> and then your image will keep working! :) >>>>> >>>>>> >>>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>>>> >>>>>> >>>>>> -- >>>>>> ~JT >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> ~JT >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 11, 2011