- Pharo-dev - lists.pharo.org

[Pharo-project] New Compiler
by Jorge Ressia March 5, 2009

March 5, 2009

Hi, Marcus Denker and myself will be working on the New Compiler for Pharo. We have a plan draft of the steps that need to be followed in order to get it up and running in Pharo: 1.- Write good tests for each module parse, check, codeGen, execute and check if works. First simple example, and then complex ones. Test recompilation too. 2.- Performance, how long does it take compared to the old compiler. 3.- Error messages: at least like in the old compiler. 4.- Introduce Eliot's Closures. Soon we will have a more detailed and formal list of thing to be done. Cheers, Jorge Ressia

8 8

[Pharo-project] What's the problem people? :)
by GÃ¶ran Krampe March 5, 2009

March 5, 2009

Hi Pharaos (and Squeak-dev)! :) Alert to Pharaos: This is a cross post! (hehe) I just wanted to say (for whatever that is worth) that I like Pharo. And I like Squeak.org. And I like everyone doing stuff in/for/on Squeak/Pharo/Smalltalk/Huemul whatever. I have Pharo on my disk. I just started playing in it for a toy project involving RB AST, RoelTyper etc. But I do all Gjallar work on 3.10.2/LPF right now, it takes time moving a large project to a different baseline, so Gjallar will probably be on 3.10.2 for a while. But nothing prevents us from testing out Pharo later on - whatever works the best I say. Gjallar is also 95% ported to GS these days. I agree with Keith/Matthew that making good tools that can *span* different forks/communities *must* be a good thing for us all to have. All tools don't need to be spanning, but it doesn't hurt if *some* are - right? I *also* agree with Pharo people that hey, Pharo is a fork - we/you can do whatever we/you like! And that is good - it's the strength of Pharo. If Pharo diverts too much in "base stuff" it might turn into a weakness - but we just don't know these things, it is still to be seen. It is all about balance, benefits, etc. And we don't need to get angry with each other do we? :) Trust me, it just burns your energy! I have code that seems to be doing fine in Pharo - SocketStream comes to mind. I know Pharo seem to be more inclined to use Universes than SM - fine with me, no problem. I hope to move SM forward in some way, and I hope it can still be loaded/used from within Pharo - even if it gets thrown out soon (I think I read something about that). I also intend to use both Pharo, Squeak or whatever works best for my different tasks. And finally I hope to revive DeltaStreams and make that work in Pharo as well as most other Squeak flavors. We are all Squeakers, right? :) regards, GÃ¶ran PS. I am not sure why I am so damn cheerful, perhaps it is the SURGE I seem to feel in the Squeak community - so many things going on all over the place... ;)

5 10

[Pharo-project] [Fwd: [squeak-dev] Re: [ANN] Preference pragmas]
by Michael Rueger March 5, 2009

March 5, 2009

1 0

Re: [Pharo-project] [squeak-dev] [ANN] Preference pragmas
by Michael Rueger March 4, 2009

March 4, 2009

Andreas Raab wrote: > Folks - > > I wanted to make the property whether to show individual processes in > MessageTally a preference and couldn't recall any of the three gazillion > methods to create one ;-) So I decided enough is enough and added the > ability to register a preference via Pragma. In other words, you specify > two class side accessors (using MessageTally as example): > > showProcesses > "Indicates whether to show each process separately or cumulatively." > <preference: 'Show Processes in MessageTally' > category: 'debug' > balloonHelp: 'If enabled, each profiled process is shown > individually in MessageTally' > type: #Boolean> > ^ShowProcesses Looking at your version I see you made some slightly different design choices than in the design that has been in design discussion and worked on in the last couple of weeks on the Pharo list. Can you elaborate what motivated the different design? Meaning what parts of the Pharo version could be made better? Or, sorry for basically asking the same thing three times, what would it take to adopt the Pharo version for Squeak? Michael

1 0

[Pharo-project] duplication between scg.bib and lse.bib ?
by Alexandre Bergel March 4, 2009

March 4, 2009

J'ai l'impression que toutes nos publications moose related doit apparaitre dans scg.bib pour Ãªtre listÃ©es sur http://moose.unibe.ch/publications/list Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

[Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support
by John M McIntosh March 4, 2009

March 4, 2009

Yes it compiles, yes after a bit of poking I could take a Squeak3.9- final-7067.image and build a closure aware image. No I could not do that without poking a bit, however I hope that we'll resolve the problems in a day or two. Yes, I could take a Pharo0.1Core-10243.image and after more poking could generate a closure aware Pharo image. At this time the 4.0.0b1 VM is not publicly available, another day or two of cross checking is required, I've asked the Pharo team to review my changes and the changes from Eliot. I've also asked Eliot to supply some fixes so we can recompile the Squeak3.9-final-7067 image without problems. I cannot speak for the 3.10 or 3.11 images, other parties will need to pursue any work to make them closure aware. Tomorrow I'll poke at making the iPhone VM closure aware, however any iPhone image relies on the Pharo team resolving what the change sets should be to make the image closure aware. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

5 8

[Pharo-project] Shadow in Watery2
by Marcus Denker March 4, 2009

March 4, 2009

Gary, Watery2 looks better and better :-) Great! One question regarding the shadow: Now the active window has a translucent shadow (like macos), very nice. But it's turned off and replaced with the hard non-translucend Morphic shadow while moving the window. Would it be possible to render the same shadow, even wen picking up windows? This would result in a much smoother apperance, and I think it even would feel faster. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

9 20

[Pharo-project] UI performance
by Sebastian Sastre March 4, 2009

March 4, 2009

Hi there, rigth now I've save a method and it takes like 6 seconds (maybe more sometimes) to return control after dropping a method in another category or even saving. That is really a show stopper for productivity. What can I disable to make the pharo's ui more responsive? thanks, sebastian pd: I dont feel like is a visual thing, I guess is trying to deduct too much at every step, maybe something related to the OB Browser?

3 5

March 4, 2009

As some of us are unregistered, I thought it could be of interest ;) ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example): showProcesses Â Â Â Â "Indicates whether to show each process separately or cumulatively." Â Â Â Â <preference: 'Show Processes in MessageTally' Â Â Â Â Â Â Â Â category: 'debug' Â Â Â Â Â Â Â Â balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally' Â Â Â Â Â Â Â Â type: #Boolean> Â Â Â Â ^ShowProcesses showProcesses: aBool Â Â Â Â "Indicates whether to show each process separately or cumulatively." Â Â Â Â ShowProcesses := aBool. and then register the preference in the class initialization method via: initialize Â Â Â Â "MessageTally initialize" Â Â Â Â "By default, show each process separately" Â Â Â Â ShowProcesses := true. Â Â Â Â "Register preferences" Â Â Â Â Preferences addPreferencesFor: self. The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use. To install, just execute the following from Squeak 3.10.2: Â Installer mantis fixBug: 7306. Enjoy! Â - Andreas -- CÃ©drick

4 12

[Pharo-project] A point a.k.a excuse to you
by Torsten Bergmann March 4, 2009

March 4, 2009

>Lukas wrote: >> Why should it run on Squeak, if I have all my code running in Pharo? >> Keith wrote: >We have two equal and opposite questions you could ask. I would ask "Why >shouldn't it run on squeak?".... Nobody stops you to make Squeak compatible to Pharo so Lukas' code will also run on Squeak ;) But the more Pharo and Squeak evolve the harder it will be. Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

1 0