I don't think like I want to hack on the system to get normal time
response. I will use #render: when it will gets too slow, even if it
breaks the beauty of the code.
This is the kind of problem where newbie may think Pharo is slow.
Hilaire
Le 05/01/2016 18:59, Ben Coman a écrit :
> On Tue, Jan 5
On Tue, Jan 5, 2016 at 10:20 PM, Hilaire wrote:
> Le 05/01/2016 14:38, Sven Van Caekenberghe a écrit :
>> The problem can does also be restated: it is really necessary for a tool to
>> convert 1000s of items to strings, even if only 10s are shown at the same
>> time on a screen ?
>>
>> I believe
Le 05/01/2016 15:45, Henrik Johansen a écrit :
>>> I believe that fast table tries to do better here.
>> > But I need to show 1000s of them once, all in the same view, at the same
>> > time.
>> >
>> > Hilaire
> I think Sven was referring to opening an inspector, where you usually only
> see 10-20
> On 05 Jan 2016, at 3:20 , Hilaire wrote:
>
> Le 05/01/2016 14:38, Sven Van Caekenberghe a écrit :
>> The problem can does also be restated: it is really necessary for a tool to
>> convert 1000s of items to strings, even if only 10s are shown at the same
>> time on a screen ?
>>
>> I believe
Le 05/01/2016 14:38, Sven Van Caekenberghe a écrit :
> The problem can does also be restated: it is really necessary for a tool to
> convert 1000s of items to strings, even if only 10s are shown at the same
> time on a screen ?
>
> I believe that fast table tries to do better here.
But I need to
> On 05 Jan 2016, at 14:26, Hilaire wrote:
>
> Agree.
> Nevertheless, the performance impact I got on OOP way of doing things
> can't be wiped out: when you ask an object to give its text
> representation but use non latin1 character, you get an important
> penalty. In the long term, it looks li
Agree.
Nevertheless, the performance impact I got on OOP way of doing things
can't be wiped out: when you ask an object to give its text
representation but use non latin1 character, you get an important
penalty. In the long term, it looks like a problem for Pharo.
Hilaire
Le 05/01/2016 13:20, Sv
String with ByteString and WideString subclasses has been a standard feature of
Squeak/Pharo for a long time. The transparent automatic conversion between the
two is a feature, not a limitation.
In se, there is nothing wrong with it.
Yes, other representations of Strings are possible, but is is
Le 04/01/2016 11:05, Henrik Johansen a écrit :
> In the fallback code for WriteStream >> #nextPut:, at:put: is called, so
> yes, streaming a wide char causes the streams collection to be converted from
> Byte to WideString.
> Conversion is done using become, which currently triggers a full heap
> On 02 Jan 2016, at 10:58 , Hilaire wrote:
>
> Hello,
>
> With Pharo3, in an object of mine, I want its text representation to
> come with the EURO symbol:
>
> CGMoney>>printOn: aStream
> aStream << (amount asScaledDecimal: 2) greaseString
> << ' ' << '€'
>
>
> It appear
Hello,
With Pharo3, in an object of mine, I want its text representation to
come with the EURO symbol:
CGMoney>>printOn: aStream
aStream << (amount asScaledDecimal: 2) greaseString
<< ' ' << '€'
It appears to be very slow when I browse such collection of objects
(says 15
11 matches
Mail list logo
