- Pharo-dev - lists.pharo.org

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

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

by Serge Stinckwich

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 ;-) >> tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> Here is how to install Athens (I also added this comment to the ConfigurationOfAthens): >>> >>> >>> 1. Install Cairo on your machine >>> For example, for Mac, you open the terminal and run: >>> sudo port install -f cairo +universal >>> >>> More information can be found here: >>> http://cairographics.org/download/ >>> >>> >>> 2. Download the NativeBoost enabled Cog VM from: >>> https://ci.lille.inria.fr/pharo/view/NativeBoost/ >>>

May 25, 2012

[Pharo-project] SmallInteger>>digitAt: protocol

by Sean P. DeNigris

Maybe a small matter, but SmallInteger>>digitAt: is in the "system primitives" protocol, even though it doesn't call a primitive. OTOH, LargePositiveInteger does use a primitive for #digitAt: -- View this message in context: http://forum.world.st/SmallInteger-digitAt-protocol-tp4631830.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2012

[Pharo-project] Pharo Sprint â Saturday 10h00 â RMoD Lab

by Camillo Bruni

We would like to invite you to a Pharo Sprint on saturday at 10h00: http://www.doodle.com/t5uv5fhmm7adi6cs It will be held in the RMoD lab: http://rmod.lille.inria.fr/web/pier/contact The entrance will be closed and can only be opened with a badge. For those who standing in front of a closed door, call one of the following badge-owners: Camillo Bruni +33 7 86 95 40 78 Marcus Denker +33 3 62 65 52 58 see you!

May 25, 2012

[Pharo-project] InputEventFetcher depending on Cursor and Form

by Guillermo Polito

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

May 25, 2012