start thinking on summer release of Pharo 1.4
Locked
1234
1234
Re: start thinking on summer release of Pharo 1.4
 
|
The girl was attractive and that's why I talked to her.
Light was faster than sound in her case, so I left. But, I wouldn't have spoken to her in the first place should she have been an ugly betty. That's just the way things go and why marketing focuses so much on packaging, even if it is an ugly mess inside (Microwave food anyone?) 2012/6/17 Igor Stasenko <[hidden email]>: > i for Pharo 1.4.1 > no messy naming please. > > Let's care more about what we put under the hood, than on glossy cover. > > -- > Best regards, > Igor Stasenko. > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
|
|
In reply to this post by philippeback
yes, Configurations Browser needs a little love too :P
On Jun 17, 2012, at 12:44 PM, [hidden email] wrote: > 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 <[hidden email]>: >> >> 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: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > <PharoScreenshot.1.png> |
|
|
In reply to this post by EstebanLM
This aligns somewhat with my own view. I see a lot of positive feedback about Nautilus from those that are experienced and confident to deal with any remaining rough edges - but if a few do remain, then newcomers are left wondering "what have I done wrong" since they don't know any better.On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: A few other considerations from my perspective... - The existing PBE uses snapshots of OB, so there is less work to update to 1.4 with OB than with Nautilus. - I haven't used Nautilus much yet (though I plan to) and would not be confident to write about it at this time. - Each chapter should be self contained. An instruction how to load OB in Chapter 1 being required for a later chapter is not ideal. Now I am not in a position to dictate, but to draw a line in the sand for me to proceed, unless vetoed I shall use OB for the 1.4 update to Pharo By Example. For the inclusion of examples like BouncingAtomsMorph I am planning to have a ConfigurationOfPBE produce a PBE.image from a vanilla Pharo1.4.image, which could include OB if required. So it is not essential for PBE to have OB as the default browser for 1.4.1, but would still be nice for newcomers to match the documentation. cheers -ben |
Re: start thinking on summer release of Pharo 1.4
|
Administrator
|
In reply to this post by philippeback
That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool under heavy development. Also, about that release date... Sean
Cheers,
Sean |
|
|
In reply to this post by EstebanLM
Esteban Lorenzano wrote:
> I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. > So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros. > > 1.4 Alexandria > 1.4 Finistère > 1.4 Usuhaia :) > > as I said... I just don't care which code name, but I don't want numbers. > > (btw... I'm kinda happy that this is the biggest divergence in my proposal :P) > Well I was very happy to hear your proposal. You are in the drivers seat so I'll live with whatever outcome - but just a bit more counter-point... Sometimes boring makes the world go round. If you release an emergency fix to '1.4 Alexandria' - what do you call it? Are you going to be tagging in the Issue Tracker the fixes included with maintenance release - what would you use? Looking further into how Ubuntu handle this [1] (since they are most obvious using funky release naming.) Turns out their official release actually remains numeric point-form, but because they include the month of release in the minor point-number they need the codename "during development". Perhaps including the numeric month somewhat addresses your concern of expectations of continuing minor revisions. However since there has been no codename and the release month is unknown to me, I have been thinking about the maintenance release as 1.4.1. I'd be very happy to have a codename to refer to this up until release (and probably for some time afterwards) - but I'd still really like a point form backing, to refer to in a few years time. [1] https://wiki.ubuntu.com/DevelopmentCodeNames cheers -ben > On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > > >> Sean P. DeNigris wrote: >> >>> EstebanLM wrote >>> >>> >>>> I started thinking on next release of Pharo 1.4 (which will be code named >>>> "summer", not an ugly number). >>>> >>>> Re browsers... I would definitely include either OB or Nautilus. The default >>>> is just too limiting. Nautilus does seem to be in a pretty usable state now, >>>> and it'd be helpful for new users not to have to learn two browsers in two >>>> releases... >>>> >>>> >>>> >>>> >> -1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: >> a) only "Summer" >> b) "Pharo Summer" >> c) "Pharo 1.4 Summer" >> >> For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. >> For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' >> > (c) was my idea, but if place-codenames are taken, we can use a different names each times. > > >> Also for consideration with using a code name rather than a version number, the two I know off... >> Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. >> Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers. >> >> >> Esteban, >> >> 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. >> > > no, because you can load Nautilus on top of OB, but not the opposite. > > >> cheers -ben >> >> >> >> > > > > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Sean P. DeNigris
Moved to Nautilus for a week, I am now back to OB. At least I can
navigate through everything without weird things popping up in my face everyone in a while (well, even with OB there are quite a bunch.). Just an example with OB (screenshot): Finder > pragma > click click on the tree branch --> bam! error message. Look at the stracktrace, the only thing I want is to close that. Phil 2012/6/17 Sean P. DeNigris <[hidden email]>: > > philippeback wrote >> >> OB if we want traction with embarking new people into Pharo. >> ... > > That makes sense. The only downside is that we will train people on one > browser and almost immediately switch to a new one. I remember questions > about how to "get the browser from PBE" (it was O2 I think). Although, I > guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool > under heavy development. > > Also, about that release date... > > Sean > > -- > View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp4634589p4635196.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
PharoScreenshot.3.png (116K)
Re: start thinking on summer release of Pharo 1.4
|
|
On 17 June 2012 16:36, [hidden email] <[hidden email]> wrote:
> Moved to Nautilus for a week, I am now back to OB. At least I can > navigate through everything without weird things popping up in my face > everyone in a while (well, even with OB there are quite a bunch.). > > Just an example with OB (screenshot): Finder > pragma > click click on > the tree branch --> bam! error message. Look at the stracktrace, the > only thing I want is to close that. > I bet this can take 2 minutes to fix. But since we don't have an OB maintainer, these 2 minutes can be easily stretched to 6 months. I leaving to you, to think how to change that :) > Phil -- Best regards, Igor Stasenko. |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by philippeback
On Sun, Jun 17, 2012 at 4:36 PM, [hidden email] <[hidden email]> wrote: Moved to Nautilus for a week, I am now back to OB. At least I can Good luck trying to make OB work in Pharo 2.0! Just an example with OB (screenshot): Finder > pragma > click click on -- Mariano http://marianopeck.wordpress.com |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Igor Stasenko
+1
________________________________________ From: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]] Sent: Sunday, June 17, 2012 6:48 AM To: [hidden email] Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 i for Pharo 1.4.1 no messy naming please. Let's care more about what we put under the hood, than on glossy cover. -- Best regards, Igor Stasenko. |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by philippeback
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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] Sent: Sunday, June 17, 2012 6:44 AM To: [hidden email] 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 <[hidden email]>: > > 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
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 <[hidden email]>: > 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] > Sent: Sunday, June 17, 2012 6:44 AM > To: [hidden email] > 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 <[hidden email]>: >> >> 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: > [hidden email] | 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
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, [hidden email] 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 <[hidden email]>: >> 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] >> Sent: Sunday, June 17, 2012 6:44 AM >> To: [hidden email] >> 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 <[hidden email]>: >>> >>> 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: >> [hidden email] | 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: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > |
Re: start thinking on summer release of Pharo 1.4
|
|
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 <[hidden email]>: > 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, [hidden email] 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 <[hidden email]>: >>> 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] >>> Sent: Sunday, June 17, 2012 6:44 AM >>> To: [hidden email] >>> 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 <[hidden email]>: >>>> >>>> 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: >>> [hidden email] | 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: >> [hidden email] | 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Stéphane Ducasse
BTW what did Mozilla FWD told you?
https://webfwd.org/ 2012/6/17 Stéphane Ducasse <[hidden email]>: > 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, [hidden email] 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 <[hidden email]>: >>> 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] >>> Sent: Sunday, June 17, 2012 6:44 AM >>> To: [hidden email] >>> 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 <[hidden email]>: >>>> >>>> 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: >>> [hidden email] | 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: >> [hidden email] | 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by Stéphane Ducasse
Who wants to hit the button?
https://webfwd.org/apply/ 2012/6/17 Stéphane Ducasse <[hidden email]>: > 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, [hidden email] 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 <[hidden email]>: >>> 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] >>> Sent: Sunday, June 17, 2012 6:44 AM >>> To: [hidden email] >>> 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 <[hidden email]>: >>>> >>>> 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: >>> [hidden email] | 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: >> [hidden email] | 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: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
> Who wants to hit the button? > > https://webfwd.org/apply/ > I read it when you told me but I was confused because pharo is not only about web. I will reread it. Stef |
Re: start thinking on summer release of Pharo 1.4
|
|
Well, it is web-ish enough to warrant some ca$h heh?
Seaside, tODE, Pier, Zn, Monticello, SS3, all that is web. Pharo and the web, distributed coding at its best. Pharo is the core upon which all the rest is built for success and kick-ass delivery! Phil 2012/6/17 Stéphane Ducasse <[hidden email]>: > > >> Who wants to hit the button? >> >> https://webfwd.org/apply/ >> > > I read it when you told me but I was confused because pharo is not only about web. > I will reread it. > > Stef > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: [hidden email] | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium |
Re: start thinking on summer release of Pharo 1.4
|
|
I reread the web site and this is more for startups?
I passed the message to guys around. > Well, it is web-ish enough to warrant some ca$h heh? > > Seaside, tODE, Pier, Zn, Monticello, SS3, all that is web. > > Pharo and the web, distributed coding at its best. > > Pharo is the core upon which all the rest is built for success and > kick-ass delivery! > > Phil > > 2012/6/17 Stéphane Ducasse <[hidden email]>: >> >> >>> Who wants to hit the button? >>> >>> https://webfwd.org/apply/ >>> >> >> I read it when you told me but I was confused because pharo is not only about web. >> I will reread it. >> >> Stef >> >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > [hidden email] | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > |
Re: start thinking on summer release of Pharo 1.4
|
|
In reply to this post by philippeback
On 2012-06-17, at 21:42, [hidden email] 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 maybe you should try again under 2.0 to load configs. We got some massive speedups in Monticello by caching the right things :P. now 2.0 is alpha so be warned :) |
|
|
In reply to this post by philippeback
There is also (http://ycombinator.com) particularly if you can do any of
these... (http://ycombinator.com/ideas.html) The first link of the FAQ is very informative but quite long. Not that these startup funds would fund Pharo directly, but perhaps someone using Pharo as a competitive advantage. [hidden email] wrote: > BTW what did Mozilla FWD told you? > https://webfwd.org/ > > 2012/6/17 Stéphane Ducasse <[hidden email]>: > >> 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, [hidden email] 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 <[hidden email]>: >>> >>>> 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: [hidden email] [[hidden email]] on behalf of [hidden email] [[hidden email]] >>>> Sent: Sunday, June 17, 2012 6:44 AM >>>> To: [hidden email] >>>> 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 <[hidden email]>: >>>> >>>>> 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: >>>> [hidden email] | 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: >>> [hidden email] | Web: http://philippeback.eu | Blog: >>> http://philippeback.be >>> >>> High Octane SPRL >>> rue cour Boisacq 101 >>> 1301 Bierges >>> Belgium >>> >>> >> > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |