[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections

Gerald Klix cuis.01 at klix.ch
Tue Feb 6 08:47:13 PST 2024 

Some 5 minutes before I saw Juan's reply, I just used that semantics.
I don't want run my code, but I did this:

bear at speedy ~/s/c/Environments> find -iname '*.st' | xargs grep 'new: ' 
| grep Order | wc -l
grep: ./Haver-UserFiles/FileOuts/TheWorldMenu: No such file or directory
grep: class-haversPreferencesMenu.st: No such file or directory
42

(Please disregard the dangling symlinks)

And no 42 is not a fake.!


For Cuis it is not that bad:

bear at speedy ~/g/C/Cuis-Smalltalk-Dev (master)> find -iname '*.st' | 
xargs grep 'new: ' | grep Order
./CoreUpdates/6174-SpurImageFormatOnly03-JuanVuletich-2024Jan04-16h34m-jmv.001.cs.st: 
results := OrderedCollection new: Smalltalk classNames size.
./CoreUpdates/6172-SpurImageFormatOnly01-JuanVuletich-2024Jan04-15h08m-jmv.003.cs.st: 
results := OrderedCollection new: Smalltalk classNames size.
./CoreUpdates/6185-Character-EnablingUnicodeRange-JuanVuletich-2024Jan08-12h24m-jmv.003.cs.st: 
newOrder := Array new: 256.
./CoreUpdates/6185-Character-EnablingUnicodeRange-JuanVuletich-2024Jan08-12h24m-jmv.003.cs.st: 
newOrder := Array new: 256.
./CoreUpdates/6028-sharedPools-Array-notOrderedColleciton-JuanVuletich-2023Sep13-18h05m-jmv.001.cs.st: 
     sharedPools := Array new: s.
./CoreUpdates/6020-String-RemoveClassVars-JuanVuletich-2023Sep11-15h35m-jmv.001.cs.st: 
newOrder := Array new: 256.
./CoreUpdates/6020-String-RemoveClassVars-JuanVuletich-2023Sep11-15h35m-jmv.001.cs.st: 
newOrder := Array new: 256.
./CoreUpdates/6007-UnicodeSymbolCleanup-add-removed-back-JuanVuletich-2023Sep09-16h58m-jmv.001.cs.st: 
contourDataIndexesByUtf8 := (IntegerArray new: 256) as: OrderedCollection.
./CoreUpdates/6004-UnicodeSymbolCleanup-new-temporary-JuanVuletich-2023Sep09-16h55m-jmv.001.cs.st: 
contourDataIndexesByUtf8 := (IntegerArray new: 256) as: OrderedCollection.
./Packages/BaseImageTests.pck.st:    things := OrderedCollection new: 
self iterationsBeforeTimeout.
./Packages/Features/YAXO.pck.st:    scope := OrderedCollection new: 20.
./Packages/Features/System-Locales.pck.st:    table := OrderedCollection 
new: 200.
./Packages/Features/Sound.pck.st:    r _ OrderedCollection new: 
aNoteList size.
./Packages/Features/Sound.pck.st:    recordedBuffers _ OrderedCollection 
new: 100.
./Packages/Features/Compression.pck.st:    tableStack _ 
OrderedCollection new: 10. "Should be more than enough"
./Packages/System/ExtendedClipboard.pck.st:    availableFormats _ 
OrderedCollection new: 10.
./Packages/System/ExtendedClipboard.pck.st:    availableFormats _ 
OrderedCollection new: 10.
./Packages/System/ExtendedClipboard.pck.st:    availableFormats _ 
OrderedCollection new: 10.
./Packages/System/FFI.pck.st:    sorted := OrderedCollection new: 
unsorted size.
./Packages/System/Collections-CompactArrays.pck.st:    LastSaveOrder _ 
self new: 2.
./CompatibilityPackages/SqueakCompatibility.pck.st:    entries _ 
OrderedCollection new: 200.
./CompatibilityPackages/SqueakCompatibility.pck.st:    result _ 
OrderedCollection new: 100.

Done before any updates.
We should definitely add the old behavior in the Squeak compatibility 
module.

HTH,

Gerald


On 2/6/24 5:21 PM, Hernán Wilkinson via Cuis-dev wrote:
> Gerald,
>   Could you run your stuff with these changes to see the real impact? I’d
> like to see that if possible
>
> Thanks!
> Hernan
>
>
> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>
>
> On Tue, 6 Feb 2024 at 13:11 Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> On 2/6/2024 12:57 PM, Gerald Klix via Cuis-dev wrote:
>>> On 2/6/24 4:44 PM, Gerald Klix wrote:
>>>> OMG, what have I done!
>>>>
>>>> PLEASE DON'T!!!!!!!!!!!!!
>>>>
>>>> See below.
>>>>
>>>>
>>>> On 2/6/24 3:56 PM, Juan Vuletich via Cuis-dev wrote:
>>>>> On 2/1/2024 5:43 PM, Gerald Klix via Cuis-dev wrote:
>>>>>> Hi all, Hi Juan,
>>>>>>
>>>>>> I found a glitch in #copyFrom:count.
>>>>>> IHMO both expression should work:
>>>>>>
>>>>>> --- snip ---
>>>>>> 1 to: 10 :: copyFrom: 1 count: 3.
>>>>>>
>>>>>> 1 to: 10 :: asOrderedCollection copyFrom: 1 count: 3.
>>>>>> --- snap ---
>>>>>>
>>>>>> The later creates an empty OrderedCollection and fails.
>>>>>>
>>>>>> I attached a change set, that replaces sends of #new: with
>>>>>> sends of #sizeOf: in various methods,
>>>>>> although some of these methods are special cased
>>>>>> in OrderedCollection.
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Gerald
>>>>> Thanks Gerald. I integrated this a few days ago. Still, I think that
>>>>>
>>>>> | n |
>>>>> n := whatever number.
>>>>> (AnyCollectionClass new: n) size = n
>>>>>
>>>>> should _always_ evaluate to true (or fail if it doesn't make sense).
>>>>> So I pushed some very substantial changes that kept me quite busy
>>>>> for several days. Now `OrderedCollection new: 10` will fail. Same
>>>>> for Set, Dictionary, Bag and a few others. I've adjusted many
>>>>> packages accordingly.
>>>>>
>>>>> Cheers,
>>>>>
>>>> Oh my goodness, that breaks so much of my and everyone else's code.
>>>> Please don't!!!!!
>>>>
>>>> This behavior was already present in Smalltalk/V for MSDos
>>>> and in Smalltalk-80 (see: https://github.com/dbanay/Smalltalk)
>>>>
>>>> Please note, 40 year ago my computer science education
>>>> began more or less with Algebraic Specification:
>>>> I am acutely aware of this inconsistency!
>>>>
>>>> Everyone – even language lawyers – can like with this invariant:
>>>> (AnyCollectionClass sizeOf: n) size = n
>>>>
>>>> Please follow my advice!
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Gerald
>>> I am also inclined to quote the ANSI Smalltalk standard:
>>>
>>> 5.7.20.2 Message: new: count
>>>
>>> Synopsis
>>> Create a new collection. The parameter count constrains the number of
>>> elements in the result.
>>>
>>> Definition: <collection factory>
>>> Return a new collection that has space for at least count elements.
>>> Conforming protocols may refine this message. In particular, the
>>> effect of the parameter count
>>> should be specified in refinements. It can be used to specify the
>>> exact number of elements, the
>>> minimum number, or in some cases can even be interpreted as a hint
>>> from the programmer, with
>>> no guarantee that the requested number of instance variables will
>>> actually be allocated.
>>> Unless otherwise stated the initial values of elements, if any, of the
>>> new collection are unspecified.
>>>
>>> Parameters
>>> count <integer> unspecified
>>>
>>> Return Values
>>> <collection> new
>>>
>>> Errors
>>> none
>>>
>>> Quoted from
>>> https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf
>>> Page 227
>>>
>>> Page 239 is even more specific:
>>>
>>> 5.7.27.1Message Refinement: new
>>>
>>> Synopsis
>>> Create a new object.
>>>
>>> Definition: <instantiator>
>>> Return a newly created object initialized to a standard initial state.
>>>
>>> Refinement: <collection factory>
>>> This message has the same effect as sending the message#new:with the
>>> argument0, and will
>>> return an empty collection.
>>>
>>> Refinement: <OrderedCollection factory>
>>>
>>> Create a new <OrderedCollection> that is optimized to store an
>>> implementation defined number of
>>> elements. The new collection initially contains no elements.
>>>
>>> Return Values
>>> <OrderedCollection>new
>>>
>>> Errors
>>> none
>>>
>>>
>>> Best Regards,
>>>
>>> Gerald
>> I really don't give crap for ANSI Smalltalk.
>>
>> But if everyone goes nuts like you about this, we can add a preference.
>>
>> Cheers,
>>
>> PS: Please don't take offense for my wording. I'm just kidding. We'll do
>> what is best for the community.
>>
>> --
>> Juan Vuletich
>> cuis.st
>> github.com/jvuletich
>> researchgate.net/profile/Juan-Vuletich
>> independent.academia.edu/JuanVuletich
>> patents.justia.com/inventor/juan-manuel-vuletich
>> linkedin.com/in/juan-vuletich-75611b3
>> twitter.com/JuanVuletich
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>

More information about the Cuis-dev mailing list