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

Ben Coman btc at openInWorld.com
Mon Jun 18 08:54:02 EDT 2012


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.

phil at highoctane.be wrote:
> BTW what did Mozilla FWD told you?
> https://webfwd.org/
>
> 2012/6/17 Stéphane Ducasse <stephane.ducasse at 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 at 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 at 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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of phil at highoctane.be [phil at highoctane.be]
>>>> Sent: Sunday, June 17, 2012 6:44 AM
>>>> To: Pharo-project at 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 at 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 at 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 at highoctane.be | Web: http://philippeback.eu | Blog:
>>> http://philippeback.be
>>>
>>> High Octane SPRL
>>> rue cour Boisacq 101
>>> 1301 Bierges
>>> Belgium
>>>
>>>       
>>     
>
>
>
>   





More information about the Pharo-dev mailing list