[ANN] Pharo 1.0 Beta

> ok with me.
>
> Stef
>
> On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
>
>    
>> On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
>>
>>      
>>> On 01.08.2009, at 07:06, Serge Stinckwich wrote:
>>>
>>>        
>>>> On Sat, Aug 1, 2009 at 2:41 AM, Stéphane
>>>> Ducasse<[hidden email]>  wrote:
>>>>          
>>>>> So what is the process now?
>>>>> Do we focus on 1.0?
>>>>> Can we integrate other issues?
>>>>> Do we have a separate stream for 1.1 alpha?
>>>>>            
>>>> Maybe the 1.1 alpha should be available after the release of Pharo
>>>> 1.0
>>>> so the efforts of the team is not disseminate on two versions.
>>>>          
>>> Yes, I think this is the way to go... we should force everyone to use
>>> the
>>> beta version for a while.
>>>        
>> Yes. We have 50 open issues for 1.0 and when more people start using
>> Pharo, they will find more bugs. So for now we should focus on
>> bringing that number down to 0.
>>
>> Adrian
>>
>>      
>>> Marcus
>>>
>>>
>>>
>>>
>>> --
>>> Marcus Denker - http://marcusdenker.de
>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>        
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>      
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>    

> Does this also include primitive (or plugib) failures  which are  
> handled
> correctly, but cause performance problems?
>
> In particular, I'm thinking of primitive 103 in core (used in  
> strikefont
> rendering), and plugin BitBlt using rule 41 (used in FTFont-
> rendering),
> whom (wild guess) both seem to have problem with the String ->
> ByteString/WideString refactoring... (IE: they fail in Pharo with a
> ByteString parameter instead of String, and use the strictly smalltalk
> fallback code resulting in... far worse performance)
>
> I tried installing VMMaker to investigate the problems further, but I
> guess the steps needed to set up an interpreter to properly test  
> exactly
> what goes wrong in these cases were too advanced for me to figure  
> out in
> 30 mins.. :(
>
> BTW, the Cuis subpixel-rendering looks beautiful (both performance and
> code-wise) compared to what is done in the FreeType code. Anyone have
> time to understand/integrate this approach before 1.0 release?
>
> Misc ideas:
> - How about inserting some sort of logging where primitives are called
> with failure, but Smalltalk code fallback is used for a seemingly
> successful result. then fixing the code/VM to handle those cases? Font
> rendering is the prime cultrip, but I'm sure there are other places as
> well....
>
> Secondary: - How about another instance cache in Color, for  
> transformed
> colours?
> Some of these transformed colours are used MANY times during each
> rendering step, (look at the senders of Color>>lighter f.ex.), it  
> seems
> silly to create new Color object that have to be GC'd in many of these
> instances. In Pharo the overhead isn't very noticeable (due to the
> primitive failures mentioned above sucking up most of the processor
> time), but in a lean system like Cuis, they did appear on  
> TimeProfiles...
>
> I'm not sure how much you can trust the leaf nodes of TimeProfiles
> though, at least in Cuis/(which I did most of my investigation in),  
> they
> seemed to be spread at random between items in a block.... (IE: from  
> one
> to another, it could shift from 90% in one method call to 90% in  
> another
> method call in the same block).
>
> If you read this entire message, you have my condolances, and written
> permission to ask for clarifications :)
>
> Cheers,
> Henry
>
> , On 04.08.2009 16:44, Stéphane Ducasse wrote:
>> ok with me.
>>
>> Stef
>>
>> On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
>>
>>
>>> On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
>>>
>>>
>>>> On 01.08.2009, at 07:06, Serge Stinckwich wrote:
>>>>
>>>>
>>>>> On Sat, Aug 1, 2009 at 2:41 AM, Stéphane
>>>>> Ducasse<[hidden email]>  wrote:
>>>>>
>>>>>> So what is the process now?
>>>>>> Do we focus on 1.0?
>>>>>> Can we integrate other issues?
>>>>>> Do we have a separate stream for 1.1 alpha?
>>>>>>
>>>>> Maybe the 1.1 alpha should be available after the release of Pharo
>>>>> 1.0
>>>>> so the efforts of the team is not disseminate on two versions.
>>>>>
>>>> Yes, I think this is the way to go... we should force everyone to  
>>>> use
>>>> the
>>>> beta version for a while.
>>>>
>>> Yes. We have 50 open issues for 1.0 and when more people start using
>>> Pharo, they will find more bugs. So for now we should focus on
>>> bringing that number down to 0.
>>>
>>> Adrian
>>>
>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Denker - http://marcusdenker.de
>>>> PLEIAD Lab - Computer Science Department (DCC) - University of  
>>>> Chile
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On 04.08.2009, at 18:49, Henrik Sperre Johansen wrote:
>
>> Hmm, so bugs are ok?
>>
>
> Why? Nobody said that we will not mark more issues as to be fixed  
> for 1.0...
> what was said is that we will not have a second stream and start to  
> add fixes
> that are decided to not be included in 1.0 there. Nothing else.
>
> If you want other reports to be tagges 1.0, add a note in the  
> bugreport.
> If you find new bugs, add a new report and tell the world that you  
> think
> that it needs to be fixed for 1.0.

> Hmm, so bugs are ok?
>
> Does this also include primitive (or plugib) failures  which are  
> handled
> correctly, but cause performance problems?
>
> In particular, I'm thinking of primitive 103 in core (used in  
> strikefont
> rendering), and plugin BitBlt using rule 41 (used in FTFont-
> rendering),
> whom (wild guess) both seem to have problem with the String ->
> ByteString/WideString refactoring... (IE: they fail in Pharo with a
> ByteString parameter instead of String, and use the strictly smalltalk
> fallback code resulting in... far worse performance)
>
> I tried installing VMMaker to investigate the problems further, but I
> guess the steps needed to set up an interpreter to properly test  
> exactly
> what goes wrong in these cases were too advanced for me to figure  
> out in
> 30 mins.. :(
>
> BTW, the Cuis subpixel-rendering looks beautiful (both performance and
> code-wise) compared to what is done in the FreeType code. Anyone have
> time to understand/integrate this approach before 1.0 release?
>
> Misc ideas:
> - How about inserting some sort of logging where primitives are called
> with failure, but Smalltalk code fallback is used for a seemingly
> successful result. then fixing the code/VM to handle those cases? Font
> rendering is the prime cultrip, but I'm sure there are other places as
> well....
>
> Secondary: - How about another instance cache in Color, for  
> transformed
> colours?
> Some of these transformed colours are used MANY times during each
> rendering step, (look at the senders of Color>>lighter f.ex.), it  
> seems
> silly to create new Color object that have to be GC'd in many of these
> instances. In Pharo the overhead isn't very noticeable (due to the
> primitive failures mentioned above sucking up most of the processor
> time), but in a lean system like Cuis, they did appear on  
> TimeProfiles...
>
> I'm not sure how much you can trust the leaf nodes of TimeProfiles
> though, at least in Cuis/(which I did most of my investigation in),  
> they
> seemed to be spread at random between items in a block.... (IE: from  
> one
> to another, it could shift from 90% in one method call to 90% in  
> another
> method call in the same block).
>
> If you read this entire message, you have my condolances, and written
> permission to ask for clarifications :)
>
> Cheers,
> Henry
>
> , On 04.08.2009 16:44, Stéphane Ducasse wrote:
>> ok with me.
>>
>> Stef
>>
>> On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote:
>>
>>
>>> On Aug 1, 2009, at 18:33 , Marcus Denker wrote:
>>>
>>>
>>>> On 01.08.2009, at 07:06, Serge Stinckwich wrote:
>>>>
>>>>
>>>>> On Sat, Aug 1, 2009 at 2:41 AM, Stéphane
>>>>> Ducasse<[hidden email]>  wrote:
>>>>>
>>>>>> So what is the process now?
>>>>>> Do we focus on 1.0?
>>>>>> Can we integrate other issues?
>>>>>> Do we have a separate stream for 1.1 alpha?
>>>>>>
>>>>> Maybe the 1.1 alpha should be available after the release of Pharo
>>>>> 1.0
>>>>> so the efforts of the team is not disseminate on two versions.
>>>>>
>>>> Yes, I think this is the way to go... we should force everyone to  
>>>> use
>>>> the
>>>> beta version for a while.
>>>>
>>> Yes. We have 50 open issues for 1.0 and when more people start using
>>> Pharo, they will find more bugs. So for now we should focus on
>>> bringing that number down to 0.
>>>
>>> Adrian
>>>
>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Marcus Denker - http://marcusdenker.de
>>>> PLEIAD Lab - Computer Science Department (DCC) - University of  
>>>> Chile
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Will do!
> Submitted Issue 1041 as a simple case where an (unneccessary)
> primitive failure happens.
> If a similar slowdown is experienced in f.ex. the fallback bitblt code
> used in font rendering, it might be worth investigating what exactly
> causes it to fail.
>
> Fallback code isn't always a good thing when everything still works as
> expected, but cause performance hits that add up over time, and are
> hard to track down :)
>
> Cheers,
> Henry
>
>
>
>
> On Aug 5, 2009, at 9:42 27AM, Stéphane Ducasse wrote:
>
>> Hi henrik
>>
>> what I suggest is: cut your messages into smaller ones so that we can
>> get multiple and clear
>> thread. Then enter bug items when needed.
>>
>> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project