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

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

by StÃ©phane Ducasse

Keith we understand your point. This is why I proposed to clean Installer and run SmallLint on it. and clean it again (no subclass references in superclass and other). Now did you said the same to Croquet, Sophie, Etoy people? why only to us? Then we have the right not to be happy with your infrastructural choices. Consider Pharo as insignificant and that squeak is the future. This way you do not have to blame us and we are happy. Stef On Mar 3, 2009, at 2:06 AM, Keith Hodges wrote: > Michael Roberts wrote: >> Keith, your email implies that you believe Pharo should be backwards >> compatible at some level with Squeak. Part of the Pharo manifesto is >> not to be compatible. So if you want to write code or have apis that >> work in a backwards direction from Pharo to Squeak, that's great. I >> don't believe it's a goal for Pharo though. The pharo process >> doesn't >> need a rethink at all as far as I'm concerned. >> >> thanks, >> >> Mike >> > No that is not what I am saying at all. Perhaps examples would help. > > Take Rio. Rio was designed from ground up to be a replacement for a > the > present non-modular kernel facility FileDirectory. It is a discrete > loadable module. > > Wild and horrible uses of FileDirectory are spread around the image in > lots of places, so one thing that Rio tries to do is to anticipate use > cases, so that the users of Rio dont have to implement File handling > code in their stuff, and so we help to keep the module boundary clear. > For example you can ask Rio to get you the next version of a file - > 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in > itself potentially lightens SmalltalkImage. If you want to read Xml > files, you can subclass File, with FileXML, define the > #validExtensions > that it handles, and implement contents/contents: This means that your > code only needs to send, 'myfile.xml' asFile contents, to get the > model. > There are all sorts of things like that. > > With Rio as a front end to File and Socket streams it is perfectly > possible to innovate on them without users of Rio being any the wiser. > If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it > was > Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' > asFile contents, now means that I dont have to care about whether > HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or > HTTPClient returning a MultiByteStream thingy in 3.8 or some other new > facility. > > So, Rio demonstrates that it is possible to innovate, on a kernel > module, and you dont need to break anything to do it. Secondly by > thinking about APIs and module interface abstractions in this way, you > can define specific interfaces and bottlenecks, that potentially turn > the ball of tangled string into something designed and architected. > There are perhaps hundreds of other modules that could use the same > treatment. > > Rio loads into all squeak images I have tried it in, so this then > means > that any of my file handling code will work in all images. This > benefit > comes from managing Rio as module external to the main image. Rio also > comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller > images in > mind. > > Having done this, the question of moving the kernel over to make use > of > the new code arises, this also can be achieved without breaking > anything > for users that have had Rio available for 2 years in every image that > their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, > Magma, Etoys, can all migrate their file handling code to the new Rio > API now, even if they are using Squeak 3.7/3.8, without having to > upgrade to the latest squeak. When they do update, they will be > pleased > to find that their file handling code works, as well as their > gzipping/archiving/remote file handling/and website accessing code. > > Installer follows the same principles, abstracting an api, freeing the > backend to be either old code or new code. If you dont have Universes > loaded, then defining Installer>>#universes to call #sake as a fall > back > would use Sake/Packages and get identical results, your users would be > none the wiser. If you dont have SqueakMap loaded, then defining > Installer>>#squeakmap to call #websqueakmap instead, would again give > your users identical results. and you thought that Installer was just > for loading things. Edgar has pointed out that you could use > CodeLoader > for that, but thats not the point of installer, Installer is > providing a > DSL for loading things that provides an architectural layer of > isolation, and thus both inherrent forward and backward > compatibility. I > expect my image building scripts to work identically with > Monticello2 in > squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7. > > Scripter (who here even knows that Scripter exists?) does the same, if > you want to write code to close or tile all the windows, after the > installing process has left a mess. Scripter can be the interface to > whatever backend GUI there happens to be whether it is > ToolBuilder/Tweak/Morphic. > > Same again with Logging, is a front end abstraction to all of the > three+ > logging backends out there. I can remove the hardwired calls to > Transcript that scatter the image and replace them with a single api > to > multiple backends, both past (Transcript) present (Syslog) and future > (seaside per-user session logging framework). > > Oh, and again with Sake/Packages.... why does Sake/Packages define > class > tasks? You can write a task that depends upon a task which removes > certain method selectors. You could just call Behaviour direct. Its > another architectural layer, that frees up the back end to be old or > new code as far as Sake task writers are concerned. I can write a task > that says, "if you find this Class with a method categorised as so, > then > it needs to be recategorised as such", in such a way as this task > would > run in all images. > > Oh and again SystemEditor... another layer of abstraction for > compiling > and loading code atomically. > > So if you think about it, those who know about the compiler could be > considering how to write their stuff, so that it logs to the Kernel > Logging API (which is valid even if Logging isnt Loaded). They might > consider connecting to SystemEditor in preference to providing a > direct > api, and another abstracted pluggable Module is needed to handle > source > code files (replacing RemoteString/ChangeSets etc), with Rio as the > local/remote file API. > > Do you get the idea now? > > For the same treatment to be available for more significant chunks of > squeak, we would need atomic loading to work. Now the code to provide > atomic loading for everyone has been available for over a year, and it > works if you dont use traits. So where is the expertise to really > get it > working for everyone with traits? > > The only difficulty with this approach is that you might need slightly > different bits to make your NEW code load into older images. This > problem is reasonably easily addressed with Installer-Scripts > (LevelPlayingField+) and Sake/Packages. > > I fully agree with Matthew about core packages like Collections. BUT > and > this is the big but. If you are going to do that kind of thing, you > need > to think about it, plan it, and create and participate in a process > that > supports everyone is diverse images using and testing that package. > From > what I have seen there is only one person on the Pharo team that > understands what LevelPlayingField is for, and how to use it. > > The biggest risk to this approach is if some other folks decide to > fork > some significant architectural component in a completely incompatible > manner, without thinking about any bigger picture at all. > > Matthew's comment about how our tools are only just getting there isnt > that relevant to the point that I am making. I didnt need a test and > build server to innovate Rio for everyone rather than just for the > image > I am using (trouble was I was using 3 different images), all I needed > was an inclusive attitude rather than an exclusive attitude. > > cheers > > Keith > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2009

Re: [Pharo-project] Universes question

by Alexandre Bergel

>> disable OB-debugger for now. > > the latest version is quite good. I would prefer you try it before I > remove it. What do you think? Few people around me were reluctant to use pharo-dev because of the debugger. I am for a new debugger, but maybe it was a bit premature. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by Alexandre Bergel

> BTW, the keyboard shortcut (w) indicated with "tally it" and also with > "watch it" does not work; it closes the window! I was not aware of this. What would be a good keybinding? Maybe I can suppress the keybidding for tallyIt. Cheers, Alexandre > > > On Mar 3, 2009, at 12:30 , StÃ©phane Ducasse wrote: > >>> >>> >>> 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 >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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 3, 2009

Re: [Pharo-project] Preference refactoring again

by Alexandre Bergel

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. Cheers, Alexandre On 2 Mar 2009, at 18:03, Matthew Fulmer wrote: > On Mon, Mar 02, 2009 at 01:59:03PM +0100, Alain Plantec wrote: >> or simply : >> >> FreeTypeSettings class>>monitorTypeLCD >> <preference:'LCD monitor type' type:#Boolean decsription:'Use of a >> LCD...'> >> ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue >> default:false] > > Did anybody ever notice my suggestion to use Magritte for > Preferences? > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.h… > > ----- Forwarded message from Matthew Fulmer <tapplek(a)gmail.com> ----- > > From: Matthew Fulmer <tapplek(a)gmail.com> > To: pharo-project(a)lists.gforge.inria.fr > Date: Mon, 16 Feb 2009 15:15:55 -0500 > Subject: Re: [Pharo-project] Preferences refactoring > > On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote: >> On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote: >>> So, for new browser it needs to be decided what information to >>> show as this >>> will affect the pragma. >>> For instance, do we still want categories, "project >>> specific" (probably not) >>> etc. >>> >>> I expect we will want a Preference class either way to model each >>> preference >>> in the browser. >>> Making a new browser is quite an undertaking given the different >>> types of >>> preference (boolean, text, one-of-many, colour, font etc.). >> >> I think Magritte is the proper solution. It already handles UI >> metadata like this. > > Something like this: > > prefTheme > <preference category: 'User Interface'> > ^ MASingleOptionDescription new > options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); > reference: MAStringDescription new; > autoAccessor: 'theme'; > label: 'Theme'; > priority: 40; > beSorted; > yourself > >> Regarding preferences being optional, I think just a few tweaks >> to the MC loader would work: If the Preferences Browser is not >> loaded, MC will not compile the methods that return the Magritte >> metadata. If this is done properly, as in MC1.5, these methods >> will hang out uncompiled in the orphanage until you load the >> preferences package, at which point they will be loaded into the >> image. > > This is completely wrong. In the above example, if Magritte was > not loaded, MASingleOptionDescription will bind to Undeclared. > Then, if Magritte is ever loaded, it will notice the reference > in Undeclared, and recompile this method to act correctly. > >> Out-of-order package loading is nice. > > Out-of-order loading, in the form of global references, has been > supported since smalltalk-76 by the Undeclared object. > > The MC1.5 orphanage supports another kind of out-of-order > loading, in addition to that supported by Undeclared. But it is > irrelavant in this example. > > ----- End forwarded message ----- > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2009

Re: [Pharo-project] OB Browser "Manual"

by Rob Rothwell

Although...I was just looking for how to USE the browser, not write another one! Rob On Tue, Mar 3, 2009 at 12:20 PM, Rob Rothwell <r.j.rothwell(a)gmail.com>wrote: > Great! Thank you very much! > > Rob > > > On Tue, Mar 3, 2009 at 12:12 PM, Alexandre Bergel < > Alexandre.Bergel(a)inria.fr> wrote: > >> Hi Rob, >> >> A chapter on OB will be available in "Pharo by Example". >> A draft is available on: http://www.bergel.eu/Omnibrowser.pdf >> Feel free to comment on it. >> >> Cheers, >> Alexandre >> >> On 3 Mar 2009, at 17:12, Rob Rothwell wrote: >> >> > Is there a guide to using the OB Browser (and associated tools for >> > that matter...debugger, etc...) anywhere? >> > >> > I KNOW I am not getting the most out of it! >> > >> > Rob >> > _______________________________________________ >> > 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 3, 2009

Re: [Pharo-project] OB Browser "Manual"

by Rob Rothwell

Great! Thank you very much! Rob On Tue, Mar 3, 2009 at 12:12 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr > wrote: > Hi Rob, > > A chapter on OB will be available in "Pharo by Example". > A draft is available on: http://www.bergel.eu/Omnibrowser.pdf > Feel free to comment on it. > > Cheers, > Alexandre > > On 3 Mar 2009, at 17:12, Rob Rothwell wrote: > > > Is there a guide to using the OB Browser (and associated tools for > > that matter...debugger, etc...) anywhere? > > > > I KNOW I am not getting the most out of it! > > > > Rob > > _______________________________________________ > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2009

Re: [Pharo-project] OB Browser "Manual"

by Alexandre Bergel

Hi Rob, A chapter on OB will be available in "Pharo by Example". A draft is available on: http://www.bergel.eu/Omnibrowser.pdf Feel free to comment on it. Cheers, Alexandre On 3 Mar 2009, at 17:12, Rob Rothwell wrote: > Is there a guide to using the OB Browser (and associated tools for > that matter...debugger, etc...) anywhere? > > I KNOW I am not getting the most out of it! > > Rob > _______________________________________________ > 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 3, 2009

Re: [Pharo-project] loadOBApha

by David RÃ¶thlisberger

>> - evaluate "ScriptLoader loadOBApha" in latest #10246 >> - open a new browser and use "OBPackageBrowserAdapter" >> - in the browser select a package, then a class and click on the >> "UML Diag." in the button pane >> You should see a red rectangle with a yellow cross (draing error) >> due to a DNU on nil >> It also throws an error if no package is selected and the button >> is used. I fixed those two problems. You can load the updates with 'ScriptLoader loadSuperOB'. David

March 3, 2009

Re: [Pharo-project] [squeak-dev] Re: HTTPSocket

by CÃ©drick BÃ©ler

2009/3/3 Michael Rueger <m.rueger(a)acm.org>: > GÃ¶ran Krampe wrote: >> >> Hi! >> >> What about perhaps looking at what has already been done, like: >> >> http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f >> http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040 > As we are here, I wonder if this is related. In the NetSqueak package [1], there is InternalSocket subclassed InternalUDPSocket and InternalTCP socket. It would be good the new implementation allows to load this package (and to have an "official" network package). Cheers [1] http://www.squeaksource.com/Net.html > I used and adapted the second one IIRC. For reasons that I can't recall > right now I liked it better :-) > > Michael > > -- CÃ©drick

March 3, 2009

[Pharo-project] OB Browser "Manual"

by Rob Rothwell

Is there a guide to using the OB Browser (and associated tools for that matter...debugger, etc...) anywhere? I KNOW I am not getting the most out of it! Rob

March 3, 2009