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

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Eliot Miranda

Hi Joachim, On Wed, Jan 5, 2011 at 9:22 AM, Joachim Geidel <joachim.geidel(a)onlinehome.de > wrote: > > Hi everybody, > > I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo > and Squeak. Almost everything works on both Mac OS X and Windows with one > exception. I can attach a Java VM to Pharo/Squeak, I can send messages to > Java objects and get results back, and even callbacks from Java to > Smalltalk > seem to work. > > The exception is that a callback from Java to Smalltalk which comes from a > different thread leads to a crash of the Squeak VM. I have not been able to > figure out what the problem is. There is a similar problem with a hook of > the Java VM: one can register a callback function which is called whenever > the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS > X, > using this hook works when the hook contains a "nil halt", and if I simply > proceed in each of the notifiers. When I remove the halt or replace it by a > Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is > different: the VM crashes. > > Does Alien support callbacks coming from a "foreign" thread? Or is this a > limitation of Alien? > That current version of Alien does /not/ support callbacks from foreign threads. I have a prototype that does support callbacks from foreign threasds and supports non-blocking callouts on arbitrary threads. Essentially the VM shares the VM between native threads such that only one thread can be running Smalltalk at any one time but that any number of natie thresds can share the VM. I demonstrated this to various people in ConcepcÃon during Smalltalks 2010. Are you interested in working with this prototype code? Pleaze let me know either way. I haven't sought permission to release this code yet but I would very much like to. I think there's value to Teleplace in my releasing it before we release it internally because it needs pounding on to bring up to production quality. If there's significant interest in this code I'll ask for permission to release it and see where we go from there. > Thanks in advance for any help, > Joachim Geidel > > -- > View this message in context: > http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p31… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Schwab,Wilhelm K

Not really an answer to your question, but Dale Rogerson's Inside COM is an excellent book (a must-have on its own) that might help with such topics. I suspect what Alien will need to do is something similar to Apartment Threading - maybe it already does. It has (thankfully??) been a long time, but I vaguely recall mutterings about sequencing calls through the message queue, and even marshaling data and interface pointers across thread boundaries. Maybe Hydra holds some helpful answers?? If you have truly free threaded Java, it would probably be possible to get into situations where an Apartment threaded server would deadlock due to the synchronization of calls - I know enough to ask the question but not enough to answer it. I await an interesting discussion among the experts. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Joachim Geidel [joachim.geidel(a)onlinehome.de] Sent: Wednesday, January 05, 2011 12:22 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Alien and callbacks from "foreign" threads? Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

[Pharo-project] Alien and callbacks from "foreign" threads?

by Joachim Geidel

Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by nullPointer

CLFramework continues in develop but donÂ´t the subset UIBuilder. For the change of window styles I didnÂ´t almost update UIBuilder. Regards. -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175983.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages

by Sven Van Caekenberghe

On 05 Jan 2011, at 16:34, CÃ©drick BÃ©ler wrote: > Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. You could also have a look at Iliad or Aida which I think are less memory hungry than seaside (but to me, nothing beats pure html anyway with a fake dynamic impression ;) ). If you only need to build a couple of very simple HTML pages (say like for some embedded device) you could use Zn. It is very lightweight, both in the number of classes and in its dependencies. However, Seaside offers an enormeous amount of functionality that you will miss. You will have to generate HTML by hand for example. Sven

Jan. 5, 2011

Re: [Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement

by Igor Stasenko

On 5 January 2011 16:25, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi there, > > While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). > > But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. > > I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. > Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? hmm.. the existence if separate class for each of xml elements doesn't automatically means that it can validate a SOAP document that it is well formed, isn't? > Or would you avoid to subclass ? > > Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) > As to me, i'd better leave the xml domain as soon as possible by validating it and then parsing its elements into something, which is reification of actual SOAP query/response model , without trying to resemble an xml dom tree. > Thanks in advance, > > CÃ©drick > > [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ > > -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages

by CÃ©drick BÃ©ler

it depends what you call dynamic pages :) Personally, I'm in the way to develop a seaside app that will manage "customers" and whose main goal is to generate pure static html pages (which can be changed from the user interface - change mean modified where it's possible and interesting then generated again). Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. You could also have a look at Iliad or Aida which I think are less memory hungry than seaside (but to me, nothing beats pure html anyway with a fake dynamic impression ;) ). My 0.02c, > > > Begin forwarded message: > >> From: Annick Fron <info(a)afceurope.com> >> Date: January 5, 2011 12:43:53 PM GMT+01:00 >> To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> >> Subject: [Pharo-users] Smalltalk server pages >> Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> >> >> Hi, >> >> and in order to get a minimum of dynamic pages, (I think Seaside will be too large for my memory) what is best to get simple Smalltalk server pages, swazoo or Komhttpserver ? >> >> Annick Fron > >

Jan. 5, 2011

[Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement

by CÃ©drick BÃ©ler

Hi there, While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? Or would you avoid to subclass ? Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) Thanks in advance, CÃ©drick [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/

Jan. 5, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #11 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 The problem is that it clearly does nothing at all to improve readability and usability, as long as there is no consistent and complete interface. Without a complete interface redesign, this simply is no improvement.

Jan. 5, 2011

Re: [Pharo-project] IRC meeting next Tuesday, January 4, at ...?

by Alexandre Bergel

+1 Alexandre On 4 Jan 2011, at 19:10, laurent laffont wrote: > On Tue, Jan 4, 2011 at 10:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > argh I totally missed my alarm clock on my machine (while cleaning the house :) > So did people discuss? > May be we should redo a clear call. > > +1 > > > Laurent. > > > > Stef > > On Jan 3, 2011, at 9:46 PM, Adrian Lienhard wrote: > > > I just figured that I also can't make it tomorrow at 20:00 (I can be online 2 hours later, though). > > > > Anyway, I suggest that everybody who is interested to discuss and sync meets at 20:00 and it would be nice if somebody could write a short summary, which we can post to the mailing list and the website. > > > > BTW, the channel is #pharo-project on irc.freenode.net. If you don't have an IRC client you can browse to > > > > http://webchat.freenode.net/?channels=pharo-project > > > > Time: http://www.timeanddate.com/counters/customcounter.html?day=4&month=1&year=2… > > > > Cheers, > > Adrian > > > > > > > > On Jan 3, 2011, at 09:15 , StÃ©phane Ducasse wrote: > > > >> Thanks for the call adrian. I will be travelling until 16h (it was not planned when I proposed that dat) but there is no problem, > >> Stef > >> On Jan 2, 2011, at 10:34 PM, Adrian Lienhard wrote: > >> > >>> Hi all, > >>> > >>> During the last meeting [1] we decided to do the next one on January 4 but we didn't decide when to start. > >>> > >>> The previous meeting started at 20:00 CET/UTC/GMT+1, which may not be optimal for people in other time zones. If somebody likes to suggest another time, please let us know soon! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> [1] http://pharo-project.org/news?article=irc-meeting-notes > >> > >> > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 5, 2011