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

[Pharo-project] socket.io

by Herby VojÄÃk

Is there / planning a socket.io (server) support in Pharo? I am making suite of client-server application where I strongly consider socket.io as the communication layer; there is no problem with clients, but at the server-side, socket.io seems only to be supported by its native node.js (which is not bad, but I'd like to consider Smalltalks as well, Pharo being the first choice). Thanx, Herby -- View this message in context: http://forum.world.st/socket-io-tp3890522p3890522.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Mariano Martinez Peck

On Mon, Oct 10, 2011 at 3:58 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > > My first impression: > > - a cross-breeding of C and .... C and a bit of C.. and then C on top. > > > > And i bet it is implemented in C > > :D > > You mean C#, of course. C#, with a side order of share-nothing message > passing concurrency. C# on the whole isn't a bad language: it's way > better than Java (which isn't, admittedly, exactly a high bar). > > But still, Dart seems like nothing to write home about. > > Note one sneaky thing: using an image as means of deployment: > http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart > comes with tools to create an image of the heap of an application and > package it into an optimized format which can be loaded nearly > instantly, reminiscient of Smalltalk's image system." > > A couple of hours ago, I have asked this: https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/fd… > Funny, given the number of arguments Smalltalkers have with people > over the use of images. > > frank > > > On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, > >> > >> Google published the first information about Dart: > >> http://www.dartlang.org/ > >> > >> Cheers, > >> -- Pavel > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Frank Shearar

On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > My first impression: > Â - a cross-breeding of C and .... C and a bit of C.. and then C on top. > > And i bet it is implemented in C > :D You mean C#, of course. C#, with a side order of share-nothing message passing concurrency. C# on the whole isn't a bad language: it's way better than Java (which isn't, admittedly, exactly a high bar). But still, Dart seems like nothing to write home about. Note one sneaky thing: using an image as means of deployment: http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart comes with tools to create an image of the heap of an application and package it into an optimized format which can be loaded nearly instantly, reminiscient of Smalltalk's image system." Funny, given the number of arguments Smalltalkers have with people over the use of images. frank > On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> Google published the first information about Dart: >> http://www.dartlang.org/ >> >> Cheers, >> -- Pavel >> >> > > > > -- > Best regards, > Igor Stasenko. > >

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Igor Stasenko

My first impression: - a cross-breeding of C and .... C and a bit of C.. and then C on top. And i bet it is implemented in C :D On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Google published the first information about Dart: > http://www.dartlang.org/ > > Cheers, > -- Pavel > > -- Best regards, Igor Stasenko.

Oct. 10, 2011

[Pharo-project] Remove/deprecate String adaptation?

by Henrik Sperre Johansen

Could we please remove, or at least deprecate the String>> #adaptTo*: andSend: protocol? Made me question my sanity a bit when I forgot some parenthesis, and 0.1 + 0.2 storeString didn't raise any errors, nor returned the string like I'd intended it to... Cheers, Henry

Oct. 10, 2011

Re: [Pharo-project] Mailinglit Archive not working

by Davide Varvello

It's down again: 2.53 pm CET Davide Marcus Denker-4 wrote: > > > gforge.inria.fr was down as a whole, its working again now. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > -- View this message in context: http://forum.world.st/Mailinglit-Archive-not-working-tp3889580p3890124.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 10, 2011

[Pharo-project] OT: Dart

by Pavel Krivanek

Hi, Google published the first information about Dart: http://www.dartlang.org/ Cheers, -- Pavel

Oct. 10, 2011

Re: [Pharo-project] Fwd: completion appears in the wrong place

by Igor Stasenko

On 10 October 2011 14:25, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 10 October 2011 09:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Any ideas? :) >> Doru > > Have one. > A PluggableTextMorph (and text morphs in general) using 0-based coordinates > in their bounds. > But they are usually wrapped by scroll pane / transform morph which doing > local/global coordinate transformation for submorphs, > therefore a submorphs positions could be in non-global coordinate system. > You can see #boundInWorld implementation and follow it, to see how to obtain global coordinates from local ones. > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Oct. 10, 2011

Re: [Pharo-project] Fwd: completion appears in the wrong place

by Igor Stasenko

On 10 October 2011 09:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Any ideas? :) > > Doru > Have one. A PluggableTextMorph (and text morphs in general) using 0-based coordinates in their bounds. But they are usually wrapped by scroll pane / transform morph which doing local/global coordinate transformation for submorphs, therefore a submorphs positions could be in non-global coordinate system. -- Best regards, Igor Stasenko.

Oct. 10, 2011

Re: [Pharo-project] Destruction of object in Pharo/Smalltalk - When I clean resources?

by Henrik Sperre Johansen

On 08.10.2011 11:36, nullPointer wrote: > I have a complexe object with many internally events references. I want know > what is the best place where I have put the code for clean that resources > when the object is cleaned for Garbage collector. I have fear that > references never out, and still throwing notifiers. > > Regards, and thanks for the help. > > -- > View this message in context: http://forum.world.st/Destruction-of-object-in-Pharo-Smalltalk-When-I-clean… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > How to deal with it differs: - Do you need strong guarantees that the "gone" object does not receive announcements after your last reference to it is gone? If no, don't use action blocks(1), and rely on the weak cleanup that the event systems do (2). If yes, is there a point where you can umbiquously determine whether the last reference is gone? If yes, either unsubscribe from source at this point, or prepare the object for unsubscription(3). If no, it's probably best to change your code. I can't think of a way to do it in a couple of minutes, and suspect whatever solution one might come up with will be intricate and hard to understand. (1) The block itself will usually contain a strong reference to the receiver and thus finalization will never kick in. So you will have to clean it manually if using blocks(4) (2) Events (notified with #triggerEvent:, registered with #when:send:to:) are weak by default. Announcements are strong by default, you make weak subscriptions by (fast) sending #weak to the announcer before registering: anAnnouncer weak on: Announcement send: #handleThis: to: self or (compatible) makeWeak to the AnnouncementSubscription returned by #on:send:to: (anAnnouncer on: Announcement send: #handleThis: to: self) makeWeak (3) With announcements you don't need a strong reference to the announcer, just a way to check whether it's valid. Then, in your action, you can do: anAnnouncer on: Announcement do: [:ann : announcer | self shouldReceive ifFalse: [^announcer unsubscribe: self]. self normalHandlingOf: ann] (4) This is what ephemerons will help for, it will allow us to write handlers like: anAnnouncer weak on: Announcement do: [:ann | myInstvar := ann foo + ann bar] and still have them cleaned by finalization. Cheers, Henry

Oct. 10, 2011