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.
Marcus
> 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<[email protected]> 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
>>>> [email protected]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
