- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Announcements for Pharo?

by Lukas Renggli

If you include it, please take the latest version Announcements-lr.13 from <http://source.lukas-renggli.ch/announcements/>. I added a comment pointing to Vassili's blog and improved the tests. Furthermore I removed the class StateMachine (described here <http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?entry=3346524723>) that I don't think is a license clean re-implementation. If we need it, somebody should read the blog and re-implement it without looking at the code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 2, 2009

Re: [Pharo-project] SortedCollection>>median

by Adrian Lienhard

On Mar 2, 2009, at 09:00 , StÃ©phane Ducasse wrote: > This reminds me some thoughts about time and date. > > Originally date and time were ok but not so great. > Then one guy (brent) fixed it and people were happy and it was > introduced in the base system. > At that time when time was introduced (in 3.7 I guess) it was a > obvious choice. > Then chronos and aconcagua went out showing some other properties. > > Now retrospectively I think that it would be better to have a minimal > version in the system and > loadable external package. There are some exceptions to this strategy: > announcements and regexp > (where this is more a language decision), but in general this is a > good strategy I think a good rule of thumb is whether the code is used by the kernel. Having packages like Regex and Announcements in the core makes only sense if they are also used in the core. Else they would better be external packages. Not sure about median, though, as for just one method you wouldn't want to create and load an extra package... Adrian > > > So we could rename median naiveMedian and have a package that does all > the rest and > that people can load it. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2009

Re: [Pharo-project] What are the ERROR messages in the Transcript Window in 10243?

by Damien Cassou

On Sun, Mar 1, 2009 at 5:22 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> wrote: > Should I post an issue? No, it's already fixed. Please update OB-Enhancements or wait for the next pharo-dev. -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

Re: [Pharo-project] Dynamic dead code alpha version

by Adrian Lienhard

On Mar 2, 2009, at 09:06 , StÃ©phane Ducasse wrote: >>>> I continued to code a little tool based on code of Alain to detect >>>> deadcode, so far I'm too sick to have clear >>>> idea why it freezes on Morph. >>> >>> This kinda reminds me of that moment in the horror film when you >>> want to >>> yell "Don't go in there!" at the characters on the screen. >> >> lol >> >> Except that you should do it from within the film itself and sit down >> watching ourselves. >> :) > > May be I should use reflectivity or byesurgeon for that. ...or use objects as methods or method wrappers. I did a quick experiment with the package http://www.squeaksource.com/ObjectsAsMethodsWrap.html from Markus GÃ¤lli. Just had to fix the send of #removeSeletorSimply: with #removeSelectorSilently: to make it work (@Markus, could you add this or give me write access?). ((PackageInfo named: 'Morphic') classes gather: [ :each | ObjectAsOneTimeMethodWrapper installOnClass: each ]) inspect gets you a collection of wrapper objects which you can ask #executed. I opened all tools and menus in the image and got 2100 methods executed out of 6518. HTH, Adrian > > But I'm curious to see until where we can go expecially since > the dnu method and automatic recompilation is in place before > transforming > the methods. > > Something else which is striking is that it is easier to redo a root > hierarchy than > doing a root morph > > ProtoObject subclass then.... > > doesNotUnderstand: aMessage > > | sel category | > sel := aMessage selector. > Transcript show: 'Does not understand ', aMessage selector > printString ; cr. > category := (Morph organization categoryOfElement: sel). > self class compile: (Morph sourceCodeAt: sel) classified: category. > ^ aMessage sentTo: self. > > works for Object but not for Morph. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Geert a Ã©crit : > Hi Alain, this sounds very interesting. thanks > I have never been a big fan of the > current "Preference Browser". The main problem with current preference system is that it makes uses of globals (declared in the class side of Preferences) and that a lot of packages depend on it. The main goal of the refactoring is to make preferences local to the packages in which they are declared. Current preference browser is not that bad and could be reused. > I am now trying to grasp (still learning > here) how this new "Pharo Preference Mechanism" works.It would be great if > the mechanism could be explained in detail in something like the new Pharo > By Example manual :) > Each preference is stored by a PreferenceValue instance and each time a PreferenceValue is updated (with a #value: message sent) an event is sent to the class which defines the preference. The event sending is standard: PreferenceValue>>value: anObject realValue ~= anObject ifTrue: [realValue := anObject. location triggerEvent: selector with: anObject] realValue is the instance variable wich stores current preference value. location is the class which declares the preference selector is the selector of the preference (i.e. #gradientButtonLook) So my proposition is to declare a preference locally. Let's take the example of freetype monitorTypeLCD preference. If we implement it the way it is now, as a boolean, it could be: --------------- 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] FreeTypeSettings class>>monitorTypeLCD: aBoolean self monitorTypeLCD value: hintingFull FreeTypeSettings class>>initialize FreeTypeSettings when: #monitorTypeLCD send: #monitorTypeLCDPreferenceChanged: to: self. FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean self current monitorTypeLCDPreferenceChanged: aBoolean ------------- The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only here for UI tools such as PreferenceBrowser. If a client object needs monitorTypeLCD value, it asks directly to its provider which is FreeTypeSettings class: ... useLCD := FreeTypeSettings monitorTypeLCD value. ... but note that such a preference should be set as a choice between two values #LCD or #CRT... hope things are a little bit clearer now. alain > > Alain Plantec wrote: > >> I've joined 4 packages : >> - PrefCore contains PreferenceValue which is now the only mandatory class. >> >> 2 packages for testing: >> - PrefProvider contains PrefProvider class which declares some preferences >> - PrefUser contains PrefChangeListener (try PrefChangeListener test). >> >> 1 package for UI: >> - PrefTool contains PreferenceCollector and PreferenceDefinition. They >> are optional. >> >> > >

March 2, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by StÃ©phane Ducasse

>> Let me apologize on behalf of the squeak-dev community. Not all > of us feel so harshly toward you, but I did not speak up enough to > convince you of our appreciation. You deserve better, and I'm > sorry we did not deliver it. Don't worry. I did not react because of harsh statements. I reacted because I could send your email while I should not and this indicating me that I was influenced by my reading on squeak-dev (you see this was meta). We have been there and we know what it is. >> Making Pharo the best it can be will be a win for everyone, even if >> some do not see it that way at the time. > > I plan to work with Pharo soon, probably once summer starts and > school is out, to get Keith's tools debugged and working in the > context of Pharo, especially Monticello 1.6 (My patches to MC1.5 > to enable real atomic loading (= no more problems upgrading > Polymorph), and Bob (the automated image builder and regression > tester). > > I know this is deep stuff, but I believe an automated image > builder will have several advantages, both for you, as Pharo > developers, and for me, as an enthusiast for cross-squeak > compatibility: > - making releases is faster > - Regression bugs are caught faster > - the scripts serve as poor-man's code sharing between squeak > distributions until we have real package-level sharing of core > code between core Yes we know. BTW matthew could you run SmallLint on Installer. I was thinking to do that and fix what I could. May be we could pair on this one. > You may or may not know, but I am a core Cobalt developer, and I > hope to bring Pharo and Cobalt much closer together. These two > projects are hosting many core changes to the image, with little > regard to backward compatibility. We may even get tweak to the > level where it is a compelling replacement for Morphic, and I > want Pharo to benefit from that if it does indeed happen. Too > many improvements to Squeak happen in the dark (Newspeak, > Spoon), and we can ill afford to estrange the truly open > projects from each other (Pharo and Cobalt, IMO). Cobalt is the open version of Croquet? You are working with Julian? We would be happy to evaluate changes made in Cobalt and retrofit them into pharo. Now for Tweak this is another story. >> Thanks for doing this! > > Yes, thank you Stef and Marcus for rekindling the passion for > Smalltalk in many people. With luck, squeak.org may be a free, > open, and useful product again. Too long has it been stuck, with > nobody to bring it forward. Pharo has done much to re-awaken the > love of smalltalk in many people, and that, if nothing else, is > a gift beyond measure. As Squeak.org release team leader, you > have my goodwill and my support. I will do what I can to spread > the gifts of your efforts to the rest of squeak, and bring their > efforts to you. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 2, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by StÃ©phane Ducasse

I know you are right. But I will take some holidays :) I saw that you are bold to discuss with some people. >> > Stephane, i don't know who were tempting your patience, but this is > not really matters. > I don't think that such little noise should be a reason for quitting > from the list. > Smalltalkers are few, and most of them are kind people. I think you > are interesting in things which happening around. And you willingly > losing a source of information just because someone put blames on > marcus. Come on.. just ignore it. > > I was a witness of quitting a Tim Rowledge from squeak community and > from squeak board.. We were discussed one little thing, arguing with > each other.. and then boom.. he says that he fed up and quits. And > since then i feel a responsibility for starting a discussion which was > led to such outcome. > I think that decision whether quit or not and why, should be based on > more pragmatic matters and should be well weightened, rather than > based on a mere random insult :) Yes you are right. I'm impulsing and the flue does not help me but right now I'm calm. lot of people did not understand how difficult it was to do squeak3.9 trying to do the best we could and then be bashed by people that did not want to see the situation changes or mere idiots. Anyway. you are right. Stef

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by StÃ©phane Ducasse

On Mar 2, 2009, at 4:44 AM, Geert wrote: > > Hi Alain, this sounds very interesting. I have never been a big fan > of the > current "Preference Browser". I am now trying to grasp (still > learning > here) how this new "Pharo Preference Mechanism" works. It would be > great if > the mechanism could be explained in detail in something like the new > Pharo > By Example manual :) this is a great idea. if it is adopted I will write it. > > Alain Plantec wrote: >> >> I've joined 4 packages : >> - PrefCore contains PreferenceValue which is now the only mandatory >> class. >> >> 2 packages for testing: >> - PrefProvider contains PrefProvider class which declares some >> preferences >> - PrefUser contains PrefChangeListener (try PrefChangeListener test). >> >> 1 package for UI: >> - PrefTool contains PreferenceCollector and PreferenceDefinition. >> They >> are optional. >> > > -- > View this message in context: http://n2.nabble.com/Preference-refactoring-again-tp2403814p2407403.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 2, 2009

Re: [Pharo-project] Dynamic dead code alpha version

by StÃ©phane Ducasse

>>> I continued to code a little tool based on code of Alain to detect >>> deadcode, so far I'm too sick to have clear >>> idea why it freezes on Morph. >> >> This kinda reminds me of that moment in the horror film when you >> want to >> yell "Don't go in there!" at the characters on the screen. > > lol > > Except that you should do it from within the film itself and sit down > watching ourselves. > :) May be I should use reflectivity or byesurgeon for that. But I'm curious to see until where we can go expecially since the dnu method and automatic recompilation is in place before transforming the methods. Something else which is striking is that it is easier to redo a root hierarchy than doing a root morph ProtoObject subclass then.... doesNotUnderstand: aMessage | sel category | sel := aMessage selector. Transcript show: 'Does not understand ', aMessage selector printString ; cr. category := (Morph organization categoryOfElement: sel). self class compile: (Morph sourceCodeAt: sel) classified: category. ^ aMessage sentTo: self. works for Object but not for Morph. Stef

March 2, 2009

Re: [Pharo-project] SortedCollection>>median

by StÃ©phane Ducasse

This reminds me some thoughts about time and date. Originally date and time were ok but not so great. Then one guy (brent) fixed it and people were happy and it was introduced in the base system. At that time when time was introduced (in 3.7 I guess) it was a obvious choice. Then chronos and aconcagua went out showing some other properties. Now retrospectively I think that it would be better to have a minimal version in the system and loadable external package. There are some exceptions to this strategy: announcements and regexp (where this is more a language decision), but in general this is a good strategy So we could rename median naiveMedian and have a package that does all the rest and that people can load it. Stef

March 2, 2009