- Pharo-dev - lists.pharo.org

Re: [Pharo-project] GUI failing apart

by StÃ©phane Ducasse

you mean that this method could be nicer :) We will continue to work on the rewrite of the events. It just takes time. handleEvent: anEvent | evt ofs | owner ifNil:[^self]. evt := anEvent. EventStats ifNil:[EventStats := IdentityDictionary new]. EventStats at: #count put: (EventStats at: #count ifAbsent:[0]) + 1. EventStats at: evt type put: (EventStats at: evt type ifAbsent:[0]) + 1. evt isMouseOver ifTrue:[^self sendMouseEvent: evt]. ShowEvents == true ifTrue:[ Display fill: (0@0 extent: 250@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue:[0@30] ifFalse:[0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45). ]. "Notify listeners" self sendListenEvent: evt to: self eventListeners. evt isWindowEvent ifTrue: [ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isKeyboard ifTrue:[ self sendListenEvent: evt to: self keyboardListeners. self sendKeyboardEvent: evt. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isDropEvent ifTrue:[ self sendEvent: evt focus: nil. ^self mouseOverHandler processMouseOver: lastMouseEvent]. evt isMouse ifTrue:[ self sendListenEvent: evt to: self mouseListeners. lastMouseEvent := evt]. "Check for pending drag or double click operations." mouseClickState ifNotNil:[ (mouseClickState handleEvent: evt from: self) ifFalse:[ "Possibly dispatched #click: or something and will not re-establish otherwise" ^self mouseOverHandler processMouseOver: lastMouseEvent]]. evt isMove ifTrue:[ self position: evt position. self sendMouseEvent: evt. ] ifFalse:[ "Issue a synthetic move event if we're not at the position of the event" (evt position = self position) ifFalse:[self moveToEvent: evt]. "Drop submorphs on button events" (self hasSubmorphs) ifTrue:[self dropMorphs: evt] ifFalse:[self sendMouseEvent: evt]. ]. ShowEvents == true ifTrue:[self mouseFocus printString displayAt: (0@ofs) + (0@15)]. self mouseOverHandler processMouseOver: lastMouseEvent. On Aug 8, 2011, at 9:44 PM, Igor Stasenko wrote: > 2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: >> >> MouseOverHandler>>handleAsMouseEnter: anEvent >> | asMouseEnterEvent | >> asMouseEnterEvent := anEvent asMouseEnter. >> enteredMorphs := enteredMorphs contents. >> enteredMorphs reverseDo: [ :anEnteredMorph | >> self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: >> anEvent ifNotFocusedDo: [] ] >> >> enteredMorphs is changing indead from WriteStream -> Array. >> IMHO mutating an inst var is very bad behaved >> This should be corrected ASAP >> > > This class is really confusing.. > According to its use (see senders to #mouseOverHandler) > it actually handling more than just mouse over events. > I would say it should be named MouseEventHander :) > > But still , its hard to say, why it is so complex.. and what its purpose. > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by StÃ©phane Ducasse

I'm confused. Is there a bug in pharo, or janko loaded a strange package? Stef On Aug 8, 2011, at 9:16 PM, Nicolas Cellier wrote: > I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: > > MouseOverHandler>>handleAsMouseEnter: anEvent > | asMouseEnterEvent | > asMouseEnterEvent := anEvent asMouseEnter. > enteredMorphs := enteredMorphs contents. > enteredMorphs reverseDo: [ :anEnteredMorph | > self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: > anEvent ifNotFocusedDo: [] ] > > enteredMorphs is changing indead from WriteStream -> Array. > IMHO mutating an inst var is very bad behaved > This should be corrected ASAP > > Nicolas > > 2011/8/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >> Looks like you may have changed one of the following methods: >> >> CharacterBlockScanner buildCharacterBlockIn: {private} >> CharacterBlockScanner characterBlockAtPoint:index:in: {scanning} >> NewParagraph defaultCharacterBlock {selection} >> >> since getting a CharacterBlockScanner back instead of a CharacterBlock in >> MultiNewParagraph>>buildSelectionBlocksFrom:to: >> >> Regards, Gary >> >> ----- Original Message ----- From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 08, 2011 6:29 PM >> Subject: Re: [Pharo-project] GUI failing apart >> >> >>> Here it is, in attachment, there actually are some GUI related >>> exceptions captured. Troubles started an hour or so ago. >>> >>> Thanks for your time and best regards >>> Janko >>> >>> S, Gary Chambers piÅ¡e: >>>> >>>> Your PharoDebug.log may have some clues... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Janko MivÅ¡ek" >>>> <janko.mivsek(a)eranova.si> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, August 08, 2011 6:04 PM >>>> Subject: [Pharo-project] GUI failing apart >>>> >>>> >>>>> Hi guys, >>>>> >>>>> Strange things start happening to my 1.3 image. When edited some method >>>>> it suddenly became covered with red, yellow crossed. Now other windows >>>>> also have trouble to recreate when they come in focus. Not to mention >>>>> many other such problems I cannot even describe. I somehow still manage >>>>> to work with this image but with such trouble all the time. >>>>> >>>>> Is there a way to recover this image from such troubles? >>>>> >>>>> Best regards >>>>> Janko >>>>> >>>>> -- >>>>> Janko MivÅ¡ek >>>>> Aida/Web >>>>> Smalltalk Web Application Server >>>>> http://www.aidaweb.si >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko MivÅ¡ek >>> Svetovalec za informatiko >>> Eranova d.o.o. >>> Ljubljana, Slovenija >>> www.eranova.si >>> tel: 01 514 22 55 >>> faks: 01 514 22 56 >>> gsm: 031 674 565 >>> >> >> >> >

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by Igor Stasenko

2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: > > MouseOverHandler>>handleAsMouseEnter: anEvent > Â Â Â Â | asMouseEnterEvent | > Â Â Â Â asMouseEnterEvent := anEvent asMouseEnter. > Â Â Â Â enteredMorphs := enteredMorphs contents. > Â Â Â Â enteredMorphs reverseDo: [ :anEnteredMorph | > Â Â Â Â Â Â Â Â self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: > anEvent ifNotFocusedDo: [] ] > > enteredMorphs is changing indead from WriteStream -> Array. > IMHO mutating an inst var is very bad behaved > This should be corrected ASAP > This class is really confusing.. According to its use (see senders to #mouseOverHandler) it actually handling more than just mouse over events. I would say it should be named MouseEventHander :) But still , its hard to say, why it is so complex.. and what its purpose. -- Best regards, Igor Stasenko AKA sig.

Aug. 8, 2011

Re: [Pharo-project] FSGit for new Filesystem implementation

by StÃ©phane Ducasse

Thanks max. Stef > Hello everyone. > > I'm happy to announce that Camillo (with a little help from me) has adapted FSGit to run with the new Filesystem implementation (version 2.0.1). All tests are green. Nonetheless, please be careful when using it. There's also support for Monticello, although I haven't used that myself. AFAIK Camillo uses that part to store his Monticello versions in a git repository on his disk (correct me if I'm wrong). > > One new thing is that I wrote thorough tests for the handling of packs (thanks to Simon Denier for reporting the bug). Note that FSGit *cannot* write pack files and I have decided to not implement write support in the future (if someone else wants to however, I'm fine with that :) ). > > I'd like to thank all the people who have snuck looks at FSGit and pointed out important stuff. There's still a lot that can be improved but I feel that FSGit is on a good way. > > > You can load FSGit through ConfigurationOfFSGit which you will find in the FSGit SqueakSource repository. This will also load Filesystem into the image. > > As usual, if you have suggestions or find a bug, hit me up directly or send an email to the list. > > > > Here's to the coolest Smalltalk environment available! :D > Max

Aug. 8, 2011

Re: [Pharo-project] audio and pharo

by StÃ©phane Ducasse

> That's unfortunate. :-( Ok. thanks for the reply. yes but if nobody helps we cannot do everything. What are you looking for? Stef > > On Mon, Aug 8, 2011 at 00:51, Henrik Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Aug 8, 2011, at 3:00 49AM, Brad Fuller wrote: >> >>> Has pharo improved/added any audio related classes since the fork? >>> >>> Thanks, >>> brad >>> >> >> Improved, no. >> Kept what you'd find in Sound-* in Squeak up to date? Sort of. >> Though there were problems with loading it in 1.2/1.3 I'm not sure was resolved correctly, you can find the code in PharoSound repository on Squeaksource. >> >> As for improvements, you could check out http://forum.world.st/ANN-SqueakMovieMorph-Alpha-plays-any-video-file-playa… >> (make sure to use a VM including the plugin) >> >> Cheers, >> Henry >> >

Aug. 8, 2011

Re: [Pharo-project] [Vm-dev] Re: Troubles with #flushCache and #run:with:in:

by Jorge Ressia

Hi Eliot, I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that? I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this. Cheers, On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > Â Â Â I'm in touch with Lukas on this but have no time to address it right now. Â worry not :) > > On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> Maybe cc'ing VM mailing list can help. >> >> On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >>> Hi Eliot, >>> >>> I am using one of the latest VMs from your site (VM.r2434) and I >>> continue to have subtle problems with objects as methods (#flushCache, >>> #run:with:in:). >>> >>> The issue is that the test coverage in Pharo is kind of broken on Cog >>> for a long time already. It reports methods as not covered that are >>> clearly covered, and tests seem to randomly fail. >>> >>> I suspected that there is something wrong with the coverage code >>> itself. So I started to experiment with TestCoverage>>flushCache and >>> noticed that the current implementation >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference methodSymbol flushCache >>> >>> performs not that well: The set of not covered methods is wrong and >>> many tests suddenly fail. If I replace it with >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference actualClass flushCache >>> >>> I actually get accurate coverage information, but there are still a >>> few tests constantly failing. I tried to use all possible combinations >>> of #flushCache (also calling it on the compiled method), but only >>> flushing the cache on the class seems to work properly. So far so >>> good, but I really wonder what the correct way is to flush the cache? >>> :-) >>> >>> For my experiments I was using the package 'AST-Tests-Semantics'. This >>> is a small package with lots of test methods that cover each method >>> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" >>> problem is that when running these tests in coverage mode, the same 4 >>> tests always fail: >>> >>> Â Â RBSemanticTest>>testBlockScope >>> Â Â RBSemanticTest>>testCascadeReceiver >>> Â Â RBSemanticTest>>testClassVariableBinding >>> Â Â RBSemanticTest>>testGlobalVariableBinding >>> >>> Not sure of how to debug that? Do you have an idea why these otherwise >>> passing tests suddenly fail? If you want to try to reproduce you can >>> use any Pharo image with the tests loaded, or use those that I used: >>> >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> >>> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. >>> >>> Any help or clarification would be appreciated :-) >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > best, > Eliot > > -- Jorge Ressia www.jorgeressia.com

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by Nicolas Cellier

2011/8/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: > > MouseOverHandler>>handleAsMouseEnter: anEvent > Â Â Â Â | asMouseEnterEvent | > Â Â Â Â asMouseEnterEvent := anEvent asMouseEnter. > Â Â Â Â enteredMorphs := enteredMorphs contents. > Â Â Â Â enteredMorphs reverseDo: [ :anEnteredMorph | > Â Â Â Â Â Â Â Â self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: > anEvent ifNotFocusedDo: [] ] > > enteredMorphs is changing indead from WriteStream -> Array. s/indead/indeed/ > IMHO mutating an inst var is very bad behaved > This should be corrected ASAP > > Nicolas > > 2011/8/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >> Looks like you may have changed one of the following methods: >> >> CharacterBlockScanner buildCharacterBlockIn: {private} >> CharacterBlockScanner characterBlockAtPoint:index:in: {scanning} >> NewParagraph defaultCharacterBlock {selection} >> >> since getting a CharacterBlockScanner back instead of a CharacterBlock in >> MultiNewParagraph>>buildSelectionBlocksFrom:to: >> >> Regards, Gary >> >> ----- Original Message ----- From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 08, 2011 6:29 PM >> Subject: Re: [Pharo-project] GUI failing apart >> >> >>> Here it is, in attachment, there actually are some GUI related >>> exceptions captured. Troubles started an hour or so ago. >>> >>> Thanks for your time and best regards >>> Janko >>> >>> S, Gary Chambers piÅ¡e: >>>> >>>> Your PharoDebug.log may have some clues... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Janko MivÅ¡ek" >>>> <janko.mivsek(a)eranova.si> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, August 08, 2011 6:04 PM >>>> Subject: [Pharo-project] GUI failing apart >>>> >>>> >>>>> Hi guys, >>>>> >>>>> Strange things start happening to my 1.3 image. When edited some method >>>>> it suddenly became covered with red, yellow crossed. Now other windows >>>>> also have trouble to recreate when they come in focus. Not to mention >>>>> many other such problems I cannot even describe. I somehow still manage >>>>> to work with this image but with such trouble all the time. >>>>> >>>>> Is there a way to recover this image from such troubles? >>>>> >>>>> Best regards >>>>> Janko >>>>> >>>>> -- >>>>> Janko MivÅ¡ek >>>>> Aida/Web >>>>> Smalltalk Web Application Server >>>>> http://www.aidaweb.si >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko MivÅ¡ek >>> Svetovalec za informatiko >>> Eranova d.o.o. >>> Ljubljana, Slovenija >>> www.eranova.si >>> tel: Â 01 514 22 55 >>> faks: 01 514 22 56 >>> gsm: 031 674 565 >>> >> >> >> >

Aug. 8, 2011

Re: [Pharo-project] GUI failing apart

by Nicolas Cellier

I also noted this: (Array does notUnderstand: #nextPut:) and it comes from: MouseOverHandler>>handleAsMouseEnter: anEvent | asMouseEnterEvent | asMouseEnterEvent := anEvent asMouseEnter. enteredMorphs := enteredMorphs contents. enteredMorphs reverseDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [] ] enteredMorphs is changing indead from WriteStream -> Array. IMHO mutating an inst var is very bad behaved This should be corrected ASAP Nicolas 2011/8/8 Gary Chambers <gazzaguru2(a)btinternet.com>: > Looks like you may have changed one of the following methods: > > CharacterBlockScanner buildCharacterBlockIn: {private} > CharacterBlockScanner characterBlockAtPoint:index:in: {scanning} > NewParagraph defaultCharacterBlock {selection} > > since getting a CharacterBlockScanner back instead of a CharacterBlock in > MultiNewParagraph>>buildSelectionBlocksFrom:to: > > Regards, Gary > > ----- Original Message ----- From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 08, 2011 6:29 PM > Subject: Re: [Pharo-project] GUI failing apart > > >> Here it is, in attachment, there actually are some GUI related >> exceptions captured. Troubles started an hour or so ago. >> >> Thanks for your time and best regards >> Janko >> >> S, Gary Chambers piÅ¡e: >>> >>> Your PharoDebug.log may have some clues... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Janko MivÅ¡ek" >>> <janko.mivsek(a)eranova.si> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, August 08, 2011 6:04 PM >>> Subject: [Pharo-project] GUI failing apart >>> >>> >>>> Hi guys, >>>> >>>> Strange things start happening to my 1.3 image. When edited some method >>>> it suddenly became covered with red, yellow crossed. Now other windows >>>> also have trouble to recreate when they come in focus. Not to mention >>>> many other such problems I cannot even describe. I somehow still manage >>>> to work with this image but with such trouble all the time. >>>> >>>> Is there a way to recover this image from such troubles? >>>> >>>> Best regards >>>> Janko >>>> >>>> -- >>>> Janko MivÅ¡ek >>>> Aida/Web >>>> Smalltalk Web Application Server >>>> http://www.aidaweb.si >>>> >>> >>> >>> >> >> -- >> Janko MivÅ¡ek >> Svetovalec za informatiko >> Eranova d.o.o. >> Ljubljana, Slovenija >> www.eranova.si >> tel: Â 01 514 22 55 >> faks: 01 514 22 56 >> gsm: 031 674 565 >> > > >

Aug. 8, 2011

Re: [Pharo-project] Be careful, problem with WeakOrderedCollection in Pharo (there is a fix)

by Chris Muller

Ok, thanks for the note. I just skimmed through the issue in tracker and it sounds like Marcus has it straightened out.. I'm glad Pharo decided to keep WeakOrderedCollection and refer to #arrayType in OrderedCollection rather than hard-coded Array. - Chris On Mon, Aug 8, 2011 at 6:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Chris. We found a problem with WeakOrderedCollection in Pharo which may > cause problems in Magma users in Pharo. Basically, once a > WeakOrderedCollection needed to #grew, it stops being weak because the > internal array was replaced by a Array instead of a WeakArray. > > (WeakOrderedCollection new instVarNamed: 'array') class ->>>> WeakArray > > > (WeakOrderedCollection new grow instVarNamed: 'array') class ->>>> Array > > So....I can imagine that some applications running magma may grow a lot due > to this bug. > > Just to check whether someone is having this bug or not, you may want to > execute: > > WeakOrderedCollection allInstances select: [:each | (each instVarNamed: > 'array') class = Array ] > > if you have instances, then that's a problem ;) > > To fix it, you can fileine the changes of the issue tracker: > http://code.google.com/p/pharo/issues/detail?id=4596 > > and then you should fix the already created instances. > > cheers > > ps: I have no idea how much Magma uses WeakOrderedCollection, but I thought > it was just worth it to raise a warning. > > -- > Mariano > http://marianopeck.wordpress.com > > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

Aug. 8, 2011

Re: [Pharo-project] Summary with UUID not so unique.

by Eliot Miranda

On Mon, Aug 8, 2011 at 1:13 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi guys. Can someone do a summary of the problem of UUID not so unique? > because I have been bitten again. > In my image, primMakeUUID is still calling the primitive: > > primMakeUUID > <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > UUIDGenerator default generateBytes: self forVersion: 4. > > By my VM is still broken with this aspect. So....how should we deal with > it? > Update your VM. > > a) Change/Commmit/Integrate this: > > primMakeUUID > UUIDGenerator default generateBytes: self forVersion: 4. > > b) there are new Cog VMs somewhere that I can use with this problem fixed? > Yes. See http://www.mirandabanda.org/files/Cog/VM/VM.r2485/ > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Aug. 8, 2011