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

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

by Bruce O'Neel

Hi, Thanks. I'll look into it in the next day or two. I'm happy to help since, for selfish reasons if no other, I want Pharo to work well on Linux, and, non x86 linuices as well. I just don't think it makes sense to have multiple people running VMMaker to do the same thing. Also I don't think Squeak/Pharo/etc is helped by having multiple VMs per platform, since that's almost a 100% guarantee that we'll be constantly answering with: "No, to work with the foo 9.4.2.1 image you need the bar VM 7.2.4.4. But for the foo 9.4.2.2 image you need the bar VM 7.7.4.8.1. Yea, you want the one built by Joe because Frank insists on using his custom patched compiler that works for no-one else. Oh, you want to run the baz 5.6.2 image at the same time? Ah, that doesn't work, and, your suffix mapping will have to change every time." Thanks again! cheers bruce On Sat, Mar 07, 2009 at 10:28:50PM +0000, bryce(a)kampjes.demon.co.uk wrote: > 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 > > _______________________________________________ > 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] Connector replacement packages for Pharo

by Alexandre Bergel

With the last version of Mondrian, I have I will dive into it this evening. I would have expected each number to be surrounded by a box. Cheers, Alexandre On 7 Mar 2009, at 22:26, <bryce(a)kampjes.demon.co.uk> wrote: > 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: > > <mondrian.jpg> > > The examples all seem to work. > > Bryce_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 8, 2009

[Pharo-project] FreeType font problem

by Damien Cassou

Hi, I'm playing with the Exupery VM on Pharo. If I change the font to something else than Accuny, the underlined texts are not underlined anymore. To reproduce: - download and use http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz - go to preferences->fonts->list fonts - select Bistream Charter/regular/10, and apply - open monticello and open the Pharo repository You will see that the installed packages are not underlined anymore. Switch back to Accuny to see them underlined. Does any of you have the same problem? -- Damien Cassou http://damiencassou.seasidehosting.st

March 8, 2009

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