- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about sharing class binding and others

by Camillo Bruni

This is what Pinocchio had, resolving classes was done by looking them up in the current environment (so basically the Class name is just a code macro). This way we could add simple class scopes without too much effort. I guess that would make the following code example a bit more complicated: oldDictClass := Dictionary. Dictionary := SmallDictionary. dict := Dictionary new. Dictionary := oldDictClass self assert: (dict isKindOf: SmallDictionary). but this is a rather bad feature in my eyes ;) On 2012-11-17, at 07:24, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > I love Marcus idea, classes aren't globals any more, and to access them is > simply another message send to a receiver: the environment. ( like the > lobby in Self ) . > > Fernando > > > On Sat, Nov 17, 2012 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> wrote: > >>> The alternative to the current scheme would be to not hard-code the >> class at all in the method at compile time. >>> >>> Instead of looking up the class and compiling the shared literal >> association, we could compile a message send >>> to the current environment. >>> >>> self class environment at: #NameOfClass >>> >>> And it should be noted that this could be evaluated at Jit-compile >> time... the same is true for ivar offsets. There >>> is no reason why these should be visible at the image level. The image >> could talk about names and let the runtime >>> translator infrastucture do the lookups needed for making a static >> version that is fast. >> >> Yes I would like to measure that too. >> My benchmarks were to measure the worse case where we have to manually >> update the methods each time the class is modified. >> >> >>

Nov. 17, 2012

Re: [Pharo-project] nonblocking stdin?

by Camillo Bruni

your example still blocks any background process! the goal would be to have an stdin that only blocks the current thread (or maybe returns nil if it's empty/not ready) so you can still can do some background work. On 2012-11-16, at 20:45, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Pavel Krivanek-3 wrote >> Is there a way how to use nonblocking input from stdin? > > Not sure if this helps, but this works out of the box on 2.0 (see > https://gist.github.com/2604215) > > >> | command | >> [ >> command := FileStream stdin nextLine. >> command ~= 'exit' ] whileTrue: [ | result | >> result := Compiler evaluate: command. >> FileStream stdout nextPutAll: result asString; lf ]. >> >> Smalltalk snapshot: false andQuit: true. > > On 1.3 or 1.4, file in https://gist.github.com/2602113 first: > >> 'From Pharo2.0a of ''18 April 2012'' [Latest update: #20041] on 3 May 2012 >> at 10:45:48 pm'! >> >> !FileStream class methodsFor: 'stdio' stamp: 'SeanDeNigris 5/3/2012 >> 22:37'! >> stdin >> >> ^Stdin ifNil: [ >> Stdin := self standardIOStreamNamed: #stdin forWrite: false. >> Stdin >> disableReadBuffering; >> yourself ].! ! > > > > > > -- > View this message in context: http://forum.world.st/nonblocking-stdin-tp4654956p4655653.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 17, 2012

Re: [Pharo-project] CachedBlockClosure was gone on purpose?

by Marcus Denker

On Nov 17, 2012, at 9:05 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Because it is not present in 2.0 but I couldn't find any issue about that. >> Issue was http://code.google.com/p/pharo/issues/detail?id=6708 -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] CachedBlockClosure was gone on purpose?

by Marcus Denker

On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Because it is not present in 2.0 but I couldn't find any issue about that. > Because it does not work with the block closure implementation that we have now... The thing is that a block in a method like this: [1+2] is not a literal, but it is instead compiled to bytecode that *creates* a new block at execution time. e.g. test ^[1+3] Test new test == Test new test ==> false. The reason is that blocks are realized like this (to save memory!!, you know, we just have 8GB of it in a shity laptop...): 17 <8F 00 00 04> closureNumCopied: 0 numArgs: 0 bytes 21 to 24 21 <76> pushConstant: 1 22 <20> pushConstant: 3 23 <B0> send: + 24 <7D> blockReturn 25 <7C> returnTop So if you now do a #becomeCached like this: becomeCached self becomeForward: ((CachedBlockClosure new: self size) outerContext: outerContext startpc: startpc numArgs: numArgs cachedValue: self value copiedValues: self) is will have no influence, as the next evaluation of the code containing the block will not see the #becomed block but instead the newly generated one. Damien C. was trying to write documentation and the example he tried to do just did not work (the block was always evaluated). Of course it works if you put the block in an iVar, but that then defeats the whole purpose as the idea of the caching block is to not need an ivar to cache... Again a case where we are shoot in the foot by the horrible architecture of the system. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] Hook into the new progress bar notification?

by Camillo Bruni

On 2012-11-17, at 08:10, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. For some tests I was doing something like this: > > > | log result | > log := FLLoggingSystemProgressItemMorph new. > result := [ super serialize: anObject ] > on: ProgressInitiationException > do: [ :ex | ex sendNotificationsTo: log ]. > self deny: log history isEmpty. > ^ result > > > FLLoggingSystemProgressItemMorph was just a simple logger so that then I > could be sure something was logged. > Of course, this does not work anymore with new progress bar. Is there a way > to achieve more or less the same? Summary: -------- use JobStartNotification Details: -------- the new scheme to show progress is done the following way: [:job| job title: 'doing a lot of work'. self aLotOfWork ] asJob run. To update the progress without a direct reference to Job you throw a JobProgress progress: 0.1 title: 'new title'. All the communication with the external world is done through JobStart, JobChange and JobEnd You can see that the ProgressMorph uses exactly those announcements to update the new. Also there is the JobStartNotification which is thrown in parallel with the JobStart, so you can listen when a job/progress is started somewhere downstream in the control flow.

Nov. 17, 2012

Re: [Pharo-project] SmalltakHub browse projects feature

by Nicolas Petton

Indeed! A more complete search is planned, as well as many new features. Stay tuned :) Nico Geert Claes <geert.wl.claes(a)gmail.com> writes: > I think I read that Nico is working at stHub at the moment so I guess > there'll be some new stuff soon > > > > -- > View this message in context: http://forum.world.st/SmalltakHub-browse-projects-feature-tp4655601p4655628… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Nicolas Petton http://nicolas-petton.fr

Nov. 17, 2012

[Pharo-project] CachedBlockClosure was gone on purpose?

by Mariano Martinez Peck

Because it is not present in 2.0 but I couldn't find any issue about that. Thanks, -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2012

[Pharo-project] Hook into the new progress bar notification?

by Mariano Martinez Peck

Hi guys. For some tests I was doing something like this: | log result | log := FLLoggingSystemProgressItemMorph new. result := [ super serialize: anObject ] on: ProgressInitiationException do: [ :ex | ex sendNotificationsTo: log ]. self deny: log history isEmpty. ^ result FLLoggingSystemProgressItemMorph was just a simple logger so that then I could be sure something was logged. Of course, this does not work anymore with new progress bar. Is there a way to achieve more or less the same? Thanks, -- Mariano http://marianopeck.wordpress.com

Nov. 17, 2012

Re: [Pharo-project] [^ 1] and ifCurtailed:

by ClÃ©ment Bera

Yeah here in your BlockClosure [^1] the homeContext and the outerContext is the context created for UndefinedObject>>DoIt. 2012/11/17 Frank Shearar <frank.shearar(a)gmail.com> > On 16 November 2012 16:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Hi guys > > > > I'm updating the exception chapter to show the interplay between > exception and ensure/ifcurtailed: > > > > [[ ^ 1 ] > > ifCurtailed: [ Transcript show: 'show only curtailed'; cr. ]] > > on: Error do: [ :e | > > Transcript show: 'error'; cr. "do not show it" > > e return: 4 ]. > > > > normally shows that only the ifCurtailed: argument is executed. > > > > Now I do not get why when I select > > [^ 1] value and execute it I do not get an error telling me that > there is no context to return to. > > > > May be because the evaluation itself creates a context. > > That's certainly true if you run it from a Workspace. > > frank > > > Stef > > > > > >

Nov. 17, 2012

Re: [Pharo-project] about sharing class binding and others

by Fernando Olivero

I love Marcus idea, classes aren't globals any more, and to access them is simply another message send to a receiver: the environment. ( like the lobby in Self ) . Fernando On Sat, Nov 17, 2012 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > The alternative to the current scheme would be to not hard-code the > class at all in the method at compile time. > > > > Instead of looking up the class and compiling the shared literal > association, we could compile a message send > > to the current environment. > > > > self class environment at: #NameOfClass > > > > And it should be noted that this could be evaluated at Jit-compile > time... the same is true for ivar offsets. There > > is no reason why these should be visible at the image level. The image > could talk about names and let the runtime > > translator infrastucture do the lookups needed for making a static > version that is fast. > > Yes I would like to measure that too. > My benchmarks were to measure the worse case where we have to manually > update the methods each time the class is modified. > > >

Nov. 17, 2012