December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [OT] Pharo and children

by blake

I used Prof. Steph's Robots book with my 9 year old. On Thu, Dec 22, 2011 at 9:53 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > my son will soon have 7 years old and starts to show interest in how all > these things move on screen. I wonder what are your cool ways to teach > programming with instant fun for kids. > > Any experience ? > > Cheers, > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Blog: http://magaloma.blogspot.com/ > Developer group: http://www.cara74.org > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Pharo web deployment: http://www.alpha.smallharbour.org >

Dec. 22, 2011

[Pharo-project] [ANN] ExperimentalBit [WAS] Re: Out of the box primitives for bit in ObjectHeader?

by Mariano Martinez Peck

Hi guys. Last days I needed to migrate some old code I used to have in the VM for tracing objects usage. Luc Fabresse wanted also to be able to set and get the value of a bit in the object header to do some experiments. So...we thought it was a good idea to make it abstract an public. So....the following is only one morning work we did together with Luc, so don't expect that much. What we did is to do a very small change in the VM to use one free bit in the object header, and then we coded 3 primitives: one to get the value, one to set it and one to unmark all objects. The idea is that you can use this code and give semantics to the bit. This is just for experimenting and prototypes, not for production code since such bit in the object header may not be available. To download: Gofer it url: 'http://ss3.gemstone.com/ss/ExperimentalBit'; package: 'ConfigurationOfExperimentalBit'; load. Now.... you can read ConfigurationOfExperimentalBit class comment: --------------- ExperimentalBit is a small facade for setting and getting the value of a bit in the Object Header. It requires a special VM which supports the primitives to set and get the value of such bit. You can get a already compiled MacOSX VM from: https://gforge.inria.fr/frs/download.php/30042/ CogMTVM-ExperimentalBit.zip. For more details read class comment of ExperimentalBitHandler. If you already have a compiled VM with the required primitives, then you can just load the image side part evaluating: ((Smalltalk at: #ConfigurationOfExperimentalBit) project version: '1.0') load. If you want to build a VM with the primitives we need, you need to download: ((Smalltalk at: #ConfigurationOfExperimentalBit) project version: '1.0') load: 'VMMakerGroup'. And then follow the steps to build the VM: - http://code.google.com/p/cog/ - http://code.google.com/p/cog/wiki/Guide ----------- And here ExperimentalBitHandler class comment: ----------- ExperimentalBitHandler is a small facade for setting and getting the value of a bit in the Object Header. It requires a special VM which supports the primitives to set and get the value of such bit. You can get a already compiled MacOSX VM from: https://gforge.inria.fr/frs/download.php/30042/ CogMTVM-ExperimentalBit.zip. To know which version of the VM you have to use to compile, check the dependencies in ConfigurationOfExperimentalBit and also the 'description' of it. For example, if version 1.0 it depends on 'CogVM' version '3.7'. In the description of version 1.0 you can also read that the used Git version of the platform code was 4a65655f0e419248d09a2502ea13b6e787992691 from the blessed repo. Basically, there are 3 operations: set the bit to a specific, get the value of the bit and turn off the bit of all objects. Examples: 'aString' experimentalBit: true. 'astring ' experimentalBit. Date today experimentalBit: false. Date today experimentalBit. ExperimentalBitHandler turnOffExperimentalBitOfAllObjects. For more details see ExperimentalBitTest. ------------- Happy Christmats for all the Smalltalk hackers!!! -- Mariano http://marianopeck.wordpress.com On Wed, Dec 14, 2011 at 1:24 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. As you may notice, I always try to push in the direction of a VM > where we can have both things: a) a really cooler super fast VM for > production super critical applications and b) the most-flexible-possible > VM for doing reasearh and experiment. > > Now I was thinking the following: we have one free bit in the > ObjectHeader. Let's say you are experimenting with something and you would > like to tag objects, such as, "traversed", "processes", "isProxy", etc. To > do that small experiment you need to modify the VM, adapt the bit, code the > primitives, build the VM, put the smalltalk side part etc etc. So I was > thinking why not providing such small functionality out of the box? the > idea would be not to give semantics to the bit since each user will do > that. So we just provide the VM with 2 primtives, one to get the value > (#getBitValue) and one to set it (#setBitTo:). Choose the names you want. > > Then we do not integrate nothing in our images that use such bit, there > won't be colisions. Then each guy who wants to experiments with that, can > use the primitives and do what he wants. > > Some people is doing something with its bit: Jean Batiptse is doing XXX, I > am doing YYY, etc. Either in his work or mine, there are much more changes > that just that bit, so in anyway, I will end up needing my own VM. > > Finally, I could help in providing the code if it is needed. > > So, what do you think? > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2011

Re: [Pharo-project] [OT] Pharo and children

by Damien Cassou

On Thu, Dec 22, 2011 at 6:53 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > my son will soon have 7 years old and starts to show interest in how all > these things move on screen. I wonder what are your cool ways to teach > programming with instant fun for kids. Squeak: Learn Programming with Robots -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 22, 2011

[Pharo-project] [OT] Pharo and children

by laurent laffont

Hi, my son will soon have 7 years old and starts to show interest in how all these things move on screen. I wonder what are your cool ways to teach programming with instant fun for kids. Any experience ? Cheers, Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Blog: http://magaloma.blogspot.com/ Developer group: http://www.cara74.org Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Pharo web deployment: http://www.alpha.smallharbour.org

Dec. 22, 2011

Re: [Pharo-project] Zinc (bug?) - multiple default servers

by StÃ©phane Ducasse

thanks http://code.google.com/p/pharo/issues/detail?id=5127 On Dec 22, 2011, at 1:01 PM, Sven Van Caekenberghe wrote: > Name: Zinc-HTTP-SvenVanCaekenberghe.233 > Author: SvenVanCaekenberghe > Time: 22 December 2011, 12:54:05 pm > UUID: 8dd541c9-2890-4a8f-b5cb-d6ac2e9341af > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.232 > > Rewrote ZnServer and subclasses's class methods #startDefaultOn: and #defaultOn: to treat the default instance like a singleton by reusing/restarting/reconfiguring existing instances; expanded comments; > Changed the implementation of ZnServer>>#start to automagically register the default instance; > Changed the implementation of ZnServer>>#stop to always unregister; > added ZnServer>>#stop: with an option to control the unregistering so that it does not happen when shutting down the image > > ---- > > Name: Zinc-Tests-SvenVanCaekenberghe.121 > Author: SvenVanCaekenberghe > Time: 22 December 2011, 12:56:23 pm > UUID: c1396284-0787-4c42-bedd-fb6ae918c68d > Ancestors: Zinc-Tests-SvenVanCaekenberghe.120 > > added ZnServerTests>>#testDefault to test the new semantics of ZnServer class>>#startDefaultOn: > > --- > > ZnServerTests>>#testDefault > | server | > ZnServer stopDefault. > self assert: ZnServer default isNil. > server := ZnServer startDefaultOn: 1701. > self assert: ZnServer default notNil. > self assert: ZnServer default == server. > self assert: ZnServer default port = 1701. > self assert: ZnServer default isRunning. > self assert: (ZnServer managedServers includes: server). > ZnServer stopDefault. > self assert: ZnServer default isNil. > self deny: server isRunning. > self deny: (ZnServer managedServers includes: server). > server := ZnServer startDefaultOn: 1701. > "Starting the default again is actually a restart" > ZnServer startDefaultOn: 1701. > self assert: ZnServer default == server. > ZnServer stopDefault

Dec. 22, 2011

Re: [Pharo-project] [Vm-dev] "fixed" AbstractLauncher missing for loading Cog

by Luc Fabresse

2011/12/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Hi guys. I have just "fixed" the problem that we cannot load clean Cog in > Pharo 1.4/1.3 because AbstractLauncher was removed. I have created a > package CogVMMakerPharoCompatibility in the repo PharoVM of SqueakSource > and I have commited a nuked version of AbstractLauncher. It is nuked > because the method #activate is sent by Cog's CommandLineLauncher class >> > initialize. So...it seems CommandLineLauncher is only used for scripting, > so if you DO want to use that class, it won't work in Pharo. But at least > Cog will load without problems and you will be able to build a VM. Of > course a better solution would be to put 'Cog-Scripting' in a separate > package and from ConfigurationOfCog do not loas such separated package if > we are in Pharo but do load it if we are in Squeak. If someone (Eliot) > publishes such a change, I don't have a problem to rollback this one. But I > was tired of this error so I proceeded with this workarround. > > So...this was done in ConfigurationOfCog new baseline 2.0 and new version > 3.7. > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfCog'; > load. > > ((Smalltalk at: # ConfigurationOfCog) project version: '3.7') load > Huge Thanks ;-) Luc > > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > >

Dec. 22, 2011

[Pharo-project] "fixed" AbstractLauncher missing for loading Cog

by Mariano Martinez Peck

Hi guys. I have just "fixed" the problem that we cannot load clean Cog in Pharo 1.4/1.3 because AbstractLauncher was removed. I have created a package CogVMMakerPharoCompatibility in the repo PharoVM of SqueakSource and I have commited a nuked version of AbstractLauncher. It is nuked because the method #activate is sent by Cog's CommandLineLauncher class >> initialize. So...it seems CommandLineLauncher is only used for scripting, so if you DO want to use that class, it won't work in Pharo. But at least Cog will load without problems and you will be able to build a VM. Of course a better solution would be to put 'Cog-Scripting' in a separate package and from ConfigurationOfCog do not loas such separated package if we are in Pharo but do load it if we are in Squeak. If someone (Eliot) publishes such a change, I don't have a problem to rollback this one. But I was tired of this error so I proceeded with this workarround. So...this was done in ConfigurationOfCog new baseline 2.0 and new version 3.7. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load. ((Smalltalk at: # ConfigurationOfCog) project version: '3.7') load Cheers -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2011

Re: [Pharo-project] [sbe-discussion] 1.3, PBE and lab setups

by Serge Stinckwich

2011/12/15 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Dec 15, 2011, at 2:24 AM, Serge Stinckwich wrote: > >> 2011/12/15 Dave Mason <dmason(a)mason-rose.ca>: >>> I am trying to get our local admins to set up labs so students can use the >>> latest Pharo. >>> >>> Currently we have 1.2 and PBE .image files and by removing the field in the >>> INI file that specified the image, if you clicked on Pharo, you'd get a >>> dialogue asking which image you wanted. Â All of these are on read-only >>> mounts, so if you want to save to the image, you need to copy the image to >>> your home directory and then you could navigate to that image file on >>> startup. Â Dropping an image on the executable works fine, though. >>> >>> Additionally, the PBE book doesn't play well with 1.3 (things that the book >>> says die when you try them). Â Apparently you can't open the PBE image from >>> the 1.3 binary without it crashing, either. >>> >>> So I have 3 questions: >>> >>> 1) is 1.3 the system to use, or will 1.4 be stable soon? >>> >>> 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? >> >> There is no plan at the moment to do that, but you could help adapt >> the Pharo Book to the new images. >> All the contents of the book is here: >> https://github.com/SquareBracketAssociates/PharoByExample-english >> >> Maybe we can have branches for each version of Pharo ? pharo1.2, >> pharo1.3, etc â¦ > > yes this would be really good to have a branch Ok, who is willing to help for adapting the Pharo by Example book to Pharo 1.4 ? I could add a branch for Pharo 1.0 for the old version and we could use master branch for Pharo 1.4. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Dec. 22, 2011

Re: [Pharo-project] Zinc (bug?) - multiple default servers

by Sven Van Caekenberghe

Name: Zinc-HTTP-SvenVanCaekenberghe.233 Author: SvenVanCaekenberghe Time: 22 December 2011, 12:54:05 pm UUID: 8dd541c9-2890-4a8f-b5cb-d6ac2e9341af Ancestors: Zinc-HTTP-SvenVanCaekenberghe.232 Rewrote ZnServer and subclasses's class methods #startDefaultOn: and #defaultOn: to treat the default instance like a singleton by reusing/restarting/reconfiguring existing instances; expanded comments; Changed the implementation of ZnServer>>#start to automagically register the default instance; Changed the implementation of ZnServer>>#stop to always unregister; added ZnServer>>#stop: with an option to control the unregistering so that it does not happen when shutting down the image ---- Name: Zinc-Tests-SvenVanCaekenberghe.121 Author: SvenVanCaekenberghe Time: 22 December 2011, 12:56:23 pm UUID: c1396284-0787-4c42-bedd-fb6ae918c68d Ancestors: Zinc-Tests-SvenVanCaekenberghe.120 added ZnServerTests>>#testDefault to test the new semantics of ZnServer class>>#startDefaultOn: --- ZnServerTests>>#testDefault | server | ZnServer stopDefault. self assert: ZnServer default isNil. server := ZnServer startDefaultOn: 1701. self assert: ZnServer default notNil. self assert: ZnServer default == server. self assert: ZnServer default port = 1701. self assert: ZnServer default isRunning. self assert: (ZnServer managedServers includes: server). ZnServer stopDefault. self assert: ZnServer default isNil. self deny: server isRunning. self deny: (ZnServer managedServers includes: server). server := ZnServer startDefaultOn: 1701. "Starting the default again is actually a restart" ZnServer startDefaultOn: 1701. self assert: ZnServer default == server. ZnServer stopDefault On 21 Dec 2011, at 08:26, Sven Van Caekenberghe wrote: > Sean, > > On 21 Dec 2011, at 04:40, Sean P. DeNigris wrote: > >> If you evaluate "ZnServer startDefaultOn: aPortNumber" several times, you end >> up with that many instances of the default server class. Is that the >> intended behavior? #default usually = singleton, so I expected all the calls >> to operate on the same instance. > > ZnServer>>#defaultOn: aNumber > "Create a new Default instance on a given port, > stopping any previously running Default and replacing it. > Register the new instance." > > Default ifNotNil: [ Default stop ]. > ^ Default := (self on: aNumber) > register; > yourself > > Hmm, I never looked at it that way, but now that you mention it, a clearer singleton behavior might make more sense. Note that in any case, only one instance was running. But it might make more sense to really maintain a singleton, the comments should be adapted as well. > > Thanks for bringing this to my attention. > > Regards, > > Sven

Dec. 22, 2011

Re: [Pharo-project] External web browser

by Alexander LazareviÄ

Hilaire, on Linux the ExternalWebBrowser package, as it is, depends on a helper program (e.g. xdg-open) to open a url in the default browser. The helper program is executed using the system() function of the standard C library. This is defined in ExternalWebBrowser>>*system:* string "system() executes a command specified in string by calling /bin/sh -c string, and returns after the command has been completed." <*apicall:* short 'system' (char*) *module:* 'c'> ^self externalCallFailed The problem is, that the VM is unable to find that 'c' module/library as you can see when you evaluate ExternalWebBrowserUnix isCLibAvailable The VM is actively looking for a library file before it will use the dynamic linker to actually load it. The VM uses permutations of well known library locations (e.g. /lib) with library pre- (e.g. lib) and postfixes (e.g. .so) to find the file. So for example it will look for /lib/libc.so (among many others see [1] on a related matter) But even back at the time I started the ExternalWebBrowser package, the Linux distributions that I used (Debian, Ubuntu) didn't provide such a file, but /lib/libc.so.6. And the VM would not look for such a file. So to make it work I used a hack that Andreas Raab used with his OpenGL package to change the module name of the FFI definitions on the fly. In isCLibAvailable I try to use the generic module name 'c' and if that fails I try it again with the specific module name 'libc.so.6'. This (hack) worked as long as there was such a file. Now it seems that on newer Linux distributions even this file disappeared and it all depends on the dynamic linker to find the right shared library file. One could extend the list of module names to try by '/lib/i386-linux-gnu/libc.so.6' as on my system, but that would most probably not work with 64bit systems and so on. A better solution would be to adapt the way tries to find/load shared libraries. In the special case of handling URLs by external programs, I think Bert Freudenberg suggested that the/a VM/VM-Module should provide such a functionality. Alex [1] http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html#a4214041 2011/12/21 Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch>: > Hello, > > What is the status of external web browser use. > Last time I checked several months ago I can't use it with Linux. > Anyone using it successfully recently? > > Thanks > > Hilaire > > -- > Dr. Geo -- http://www.drgeo.eu > >

Dec. 22, 2011