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

Re: [Pharo-project] [update 1.2] #12170

by StÃ©phane Ducasse

Thanks I will integrate it now On Oct 5, 2010, at 12:46 PM, Henrik Johansen wrote: > > On Oct 5, 2010, at 12:25 37PM, Pavel Krivanek wrote: > >> Hi, >> >> On Tue, Oct 5, 2010 at 12:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> aMethod is a selector. >> >> aMethod is a CompiledMethod or nil (when the method is deleted) >> >> -- Pavel > > Submitted new slice, this time deprecating old constructor, and using a new one passing the selector explicitly, seeing as how method (or nil) was inferred based on it in the first place. > Of course, an alternative is to just set itemSelector if method notNil, the choice simply reflects my personal preference. > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2010

Re: [Pharo-project] Soap Webservices for pharo

by StÃ©phane Ducasse

cool! > A little of progress... > > I fixed the underscores assignments, and Preferences references. > I built a first metacello configuration to download this package: > > Gofer it > squeaksource:'MetacelloRepository'; > package:'ConfigurationOfSoapOpera'; > load > > ConfigurationOfSoapOpera project lastVersion load > > It depends on ConfigurationOfKomHttpServer (Komanche). > I will enhance it in the future to make it depend in the Xml parser in XMLSupport. > > By now, in my 1.2 core image the tests are: 134 run, 121 passes, 0 expected failures, 2 failures, 11 errors, 0 unexpected passes. > > Cheers! > > 2010/10/4 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi guys, > > Nice to see that SOA Web Services in Squeak/Pharo is rolling on again. > We really need that, if we want Pharo to be useful in commercial, > specially in so called "enterprisely" world. Those who listen Andreas > ThÃ¶nne's talk on ESUG, know what I mean. > > What we really need on SOA Web Services front: > > - WSDL support, > - XML <-> Object mapping. > - Tools > > Goal should be a "one-click" use of Web Services. From both client and > server setup. As all Smalltalks support it, except Squeak/Pharo yet not. > Look at excellent VW or VA Smalltlak WebServices suport for inspiration. > > Best regards > Janko > > On 04. 10. 2010 16:21, Guillermo Polito wrote: > > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html > > > > So, we have some tasks now: > > > > - put it in squeaksource > > - test it in pharo > > - build a metacello config > > - document it? > > > > Any help is really appreciated, since I don't have too much time. > > > > Cheers, > > Guille > > > > ---------- Forwarded message ---------- > > From: *Masashi Umezawa* <umejava(a)mars.dti.ne.jp > > <mailto:umejava@mars.dti.ne.jp>> > > Date: Mon, Oct 4, 2010 at 8:46 AM > > Subject: Re: About SoapOpera and SoapCore > > To: Guillermo Polito <guillermopolito(a)gmail.com > > <mailto:guillermopolito@gmail.com>> > > > > > > Hi Guillermo, > > > > I am happy to hear that SoapOpera and SoapCore would be useful for your > > projects. Please feel free to reuse my Soap stuff. > > Recently I do not have enough time to upgrade those packages. So I > > really appreciate your offer. > > > > I hope SoapOpera and SoapCore will start growing again! > > > > Best regards, > > > > Guillermo Polito <guillermopolito(a)gmail.com > > <mailto:guillermopolito@gmail.com>> wrote: > >> Hi! > >> > >> My name's Guillermo and I'm from Argentina. I'm participating in the > > pharo > >> project (www.pharo-project.org <http://www.pharo-project.org>), and I > > would love to integrate your soap > >> package into our available packages :). > >> I was wandering if you let us put it into squeaksource > > (www.squeaksource.com <http://www.squeaksource.com>) > >> and mantain it for our use, because pharo is growing very quickly and it > >> needs this kind of really cool stuff :). Of course we will keep the MIT > >> license. > >> > >> Thank you for your time and sorry for bothering :P! > >> Guille > > > > --- > > [:masashi | ^umezawa] > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > 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

Oct. 5, 2010

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))

by StÃ©phane Ducasse

>>> >>>> Noury, >>>> >>>> One of the other aspects that I find important is elementary efficiency. >>>> >>>> A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work ! >>>> >>>> Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-) >>> >>> This is why we implemented our own SocketStream in PostgresV3. >> >> what is the license? > > It's MIT, but it's not a general purpose SocketStream. sniff

Oct. 5, 2010

Re: [Pharo-project] TextConstants

by StÃ©phane Ducasse

probably start step by step defining first the sharedPool class after after migrating silently (no ui feedback) Stef On Oct 5, 2010, at 3:46 PM, NicolÃ¡s Paez wrote: > Hi, I noticed that this PoolDictinary is not implemented like the others that are based on SharedPool. > I made some research in this the mailing list (and in Squeak), and the only explanation I found is that it is a risky and time consuming task to change the implementation of TextConstant. > > I would like to do a spike trying to implemented the change and see what I find. > > Has anyone tried to perform this change? > > Do you have any warning/suggestion? > > Regards, > > Saludos! > Nico. > blog: nicopaez.wordpress.com > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2010

Re: [Pharo-project] [update 1.2] #12170

by StÃ©phane Ducasse

On Oct 5, 2010, at 12:25 PM, Henrik Johansen wrote: > So aMethod parameter can be either CompiledMethod (method recategorization), nil (when building core), or a selector (dropping cs). > Makes total sense... :P we should really fix that this is really ugly. So we will have to fix that. > Cheers, > Henry > > On Oct 5, 2010, at 12:03 22PM, StÃ©phane Ducasse wrote: > >> aMethod is a selector. >> >> so we should change the code and like that the tests get green :). >> >> Stef >> >>> Henrik >>> >>> when I drop a cs I get a DNU. >>> No time to check now. >>> >>> Stef >>> On Oct 5, 2010, at 11:51 AM, StÃ©phane Ducasse wrote: >>> >>>>> >>>>> >>>>> From: stephane ducasse <stephane.ducasse(a)gmail.com> >>>>> Date: October 5, 2010 11:43:17 AM GMT+02:00 >>>>> To: An open mailing list to discuss any topics related to an open-source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> >>>>> Subject: [update 1.2] #12170 >>>>> >>>>> >>>>> >>>>> 12170 >>>>> ----- >>>>> >>>>> - Issue 3060: Update Monticello to detect method recategorization correctly. Thanks Pavel Krivanek and Henrik Johanssen >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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

Oct. 5, 2010

Re: [Pharo-project] UUID and Cog?

by laurent laffont

On Tue, Oct 5, 2010 at 5:22 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 05.10.2010 16:41, David T. Lewis wrote: > > If anyone has any specific information as to the root cause of the > libuuid > > bug, I'd appreciate if you can update the bug report here: > > > > http://bugs.squeak.org/view.php?id=7358 > > > > I had previously tried to summarize as follows: > > > >> The bug exists in some versions of libuuid on some Linux distributions. > >> The workaround is to compile the plugin internal. The latest versions > >> of Unix VM have the plugin compiled internally, although some users may > >> still experience problems if they have a leftover external plugin from > >> a prior installation. > > > > But it's not clear if this is accurate given the recent reports here. > > In particular, if a precompiled Cog VM with the UUID plugin compiled > > internally leads to a crash, then the above is not a sufficient > > workaround (at least not on Cog). > > > > If we are seeing crashes on Cog with an internal UUID plugin, but > > not on the traditional VM with an internal UUID plugin, then I think > > I smell a pthread related issue. > > How can I find out whether the plugin is compiled internally or not? > > See http://book.pharo-project.org/book/Virtual-Machine/VMPlugins/LoadingOfVMPlu… To list the plugins built in the VM (internals), evaluate: SmalltalkImage current listBuiltinModules Laurent > What I see in the console is the following: > > Segmentation fault > > > > Smalltalk stack dump: > 0xff79f344 M UUID>initialize -1045926312: a(n) UUID > 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class > 0xff79f380 I UUID class>new -1246728604: a(n) UUID class > > ... > > Most recent primitives > ... > withArgs:executeMethod: > basicNew: > primMakeUUID > > Is there a way to provide more information? > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 5, 2010

Re: [Pharo-project] UUID and Cog?

by Philippe Marschall

On 05.10.2010 16:41, David T. Lewis wrote: > If anyone has any specific information as to the root cause of the libuuid > bug, I'd appreciate if you can update the bug report here: > > http://bugs.squeak.org/view.php?id=7358 > > I had previously tried to summarize as follows: > >> The bug exists in some versions of libuuid on some Linux distributions. >> The workaround is to compile the plugin internal. The latest versions >> of Unix VM have the plugin compiled internally, although some users may >> still experience problems if they have a leftover external plugin from >> a prior installation. > > But it's not clear if this is accurate given the recent reports here. > In particular, if a precompiled Cog VM with the UUID plugin compiled > internally leads to a crash, then the above is not a sufficient > workaround (at least not on Cog). > > If we are seeing crashes on Cog with an internal UUID plugin, but > not on the traditional VM with an internal UUID plugin, then I think > I smell a pthread related issue. How can I find out whether the plugin is compiled internally or not? What I see in the console is the following: Segmentation fault Smalltalk stack dump: 0xff79f344 M UUID>initialize -1045926312: a(n) UUID 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class 0xff79f380 I UUID class>new -1246728604: a(n) UUID class ... Most recent primitives ... withArgs:executeMethod: basicNew: primMakeUUID Is there a way to provide more information? Cheers Philippe

Oct. 5, 2010

Re: [Pharo-project] UUID and Cog?

by David T. Lewis

If anyone has any specific information as to the root cause of the libuuid bug, I'd appreciate if you can update the bug report here: http://bugs.squeak.org/view.php?id=7358 I had previously tried to summarize as follows: > The bug exists in some versions of libuuid on some Linux distributions. > The workaround is to compile the plugin internal. The latest versions > of Unix VM have the plugin compiled internally, although some users may > still experience problems if they have a leftover external plugin from > a prior installation. But it's not clear if this is accurate given the recent reports here. In particular, if a precompiled Cog VM with the UUID plugin compiled internally leads to a crash, then the above is not a sufficient workaround (at least not on Cog). If we are seeing crashes on Cog with an internal UUID plugin, but not on the traditional VM with an internal UUID plugin, then I think I smell a pthread related issue. Thanks, Dave On Tue, Oct 05, 2010 at 02:13:46PM +0200, Levente Uzonyi wrote: > On Tue, 5 Oct 2010, Philippe Marschall wrote: > > >Hi > > > >Does anybody know whether UUIDs are supposed to work on Cog on Linux? I > >got the latest prebuilt Cog from [1] and UUID new crashes my VM with a > >seg fault on a Monticello commit. I believe it was working before I > >updated some Linux packages. > > Just rebuild the VM on your Linux, that should work. > > > Levente > > > > >[1] http://www.mirandabanda.org/files/Cog/VM/VM.r2316/ > > > >Cheers > >Philippe > >

Oct. 5, 2010

Re: [Pharo-project] FastCGI support in Pharo

by Philippe Marschall

On 05.10.2010 14:58, Dario Trussardi wrote: > Hi, > > i have a Lighttpd server with FastCGI support for deployment system ( based on GLASS ). > > Now i'm interested to work with the same web server for development system based on Pharo. > > For now in Pharo i use the WAKom interface. > > I can load the FastCGI support into Pharo ? Loading the the GemStone FastCGI package is unlikely to work. You can try to load the Squeak FastCGI package [1] but that seems to have some underscore assignments. [1] http://www.squeaksource.com/FCGI.html Cheers Philippe

Oct. 5, 2010

[Pharo-project] TextConstants

by NicolÃ¡s Paez

Hi, I noticed that this PoolDictinary is not implemented like the others that are based on SharedPool. I made some research in this the mailing list (and in Squeak), and the only explanation I found is that it is a risky and time consuming task to change the implementation of TextConstant. I would like to do a spike trying to implemented the change and see what I find. Has anyone tried to perform this change? Do you have any warning/suggestion? Regards, Saludos! Nico. blog: nicopaez.wordpress.com

Oct. 5, 2010