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

[Pharo-project] Pharo-Core, Pharo, Pharo-Dev, Squeak-Dev ...

by Geert

I just noticed that release 10236 is now available for download on https://gforge.inria.fr/frs/?group_id=1299 gforge.inria.fr . To avoid confusion, the project file releases probably needs some cleaning up. Is having the old Squeak and/or Sapphire labeled releases still useful? On the Pharo-Project site it describes "Pharo" as the bundle of "Pharo-Core" + "IDE Tools". On the download site the file releases with "Pharo-Core" in their name are under "Pharo" ... and then there are also the Pharo-Dev and Squeak-Dev image releases. Its probably not a big deal and everyone is flat out doing the actual important stuff but I thought I'd mention it anyway as it may cause some confusion :) It may also be useful to include a list of the packages (package name, version, package description) which are part of the release in the release notes file (above the "Changes" section). -- View this message in context: http://n2.nabble.com/Pharo-Core%2C-Pharo%2C-Pharo-Dev%2C-Squeak-Dev-...-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 19, 2009

Re: [Pharo-project] Debugging with morphic

by Alexandre Bergel

I agree with you Marcus... Alexandre On 18 Feb 2009, at 23:19, Marcus Denker wrote: > > On 18.02.2009, at 22:46, Michael Roberts wrote: > >> Did Marcus not write some code a while ago that checked the context >> before raising the error? > > I extended #haltIf: to check the selectors of methods on the stack. > (This way one can put a halt into OrderedCollection>>add:, for > example). > > I think that behind this is some very important basic concept... > Something like the idea that the world should not look the same from > everywhere. > E.g, one wants to be able to debug the UI and restrict the visibility > of the > breakpoints (and even then the code one changes) to the debug session. > > Nice area of research, we did some stuff that is related e.g. > > http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk07c > http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk08b > > Much more is needed, both in terms of pure conceptual research and > then > especially in making in "real". > >>>> Another thing that can be very helpful is a class called Once. It >>>> can be #reset and is used something like (if there is interest I >>>> can >>>> look for it) >>>> >>>> Once do:[ >>>> self halt. >>>> ]. > > There is #haltOnce in Pharo (and in Squeak, at least in 3.9). > > Marcus > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 18, 2009

Re: [Pharo-project] Debugging with morphic

by Marcus Denker

On 18.02.2009, at 22:46, Michael Roberts wrote: > Did Marcus not write some code a while ago that checked the context > before raising the error? I extended #haltIf: to check the selectors of methods on the stack. (This way one can put a halt into OrderedCollection>>add:, for example). I think that behind this is some very important basic concept... Something like the idea that the world should not look the same from everywhere. E.g, one wants to be able to debug the UI and restrict the visibility of the breakpoints (and even then the code one changes) to the debug session. Nice area of research, we did some stuff that is related e.g. http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk07c http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk08b Much more is needed, both in terms of pure conceptual research and then especially in making in "real". >>> Another thing that can be very helpful is a class called Once. It >>> can be #reset and is used something like (if there is interest I can >>> look for it) >>> >>> Once do:[ >>> self halt. >>> ]. There is #haltOnce in Pharo (and in Squeak, at least in 3.9). Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 18, 2009

Re: [Pharo-project] Debugging with morphic

by Michael Roberts

Did Marcus not write some code a while ago that checked the context before raising the error? or am I imagining that. I thought we could check the sender chain and prevented triggering. i.e if you are inside a particular call chain. In VW I had to just learn to not put breakpoints high up in the UI hierarchy but the system could be more clever. cheers Mike On Sun, Feb 15, 2009 at 8:15 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Thanks Bill, > > Reading your post was indeed useful > > Alexandre > > > On 14 Feb 2009, at 21:37, Schwab,Wilhelm K wrote: > >> Gary, Alexandre, >> >> I have long advocated an approach to this in the Dolphin community - >> not sure how many people have really adopted it, but the same ideas >> should work here. Gary just hit a big part of it - set yourself up >> to do something dangerous (don't do it yet), save, then try it. If >> it blows up, learn what you can, close, and try again. >> >> In Dolphin, the debate surrounds view subclasses. I submit that >> most of them are unnecessary, as an image presenter can do the job. >> There are exceptions, but probably not many with a little >> creativity. The trick then is to generate code that draws on a >> canvas. Start out with a bitmap that you do not even expect to >> display. The debugger says hello, and no real harm is done. When >> the notifiers cease, it's time to actually look at the image. More >> fun, and perhaps some iteration, but nothing bad really happens. >> Once it runs and is correct, it can go into a standard presenter. >> The alternative of making a view puts the system increases risk >> unless one protects the drawing to ensure the view ends up in a sane >> state. >> >> Another thing that can be very helpful is a class called Once. It >> can be #reset and is used something like (if there is interest I can >> look for it) >> >> Once do:[ >> self halt. >> ]. >> >> with the predictable result - one pass through the offending code >> halts, the rest go merrily onward until a Once reset occurs. >> >> Here's hoping that was worth the time you wasted reading it :) >> >> Bill >> >> >> ---- >> Wilhelm K. Schwab, Ph.D. >> bschwab AT anest DOT ufl DOT edu >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr >> ] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] >> Sent: Saturday, February 14, 2009 2:03 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Debugging with morphic >> >> More often than not the emergency evaluator can save you from having >> to >> reload changes... >> Otherwise, save often after careful consideration and before likely >> dangerous changes. Not a huge hassle to relaunch and load the last >> changes >> either though. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Alexandre Bergel" <alexandre(a)bergel.eu> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 14, 2009 6:29 PM >> Subject: Re: [Pharo-project] Debugging with morphic >> >> >>> I was just wondering how you guys debug your morphic programming. >>> There is probably something wrong in the way I do. I cannot imagine >>> people have been doing some morphic for so long without having a >>> simple way to debug it. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 14 Feb 2009, at 18:26, Gary Chambers wrote: >>> >>>> I'm sure I can come up with something... you obvioulsy want some >>>> kind of >>>> debugger if an error occurs. >>>> The taskbar works effectively synchronously with the display and >>>> should >>>> handle self inflicted errors. >>>> Other display errors *should* get managed by the #errorOnDraw thing, >>>> but not >>>> always it would seem. >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- >>>> From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> >>>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Saturday, February 14, 2009 4:53 PM >>>> Subject: [Pharo-project] Debugging with morphic >>>> >>>> >>>>> Hi All (and especially the Pinesoft crew), >>>>> >>>>> When an error is triggered by a displayOn: method, the bottom bar >>>>> is >>>>> being filled with debugger windows. It then become hardly >>>>> debuggable. >>>>> Ideally, the system should not display a window if an error is >>>>> triggered in the displayOn. >>>>> >>>>> Do you have any recommandation/conviention/enhancement to prevent >>>>> the >>>>> image to hang when an error is signaled in a displayOn. This is >>>>> really >>>>> annoying. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 18, 2009

Re: [Pharo-project] Question about Universes

by David RÃ¶thlisberger

> On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> Omnibrowser gets installed, where it should not. Where is the >> definition of this Universe stored? > > Without thinking and checking: ShoutOmnibrowser depends on > Omnibrowser, that's why OB is installed. yes, but obviously this dependency did get loaded in older Pharo versions, but now in the very latest version it does - why, what got changed? Does anyone know? David

Feb. 18, 2009

Re: [Pharo-project] ??? OB loading???

by David RÃ¶thlisberger

> When I load that in the latest image I get a topPanel DNU > I do not understand how to fix it. See the latest two threads of Alex. The problem lies not in OB, but in how it gets loaded. Something changed in this process, related to Universe, but we do not yet know what exactly. David > > | instClass | > instClass := self environment at: #Installer ifAbsent: [self new > installingInstaller]. > > self new universalInstaller universe > update; > addPackage: 'Shout'; > addPackage: 'AST'; > addPackage: 'Refactoring Core'; > install. > > "load latest alpha version of OB directly from its Monticello repo" > instClass wiresong > project: 'ob'; > install: 'OmniBrowser'; > install: 'OB-Standard'; > install: 'OB-Morphic'; > install: 'OB-Enhancements'; > install: 'OB-Refactory'. > > self new universalInstaller universe > addPackage: 'ShoutOmniBrowser'; > addPackage: 'eCompletion'; > addPackage: 'eCompletionOmniBrowser'; > addPackage: 'eCompletion-Traits'; > install. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 18, 2009

Re: [Pharo-project] loadOBAlpha

by David RÃ¶thlisberger

>>>>> self new universalInstaller universe >>>>> addPackage: 'ShoutOmniBrowser'; >>>>> addPackage: 'eCompletion'; >>>>> addPackage: 'eCompletionOmniBrowser'; >>>>> addPackage: 'eCompletion-Traits'; >>>>> install. > > install an older version of OB, overriding the loading instruction > located before in the method. But that's new, it didn't use to do that. What got changed to make it behave like that? Did someone change the dependencies of these package in Universe? Like this it gets hard to rely on Universe if suddenly dependencies get introduced that have been defined before. David > On 18 Feb 2009, at 15:13, David RÃ¶thlisberger wrote: > >>> This is quite strange. >>> Executing ScriptLoader loadOBAlpha loads OB-Strandard-dr.389 instead >>> of the last version. Do you want me to dive into this? >> yes, please. In particular as it does not for me, so I cannot >> reproduce this. >> I remember Gary had a similar problem, but we then assumed it was >> because he has >> locally changed something in that particualr package (I guess it was >> OB-Morphic), so >> that's why the package didn't get updated. But I guess this is not >> the case here. >> >> David >> >> >> >>> On 18 Feb 2009, at 11:51, David RÃ¶thlisberger wrote: >>> >>>>> I obtained the error by taking a fresh a 10231, did a system update >>>>> and doit "ScriptLoader loadOBAlpha" >>>>> Does it really work with you? There is no implementor of topPanel. >>>> Which version of OB-Standard do you have loaded in your image after >>>> the doit? >>>> dr.395 brings OBCodeBrowser class >> topPanel. >>>> >>>> David >>>> >>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>> loadOBAlpha >>>>> "self loadOBAlpha" >>>>> >>>>> | instClass | >>>>> instClass := self environment at: #Installer ifAbsent: [self new >>>>> installingInstaller]. >>>>> >>>>> self new universalInstaller universe >>>>> update; >>>>> addPackage: 'Shout'; >>>>> addPackage: 'AST'; >>>>> addPackage: 'Refactoring Core'; >>>>> install. >>>>> >>>>> "load latest alpha version of OB directly from its Monticello >>>>> repo" >>>>> instClass wiresong >>>>> project: 'ob'; >>>>> install: 'OmniBrowser'; >>>>> install: 'OB-Standard'; >>>>> install: 'OB-Morphic'; >>>>> install: 'OB-Enhancements'; >>>>> install: 'OB-Refactory'. >>>>> >>>>> self new universalInstaller universe >>>>> addPackage: 'ShoutOmniBrowser'; >>>>> addPackage: 'eCompletion'; >>>>> addPackage: 'eCompletionOmniBrowser'; >>>>> addPackage: 'eCompletion-Traits'; >>>>> install. >>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On 18 Feb 2009, at 11:17, David RÃ¶thlisberger wrote: >>>>> >>>>>> Hi Alex, >>>>>> >>>>>>> Apparently, what is loaded by ScriptLoader>>loadOBAlpha cannot be >>>>>>> opened. OBPackageBrowser>>topPanel DNU >>>>>>> It would be great to fix this... >>>>>> I don't get this error. >>>>>> The method you mention is in OBCodeBrowser in pkg OB-Standard, >>>>>> maybe >>>>>> this package >>>>>> didn't get updated when you loaded OBAlpha. >>>>>> >>>>>> David >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Feb. 18, 2009

Re: [Pharo-project] [update] #10236

by Adrian Lienhard

On Feb 18, 2009, at 20:37 , John M McIntosh wrote: > > On 18-Feb-09, at 4:44 AM, Marcus Denker wrote: > >> 10236 >> ----- >> >> Issue 316: forgetAllGrabCommandsFrom: at startup scanning all the >> objects > > Er so what did we do here? http://code.google.com/p/pharo/issues/detail?id=316 I added a cs in response to your comment, and I noted: "Like this we either purge on shutdown *or* on startup, but not twice. Default is on shutdown." OK? Cheers, Adrian > In relooking at this I was confused about > the intent and I guess the bug. > > Preferences purgeUndoOnQuit from a naming viewpoint seemed to imply > that the purge would > occur on quit, but not on startup if True, otherwise it would occur at > startup time. > > However the old code would entirely disable the purging both at > startup and shutdown if purgeUndoOnQuit was false. > Maybe the intent was to call it purgeUndoRecords > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 18, 2009

Re: [Pharo-project] [update] #10236

by John M McIntosh

On 18-Feb-09, at 4:44 AM, Marcus Denker wrote: > 10236 > ----- > > Issue 316: forgetAllGrabCommandsFrom: at startup scanning all the > objects Er so what did we do here? In relooking at this I was confused about the intent and I guess the bug. Preferences purgeUndoOnQuit from a naming viewpoint seemed to imply that the purge would occur on quit, but not on startup if True, otherwise it would occur at startup time. However the old code would entirely disable the purging both at startup and shutdown if purgeUndoOnQuit was false. Maybe the intent was to call it purgeUndoRecords -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 18, 2009

[Pharo-project] ABout MC browser size

by StÃ©phane Ducasse

Hi gary I do not really understand since I fixed the default size of the MC browser in the past. When I loaded your code I imagine that I merge and that they were no conflict so I do not understand why now I have again a wrong size. Do you have an idea? Did you merge back my little changes? Stef

Feb. 18, 2009