Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Resistance is useless! (If << 1 ohm)
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as: OrderedCollection.
I can't commit now, so please do it.
Levente
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Resistance is useless! (If << 1 ohm)
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as: OrderedCollection.
I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
Hi Tim, I did the change and the rationale is that the most logical Collection recipient for Character is String, what else? 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. So, put together, the Rationale is simply a principle of least astonishment.
I just used this selector for own little experiments, then I used my commiter privilege (abused ?) to push the change to my benefit. I only act like this when I think that my own benefit matches general benefit. I have plenty of more questionnable changes that I don't push. I'm sorry that general benefit does not mean everyone's benefit, but in this case I would tend to favour Levente solution, fix Scratch and keep the String recipient.
Cheers
2013/7/18 tim Rowledge tim@rowledge.org
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an
Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a
collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as:OrderedCollection.
I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
On 18-07-2013, at 3:47 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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; tim@rowledge.org; 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
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 tim@rowledge.org
On 18-07-2013, at 3:47 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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; tim@rowledge.org; 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
On 19 July 2013 12:05, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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...
Sure we are! Add the note to http://wiki.squeak.org/squeak/6189 and when 4.5 gets released the release manager will have a nice lump of text to add to the "what's new" window.
frank
Cheers
2013/7/18 tim Rowledge tim@rowledge.org
On 18-07-2013, at 3:47 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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; tim@rowledge.org; 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
I ran into another "astonishing" breakage today, related to the change of Character>>#to:.
($0 to: $9) , (Array with: $_ with: $-) "now answers '0123456789#($_ $-)'"
To get around it, I simply changed the apps code to:
(Array with: $_ with: $-), ($0 to: $9) " #($_ $- $0 $1 $2 $3 $4 $5 $6 $7 $8 $9)"
I was fairly sold on your arguments but that these two are no longer commutative has caused some doubt to start creeping in.
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 nicolas.cellier.aka.nice@gmail.com 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 tim@rowledge.org
On 18-07-2013, at 3:47 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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; tim@rowledge.org; 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
I was fairly sold on your arguments but that these two are no longer commutative has caused some doubt to start creeping in.
Ok, maybe not that their not commutative, because there are other cases where the class of the receiver determines the class of the result.
But we should watch out for code that is wanting to defined limited Character sets using , (comma) concatenation..
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 nicolas.cellier.aka.nice@gmail.com 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 tim@rowledge.org
On 18-07-2013, at 3:47 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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; tim@rowledge.org; 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
The "why" of any change like this should be documented by its MCVersionInfo.
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as: OrderedCollection.I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
Yes it should, it was a bit shorter, but rationale was told in Collection-nice.518 http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-May/170832.html
2013/7/18 Chris Muller asqueaker@gmail.com
The "why" of any change like this should be documented by its MCVersionInfo.
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of
an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a
collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as:OrderedCollection.
I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the
system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
On Thu, Jul 18, 2013 at 08:37:06AM -0500, Chris Muller wrote:
The "why" of any change like this should be documented by its MCVersionInfo.
Ok, I'll bite. I'm looking at Character>>to: in a browser. I can find the version history, which gives a useful versions browser. And the versions browser provides "find original change set" in its menu. Very cool, although it does not seem to actually work. But never mind that, I'm sure that it used to work once upon a time, and it's a great idea so I like it.
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
Dave
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as: OrderedCollection.I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
On Fri, Jul 19, 2013 at 4:47 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jul 18, 2013 at 08:37:06AM -0500, Chris Muller wrote:
The "why" of any change like this should be documented by its
MCVersionInfo.
Ok, I'll bite. I'm looking at Character>>to: in a browser. I can find the version history, which gives a useful versions browser. And the versions browser provides "find original change set" in its menu. Very cool, although it does not seem to actually work. But never mind that, I'm sure that it used to work once upon a time, and it's a great idea so I like it.
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
No. The "system" is. As I understand it, the only way to locate an MC package version containing the first occurrence of a specific method version is to search versions of the MC package in a repository. One at least knows that the commit date of the MC package is >= the date of the version. One needs to compare two MC packages and verify that the method version doesn't exist in the first and does exit in the second. I've done this manually enough to know that it should be automated ;-)
Dave
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of
an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a
collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as:OrderedCollection.
I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up
the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters
- but I want to be assured that the change didn't bugger up any other
methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
No. The "system" is. As I understand it, the only way to locate an MC package version containing the first occurrence of a specific method version is to search versions of the MC package in a repository. One at least knows
If you're doing it manually like that, paging through the in-memory ancestry history (via the "History" button) is much faster than opening versions in the repository.
that the commit date of the MC package is >= the date of the version. One needs to compare two MC packages and verify that the method version doesn't exist in the first and does exit in the second. I've done this manually enough to know that it should be automated ;-)
It was automated, many moons ago. I use this almost every day.
http://wiki.squeak.org/squeak/5603
Dave
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 7:18 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 17 Jul 2013, tim Rowledge wrote:
Not long ago Character>to: was changed to return a String instead of an Array. That broke ObjectsTool>alphabeticTabs
Either we need to fix alphabeticTabs to re-convert the String to a collection, or rescind the change to Character>to:. It would help if the rationale for that change were known.
The fix is easy, just replace the line causing the bug with this:
tabLabels := ($a to: $z) collect: [:ch | ch asString] as:OrderedCollection.
I can't commit now, so please do it.
I had already sent a fix like that to Frank - since he's tearing up the system right now and I'm a bit occupied with Scratch modernisation - but I'm not convinced it is better than making $a to: $z go back to returning an Array. I *know* a String is kinda-sorta an array of characters - but I want to be assured that the change didn't bugger up any other methods as a side-effect. Why was it done? What efforts to ensure it didn't screw things were made?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode
-- best, Eliot
On Sat, Jul 20, 2013 at 01:11:34PM -0500, Chris Muller wrote:
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
No. The "system" is. As I understand it, the only way to locate an MC package version containing the first occurrence of a specific method version is to search versions of the MC package in a repository. One at least knows
If you're doing it manually like that, paging through the in-memory ancestry history (via the "History" button) is much faster than opening versions in the repository.
that the commit date of the MC package is >= the date of the version. One needs to compare two MC packages and verify that the method version doesn't exist in the first and does exit in the second. I've done this manually enough to know that it should be automated ;-)
It was automated, many moons ago. I use this almost every day.
Two questions:
1) Can this capability be made available and visible in the browsers that most of us use every day?
2) Why aren't we (all of us including most especially myself) paying more attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
Dave
+1 I've actually wondered about using the repo feature of Magma, but I haven't vocalized it. SqueakSource is wonky and Magma isn't, which is enough reason to try it.
Also, more people should check out Maui: it's fantastic.
On Jul 20, 2013, at 1:21 PM, "David T. Lewis" lewis@mail.msen.com wrote:
On Sat, Jul 20, 2013 at 01:11:34PM -0500, Chris Muller wrote:
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
No. The "system" is. As I understand it, the only way to locate an MC package version containing the first occurrence of a specific method version is to search versions of the MC package in a repository. One at least knows
If you're doing it manually like that, paging through the in-memory ancestry history (via the "History" button) is much faster than opening versions in the repository.
that the commit date of the MC package is >= the date of the version. One needs to compare two MC packages and verify that the method version doesn't exist in the first and does exit in the second. I've done this manually enough to know that it should be automated ;-)
It was automated, many moons ago. I use this almost every day.
Two questions:
- Can this capability be made available and visible in the browsers that
most of us use every day?
- Why aren't we (all of us including most especially myself) paying more
attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
Dave
Once we get a more-stable 4.5 I want to release new versions of both of these.
On Sat, Jul 20, 2013 at 3:54 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
+1 I've actually wondered about using the repo feature of Magma, but I haven't vocalized it. SqueakSource is wonky and Magma isn't, which is enough reason to try it.
Also, more people should check out Maui: it's fantastic.
On Jul 20, 2013, at 1:21 PM, "David T. Lewis" lewis@mail.msen.com wrote:
On Sat, Jul 20, 2013 at 01:11:34PM -0500, Chris Muller wrote:
I don't see anything at all that takes me to the MCVersionInfo corresponding to a version in the versions browser. Am I missing something?
No. The "system" is. As I understand it, the only way to locate an MC package version containing the first occurrence of a specific method version is to search versions of the MC package in a repository. One at least knows
If you're doing it manually like that, paging through the in-memory ancestry history (via the "History" button) is much faster than opening versions in the repository.
that the commit date of the MC package is >= the date of the version. One needs to compare two MC packages and verify that the method version doesn't exist in the first and does exit in the second. I've done this manually enough to know that it should be automated ;-)
It was automated, many moons ago. I use this almost every day.
Two questions:
- Can this capability be made available and visible in the browsers that
most of us use every day?
- Why aren't we (all of us including most especially myself) paying more
attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
Dave
- Why aren't we (all of us including most especially myself) paying more
attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
OK, I've wondered before but never got around to doing a damn thing about it; time to at least make an effort to correct that.
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].
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?
tim
[1] http://thereluctantsinger.xanga.com/663138748/does-anyone-know-/ -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DTF: Dump Tape to Floor
On 7/20/13, tim Rowledge tim@rowledge.org wrote:
- Why aren't we (all of us including most especially myself) paying
more attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
OK, I've wondered before but never got around to doing a damn thing about it; time to at least make an effort to correct that.
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].
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?
Great idea Tim to have a object oriented DB with a version of every method in the main image. And doable with the new servers I assume.
--Hannes
tim
[1] http://thereluctantsinger.xanga.com/663138748/does-anyone-know-/
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DTF: Dump Tape to Floor
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?
Below.
On Jul 21, 2013, at 11:00 AM, Chris Muller asqueaker@gmail.com wrote:
Magma currently talks with a proprietary, binary protocol and has not been sufficiently hardened from attack.
If you want some nice nice threats, I know a guy who knows a guy (actually the guy he knows is me) who enjoys the hell out of hunting these kinds of bugs in an appropriate context:)
You might do WebClient + SqueakSSL. That's at least going to give you a prototype real fast to vet the idea.
On Jul 21, 2013, at 11:00 AM, Chris Muller asqueaker@gmail.com wrote:
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?
It was automated, many moons ago. I use this almost every day.
Two questions:
- Can this capability be made available and visible in the browsers that
most of us use every day?
It already is. It uses the Service registry stuff to register two new capabilities for the methods menu and the class-list menu. The screenshot at the above link is a picture of those standard menus after loading Magma into your image. They will be grayed-out unless you add a Magma-based MC repository to the package of whatever method you're browsing.
- Why aren't we (all of us including most especially myself) paying more
attention to Magma and making use of it as supporting infrastructure? It seems blindingly obvious that this would be a good way to support shared access to a database of Squeak version history.
Magma lacks a user-account model necessary to host a shared repository directly on the Internet (not to mention, the challenges of finding a hosting service that will let you run a Squeak image to serve up a proprietary binary protocol..??).
Which leaves the only option would be to have a WEB front-end on a with a Magma DB on the backend. This can be done, but it requires careful attention to performance considerations -- where increasing the number of session connections to the DB can increase throughput, but also the costs of transparently keeping those sessions consistent and up-to-date with the model -- the wonderfullest aspect of Magma -- intrudes into the performance of the web-app, driving the developer to use simpler databases.
But for this one use-case, there is no reason anyone who develops in Squeak could not create their own Magma repository on their LAN and copy all Versions from one or more MC repository into it in just a few minutes. Just doing that provides the version-lookup and MC method-history capabilities directly in the browsers.
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
H. Hirzel -
Levente Uzonyi -
Nicolas Cellier -
tim Rowledge