- Pharo-dev - lists.pharo.org

[Pharo-project] MacRuby Cocoa UIs
by Sean P. DeNigris Dec. 22, 2011

Dec. 22, 2011

For a while, I've been thinking about using MacRuby for native UIs and multiple windows in Pharo on the Mac. I uploaded a proof of concept to https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI that uses http to get a value (the current time) from a running Pharo image and displays it in a text field. Sean -- View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4220336.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 1

[Pharo-project] decoupling the vm: UI and interpretation
by Fernando Olivero Dec. 22, 2011

Dec. 22, 2011

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..). 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)) Wouldn't it make easier the task of maintaining and enhancing both VMs separately? This idea came up because of the current effort to free Pharo, from the outdated bitmap dependency, into a vectorial user interface framework. 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.

4 3

Re: [Pharo-project] MacRuby Cocoa UIs
by Fernando Olivero Dec. 22, 2011

Dec. 22, 2011

nice! I was about to play with a similar approach using Cocoa. Did you try with more complex examples? i would like to understand if HTTP would be fast enough as an IPC, between the UI and a Pharo headless vm. Fernando On Wed, Dec 21, 2011 at 4:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > For a while, I've been thinking about using MacRuby for native UIs and > multiple windows in Pharo on the Mac. I uploaded a proof of concept to > https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI > that uses http to get a value (the current time) from a running Pharo image > and displays it in a text field. > > Sean > > -- > View this message in context: http://forum.world.st/MacRuby-Cocoa-UIs-tp4220336p4220336.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

2 1

[Pharo-project] [ANN] ExperimentalBit [WAS] Re: Out of the box primitives for bit in ObjectHeader?
by Mariano Martinez Peck Dec. 22, 2011

Dec. 22, 2011

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

1 0

[Pharo-project] Zinc (bug?) - multiple default servers
by Sean P. DeNigris Dec. 22, 2011

Dec. 22, 2011

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. -- View this message in context: http://forum.world.st/Zinc-bug-multiple-default-servers-tp4220409p4220409.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

[Pharo-project] "fixed" AbstractLauncher missing for loading Cog
by Mariano Martinez Peck Dec. 22, 2011

Dec. 22, 2011

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

2 1

[Pharo-project] 1.3, PBE and lab setups
by Dave Mason Dec. 22, 2011

Dec. 22, 2011

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? 3) what is the timeline on these, as our semester starts Jan 10. Thanks ../Dave

4 4

[Pharo-project] External web browser
by Hilaire Fernandes Dec. 22, 2011

Dec. 22, 2011

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

2 1

[Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307
by Johan Brichau Dec. 22, 2011

Dec. 22, 2011

Hi, I have been running Pharo 1.3 (#13315) with a pre-built Cog VM's downloaded from Eliot's site in a reliable manner (i.e. very few crashes) for many months. Just last week, I decided to try the Cog VM that is served from the Pharo website (Cog VM Mac-13307) and I am experiencing continuous crashes of the image. I am attaching a dump to this email. Once I switched back to the latest VM served on Eliot's site (VM.r2522), I stopped experiencing these crashes. If I experience this, probably other are tooâ¦ cheers, Johan

6 17

[Pharo-project] gt inspector
by Tudor Girba Dec. 21, 2011

Dec. 21, 2011

Hi, Just out of curiosity: Does any of you use the GTInspector? For those that wonder what that is, here is a demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk This is available in any recent Moose image mapped as Explorer (CMD+I). You can load it in a Pharo 1.3 image by:Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: #GTInspector) registerToolsOn: Smalltalk tools. Cheers,Doru -- www.tudorgirba.com "Every thing has its own flow"

4 6