- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Tudor Girba

Hi, I am not sure I got the summary of the discussion related to the problem of deploying a Pharo-based image to seasidehosting. Is there any conclusion? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

March 3, 2009

[Pharo-project] Unicode test II

by Michael Rueger

Hi all, after some interesting adventures in Unicode land here's a second version of the unicode test image/app: http://impara.de/~michael/unicode-test.zip Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far) Mostly untested: - unicode filename handling Known not to work: - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. That would take another major refactoring of handling shortcuts. Once I know this version works reasonable well I'll package everything up for inclusion in the updates. Right now it is pretty much a mess. Happy testing Michael

March 3, 2009

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

by Michael Rueger

GÃ¶ran Krampe wrote: > Hi! > > What about perhaps looking at what has already been done, like: > > http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f > http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 I used and adapted the second one IIRC. For reasons that I can't recall right now I liked it better :-) Michael

March 3, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Igor Stasenko a Ã©crit : > Looks nice (especially integration with notifications). > > Just a single straw hat man question: > > - how you dealing with a preferences which declared multiple times > under the same name: > > MyAlphaClass class>>enabled > <preference: 'enabled' type: #Boolean set: #setEnabled: default: > #false description: 'Alpha thingy enabled'> > > MyBetaClass class>>enabled > <preference: 'enabled' type: #Boolean set: #setEnabled: default: > #false description: 'Beta thingy enabled'> > Hi Igor, When a pragma is collected, the name of the class in wich the pragma is defined is available. > it also seem would be nice to have a preference category name(s) > yes, it will be added. thanks for your remarks. alain > > 2009/3/2 Alain Plantec <alain.plantec(a)free.fr>: > >> Matthew Fulmer a Ã©crit : >> >>> Did anybody ever notice my suggestion to use Magritte for >>> Preferences? >>> >>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.h… >>> >>> >>> >> Hi Matthew, >> one should have answer something to you. sorry. >> First I know what magritte is but I've never tried it so I can't give an >> opinion if it is desirable, possible... >> But magritte is not a part of Pharo-core. Is it planned to include it ? >> What I'm trying to do (with a big help from Gary) is to implement a >> proposition so people can >> make their own opinion and say if it is ok or not. >> I will post a new one soon (I hope), maybe you can have a look and >> propose something with Magritte. >> Cheers >> alain >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > >

March 3, 2009

[Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by John M McIntosh

Yes it compiles, yes after a bit of poking I could take a Squeak3.9- final-7067.image and build a closure aware image. No I could not do that without poking a bit, however I hope that we'll resolve the problems in a day or two. Yes, I could take a Pharo0.1Core-10243.image and after more poking could generate a closure aware Pharo image. At this time the 4.0.0b1 VM is not publicly available, another day or two of cross checking is required, I've asked the Pharo team to review my changes and the changes from Eliot. I've also asked Eliot to supply some fixes so we can recompile the Squeak3.9-final-7067 image without problems. I cannot speak for the 3.10 or 3.11 images, other parties will need to pursue any work to make them closure aware. Tomorrow I'll poke at making the iPhone VM closure aware, however any iPhone image relies on the Pharo team resolving what the change sets should be to make the image closure aware. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 3, 2009

[Pharo-project] System Updates

by Rob Rothwell

Hi all, Occasionally (stupid, I know), I just go back to the current clean image and make sure everything works ok with updates, etc... Maybe I missed this, but a base 10243 is not updating anymore (see attached), but an older image I had updated to 10244 updated just fine. Rob

March 3, 2009

Re: [Pharo-project] [squeak-dev] Re: A point a.k.a excuse to you

by Michael Rueger

Keith Hodges wrote: > So... would anyone out there be willing to rewrite HTTPSocket/Client > from scratch so that it is well designed and so on from the ground up? > Assuming that Socket will remain common between Squeak/Pharo etc, it > could also provide an abstraction onto the Curl plugin as well. This new > module would of course be for the benefit of all. There are at least two clean implementations of a full HTTPClient out there. I adapted one of them to my URI and MIME packages, next on my list to make it work on Pharo. I don't remember right now who did the original implementation, need to look that up to give due credit. Michael

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

Schwab,Wilhelm K wrote: > I suggest making the socket as pluggable as possible, because I suspect we will see SSL sooner rather than later. Call it a hunch. Another thing that I would like to see is #readStream and #writeStream to lazily initialize appropriate streams on sockets. Dolphin has had that for a long time, and it works very nicely. > > Bill > > what does that give you? Keith

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Schwab,Wilhelm K

I suggest making the socket as pluggable as possible, because I suspect we will see SSL sooner rather than later. Call it a hunch. Another thing that I would like to see is #readStream and #writeStream to lazily initialize appropriate streams on sockets. Dolphin has had that for a long time, and it works very nicely. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Monday, March 02, 2009 9:17 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] A point a.k.a excuse to you > build server to innovate Rio for everyone rather than just for the image > I am using (trouble was I was using 3 different images), all I needed > was an inclusive attitude rather than an exclusive attitude. > Dear All, I was trying to implement FileHttpExecutive in Rio today, I wanted to perform a GET, and have Rio informed of the File size as soon as the headers have been downloaded. As an alternative it would also be nice to be able to send a HEAD request prior to getting the whole file. I also want to read the stream as it is coming in, since Rio already can buffer ftp reads direct to a file, or other destination. About 5 minutes looking at the code showed me that this was pretty impossible. There was no clean way to subclass HTTPSocket and have it hold a handle on my file instance and report that information to me, since most of the business is performed on the class side (why do people do that?) My only option is probably to subclass HTTPSocket, inserting some Notifications in there, and use exception handlers to collect the data. So... would anyone out there be willing to rewrite HTTPSocket/Client from scratch so that it is well designed and so on from the ground up? Assuming that Socket will remain common between Squeak/Pharo etc, it could also provide an abstraction onto the Curl plugin as well. This new module would of course be for the benefit of all. Has anyone done/is anyone doing this already? thanks in advance Keith _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

> build server to innovate Rio for everyone rather than just for the image > I am using (trouble was I was using 3 different images), all I needed > was an inclusive attitude rather than an exclusive attitude. > Dear All, I was trying to implement FileHttpExecutive in Rio today, I wanted to perform a GET, and have Rio informed of the File size as soon as the headers have been downloaded. As an alternative it would also be nice to be able to send a HEAD request prior to getting the whole file. I also want to read the stream as it is coming in, since Rio already can buffer ftp reads direct to a file, or other destination. About 5 minutes looking at the code showed me that this was pretty impossible. There was no clean way to subclass HTTPSocket and have it hold a handle on my file instance and report that information to me, since most of the business is performed on the class side (why do people do that?) My only option is probably to subclass HTTPSocket, inserting some Notifications in there, and use exception handlers to collect the data. So... would anyone out there be willing to rewrite HTTPSocket/Client from scratch so that it is well designed and so on from the ground up? Assuming that Socket will remain common between Squeak/Pharo etc, it could also provide an abstraction onto the Curl plugin as well. This new module would of course be for the benefit of all. Has anyone done/is anyone doing this already? thanks in advance Keith

March 3, 2009