- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WriteStream>>ensureEndsWith: removed by accident?

by Damien Cassou

On Sat, Mar 7, 2009 at 6:36 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > There is a test testEnsureEndsWith that calls this method. If the > method is removed, the test should be removed as well... IIRC, #ensureEndsWith: has been added recently to Pharo. Don't know why it has been removed -- Damien Cassou http://damiencassou.seasidehosting.st

March 8, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

It will be great. Hilaire 2009/3/7 <bryce(a)kampjes.demon.co.uk>: > Hilaire Fernandes writes: > Â > 2009/3/7 Â <bryce(a)kampjes.demon.co.uk>: > Â > > Â > > With these VMs you could load Exupery from either SqueakMap > Â > > or Universes and start it. Documentation is here: > Â > > Â > I installed exupery code in pharo 203, run the test, got 4 errors on > Â > #testBlockBug3, #testBlockNonLocalReturnRecycledContext, > Â > #testDelayWaitStreeTest, #testStressFailure1 > Â > > Â > Next I did three benchmarks on 3 different setups with DrGeo > Â > MessageTally spyOn [Carre new]. > Â > > Â > Carre new instanciate a DrGeo canvas with Smalltalk programmed figure, > Â > it results in a self-repeating sketch (see screenshot) > Â > > Â > 1. image with exupery runned with exupery VM > Â > 2. image without exupery runned with stock 3.9 VM > Â > 3. image without exupery runned with exupery VM > Â > > Â > I used exupery image Damien pointed to in his email. > Â > > Â > Do you want the images ? > > Thanks, I'd like to look at the images later but probably not > until after the next release. The decision to work on full > method inlining is a decision to not do much tuning until > after a critical optimisation is in place. > > It is possible that running Exupery can slow down code. Normally this > is because it either didn't compile something it needed to for a given > benchmark. In your case it's suspicious that it's only compiled one of > the leaf methods. It's also possible that I need to optimise something > where Exupery is slower than the interpreter, I'm not aware of any > such cases but further profiling may find some. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

March 8, 2009

Re: [Pharo-project] last win32 VM

by Michael Rueger

Schwab,Wilhelm K wrote: > Michael, > > So you are saying that rather than put the call in the VM itself, it > would go in a plugin that does the right things for the various > platforms? Is there a plugin per platform, or one that grows to > cover them all?? > > How am I doing? If I'm at all close, it sounds like a winner. There Close :-) One plugin with support for the different platforms (see locale plugin for a similar solution). The plugin could support calls like primTempDirectory, primSystemFontFolder(s), primUserDirectory etc. or other platform specific calls (can't think of one right now ;-) ). As I said, we are doing this in Sophie with FFI in Files-Locations, making Sophie a "good citizen" on each platform instead of using "C:\My Squeak" or the VM/image directory. Michael

March 8, 2009

Re: [Pharo-project] last win32 VM

by Schwab,Wilhelm K

Michael, So you are saying that rather than put the call in the VM itself, it would go in a plugin that does the right things for the various platforms? Is there a plugin per platform, or one that grows to cover them all?? How am I doing? If I'm at all close, it sounds like a winner. There are those who do not want too much reliance on FFI, and I see their point, um, to a point. The idea of being able to disable FFI from the command line is interesting from a security perspective, so a plugin seems a good way to go. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, March 07, 2009 11:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] last win32 VM Schwab,Wilhelm K wrote: > Torsten, > > It could be up to the VM if we made it that way. There is a function > call to get the system directory, and the VM can "just do that" vs. > the image needing to have access to FFI/Alien to do so. Perhaps the > other VMs could add something analogous, or just answer an empty > string, vm path, whatever if their hosts are better designed than > Windows (not that such a thing is imaginable... queue throat clearing > .wav). We could add that as part of the OSPlatform package and add a plugin returning platform specific "stuff". In Sophie we had packaged access to platform specific paths in an extra package using mostly FFI, but a plugin would be more sensible in the long run. Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 8, 2009

Re: [Pharo-project] last win32 VM

by Michael Rueger

Schwab,Wilhelm K wrote: > Torsten, > > It could be up to the VM if we made it that way. There is a function > call to get the system directory, and the VM can "just do that" vs. > the image needing to have access to FFI/Alien to do so. Perhaps the > other VMs could add something analogous, or just answer an empty > string, vm path, whatever if their hosts are better designed than > Windows (not that such a thing is imaginable... queue throat clearing > .wav). We could add that as part of the OSPlatform package and add a plugin returning platform specific "stuff". In Sophie we had packaged access to platform specific paths in an extra package using mostly FFI, but a plugin would be more sensible in the long run. Michael

March 8, 2009

Re: [Pharo-project] last win32 VM

by Schwab,Wilhelm K

Torsten, It could be up to the VM if we made it that way. There is a function call to get the system directory, and the VM can "just do that" vs. the image needing to have access to FFI/Alien to do so. Perhaps the other VMs could add something analogous, or just answer an empty string, vm path, whatever if their hosts are better designed than Windows (not that such a thing is imaginable... queue throat clearing .wav). Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Torsten Bergmann Sent: Saturday, March 07, 2009 8:29 PM To: pharo-project(a)lists.gforge.inria.fr; andreas.raab(a)gmx.de Subject: [Pharo-project] last win32 VM Sebastian Sastre wrote on pharo-project list: >I've found this weird: downloaded the vm for win32 from pharo site and is >happening that it complies about no disk in drive G: every time I open an >image. >I've press continue a couple of times and the image opens normally. I would guess it is not the newest VM, but the code in "FreeTypeFontProvider>>guessWindowsFontFolderPath" running through all drives and F: is the last mapped drive on your system. Therefore it crashes when accessing drive G: On Vista this gives you a nice Win32 Exception. Maybe the FreeType code should switch to another way to get the windows system and font folder (using Registry, Win32 API, ... - but there is no FFI by default). However, quickfix is to disable the update in FreeTypeFontProvider>>startUp: So it is not a VM issue. Bye Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 8, 2009

[Pharo-project] last win32 VM

by Torsten Bergmann

Sebastian Sastre wrote on pharo-project list: >I've found this weird: downloaded the vm for win32 from pharo site and is >happening that it complies about no disk in drive G: every time I open an >image. >I've press continue a couple of times and the image opens normally. I would guess it is not the newest VM, but the code in "FreeTypeFontProvider>>guessWindowsFontFolderPath" running through all drives and F: is the last mapped drive on your system. Therefore it crashes when accessing drive G: On Vista this gives you a nice Win32 Exception. Maybe the FreeType code should switch to another way to get the windows system and font folder (using Registry, Win32 API, ... - but there is no FFI by default). However, quickfix is to disable the update in FreeTypeFontProvider>>startUp: So it is not a VM issue. Bye Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

March 8, 2009

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

by bryce＠kampjes.demon.co.uk

Try http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux-src.tz Though if you want to help out I'm sure there's things to do. Bryce Bruce O'Neel writes: > Hi, > > Since this seems to work well for the x86 folks, Bryce, would you mind uploading > a source tarball so that others could build for other unixy system? That > would be great! > > If you could do this then I'll put my feeble attempts to build VMs on > hold since it's probably better for only one person to do this work per > platform, rather than have a confusing set of built VMs. :-) > > cheers > > bruce > > On Wed, Mar 04, 2009 at 08:39:11PM +0000, bryce(a)kampjes.demon.co.uk wrote: > > StÃ©phane Ducasse writes: > > > creating a unix vm. > > > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > > > Both have the closure bytecodes and the FreeType bitblit extensions. > > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > > > Bryce > > > > _______________________________________________ > > 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

March 7, 2009

Re: [Pharo-project] {Spam?} Re: Pharo + Exupery VM + Something else than Accuny

by bryce＠kampjes.demon.co.uk

Schwab,Wilhelm K writes: > Bryce, > > I'll play dumb here - actually, I'm not playing in this case :) > > The little I know about Exupery comes from FAQs. In the past at least, you cautioned against enabling dynamic compiling of methods, at least in production. How does that square with full-inlining? Are they different concepts, or have thing improved enough that you are now confident enough to throw the switch? Full-inlining sounds like it could consume a lot of space. Is that a concern, or does the selection of what it compiles keep it manageable? How does it decide what to compile, and (more relevant to my dumb questions) how does that differ from the dynamic compilation? > > Please don't feel attacked - I'm simply trying to understand what is hopefully just around the corner. What's changed is I've fixed a few bugs. It's possible that Exupery is reliable. I've yet done enough testing to be sure but since the last fix I haven't yet seen Exupery cause a crash. I'm confident enough to throw the switch. By full inlining all I mean is the ability to inline entire methods. Exupery will already dynamically inline the primitives it compiles to machine code. Dynamic inlining is the critical optimisation to allow further optimisations, without it the compiler can only see a method or a block at a time. It can't see where the loops are as they're probably in a different method as with #do: loops. This really limits the optimisations that can be performed later. Full inlining will be driven by profiling so it's only the hot spots that should get inlined, at least after I've tuned the profiler. Inlining can sometimes reduce the amount of code executed. For small methods it's easy to spend more code on the message send than is consumed by the method body. Initially it's likely the profiler will make bad inlining decisions like the current profiler will compile every method seen eventually which is probably bad for performance, compiling everything at least doesn't avoid compiling infrequent methods that may trigger a compiler bug. Full method inlining is a form of dynamic compilation. It lets the dynamic compiler inline entire methods when it sees the need. Bryce.

March 7, 2009

Re: [Pharo-project] Connector replacement packages for Pharo

by bryce＠kampjes.demon.co.uk

Alexandre Bergel writes: > This is trivial to achieve. I will give a try this week end. The other thing I noticed is the following script produces a messed up display. I'm not sure if this is a bug or if I'm missing something. |view| view := MOViewRenderer new. view shape: (MORectangleShape new width: 30; height: 30; text: [:t| t model printString]). view nodes: (1 to: 53). view gridLayout. view open. Without the text: attribute it produces a sensible drawing. The messed up drawing is: The examples all seem to work. Bryce

March 7, 2009