- Pharo-dev - lists.pharo.org

Re: [Pharo-project] decoupling the vm: UI and interpretation

by csrabak＠bol.com.br

Em 20/12/2011 07:38, Fernando Olivero < fernando.olivero(a)usi.ch > escreveu: > Hi, a question to the VM maintainers. > Would it be hard to decouple the VM, one part handling the object > machinery, and the other the UI portion of the current OS. > The "UI Vm" would feed the VM with the events, similarly to the > current scheme, but there's no need for them to be coupled within > the same project. So we could implement separately the "UI Vm", > that its implemented in whatever windowed framework we choose ( > Cocoa, X11, Windows, etc..). I think this is an idea which may have appeal for theoretic reasons and even if it is short to medium term feasible it will not have the impact it deserves. > In short, do you think it would worth it to break the VM into two > pieces: > 1)UI VM: handles the window, the drawing context were Pharo should > be drawn into, and announcing user events to the Smalltalk VM. > 2)Smalltalk VM: everything else (truly headless). > (The two OS processes could communicate via any available > IPC(interprocess communication)) It would add complexity, reduce performance without any obvious advantage for the final user... > Wouldn't it make easier the task of maintaining and enhancing both > VMs separately? No, because the problems to port for each platform would remain all there. Worse, if we need to create a new "upper level" abstraction in order to translate all the UI VM primitives to all the corresponding platform OSs. > This idea came up because of the current effort to free Pharo, from > the outdated bitmap dependency, into a vectorial user interface > framework. Which I see as distantly related issue which is not easily solvable by the proposal of this post. > Fernando pd: I've been playing around recently with Cocoa, the > "smalltalk and morphic" ripoff from apple. And found it relatively > easy to come with a "UI VM". What is difficult is to plug into the > current scheme. Yes, then imagine plug into the current scheme 'n' different UI VMs. . . > >

Dec. 22, 2011

Re: [Pharo-project] MacRuby Cocoa UIs

by Sean P. DeNigris

Fernando olivero-2 wrote > > I was about to play with a similar approach using Cocoa. > I just used MacRuby because it is more fun than ObjC :) Fernando olivero-2 wrote > > Did you try with more complex examples? > No, I just wanted the build and play with simplest possible example. Fernando olivero-2 wrote > > i would like to understand if HTTP would be fast enough as an IPC, > between the UI and a Pharo headless vm. > Me too :) -- View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4226347.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 22, 2011

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

by laurent laffont

On Thu, Dec 22, 2011 at 7:29 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 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 > oh I forgot this one. Just ordered :) Laurent > > -- > 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

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