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

Re: [Pharo-project] Canvas >>draw: anObject

by Gary Chambers

It is all rather messy. Note that #fullBounds can be different to #bounds if submorphs lie outside the bounds of the owner (parent). Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr>; <fernando.olivero(a)usi.ch> Sent: Tuesday, February 08, 2011 3:42 PM Subject: Re: [Pharo-project] Canvas >>draw: anObject On 8 February 2011 16:37, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > There's a method in Morph>>clipsSubmorphs , that dictates that behavior. > surely is on by default . > no. this is different. It tells whether submorphs can be drawn outside of morph's bounds, but nothing about morph itself. In fact, i think many of these flags are redundant. For instance: if one wants submorphs to be drawn outside of morph's bounds, he can simply put them into morph's parent and so on up to topmost one - world.. > Fernando > > > On Tue, Feb 8, 2011 at 10:20 AM, StÃ©phane Ducasse > <Stephane.Ducasse(a)inria.fr> wrote: >> Yes now apparently even if I draw outside the bounds they are clipped in >> pharo too. I have to check how. >> >> On Feb 8, 2011, at 12:51 AM, Igor Stasenko wrote: >> >>> On 7 February 2011 22:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> Canvas>>draw: anObject >>>> ^anObject drawOn: self >>>> >>>> >>>> Now in SM we got >>>> >>>> SMxCanvas>>draw: anObject >>>> ^self clipBy: anObject bounds during: [ :c | anObject drawOn: c] >>>> >>>> and I'm wondering what is the exact difference. >>>> Any idea? >>>> >>> >>> yes, >>> SMxCanvas ensures that not matter what happens, a morph cannot draw >>> outside of its declared bounds. >>> Which usually should not happen anyways.. so it looks like an >>> additional rule enforcement. >>> >>> >>> >>>> Stef >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 8, 2011

Re: [Pharo-project] Canvas >>draw: anObject

by Igor Stasenko

On 8 February 2011 16:37, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > There's a method in Morph>>clipsSubmorphs , that dictates that behavior. > surely is on by default . > no. this is different. It tells whether submorphs can be drawn outside of morph's bounds, but nothing about morph itself. In fact, i think many of these flags are redundant. For instance: if one wants submorphs to be drawn outside of morph's bounds, he can simply put them into morph's parent and so on up to topmost one - world.. > Fernando > > > On Tue, Feb 8, 2011 at 10:20 AM, StÃ©phane Ducasse > <Stephane.Ducasse(a)inria.fr> wrote: >> Yes now apparently even if I draw outside the bounds they are clipped in pharo too. I have to check how. >> >> On Feb 8, 2011, at 12:51 AM, Igor Stasenko wrote: >> >>> On 7 February 2011 22:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Canvas>>draw: anObject >>>> Â Â Â ^anObject drawOn: self >>>> >>>> >>>> Now in SM we got >>>> >>>> SMxCanvas>>draw: anObject >>>> Â Â Â ^self clipBy: anObject bounds during: [ :c | anObject drawOn: c] >>>> >>>> and I'm wondering what is the exact difference. >>>> Any idea? >>>> >>> >>> yes, >>> SMxCanvas ensures that not matter what happens, a morph cannot draw >>> outside of its declared bounds. >>> Which usually should not happen anyways.. so it looks like an >>> additional rule enforcement. >>> >>> >>> >>>> Stef >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 8, 2011

Re: [Pharo-project] Canvas >>draw: anObject

by Fernando Olivero

There's a method in Morph>>clipsSubmorphs , that dictates that behavior. surely is on by default . Fernando On Tue, Feb 8, 2011 at 10:20 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Yes now apparently even if I draw outside the bounds they are clipped in pharo too. I have to check how. > > On Feb 8, 2011, at 12:51 AM, Igor Stasenko wrote: > >> On 7 February 2011 22:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Canvas>>draw: anObject >>> Â Â Â ^anObject drawOn: self >>> >>> >>> Now in SM we got >>> >>> SMxCanvas>>draw: anObject >>> Â Â Â ^self clipBy: anObject bounds during: [ :c | anObject drawOn: c] >>> >>> and I'm wondering what is the exact difference. >>> Any idea? >>> >> >> yes, >> SMxCanvas ensures that not matter what happens, a morph cannot draw >> outside of its declared bounds. >> Which usually should not happen anyways.. so it looks like an >> additional rule enforcement. >> >> >> >>> Stef >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > >

Feb. 8, 2011

Re: [Pharo-project] Delay error after system crash

by Esteban Lorenzano

yeah... I'm not using it... seems to be InputEventPollingFetcher, the problem :( El 08/02/2011, a las 11:59a.m., Igor Stasenko escribiÃ³: > This happens when you try to wait for same Delay instance. > Try to not capture the Delay instance into vars and don't use same > delay instances for multiple waits. > > As to me the logic of delay handling is wrong. I don't see why same > delay instance can't be shared by multiple processes to wait for same > period of time. > > For behavior which it demonstrates currently i would call it like DelayedSignal. > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 8, 2011

Re: [Pharo-project] Delay error after system crash

by Igor Stasenko

This happens when you try to wait for same Delay instance. Try to not capture the Delay instance into vars and don't use same delay instances for multiple waits. As to me the logic of delay handling is wrong. I don't see why same delay instance can't be shared by multiple processes to wait for same period of time. For behavior which it demonstrates currently i would call it like DelayedSignal. -- Best regards, Igor Stasenko AKA sig.

Feb. 8, 2011

Re: [Pharo-project] [COTDC] 4 - RecategorizedEvent

by Francisco Ortiz PeÃ±aloza

Ben, imho we shouldn't provide detail about its messages just illustrate what it is for and maybe and example of common use. Cheers, Francisco On Tue, Feb 8, 2011 at 9:25 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I'm the event sent by the system when a method or a class is recategorized. > > To retrieve information, you can access to: > Â Â Â Â item: the CompiledMethod or the class recategorized > Â Â Â Â itemKind: #method for a method, #class for a class > Â Â Â Â environment: aDictionary with new information > Â Â Â Â Â Â Â Â for a method: > Â Â Â Â Â Â Â Â Â Â Â Â - #class: the class of the method (it hasn't changed) > Â Â Â Â Â Â Â Â Â Â Â Â - #protocol: the new category of the method > Â Â Â Â Â Â Â Â Â Â Â Â - #selector: the selector of the method (it hasn't changed) > Â Â Â Â Â Â Â Â for a class: > Â Â Â Â Â Â Â Â Â Â Â Â - #category: the new category > Â Â Â Â oldCategory: the category where the item was formerly categorized > > > Ben > > On Feb 7, 2011, at 7:35 PM, Esteban Lorenzano wrote: > >> Also, AbstractEvent is not commented: >> >> I'm a generic event raised by the system (SystemChangeNotifier) when anything (both classes or methods) changes in the system. >> Each one of my children represents a specific kind of event the system can notify. >> >> Now I will soon fade away and be replaced by announcements. >> >> (not a lot imaginative, but works :)) >> >> El 07/02/2011, a las 3:25p.m., StÃ©phane Ducasse escribiÃ³: >> >>> I'm an event raised by the system (SystemChangeNotifier) when a class or a method changed its category. The way to create my instances is the following: >>> >>> >>> (RecategorizedEvent >>> Â Â Â method: (aClass compiledMethodAt: selector ifAbsent: [nil]) >>> Â Â Â selector: selector >>> Â Â Â protocol: newCategory >>> Â Â Â class: aClass >>> Â Â Â oldProtocol: oldCategory) >>> >>> >>> (RecategorizedEvent >>> Â Â Â class: aClass >>> Â Â Â category: newCategory >>> Â Â Â oldCategory: oldCategory) >>> >>> Now I will soon fade away and be replaced by announcements. >>> >>> >>> >>> >>> >>> On Feb 7, 2011, at 6:25 PM, laurent laffont wrote: >>> >>>> Comment Of The Day Contest - One Day One Comment >>>> Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). >>>> >>>> >>>> Today: RecategorizedEvent >>>> >>>> >>>> Laurent >>> >>> >> >> > > >

Feb. 8, 2011

[Pharo-project] Delay error after system crash

by Esteban Lorenzano

Hi, I'm having a problem with Delay after a system crash (yeah, the real problem is the system crash, but I'm also having this one after it happens) I have several processes running who monitor some state, and synchronize some file outs (the sync is made using a mutex). The original crash seems to be happening somewhere there. After the crash, I restart the image tries to reconstruct the data (taking the files previously saved) and I'm getting this error: THERE_BE_DRAGONS_HERE Error: This Delay has already been scheduled. 8 February 2011 5:00:05 am VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35] Image: Pharo-1.1.1-- [Latest update: #11414] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/administrator/emanual Trusted Dir /home/administrator/emanual/secure Untrusted Dir /home/administrator/emanual/My Squeak Delay(Object)>>error: Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: aString: 'This Delay has already been scheduled.' Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true Delay>>schedule Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true Delay>>wait Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true InputEventPollingFetcher>>waitForInput Receiver: an InputEventPollingFetcher Arguments and temporary variables: Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() InputEventPollingFetcher(InputEventFetcher)>>eventLoop Receiver: an InputEventPollingFetcher Arguments and temporary variables: eventBuffer: #(0 0 0 0 0 0 0 0) type: 0 window: nil Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() [] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop Receiver: an InputEventPollingFetcher Arguments and temporary variables: Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() [] in BlockClosure>>newProcess Receiver: [self eventLoop] Arguments and temporary variables: Receiver's instance variables: outerContext: InputEventPollingFetcher(InputEventFetcher)>>installEventLoop startpc: 48 numArgs: 0 --- The full stack --- Delay(Object)>>error: Delay>>schedule Delay>>wait InputEventPollingFetcher>>waitForInput InputEventPollingFetcher(InputEventFetcher)>>eventLoop [] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop [] in BlockClosure>>newProcess Any idea what can be causing this? I also noticed that there is another error when the image restarts: 'Trying to activate Delay twice' which is thrown on Delay class>>#startUp Any idea what can be happening? Cheers, Esteban

Feb. 8, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #24 on issue 3583 by tudor.gi...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 Thanks a lot. I tested it briefly and it looks good. It would be great to integrate this in 1.2.

Feb. 8, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #23 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 That should shout the workspace :) Give me feedback please ;) Attachments: ShoutWorkspace.1.cs 547 bytes

Feb. 8, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #22 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 It should fix the debugger (and all the codeholders) Let's take a look at the workspace now Attachments: ShoutCodeHolder.1.cs 652 bytes

Feb. 8, 2011