January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

On Sat, Jan 7, 2012 at 4:04 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 6 Jan 2012, Mariano Martinez Peck wrote: > > >>> Thanks Levente. However, #pointersToExcept: does a GC at the >>>>> >>>> beginning... >>>> so.. am I missing something? >>>> >>>> >>> Yes, at the beginning The MethodContexts are created after that GC. >>> >>> >>> But those MC shouldn't be excluded by the instVar >> objectsToAlwaysExclude ? >> >> objectsToAlwaysExclude := { >> results collector. >> thisContext. >> thisContext sender. >> thisContext sender sender. >> objectsToExclude. >> }. >> > > Since #pointsTo: is not a primitive anymore, That's an interesting point. Now I understand this better. Even if I didn't know the reasons (now I do), I even tried adding some more senders but still they appear :( I tried (for example) objectsToAlwaysExclude := { results collector. thisContext. thisContext sender. thisContext sender sender. thisContext sender sender sender. thisContext sender sender sender sender. thisContext sender sender sender sender sender. objectsToExclude. }. What I don't understand is why in Squeak it does work. Thanks in advance Levente! > it will create at least one new MethodContext which is not included in > that list. > > > Levente > > >> >> >> >> >> >>> Levente >>> >>> >>> Thanks again. >>>> >>>> >>>> >>>> Levente >>>>> >>>>> >>>>> >>>>> >>>>> Do you mean what I understand :)? that some tools compiled methods? :) >>>>>> >>>>>> >>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>> **** >>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 7, 2012

[Pharo-project] [update 1.4] #14279

by StÃ©phane Ducasse

14279 ----- - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=5157 - Issue 5151: Recategorization of PanelMorph. Thanks Benjamin van Ryseghem. There is no useless cleans. Even small steps are cool and important. http://code.google.com/p/pharo/issues/detail?id=5151 - Issue 5154: It would be great to have a setting to allow the Debugger to open centered and be 3/4 of screen. Thanks Alain Plantec. http://code.google.com/p/pharo/issues/detail?id=5154 - Issue 5148: LimitNumberOfEntriesInZnMultiValueDictionary. Thanks Sven van Caekenberghe. http://code.google.com/p/pharo/issues/detail?id=5148 stef

Jan. 7, 2012

Re: [Pharo-project] Process questions about configurationOfâ¦.

by StÃ©phane Ducasse

first - let us focus on 95% of the cases. - we do not want overrides now in any case if you load a configuration from a given see you should get a working system. Stef On Jan 7, 2012, at 6:49 PM, Guillermo Polito wrote: > Some thoughts that comes to my mind: > > - What if the project depends on external stuff? Let's put dbxtalk: for the tests running ok, you have to install opendbx + several databases. > And since it's a pain to perform a special install for every project with special necessities, this kind of projects should be considered as a special case perhaps... > > - And what if the project has no test cases? hehe > > - Should the process care about overrides between packages? :/ We can have conflicting projects... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > BTW, If a person takes care of publishing the package to the metarepo inbox, isn't it enough to consider the package to be included as it is? It's a lot of work to certify each project :/ > > Guille > > On Sat, Jan 7, 2012 at 1:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > > Some questions out of curiosity since I'm not yet involved in publishing any packages > > > > Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string. > > > > As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms? > > the idea is that you should keep the master in your project and publish to the repository when you want to make > your configuration available. > > > What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location. > > > >

Jan. 7, 2012

Re: [Pharo-project] Process questions about configurationOfâ¦.

by Guillermo Polito

Some thoughts that comes to my mind: - What if the project depends on external stuff? Let's put dbxtalk: for the tests running ok, you have to install opendbx + several databases. And since it's a pain to perform a special install for every project with special necessities, this kind of projects should be considered as a special case perhaps... - And what if the project has no test cases? hehe - Should the process care about overrides between packages? :/ We can have conflicting projects... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= BTW, If a person takes care of publishing the package to the metarepo inbox, isn't it enough to consider the package to be included as it is? It's a lot of work to certify each project :/ Guille On Sat, Jan 7, 2012 at 1:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > >> > > Some questions out of curiosity since I'm not yet involved in publishing > any packages > > > > Is there some way to tag for the submitter to be emailed the Jenkins > results? Perhaps a method like 'emailJenkinsResultsTo:' inthe > configuration or alternatively Jenkins might unzip the mcz to directly > search the ".st" files for a specific string. > > > > As I understand it, the ConfigurationOfXXX contains information on > multiple versions and multiple platforms. Thinking ahead to when there is > a MetaRepoForPharo14, are there any concerns keeping two versions of > ConfigurationOfXXX in sync between the two repos? For example when an > application releases a new version for Pharo13, do you only update the > ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with > further forks for ConfigurationOfXXX on other platforms? > > the idea is that you should keep the master in your project and publish to > the repository when you want to make > your configuration available. > > > What about a single repository (if not the existing MetacelloRepository > then perhaps MetaRepoCI), which Jenkins processes and then if that single > file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works > for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can > do the same. That way the application developer has to manage a single > location. > > > >

Jan. 7, 2012

Re: [Pharo-project] Suggestion Note:

by StÃ©phane Ducasse

On Jan 4, 2012, at 10:22 AM, S Krish wrote: > Should raise this as a separate artifact and probably send out my fixes ( currently these are hacks). > > Many of the other logics do not work as per standard practices... from other comp usage.. windows/ linux.. > > * FileOut is silent and saves to the resources folder ... no chance of intervention while it goes out.. also overwrites silently.. > Simple save/ saveas popup menu would help .. when reqd. > * Image saveAs : only image name is taken.. no folder selection... though one can give a full path in the text editor. > * remember the last navigated path in file open/ save dialogs > * Monticello save is incremental and quickly builds up a huge stack of files.. need to optimize this.. autosave packages marked to a given default single file overwriting it.. reduce multiple mc saves to the minimum when you really need to version a new base. sign the license send code and we will discuss Stef

Jan. 7, 2012

Re: [Pharo-project] Bug reports: 2 of 6:

by StÃ©phane Ducasse

I do not think that fork is the solution. Stef On Jan 3, 2012, at 2:35 PM, S Krish wrote: > > ( SimpleButtonMorph new extent: 80@60 ; label: 'test' ; on:#click send: > #value to:[ [UIManager default inform: 'test' ] fork]; color: Color red) > openInWorld. > > the fork helps.. it simply lets the on:send:to: method continue to finish up the clean up and invoke the mouseUp... > > It is simply that this target code if it blocks.. it blocks the mouseUp call to the morph and thereby holds the morph as the clickClient... > > On Tue, Jan 3, 2012 at 5:05 PM, Ben Coman <btc(a)openinworld.com> wrote: > S Krish wrote: > 2. bug with mouseUp not passing through for event handling with > on:send:to: target... > > click all over the World and you will keep getting the dialog though you > are not clicking the morph. > #clickClient in MouseClickState holds the morph as the recipient morph for > clicks.. rather than the modal dialog.. > > ( SimpleButtonMorph new extent: 80@60 ; label: 'test' ; on:#click send: > #value to:[ UIManager default inform: 'test']; color: Color red) > openInWorld. > > > Replicated on: > Pharo-1.2.1-OneClick > Pharo-1.3-13315-OneCLick > Pharo-1.4-14263. Additional observation is that specifically clicking the <OK> button on the dialog does not close it. > Right-clicking anywhere fixes the behaviour such that clicking <OK> does close the dialog rather than creating a new one. > > >

Jan. 7, 2012

Re: [Pharo-project] Bug Report 5 of 6: Minor annoyance in SimpleButtonMorph

by StÃ©phane Ducasse

what do you suggest? How do you get a button with a bitmap style? The idea is that the protocol should be coherent. Stef > 5. > SimpleButtonMorph>> > updateVisualState: evt > > flashes the button with a color fill. For buttons that I have bitmap style, this is annoying.. ? I can override.. but better not have this for default buttons..?

Jan. 7, 2012

[Pharo-project] would it be possible to get the primitiveBeep working on recent VM?

by StÃ©phane Ducasse

Hi guys would it be possible to get the primitiveBeep working on recent VM? Stef

Jan. 7, 2012

Re: [Pharo-project] Bug Report: 3 of 6; Image freeze

by StÃ©phane Ducasse

On Jan 3, 2012, at 11:22 AM, S Krish wrote: > 3. Image Freeze: > > Anything that hits #fullBounds with a byteString instead of a Morph does not simply handle it... but freezes. This occurs with an external Table Morph Package that permits constructing a grid of morphs, but if you pass the 'string' instead of 'string' asMorph.. it takes it.. but when opening freezes similar to if we put a break point on Morph>>fullBounds/ processEvent:using: â¦ do you have example? Now if the system expects a morph passing a string should not work. Stef > > Alt . with an image that has Sound package loaded, causes a dialog for choosing a Sound Package that is all disabled and freezes the image can you tell me which package sound? Because I would like to reproduce your problem to see how to fix it. Stef

Jan. 7, 2012

Re: [Pharo-project] Bug Report 4 of 6: PasteUpMorph>>processEvent:

by StÃ©phane Ducasse

I do not know. :) so far PasteUpMorph>>processEvent: anEvent using: defaultDispatcher "Reimplemented to install the receiver as the new ActiveWorld if it is one" | priorWorld result | self isWorldMorph ifFalse:[^super processEvent: anEvent using: defaultDispatcher]. priorWorld := ActiveWorld. ActiveWorld := self. result := super processEvent: anEvent using: defaultDispatcher. ActiveWorld := priorWorld. ^result and I would be inclined not to change it except if we really want to spend time there. Right now we are focusing on the other irons we have on the fire. > 4. > For PasteUpMorph>> > processEvent: anEvent using: defaultDispatcher > "Why not reject events not on the morph.. rather than send rejectEvent call to the morph" > > (anEvent isMouse | anEvent isKeyboard > and: [(self fullContainsPoint: anEvent cursorPoint) not]) > ifTrue: [^ #rejected]. > > (self rejectsEvent: anEvent) > ifTrue: [^ #rejected]. > ^ defaultDispatcher dispatchEvent: anEvent with: self

Jan. 7, 2012