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 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

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

by bryce＠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

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. Thanks, I played around a little last night. One question, is it possible to move the nodes manually to tweak the layout? I'm currently using graphviz to layout the graph, it almost does a good enough job but often moving a few nodes around makes it much easier to follow. Mondrian looks very cleanly designed. Bryce

March 7, 2009

Re: [Pharo-project] [Vm-dev] New Window VM (Closures, FT2Plugin, Large Cursors)

by John M McIntosh

Ah, I have a bias opinion for an answer, but I'll not discuss that here. However the BIG issue for the 3.8.x and earlier series of macintosh carbon VM is their behaviour for opening a closure image. What you will find is that if you attempt to open a closure image the squeak.app will start then terminate It will print a diagnostic message to the console which you can see via Apple's Console.app found in Applications/Utilities. 07/03/09 11:11:51 AM [0x0-0x8d08d].org.squeak.Squeak[1894] This interpreter (vers. 6502) cannot read image file (vers. 6504). 07/03/09 11:11:51 AM [0x0-0x8d08d].org.squeak.Squeak[1894] Press CR to quit... The reason for this behaviour is that 15 some years back John Maloney coded up the version checking logic and there was a question what to do now. At the time CodeWarrior under os-7.5.x would helpfully put up a dialog window if you printed to the *console* and did a getchar for the answer, that code has moved forward for years now and no-one really has tested until now. Interestingly the getchar on os-x does not block and returns null and we terminate the VM, but the behaviour is confusing if you don't understand what is going on. I will at some point push out a 3.8.22 VM that should put up a more helpful dialog message, but people who have older VMs underfoot should realize this behaviour should be an indication that perhaps your VM is too old. On 7-Mar-09, at 8:12 AM, Andreas Raab wrote: > Bert Freudenberg wrote: >> John bumped the Mac VM's major version to 4 to signify closure >> support. Maybe the other platforms should follow suit? > > I figured v4 would signify the Stack VM or later as this VM will no > longer be able to run v3 images. The current set of VMs are fully > backwards compatible so I consider them logically to be v3 VMs. > > But I'm willing to reconsider if people prefer the v4 terminology. > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 7, 2009

[Pharo-project] last win32 VM

by Sebastian Sastre

hi there, 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. cheers, sebastian

March 7, 2009

[Pharo-project] Error in CollectionRootTest>>testDo2

by Adrian Lienhard

What is with this test? For Dictionary and SmallDictionary it gives an error. Please fix... Cheers, Adrian testDo2 "dc: Bad test, it assumes that a new instance of #speciesClass allows addition with #add:. This is not the case of Interval for which species is Array." | res | res := self speciesClass new. self collection do: [:each | res add: each class]. self assert: res = self result. ___________________ http://www.adrian-lienhard.ch/

March 7, 2009

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

by Adrian Lienhard

There is a test testEnsureEndsWith that calls this method. If the method is removed, the test should be removed as well... Adrian ___________________ http://www.adrian-lienhard.ch/

March 7, 2009

[Pharo-project] [update] #10248

by Adrian Lienhard

10248 ------------ Issue 628: Shortcut for "Debug it" (thanks cdrick65) Issue 633: Bring back keyboard shortcut for "case insensitive search for method strings containing it" Issue 625: "recent submissions" missing Issue 626: TestRunner showing wrong status colour when expected failures are present (thanks Julien) ___________________ http://www.adrian-lienhard.ch/

March 7, 2009