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

Re: [Pharo-project] thanks for pharoconf

by StÃ©phane Ducasse

yes igor. You are a great enabler. We should finish events, athens, opal and release 2.0 ;) > +1 > > i got a hyper-motivation injection because of it .. :) > > On 27 May 2012 00:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I had a good time at PharoConf. >> >> Thanks for organizing it. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by StÃ©phane Ducasse

thanks for coming :) I went to bed at 9:00 exhausted but happy. Now working on fixing RPackage, events and a couple more. Stef PS: we ate all the chocolate. > Hi, > > I had a good time at PharoConf. > > Thanks for organizing it. > > Cheers, > Doru

May 27, 2012

Re: [Pharo-project] class message

by StÃ©phane Ducasse

> :) > But we always try to minimize else we would go much faster and btw class should not break older code :) > > It did break Mocketry (http://www.squeaksource.com/Mocketry) > I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic. How mockery used the fact that class was not a send message? Stef

May 27, 2012

Re: [Pharo-project] building and installing a morph in the background

by Tudor Girba

Hi Igor, I tried adding it outside of the addDeferredUIMessage as well: process := [ newMorph := aBlockWhoseValueReturnsAMorph value. WorldState addDeferredUIMessage: [...] ] newProcess. However, the problem seems to be the same. If you, or someone else, would have time to look into it, here is how to reproduce: Download the latest moose image: http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… Run: | browser | browser := GLMTabulator new. browser column: #numbers. browser transmit to: #numbers; andShow: [:a | a list display: [:x | 1 to: x] ]. browser transmit from: #numbers; toWatcher; andShow: [:a | a list title: [:x | 'Large presentation for ', x asString]; display: [:x | x to: (x * 1000)] ]. (browser openOn: 42) left: 0; top: 0. (GLMWatcherWindow uniqueInstance toggleOpen) left: 300; top: 100 . Time millisecondsToRun: [ (browser panes first port: #selection) value: 10 ] . The relevant code is in GLMWatcherWindow>>addContent: The interesting thing is that if I print the amount of time, it goes fast (close to 0s), but the UI is still blocked. Cheers, Doru On 27 May 2012, at 04:23, Igor Stasenko wrote: > On 27 May 2012 01:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> process := [ >> WorldState addDeferredUIMessage: [ >> newMorph := aBlockWhoseValueReturnsAMorph value. >> self contentsMorph >> removeAllMorphs; >> addMorph: newMorph fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)) >> ] >> ] newProcess. > > Sure thing, because you still building your morph in UI thread (inside > a block which you pass > to addDeferredUIMessage. > > To make it clear, WorldState addDeferredUIMessage: > can be rephrased as: > > WorldState evaluateThisBlockInUIProcess: > > So, moving > newMorph := aBlockWhoseValueReturnsAMorph value. > outside of this block will do the thing. -- www.tudorgirba.com "Speaking louder won't make the point worthier."

May 27, 2012

Re: [Pharo-project] building and installing a morph in the background

by Igor Stasenko

On 27 May 2012 01:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am trying to build a complex morph and install it in another morph in a background process such that it does not impact the rest of the user interface. After a discussion with Igor, I got to the code below (similar to what can be found in CodeAnnotationPane). > > However, it still does not seem to have the desired effect as the main ui still appears to be blocked. Can anyone see any problem with the code? > > The code can be found in the latest version of Glamour. > > Cheers, > Doru > > > GLMWatcherWindow>>addContent: aBlockWhoseValueReturnsAMorph > Â Â Â Â | newMorph | > > Â Â Â Â "if we are still rendering some contents for another watcher, > Â Â Â Â we stop and replace with the current request" > Â Â Â Â process ifNotNil: [ process terminate ]. > Â Â Â Â process := nil. > > Â Â Â Â process := [ > Â Â Â Â Â Â Â Â WorldState addDeferredUIMessage: Â [ > Â Â Â Â Â Â Â Â Â Â Â Â newMorph := aBlockWhoseValueReturnsAMorph value. > Â Â Â Â Â Â Â Â Â Â Â Â self contentsMorph > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â removeAllMorphs; > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â addMorph: newMorph fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)) > Â Â Â Â Â Â Â Â ] > Â Â Â Â ] newProcess. > Â Â Â Â process priority: Processor userBackgroundPriority. > Â Â Â Â process resume Sure thing, because you still building your morph in UI thread (inside a block which you pass to addDeferredUIMessage. To make it clear, WorldState addDeferredUIMessage: can be rephrased as: WorldState evaluateThisBlockInUIProcess: So, moving newMorph := aBlockWhoseValueReturnsAMorph value. outside of this block will do the thing. > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by Igor Stasenko

+1 i got a hyper-motivation injection because of it .. :) On 27 May 2012 00:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I had a good time at PharoConf. > > Thanks for organizing it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > -- Best regards, Igor Stasenko.

May 27, 2012

[Pharo-project] building and installing a morph in the background

by Tudor Girba

Hi, I am trying to build a complex morph and install it in another morph in a background process such that it does not impact the rest of the user interface. After a discussion with Igor, I got to the code below (similar to what can be found in CodeAnnotationPane). However, it still does not seem to have the desired effect as the main ui still appears to be blocked. Can anyone see any problem with the code? The code can be found in the latest version of Glamour. Cheers, Doru GLMWatcherWindow>>addContent: aBlockWhoseValueReturnsAMorph | newMorph | "if we are still rendering some contents for another watcher, we stop and replace with the current request" process ifNotNil: [ process terminate ]. process := nil. process := [ WorldState addDeferredUIMessage: [ newMorph := aBlockWhoseValueReturnsAMorph value. self contentsMorph removeAllMorphs; addMorph: newMorph fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)) ] ] newProcess. process priority: Processor userBackgroundPriority. process resume -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

May 26, 2012

[Pharo-project] thanks for pharoconf

by Tudor Girba

Hi, I had a good time at PharoConf. Thanks for organizing it. Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

May 26, 2012

Re: [Pharo-project] Working directory

by Igor Stasenko

On 26 May 2012 16:55, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sat, May 26, 2012 at 10:44:15AM +0200, Camillo Bruni wrote: >> >> On 2012-05-26, at 06:41, David T. Lewis wrote: >> >> > What is a "working directory"? And for that matter, what is a "directory"? >> > These are concepts and metaphors that have been used in various ways by >> > some (but not all) operating systems, and that do not automatically have >> > a well defined meaning independent of those metaphors and operating systems. >> > There is really no such thing as "current working directory" in Squeak/Pharo, >> > so if you want to create such a concept you are free to do so in any way >> > you please. >> >> well on all unix there is a very clear precise definition of it "getcwd()"! >> and on all decent platforms there's a more or less clear notion of >> what is a file and what is a directory? >> >> Talking about Pharo, which platforms do we target? >> - Linux >> - OS X >> - Win > > You're right about that of course. > > I guess I just like to remind people that unix is not the only good > operating system that has ever been invented, and that ideas like "files" > are just part of a metaphor that was invented decades ago to help people > relate their computer to something they already understood (a physical > desk with a desktop and with file cabinets filled with folders that > contained paper documents). > > With cell phones, tablets, and solid state storage it is quite possible > that the ancient "desk with file cabinet" metaphors will become obsolete, > so it is good to keep an open mind. > I can hardly see what else can replace a tree/graph-like data organization. >> >> maybe I am wrong, but I think we could assume a common denominator here? >> (Using python and ruby yields to the same results AFAIK) > > I don't know. But OS X may well be an example of an environment that > presents a file system view to the user that is different from the file > system view at the unix file system or unix shell level. And Windows 7 > appears to be trying to imitate OS X in that regard. If you implement > a concept of "current working directory" in the image, you are free to > define it in whatever way makes good sense. But there is no fundamental > reason why you need to use a definition that matches the unix file system > view (as reported by OSProcess). You might instead prefer to use a > definition that matches what the OS X user expects to see in the finder, > and maybe that is a different thing (I am not an OS X user, so apologies > if I am getting this wrong). > the 'working directory' concept matters for consoles & console-based shells. So, of course it is beneficial to have same behavior/definition of working directory as in shell. For those who using different graphical-rich file system "shells" like 'finder' on os-x or 'explorer' on windows, this concept means nothing, as well as things like stdin/stdout/pipes and many other. So why we need to worry about it? > Dave -- Best regards, Igor Stasenko.

May 26, 2012

Re: [Pharo-project] class message

by Igor Stasenko

On 26 May 2012 22:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 26, 2012, at 8:59 PM, Milan Mimica wrote: > >> On 26 May 2012 20:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > >> > What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that? >> > >> > no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send. >> > >> > That is much better. Thanks! I like progress even if it breaks old code. >> >> :) >> But we always try to minimize else we would go much faster and btw class should not break older code :) >> >> It did break Mocketry (http://www.squeaksource.com/Mocketry) >> I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic. >> > normally it should do the opposite: as #class is not special, magic is much easier. > you have no trust, you're from academia :) > Â Â Â Â Marcus -- Best regards, Igor Stasenko.

May 26, 2012