Character>to: was changed and breaks ObjectsTool

>> Chris, I'm sure you've been asked enough times before that you have some canned response you can point us to - how *exactly* would one personally make use of Magma as a repository. I'd prefer a tediously pedantic, explain everything in terms a complete dimwit can follow (believe me, I can play one of those) with more examples than you could imagine being needed by a Zabriskan Fontema[1].
> -----------
>
> Yes, I still need to update my configs for the SS3 changeover.  And I
> want it loading on the latest trunk.  Soon.
>
> -------------
>> As a possibly more widely useful alternative to running a local copy, would it be reasonable to set up a network accessible repository? I'm thinking here of a read-only (or at least almost-only) system that can answer *all* the versions of a method (and other Useful Things Of Assorted Nature) via some easy to implement net api. Run it on a decently powerful machine and load up absolutely every version of every method that has ever been in a main image, and maybe even every package that has been published?
>
> ------------
>
> Read-only might be doable, because it wouldn't require individual
> user-accounts.  Some job on the server could commit the new MC
> packages as they came in.
>
> The challenge might be with connecting to the read-only Magma
> repository across the open Internet.  I've long wanted to try to
> address this but there are so many ways and things to learn; I could
> actually use some guidance from the folks on this list on the best
> approach to handle this.  Magma currently talks with a proprietary,
> binary protocol and has not been sufficiently hardened from attack.
>
> Could its binary protocol simply be tunneled through SSL (SSH?) and
> would that be sufficient?  Would it be helpful at all for Magma to be
> able to talk over HTTP?  Not necessarily for consumption via
> web-browser, but just to be more.. "conventional" across the
> Internet..?  Does that matter?
>
> I would love to try the experiment Tim suggested, and the DB-side is
> done and ready, but what is the best approach for the connectivity
> across the internet?
>

> First, let's forget about OrderedCollection, that's just Levente's post that
> misguided me.
> The old behaviour was to return an Array, so you couldn't add: either.
>
> In your example, you explicitely asked for an Array, then you select: an
> Array, that seems fair.
> I see no reason why we would change that to a String.
>
> That's different from ($a to: $z) case where we did not explicitely
> requested an Array.
> Some code does indeed implicitely expect an Array, and I broke it, because
> - as you said, it's hard to analyze source (many senders)
> - and as we all know, we lack a few tests here and there (well, it's a joke,
> we lack more than we have, but that's a debt from the past that we slowly
> refund)
>
> But let's return to these expectations.
> An Array of Character has not much value per se. I mean that's exactly what
> a String is, an Array of Character...
> Except that the String is much much reacher with a bunch of specialized
> methods (because we know it contains Character).
> So to me, the most logical thing to do remains to answer a String.
> I'm not the only one to share this logic, look what Character class methods
> do:
>
> {Character alphabet. Character separators. Character allByteCharacters}
> collect: #class as: Set
>
> The only difference with String is when you collect: something else than
> Character, and that's what you bumped into.
> But as Levente said, we have very convenient collect:as: for this special
> case.
> So, I agree that I changed the contract and broke some code, but that's an
> easy to fix and probably rare problem.
> To me the balance benefits/costs is fair.
>
> This knowledge should go into some realease notes at least, in order to ease
> upgrades.
> But we are not yet at this level of maturity...
>
> Cheers
>
>
>
> 2013/7/18 tim Rowledge <[hidden email]>
>>
>>
>> On 18-07-2013, at 3:47 AM, Nicolas Cellier
>> <[hidden email]> wrote:
>> > I did the change and the rationale is that the most logical Collection
>> > recipient for Character is String, what else?
>>
>> I'm not at all sure I agree there; yes, as mentioned before a String is a
>> collection of Characters in some sense - but one should also consider an
>> Interval as an Array that is specified by shorthand that relies on a known
>> ordering. If we wrote
>> (Array with: $a with: $b with: $c) select:[:c| c =$b]
>> should we get #($b) or 'b' ? I think #($b) is correct.
>>
>> > OrderedCollection is totally arbitrary with this respect.
>> > OK, you cannot add: to a String. But can you add: to (1 to: 10)? No you
>> > can't.
>>
>> That's why #species is there - to provide a suitable recipient for the
>> results of enumerations when running over such objects.
>>
>> > So, put together, the Rationale is simply a principle of least
>> > astonishment.
>>
>> The practical problem is that even though I'm sure you looked to see what
>> problems the change might cause  - because you're nice (how often do I get
>> to make a fun pun on someone's name?) - you can't easily be sure that you
>> can even see all the places where it might be troublesome. It broke a
>> relatively basic tool that I stumbled upon because it is mentioned in a
>> tutorial. How can we feel sure it doesn't affect other bits of code? I don't
>> think it's terribly practical to search out every use of #to: (or other
>> Interval creation methods) and then dig around to find out how it got used
>> subsequently, it's simply too common an idiom. Within one's own special code
>> it can still be tricky if the project has grown large (ask me about grokking
>> Scratch…) but in the general case? Forget it, unless somebody has a project
>> to really, truly automate it. And in all the cases where we didn't catch the
>> problem, somebody is going to be unpleasantly astonished.
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> No, I don't explode cats. It's way too difficult to coax them into the
>> microwave - http://tinyurl.com/yp3hgr
>>
>>
>
>
>
>

>
> With our new friendly String concatenation Andreas introduced in 2009
> for safer error-handling, I can see there might be a plurality of
> cases like the above.
>
> On Fri, Jul 19, 2013 at 6:05 AM, Nicolas Cellier
> <[hidden email]> wrote:
>> First, let's forget about OrderedCollection, that's just Levente's post that
>> misguided me.
>> The old behaviour was to return an Array, so you couldn't add: either.
>>
>> In your example, you explicitely asked for an Array, then you select: an
>> Array, that seems fair.
>> I see no reason why we would change that to a String.
>>
>> That's different from ($a to: $z) case where we did not explicitely
>> requested an Array.
>> Some code does indeed implicitely expect an Array, and I broke it, because
>> - as you said, it's hard to analyze source (many senders)
>> - and as we all know, we lack a few tests here and there (well, it's a joke,
>> we lack more than we have, but that's a debt from the past that we slowly
>> refund)
>>
>> But let's return to these expectations.
>> An Array of Character has not much value per se. I mean that's exactly what
>> a String is, an Array of Character...
>> Except that the String is much much reacher with a bunch of specialized
>> methods (because we know it contains Character).
>> So to me, the most logical thing to do remains to answer a String.
>> I'm not the only one to share this logic, look what Character class methods
>> do:
>>
>> {Character alphabet. Character separators. Character allByteCharacters}
>> collect: #class as: Set
>>
>> The only difference with String is when you collect: something else than
>> Character, and that's what you bumped into.
>> But as Levente said, we have very convenient collect:as: for this special
>> case.
>> So, I agree that I changed the contract and broke some code, but that's an
>> easy to fix and probably rare problem.
>> To me the balance benefits/costs is fair.
>>
>> This knowledge should go into some realease notes at least, in order to ease
>> upgrades.
>> But we are not yet at this level of maturity...
>>
>> Cheers
>>
>>
>>
>> 2013/7/18 tim Rowledge <[hidden email]>
>>>
>>>
>>> On 18-07-2013, at 3:47 AM, Nicolas Cellier
>>> <[hidden email]> wrote:
>>> > I did the change and the rationale is that the most logical Collection
>>> > recipient for Character is String, what else?
>>>
>>> I'm not at all sure I agree there; yes, as mentioned before a String is a
>>> collection of Characters in some sense - but one should also consider an
>>> Interval as an Array that is specified by shorthand that relies on a known
>>> ordering. If we wrote
>>> (Array with: $a with: $b with: $c) select:[:c| c =$b]
>>> should we get #($b) or 'b' ? I think #($b) is correct.
>>>
>>> > OrderedCollection is totally arbitrary with this respect.
>>> > OK, you cannot add: to a String. But can you add: to (1 to: 10)? No you
>>> > can't.
>>>
>>> That's why #species is there - to provide a suitable recipient for the
>>> results of enumerations when running over such objects.
>>>
>>> > So, put together, the Rationale is simply a principle of least
>>> > astonishment.
>>>
>>> The practical problem is that even though I'm sure you looked to see what
>>> problems the change might cause  - because you're nice (how often do I get
>>> to make a fun pun on someone's name?) - you can't easily be sure that you
>>> can even see all the places where it might be troublesome. It broke a
>>> relatively basic tool that I stumbled upon because it is mentioned in a
>>> tutorial. How can we feel sure it doesn't affect other bits of code? I don't
>>> think it's terribly practical to search out every use of #to: (or other
>>> Interval creation methods) and then dig around to find out how it got used
>>> subsequently, it's simply too common an idiom. Within one's own special code
>>> it can still be tricky if the project has grown large (ask me about grokking
>>> Scratch…) but in the general case? Forget it, unless somebody has a project
>>> to really, truly automate it. And in all the cases where we didn't catch the
>>> problem, somebody is going to be unpleasantly astonished.
>>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>> No, I don't explode cats. It's way too difficult to coax them into the
>>> microwave - http://tinyurl.com/yp3hgr
>>>
>>>
>>
>>
>>
>>