- Pharo-dev - lists.pharo.org

Re: [Pharo-project] multiple pharo images

by StÃ©phane Ducasse

On May 2, 2012, at 11:20 PM, Francisco Garau wrote: > How about Jenkins putting a build suffix to the images? -- something like Pharo-2.0.build-20040.image + 1 :) > > At the moment, all the build generate files with the same name. > > https://ci.lille.inria.fr/pharo/job/Pharo-2.0/41/ > > 2.0 #20040 > > Pharo-2.0.changes 13069724 > Pharo-2.0.image 18732936 > Pharo-2.0-one-click.zip 19242637 > Pharo-2.0.zip 14962904

May 3, 2012

Re: [Pharo-project] NativeBoost help

by StÃ©phane Ducasse

Igor is on vacation right now. I mean real vacation - no computer :) Stef On May 2, 2012, at 6:40 PM, Luc Fabresse wrote: > Hi Igor and other NB Gurus, > > A group of students is trying to use NativeBoost to wrap the OpenCV C image library. > The problem we are facing is that the function cvSize return a struct. > > typedef struct { int width; int height; } CvSize; > CV_INLINE CvSize cvSize( int width, int height ); > > But the NBExternalStructure seems to not support that if I understood correctly. > > NBExternalStructure>>coerceReturn: gen > " ... should we support handling return of external structures? " > self error: 'returning pointer to structure?' > > Did I miss something? > Any idea or workaround? > > Thanks, > > Luc

May 3, 2012

Re: [Pharo-project] [squeak-dev] The Trunk: Kernel-eem.684.mcz

by StÃ©phane Ducasse

I saw I'm just in a place without internet right now :) Stef On May 2, 2012, at 4:59 PM, Mariano Martinez Peck wrote: > Hi stef. Eliot send us (me and marcus) a private email about these changes and a suggestion for Fuel. > Marcus has already integrates all of these new methods ;) > > On Wed, May 2, 2012 at 4:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Begin forwarded message: > >> From: pharo-project-owner(a)lists.gforge.inria.fr >> Subject: Fwd: [squeak-dev] The Trunk: Kernel-eem.684.mcz >> Date: April 30, 2012 6:48:24 PM GMT+02:00 >> To: stephane.ducasse(a)gmail.com >> >> You are not allowed to post to this mailing list, and your message has >> been automatically rejected. If you think that your messages are >> being rejected in error, contact the mailing list owner at >> pharo-project-owner(a)lists.gforge.inria.fr. >> >> >> From: stephane ducasse <stephane.ducasse(a)gmail.com> >> Subject: Fwd: [squeak-dev] The Trunk: Kernel-eem.684.mcz >> Date: April 30, 2012 6:46:40 PM GMT+02:00 >> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >> >> >> >> >> Begin forwarded message: >> >>> From: commits(a)source.squeak.org >>> Subject: [squeak-dev] The Trunk: Kernel-eem.684.mcz >>> Date: April 26, 2012 6:07:56 PM GMT+02:00 >>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>> >>> Eliot Miranda uploaded a new version of Kernel to project The Trunk: >>> http://source.squeak.org/trunk/Kernel-eem.684.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Kernel-eem.684 >>> Author: eem >>> Time: 26 April 2012, 11:07:37.737 am >>> UUID: e838a325-27ec-4a62-a907-d4059451a046 >>> Ancestors: Kernel-nice.683 >>> >>> Implement endPC numArgs and numTemps for closures >>> and contexts (both block and method activations). >>> Provide CompiledMethod>abstractBytecodeMessagesDo: >>> et al. >>> Implement BlockClosure>isClean to identify self-contained blocks. >>> >>> =============== Diff against Kernel-nice.683 =============== >>> >>> Item was added: >>> + ----- Method: BlockClosure>>abstractBytecodeMessagesDo: (in category 'scanning') ----- >>> + abstractBytecodeMessagesDo: aBlock >>> + "Evaluate aBlock with the sequence of abstract bytecodes in the receiver." >>> + self method >>> + abstractBytecodeMessagesFrom: startpc >>> + to: self endPC >>> + do: aBlock >>> + >>> + "| msgs | >>> + msgs := OrderedCollection new. >>> + (SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: false]) sortBlock >>> + abstractBytecodeMessagesDo: [:msg| msgs add: msg selector]. >>> + msgs"! >>> >>> Item was added: >>> + ----- Method: BlockClosure>>blockCreationBytecodeMessage (in category 'scanning') ----- >>> + blockCreationBytecodeMessage >>> + "Answer the abstract bytecode message that created the receiver." >>> + | blockCreationBytecodeSize | >>> + ^self method abstractBytecodeMessageAt: startpc - (blockCreationBytecodeSize := 4) >>> + >>> + "(SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: false]) sortBlock blockCreationBytecodeMessage"! >>> >>> Item was added: >>> + ----- Method: BlockClosure>>endPC (in category 'accessing') ----- >>> + endPC >>> + ^self blockCreationBytecodeMessage arguments last + startpc - 1! >>> >>> Item was changed: >>> ----- Method: BlockClosure>>hasMethodReturn (in category 'testing') ----- >>> hasMethodReturn >>> "Answer whether the receiver has a method-return ('^') in its code." >>> + | scanner endpc | >>> + scanner := InstructionStream new method: outerContext method pc: startpc. >>> + endpc := self endPC. >>> + scanner scanFor: [:byte | (byte between: 120 and: 124) or: [scanner pc > endpc]]. >>> + ^scanner pc <= endpc! >>> - | myMethod scanner preceedingBytecodeMessage end | >>> - "Determine end of block from the instruction preceding it. >>> - Find the instruction by using an MNU handler to capture >>> - the instruction message sent by the scanner." >>> - myMethod := outerContext method. >>> - scanner := InstructionStream new method: myMethod pc: myMethod initialPC. >>> - [scanner pc < startpc] whileTrue: >>> - [[scanner interpretNextInstructionFor: nil] >>> - on: MessageNotUnderstood >>> - do: [:ex| preceedingBytecodeMessage := ex message]]. >>> - end := preceedingBytecodeMessage arguments last + startpc - 1. >>> - scanner method: myMethod pc: startpc. >>> - scanner scanFor: [:byte | (byte between: 120 and: 124) or: [scanner pc > end]]. >>> - ^scanner pc <= end! >>> >>> Item was added: >>> + ----- Method: BlockClosure>>isClean (in category 'testing') ----- >>> + isClean >>> + "Answer if the receiver does not close-over any variables other than globals, and does >>> + not ^-return (does not close over the home context). Clean blocks are amenable to >>> + being created at compile-time." >>> + self numCopiedValues > 0 ifTrue: >>> + [^false]. >>> + self abstractBytecodeMessagesDo: >>> + [:msg| >>> + (#( pushReceiver >>> + pushReceiverVariable: popIntoReceiverVariable: storeIntoReceiverVariable: >>> + methodReturnConstant: methodReturnReceiver methodReturnTop) >>> + includes: msg selector) ifTrue: >>> + [^false]]. >>> + ^true >>> + >>> + "clean:" >>> + "[] isClean" >>> + "[:a :b| a < b] isClean" >>> + "unclean" >>> + "[^nil] isClean" >>> + "[self class] isClean" >>> + "| v | v := 0. >>> + [v class] isClean"! >>> >>> Item was added: >>> + ----- Method: BlockClosure>>numTemps (in category 'accessing') ----- >>> + numTemps >>> + "Answer the number of temporaries for the receiver; this includes >>> + the number of arguments and the number of copied values." >>> + | blockCreationBytecodeSize | >>> + ^self numCopiedValues >>> + + self numArgs >>> + + (BlockLocalTempCounter >>> + tempCountForBlockAt: startpc - (blockCreationBytecodeSize := 4) >>> + in: self method)! >>> >>> Item was added: >>> + ----- Method: CompiledMethod>>abstractBytecodeMessageAt: (in category 'scanning') ----- >>> + abstractBytecodeMessageAt: pc >>> + "Answer the abstract bytecode message at pc in the receiver." >>> + ^[(InstructionStream new method: self pc: pc) interpretNextInstructionFor: nil] >>> + on: MessageNotUnderstood >>> + do: [:ex| ex message]! >>> >>> Item was added: >>> + ----- Method: CompiledMethod>>abstractBytecodeMessagesDo: (in category 'scanning') ----- >>> + abstractBytecodeMessagesDo: aBlock >>> + "Evaluate aBlock with the sequence of abstract bytecodes in the receiver" >>> + self abstractBytecodeMessagesFrom: self initialPC >>> + to: self endPC >>> + do: aBlock >>> + >>> + "| msgs | >>> + msgs := OrderedCollection new. >>> + CompiledMethod >> #abstractBytecodeMessagesFrom:to: abstractBytecodeMessagesDo: >>> + [:msg| msgs add: msg selector]. >>> + msgs"! >>> >>> Item was added: >>> + ----- Method: CompiledMethod>>abstractBytecodeMessagesFrom:to:do: (in category 'scanning') ----- >>> + abstractBytecodeMessagesFrom: startpc to: endpc do: aBlock >>> + "Evaluate aBlock with the sequence of abstract bytecodes from startpc through endpc in the receiver" >>> + | scanner | >>> + scanner := InstructionStream new method: self pc: startpc. >>> + [scanner pc <= endpc] whileTrue: >>> + [[scanner interpretNextInstructionFor: nil] >>> + on: MessageNotUnderstood >>> + do: [:ex| aBlock value: ex message]] >>> + >>> + "| m msgs | >>> + msgs := OrderedCollection new. >>> + (m := CompiledMethod >> #abstractBytecodeMessagesFrom:to:) >>> + abstractBytecodeMessagesFrom: m initialPC >>> + to: m endPC >>> + do: [:msg| msgs add: msg selector]. >>> + msgs"! >>> >>> Item was added: >>> + ----- Method: MethodContext>>endPC (in category 'private') ----- >>> + endPC >>> + ^closureOrNil >>> + ifNil: [self method endPC] >>> + ifNotNil: [closureOrNil endPC]! >>> >>> Item was added: >>> + ----- Method: MethodContext>>numArgs (in category 'accessing') ----- >>> + numArgs >>> + "Answer the number of arguments for this activation." >>> + ^closureOrNil >>> + ifNil: [method numArgs] >>> + ifNotNil: [closureOrNil numArgs]! >>> >>> Item was added: >>> + ----- Method: MethodContext>>numTemps (in category 'accessing') ----- >>> + numTemps >>> + "Answer the number of temporaries for this activation; this includes >>> + the number of arguments, and for blocks, the number of copied values." >>> + ^closureOrNil >>> + ifNil: [method numTemps] >>> + ifNotNil: [closureOrNil numTemps]! >>> >>> >> >> >> >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 3, 2012

[Pharo-project] ZTimestamp

by Sven Van Caekenberghe

Hi All, I don't like DateAndTime and/or TimeStamp a lot because it forces nanosecond precision and timezones on me, while in most cases I only want second precision and no timezones. Futhermore the class has some quirks that make it hard to understand. So last month I wrote my own, independent, more efficient ZTimestamp. As an experiment, I am releasing it like this: https://github.com/svenvc/ztimestamp I think Dale is really on to something with filetree, git and github. Check it out! Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 3, 2012

Re: [Pharo-project] Adding hooks for well known events in morphic

by GastÃ³n Dall' Oglio

2012/5/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > I do not see the difference between signals and event. For that reason, I meant about possibility of reuse this existing implementation, if it was useful for your objectives of course. > And yes we look at the code, it is not a really good idea to use > thisContext for every little notifications. > I see, that is not good :) Maybe that explained the slow result in the benchmark at the below table in that page (Signals doc), compared to Announcement. Regards

May 3, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

Sounds great!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, May 02, 2012 1:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Let me repeat it again (reread the vision document) we will put in place a process that: - check all the configurations of a given repository (for each versions) so for example for MetaRepoForPharo1.4 and MetaRepoForPharo20â¦ - each configuration will be loaded, test runs, rules executed. - we will have inbox for each repository, - if a configuration does not pass, it will move the configurations into an outbox Then people will be able to load configurations that have been loaded and verified. Stef

May 3, 2012

Re: [Pharo-project] Pharo 2.0: Just need a recompileAll or a real problem in background?

by Mariano Martinez Peck

> >> Ok. If I understand this correctly, this is yet ANOTHER thing to test, >> right? I mean, it does not cover my original problem but another one >> possible ;) >> right? >> > > I was assuming that my test is a superset of yours, but now I see it is > not strict enough. It also needs to compare bindings to see that they're > identical. I've attached a stricter version. This says that for any > global, it should match either the class's notion of what bindingOf: the > key is, or bindingOf: should be nil and the binding should be in > Undeclared. If the class answers a different binding through bindingOf: > or answers no binding and the binding is not in Undeclared then the > variable in the method is wrong. > > Ok, now we agree :) I commited this version and removed my previous test. Thanks! > methodsWithUnboundGlobals > "Get all methods that use undeclared global objects that are not listed in > Undeclared. For a clean image the result should be empty." > > "SystemNavigation new methodsWithUnboundGlobals" > > ^self allSelect: > [:m| > m literals anySatisfy: > [:l| > l isVariableBinding > and: [l key isSymbol "avoid class-side methodClass literals" > and: [(m methodClass bindingOf: l key) > ifNil: [(Undeclared associationAt: l key ifAbsent: []) ~~ l] > ifNotNil: [:b| b ~~ l]]]]] > > > So I think with this stricter definition self assert: SystemNavigation > new methodsWithUnboundGlobals isEmpty is an adequate test. > > >> Thanks Eliot. >> >> >> >> >>> And I have 6 methods from the classes SmalltalkImage and ScriptLoader >>>> and all the 6 literals are pointing to ScriptLoader. So something weird >>>> happened with this class. >>>> Any idea? >>>> >>>> For the moment I will update the test and do a Compiler recompileAll. >>>> >>>> >>>> >>>> >>>>> >>>>>> > Association >> #literalEqual: otherLiteral >>>>>> > "Answer true if the receiver and otherLiteral represent the same >>>>>> > literal. >>>>>> > Variable bindings are literally equals only if identical. >>>>>> > This is how variable sharing works, by preserving identity and >>>>>> changing >>>>>> > only the value." >>>>>> > ^self == otherLiteral >>>>>> > >>>>>> > instead of the Object implementation. >>>>>> > >>>>>> > >>>>>> >> >>>>>> >> On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> wrote: >>>>>> >>> >>>>>> >>> (Smalltalk globals associationAt: #ScriptLoader) == >>>>>> ((SmalltalkImage >> >>>>>> >>> #shrinkToCore) literalAt: 4) >>>>>> >>> gives false when it should be true. If I do a Compiler >>>>>> recompileAll it >>>>>> >>> gets fixed. So, my question is, is that normal? how could that >>>>>> happen? >>>>>> >>> is there any real problem behind? >>>>>> >>> >>>>>> >>> anyway, can we do a recompileAll for the moment? >>>>>> >>> >>>>>> >>> thanks! >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Mariano >>>>>> >>> http://marianopeck.wordpress.com >>>>>> >>> >>>>>> >> >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Mariano >>>>>> > http://marianopeck.wordpress.com >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

May 3, 2012

Re: [Pharo-project] Pharo 2.0: Just need a recompileAll or a real problem in background?

by Eliot Miranda

On Wed, May 2, 2012 at 11:44 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, May 2, 2012 at 8:21 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Mariano, >> >> On Wed, May 2, 2012 at 1:27 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Tue, May 1, 2012 at 10:17 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, May 1, 2012 at 10:05 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> On 1 May 2012 21:45, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>> > >>>>> > >>>>> > On Tue, May 1, 2012 at 9:22 PM, Francisco Garau < >>>>> francisco.garau(a)gmail.com> >>>>> > wrote: >>>>> >> >>>>> >> Your code snippet is comparing the associations. The below one >>>>> evaluates >>>>> >> to true: >>>>> >> >>>>> >> (Smalltalk globals associationAt: #ScriptLoader) value >>>>> >> == >>>>> >> ((SmalltalkImage >> #shrinkToCore) literalAt: 4) value >>>>> >> >>>>> > >>>>> > Yes, but the literals of CompiledMethod that refer to classes should >>>>> have >>>>> > the SAME association as Smalltalk globals. In fact, that's the >>>>> reason why we >>>>> > have: >>>>> > >>>>> indeed. >>>>> The question is what leads to creation of multiple associations >>>>> pointing to same global? >>>>> >>>> >>>> >>>> Exactly. I can easily fix it with a Compiler recompileAll. But the main >>>> question is if we have a bug or something that could let us in that state. >>>> >>>> >>> >>> Ok, I wrote an ugly test and I noticed that the ONLY method with this >>> problem in the image is >>> >>> >>> | behaviorAssociations broken | >>> behaviorAssociations := Smalltalk globals associations select: [:each | >>> each value isBehavior or: [each value isTrait]]. >>> broken := OrderedCollection new. >>> (CompiledMethod allInstances select: [:each | each isInstalled]) >>> do: [:aMethod | aMethod literals >>> do: [:aLiteral | aLiteral isVariableBinding >>> ifTrue: [ >>> ((behaviorAssociations includes: aLiteral) >>> and: >>> [(behaviorAssociations identityIncludes: aLiteral) not]) >>> ifTrue: [broken >>> add: (aMethod -> aLiteral)] >>> ] >>> ] >>> ]. >>> broken inspect >>> >> >> This doesn't look for unbound class variables. >> > > Indeed. > > >> I just wrote something that handles this in Squeak trunk: >> >> methodsWithUnboundGlobals >> "Get all methods that use undeclared global objects that are not listed >> in Undeclared. For a clean image the result should be empty." >> >> "SystemNavigation new methodsWithUnboundGlobals" >> >> ^self allSelect: >> [:m| >> m literals anySatisfy: >> [:l| >> l isVariableBinding >> and: [l key isSymbol "avoid class-side methodClass literals" >> and: [(m methodClass bindingOf: l key) isNil >> and: [(Undeclared associationAt: l key ifAbsent: []) ~~ l]]]]] >> >> so the test would be >> self assert: SystemNavigation new methodsWithUnboundGlobals isEmpty >> >> >>> > Ok. If I understand this correctly, this is yet ANOTHER thing to test, > right? I mean, it does not cover my original problem but another one > possible ;) > right? > I was assuming that my test is a superset of yours, but now I see it is not strict enough. It also needs to compare bindings to see that they're identical. I've attached a stricter version. This says that for any global, it should match either the class's notion of what bindingOf: the key is, or bindingOf: should be nil and the binding should be in Undeclared. If the class answers a different binding through bindingOf: or answers no binding and the binding is not in Undeclared then the variable in the method is wrong. methodsWithUnboundGlobals "Get all methods that use undeclared global objects that are not listed in Undeclared. For a clean image the result should be empty." "SystemNavigation new methodsWithUnboundGlobals" ^self allSelect: [:m| m literals anySatisfy: [:l| l isVariableBinding and: [l key isSymbol "avoid class-side methodClass literals" and: [(m methodClass bindingOf: l key) ifNil: [(Undeclared associationAt: l key ifAbsent: []) ~~ l] ifNotNil: [:b| b ~~ l]]]]] So I think with this stricter definition self assert: SystemNavigation new methodsWithUnboundGlobals isEmpty is an adequate test. > Thanks Eliot. > > > > >> And I have 6 methods from the classes SmalltalkImage and ScriptLoader >>> and all the 6 literals are pointing to ScriptLoader. So something weird >>> happened with this class. >>> Any idea? >>> >>> For the moment I will update the test and do a Compiler recompileAll. >>> >>> >>> >>> >>>> >>>>> > Association >> #literalEqual: otherLiteral >>>>> > "Answer true if the receiver and otherLiteral represent the same >>>>> > literal. >>>>> > Variable bindings are literally equals only if identical. >>>>> > This is how variable sharing works, by preserving identity and >>>>> changing >>>>> > only the value." >>>>> > ^self == otherLiteral >>>>> > >>>>> > instead of the Object implementation. >>>>> > >>>>> > >>>>> >> >>>>> >> On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> wrote: >>>>> >>> >>>>> >>> (Smalltalk globals associationAt: #ScriptLoader) == >>>>> ((SmalltalkImage >> >>>>> >>> #shrinkToCore) literalAt: 4) >>>>> >>> gives false when it should be true. If I do a Compiler >>>>> recompileAll it >>>>> >>> gets fixed. So, my question is, is that normal? how could that >>>>> happen? >>>>> >>> is there any real problem behind? >>>>> >>> >>>>> >>> anyway, can we do a recompileAll for the moment? >>>>> >>> >>>>> >>> thanks! >>>>> >>> >>>>> >>> -- >>>>> >>> Mariano >>>>> >>> http://marianopeck.wordpress.com >>>>> >>> >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Mariano >>>>> > http://marianopeck.wordpress.com >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

May 3, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Cameron Sanders

Sounds great! We have encountered two main problems in getting the DBXTalk tools (including supporting tools, Glorp, etc.) loaded: 1) 64-bit vs 32-bit crossover problems with FFI, and 2) proper configuration patterns (online Configuration snippets with errors) and sequencing. -Cam On Wed, May 2, 2012 at 1:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Let me repeat it again (reread the vision document) > > we will put in place a process that: > - check all the configurations of a given repository (for each > versions) > so for example for MetaRepoForPharo1.4 and MetaRepoForPharo20â¦ > - each configuration will be loaded, test runs, rules executed. > - we will have inbox for each repository, > - if a configuration does not pass, it will move the configurations > into an outbox > > Then people will be able to load configurations that have been loaded and > verified. > > Stef >

May 3, 2012

Re: [Pharo-project] Mouse handler on a morph

by Gary Chambers

Hi, I guess that properly you should do: (self globalPointToLocal: event position) - self position which should deal with the case of being embedded in a scroll pane or other transform Regards, Gary ----- Original Message ----- From: Erwan Douaille To: Pharo-project(a)lists.gforge.inria.fr ; ma.chris.m(a)gmail.com Sent: Thursday, May 03, 2012 8:35 AM Subject: Re: [Pharo-project] Mouse handler on a morph Okay, but i didn't find anything with globalToLocal. And i've find another solution, just use soustraction for this problem : captureMouse: event Transcript cr;show: event position - self position. That's work too :) Thanks ;) 2012/5/2 Chris Muller <asqueaker(a)gmail.com> This is because, under rare circumstances, it is desirable to do something in/on/to the desktop based on the position in the local morph. To get the local coordinates look for a method with the word "global" in it -- globalToLocal: or something like that. It's in Squeak, not sure whether this is still in Pharo though.. If anything, you could always just subtract the upperleft coordinate of your window from the MouseEvent's position.. On Wed, May 2, 2012 at 9:02 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > Hi. > > I would like to know if it's possible to add a mouse handler on a specific > morph ? > I have a window and i would like to know the position of my mouse only in > this window. > > For exemple i also use : > > self on: #mouseDown send: #captureMouse: to: self. > > But it give me the mouse position in pharo environment and not only in my > window. > > > Thanks :) > > -- > Douaille Erwan <douaille.erwan(a)gmail.com> -- Douaille Erwan <douaille.erwan(a)gmail.com>

May 3, 2012