- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: A new way to render the debugger

by StÃ©phane Ducasse

I like the fact that the method symbols are aligned If the class name is too long (is it cut) so that we can still see the selector without horizontally scrolling? On Sep 7, 2011, at 6:09 PM, Benjamin wrote: > Hello guys, > > Camillo and I were looking for a way to improve the way the debugger show the stack, so we worked on a tabbed version of the list. Here is a screenshot: > > <Screen shot 2011-09-07 at 4.56.06 PM.png> > > > And so we implement the same on senders/implementors :) > > Do you like it ? (Should it be integrated ?) > > Thanks in advance for your feedback, > > > Ben >

Sept. 7, 2011

Re: [Pharo-project] How to convert Sensor polling left over

by StÃ©phane Ducasse

:) you see you found my mail Tx for the record of our discussions. On Sep 7, 2011, at 5:03 PM, Igor Stasenko wrote: > On 7 September 2011 10:53, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> Hi igor >> >> how should I convert code like that >> >> [ Sensor anyButtonPressed ] whileFalse: >> [ aBitBlt destOrigin: Sensor cursorPoint. >> aBitBlt copyBits ]. >> >> So that it avoid polling? >> >> Should we change >> >> contents := (Sensor shiftPressed not) >> ifTrue: [currentCompiledMethod decompileWithTemps] >> ifFalse: [currentCompiledMethod decompile]. >> contents := contents decompileString asText makeSelector >> > > For examples which using some drawing on screen, i think best would be > to implement a custom morph, which > accepts a block for drawing stuff in it. > Then example code could draw there, and open it in morph. Then once > used no longer amused, he can just close morph/window > instead of waiting for mouse clicks etc etc. > > For things like shift-key pressed, a code should use events /hand to > extract the key statuses, but not sensor. > One of reasons for that, if we could have an event recorder & event > player, all tests/examples could use them. > But if you refer directly to Sensor, such scenarios are not possible, > since sensor provides an actual status of keyboard/events whatever. > >> >> or >> [(nextEvent := Sensor peekEvent) isNil] whileFalse: >> [nextEvent first = currentBuf first >> ifFalse: [^trail contents "different event type"]. >> nextEvent fifth = currentBuf fifth >> ifFalse: [^trail contents "buttons changed"]. >> nextEvent sixth = currentBuf sixth >> ifFalse: [^trail contents "modifiers changed"]. >> "nextEvent is similar. Remove it from the queue, and check the next." >> nextEvent := Sensor nextEvent. >> nextEvent >> ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth ]]. >> >> Then when I install the nonpolling behavior >> InputEventSensor installPollingEventSensorFramework >> the menu of the world gets sluggish (may be I do not use the right VM BTW). > > yes, you using old VM, which for some reason not awaking the fetcher > process immediately once new events > arrived from OS. > >> >> Stef >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Sept. 7, 2011

[Pharo-project] Fwd: A new way to render the debugger

by Benjamin

Hello guys, Camillo and I were looking for a way to improve the way the debugger show the stack, so we worked on a tabbed version of the list. Here is a screenshot: And so we implement the same on senders/implementors :) Do you like it ? (Should it be integrated ?) Thanks in advance for your feedback, Ben

Sept. 7, 2011

[Pharo-project] [update 1.4] #14124

by Marcus Denker

14124 ----- Issue 4613: metacello default platform http://code.google.com/p/pharo/issues/detail?id=4613 Issue 4712: move some Collections package to Kernel http://code.google.com/p/pharo/issues/detail?id=4712 -- Marcus Denker -- http://marcusdenker.de

Sept. 7, 2011

Re: [Pharo-project] How to convert Sensor polling left over

by Igor Stasenko

On 7 September 2011 10:53, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi igor > > how should I convert code like that > > [ Sensor anyButtonPressed ] whileFalse: > Â Â Â Â Â Â Â Â [ aBitBlt destOrigin: Sensor cursorPoint. > Â Â Â Â Â Â Â Â aBitBlt copyBits ]. > > So that it avoid polling? > > Should we change > > contents := (Sensor shiftPressed not) > Â Â Â Â Â Â Â Â ifTrue: [currentCompiledMethod decompileWithTemps] > Â Â Â Â Â Â Â Â ifFalse: [currentCompiledMethod decompile]. > Â Â Â Â contents := contents decompileString asText makeSelector > For examples which using some drawing on screen, i think best would be to implement a custom morph, which accepts a block for drawing stuff in it. Then example code could draw there, and open it in morph. Then once used no longer amused, he can just close morph/window instead of waiting for mouse clicks etc etc. For things like shift-key pressed, a code should use events /hand to extract the key statuses, but not sensor. One of reasons for that, if we could have an event recorder & event player, all tests/examples could use them. But if you refer directly to Sensor, such scenarios are not possible, since sensor provides an actual status of keyboard/events whatever. > > or > [(nextEvent := Sensor peekEvent) isNil] whileFalse: > Â Â [nextEvent first = currentBuf first > Â Â Â ifFalse: [^trail contents "different event type"]. > Â Â nextEvent fifth = currentBuf fifth > Â Â Â ifFalse: [^trail contents "buttons changed"]. > Â Â nextEvent sixth = currentBuf sixth > Â Â Â ifFalse: [^trail contents "modifiers changed"]. > Â Â "nextEvent is similar. Â Remove it from the queue, and check the next." > Â Â nextEvent := Sensor nextEvent. > Â Â nextEvent > Â Â Â ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth ]]. > > Then when I install the nonpolling behavior > Â Â Â Â InputEventSensor installPollingEventSensorFramework > the menu of the world gets sluggish (may be I do not use the right VM BTW). yes, you using old VM, which for some reason not awaking the fetcher process immediately once new events arrived from OS. > > Stef > > -- Best regards, Igor Stasenko AKA sig.

Sept. 7, 2011

Re: [Pharo-project] how to capture pasting in a textmorph

by Tudor Girba

How do I find the changes? Doru On 7 Sep 2011, at 14:56, Camillo Bruni wrote: > It has been integrated in 1.4 but I guess you can copy out the changes and merge them in 1.3 (though no guarantee that this works)â¦ > > cami > > On 2011-09-07, at 10:22, Tudor Girba wrote: >> Is this available only in 1.4? >> >> Cheers, >> Doru >> >> >> On 7 Sep 2011, at 10:05, Camillo Bruni wrote: >> >>> I added a PluggableTextMorph >> #changedAction: which should do exactly that. It's currently used for the new ClassSerach widget which as a live-filtered list. >>> >>> cami >>> >>> On 2011-09-07, at 09:57, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I have a PluggableTextMorph, and I would like to get notified every time the text contents change. >>>> >>>> Currently, I intercept keystroke:from:, but the problem is that this does not capture pasting of text. Is there a better hook? >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Value is always contextual." >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Sept. 7, 2011

Re: [Pharo-project] how to capture pasting in a textmorph

by Camillo Bruni

It has been integrated in 1.4 but I guess you can copy out the changes and merge them in 1.3 (though no guarantee that this works)â¦ cami On 2011-09-07, at 10:22, Tudor Girba wrote: > Is this available only in 1.4? > > Cheers, > Doru > > > On 7 Sep 2011, at 10:05, Camillo Bruni wrote: > >> I added a PluggableTextMorph >> #changedAction: which should do exactly that. It's currently used for the new ClassSerach widget which as a live-filtered list. >> >> cami >> >> On 2011-09-07, at 09:57, Tudor Girba wrote: >> >>> Hi, >>> >>> I have a PluggableTextMorph, and I would like to get notified every time the text contents change. >>> >>> Currently, I intercept keystroke:from:, but the problem is that this does not capture pasting of text. Is there a better hook? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > >

Sept. 7, 2011

[Pharo-project] 64 bit

by Milan Mimica

Hello list! I was wondering, are you going to provide a 64-bit OneClick package any time soon? When and what does that depend on? If not, how do I go about building my own 64-bit image on linux? -- Milan Mimica http://sparklet.sf.net

Sept. 7, 2011

Re: [Pharo-project] Monticello and different time zones

by Frank Shearar

On 7 September 2011 12:33, Andy Kellens <akellens(a)vub.ac.be> wrote: > > On 07 Sep 2011, at 12:38, Frank Shearar wrote: > >> On 7 September 2011 10:52, Andy Kellens <akellens(a)vub.ac.be> wrote: >>> Hello, >>> >>> While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. >>> Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. >>> >>> As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. >>> It looks like Monticello uses the timestamp of Â the computer from which the package was published; not the timestamp from the computer. >>> Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. >>> >>> Shouldn't Monticello use the timestamp from the server? >> >> What's a server, though? My computer? Your computer? Some shared >> repository (which is really just another peer)? >> >> What if I commit one version to my local package cache, daylight >> savings starts (or ends - I can never remember which makes the clock >> go back), and I commit a new version. Hey presto, the new version has >> a timestamp older than the old version. >> >> The answer is this: don't look at the timestamp; it's irrelevant. Look >> at the ancestry of the package. > > The motivation of using the timestamp is that we are computing dependencies between packages. > Sure, in the case that you have a Metacello configuration, or you use slices, it is fairly easy to see which versions of packages go together. > However, if you do not have this information, timestamps seem to be the only thing you can rely on. I've worked a little on this recently, in trying to break up LanguageBoxes so I can port it to Squeak. The approach I used was to try port DependencyBrowser to point at a Monticello repository instead of an image. It examines the latest version (*) of every package within that repository, collecting information like "this package defines these classes" and "this method uses these classes, so must depend on that package". It's very far from complete, mind you. (*) Version with the highest number frank > Actually, we were able to pin down the problem: it is not an issue of Monticello at all but rather an issue related to how time zones are handled in Pharo. > Pharo appears to set the local time zone when opening the image; if you are traveling with an image open (what Veronica did), change time zones, and continue to work, then your TimeStamps are not aware of the fact that you changed time zones. > > This made me wonder: what is the reason for keeping track of the current time zone within the image, and not just relying on the computer's time when calculating DateAndTime now? > There is a primitive that asks for the local time zone. > >> >> frank >> >>> Kind regards, >>> >>> Andy >>> >> > > >

Sept. 7, 2011

Re: [Pharo-project] Monticello and different time zones

by Andy Kellens

On 07 Sep 2011, at 12:38, Frank Shearar wrote: > On 7 September 2011 10:52, Andy Kellens <akellens(a)vub.ac.be> wrote: >> Hello, >> >> While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. >> Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. >> >> As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. >> It looks like Monticello uses the timestamp of the computer from which the package was published; not the timestamp from the computer. >> Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. >> >> Shouldn't Monticello use the timestamp from the server? > > What's a server, though? My computer? Your computer? Some shared > repository (which is really just another peer)? > > What if I commit one version to my local package cache, daylight > savings starts (or ends - I can never remember which makes the clock > go back), and I commit a new version. Hey presto, the new version has > a timestamp older than the old version. > > The answer is this: don't look at the timestamp; it's irrelevant. Look > at the ancestry of the package. The motivation of using the timestamp is that we are computing dependencies between packages. Sure, in the case that you have a Metacello configuration, or you use slices, it is fairly easy to see which versions of packages go together. However, if you do not have this information, timestamps seem to be the only thing you can rely on. Actually, we were able to pin down the problem: it is not an issue of Monticello at all but rather an issue related to how time zones are handled in Pharo. Pharo appears to set the local time zone when opening the image; if you are traveling with an image open (what Veronica did), change time zones, and continue to work, then your TimeStamps are not aware of the fact that you changed time zones. This made me wonder: what is the reason for keeping track of the current time zone within the image, and not just relying on the computer's time when calculating DateAndTime now? There is a primitive that asks for the local time zone. > > frank > >> Kind regards, >> >> Andy >> >

Sept. 7, 2011