- Pharo-dev - lists.pharo.org

[Pharo-project] new Cog linux VM available

by Eliot Miranda

Hi All, a new Cog linux VM is available at http://www.mirandabanda.org/files/Cog/VM/VM.r2437/ which fixes a lack of correct stack alignment in Alien callouts. -- best, Eliot

June 20, 2011

Re: [Pharo-project] ZnServer - Swazoo - Comanche

by GermÃ¡n Arduino

Thanks Sven, very clear explanation. GermÃ¡n. 2011/6/19 Sven Van Caekenberghe <sven(a)beta9.be>: > Hello GermÃ¡n, > > On 19 Jun 2011, at 16:14, GermÃ¡n Arduino wrote: > >> Hi Sven, People: >> >> I want to ask about ZnServer, is focused in have at some point all the >> features of Swazoo or Comanche and being itself a complete web server? >> >> Or the goal is only to be a default implementation, as the comment says? >> >> Thanks. >> GermÃ¡n. > > From my point of view, the goal of Zn is to be a framework implementing the HTTP protocol and a library on top of that offering client and server functionality based mainly on RFC 2616. > > The server part is kept relatively simple: the server does multithreading, connection handling, request parsing and response writing and then asks its delegate to do the work, using #handleRequest: which is given a ZnRequest as argument and is expected to return a ZnResponse. > > The code doing the #handleRequest can be simple, like in the examples that are included, but could become arbitrarily complex, like Apache. > > Anyone is free to build on top of Zn whatever they think makes sense, most of this will probably be more application specific and hence out of the scope of Zn. > > The Seaside adaptor is a good example: it is an add-on. Seaside expects very little from its servers and Zn is offering slightly more than needed. Still, the Seaside experience is quite rich to say the least. > > I don't consider Swazoo or Comanche competition, they offer more features but also specific API's. > > Another goal of Zn is understandability: I would like the Zn code to be readable by anyone interested in HTTP. > > Sven > > >

June 20, 2011

Re: [Pharo-project] Draft chapter on Settings Framework for PBE2 now online

by HernÃ¡n Morales Durand

Hi Oscar, I would like to build my own application settings in a separated Settings browser, can I use <myAppSettings> like the <systemsettings> pragma? any example code how to do it? Cheers, 2011/2/8 Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com>: > > Hi Folks, > > There is now a draft chapter on the Settings Framework for "Pharo by Example 2" available for review: > > https://gforge.inria.fr/frs/download.php/28243/Settings.pdf > > http://pharobyexample.org/ > > Cheers, > - on > > >

June 20, 2011

Re: [Pharo-project] Why has system browser icon dissapeared in 1.3?

by StÃ©phane Ducasse

No idea why it disappeared. Stef On Jun 19, 2011, at 11:42 PM, Mariano Martinez Peck wrote: > I miss it too :( > > On Sun, Jun 19, 2011 at 3:45 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Actually, without the icon, the menu item is smaller and I feel it's harder to hit, jeje. Maybe just a feeling. > > Is there a particular reason to remove it? > > Also, It's not consistant because ALL the other have icon. It's discrimination :P. > > Guille > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 19, 2011

Re: [Pharo-project] Why has system browser icon dissapeared in 1.3?

by Mariano Martinez Peck

I miss it too :( On Sun, Jun 19, 2011 at 3:45 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Actually, without the icon, the menu item is smaller and I feel it's harder > to hit, jeje. Maybe just a feeling. > > Is there a particular reason to remove it? > > Also, It's not consistant because ALL the other have icon. It's > discrimination :P. > > Guille > -- Mariano http://marianopeck.wordpress.com

June 19, 2011

Re: [Pharo-project] About not using full Pharo

by Mariano Martinez Peck

Hi Damien. That peolpe are NOT using PharoDev is something really good from my point of view because: 1) it means that we have a set of external packages that can be loaded and work in a PharoCore 2) it is easy to manage them (otherwise they wouldn't do it) I think there are important "new" reasons why people can *now* build they own images: a) Metacello existance b) There are configurations for almost all needed projects/packages c) Jenkis d) New and easy Settings browser With all of the them is it TRIVIAL to automatically build your own PharoDev image, where you put what you want, you set the settings to want, etc. But for all the rest of the people, you have PharoDev :) Cheers On Sun, Jun 19, 2011 at 10:38 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > Hi, > > I've read that some of you are installing their own set of packages on > top of Pharo-Core and not using Pharo. Why is that so? What don't you > like in Pharo? Why didn't you tell us before? > > If we don't have this information, you might not like the new > Pharo-Core and you will have nothing anymore to base your images on. > Speak now or forever hold your peace :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > -- Mariano http://marianopeck.wordpress.com

June 19, 2011

[Pharo-project] About not using full Pharo

by Damien Cassou

Hi, I've read that some of you are installing their own set of packages on top of Pharo-Core and not using Pharo. Why is that so? What don't you like in Pharo? Why didn't you tell us before? If we don't have this information, you might not like the new Pharo-Core and you will have nothing anymore to base your images on. Speak now or forever hold your peace :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 19, 2011

Re: [Pharo-project] ZnServer - Swazoo - Comanche

by Sven Van Caekenberghe

Hello GermÃ¡n, On 19 Jun 2011, at 16:14, GermÃ¡n Arduino wrote: > Hi Sven, People: > > I want to ask about ZnServer, is focused in have at some point all the > features of Swazoo or Comanche and being itself a complete web server? > > Or the goal is only to be a default implementation, as the comment says? > > Thanks. > GermÃ¡n. >From my point of view, the goal of Zn is to be a framework implementing the HTTP protocol and a library on top of that offering client and server functionality based mainly on RFC 2616. The server part is kept relatively simple: the server does multithreading, connection handling, request parsing and response writing and then asks its delegate to do the work, using #handleRequest: which is given a ZnRequest as argument and is expected to return a ZnResponse. The code doing the #handleRequest can be simple, like in the examples that are included, but could become arbitrarily complex, like Apache. Anyone is free to build on top of Zn whatever they think makes sense, most of this will probably be more application specific and hence out of the scope of Zn. The Seaside adaptor is a good example: it is an add-on. Seaside expects very little from its servers and Zn is offering slightly more than needed. Still, the Seaside experience is quite rich to say the least. I don't consider Swazoo or Comanche competition, they offer more features but also specific API's. Another goal of Zn is understandability: I would like the Zn code to be readable by anyone interested in HTTP. Sven

June 19, 2011

Re: [Pharo-project] Compiling a method taking wrong source

by Guillermo Polito

Yeap, my fault! I was using a #12340 image while the ones in hudson are #12353 :) At least I learnt some things :P. Sorry for the spam, Guille On Sun, Jun 19, 2011 at 4:21 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Mmm, maybe I'm using an old image. Let me check, > > thanks! > > > On Sun, Jun 19, 2011 at 4:17 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> This is a bug introduced by the TextEditor changes. I thought it was >> fixed in the latest Pharo 1.2.1? >> >> Lukas >> >> On 19 June 2011 20:37, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > Well, replacing: >> > >> > self logMethodSource: text forMethodWithNode: methodAndNode >> > inCategory: category withStamp: changeStamp notifying: >> > requestor. >> > >> > by >> > >> > self logMethodSource: methodAndNode node printString forMethodWithNode: >> > methodAndNode >> > inCategory: category withStamp: changeStamp notifying: >> > requestor. >> > >> > Works well :). But for sure I smell I'm doing something veeery wrong :S >> > >> > Has it something to do with using a mutable text instead of a string? >> > >> > On Sun, Jun 19, 2011 at 3:32 PM, Guillermo Polito >> > <guillermopolito(a)gmail.com> wrote: >> >> >> >> Hi, I have a simple snippet of code which says: >> >> >> >> someObject class compile: aMethod classified: someCategory notifying: >> >> aRequestor. >> >> >> >> where aRequestor is a PluggableTextMorph. >> >> >> >> Actually, when I try to compile a method with a temp var, letting the >> >> compiler notify me when a temp var is needed, I always see the final >> >> CompiledMethod with the wrong source. For example, compiling >> >> >> >> someMethod >> >> ^someTemp >> >> >> >> Is correctly updated to be >> >> >> >> someMethod >> >> | someTemp | >> >> ^someTemp >> >> >> >> But, after the compilation process, when I get the compiled method >> source, >> >> It just have >> >> >> >> someMethod >> >> ^someTemp >> >> >> >> >> >> Debugging, I ended up in >> >> >> >> ClassDescriptioncompile: text classified: category withStamp: >> changeStamp >> >> notifying: requestor logSource: logSource >> >> | methodAndNode | >> >> methodAndNode := self compile: text asString classified: category >> >> notifying: requestor >> >> trailer: self defaultMethodTrailer ifFail: >> >> [^nil]. >> >> logSource ifTrue: [ >> >> self logMethodSource: text forMethodWithNode: methodAndNode >> >> inCategory: category withStamp: changeStamp notifying: >> >> requestor. >> >> ]. >> >> self addAndClassifySelector: methodAndNode selector withMethod: >> >> methodAndNode >> >> method inProtocol: category notifying: requestor. >> >> self instanceSide noteCompilationOf: methodAndNode selector meta: >> self >> >> isClassSide. >> >> ^ methodAndNode selector >> >> >> >> Which is saving as the CompiledMethod source, the original text, not >> the >> >> one which was changed in the PluggableTextMorph and compiled in the >> >> methodAndNode object. >> >> >> >> >> >> Well, I was looking how the Browser works, and I didn't realize the >> >> difference... Can someone enlight me? >> >> >> >> Thanks, >> >> Guille >> > >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> >

June 19, 2011

Re: [Pharo-project] Compiling a method taking wrong source

by Guillermo Polito

Mmm, maybe I'm using an old image. Let me check, thanks! On Sun, Jun 19, 2011 at 4:17 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > This is a bug introduced by the TextEditor changes. I thought it was > fixed in the latest Pharo 1.2.1? > > Lukas > > On 19 June 2011 20:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Well, replacing: > > > > self logMethodSource: text forMethodWithNode: methodAndNode > > inCategory: category withStamp: changeStamp notifying: > > requestor. > > > > by > > > > self logMethodSource: methodAndNode node printString forMethodWithNode: > > methodAndNode > > inCategory: category withStamp: changeStamp notifying: > > requestor. > > > > Works well :). But for sure I smell I'm doing something veeery wrong :S > > > > Has it something to do with using a mutable text instead of a string? > > > > On Sun, Jun 19, 2011 at 3:32 PM, Guillermo Polito > > <guillermopolito(a)gmail.com> wrote: > >> > >> Hi, I have a simple snippet of code which says: > >> > >> someObject class compile: aMethod classified: someCategory notifying: > >> aRequestor. > >> > >> where aRequestor is a PluggableTextMorph. > >> > >> Actually, when I try to compile a method with a temp var, letting the > >> compiler notify me when a temp var is needed, I always see the final > >> CompiledMethod with the wrong source. For example, compiling > >> > >> someMethod > >> ^someTemp > >> > >> Is correctly updated to be > >> > >> someMethod > >> | someTemp | > >> ^someTemp > >> > >> But, after the compilation process, when I get the compiled method > source, > >> It just have > >> > >> someMethod > >> ^someTemp > >> > >> > >> Debugging, I ended up in > >> > >> ClassDescriptioncompile: text classified: category withStamp: > changeStamp > >> notifying: requestor logSource: logSource > >> | methodAndNode | > >> methodAndNode := self compile: text asString classified: category > >> notifying: requestor > >> trailer: self defaultMethodTrailer ifFail: > >> [^nil]. > >> logSource ifTrue: [ > >> self logMethodSource: text forMethodWithNode: methodAndNode > >> inCategory: category withStamp: changeStamp notifying: > >> requestor. > >> ]. > >> self addAndClassifySelector: methodAndNode selector withMethod: > >> methodAndNode > >> method inProtocol: category notifying: requestor. > >> self instanceSide noteCompilationOf: methodAndNode selector meta: > self > >> isClassSide. > >> ^ methodAndNode selector > >> > >> Which is saving as the CompiledMethod source, the original text, not the > >> one which was changed in the PluggableTextMorph and compiled in the > >> methodAndNode object. > >> > >> > >> Well, I was looking how the Browser works, and I didn't realize the > >> difference... Can someone enlight me? > >> > >> Thanks, > >> Guille > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

June 19, 2011