September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ANN - Pre-compiled Pharo VM for Debian Stable

by Bernardo Ezequiel Contreras

THANK YOU VERY MUCH! I really needed it. On Sun, Sep 28, 2014 at 7:17 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi there, > > Getting Pharo 2.0/3.0 up and running on Debian Wheezy (= Stable) or on > other more conservative linux distribution wasn't exactly easy as the > VM's provided by the Pharo team fail to run on those systems. > > Well, not any longer. You may find precompiled binaries at: > > https://swing.fit.cvut.cz/jenkins/view/Projects/job/pharo-vm-stable-swing/ > > or use zeroconf script: > > curl http://swing.fit.cvut.cz/download/pharo/vm-swing | bash > > or > > wget -O- http://swing.fit.cvut.cz/download/pharo/vm-swing | bash > > The VM is compiled from pre-generated sources found at: > > > http://files.pharo.org/vm/src/vm-unix-sources/blessed/pharo-vm-2014.09.20.t… > > Thanks to Clement, Damien & Markus for their help. > > Have fun. > > Jan > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Sept. 29, 2014

ANN - Pre-compiled Pharo VM for Debian Stable

by Jan Vrany

Hi there, Getting Pharo 2.0/3.0 up and running on Debian Wheezy (= Stable) or on other more conservative linux distribution wasn't exactly easy as the VM's provided by the Pharo team fail to run on those systems. Well, not any longer. You may find precompiled binaries at: https://swing.fit.cvut.cz/jenkins/view/Projects/job/pharo-vm-stable-swing/ or use zeroconf script: curl http://swing.fit.cvut.cz/download/pharo/vm-swing | bash or wget -O- http://swing.fit.cvut.cz/download/pharo/vm-swing | bash The VM is compiled from pre-generated sources found at: http://files.pharo.org/vm/src/vm-unix-sources/blessed/pharo-vm-2014.09.20.t… Thanks to Clement, Damien & Markus for their help. Have fun. Jan

Sept. 28, 2014

Working configuration of OS and Graphiccard for Woden

by Nicolai Hess

Is Woden supposed to work on windows? I tried Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge on windows but it failed (some NB error). I just want to know if anyone tried woden on Windows already. I tried this on linux too, but it fails. (But I wasn't able to run Roassal3D or NBOpenGL on my linux box so I hadn't high expectations, but at least on my windows box I could get NBOpenGL working) Nicolai

Sept. 28, 2014

Re: [Pharo-dev] Data Analysis in Pharo

by Craig Latta

> The teams of Serge, Thierry and Noury have been doing wonderful > things. > > [links to wonderful things] Nice! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 28, 2014

Re: [Pharo-dev] Context representation in current VM

by Esteban Lorenzano

On 28 Sep 2014, at 23:09, Martin McClure <martin(a)hand2mouse.com> wrote: > On 09/28/2014 12:20 PM, Eliot Miranda wrote: >> Hi Martin, >> >> On Sep 28, 2014, at 1:18 AM, Martin McClure <martin(a)hand2mouse.com> wrote: >> >>> I'm updating the exceptions chapter of Deep Into Pharo, which currently contains this text: >>> >>> "...some Smalltalk implementations use the native C execution stack of the virtual machine to avoid creating objects all the time. >>> The current Pharo virtual machine does actually use full Smalltalk objects all the time; for speed, it recycles old method context objects rather than creating a new one for each message-send." >>> >>> Is this still true as of Pharo 4? I'd gotten the idea that this hadn't been true for a while, that the Cog VMs that Pharo is using did use a non-object stack to cache the top N contexts, only converting to actual Context objects when necessary. >> >> So both are true; it depends on the virtual machine. The interpreter VM works as described in the existing chapter. > > Thanks, I'd thought that was the case. >> >> The Cog and Stack VMs work exactly as described in my blog post on context to stack mapping. It's not really the top N contexts. The stack zone, which is allocated on the native stack at startup, is divided into pages, each of which can hold up to ~ 40 activations (depending on stack depth, determined by #temps and nested call complexity). By default there are 160 pages. That either means 160 pages full of activations of a single process (eg one that is deeply recursive) or 1 page of up to 40 activations of 160 different processes or any combination in between. ie a page can only be used by a single process. When a new page is needed the oldest one is emptied by ensuring all activations on the page have contexts (on the heap), and updating the state of those contexts, effectively writing the page to the heap in the form of contexts. > > Ah, I'll have to reread that blog post. > > The remaining question is: For the purposes of this chapter, which is the default VM for Pharo 4? it is a cogvm, and hopefully when we release it will be a spurvm :) > > Regards, > > -Martin >

Sept. 28, 2014

Re: [Pharo-dev] Context representation in current VM

by Martin McClure

On 09/28/2014 12:20 PM, Eliot Miranda wrote: > Hi Martin, > > On Sep 28, 2014, at 1:18 AM, Martin McClure <martin(a)hand2mouse.com> wrote: > >> I'm updating the exceptions chapter of Deep Into Pharo, which currently contains this text: >> >> "...some Smalltalk implementations use the native C execution stack of the virtual machine to avoid creating objects all the time. >> The current Pharo virtual machine does actually use full Smalltalk objects all the time; for speed, it recycles old method context objects rather than creating a new one for each message-send." >> >> Is this still true as of Pharo 4? I'd gotten the idea that this hadn't been true for a while, that the Cog VMs that Pharo is using did use a non-object stack to cache the top N contexts, only converting to actual Context objects when necessary. > > So both are true; it depends on the virtual machine. The interpreter VM works as described in the existing chapter. Thanks, I'd thought that was the case. > > The Cog and Stack VMs work exactly as described in my blog post on context to stack mapping. It's not really the top N contexts. The stack zone, which is allocated on the native stack at startup, is divided into pages, each of which can hold up to ~ 40 activations (depending on stack depth, determined by #temps and nested call complexity). By default there are 160 pages. That either means 160 pages full of activations of a single process (eg one that is deeply recursive) or 1 page of up to 40 activations of 160 different processes or any combination in between. ie a page can only be used by a single process. When a new page is needed the oldest one is emptied by ensuring all activations on the page have contexts (on the heap), and updating the state of those contexts, effectively writing the page to the heap in the form of contexts. Ah, I'll have to reread that blog post. The remaining question is: For the purposes of this chapter, which is the default VM for Pharo 4? Regards, -Martin

Sept. 28, 2014

[Review: 13088] Deleting class that is used in pool dictionaries leaves a "private" class pool entry

by Max Leske

Please review https://pharo.fogbugz.com/f/cases/13088/Deleting-class-that-is-used-in-pool…

Sept. 28, 2014

[OT] The Definitive Guide To Syntax Highlighting

by Sven Van Caekenberghe

Slightly OT: The Definitive Guide To Syntax Highlighting | Wilfred Hughes :: Blog http://www.wilfred.me.uk/blog/2014/09/27/the-definitive-guide-to-syntax-hig… Quite interesting, I didn't realise there were some many options. Seems like a good reference if we ever discuss this topic (again). Also interesting, he mentioned Pharo at the end ! Sven

Sept. 28, 2014

Re: [Pharo-dev] [Vm-dev] Re: Maintainer of FFI-Package

by Nicolai Hess

Thank you David, Thank you Eliot 2014-09-28 21:24 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > On Sep 28, 2014, at 2:19 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > Who is the maintainer of the FFI-Package for > > Squeak and/or Pharo ? > > I guess I'm the de facto maintainer because I'm the one who has changed > things most recently, reimplementing the FFI plugin via the > ThreadedFFIPlugin. > > > > I especially interested in the FFI-Unix examples > > and the state on working FFI on linux for current squeak release > > (AFAIK it does not work with "squeak all in one" 4.5) > > Can you give me a reproducible case? I'd this with a Cog,Stack or > Interpreter VM? Which specific things fail and how? > Image ----- /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Resources/Squeak4.5-13680.image Squeak4.5 latest update: #13680 Current Change Set: Unnamed1 Image format 6505 (32 bit) Virtual Machine --------------- /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Linux-i686/lib/squeak/4.0-2776/squeak Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] Unix built on Aug 22 2013 10:35:37 Compiler: 4.1.2 20080704 (Red Hat 4.1.2-48) platform sources revision VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 Load Name: FFI-Pools-eem.3 Name: FFI-Kernel-eem.26 Name: FFI-Tests-djm.7 Run FFI-Test -> 32 run, 24 passes, 0 expected failures, 0 failures, 8 errors, 0 unexpected passes Load Name: FFI-Unix-mtf.4 run X11Display class>>#coloredRectangles -> Error: Could not coerse arguments Load newer cogvm Virtual Machine --------------- /media/Programs/squeak/Squeak-4.5-All-in-One.app/coglinux/lib/squeak/4.0-2987/squeak Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.746] Unix built on Jun 11 2014 14:59:18 Compiler: 4.1.2 20080704 (Red Hat 4.1.2-48) platform sources revision VM: r2987 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-06-11 14:26:16 -0700 Plugins: r2954 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins CoInterpreter VMMaker.oscog-eem.746 uuid: cc4961d3-e629-4e28-b308-88eab314a8c9 Jun 11 2014 StackToRegisterMappingCogit VMMaker.oscog-eem.766 uuid: 3045c341-cfbf-494c-a7b1-fb29c26a7340 Jun 11 2014 Run FFI-Test -> 32 run, 32 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes The error in FFI-Unix is strange. The last package comment from Name: FFI-Unix-mtf.4 Author: mtf is "made the XLib examples actually work (Window is an unsigned int handle, not a struct)" That the window is an int handle and not a struct explains why this version replaces the parent class of XDrawable from ExternalStructur to Object. But all calls with an XDrawable still have this object as parameter ( and not its instance var "xid"). I don't understand how this ever worked (or was there some kind of automatic argument conversion like: transform an object with an instvar -> a int, if the function expects an int handle?) Sure we can replace all XDrawable arguments in X11 calls from "aXDrawable" to "aXDrawable xid". But I only wonder, did this ever work and if Author "mtf" did the last change, can I contact him or is he still maintaining the FF-Unix examples? > > > regards > > Nicolai > > Eliot (phone)

Sept. 28, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Maintainer of FFI-Package

by Eliot Miranda

Hi David, On Sep 28, 2014, at 12:44 PM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > On Sun, Sep 28, 2014 at 09:04:59AM -0400, David T. Lewis wrote: >> >> On Sun, Sep 28, 2014 at 11:19:30AM +0200, Nicolai Hess wrote: >>> Who is the maintainer of the FFI-Package for >>> Squeak and/or Pharo ? >>> I especially interested in the FFI-Unix examples >>> and the state on working FFI on linux for current squeak release >>> (AFAIK it does not work with "squeak all in one" 4.5) >> >> The FFI package, including the FFI-Unix examples that you mention, is at >> http://source.squeak.org/FFI. >> >> The primary author was Andreas Raab. Eliot Miranda is the most recent >> contributor, and he is probably the most knowledgeable in this area. >> Currently, the Squeak core developers (those with commit rights to Squeak >> trunk) have commit rights to the FFI project, and can make updates as needed. >> >> The FFI examples for Unix work with the old FFI plugin, which is still >> present in the interpreter VM. The active development of Squeak FFI is >> taking place in Cog, and I'm not sure if the old FFI examples work with >> the newer plugins (which would be present in the Squeak all-in-one). >> The FFI plugin in the interpreter VM (i.e. trunk VMMaker) needs to be >> updated, and presumably the FFI examples may need some updates as well. > > A small but important correction: For the old plugin (currently in the > interpreter VM), FFI works only for a 32-bit VM. It also works for a 64-bit > VM, but only if the patches in http://bugs.squeak.org/view.php?id=7237 have > been applied (in other words, if you compiled it yourself and included > those patches). Good point. It should be easier to adapt the ThreadedFFIPlugin to 64 bits because there's no assembler involved. But this gets to the crux of why we need to rearchitect, because the x86-64/IA64 ABI is extremely complex to use interpretively and much easier to approach with a special-purpose compiler. Some steps are being taken in this direction in the Pharo community. In fact there's more possibility of getting x86-64/IA64 working with the Squeak FFI than with eg VisualWorks because Andreas' type signature scheme (ExternalType et al) is richer than VW's. but it's work; much of the marshaling code in the plugin would need rewriting. We're just starting the Spur 64-but VM and do will tackle this soon enough (some time mid next year?). Whether by that time it'll make more sense to extend the existing ThreadedFFIPlugin or go with the new architecture is too early to tell. HTH > This is mainly of historical interest, although it is possible that some > of the 64-bit patches will prove helpful for the newer FFI plugin. But > the emphasis now should be on Eliot's more recent FFI work. +1 > > Dave Cheers, Eliot

Sept. 28, 2014