- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Block questions

by StÃ©phane Ducasse

> > > foo > > |b| > b := 3. > ^ [ |a | a :=2. a] > > In my stupid lisp implementation an environment is represented by bindings and closure points to their own environment > so > [ |a | a :=2. a] > points to > (b.3) (toplevel) (and not top-level) > > and for closure execution we just added temporaly a binding for a to the closure environment. > eval a:=2. a in (a) (b.3) (toplevel) > > This is the wrong example. I understand your example below and the fact that closure environment is allocated on the heap via an array to be independent of the activation context but I do not get why consing the local environment to be one current one is wrong. (define (%apply proc largs) (cond ((%primitive? proc) (%apply-internal proc largs)) ((%closure? proc) (%apply-closure proc largs)) (else (error "Bad ! Un-apply-able object !" proc)))) (define (%apply-closure proc largs) ;; apply a closure: evaluate proc body in ;; extended the closure environment with ;; proc arguments and largs (%eval (%closure-body proc) (%extend-env (%closure-args proc) largs (%closure-env proc)))) (define (%eval-lambda expr env) ;; lambda in Scheme captures the environment at compile time ;; expr = ((x) (+ x 2)) (%make-closure (car expr) (cadr expr) env)) > You need to consider how to implement this example: > > Object subclass: #AbstractSuperclass > > AbstractSuperclass>>computeV > | v | > v := 0. > self maybeCapture: [v := v + 1. v]. > ^self maybeBlock: v > > AbstractSuperclass subclass: #CaptureBlock > instanceVariableNames: 'block' > > CaptureBlock>>maybeCapture: aBlock > block := aBlock > > CaptureBlock>>maybeBlock: value > ^block > > AbstractSubclass subclass: #DontCaptureBlock > > DontCaptureBlock>>maybeCapture: aBlock > > DontCaptureBlock>>maybeBlock: value > ^value > > > Then > | thingOne thingTwo | > thingOne := CaptureBlock computeV. > thingTwo := DontCaptureBlock computeV. > (1 to: 10) collect: [:ignore| { thingOne value. thingTwo value }] > > should answer > #((1 0) (2 0) (3 0) ... (10 0)) if 0 value returns 0? yes. (it confused me for a while). > right? So where does the l-value for v in computeV live? Iy must be an l-value since it is assigned to in the block in computeV. It must outlive the activation of computeV since CaptureBlock>maybeCapture: captures the block and CaptureBlock>>maybeBlock: answers it and the doit evaluates it. If it lives on the stack of the activation of computeV then there is no problem in a Context VM, but in a VM that maps activations to stack frames something special (and slow) has to happen when returning from computeV. However, if the l-value lives in a separate Array (as it does in my VisualWorks and Squeak closure implementations, and as happens in some Lisp implementations), nothing special has to happen. The block refers to the Array, *not* to the activation of computeV. > > Make sense now? Yes you allocate on the heap closure binding to be orthogonal to activation context. I will reread your blog now. Stef

April 30, 2012

[Pharo-project] [update 2.0] #20029

by Marcus Denker

20029 ----- Issue 5736: deprecate #getSourceFor:in: http://code.google.com/p/pharo/issues/detail?id=5736 Issue 5741: New version of NautilusCommon http://code.google.com/p/pharo/issues/detail?id=5741 Issue 5745: numArgs, numTemps, endPC & isClean et al http://code.google.com/p/pharo/issues/detail?id=5745 -- Marcus Denker -- http://marcusdenker.de

April 30, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Norbert Hartl

Am 30.04.2012 um 00:11 schrieb Schwab,Wilhelm K: > I stayed on 1.1.1 for a long time for just these reasons. If want people to test new versions, there needs to be at least some hope that they will work. > To be honest I'm not sure if you should upgrade to 1.2. Just wait a little more. And then remember that it will be close to impossible to load an external module. If you don't need one, good, if not you are in serious trouble. Norbert > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Saturday, April 28, 2012 6:44 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > Dale Henrichs wrote >> >> In my last post, I provided my vision of the future >> > That was very helpful. I can see the big picture much better now... > > > Dale Henrichs wrote >> >> If you don't want to experience the pain of developing on a new platform, >> then don't move to the new platform until the hubbub has died down ... >> > I'm perfectly happy, but it seemed like nobody knew where bill was coming > from, while the API and best practices have been rapidly evolving... > > Sean > > -- > View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visi… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 30, 2012

Re: [Pharo-project] Pretty printing on Nautilus

by Davide Varvello

Thanks Mariano. I've zero time now :-) I'm implementing a smalltalk web app for the Italian market, if you can understand a little bit of Italian you can see a demo video here: http://bit.ly/JVeWYe Davide -- View this message in context: http://forum.world.st/Pretty-printing-on-Nautilus-tp4596333p4597485.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 30, 2012

Re: [Pharo-project] Pretty printing on Nautilus

by Davide Varvello

Yep Benjamin, I seconded. Davide -- View this message in context: http://forum.world.st/Pretty-printing-on-Nautilus-tp4596333p4597480.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 30, 2012

Re: [Pharo-project] new icon set

by Bernardo Ezequiel Contreras

the new icon set is really wonderful. THANKS! On Tue, Apr 24, 2012 at 10:46 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 14:54, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 24.04.2012 um 14:37 schrieb Igor Stasenko: > > > > On 24 April 2012 14:13, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > > > > > > but, Norbert, I don't see the point. In a server you will not have (or > > *should* not have) a display... so rendering time, etc. is non an issue, > > because it will not be any... or I'm missing something? > > > > > > I think most people using pharo on the server are using VNC to maintain > > them. I do that,too, in lack of a better tool. So in this case there is > a > > display and there are icons. Rendering is not an issue as long as you > > suspend to UI thread until you need it. > > > > So, let me just repeat > > > > > > ...new icons.... cool! > > > > ...svg icons.....cool! > > > > ...removable icons...cool! > > > > > > That's basically all I wanted to say. > > > > > > > > and this is not preventing an operating systems from having even more > > rich graphics and still use remote desktop connections? > > i don't share your concerns.. because we're talking about different > > terms of use. > > for desktop applications we need a modern rich graphics and eye candy. > > this not a question. > > > > for servers you can live perfectly with command-line tools only, and > > pharoers also working in that direction.. > > so it is not an exclusive choice where you should pick between one > > over another. > > you can have both: minimal memory footprint on server(s) and decent > > graphics on desktop. i am talking about modular system, where you can > > (un)load modules at your please, and we're moving towards it. > > > > > > Igor, > > > > I didn't say there should be one approach and that you need to choose. I > > tried to make explicit that having options is a good thing. And that > > includes the joy of using a commandline for a server or not. You have no > > reason to decide for everyone that they should live with commandline > tools > > on the server. > > I was talking about the near future and you reach far more off. Of > course I > > like to have a tiny pharo image running on a server that lets me connect > > from my development image and lets me debug/inspect everything from > remote > > where everything is either SVG or opengl. But I don't expect that to > happen > > tomorrow or the day after. There is a need for short term solution. Or > to > > make fun of a quote > > > > Don't obscure my reality with your future > > > > no, i don't want to put you into a cage. > my post was primarily to advertise some of my work :) > > > one of the problems with graphics, is that if you working with bitmap > format(s), > like icon sets or fonts, you always have to keep multiple resolutions > for them.. > for different DPI and different themes. > With vector graphics this is obviously not an issue. > And i making SVG importer mainly to open a rich vector graphics world to > pharo. > So, you can create graphics using editors like inkscape or other , and > then just put it into your image. > And i didn't said that you cannot use bitmaps as endpoint format, > while using SVG as a source.. > so in case if you want to render different resolution bitmaps you can > always reproduce them > in a couple of minutes.. > > > Norbert > > > > > > -- > Best regards, > Igor Stasenko. > >

April 30, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

I stayed on 1.1.1 for a long time for just these reasons. If want people to test new versions, there needs to be at least some hope that they will work. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Saturday, April 28, 2012 6:44 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Dale Henrichs wrote > > In my last post, I provided my vision of the future > That was very helpful. I can see the big picture much better now... Dale Henrichs wrote > > If you don't want to experience the pain of developing on a new platform, > then don't move to the new platform until the hubbub has died down ... > I'm perfectly happy, but it seemed like nobody knew where bill was coming from, while the API and best practices have been rapidly evolving... Sean -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visi… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 29, 2012

Re: [Pharo-project] Pretty printing on Nautilus

by Benjamin

I will implement a pretty print. But the thing is since I am not the god of pretty print, I definitely want a mechanism to let every user to specify it's own way to pretty print. Without that, it's useless for me :) Ben On Apr 29, 2012, at 2:59 PM, Davide Varvello wrote: > Hi, > Today I have a lot of "cosmetic" questions :-) > How can I enable pretty printing on Nautilus? Moreover, the old cmd-r does > not work anymore, right? > Thanks > Davide > > -- > View this message in context: http://forum.world.st/Pretty-printing-on-Nautilus-tp4596333p4596333.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 29, 2012

Re: [Pharo-project] Redefine shortcuts

by Guillermo Polito

On Sun, Apr 29, 2012 at 9:12 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > Is it possible to redefine Pharo's shortcuts? > > How about by changing the code? > > Haha, yes, that's possible :). The problem relies on chasing the spot where the shortcuts are defined.

April 29, 2012

Re: [Pharo-project] Redefine shortcuts

by Chris Muller

> Â Is it possible to redefine Pharo's shortcuts? How about by changing the code?

April 29, 2012