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

Re: [Pharo-project] Undo/Redo [was: Re: Object Buffer (implementation tryout)]

by John M McIntosh

Ya, I'm sure StÃ©phane said why don't you give a talk on it... On 2010-01-13, at 1:02 AM, Serge Stinckwich wrote: > Advertisement problem ? > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 13, 2010

Re: [Pharo-project] InputSensor next step cleanup

by StÃ©phane Ducasse

thanks mike I realllllly want to clean that part too. And we will do it. This is why I need a bit of supervision and time. Stef On Jan 13, 2010, at 11:20 AM, Michael Rueger wrote: > On 1/13/2010 11:13 AM, Igor Stasenko wrote: > >> Next step is removing a direct reference to Sensor global, and replace >> it with something like: >> >> self eventSensor > > No, that is fixing a sympton, not the problem. > (John will love this ;-) ) > > You would still be polling the sensor. There should be no references to > Sensor -directly or indirectly- at all. The system should be completely > event driven and not be allowed to ask for anything. I know it is just > so comfortable to do this, but a very bad idea. > This basically goes back to introducing global references to ActiveHand > etc, something that really needs to be removed as well. > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] InputSensor next step cleanup

by Michael Rueger

On 1/13/2010 11:13 AM, Igor Stasenko wrote: > Next step is removing a direct reference to Sensor global, and replace > it with something like: > > self eventSensor No, that is fixing a sympton, not the problem. (John will love this ;-) ) You would still be polling the sensor. There should be no references to Sensor -directly or indirectly- at all. The system should be completely event driven and not be allowed to ask for anything. I know it is just so comfortable to do this, but a very bad idea. This basically goes back to introducing global references to ActiveHand etc, something that really needs to be removed as well. Michael

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

we should do something veryDeepFixupWith: deepCopier "If target and arguments fields were weakly copied, fix them here. If they were in the tree being copied, fix them up, otherwise point to the originals!!" veryDeepCopySibling "Do a complete tree copy using a dictionary. Substitute a clone of oldPlayer for the root. Normally, a Player or non systemDefined object would have a new class. We do not want one this time. An object in the tree twice, is only copied once. All references to the object in the copy of the tree will point to the new copy." veryDeepCopyUsing: copier "Do a complete tree copy using a dictionary. An object in the tree twice is only copied once. All references to the object in the copy of the tree will point to the new copy. Same as veryDeepCopy except copier (with dictionary) is supplied. ** do not delete this method, even if it has no callers **" | new refs newDep newModel | new := self veryDeepCopyWith: copier. copier references associationsDo: [:assoc | assoc value veryDeepFixupWith: copier]. "Fix dependents" refs := copier references. DependentsFields associationsDo: [:pair | pair value do: [:dep | (newDep := refs at: dep ifAbsent: [nil]) ifNotNil: [ newModel := refs at: pair key ifAbsent: [pair key]. newModel addDependent: newDep]]]. ^ new veryDeepCopyWith: deepCopier "Copy me and the entire tree of objects I point to. An object in the tree twice is copied once, and both references point to him. deepCopier holds a dictionary of objects we have seen. Some classes refuse to be copied. Some classes are picky about which fields get deep copied." | class index sub subAss new sup has mine | deepCopier references at: self ifPresent: [:newer | ^ newer]. "already did him" class := self class. class isMeta ifTrue: [^ self]. "a class" new := self clone. deepCopier references at: self put: new. "remember" (class isVariable and: [class isPointers]) ifTrue: [index := self basicSize. [index > 0] whileTrue: [sub := self basicAt: index. (subAss := deepCopier references associationAt: sub ifAbsent: [nil]) ifNil: [new basicAt: index put: (sub veryDeepCopyWith: deepCopier)] ifNotNil: [new basicAt: index put: subAss value]. index := index - 1]]. "Ask each superclass if it wants to share (weak copy) any inst vars" new veryDeepInner: deepCopier. "does super a lot" "other superclasses want all inst vars deep copied" sup := class. index := class instSize. [has := sup compiledMethodAt: #veryDeepInner: ifAbsent: [nil]. has := has ifNil: [ false ] ifNotNil: [ true ]. mine := sup instVarNames. has ifTrue: [index := index - mine size] "skip inst vars" ifFalse: [1 to: mine size do: [:xx | sub := self instVarAt: index. (subAss := deepCopier references associationAt: sub ifAbsent: [nil]) "use association, not value, so nil is an exceptional value" ifNil: [new instVarAt: index put: (sub veryDeepCopyWith: deepCopier)] ifNotNil: [new instVarAt: index put: subAss value]. index := index - 1]]. (sup := sup superclass) == nil] whileFalse. new rehash. "force Sets and Dictionaries to rehash" ^ new veryDeepInner: deepCopier "No special treatment for inst vars of my superclasses. Override when some need to be weakly copied. Object>>veryDeepCopyWith: will veryDeepCopy any inst var whose class does not actually define veryDeepInner:" On Jan 13, 2010, at 10:53 AM, StÃ©phane Ducasse wrote: > http://code.google.com/p/pharo/issues/detail?id=1802 > > Stef > > On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote: > >> Lukas Renggli a Ã©crit : >>> I suggest everybody to have a quick look at VW: >>> - they have #copy and #postCopy as we do >>> - they have #shallowCopy that is used from #copy as we do >>> - they have #dcopy (what a horrible name) that is implemented in a >>> similar way to what I suggested for #deepCopy >>> >>> There is nothing else. >>> >> yes, I think we should adopt this with (dcopy -> deepCopy). >> Alain >>> Lukas >>> >>> >> >> >> _______________________________________________ >> 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

Jan. 13, 2010

Re: [Pharo-project] InputSensor next step cleanup

by Igor Stasenko

2010/1/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> do you have one example so that I can evaluate? >> >> there are differents use cases of referencing Sensor (Except examples which could simple be removed from the image). >> >> - asking for the current cursor position (which is the majority of the references) >> e.g. >> 'Scanning ', aFile localName, '...' >> Â Â Â displayProgressAt: Sensor cursorPoint >> Â Â Â from: startPosition to: stopPosition >> Â Â Â during: [:bar | >> >> This could be replaced by Display center, the current active Window position or things like that. >> >> - asking for the state of modifier keys >> >> shift := Sensor leftShiftDown. >> >> This needs some refactoring to hand down the current event into these methods. I already refactored a few of these methods when cleaning up the unicode handling but not all. >> >> >> - the worst offender is actually polling >> e.g. >> newRectFrom: newRectBlock >> >> ... >> [ Sensor nextEvent isNil ] whileFalse. >> buttonNow := Sensor anyButtonPressed. >> newRect := newRectBlock value: rect. >> ... >> I don't remember my original idea, but i offered to replace such uses by something like: Sensor captureEventsDuring: aBlock where block should accept a single event, and it should stay captured until block returns false, i.e.: Sensor captureEventsDuring: [:ev | "handle the event here" ev anyButtonPressed "keep looping if any mouse button still held" ]. Next step is removing a direct reference to Sensor global, and replace it with something like: self eventSensor >> Not always easy to code around this, as you need stateful event handling to replace the polling. On the other hand it looks like the method could simply be removed as there don't seem to be any important callers left. >> >> Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010

Re: [Pharo-project] Issue 1788: SMTPClient does not send HELO or EHLO, session is not initiated

by StÃ©phane Ducasse

already in On Jan 13, 2010, at 10:55 AM, GÃ¶ran Krampe wrote: > StÃ©phane Ducasse wrote: >> Thanks!!! >> Soon in the new image > > You might want to search at bugs.squeak.org from time to time, perhaps > you should want this one too: > > http://bugs.squeak.org/view.php?id=6843 > > Don't have a Pharo handy, perhaps you already fixed it. > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 13, 2010

Re: [Pharo-project] I cannot believe that Browser is relying on Object>>initialExtent

by Igor Stasenko

Kill them , please. :) I dreaming about the time, when every method in Object will have a very strong reasons to stay there. 2010/1/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > hold on :) > we will kill a lot of them one at a time with a nice chainsaw :) > > Stef > > On Jan 13, 2010, at 8:58 AM, Lukas Renggli wrote: > >> And #defaultColor and #inform: and #modelSleep and #modelWakeUp and >> #modelWakeUpIn: and ... >> >> 2010/1/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> argh....... >>> May be not putting everything in Object would help. >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010

[Pharo-project] InputSensor next step cleanup

by StÃ©phane Ducasse

> >> do you have one example so that I can evaluate? > > there are differents use cases of referencing Sensor (Except examples which could simple be removed from the image). > > - asking for the current cursor position (which is the majority of the references) > e.g. > 'Scanning ', aFile localName, '...' > displayProgressAt: Sensor cursorPoint > from: startPosition to: stopPosition > during: [:bar | > > This could be replaced by Display center, the current active Window position or things like that. > > - asking for the state of modifier keys > > shift := Sensor leftShiftDown. > > This needs some refactoring to hand down the current event into these methods. I already refactored a few of these methods when cleaning up the unicode handling but not all. > > > - the worst offender is actually polling > e.g. > newRectFrom: newRectBlock > > ... > [ Sensor nextEvent isNil ] whileFalse. > buttonNow := Sensor anyButtonPressed. > newRect := newRectBlock value: rect. > ... > > Not always easy to code around this, as you need stateful event handling to replace the polling. On the other hand it looks like the method could simply be removed as there don't seem to be any important callers left. > > Michael

Jan. 13, 2010

[Pharo-project] InputSensor next step cleanup

by StÃ©phane Ducasse

> >> what are the next steps with should do for the >> >> Sensor references in the system >> 166 >> and the >> >> I would really to do some steps in the direction of cleaning what should be >> left to do. >> >> I'm confused by the comment >> >> "The usage of these funtions is discouraged. " >> so what should be done? > > the callers need to be rewritten. Right now they still use the old event polling Sensor functions, blocking the Morphic process. They would need to be rewritten to use event handling. > > Michael >

Jan. 13, 2010

Re: [Pharo-project] Issue 1788: SMTPClient does not send HELO or EHLO, session is not initiated

by GÃ¶ran Krampe

StÃ©phane Ducasse wrote: > Thanks!!! > Soon in the new image You might want to search at bugs.squeak.org from time to time, perhaps you should want this one too: http://bugs.squeak.org/view.php?id=6843 Don't have a Pharo handy, perhaps you already fixed it. regards, GÃ¶ran

Jan. 13, 2010