Ah yes, you're right, why calling this primitive at all?
Note that I also changed stopConditions because 257-1 and 258-1 are valid
Character codes
(A macron see for example
http://tech.groups.yahoo.com/group/squeak/message/118800)
So the primitive just has one less chance to work.
Anyway, would the primitive do kerning?

Maybe the primitive can still be useful for a simplified image like Cuis
though (no internationalization). Did you take a look?
In which case we'd better not remove it from COG.


2013/7/22 tim Rowledge <tim at rowledge.org>

>
> On 21-07-2013, at 12:02 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
> > Clearly, character scanning inner loop is now written all in Smalltalk,
> and that seems efficient enough on our computers.
>
> Well, when is efficient enough, enough? The first problem is that for
> every send to basicScanCharacters… we are wasting time on calling the prim
> and failing it after pointless work. Second is that we have no measurement
> for whether things would be faster with the prim working or not. I could
> easily believe that on a Cog vm it would be about the same either way, but
> only after seeing decent tests results.
>
> > Is it a problem on Pi?
>
> Performance wise, almost everything to do with running under Morphic is a
> problem. Run in an MVC project on a Pi and see it fly!
>
> > IMHO, the thing to do would be to document the primitive as backward
> compatibility support only (interpreter VM)
> > In case of COG, since there is no such backward compatibility anyway,
> drop the primitives.
> > Or rewrite them to support i18n…
>
> I'd love to se some reasonable tests done to measure the effect of
> a) remove prim entirely
> b) fix prim (probably by actually faking up a test scanner class that
> doesn't break the prim rules)
> c)  machine differences -pc, mac, plain interp, cog, Pi, Pi stackvm
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Try not to let implementation details sneak into design documents.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130722/ebcd97c8/attachment.htm