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

Re: [Pharo-project] Progress bar in the top left

by Schwab,Wilhelm K

There are times when it is necessary to protect the user from themselves. Modal to a particular window can be a VERY good thing. Several years ago, I remember watching in horror as my chairman was tinkering with a UI I had created that was not sufficiently modal, and he was at extreme risk of losing a lot of "work" as a result. You had to be there... BTW, he's a great guy and would have put it down to a learning experience for us both, not to mention a major bug report. I promptly made it modal, and all was well for years after that. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, May 25, 2012 9:12 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Progress bar in the top left I meant modal. > Since when? > > Rule #1 of UI: never block UI. > Because if you do, then we have no right to call it UI. > > do you know why we need this panic button (Alt-.) in our images? > Exactly because every silly thing prefers to block UI at any point, > even if it doesn't necessary. stef

May 26, 2012

Re: [Pharo-project] Working directory

by Igor Stasenko

we should integrate the chdir fix to osprocess into jenkins vms On 25 May 2012 22:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > When OSProcess is integrated, we will have two different concepts of the > working directory: > Â fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' > asFileReference. > Â [ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. > Â FileSystem disk workingDirectory = fsPwd. "true" > > Â ospPwd := '/Volumes/Sean''s > Universe/sean/.jenkins/jobs/Dynabook/workspace'. > Â OSProcess thisOSProcess chDir: ospPwd. > Â FileSystem disk workingDirectory = ospPwd. "false" > Â (PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true" > > -- > View this message in context: http://forum.world.st/Working-directory-tp4631865.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 26, 2012

Re: [Pharo-project] Book search: PL history and paradigms

by Frank Shearar

Well, objects are closures, so it makes sense to say that Java has closures. It doesn't have _lightweight_ closures with a decent syntax, but it does still have closures! Message passing is "message passing concurrency", which isn't the "message passing" in "message passing vs method invocation". Of course, the chart isn't meant to imply that some language X with paradigms A, B and C can't support paradigm D: you can, for instance, implement the logic programming paradigm in Scheme (miniKanren), Clojure (core.logic) and, well, not in Smalltalk yet (other than the embedded Prologs) because I haven't finished Nutcracker yet! frank On 25 May 2012 22:56, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > I have not read the book, but seeing the principal programming paradigm > poster makes me think about how good it is because Java and Smalltalk are > wrongly categorized, at least for what I understand of the poster (java with > closure, smalltalk not in the message passing category) > > > On Wed, May 23, 2012 at 8:11 AM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 23 May 2012 12:00, Max Leske <maxleske(a)gmail.com> wrote: >> > I'm looking for a good book on programming language history with a focus >> > on the different paradigms (e.g. imperative, functional, â¦). Any >> > suggestions? >> >> Peter Van Roy's and Seif Haridi' "Concepts, Techniques, and Models of >> Computer Programming" [1] has loads on the different paradigms and >> comparing them. Not a lot on the _history_ of those though. >> >> ACM's HOPL conferences would provide the history of particular languages. >> >> Between those two sources you ought to be able to construct something >> like what you need by mapping CTM's "this model uses these paradigms" >> to the HOPL papers. >> >> frank >> >> [1] http://www.info.ucl.ac.be/~pvr/book.html >> >> >> > Thanks, >> > Max >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 4311 - 8404 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site:Â http://www.10Pines.com > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >

May 25, 2012

Re: [Pharo-project] Book search: PL history and paradigms

by Hernan Wilkinson

I have not read the book, but seeing the principal programming paradigm poster makes me think about how good it is because Java and Smalltalk are wrongly categorized, at least for what I understand of the poster (java with closure, smalltalk not in the message passing category) On Wed, May 23, 2012 at 8:11 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 23 May 2012 12:00, Max Leske <maxleske(a)gmail.com> wrote: > > I'm looking for a good book on programming language history with a focus > on the different paradigms (e.g. imperative, functional, â¦). Any > suggestions? > > Peter Van Roy's and Seif Haridi' "Concepts, Techniques, and Models of > Computer Programming" [1] has loads on the different paradigms and > comparing them. Not a lot on the _history_ of those though. > > ACM's HOPL conferences would provide the history of particular languages. > > Between those two sources you ought to be able to construct something > like what you need by mapping CTM's "this model uses these paradigms" > to the HOPL papers. > > frank > > [1] http://www.info.ucl.ac.be/~pvr/book.html > > > > Thanks, > > Max > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - 4311 - 8404** Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

May 25, 2012

Re: [Pharo-project] Book search: PL history and paradigms

by Max Leske

Thanks Frank, I'll take a look at those. Cheers, Max On 23.05.2012, at 13:11, Frank Shearar wrote: > On 23 May 2012 12:00, Max Leske <maxleske(a)gmail.com> wrote: >> I'm looking for a good book on programming language history with a focus on the different paradigms (e.g. imperative, functional, â¦). Any suggestions? > > Peter Van Roy's and Seif Haridi' "Concepts, Techniques, and Models of > Computer Programming" [1] has loads on the different paradigms and > comparing them. Not a lot on the _history_ of those though. > > ACM's HOPL conferences would provide the history of particular languages. > > Between those two sources you ought to be able to construct something > like what you need by mapping CTM's "this model uses these paradigms" > to the HOPL papers. > > frank > > [1] http://www.info.ucl.ac.be/~pvr/book.html > > >> Thanks, >> Max >

May 25, 2012

Re: [Pharo-project] InputEventFetcher depending on Cursor and Form

by Igor Stasenko

There is no reason to setup event fetcher, if there is nobody to consume events (like Morphic) in image. I would 1. remove event fetcher registration from startup list 2. change MorphicUIManager>>onSnapshot: resuming "The resuming argument is true when image boots from disk, and false, if user just did an image snapshot." "if we resuming, check if we're still interactive " resuming ifTrue: [ Smalltalk isInteractive ifFalse: [ ^ self nonInteractiveManager onSnapshot: resuming ]. Smalltalk isHeadless ifTrue: [ ^ self headlessManager onSnapshot: resuming ]]. +++ InputEventFetcher startup. SystemWindow wakeUpTopWindowUponStartup --------------- then we no need to guess where to put Sensor in startup sequence, because it will start up in right place, right before the guy who going to consume events. Starting it up before this place makes little sense anyways - no events will be handled. Shutdown then can be thrown out.. As a bonus, there will be no pointless shutdown/startup when you saving image. On 25 May 2012 15:40, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Does InputEventFetcher really depend on Cursor & Form to install/uninstall > the event fetch process? > > install > Â Â Â "InputEventFetcher install" > > Â Â Â Smalltalk addToStartUpList: self after: Cursor. > Â Â Â Smalltalk addToShutDownList: self after: Form. > > Â Â Â Default := self new. > Â Â Â Default startUp > > > Guille -- Best regards, Igor Stasenko.

May 25, 2012

[Pharo-project] Working directory

by Sean P. DeNigris

When OSProcess is integrated, we will have two different concepts of the working directory: fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' asFileReference. [ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. FileSystem disk workingDirectory = fsPwd. "true" ospPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/workspace'. OSProcess thisOSProcess chDir: ospPwd. FileSystem disk workingDirectory = ospPwd. "false" (PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true" -- View this message in context: http://forum.world.st/Working-directory-tp4631865.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2012

Re: [Pharo-project] [Vm-dev] Re: VM problem?

by Igor Stasenko

On 25 May 2012 20:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Fri, May 25, 2012 at 12:57 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: >> >> Hi, >> I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site. > > > I changed the definition of at: for CompiledMethod to prevent it accessing bytes outside of the bytecodes part of a compiled method. Â What's happening here is that a hash is being derived form the compiled method by looking at the pointers part of the compiled method (i.e. bytes < aMethod initialPC). Yes, this is reasonable. But the more cases like this we find, the more i feel that we need better format for compiled methods, to keep its bytecode in a separate plain bytearray, to be able to reshape/modify the method's state and access it in convenient manner. A bytecode could be held in a first ivar of compiled method. Yes, we will have 4-8 more bytes per method in image (a ByteArray instance header).. but at the same time, we can save our brain cells as well as save bytes of implementation in both image and vm sides: - no need to deduce initialPc/end pc , because it is always 1...bytearray size - simpler method header (no need to count method's literals) - no need for a method trailer crap, any additional state can be held in own ivar. - we can simplify implementation - free the placeholders in object format for something else, now 12..15 (4 values) is for CompiledMethod, we may need only 1. - i would even make an extra slot for JIT code pointer, instead of insane hacks which Eliot has to introduce in Cog, just because of need to keep things compatible. And more about space. My image is 43Mb now. CompiledMethod allInstances size 63563 so, if we have 4 more bytes per method .. this is 254252 more bytes. which is 0.5 % of total space. 8 more bytes per method.. 1% so my image will be 1% bigger.. we dooommeeed.. >Â But it is wrong to try and derive a hash from these bytes. Â Since the GC can move objects these bytes can change as the GC moves the literals a method references (unlike the bytes between: aMethod initialPC and: aMethod size). > Yes. Strange that nobody noticed this before, perhaps because nobody places methods in dicts/setc :) I never found why one would want to put methods in dictionary (they are naturally found in dictionary already). But in case of Moose, this is of course possible. More than that, since CompiledMethod redefines #=, it is strange that it's not redefines #hash as well, because it is one of requirements to make sure they are always in sync. > Two conclusions: > > The solution is to define CompiledMethod>hash such that it does not access bytes < initialPC. Â The hash it is inheriting from ByteArray is fine for ByteArray but not at all OK for CompiledMethod. > Yes, i would just do self methodClass hash bitXor: self selector hash > The VM is revealing a latent bug, i.e. that on older VMs the system could be computing a variable hash, and hence result in not-found errors in certain circumstances, hence the VM is right to impose this stricter bounds checking. > >> >> I'm on Mac os 10.7.4 and the image is: >> >> Pharo1.4 >> Latest update: #14438 >> >> Cheers, >> Fabrizio >> > > > > -- > best, > Eliot > > -- Best regards, Igor Stasenko.

May 25, 2012

Re: [Pharo-project] VM problem?

by Eliot Miranda

On Fri, May 25, 2012 at 12:57 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>wrote: > Hi, > I'm using last Moose build on top of CogVM 2550 and each time I click on a > method an error pops up (see the attachment). The same problem I have it > with older builds of Moose but I don't have any problem if I open the same > image with Cog VM 2540 or CogVM from the Pharo web site. > I changed the definition of at: for CompiledMethod to prevent it accessing bytes outside of the bytecodes part of a compiled method. What's happening here is that a hash is being derived form the compiled method by looking at the pointers part of the compiled method (i.e. bytes < aMethod initialPC). But it is wrong to try and derive a hash from these bytes. Since the GC can move objects these bytes can change as the GC moves the literals a method references (unlike the bytes between: aMethod initialPC and: aMethod size). Two conclusions: The solution is to define CompiledMethod>hash such that it does not access bytes < initialPC. The hash it is inheriting from ByteArray is fine for ByteArray but not at all OK for CompiledMethod. The VM is revealing a latent bug, i.e. that on older VMs the system could be computing a variable hash, and hence result in not-found errors in certain circumstances, hence the VM is right to impose this stricter bounds checking. > I'm on Mac os 10.7.4 and the image is: > > Pharo1.4 > Latest update: #14438 > > Cheers, > Fabrizio > > -- best, Eliot

May 25, 2012

Re: [Pharo-project] loading athens - a user perspective

by Igor Stasenko

On 25 May 2012 18:51, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > EnvoyÃ© de mon iPhone > > Le 25 mai 2012 Ã 20:23, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > >> Should i put more elaborate error message? >> A 'function unavailable' is exception which you get when... function >> is not available. >> >> I just thinking how to prevent receiving a huge and worthless stack traces. :) >> One way is of course write documentation.. :) >> > > Ahah, so maybe I will send more useless stack traces ;-) > No, but frankly, please tell me what was unclear to you, and why you thought that sending a trace will be helpful to resolve the problem. Because this is not a bug, and behavior is correct, so what that trace serves for? -- Best regards, Igor Stasenko.

May 25, 2012