June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

Stef, Just a matter of time before the money flows in. I am pretty convinced of that. No kidding. Phil 2012/6/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Phil > > just for the record, if we would get 4 engineers working full time during 2 more years > you would not recognize Pharo. > Now we are making progress but we are nearly all working on our free time. > So this is not that we do not have the vision, just not enough money :). > > Stef > > > On Jun 17, 2012, at 9:42 PM, phil(a)highoctane.be wrote: > >> Don't get me wrong. I love all of what I do see in there. I've done a >> ton of Maven2 stuff (including setting up a quite large maven proxy), >> so I perfectly understand the ton of hard work that goes along with >> configs. Much important, much needed, much significant work. >> >> Just that I am running a business and want to make Pharo a cornerstone >> of my technical tools. >> >> This means that I'll have to explain it to a lot of people partnering >> with me. I need traction to pull them in. >> >> There is incredible potential in Pharo. Just that for the newcomer, >> the paradigm switch to an image-based beast is big enough to smoothen >> the curve. And we can do it. >> >> Phil >> >> >> >> 2012/6/17 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. >>> >>> Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. >>> >>> The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress. >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of phil(a)highoctane.be [phil(a)highoctane.be] >>> Sent: Sunday, June 17, 2012 6:44 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 >>> >>> Who is his/her right mind would be able to make sense of this without >>> a lot of preexposure? And who the hell are those people? >>> >>> And figuring out they need to right click, followed by a load >>> configuration *and* stable version? Followed by a loooong wait. And if >>> there is no internet, well, it would freeze for a significant while. >>> >>> That's the feedback I get from people I try to get into the flow. Lots >>> of blank stares... along the lines of "What the heck are you doing?" >>> >>> Phil >>> >>> >>> 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>> On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: >>>> >>>>> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >>>>> I need to know this to continue updating Pharo By Example for 1.4. >>>> >>>> this is an interesting and important issue (much more than codenames, he). >>>> I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): >>>> >>>> Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. >>>> Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. >>>> To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). >>>> >>>> So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. >>>> Frankly, Â I don't know what to do now :) >>>> >>>> Esteban >>> >>> >>> >>> -- >>> Philippe Back >>> Dramatic Performance Improvements >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >>> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >>> http://philippeback.be >>> >>> High Octane SPRL >>> rue cour Boisacq 101 >>> 1301 Bierges >>> Belgium >>> >> >> >> >> -- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> Belgium >> > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] Jenkins down?

by StÃ©phane Ducasse

yes probably a problem with Java having too many handle open. This is strange since last week christophe removed the aida job that was causing us trouble. Stef On Jun 17, 2012, at 9:49 PM, phil(a)highoctane.be wrote: > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

Phil just for the record, if we would get 4 engineers working full time during 2 more years you would not recognize Pharo. Now we are making progress but we are nearly all working on our free time. So this is not that we do not have the vision, just not enough money :). Stef On Jun 17, 2012, at 9:42 PM, phil(a)highoctane.be wrote: > Don't get me wrong. I love all of what I do see in there. I've done a > ton of Maven2 stuff (including setting up a quite large maven proxy), > so I perfectly understand the ton of hard work that goes along with > configs. Much important, much needed, much significant work. > > Just that I am running a business and want to make Pharo a cornerstone > of my technical tools. > > This means that I'll have to explain it to a lot of people partnering > with me. I need traction to pull them in. > > There is incredible potential in Pharo. Just that for the newcomer, > the paradigm switch to an image-based beast is big enough to smoothen > the curve. And we can do it. > > Phil > > > > 2012/6/17 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. >> >> Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. >> >> The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress. >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of phil(a)highoctane.be [phil(a)highoctane.be] >> Sent: Sunday, June 17, 2012 6:44 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 >> >> Who is his/her right mind would be able to make sense of this without >> a lot of preexposure? And who the hell are those people? >> >> And figuring out they need to right click, followed by a load >> configuration *and* stable version? Followed by a loooong wait. And if >> there is no internet, well, it would freeze for a significant while. >> >> That's the feedback I get from people I try to get into the flow. Lots >> of blank stares... along the lines of "What the heck are you doing?" >> >> Phil >> >> >> 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: >>> >>>> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >>>> I need to know this to continue updating Pharo By Example for 1.4. >>> >>> this is an interesting and important issue (much more than codenames, he). >>> I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): >>> >>> Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. >>> Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. >>> To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). >>> >>> So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. >>> Frankly, I don't know what to do now :) >>> >>> Esteban >> >> >> >> -- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> Belgium >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 17, 2012

Re: [Pharo-project] Help review ! Re: [Pharo-bugtracker] Issue 6077 in pharo: Let DataStream only for Monticello Part2

by StÃ©phane Ducasse

ok I will have a look. Stef On Jun 17, 2012, at 8:26 PM, Mariano Martinez Peck wrote: > btw, one way to test it is by just using Monticello after integrating the fix. > > On Sun, Jun 17, 2012 at 3:37 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I touched a couple of packages so it will get obsolete soon if we don't integrate it. > Anywone to review? > > On Sun, Jun 17, 2012 at 3:36 PM, <pharo(a)googlecode.com> wrote: > Updates: > Status: FixReviewNeeded > > Comment #1 on issue 6077 by marianopeck: Let DataStream only for Monticello Part2 > http://code.google.com/p/pharo/issues/detail?id=6077 > > So slice in inbox. > IMPORTANT: after integrating, you have to evaluate: > > ScriptLoader new deletePackage: 'System-Object Storage' > > > > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 17, 2012

Re: [Pharo-project] Jenkins down?

by Schwab,Wilhelm K

Looks that way from here (Florida). ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of phil(a)highoctane.be [phil(a)highoctane.be] Sent: Sunday, June 17, 2012 3:49 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Jenkins down? -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

[Pharo-project] Jenkins down?

by phil＠highoctane.be

-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

Don't get me wrong. I love all of what I do see in there. I've done a ton of Maven2 stuff (including setting up a quite large maven proxy), so I perfectly understand the ton of hard work that goes along with configs. Much important, much needed, much significant work. Just that I am running a business and want to make Pharo a cornerstone of my technical tools. This means that I'll have to explain it to a lot of people partnering with me. I need traction to pull them in. There is incredible potential in Pharo. Just that for the newcomer, the paradigm switch to an image-based beast is big enough to smoothen the curve. And we can do it. Phil 2012/6/17 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. > > Long delays and hangs are BAD, but that can be addressed using background threads. Â This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. > > The list of configs appearing in the browser is encouraging. Â I'd hope to see ODBC listed too, but Glorp is there. Â If all of these configs offer and can load a #stable version, that would be huge progress. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of phil(a)highoctane.be [phil(a)highoctane.be] > Sent: Sunday, June 17, 2012 6:44 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 > > Who is his/her right mind would be able to make sense of this without > a lot of preexposure? And who the hell are those people? > > And figuring out they need to right click, followed by a load > configuration *and* stable version? Followed by a loooong wait. And if > there is no internet, well, it would freeze for a significant while. > > That's the feedback I get from people I try to get into the flow. Lots > of blank stares... along the lines of "What the heck are you doing?" > > Phil > > > 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: >> >>> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >>> I need to know this to continue updating Pharo By Example for 1.4. >> >> this is an interesting and important issue (much more than codenames, he). >> I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): >> >> Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. >> Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. >> To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). >> >> So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. >> Frankly, Â I don't know what to do now :) >> >> Esteban > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Schwab,Wilhelm K

I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of phil(a)highoctane.be [phil(a)highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people? And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while. That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?" Phil 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > >> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >> I need to know this to continue updating Pharo By Example for 1.4. > > this is an interesting and important issue (much more than codenames, he). > I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): > > Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. > Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. > To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). > > So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. > Frankly, I don't know what to do now :) > > Esteban -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] Help review ! Re: [Pharo-bugtracker] Issue 6077 in pharo: Let DataStream only for Monticello Part2

by Mariano Martinez Peck

btw, one way to test it is by just using Monticello after integrating the fix. On Sun, Jun 17, 2012 at 3:37 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. I touched a couple of packages so it will get obsolete soon if we > don't integrate it. > Anywone to review? > > On Sun, Jun 17, 2012 at 3:36 PM, <pharo(a)googlecode.com> wrote: > >> Updates: >> Status: FixReviewNeeded >> >> Comment #1 on issue 6077 by marianopeck: Let DataStream only for >> Monticello Part2 >> http://code.google.com/p/**pharo/issues/detail?id=6077<http://code.google.com/p/pharo/issues/detail?id=6077> >> >> So slice in inbox. >> IMPORTANT: after integrating, you have to evaluate: >> >> ScriptLoader new deletePackage: 'System-Object Storage' >> >> >> >> ______________________________**_________________ >> Pharo-bugtracker mailing list >> Pharo-bugtracker(a)lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/** >> pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 17, 2012

[Pharo-project] FileSystem and file extensions

by Guillermo Polito

Hi! I've seen that FS takes as a file extension everything after the first dot, instead of the last one. Now, that conflicts with the naming we are using for our files: - changesets and fileouts often take the form something.cs, something.1.cs, something.2.cs - image names: pharo-2.0.image, pharo-2.0.1.image One of them has to be changed I think... :) Also, I'm more used to the other definition of extension: All after the last dot :S Guille

June 17, 2012