July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Customized Cog Win32 for Pharo 1.3 (based on Cog r2474)

by Igor Stasenko

On 28 July 2011 17:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 28, 2011, at 4:38 PM, Torsten Bergmann wrote: > >>> I personally am completely confused about VMs. Now we have even one more :-) >> >> No - we do not have one more, just an updated rebranded version >> as I did in the past to make it more Pharo like. >> >> On Win32 it goes like this: >> =========================== >> >> A) Andreas provided the official Squeak VM on http://squeakvm.org/win32/ >> Â Â Last official one is 4.1.1, I just gave it a new pharo icon ("lighthouse"), name >> Â Â and file ressource so one can see the VM version directly in Explorer. >> >> Â Â => unfortunately this is very outdated from 2010, no activity/response on >> Â Â Â Â Andreas side and no new Win32 Squeak VM maintainer stepped up AFAIK >> >> Â Â Even when outdated we still use this as the standard VM in the Win32 >> Â Â Installer (see Pharo1.2), I will reuse this standard VM for 1.3 too. >> >> B) Eliot provides the fast Cog VM on http://www.mirandabanda.org/files/Cog/VM/ >> Â Â Last SVN revision is VM.r2474, again anything I do is building the >> Â Â VM from subversion with another icon ("lighthouse with gear"), name and >> Â Â a file ressource so one can see the VM version directly in Explorer. >> >> Â Â This Cog VM is also in the Win32 Pharo 1.2/upcoming 1.3 installer >> Â Â so Win users can profit from Eliots work. >> >> After using the Win32-Installer one can (by using the different icon "lighthouse" or "lighthouse with gear") start the appropriate engine to run his image. >> >> I hope that we can get a better situation as soon as >> - the standard VM "A" is built right from the newest VMMaker >> - for "B" (the Cog VM) is either built from VMMaker or from Eliots SVN repo >> > > And there is > > C) > > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Win32/ > > Which is auto-build and soon even auto-tested... > yeah, as soon as we figure out how to gain stability of win32 slave, because right now something strange happens after week or two of working it stops responding and i need to contact INRIA admins and ask them to reboot/kick its ass over and over again :) > > Â Â Â Â Marcus > -- > Marcus Denker -- http://marcusdenker.de > -- Best regards, Igor Stasenko AKA sig.

July 28, 2011

Re: [Pharo-project] [ANN] Customized Cog Win32 for Pharo 1.3 (based on Cog r2474)

by Eliot Miranda

On Thu, Jul 28, 2011 at 7:46 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 28, 2011, at 4:38 PM, Torsten Bergmann wrote: > > >> I personally am completely confused about VMs. Now we have even one more > :-) > > > > No - we do not have one more, just an updated rebranded version > > as I did in the past to make it more Pharo like. > > > > On Win32 it goes like this: > > =========================== > > > > A) Andreas provided the official Squeak VM on http://squeakvm.org/win32/ > > Last official one is 4.1.1, I just gave it a new pharo icon > ("lighthouse"), name > > and file ressource so one can see the VM version directly in Explorer. > > > > => unfortunately this is very outdated from 2010, no > activity/response on > > Andreas side and no new Win32 Squeak VM maintainer stepped up > AFAIK > > > > Even when outdated we still use this as the standard VM in the Win32 > > Installer (see Pharo1.2), I will reuse this standard VM for 1.3 too. > > > > B) Eliot provides the fast Cog VM on > http://www.mirandabanda.org/files/Cog/VM/ > > Last SVN revision is VM.r2474, again anything I do is building the > > VM from subversion with another icon ("lighthouse with gear"), name > and > > a file ressource so one can see the VM version directly in Explorer. > > > > This Cog VM is also in the Win32 Pharo 1.2/upcoming 1.3 installer > > so Win users can profit from Eliots work. > > > > After using the Win32-Installer one can (by using the different icon > "lighthouse" or "lighthouse with gear") start the appropriate engine to run > his image. > > > > I hope that we can get a better situation as soon as > > - the standard VM "A" is built right from the newest VMMaker > > - for "B" (the Cog VM) is either built from VMMaker or from Eliots SVN > repo > > > > And there is > > C) > > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Win32/ > > Which is auto-build and soon even auto-tested... > and would be the VM I would expect Pharo to use. You're welcome to use the VMs off my site but Pharo wants the correct icons, and something that has been auto-built and autotested, etc > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

July 28, 2011

Re: [Pharo-project] Reference temporary variable of method ( or other solution )

by Igor Stasenko

On 28 July 2011 17:54, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 28, 2011, at 5:11 PM, Dario Trussardi wrote: >> >> and methodB: >> >> Â Â Â methodB >> >> Â Â Â Â Â Â Â | a b c | >> >> Â Â Â Â Â Â Â a := 'a'. >> >> Â Â Â Â Â Â Â ......... Â i can now at this step Â reference the Â Â Â Â Â Â Â Â Â var1 Â Â Â defined in methodA ? >> >> >> >> >> I think it's in the stack or i wrong ? >> > Yes, it is on the stack: > > Â Â Â Â thisContext sender tempNamed: 'var1'. > > but tempNamed: has to look at the sources... so faster is: > > Â Â Â Â thisContext sender tempAt: 1. > >> It's no elegant do it ? >> > > I would not do it... it's hard to understand, easy to break (adding a temp will break it, refactoring > breaks it easily, calling the method from somewhere else will lead to funny effects, and so on). > yes, but you can check who calling you, like: (thisContext sender method == (SomeClass>> #methodA )) ifTrue: [ ... ] but of course it doesn't makes this hack less evil. Less brittle , yes :) > And it's slow (on the jit it means that the context needs to be created) and far too much magic. > > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Best regards, Igor Stasenko AKA sig.

July 28, 2011

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Lukas Renggli

>> I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image. > > Yes, the WAServerManager should bring them up again. I suspect this is > an issue with Seaside or Pharo; as this is exactly the same problem > with Kom. Now I can fix the ZnZincServerAdaptor when I add the following methods: ZnZincServerAdaptor>>startUp self server isNil ifFalse: [ self server start ] ZnZincServerAdaptor>>shutDown self server isNil ifFalse: [ self server stop ] The strange thing though is that when the images comes up and I stop the server adaptor manually, the server continues to run :-S Lukas -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Lukas Renggli

> How exactly do you start the adaptor ? > > Â Â Â Â ZnZincServerAdaptor new port: 8080; start Yep. > I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image. Yes, the WAServerManager should bring them up again. I suspect this is an issue with Seaside or Pharo; as this is exactly the same problem with Kom. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011

Re: [Pharo-project] Reference temporary variable of method ( or other solution )

by Damien Cassou

Hi Dario, On Thu, Jul 28, 2011 at 5:11 PM, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Any other indications to solve this problematic ? looking for a temporary variable is probably possible but not elegant. It also means that only methodA can call methodB. There are multiple solutions: - add an instance variable (but you don't like it) - add a parameter to methodB (but you don't like it) - create a dedicated class with with just var1 as instance variable and methodA and methodB as methods. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 28, 2011

Re: [Pharo-project] Reference temporary variable of method ( or other solution )

by Marcus Denker

On Jul 28, 2011, at 5:11 PM, Dario Trussardi wrote: > > and methodB: > > methodB > > | a b c | > > a := 'a'. > > ......... i can now at this step reference the var1 defined in methodA ? > > > > > I think it's in the stack or i wrong ? > Yes, it is on the stack: thisContext sender tempNamed: 'var1'. but tempNamed: has to look at the sources... so faster is: thisContext sender tempAt: 1. > It's no elegant do it ? > I would not do it... it's hard to understand, easy to break (adding a temp will break it, refactoring breaks it easily, calling the method from somewhere else will lead to funny effects, and so on). And it's slow (on the jit it means that the context needs to be created) and far too much magic. Marcus -- Marcus Denker -- http://marcusdenker.de

July 28, 2011

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Sven Van Caekenberghe

Hi Lukas, On 28 Jul 2011, at 16:51, Lukas Renggli wrote: > We now have builds with Zinc, Kom and Swazoo. > > Zinc is the default for all subsequent builds (Seaside One-Click, > Magritte, Pier). Supercool, thanks a lot ! > Strangely none of the server adaptors works when the image comes up > (Kom and Zinc worked out of the box in Pharo 1.2). After stop and > restart Kom and Zinc work though. How exactly do you start the adaptor ? ZnZincServerAdaptor new port: 8080; start Only the default Zn server gets registered automatically for this, see ZnSingleThreadedServer class>>#defaultOn: (inherited by ZnMultiThreadedServer) other manually started servers have to register themselves using ZnServer>>#register I guess it would be a good idea for the Seaside adaptor to do this automagically ? I'll have a look when I download your freshly backed image. Sven

July 28, 2011

[Pharo-project] Reference temporary variable of method ( or other solution )

by Dario Trussardi

Hi, i work with Pharo and GLASS. My question is relative to reference method variable define in the method. If i have methodA: methodA | var1 | var1 := 'this is an string'. self methodB. and methodB: methodB | a b c | a := 'a'. ......... i can now at this step reference the var1 defined in methodA ? I think it's in the stack or i wrong ? It's no elegant do it ? a need call self methodB: var1 The question is because i have some class for manage database and i will don't add istances variable to manage the operations on it. With this reference i can solve the problem without pass variables from some methods to other methods. If i found in the stack the specific reference i can manage some operations based on it. Any other indications to solve this problematic ? Thanks, Dario

July 28, 2011

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Lukas Renggli

We now have builds with Zinc, Kom and Swazoo. Zinc is the default for all subsequent builds (Seaside One-Click, Magritte, Pier). Strangely none of the server adaptors works when the image comes up (Kom and Zinc worked out of the box in Pharo 1.2). After stop and restart Kom and Zinc work though. Swazoo seems to be broken. Lukas On 28 July 2011 13:20, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 28 Jul 2011, at 12:54, Lukas Renggli wrote: > >> What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images. > > OK, please let me know ASAP if run into any issues. > > Sven > -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011