March 2009 - Pharo-dev - lists.pharo.org

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

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

by Keith Hodges

Michael Roberts wrote: > Keith, your email implies that you believe Pharo should be backwards > compatible at some level with Squeak. Part of the Pharo manifesto is > not to be compatible. So if you want to write code or have apis that > work in a backwards direction from Pharo to Squeak, that's great. I > don't believe it's a goal for Pharo though. The pharo process doesn't > need a rethink at all as far as I'm concerned. > > thanks, > > Mike > No that is not what I am saying at all. Perhaps examples would help. Take Rio. Rio was designed from ground up to be a replacement for a the present non-modular kernel facility FileDirectory. It is a discrete loadable module. Wild and horrible uses of FileDirectory are spread around the image in lots of places, so one thing that Rio tries to do is to anticipate use cases, so that the users of Rio dont have to implement File handling code in their stuff, and so we help to keep the module boundary clear. For example you can ask Rio to get you the next version of a file - 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in itself potentially lightens SmalltalkImage. If you want to read Xml files, you can subclass File, with FileXML, define the #validExtensions that it handles, and implement contents/contents: This means that your code only needs to send, 'myfile.xml' asFile contents, to get the model. There are all sorts of things like that. With Rio as a front end to File and Socket streams it is perfectly possible to innovate on them without users of Rio being any the wiser. If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' asFile contents, now means that I dont have to care about whether HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or HTTPClient returning a MultiByteStream thingy in 3.8 or some other new facility. So, Rio demonstrates that it is possible to innovate, on a kernel module, and you dont need to break anything to do it. Secondly by thinking about APIs and module interface abstractions in this way, you can define specific interfaces and bottlenecks, that potentially turn the ball of tangled string into something designed and architected. There are perhaps hundreds of other modules that could use the same treatment. Rio loads into all squeak images I have tried it in, so this then means that any of my file handling code will work in all images. This benefit comes from managing Rio as module external to the main image. Rio also comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in mind. Having done this, the question of moving the kernel over to make use of the new code arises, this also can be achieved without breaking anything for users that have had Rio available for 2 years in every image that their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, Magma, Etoys, can all migrate their file handling code to the new Rio API now, even if they are using Squeak 3.7/3.8, without having to upgrade to the latest squeak. When they do update, they will be pleased to find that their file handling code works, as well as their gzipping/archiving/remote file handling/and website accessing code. Installer follows the same principles, abstracting an api, freeing the backend to be either old code or new code. If you dont have Universes loaded, then defining Installer>>#universes to call #sake as a fall back would use Sake/Packages and get identical results, your users would be none the wiser. If you dont have SqueakMap loaded, then defining Installer>>#squeakmap to call #websqueakmap instead, would again give your users identical results. and you thought that Installer was just for loading things. Edgar has pointed out that you could use CodeLoader for that, but thats not the point of installer, Installer is providing a DSL for loading things that provides an architectural layer of isolation, and thus both inherrent forward and backward compatibility. I expect my image building scripts to work identically with Monticello2 in squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7. Scripter (who here even knows that Scripter exists?) does the same, if you want to write code to close or tile all the windows, after the installing process has left a mess. Scripter can be the interface to whatever backend GUI there happens to be whether it is ToolBuilder/Tweak/Morphic. Same again with Logging, is a front end abstraction to all of the three+ logging backends out there. I can remove the hardwired calls to Transcript that scatter the image and replace them with a single api to multiple backends, both past (Transcript) present (Syslog) and future (seaside per-user session logging framework). Oh, and again with Sake/Packages.... why does Sake/Packages define class tasks? You can write a task that depends upon a task which removes certain method selectors. You could just call Behaviour direct. Its another architectural layer, that frees up the back end to be old or new code as far as Sake task writers are concerned. I can write a task that says, "if you find this Class with a method categorised as so, then it needs to be recategorised as such", in such a way as this task would run in all images. Oh and again SystemEditor... another layer of abstraction for compiling and loading code atomically. So if you think about it, those who know about the compiler could be considering how to write their stuff, so that it logs to the Kernel Logging API (which is valid even if Logging isnt Loaded). They might consider connecting to SystemEditor in preference to providing a direct api, and another abstracted pluggable Module is needed to handle source code files (replacing RemoteString/ChangeSets etc), with Rio as the local/remote file API. Do you get the idea now? For the same treatment to be available for more significant chunks of squeak, we would need atomic loading to work. Now the code to provide atomic loading for everyone has been available for over a year, and it works if you dont use traits. So where is the expertise to really get it working for everyone with traits? The only difficulty with this approach is that you might need slightly different bits to make your NEW code load into older images. This problem is reasonably easily addressed with Installer-Scripts (LevelPlayingField+) and Sake/Packages. I fully agree with Matthew about core packages like Collections. BUT and this is the big but. If you are going to do that kind of thing, you need to think about it, plan it, and create and participate in a process that supports everyone is diverse images using and testing that package. From what I have seen there is only one person on the Pharo team that understands what LevelPlayingField is for, and how to use it. The biggest risk to this approach is if some other folks decide to fork some significant architectural component in a completely incompatible manner, without thinking about any bigger picture at all. Matthew's comment about how our tools are only just getting there isnt that relevant to the point that I am making. I didnt need a test and 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. cheers Keith

March 3, 2009

Re: [Pharo-project] VMs and Closures

by John M McIntosh

My todo list says I need to build a macintosh carbon VM with closure today sometime before midnight... I note it will be a 4.0.0 VM On 2-Mar-09, at 2:37 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > > I've built both a Linux and Windows VM with the latest closure > bytecodes. They'll both be available in the next few days. > > Both have the FreeType bitblit changes but I didn't build the FreeType > plugin for Windows. Building the FreeType dev libraries will wait > until next time. > > What's going on with closure support? > > Bryce > > P.S. Yes, this means I'm preparing for an Exupery release > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 2, 2009

Re: [Pharo-project] Universes question

by Rob Rothwell

I noticed the same thing yesterday, but forgot to say anything. It was there in 10236-dev under World->Tools->More, but seems to have been missing since 10243... Rob On Mon, Mar 2, 2009 at 1:57 PM, Brian Brown <brian(a)ablelinktech.com> wrote: > Hello all, > > I just downloaded pharo0.1-10243dev09.02.3 from the website and > updated to the latest. I expected to see the Universe browser in the > menus, but it isn't there, So I checked the image, and Universes is > not there. > > I thought the Universes code was in the dev image.... what am I missing? > > > Regards, > > - Brian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 2, 2009

Re: [Pharo-project] MIMEDocument issue

by Michael Rueger

Brian Brown wrote: > On Mar 2, 2009, at 3:56 PM, Brian Brown wrote: > >> Not explicitly, it was loaded as part of another script. Should I >> load the latest from squeak source? No, the fix is not in there yet. You need the one from the PharoInbox, it's still work in progress. As a quick fix you should be able to revert the mimeType method. Michael

March 2, 2009

Re: [Pharo-project] MIMEDocument issue

by Brian Brown

On Mar 2, 2009, at 3:56 PM, Brian Brown wrote: > Not explicitly, it was loaded as part of another script. Should I > load the latest from squeak source? > > > On Mar 2, 2009, at 3:52 PM, Michael Rueger wrote: > >> Brian Brown wrote: >>> Here is some nice recursion that kills my pharo image.... (updated >>> to 10246) >>> >>> Here are three MIMEDocument methods: >>> >>> >>> mimeType >>> >>> ^self type >> >> that is definitely wrong. >> Did you load the KomHTTP package? Small update - the KomHttpServer I have in my image is gc.42 >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Brian Brown > CTO > AbleLink Technologies, Inc. > http://www.ablelinktech.com > > > Brian Brown CTO AbleLink Technologies, Inc. http://www.ablelinktech.com

March 2, 2009

Re: [Pharo-project] MIMEDocument issue

by Brian Brown

Not explicitly, it was loaded as part of another script. Should I load the latest from squeak source? On Mar 2, 2009, at 3:52 PM, Michael Rueger wrote: > Brian Brown wrote: >> Here is some nice recursion that kills my pharo image.... (updated >> to 10246) >> >> Here are three MIMEDocument methods: >> >> >> mimeType >> >> ^self type > > that is definitely wrong. > Did you load the KomHTTP package? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Brian Brown CTO AbleLink Technologies, Inc. http://www.ablelinktech.com

March 2, 2009

Re: [Pharo-project] MIMEDocument issue

by Michael Rueger

Brian Brown wrote: > Here is some nice recursion that kills my pharo image.... (updated > to 10246) > > Here are three MIMEDocument methods: > > > mimeType > > ^self type that is definitely wrong. Did you load the KomHTTP package? Michael

March 2, 2009