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

Re: [Pharo-project] New version of Little Number Chapter

by John Toohey

Nice chapter. Working some of the examples, and with the latest 1.3 release, bitString is not available. Is this part of 1.4? On Sun, Sep 11, 2011 at 02:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I took into account the remarks of mariano and I imagine that the chapter improved. It can be obvious for some people > but I like to make sure that we all find this obvious. Because it is not difficult once you spend a little time on it. > Now if somebody wants to extend and improve, he/she welcome. > > I will continue to work on the others chapters. > > > > > > Stef > A guy that truly believe that software is only done when the documentation is packed too. > > > -- ~JT

Sept. 11, 2011

Re: [Pharo-project] Zinc HTTPS

by Sven Van Caekenberghe

On 11 Sep 2011, at 15:42, Norbert Hartl wrote: > What is Zodiac based on again? I assume you didn't write to native stuff yourself. The idea is to use a new, more comprehensible SocketStream implementation and the use that to subclass a new SecureSocketStream that delegates the 4 key ssl methods (connect, accept, encode & decode) to an ssl session object. There could be 2 implementations of that session object: one based on the existing SSL plugin (a wrapper to the OpenSSL library) and one based on all the crypto work being done in Smalltalk. Sven

Sept. 11, 2011

Re: [Pharo-project] Zinc HTTPS

by Norbert Hartl

Am 19.08.2011 um 20:45 schrieb Sven Van Caekenberghe: > Hi Camillo, > > On 19 Aug 2011, at 20:02, Camillo Bruni wrote: > >> I'm working on the various GitProtocols, amongst them is the normal HTTP version which in popular cases (like github) requires the SSL version. >> >> So is there somewhere an SSL version for Zinc? (even partially working ;) >> >> cheers cami > > > There is the 'Zodiac Alpha Release', http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050539.html > This is only for Mac though. > I haven't really worked on this since then. > What is Zodiac based on again? I assume you didn't write to native stuff yourself. Norbert

Sept. 11, 2011

[Pharo-project] [update 1.4] #14130

by Marcus Denker

14130 ----- Issue 4700: hasTraitComposition http://code.google.com/p/pharo/issues/detail?id=4700 Issue 709: Debugger highlight bug http://code.google.com/p/pharo/issues/detail?id=709 -- Marcus Denker -- http://marcusdenker.de

Sept. 11, 2011

Re: [Pharo-project] 1.3 OneCick with Cog VM

by Sean P. DeNigris

Igor Stasenko wrote: > > hehe.. well. lost code & time is definitely not exciting adventure :) > :) I actually had just started porting my projects from Pharo 1.2 to 1.3 and I didn't really have any data in the frozen image. But, I realized that if an important (possibly not-backed-up?) image ever froze on me, I'd be totally helpless. It felt like an important psychological and intellectual exercise to know that I could go down the VM rabbit hole when needed and rescue myself no matter how badly I messed something up in the image. So, I drew a line in the sand and decided I would do whatever it took to figure it out. Having come out the other side, nothing seems impossible (although I got really clear why I made the 15 year journey from C that has landed me on Smalltalk - compile cycles suck, for one thing). I would recommend everyone dive into the VM. I feel much more at ease now, and look forward to possibly contributing to the VM (beyond just filing a lot of bug reports, lol). Sean p.s. It's awesome to have a cadre of VM experts at our fingertips. I got near-immediate support from Mariano, Elliot, and Igor; which made all the difference. -- View this message in context: http://forum.world.st/1-3-OneCick-with-Cog-VM-tp3798884p3805097.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 11, 2011

[Pharo-project] [update 1.3] #13305

by Marcus Denker

13305 ----- Issue 4699: Selected list item color in Vistary, W2K, Watery and Watery 2 http://code.google.com/p/pharo/issues/detail?id=4699a -- Marcus Denker -- http://marcusdenker.de

Sept. 11, 2011

[Pharo-project] [update 1.4] #14129

by Marcus Denker

14129 ----- Issue 3750: The desktop logo should be changeable from the SettingBrowser http://code.google.com/p/pharo/issues/detail?id=3750 Issue 4699: Selected list item color in Vistary, W2K, Watery and Watery 2 http://code.google.com/p/pharo/issues/detail?id=4699 -- Marcus Denker -- http://marcusdenker.de

Sept. 11, 2011

[Pharo-project] New version of Little Number Chapter

by StÃ©phane Ducasse

Hi guys I took into account the remarks of mariano and I imagine that the chapter improved. It can be obvious for some people but I like to make sure that we all find this obvious. Because it is not difficult once you spend a little time on it. Now if somebody wants to extend and improve, he/she welcome. I will continue to work on the others chapters. Stef A guy that truly believe that software is only done when the documentation is packed too.

Sept. 11, 2011

Re: [Pharo-project] 1.3 OneCick with Cog VM

by StÃ©phane Ducasse

What we want is to be able to remotely access kernels and isolate them. But this quite difficult and a solution probably requires having extra bits. Stef On Sep 11, 2011, at 2:49 AM, Schwab,Wilhelm K wrote: > Stef, > > It's lonely at the top :) Best wishes with your new opportunities. > > As a linux user, one thing I cringe about is opening a second image and creating a COMPLETE mess of my image. The IDE really needs to detect the problem and refuse to open before badness happens. Otherwise, I make backups (not as often as I should) and good use of recovering lost changes. > > As for the general problem of building images, I see it much as lack of tools. We need something (Migrate being my evolving solution) that looks at what is installed and can get it into the next image. Metacello is a welcome way to install complicated stuff from others, by *my* code is presumably always something that I want to save and load w/o hassles. > > FWIW, I have a love-hate relationship with R, and that community is facing a similar problem, and their presumed solution appears to be something that will analyze and build. I realize R's language is awful (raises doubt), but the system as a whole is quite impressive (restores faith). > > 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: Saturday, September 10, 2011 4:37 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.3 OneCick with Cog VM > > On Sep 10, 2011, at 9:00 PM, John Toohey wrote: > >> I saw the screencast where Mariano did something like that. I had just >> built the image, when the original VM crash happened, so it wasn't >> that much of a deal to rebuild it. >> >> I would like to see some form of safe-mode boot for Pharo, so that >> just the kernel would be loaded. ST images are all about state, and >> when production servers go down, it would be nice to be able to start >> them up, and rewind the app. For normal apps this is not an issue, but >> when forking processes for socket IO or a FFI call, it is possible to >> bring it down (or in my case where I think my error handling code >> caused an error) , and moving in a backup image is not always enough. > > I would like to be able to rebuild the kernel at startup. > Now I should work on it but I got new responsibilities and they take my time. > > Stef >> >> I would like to get involved in such a project, if there was interest for it. >> >> On Fri, Sep 9, 2011 at 18:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> John Toohey wrote: >>>> >>>> So do I have to rebuild a new image from scratch now? Is there any >>>> command line switch that I can use to by pass the loading of my app on >>>> start up? >>>> >>> >>> I don't know if it'd be worth it, but if you're talking about a lot of work >>> lost, it sounds like you could build a debug VM and bypass the loading code >>> from the debugger (like I just had to do). >>> >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/1-3-OneCick-with-Cog-VM-tp3798884p3802970.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >> >> >> >> -- >> ~JT >> > > >

Sept. 11, 2011

Re: [Pharo-project] 1.3 OneCick with Cog VM

by Schwab,Wilhelm K

Stef, It's lonely at the top :) Best wishes with your new opportunities. As a linux user, one thing I cringe about is opening a second image and creating a COMPLETE mess of my image. The IDE really needs to detect the problem and refuse to open before badness happens. Otherwise, I make backups (not as often as I should) and good use of recovering lost changes. As for the general problem of building images, I see it much as lack of tools. We need something (Migrate being my evolving solution) that looks at what is installed and can get it into the next image. Metacello is a welcome way to install complicated stuff from others, by *my* code is presumably always something that I want to save and load w/o hassles. FWIW, I have a love-hate relationship with R, and that community is facing a similar problem, and their presumed solution appears to be something that will analyze and build. I realize R's language is awful (raises doubt), but the system as a whole is quite impressive (restores faith). 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: Saturday, September 10, 2011 4:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.3 OneCick with Cog VM On Sep 10, 2011, at 9:00 PM, John Toohey wrote: > I saw the screencast where Mariano did something like that. I had just > built the image, when the original VM crash happened, so it wasn't > that much of a deal to rebuild it. > > I would like to see some form of safe-mode boot for Pharo, so that > just the kernel would be loaded. ST images are all about state, and > when production servers go down, it would be nice to be able to start > them up, and rewind the app. For normal apps this is not an issue, but > when forking processes for socket IO or a FFI call, it is possible to > bring it down (or in my case where I think my error handling code > caused an error) , and moving in a backup image is not always enough. I would like to be able to rebuild the kernel at startup. Now I should work on it but I got new responsibilities and they take my time. Stef > > I would like to get involved in such a project, if there was interest for it. > > On Fri, Sep 9, 2011 at 18:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> John Toohey wrote: >>> >>> So do I have to rebuild a new image from scratch now? Is there any >>> command line switch that I can use to by pass the loading of my app on >>> start up? >>> >> >> I don't know if it'd be worth it, but if you're talking about a lot of work >> lost, it sounds like you could build a debug VM and bypass the loading code >> from the debugger (like I just had to do). >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/1-3-OneCick-with-Cog-VM-tp3798884p3802970.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > > -- > ~JT >

Sept. 11, 2011