Character>to: was changed and breaks ObjectsTool
Locked
12
12
Character>to: was changed and breaks ObjectsTool
 
|
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; [hidden email]; http://www.rowledge.org/tim Resistance is useless! (If << 1 ohm) |
Re: Character>to: was changed and breaks ObjectsTool
|
|
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; [hidden email]; http://www.rowledge.org/tim > Resistance is useless! (If << 1 ohm) > > > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
On 17-07-2013, at 7:18 PM, Levente Uzonyi <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: YOGA: Exit Finite-State Mode |
Re: Character>to: was changed and breaks ObjectsTool
|
|
Hi Tim, OrderedCollection is totally arbitrary with this respect. I did the change and the rationale is that the most logical Collection recipient for Character is String, what else? 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 <[hidden email]>
|
Re: Character>to: was changed and breaks ObjectsTool
|
|
In reply to this post by timrowledge
The "why" of any change like this should be documented by its MCVersionInfo.
On Wed, Jul 17, 2013 at 10:56 PM, tim Rowledge <[hidden email]> wrote: > > On 17-07-2013, at 7:18 PM, Levente Uzonyi <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: YOGA: Exit Finite-State Mode > > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
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 <[hidden email]> The "why" of any change like this should be documented by its MCVersionInfo. |
Re: Character>to: was changed and breaks ObjectsTool
|
|
In reply to this post by Nicolas Cellier
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 |
Re: Character>to: was changed and breaks ObjectsTool
|
|
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 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]>
|
Re: Character>to: was changed and breaks ObjectsTool
|
|
On 19 July 2013 12:05, 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... 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 <[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 >> >> > > > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
In reply to this post by Chris Muller-3
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 <[hidden email]> wrote: > > > > On 17-07-2013, at 7:18 PM, Levente Uzonyi <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > > Strange OpCodes: YOGA: Exit Finite-State Mode > > > > > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
On Fri, Jul 19, 2013 at 4:47 PM, David T. Lewis <[hidden email]> wrote: On Thu, Jul 18, 2013 at 08:37:06AM -0500, Chris Muller wrote: 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 ;-)
best, Eliot
|
Re: Character>to: was changed and breaks ObjectsTool
|
|
>> 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 <[hidden email]> wrote: >> > > >> > > On 17-07-2013, at 7:18 PM, Levente Uzonyi <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim >> > > Strange OpCodes: YOGA: Exit Finite-State Mode >> > > >> > > >> > > >> > > > > -- > best, > Eliot > > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
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. > > http://wiki.squeak.org/squeak/5603 > 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 |
Re: Character>to: was changed and breaks ObjectsTool
|
|
+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" <[hidden email]> 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. >> >> http://wiki.squeak.org/squeak/5603 >> > > 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 > > |
Re: Character>to: was changed and breaks ObjectsTool
|
|
In reply to this post by David T. Lewis
>> It was automated, many moons ago. I use this almost every day.
>> >> http://wiki.squeak.org/squeak/5603 >> > > Two questions: > > 1) 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. > 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. 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. |
Re: Character>to: was changed and breaks ObjectsTool
|
|
In reply to this post by Casey Ransberger-2
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 <[hidden email]> 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" <[hidden email]> 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. >>> >>> http://wiki.squeak.org/squeak/5603 >>> >> >> 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 >> >> > |
Magma code repository (was Re: [squeak-dev] Character>to: was changed and breaks ObjectsTool)
|
|
>> 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. 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: DTF: Dump Tape to Floor |
Re: Magma code repository (was Re: [squeak-dev] Character>to: was changed and breaks ObjectsTool)
|
|
On 7/20/13, tim Rowledge <[hidden email]> wrote:
>>> 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. > > > 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; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: DTF: Dump Tape to Floor > > > > |
Re: Magma code repository (was Re: [squeak-dev] Character>to: was changed and breaks ObjectsTool)
|
|
In reply to this post by timrowledge
> 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? |
Re: Magma code repository (was Re: [squeak-dev] Character>to: was changed and breaks ObjectsTool)
|
|
Below.
On Jul 21, 2013, at 11:00 AM, Chris Muller <[hidden email]> 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:) |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |