Fwd: [squeak-dev] Updated trunk image

> From: Andreas Raab <[hidden email]>
> Date: November 29, 2009 4:33:59 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Updated trunk image
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Folks -
>
> After a nice batch of new stuff over the last two weeks, I've uploaded a fully updated trunk image to:
>
> http://ftp.squeak.org/trunk/Squeak3.10.2-Trunk-091128.zip
>
> Below the summary of this version.
>
> Cheers,
> - Andreas
>
> This is a list of the main achievements that went into the trunk image.
> The list is in reverse chronological order, newest additions on the top:
>
> [------------------------- updated 11/28/09 ---------------------------]
>
> Menu Bar
> --------
> Squeak now has a standard menu bar to make it easier to discover its contents for new users, replacing the World menu as the prime source for launching tools and other activities.
>
> Compiler
> --------
> Support for literal ByteArray syntax has been added. Byte arrays can now be written as #[1 2 3 "..."] instead of #(1 2 3) asByteArray  avoiding the need for conversion and a more compact default representation.
>
> Numbers
> -------
> Some prime related changed: Integer>>isPrime is now a deterministic test, Integer>>isProbablyPrime a probabilistic variant. Intger>>highBit and Integer>>lowBit have been sped up significantly.
>
> CRLF Handling
> -------------
> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF.
>
> Collections
> -----------
> Dictionary is no longer a subclass of Set. HashedCollection is the new superclass for both Set and Dictionary. Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>
> [------------------------- updated 11/14/09 ---------------------------]
>
> Kernel
> ------
> Support for isolation layers has been retired. "self-evaluation" as a concept has been removed since every object can be forced to be self-evaluating by asking for its storeString.
>
> Projects
> --------
> Project refactoring are an ongoing process. Project itself has been split into Project / MVCProject / MorphicProject such that Project itself is abstract and various requests are handled properly in the subclasses.
>
> Collections
> -----------
> Several improvements have been added to Collections. Sets have become faster, Arrays now print in brace form by default, Dictionary>>keys return an array instead of a set.
>
> Monticello
> ----------
> Various load-order issues have been fixed within Monticello, making loading of packages more robust. Monticello and PackageInfo have been sped up in several areas making browsing of large repositories significantly faster.
>
> Faster UTF-8 Conversions
> ------------------------
> Generalize trick from ByteString>>#squeakToUtf8 to every converter using class instance variables. Dramatically improves performance of file operations.
>
> FaceLift
> --------
> An adaptation of Newspeak's Facelift look has been added to Squeak under the code name of "Botox" (meaning a small set of carefully chosen injections to improve the out of the box look for Squeak).
>
> Shout
> -----
> Shout (Syntax Hightlighting As You Type) has been added to this image. As with all new additions, it can be easily unloaded for people wanting smaller images.
>
> ToolBuilder conversion
> ----------------------
> All the tools have been given a make-over, removing pretty much all of the interface construction code and replacing it by ToolBuilder specs. This removes a huge amount of dependencies between the tools and particular UI frameworks, and puts all the UIs on equal footing (there were several tools that were either not all or only partially supported in MVC before).
>
> New Text Editors
> ----------------
> A complete new set of text editors (Editor, TextEditor and SmalltalkEditor) are available. They replace TextMorphEditor and break one of the last hard links between Morphic and MVC. With the new editors it will finally become possible to have Morphic be self-contained without the need to rely on portions of MVC.
>
> Morphic Text Improvements
> -------------------------
> Morphic has now regular blinking insertion point cursors instead of the (virtually invisible) static cursor previously. In addition, various problems with mixing fonts and the heights of text have been fixed.
>
> Preference Pragmas
> ------------------
> Preference pragmas simplify dealing with preferences by providing automatic discovery for preferences defined in your classes. No more littering Preferences; you can now define preferences local to your class and store the values in regular class variables. The preference gets automatically discovered by using the <preference:category:description:type:> pragma.
>
> Beautiful, Anti-Aliased Fonts
> -----------------------------
> We have a new set of beautiful anti-aliased Deja Vu bitmap fonts in this image. The default sizes include 7pt (for handheld devices), 9pt (generic text, list and menu fonts) as well as 12pt (window and title fonts):
> Deja Vu 7pt: Regular, Bold, Italics
> Deja Vu 9pt: Regular, Bold, Italics
> Deja Vu 12pt: Regular, Bold, Italics
>
> Russian Language Support
> ------------------------
> To input text in Russian language, install a font supporting the Cyrillic alphabet, then switch the locale accordingly:
>
> TTFileDescription installFamilyNamed: 'Arial'.
> Locale switchToID: (LocaleID isoLanguage: 'ru').
>
> This will enable Russian text input, display and processing.
>
> Improved Truetype Support
> -------------------------
> The new TTFileDescription works just like TTFontDescription but operates on the files directly on disk. This helps greatly to support the m17n efforts since we no longer load all the fonts into memory. To use the available fonts on your platform, select some text, hit Cmd-k (Alt-k) and select "More (non-portable) fonts".
>
> Full Closure Support
> --------------------
> This is a closure converted image. With full closure support, you can finally use recursive blocks like here:
>
> fac := [:n| n > 1 ifTrue:[n * (fac value: n-1)] ifFalse:[1]].
> fac value: 5.
>
> and close over temps correctly, such as here:
>
> (1 to: 10) do:[:i| WorldState addDeferredUIMessage:[Transcript cr; show: i]].
>
> A new Development Model
> -----------------------
> This image is being developed using a new development model described at
>
> http://board.squeak.org/2009/07/02/a-new-community-development-model/
>
> The image itself started as Squeak3.10.2-7179-basic.image. It was then updated from http://source.squeak.org/trunk. In order to keep track of ongoing development, simply hit the 'Load Code Updates' button.
>

> Stef
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>>>> Menu Bar
>>>> --------
>>>> Squeak now has a standard menu bar to make it easier to discover its contents for new users, replacing the World menu as the prime source for launching tools and other activities.
>>>>
>>>> Compiler
>>>> --------
>>>> Support for literal ByteArray syntax has been added. Byte arrays can now be written as #[1 2 3 "..."] instead of #(1 2 3) asByteArray  avoiding the need for conversion and a more compact default representation.
>> we got that since long time ago
>>
>
> Yes, I picked the method from Pharo :)

>
>>
>>>>
>>>> CRLF Handling
>>>> -------------
>>>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF.
>>
>> I imagine that this were fixes of nicolas
>>
>
> Only the line splitting stuff is in Pharo (it was started in Pharo).
> I did not port the transparent displaying of line feeds to Pharo yet.
> Are you interested ?

>>>>> Menu Bar
>>>>> --------
>>>>> Squeak now has a standard menu bar to make it easier to discover its contents for new users, replacing the World menu as the prime source for launching tools and other activities.
>>>>>
>>>>> Compiler
>>>>> --------
>>>>> Support for literal ByteArray syntax has been added. Byte arrays can now be written as #[1 2 3 "..."] instead of #(1 2 3) asByteArray  avoiding the need for conversion and a more compact default representation.
>>> we got that since long time ago
>>>
>>
>> Yes, I picked the method from Pharo :)
>
> :) I really wonder what would be squeak if you would not push it ;-D
>
>>
>>>>> Numbers
>>>>> -------
>>>>> Some prime related changed: Integer>>isPrime is now a deterministic test, Integer>>isProbablyPrime a probabilistic variant.
>>> I think that andres changes were introduced. But apparently not.
>>> I will do that. Strange
>>>
>>
>> I think Leventes just picked Andres change...
>
> This is strange because I thought I integrated that. I will redo it.
>
>>
>>>>> Intger>>highBit and Integer>>lowBit have been sped up significantly.
>>> This is in
>>>
>>
>> Yes, though I cached 8bits in trunk instead of 4bits in Pharo and
>> initila mantis report.
>
> This is strange because I check the code and it looked similar.
> I will recheck later.
>
>>
>>>
>>>>>
>>>>> CRLF Handling
>>>>> -------------
>>>>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF.
>>>
>>> I imagine that this were fixes of nicolas
>>>
>>
>> Only the line splitting stuff is in Pharo (it was started in Pharo).
>> I did not port the transparent displaying of line feeds to Pharo yet.
>> Are you interested ?
>
> what is it?
>

>>
>>>>> Collections
>>>>> -----------
>>>>> Dictionary is no longer a subclass of Set. HashedCollection is the new superclass for both Set and Dictionary. Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>> This is cool......
>>> We definitively should look at that.
>>>
>>
>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>
> Yes and I like the fast in the sentence :)
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>
>>>>>> Collections
>>>>>> -----------
>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>
>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>
>> Yes and I like the fast in the sentence :)
> It's probably along the lines of what I did back in August for Pharo,
> using the array primitives directly, instead of copying the elements one
> by one.
>
> Cheers,
> Henry
>

>>>>>>
>>>>>> CRLF Handling
>>>>>> -------------
>>>>>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF.
>>>>
>>>> I imagine that this were fixes of nicolas
>>>>
>>>
>>> Only the line splitting stuff is in Pharo (it was started in Pharo).
>>> I did not port the transparent displaying of line feeds to Pharo yet.
>>> Are you interested ?
>>
>> what is it?
>>
>
> It is a change to render LF just like CR in DisplayScanner & co, with
> a hack for CR-LF pairs, instead of an ugly box [].
> RATIONALE: most times we don't care how the line ending is encoded, we
> just want it to be rendered correctly.
>
> Note that juan did modify more a less the same methods in Cuis but
> added a visible boxed [lf] glyph instead of transparent one.
> RATIONALE: In squeak, all line endings should have been converted to
> CR already, except in some cases when we care for LF.
> In such cases, we would like to control visually the presence:
> - of LF (a [lf] is displayed at end of line)
> - or of CR-LF (a [lf] is displayed at beginning of next line).
>
> These are two different approaches of the same problem: whatever our
> ingeniousity, we just can't eradicate LF...

>>>>>>>
>>>>>>> CRLF Handling
>>>>>>> -------------
>>>>>>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF.
>>>>>
>>>>> I imagine that this were fixes of nicolas
>>>>>
>>>>
>>>> Only the line splitting stuff is in Pharo (it was started in Pharo).
>>>> I did not port the transparent displaying of line feeds to Pharo yet.
>>>> Are you interested ?
>>>
>>> what is it?
>>>
>>
>> It is a change to render LF just like CR in DisplayScanner & co, with
>> a hack for CR-LF pairs, instead of an ugly box [].
>> RATIONALE: most times we don't care how the line ending is encoded, we
>> just want it to be rendered correctly.
>>
>> Note that juan did modify more a less the same methods in Cuis but
>> added a visible boxed [lf] glyph instead of transparent one.
>> RATIONALE: In squeak, all line endings should have been converted to
>> CR already, except in some cases when we care for LF.
>> In such cases, we would like to control visually the presence:
>> - of LF (a [lf] is displayed at end of line)
>> - or of CR-LF (a [lf] is displayed at beginning of next line).
>>
>> These are two different approaches of the same problem: whatever our
>> ingeniousity, we just can't eradicate LF...
>
> If we think that we could eradicate lf I think that it would be nice to see [lf]
> because if we paste the code from pharo to any other tools it would be good
> to see that we are not consistent. Then we could also know that this is the time
> to run an eradicating script once more on the complete source code.
>

> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>
>>>>>>> Collections
>>>>>>> -----------
>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>
>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>
>>> Yes and I like the fast in the sentence :)
>> It's probably along the lines of what I did back in August for Pharo,
>> using the array primitives directly, instead of copying the elements one
>> by one.
>>
>> Cheers,
>> Henry
>>
>
> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
> My implementation is a bit shorter and yours is faster:
>
> asArray
> "Overriden for speed"
> ^array copyFrom: firstIndex to: lastIndex
>
> Cheers
>
> Nicolas
>
>>
>> _______________________________________________
>> 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 Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote:
>
>> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>>
>>>>>>>> Collections
>>>>>>>> -----------
>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>>
>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>>
>>>> Yes and I like the fast in the sentence :)
>>> It's probably along the lines of what I did back in August for Pharo,
>>> using the array primitives directly, instead of copying the elements one
>>> by one.
>>>
>>> Cheers,
>>> Henry
>>>
>>
>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
>> My implementation is a bit shorter and yours is faster:
>>
>> asArray
>>       "Overriden for speed"
>>        ^array copyFrom: firstIndex to: lastIndex
>>
>> Cheers
>>
>> Nicolas
>>
>>>
>>> _______________________________________________
>>> 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
>

> 2009/11/30 Stéphane Ducasse <[hidden email]>:
>> ok so I imagine that this is already in pharo :)
>> Excellent.
>>
>> Stef
>>
>
> The only complication is that every DisplayScanner & co method was
> reformatted in Pharo.
> Chasing my own changes gets a bit tricky in these conditions...
> I would need a special merger option to ignore formats (just scan code
> and compare the sequence of tokens for example...).
>

> Nicolas
>
>> On Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote:
>>
>>> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>>>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>>>
>>>>>>>>> Collections
>>>>>>>>> -----------
>>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>>>
>>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>>>
>>>>> Yes and I like the fast in the sentence :)
>>>> It's probably along the lines of what I did back in August for Pharo,
>>>> using the array primitives directly, instead of copying the elements one
>>>> by one.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>
>>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
>>> My implementation is a bit shorter and yours is faster:
>>>
>>> asArray
>>>       "Overriden for speed"
>>>        ^array copyFrom: firstIndex to: lastIndex
>>>
>>> Cheers
>>>
>>> Nicolas
>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>

> 2009/11/30 Stéphane Ducasse <[hidden email]>:
>> ok so I imagine that this is already in pharo :)
>> Excellent.
>>
>> Stef
>>
>
> The only complication is that every DisplayScanner & co method was
> reformatted in Pharo.
> Chasing my own changes gets a bit tricky in these conditions...
> I would need a special merger option to ignore formats (just scan code
> and compare the sequence of tokens for example...).
>
> Nicolas
>
>> On Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote:
>>
>>> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>>>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>>>
>>>>>>>>> Collections
>>>>>>>>> -----------
>>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>>>
>>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>>>
>>>>> Yes and I like the fast in the sentence :)
>>>> It's probably along the lines of what I did back in August for Pharo,
>>>> using the array primitives directly, instead of copying the elements one
>>>> by one.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>
>>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
>>> My implementation is a bit shorter and yours is faster:
>>>
>>> asArray
>>>       "Overriden for speed"
>>>        ^array copyFrom: firstIndex to: lastIndex
>>>
>>> Cheers
>>>
>>> Nicolas
>>>
>>>>
>>>> _______________________________________________
>>>> 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

> Yes I know.
>
> Stef
>
> On Nov 30, 2009, at 9:26 PM, Nicolas Cellier wrote:
>
>> 2009/11/30 Stéphane Ducasse <[hidden email]>:
>>> ok so I imagine that this is already in pharo :)
>>> Excellent.
>>>
>>> Stef
>>>
>>
>> The only complication is that every DisplayScanner & co method was
>> reformatted in Pharo.
>> Chasing my own changes gets a bit tricky in these conditions...
>> I would need a special merger option to ignore formats (just scan code
>> and compare the sequence of tokens for example...).
>>
>> Nicolas
>>
>>> On Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote:
>>>
>>>> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>>>>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>>>>
>>>>>>>>>> Collections
>>>>>>>>>> -----------
>>>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>>>>
>>>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>>>>
>>>>>> Yes and I like the fast in the sentence :)
>>>>> It's probably along the lines of what I did back in August for Pharo,
>>>>> using the array primitives directly, instead of copying the elements one
>>>>> by one.
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>
>>>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
>>>> My implementation is a bit shorter and yours is faster:
>>>>
>>>> asArray
>>>>       "Overriden for speed"
>>>>        ^array copyFrom: firstIndex to: lastIndex
>>>>
>>>> Cheers
>>>>
>>>> Nicolas
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> http://code.google.com/p/pharo/issues/detail?id=1527
> http://code.google.com/p/pharo/issues/detail?id=1528
>
> A bit longer than I thought...
> At the end, I used change list instead of merger, because I can see
> method timestamp and isolate my own changes faster...
> That another enhancement request toward MC...
>
> Nicolas
>
> 2009/11/30 Stéphane Ducasse <[hidden email]>:
>> Yes I know.
>>
>> Stef
>>
>> On Nov 30, 2009, at 9:26 PM, Nicolas Cellier wrote:
>>
>>> 2009/11/30 Stéphane Ducasse <[hidden email]>:
>>>> ok so I imagine that this is already in pharo :)
>>>> Excellent.
>>>>
>>>> Stef
>>>>
>>>
>>> The only complication is that every DisplayScanner & co method was
>>> reformatted in Pharo.
>>> Chasing my own changes gets a bit tricky in these conditions...
>>> I would need a special merger option to ignore formats (just scan code
>>> and compare the sequence of tokens for example...).
>>>
>>> Nicolas
>>>
>>>> On Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote:
>>>>
>>>>> 2009/11/30 Henrik Sperre Johansen <[hidden email]>:
>>>>>> On 30.11.2009 19:29, Stéphane Ducasse wrote:
>>>>>>>>
>>>>>>>>>>> Collections
>>>>>>>>>>> -----------
>>>>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly.
>>>>>>>>>>>
>>>>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there.
>>>>>>>>
>>>>>>> Yes and I like the fast in the sentence :)
>>>>>> It's probably along the lines of what I did back in August for Pharo,
>>>>>> using the array primitives directly, instead of copying the elements one
>>>>>> by one.
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>
>>>>>
>>>>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it.
>>>>> My implementation is a bit shorter and yours is faster:
>>>>>
>>>>> asArray
>>>>>       "Overriden for speed"
>>>>>        ^array copyFrom: firstIndex to: lastIndex
>>>>>
>>>>> Cheers
>>>>>
>>>>> Nicolas
>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>>
>> _______________________________________________
>> 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