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

[Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas
by CÃ©drick BÃ©ler March 4, 2009

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

Re: [Pharo-project] Fwd: On the OTDebugger...
by Dale Henrichs March 4, 2009

March 4, 2009

----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> 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 For 'copy stack', check out 'error report' in OB-Tools-dkh.65. Part of the error report is a stack dump ... I could change the name and/or produce only a stack. Dale

2 2

[Pharo-project] Seaside working on Pharo
by Damien Cassou March 4, 2009

March 4, 2009

Hi, I've just written a small Installer-based script to install Seaside2.8 into Pharo image. Load the latest ScriptLoader from PharoInbox and do: ScriptLoader loadSeaside Unfortunately, this crashed my unix VM 2 times with the following message: squeak: /home/piumarta/squeak/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted Sometimes it works though. To make it work more reliably, I pass '-memory 512m' to the VM. -- Damien Cassou http://damiencassou.seasidehosting.st

3 5

[Pharo-project] A point a.k.a excuse to you
by StÃ©phane Ducasse March 4, 2009

March 4, 2009

Hi guys I probably should not have forwarded to you the email I replied to matthew but I was thinking that other people can know that I was personally touched by the situation in Squeak. I'm sorry about. We got a lot of bird names and others. Recently somebody was implying that marcus was bashing squeak because he sent an email on the pharo mailing-list stating that the situation for keyboard was worse in squeak. I'm fed up. I'm interested in pharo because I want to create free and good energy. We did a lot in the past and I want to continue. Now I unregistered from the squeak mailing-list and I will not justify anymore why I quit. Now I want pharo to be cool. Stef

15 52

[Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu
by StÃ©phane Ducasse March 4, 2009

March 4, 2009

> > > From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> > Date: March 2, 2009 11:00:09 PM CEST > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: about adding chasing pointers and friends in the debug menu > > > Hi > > we can only access pointer finder and chase pointer from the > inspector menu and it would be nice to > have that much more accessible. > What do you think? > > Stef > > >

6 18

[Pharo-project] Fwd: On the OTDebugger...
by StÃ©phane Ducasse March 4, 2009

March 4, 2009

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 >

4 3

March 4, 2009

Hi guys I discussed with gwenael about the parsing of the complete image to remove _ and strange character. Apparently there is an issue related to numbers. He will certainly post more information but we will have to think about that. Stef

1 0

Re: [Pharo-project] Preference refactoring again
by Alain Plantec March 4, 2009

March 4, 2009

Gary Chambers a Ã©crit : > In that case perhaps the setter should expect a PreferenceValue or > native and internally store > one after setting its value. > > Not quite clear what should be stored in the class var from the code > snippet. > > Perhaps the following is simpler if the PreferenceValue does the > handling: > > FreeTypeSettings class>>monitorTypeLCD > <preference: 'LCD monitor type' type: #Boolean defaultValue: false > description: 'Use of a LCD...'> > ^ MonitorTypeLCD > ifNil: [MonitorTypeLCD := PreferenceValue value: false] > > Then to get is > > FreeTypeSettings monitorTypeLCD value > > and to set is > > FreeTypeSettings monitorTypeLCD value: true yes, it is better > > the PreferenceValue handles the notifications... > > FreeTypeSettings class>>initialize > self monitorStyleLCD when: #valueChanged send: > #monitorTypeLCDPreferenceChanged: to: self > > PreferenceValue>>value: anObject > realValue ~= anObject > ifTrue: [realValue := anObject. > self triggerEvent: #valueChanged with: anObject] cool, better again happy to learn :) > > Tools can just pick up the pragma and not have to worry about setters, > "location" etc. ok > Perhaps the PreferenceValue could hold the types/description too to > help tools... > > FreeTypeSettings class>>monitorTypeLCD > <preference> > ^ MonitorTypeLCD ifNil: [ > MonitorTypeLCD := PreferenceValue > name: 'LCD monitor type' > type: #Boolean > value: false > default: false > decsription: 'Use of a LCD...'] could be ok for me, anyway what do you think of: FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value: false default: false] Name, type and description are only useful from PreferenceBrowser point of view (preference helper) whereas a PreferenceValue is concerned by its value and its default. > > Here the pragma is a simple marker to identify the selector as a > preference returner. > > Of course, deliberately overwriting the class var directly will mean > that notification subscribers will become disassociated... If I well understand, I consider this as a bad pratice which should be detected by a lint rule. so, it is not a problem for me Cheers Alain > > > Simpler the better perhaps though. > > Regards, Gary > > ----- Original Message ----- From: "Alain Plantec" <beranger22(a)gmail.com> > To: "Gary Chambers" <gazzaguru2(a)btinternet.com> > Sent: Monday, March 02, 2009 11:05 AM > Subject: Re: [Pharo-project] Preference refactoring again > > >> Gary Chambers a Ã©crit : >> >> Hi Gary, >>> Looks good. Is there really a need for a PreferenceValue class though? >>> >>> I'm concerned that the getter returns a different kind of object to >>> that expected by the setter... >> yes, ok >> >> FreeTypeSettings class>>monitorTypeLCD >> <preference: 'LCD monitor type' type: #Boolean set: >> #monitorTypeLCD: defaultValue: false description: 'Use of a LCD...'> >> ^ (MonitorTypeLCD >> ifNil: [MonitorTypeLCD := PreferenceValue value: false >> location: self selector: #monitorTypeLCD]) value >> >>> For any preference tool the presence of the pragma is sufficient to >>> get/set the native value and, assuming always class-side, support >>> event triggering for changes. >> I'm not sure to understand. >> you suggest a solution like this ? : >> FreeTypeSettings class>>monitorTypeLCD: aBoolean >> monitorTypeLCD := aBoolean. >> self triggerEvent: #monitorTypeLCD with: aBoolean >> >> Of course, then you do not need PreferenceValue. >> But I prefer PreferenceValue solution because it encapsulates the >> triggerEvent, the developper do not have to deal >> with it and it is more evolutive (it is easy to change the way events >> are triggered or to change the notification framework). >> >> regarding the pragma use, I see it as only useful from supporting >> tools (PreferencesBrowser...). >> but maybe I'm wrong, let me know. >> >> Cheers >> Alain

5 9

March 4, 2009

Hi can someone check http://code.google.com/p/pharo/issues/detail?id=520 Thanks

10 50