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

Re: [Pharo-project] Show stopper network bug on Windows

by Schwab,Wilhelm K

Again, I *think* the problem is too much code removed, and failure to protect with #useOldNetwork. It blows up on IPv4; it happens both on Windows and Linux. If anyone has counter examples or can otherwise show me wrong, please set me straight. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Tuesday, July 21, 2009 11:29 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Show stopper network bug on Windows On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<adi(a)netstyle.ch> wrote: > If this bug also exists in Squeak (which I expect since it seems a VM > problem), I suggest to report it there too (and create a Mantis entry). No, it's only Pharo. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Persist a morph in a message.

by Gary Chambers

Yeah, then zip the text file... much more compact! Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, July 21, 2009 5:28 PM Subject: Re: [Pharo-project] Persist a morph in a message. > This is way better than having a methods carrying a multi-kilobyte > long bytearray, > but still not perfect. > > Why just don't 'serialize' the morph as a code which builds it? > > buildMyMorph > > | myMorph | > myMorph := MyMorph new. > myMorph layout: blablahblah.. > myMorph label: blabla... > ... > ^ myMorph > > 2009/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Yes something like that. >> Use a system that we can hack and modify (have a look at the VW >> windowspec) >> >> this way your builder to build morphic but also something else too. >> >> windowSpec >> "UIPainter new openOnClass: self andSelector: #windowSpec" >> >> <resource: #canvas> >> ^#(#{UI.FullSpec} >> #window: >> #(#{UI.WindowSpec} >> #properties: #(#{UI.PropertyListDictionary} #sizeType >> #specifiedSize #positionType #screenCenter #openType #advanced ) >> #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks >> #defaultString: 'About Visual Works' #catalogID: #labels) >> #min: #(#{Core.Point} 20 20 ) >> #max: #(#{Core.Point} 1024 768 ) >> #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) >> #component: >> #(#{UI.SpecCollection} >> #collection: #( >> #(#{UI.TabControlSpec} >> #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) >> #name: #tabs >> #model: #tabListHolder >> #labels: #() ) >> #(#{UI.ActionButtonSpec} >> #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) >> #name: #ok >> #model: #accept >> #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' >> #catalogID: #labels) >> #isDefault: true >> #defaultable: true ) ) ) ) >> >> Stef >> >> >> On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <epicfan(a)gmail.com> >>> wrote: >>> >>> Excuse me for my poor english. >>> >>> IÂ´m developing a GUI Builder for Pharo -> >>> http://www.youtube.com/watch?v=CHbc1t83fEI >>> >>> One of my problems is the way of persist a morph.Now i use the same >>> way for >>> create a Morph than message #saveOnFile but not saving in a >>> external file >>> else in array of bytes returned for a #spec message. >>> >>> I would know if morphic allow or exists another way of persistence >>> more >>> readable and fast. A complex morph serialized of that way is too >>> slow in >>> load. >>> >>> Perhaps you can use another serializer. Here a some: >>> http://www.seaside.st/documentation/persistence >>> >>> For example, http://www.seaside.st/documentation/persistence#230290016 >>> or http://www.seaside.st/documentation/persistence#40827471 >>> >>> Your project seems very interesting, tough. >>> >>> Best, >>> >>> Mariano >>> >>> >>> >>> >>> Regards. >>> -- >>> View this message in context: >>> http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Persist a morph in a message.

by Igor Stasenko

This is way better than having a methods carrying a multi-kilobyte long bytearray, but still not perfect. Why just don't 'serialize' the morph as a code which builds it? buildMyMorph | myMorph | myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla... ... ^ myMorph 2009/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yes something like that. > Use a system that we can hack and modify (have a look at the VW > windowspec) > > this way your builder to build morphic but also something else too. > > windowSpec > Â Â Â Â "UIPainter new openOnClass: self andSelector: #windowSpec" > > Â Â Â Â <resource: #canvas> > Â Â Â Â ^#(#{UI.FullSpec} > Â Â Â Â Â Â Â Â #window: > Â Â Â Â Â Â Â Â #(#{UI.WindowSpec} > Â Â Â Â Â Â Â Â Â Â Â Â #properties: #(#{UI.PropertyListDictionary} #sizeType > #specifiedSize #positionType #screenCenter #openType #advanced ) > Â Â Â Â Â Â Â Â Â Â Â Â #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks > #defaultString: 'About Visual Works' #catalogID: #labels) > Â Â Â Â Â Â Â Â Â Â Â Â #min: #(#{Core.Point} 20 20 ) > Â Â Â Â Â Â Â Â Â Â Â Â #max: #(#{Core.Point} 1024 768 ) > Â Â Â Â Â Â Â Â Â Â Â Â #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) > Â Â Â Â Â Â Â Â #component: > Â Â Â Â Â Â Â Â #(#{UI.SpecCollection} > Â Â Â Â Â Â Â Â Â Â Â Â #collection: #( > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #(#{UI.TabControlSpec} > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #name: #tabs > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #model: #tabListHolder > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #labels: #() ) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #(#{UI.ActionButtonSpec} > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #name: #ok > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #model: #accept > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' > #catalogID: #labels) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #isDefault: true > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #defaultable: true ) ) ) ) > > Stef > > > On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: > >> >> >> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <epicfan(a)gmail.com> >> wrote: >> >> Excuse me for my poor english. >> >> IÂ´m developing a GUI Builder for Pharo -> >> http://www.youtube.com/watch?v=CHbc1t83fEI >> >> One of my problems is the way of persist a morph.Now i use the same >> way for >> create a Morph than message #saveOnFile Â but not saving in a >> external file >> else in array of bytes returned for a #spec message. >> >> I would know if morphic allow or exists another way of persistence >> more >> readable and fast. A complex morph serialized of that way is too >> slow in >> load. >> >> Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence >> >> For example, http://www.seaside.st/documentation/persistence#230290016 >> or http://www.seaside.st/documentation/persistence#40827471 >> >> Your project seems very interesting, tough. >> >> Best, >> >> Mariano >> >> >> >> >> Regards. >> -- >> View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 21, 2009

Re: [Pharo-project] Show stopper network bug on Windows

by Damien Cassou

On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<adi(a)netstyle.ch> wrote: > If this bug also exists in Squeak (which I expect since it seems a VM > problem), I suggest to report it there too (and create a Mantis entry). No, it's only Pharo. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 21, 2009

Re: [Pharo-project] Why Pharo?

by Mariano Martinez Peck

On Tue, Jul 21, 2009 at 2:59 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Hello, > > Mariano's post spurred me to write my reasons of "why to use it", so I > started this post. > yes, I asked because I saw that perhaps a "Why pharo?" section in www.pharo-project.org could be a good idea :) > > >>After many hesitations (I was reluctant to use Squeak) I decided to > >>use Pharo for it and not Dolphin (my favorite Smalltalk), because of > >>several reasons. > >would be nice to know them hehe > >sorry...in another thread. > > - It's mainly about getting mainstream, and not willing to develop > everything from scratch once and again. > > - At work we've developed everything by our own on VSE/Dolphin, so > every time we wanted to do something, we had to build it by ourselves > (most of it). We even had a Magritte like framework (years before > Magritte existed), persistence, reporting, etc. Now some of them, are > very mature frameworks. But I can't borrow any of them for personal > use ;-) and don't want to spend a year rewriting the frameworks I've > created, contributed to or used at work. > > - Because what I want to build is going to be web based (and I hope to > get it mobile to), anything that runs on linux is good to be > considered as a server solution. > > - So I wanted a rich class library/frameworks, in order to be able to > focus on the business logic I want to build. > > - I wanted to have the latest versions of such frameworks, even when > it's getting easier to port them (I did port Swazoo and Seaside in the > past), I'm not in the mood to do it now (yes, I'm getting lazy). > > - Because Dolphin future is uncertain yet, DNG seems to be the > next-generation VM/Smalltalk, but I can't wait until it's ready, the > conditions clear ($$$) and have the above mentioned points included. > > - Because I like where Pharo is going to, or seems to be going. I like > its mission and how its being managed (releases, issues, > patches,tests). It's a solid foundation for any reliable project. > > - Because nothing really new has come from other really good > smalltalks like VAST/Dolphin/VW, everything is getting ported, and > eventually a contribution gets back to the source. I see GLASS as an > "extension" of Pharo/Squeak, because it was made very compatible, and > the edges in contact work very close to each other (GLASS is useless > if outdated in relation with Pharo/Squeak). > > - Because after all, Pharo is also Smalltalk. And I rather choose it > before going to other also good stuff (like Rails), or not so good as > PHP/Java/DotNet) > > - I want to focus on the business I'm trying to solve, and forget > about everything mentioned above. > > The only thing that keeps me remembering the stuff above, is I'm still > not comfortable as I am with Dolphin, not just because of habit. > Dolphin's IDE is really neat, quick, consistent, gets the stuff done > and then gets out of your way. > You have to use it and do some real work to understand what I'm talking > about. > But I'm pretty confident Pharo will achieve such level of maturity in > the not so far future. > > I hope it clears my reasoning behind choosing Pharo. > > > Best regards, > > > -- > Esteban > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 21, 2009

Re: [Pharo-project] Why Pharo?

by Schwab,Wilhelm K

+100000000000000 to Esteban's comments on the Dolphin IDE - it's slick in ways that are not visually obvious. Some of it comes from speed, some from use of the good from GUI conventions, and the rest from good IDE design. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban A. Maringolo Sent: Tuesday, July 21, 2009 10:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Why Pharo? Hello, Mariano's post spurred me to write my reasons of "why to use it", so I started this post. >>After many hesitations (I was reluctant to use Squeak) I decided to >>use Pharo for it and not Dolphin (my favorite Smalltalk), because of >>several reasons. >would be nice to know them hehe >sorry...in another thread. - It's mainly about getting mainstream, and not willing to develop everything from scratch once and again. - At work we've developed everything by our own on VSE/Dolphin, so every time we wanted to do something, we had to build it by ourselves (most of it). We even had a Magritte like framework (years before Magritte existed), persistence, reporting, etc. Now some of them, are very mature frameworks. But I can't borrow any of them for personal use ;-) and don't want to spend a year rewriting the frameworks I've created, contributed to or used at work. - Because what I want to build is going to be web based (and I hope to get it mobile to), anything that runs on linux is good to be considered as a server solution. - So I wanted a rich class library/frameworks, in order to be able to focus on the business logic I want to build. - I wanted to have the latest versions of such frameworks, even when it's getting easier to port them (I did port Swazoo and Seaside in the past), I'm not in the mood to do it now (yes, I'm getting lazy). - Because Dolphin future is uncertain yet, DNG seems to be the next-generation VM/Smalltalk, but I can't wait until it's ready, the conditions clear ($$$) and have the above mentioned points included. - Because I like where Pharo is going to, or seems to be going. I like its mission and how its being managed (releases, issues, patches,tests). It's a solid foundation for any reliable project. - Because nothing really new has come from other really good smalltalks like VAST/Dolphin/VW, everything is getting ported, and eventually a contribution gets back to the source. I see GLASS as an "extension" of Pharo/Squeak, because it was made very compatible, and the edges in contact work very close to each other (GLASS is useless if outdated in relation with Pharo/Squeak). - Because after all, Pharo is also Smalltalk. And I rather choose it before going to other also good stuff (like Rails), or not so good as PHP/Java/DotNet) - I want to focus on the business I'm trying to solve, and forget about everything mentioned above. The only thing that keeps me remembering the stuff above, is I'm still not comfortable as I am with Dolphin, not just because of habit. Dolphin's IDE is really neat, quick, consistent, gets the stuff done and then gets out of your way. You have to use it and do some real work to understand what I'm talking about. But I'm pretty confident Pharo will achieve such level of maturity in the not so far future. I hope it clears my reasoning behind choosing Pharo. Best regards, -- Esteban _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Scamper

by Schwab,Wilhelm K

+1. The security considerations, range of expected behavior, etc., make it the only viable option IMHO. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Tuesday, July 21, 2009 10:54 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper Nope, scamper is way out of date. I think the answer is to do a webkit plugin if we want web content in pharo. On Jul 21, 2009, at 8:13 AM, Brian Mason wrote: I've been trying to use scamper with no success. I've loaded the latest version from Monticello. Is there a later version? Is anyone supporting this? _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Why Pharo?

by Alexandre Bergel

> - Because I like where Pharo is going to, or seems to be going. I like > its mission and how its being managed (releases, issues, > patches,tests). It's a solid foundation for any reliable project. Thanks Esteban Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 21, 2009

[Pharo-project] Why Pharo?

by Esteban A. Maringolo

Hello, Mariano's post spurred me to write my reasons of "why to use it", so I started this post. >>After many hesitations (I was reluctant to use Squeak) I decided to >>use Pharo for it and not Dolphin (my favorite Smalltalk), because of >>several reasons. >would be nice to know them hehe >sorry...in another thread. - It's mainly about getting mainstream, and not willing to develop everything from scratch once and again. - At work we've developed everything by our own on VSE/Dolphin, so every time we wanted to do something, we had to build it by ourselves (most of it). We even had a Magritte like framework (years before Magritte existed), persistence, reporting, etc. Now some of them, are very mature frameworks. But I can't borrow any of them for personal use ;-) and don't want to spend a year rewriting the frameworks I've created, contributed to or used at work. - Because what I want to build is going to be web based (and I hope to get it mobile to), anything that runs on linux is good to be considered as a server solution. - So I wanted a rich class library/frameworks, in order to be able to focus on the business logic I want to build. - I wanted to have the latest versions of such frameworks, even when it's getting easier to port them (I did port Swazoo and Seaside in the past), I'm not in the mood to do it now (yes, I'm getting lazy). - Because Dolphin future is uncertain yet, DNG seems to be the next-generation VM/Smalltalk, but I can't wait until it's ready, the conditions clear ($$$) and have the above mentioned points included. - Because I like where Pharo is going to, or seems to be going. I like its mission and how its being managed (releases, issues, patches,tests). It's a solid foundation for any reliable project. - Because nothing really new has come from other really good smalltalks like VAST/Dolphin/VW, everything is getting ported, and eventually a contribution gets back to the source. I see GLASS as an "extension" of Pharo/Squeak, because it was made very compatible, and the edges in contact work very close to each other (GLASS is useless if outdated in relation with Pharo/Squeak). - Because after all, Pharo is also Smalltalk. And I rather choose it before going to other also good stuff (like Rails), or not so good as PHP/Java/DotNet) - I want to focus on the business I'm trying to solve, and forget about everything mentioned above. The only thing that keeps me remembering the stuff above, is I'm still not comfortable as I am with Dolphin, not just because of habit. Dolphin's IDE is really neat, quick, consistent, gets the stuff done and then gets out of your way. You have to use it and do some real work to understand what I'm talking about. But I'm pretty confident Pharo will achieve such level of maturity in the not so far future. I hope it clears my reasoning behind choosing Pharo. Best regards, -- Esteban

July 21, 2009

Re: [Pharo-project] Scamper

by Eagle Offshore

Nope, scamper is way out of date. I think the answer is to do a webkit plugin if we want web content in pharo. On Jul 21, 2009, at 8:13 AM, Brian Mason wrote: > Iâve been trying to use scamper with no success. Iâve loaded the > latest version from Monticello. > > Is there a later version? Is anyone supporting this? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009