March 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by CÃ©drick BÃ©ler

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

March 4, 2009

Re: [Pharo-project] New Compiler

by StÃ©phane Ducasse

I would love to have one compilerContext object so that we do not have to pass all these parameters plague It would be nice to have compile: 'text' context: (aCompilerContext) aCompilerContext in: aClass ; silently: true ; inCategory: 'zork' But this is something we should do after :) On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote: > Hi Jorge, > > great to hear. I have two things that I wish you add to your list: > > 1. My first wish also affects the old compiler, but that should be > easy to fix in Pharo. Currently there are dozens of selectors in > Behavior that hardcode the currently used compiler #parseClass, > #compilerClass, #evaluatorClass, #decompilerClass, > #subclassDefinerClass, ... I would prefer to have exactly one entry > point, for example under the name #compiler. This object could act > like a compiler MOP on the receiving class and set through a > preference for all classes of the system that do not override this > method themselves. This would make it much cleaner to have different > compilers in the image, swap them on the fly, get rid of various hacks > and overrides and even allow to unload the old compiler. > > 2. My second wish is only about the new compiler. One thing stroke me > when working on transactional memory and domain specific languages, is > that the new compiler isn't as extensible as it advertises. The > problem is there is no central place where the different phases > (parsing, annotation, bytecode generation) of the compilation is > triggered. Currently this happens at various places throughout the > system. This has not only the problem that extending the compiler is > difficult without patching it, but also makes it nearly impossible to > get certain information at a particular place of the process. For > example, during parsing it is not know in what class the method is > supposed to be compiled, or during bytecode generation I don't know > the source code anymore, etc. I suggest to introduce a compilation > context, that is accessible anywhere and that can pass necessary > information through the compilation phases. Furthermore I suggest to > implement the delegation to the different parts of the compiler in a > deticated object that can be subclassed and used for example if > somebody wants to cleanly replace, customize or extend certain parts > of the compiler. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] New Compiler

by Lukas Renggli

Hi Jorge, great to hear. I have two things that I wish you add to your list: 1. My first wish also affects the old compiler, but that should be easy to fix in Pharo. Currently there are dozens of selectors in Behavior that hardcode the currently used compiler #parseClass, #compilerClass, #evaluatorClass, #decompilerClass, #subclassDefinerClass, ... I would prefer to have exactly one entry point, for example under the name #compiler. This object could act like a compiler MOP on the receiving class and set through a preference for all classes of the system that do not override this method themselves. This would make it much cleaner to have different compilers in the image, swap them on the fly, get rid of various hacks and overrides and even allow to unload the old compiler. 2. My second wish is only about the new compiler. One thing stroke me when working on transactional memory and domain specific languages, is that the new compiler isn't as extensible as it advertises. The problem is there is no central place where the different phases (parsing, annotation, bytecode generation) of the compilation is triggered. Currently this happens at various places throughout the system. This has not only the problem that extending the compiler is difficult without patching it, but also makes it nearly impossible to get certain information at a particular place of the process. For example, during parsing it is not know in what class the method is supposed to be compiled, or during bytecode generation I don't know the source code anymore, etc. I suggest to introduce a compilation context, that is accessible anywhere and that can pass necessary information through the compilation phases. Furthermore I suggest to implement the delegation to the different parts of the compiler in a deticated object that can be subclassed and used for example if somebody wants to cleanly replace, customize or extend certain parts of the compiler. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2009

Re: [Pharo-project] Fwd: On the OTDebugger...

by Alexandre Bergel

Ok for me. Cheers, Alexandre On 4 Mar 2009, at 10:30, StÃ©phane Ducasse wrote: > So we should proceed that way: > - Put a big warning + the expression to switch debugger in the pharo- > dev > - then we follow what dale is saying > - I will produce a list of important features we need to have > -- copy stack > -- chase pointer > ... in OT > > Is is ok for your community? > > Stef > > > Begin forwarded message: > >> From: Dale Henrichs <dale.henrichs(a)gemstone.com> >> Date: March 3, 2009 6:57:36 PM CEST >> To: stephane.ducasse(a)inria.fr >> Subject: On the OTDebugger... >> Reply-To: dale.henrichs(a)gemstone.com >> >> Steph, >> >> This note isn't about your 'disable OB-debugger for now message', >> but it is a response, of sorts to the ensuing discussion. >> >> If you want a '120% debugger' then folks working on Pharo need to >> use the debugger and eat their own dogfood. It's the only way to >> ensure that a tool like the debugger gets enough coverage to ensure >> that it is stable. With that said, I wouldn't want to commit to >> using a tool that was broken or that I couldn't depend upon. >> >> With that in mind, I am willing to commit to the following things: >> >> 1. fix any bugs or implement any features that are deemed as show >> stoppers with the current OTDebugger - i.e., the things that are >> preventing folks from getting work done today. >> >> 2. I also promise a quick response to any show stopper bugs that >> folks come across while doing development with the OTDebugger (or >> any other of the OB-Tools). >> >> I came to maintain the OB-Tools through the 'back door'. I use a >> branch the OB-Tools in GLASS and have decided to maintain the OB- >> Tools for the Squeak/Pharo community as a way to contribute back to >> the community. What that means specifically is that next to Lukas, I >> probably know more about the OB-Tools than anyone else, however, I >> don't have a laundry list of features that need to be added to the >> debugger. >> >> I could go through the Squeak debugger and duplicate all of the >> 'missing features', but my personal sense is that some of those >> features aren't useful - I know that I have not even read all of the >> menu items in the old Squeak debugger, let alone tried to figure out >> what they do... >> >> Getting a list of important/missing features from a small group is >> important to me (at least at the start). I don't have a personal >> sense of "what's missing" from the current OTDebugger, since I have >> not used the old Squeak debugger extensively. So getting feedback >> from "old hands" is important, but I also know that I won't be able >> to respond correctly to a general query for "what's missing from the >> debugger?" >> >> For direction towards the "120% debugger", I think it makes sense >> that you and rest of the Pharo leadership team make a list of >> "debugger franchise features" - i.e., a list of features that are a >> must have for the Pharo debugger and the other OB-Tools as well >> (BTW, if that list is to "duplicate all of the 'missing features'" >> then that's fine and I'm willing to do it). >> >> The debugger along with browsers are the face of the development >> environment and I don't want to bloat the debugger without at least >> a second opinion and I trust the opinions of you and the rest of the >> Pharo leadership team. >> >> Thanks, >> >> Dale >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 4, 2009

[Pharo-project] Fwd: On the OTDebugger...

by StÃ©phane Ducasse

So we should proceed that way: - Put a big warning + the expression to switch debugger in the pharo- dev - then we follow what dale is saying - I will produce a list of important features we need to have -- copy stack -- chase pointer ... in OT Is is ok for your community? Stef Begin forwarded message: > From: Dale Henrichs <dale.henrichs(a)gemstone.com> > Date: March 3, 2009 6:57:36 PM CEST > To: stephane.ducasse(a)inria.fr > Subject: On the OTDebugger... > Reply-To: dale.henrichs(a)gemstone.com > > Steph, > > This note isn't about your 'disable OB-debugger for now message', > but it is a response, of sorts to the ensuing discussion. > > If you want a '120% debugger' then folks working on Pharo need to > use the debugger and eat their own dogfood. It's the only way to > ensure that a tool like the debugger gets enough coverage to ensure > that it is stable. With that said, I wouldn't want to commit to > using a tool that was broken or that I couldn't depend upon. > > With that in mind, I am willing to commit to the following things: > > 1. fix any bugs or implement any features that are deemed as show > stoppers with the current OTDebugger - i.e., the things that are > preventing folks from getting work done today. > > 2. I also promise a quick response to any show stopper bugs that > folks come across while doing development with the OTDebugger (or > any other of the OB-Tools). > > I came to maintain the OB-Tools through the 'back door'. I use a > branch the OB-Tools in GLASS and have decided to maintain the OB- > Tools for the Squeak/Pharo community as a way to contribute back to > the community. What that means specifically is that next to Lukas, I > probably know more about the OB-Tools than anyone else, however, I > don't have a laundry list of features that need to be added to the > debugger. > > I could go through the Squeak debugger and duplicate all of the > 'missing features', but my personal sense is that some of those > features aren't useful - I know that I have not even read all of the > menu items in the old Squeak debugger, let alone tried to figure out > what they do... > > Getting a list of important/missing features from a small group is > important to me (at least at the start). I don't have a personal > sense of "what's missing" from the current OTDebugger, since I have > not used the old Squeak debugger extensively. So getting feedback > from "old hands" is important, but I also know that I won't be able > to respond correctly to a general query for "what's missing from the > debugger?" > > For direction towards the "120% debugger", I think it makes sense > that you and rest of the Pharo leadership team make a list of > "debugger franchise features" - i.e., a list of features that are a > must have for the Pharo debugger and the other OB-Tools as well > (BTW, if that list is to "duplicate all of the 'missing features'" > then that's fine and I'm willing to do it). > > The debugger along with browsers are the face of the development > environment and I don't want to bloat the debugger without at least > a second opinion and I trust the opinions of you and the rest of the > Pharo leadership team. > > Thanks, > > Dale >

March 4, 2009

[Pharo-project] New Compiler

by Jorge Ressia

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

March 4, 2009

Re: [Pharo-project] Unicode test II

by Serge Stinckwich

On Tue, Mar 3, 2009 at 2:11 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Hi all, > > after some interesting adventures in Unicode land here's a second > version of the unicode test image/app: > > http://impara.de/~michael/unicode-test.zip > > Things that I think should work: > - unicode text input on all platforms including support of composing > character sequences (.eg. US international keyboards) > - unicode clipboard handling > - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking > about it, only tested on Windows so far) It seems to work with a french keyboard on Mac OS X. I try with a vietnamese keyboard but i think i need a vietnamese font. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 4, 2009

Re: [Pharo-project] Preference refactoring again

by Matthew Fulmer

On Tue, Mar 03, 2009 at 06:58:26PM +0100, Alexandre Bergel wrote: > This will probably work and seems reasonable in a general context. > However, for our situation, I feel these are on different levels. > Preferences should be defined and taken into account in Pharo-core, > meaning without Magritte. Hmm. I'd think pharo-core would not have preferences. I was just suggesting it; it seems that once you implement enough to have generic boolean, string, or enumerable preferences, you basically have a watered-down magritte anyway. And who's to say we won't want a generic timezone, email address, or url preference in the future? Magritte can do those without having to rewrite string parsing/verification into every class. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 4, 2009

Re: [Pharo-project] Universes question

by Dale Henrichs

March 4, 2009

Re: [Pharo-project] Unicode test II

by Michael Rueger

Igor Stasenko wrote: > 2009/3/4 Michael Rueger <m.rueger(a)acm.org>: > scanMultiCharactersCombiningFrom: startIndex to: stopIndex in: > sourceString rightX: rightX stopConditions: stops kern: kernDelta > > method near following statement: > (encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [ hmm, could be that the encoding gets lost somewhere and so allows the code to enter the block. I think we rather need to test for charCode < 256 as the stopConditions are only of that size for any encoding AFAIK. Michael

March 4, 2009