While looking around in a 4.5 image to prepare to move my code into the ‘official’ image I idly noodled around some of the docking bar menus.
I noticed that the Apps->Services Browser opened something that appears to actually be the PreferencesBrowser, and that after taking a look at the Services classes I have no idea what the entire package is supposed to do nor whether it is used much. Is it actually useful?
I noticed that Apps->Universe Browser doesn’t do anything fun because it can’t load any data from the now non-existent universes.dnsalias.net And there are two entries (Apps->Package Universe Browser & Apps->Universe Browser) that open what looks to be identical browsers. IIRC we are planning to remove this stuff anyway, so perhaps it doesn’t matter too much.
I noticed that Apps->SqueakMap Catalog & Categories sort-of open but after supposedly updating the contents hardly any of the packages you can see via a plain web browser appear in the lists. For example, in the development tools section I see only LispKit & Prolog and not the perhaps 100 other packages.
And since one of the things I was originally intending to check on was space usage, I’m amazed to see 3Mb of strings (that’s about War and Peace), 9000 MCVersionInfo instances (and similar numbers of MCVersionName + DateAndTime, and Date, and Time). Wow. We’re holding on to too much stuff somewhere...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!
On 4/8/14, 11:52 PM, "tim Rowledge" tim@rowledge.org wrote:
While looking around in a 4.5 image to prepare to move my code into the official¹ image I idly noodled around some of the docking bar menus.
I noticed that the Apps->Services Browser opened something that appears to actually be the PreferencesBrowser, and that after taking a look at the Services classes I have no idea what the entire package is supposed to do nor whether it is used much. Is it actually useful?
I noticed that Apps->Universe Browser doesn¹t do anything fun because it can¹t load any data from the now non-existent universes.dnsalias.net And there are two entries (Apps->Package Universe Browser & Apps->Universe Browser) that open what looks to be identical browsers. IIRC we are planning to remove this stuff anyway, so perhaps it doesn¹t matter too much.
I noticed that Apps->SqueakMap Catalog & Categories sort-of open but after supposedly updating the contents hardly any of the packages you can see via a plain web browser appear in the lists. For example, in the development tools section I see only LispKit & Prolog and not the perhaps 100 other packages.
And since one of the things I was originally intending to check on was space usage, I¹m amazed to see 3Mb of strings (that¹s about War and Peace), 9000 MCVersionInfo instances (and similar numbers of MCVersionName + DateAndTime, and Date, and Time). Wow. We¹re holding on to too much stuff somewhere...
tim
From 3.10 times I saying we should rip Universes, SqueakMap ,ScriptLoader,
etc and stick only to Monticello as a way to load any into the .image.
As Pharo and Cuis do today.
Specially look Cuis GitHub package way, it's where we should go in 4.6 and beyond.
Not sure about Services, but think Andreas talk about rip this also.
Edgar
On Wed, Apr 09, 2014 at 08:23:43AM -0300, Edgar J. De Cleene wrote:
On 4/8/14, 11:52 PM, "tim Rowledge" tim@rowledge.org wrote:
While looking around in a 4.5 image to prepare to move my code into the ?official? image I idly noodled around some of the docking bar menus.
I noticed that the Apps->Services Browser opened something that appears to actually be the PreferencesBrowser, and that after taking a look at the Services classes I have no idea what the entire package is supposed to do nor whether it is used much. Is it actually useful?
I noticed that Apps->Universe Browser doesn?t do anything fun because it can?t load any data from the now non-existent universes.dnsalias.net And there are two entries (Apps->Package Universe Browser & Apps->Universe Browser) that open what looks to be identical browsers. IIRC we are planning to remove this stuff anyway, so perhaps it doesn?t matter too much.
I noticed that Apps->SqueakMap Catalog & Categories sort-of open but after supposedly updating the contents hardly any of the packages you can see via a plain web browser appear in the lists. For example, in the development tools section I see only LispKit & Prolog and not the perhaps 100 other packages.
And since one of the things I was originally intending to check on was space usage, I?m amazed to see 3Mb of strings (that?s about War and Peace), 9000 MCVersionInfo instances (and similar numbers of MCVersionName + DateAndTime, and Date, and Time). Wow. We?re holding on to too much stuff somewhere...
tim
From 3.10 times I saying we should rip Universes, SqueakMap ,ScriptLoader, etc and stick only to Monticello as a way to load any into the .image.
As Pharo and Cuis do today.
Specially look Cuis GitHub package way, it's where we should go in 4.6 and beyond.
Not sure about Services, but think Andreas talk about rip this also.
Edgar
SqueakMap uses Monticello to load packages, so that is not a problem. It also allows other loaders to be used, which may be important for older packages.
The Cuis approach is interesting, but we do not need *more* ways to find loadable packages. I have tried the Cuis approach (I put OSProcess into a package for Cuis). It is a good idea with some advantages, but it would not be helpful as a "Squeak map catalog" because it relies on active package maintainers who are participating in the development process.
Pharo looks like a mess to me. Everything is declared to work with some version of stuff that you don't have. Let's not go there.
The only problem I have with SqueakMap is that for packages like TwosComplement or PunchedCards on SqueakMap, which run on more or less any version of Squeak, I am expected to remember to update those packages on SqueakMap every time someone releases a new Squeak version. This is annoying and eventually I might run out of patience and forget to do it.
Dave
On 4/9/14, 9:18 AM, "David T. Lewis" lewis@mail.msen.com wrote:
The Cuis approach is interesting, but we do not need *more* ways to find loadable packages. I have tried the Cuis approach (I put OSProcess into a package for Cuis).
Where I found OSProcess and CommandShell for Cuis?
It is a good idea with some advantages, but it would not be helpful as a "Squeak map catalog" because it relies on active package maintainers who are participating in the development process.
Many packages work in 4.5 , but not listed as such in SqueakMap.
Edgar
On 4/9/14, 9:18 AM, "David T. Lewis" lewis@mail.msen.com wrote:
The Cuis approach is interesting, but we do not need *more* ways to find loadable packages. I have tried the Cuis approach (I put OSProcess into a package for Cuis).
Where I found OSProcess and CommandShell for Cuis?
OSProcess is at https://github.com/dtlewis290/Cuis-Smalltalk-OSProcess on GitHub. I have not updated CommandShell for Cuis (that is more work).
It is a good idea with some advantages, but it would not be helpful as a "Squeak map catalog" because it relies on active package maintainers who are participating in the development process.
Many packages work in 4.5 , but not listed as such in SqueakMap.
Edgar
The only problem I have with SqueakMap is that for packages like TwosComplement or PunchedCards on SqueakMap, which run on more or less any version of Squeak, I am expected to remember to update those packages on SqueakMap every time someone releases a new Squeak version. This is annoying and eventually I might run out of patience and forget to do it.
What's more annoying is bit-rot, having a bunch of stuff listed in SqueakMap that doesn't work. That's what led to its horrible reputation.
The whole purpose of the Catalog is to tell me what software is _available_ -- e.g., what *works*. If it can't do that, it's useless. The only way it can do that is to require that we manually designate new releases of packages for each new release of Squeak.
Which is why I tried to make that process as quick and painless as possible. And it's clearly documented here:
http://wiki.squeak.org/squeak/6180
It takes just a few minutes per package. How often are new Squeak versions put out? So, a few minutes per year per package seems like a small price to pay for solving the bit-rot problem..
On 09-04-2014, at 5:18 AM, David T. Lewis lewis@mail.msen.com wrote:
The only problem I have with SqueakMap is that for packages like TwosComplement or PunchedCards on SqueakMap, which run on more or less any version of Squeak, I am expected to remember to update those packages on SqueakMap every time someone releases a new Squeak version. This is annoying and eventually I might run out of patience and forget to do it.
That’s an important issue; somebody either leaving the squeak world, or being busy, or forgetful or whatever, can effectively kill a package. There must be a way to allow ‘other’ to tag a package as ok for a later release. There probably ought to be away to wrest ownership from an absent landlord.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LAG: Load and Garble
On Wed, Apr 9, 2014 at 12:05 PM, tim Rowledge tim@rowledge.org wrote:
On 09-04-2014, at 5:18 AM, David T. Lewis lewis@mail.msen.com wrote:
The only problem I have with SqueakMap is that for packages like TwosComplement or PunchedCards on SqueakMap, which run on more or less any version of Squeak, I am expected to remember to update those packages on SqueakMap every time someone releases a new Squeak version. This is annoying and eventually I might run out of patience and forget to do it.
By following the SqueakMap Publishing Guidelines, this issue is avoided / solved.
http://wiki.squeak.org/squeak/6182
See under heading "Guidelines for writing the script for the head release".
To wit, it suggests using the provided script to enable a trunk-like process for every cataloged project. For example, you can simply "install" it again and it will do a merge so even if you've made local changes, you won't lose them.
(But, please note the Guidelines also request you make at least one *fixed-configuration* so its at least preserved in SOME version of Squeak, protected from bit-rot.
That’s an important issue; somebody either leaving the squeak world, or being busy, or forgetful or whatever, can effectively kill a package.
I somewhat disagree. Packages don't die. They just "sleep" until the need it fulfilled is needed again, and someone comes looking and finds it and, even if only a fixed-configuration for an older version of Squeak is available, by the Publishing Guidelines they at least know it will WORK in taht version of Squeak and can do the (usually simple) work of porting it forward to current Squeak.
There must be a way to allow ‘other’ to tag a package as ok for a later release.
Yes, it's the head release described by the Publishing Guidelines.
There probably ought to be away to wrest ownership from an absent landlord.
Yes, that is requirement #9 at http://wiki.squeak.org/squeak/6183, which is fulfilled by the Community-Supported tag. We used when YOU were the absent landlord for a few years.. :)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-July/164962.html
I’m both glad that there is actual documentation for this and saddened that I’ve had such a bad time in general looking for doc that I’ve almost given up.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
Hi Tim,
On Tue, Apr 8, 2014 at 9:52 PM, tim Rowledge tim@rowledge.org wrote:
While looking around in a 4.5 image to prepare to move my code into the ‘official’ image I idly noodled around some of the docking bar menus.
I noticed that the Apps->Services Browser opened something that appears to actually be the PreferencesBrowser, and that after taking a look at the Services classes I have no idea what the entire package is supposed to do nor whether it is used much. Is it actually useful?
I'm not sure why Services Browser seems to open Preferences Browser, maybe THAT's a bug, but Services are definitely used and useful.
They're so that external frameworks can extend the IDE. For example, that MC History function which you wanted and got delivered to you uses the Services framework. :)
Check out "Create new service..." on the Methods menu.
I noticed that Apps->Universe Browser doesn’t do anything fun because it can’t load any data from the now non-existent universes.dnsalias.net And there are two entries (Apps->Package Universe Browser & Apps->Universe Browser) that open what looks to be identical browsers. IIRC we are planning to remove this stuff anyway, so perhaps it doesn’t matter too much.
Universes is not used at all, TMK.
I noticed that Apps->SqueakMap Catalog & Categories sort-of open but after supposedly updating the contents hardly any of the packages you can see via a plain web browser appear in the lists. For example, in the development tools section I see only LispKit & Prolog and not the perhaps 100 other packages.
That's because they weren't tagged as working in 4.5 and you didn't unselect "safely available" packages.
Displaying all packages for all versions of Squeak is much worse than displaying the just ones that WORK. Because SM developed a reputation over the years that "nothing works". In actuality, most everything works as long as you load it into the Squeak version it is designated for.
If something has not been re-designated for latest 4.5 of Squeak then, by definition, it is "rotting" and so should not be displayed in the list.
Please read for refresher:
http://wiki.squeak.org/squeak/6182 http://wiki.squeak.org/squeak/6183 http://wiki.squeak.org/squeak/6180
And since one of the things I was originally intending to check on was space usage, I’m amazed to see 3Mb of strings (that’s about War and Peace), 9000 MCVersionInfo instances (and similar numbers of MCVersionName + DateAndTime, and Date, and Time). Wow. We’re holding on to too much stuff somewhere...
Yes, and as you know I already addressed MCVersionInfo bloat (just select "flush cached versions and ancestry") but nobody liked it, so maybe you can improve it so they will.
I also introduced String #empty, but we still have thousands of empty ByteStrings in the image, which is kinda useless.
Also, you may want to check how many duplicate Date's you have and do something to canonicalize your Date instances.
On 09-04-2014, at 9:12 AM, Chris Muller asqueaker@gmail.com wrote:
I'm not sure why Services Browser seems to open Preferences Browser, maybe THAT's a bug, but Services are definitely used and useful.
They're so that external frameworks can extend the IDE. For example, that MC History function which you wanted and got delivered to you uses the Services framework. :)
Check out "Create new service..." on the Methods menu.
OK, good to know it is used. Some class comments etc might have helped to make it more obvious what it is for, some easily findable doc on the swiki would be nice… oh, wait, buried in WorldMenuProvider is #servicesHelpText - which is supposed to appear in some response to #preferencesMenuhelpOnServices. Except that I can’t find any reference to that anywhere, even doing a sources scan, so it looks like there isn’t any way one would see that.
The browser class ‘ServiceBrowserMorph’ seems like it must have been eviscerated since there is only one method, which over-rides the PreferenceBrowserMorph so as to not have the row of buttons in the top pane. That really can’t be what was intended, surely.
There’s an old saying of Adele’s - “if it isn’t documented, it doesn’t exist. If it doesn’t exist, what did we pay you for?” Now, while there may not be much in the way of payment going on, the spirit of the aphorism is really important. No doc means nobody is likely to understand WTF is going on. Which means it won’t get used properly, won’t be debugged and improved properly and before you know it you’ve got Ruby. Or Java. We collectively should hold ourselves to a higher standard on not adding code to the system that isn’t adequately described, and preferably provided with examples and tests.
I noticed that Apps->SqueakMap Catalog & Categories sort-of open but after supposedly updating the contents hardly any of the packages you can see via a plain web browser appear in the lists. For example, in the development tools section I see only LispKit & Prolog and not the perhaps 100 other packages.
That's because they weren't tagged as working in 4.5 and you didn't unselect "safely available" packages.
OK, that’s sensible BUT another case where we are failing to provide the user with important documentation in a sensible place. Perhaps nothing more is needed than a pane clearly showing which filtering is in use? Yes, I see the checkboxes in the menu and even a brief mention in the help pop-up (which is a big improvement over the typical app, by the way).
And since one of the things I was originally intending to check on was space usage, I’m amazed to see 3Mb of strings (that’s about War and Peace), 9000 MCVersionInfo instances (and similar numbers of MCVersionName + DateAndTime, and Date, and Time). Wow. We’re holding on to too much stuff somewhere...
Yes, and as you know I already addressed MCVersionInfo bloat (just select "flush cached versions and ancestry") but nobody liked it, so maybe you can improve it so they will.
Vaguely remembered, mostly forgotten, quickly checked and claims to have cut 2Mb .. and it does indeed reduce the image size on disk. That’s also cut 7000 MCinfo-wotsits so we’re down to just 2500 (why are any left?) and a similar number of DateAndTime/Date/Time, so clearly they are tightly related. (Fun aside; inspecting MCVersionInfo allInstances, select one at random, ‘chase pointers’ - and a large list of updates start loading…. adding 13Mb to the image size. Yippee.)
I also introduced String #empty, but we still have thousands of empty ByteStrings in the image, which is kinda useless.
Damn straight. Wonder if I can find them all….
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't be sexist; broads hate that!
On Wed, Apr 9, 2014 at 1:01 PM, tim Rowledge tim@rowledge.org wrote:
Vaguely remembered, mostly forgotten, quickly checked and claims to have cut 2Mb .. and it does indeed reduce the image size on disk. That's also cut 7000 MCinfo-wotsits so we're down to just 2500 (why are any left?) and a similar number of DateAndTime/Date/Time, so clearly they are tightly related. (Fun aside; inspecting MCVersionInfo allInstances, select one at random, 'chase pointers' - and a large list of updates start loading.... adding 13Mb to the image size. Yippee.)
That's why nobody liked it. :-)
Colin
On 09-04-2014, at 11:07 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Apr 9, 2014 at 1:01 PM, tim Rowledge tim@rowledge.org wrote:
Vaguely remembered, mostly forgotten, quickly checked and claims to have cut 2Mb .. and it does indeed reduce the image size on disk. That’s also cut 7000 MCinfo-wotsits so we’re down to just 2500 (why are any left?) and a similar number of DateAndTime/Date/Time, so clearly they are tightly related. (Fun aside; inspecting MCVersionInfo allInstances, select one at random, ‘chase pointers’ - and a large list of updates start loading…. adding 13Mb to the image size. Yippee.)
That's why nobody liked it. :-)
It may be that Chris’s technique for dumping the ancestry was less than perfect, but I’d say the real problem would likely be the ancestry code. Is there any plausible reason for a ‘clean’ image to have 9000 version-doohickeys taking up a couple of MB?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PO: Punch Operator
On Wed, Apr 9, 2014 at 1:01 PM, tim Rowledge tim@rowledge.org wrote:
Vaguely remembered, mostly forgotten, quickly checked and claims to have cut 2Mb .. and it does indeed reduce the image size on disk. That’s also cut 7000 MCinfo-wotsits so we’re down to just 2500 (why are any left?) and a similar number of DateAndTime/Date/Time, so clearly they are tightly related. (Fun aside; inspecting MCVersionInfo allInstances, select one at random, ‘chase pointers’ - and a large list of updates start loading…. adding 13Mb to the image size. Yippee.)
That's why nobody liked it. :-)
It may be that Chris’s technique for dumping the ancestry was less than perfect, but I’d say the real problem would likely be the ancestry code. Is there any plausible reason for a ‘clean’ image to have 9000 version-doohickeys taking up a couple of MB?
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
On 09-04-2014, at 11:37 AM, Chris Muller asqueaker@gmail.com wrote:
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
Wasn’t criticising what you did because I don’t know what you did - merely allowing that Colin might know of some problem in your approach. Thus the "I’d say the real problem would likely be the ancestry code” bit.
I agree about what is wanted (except I’d like to know how we could get rid of the other 2500 version-thingies as well) and the proxy problems.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There are no stupid questions. But, there are a lot of inquisitive idiots.
I agree about what is wanted (except I’d like to know how we could get rid of the other 2500 version-thingies as well) and the proxy problems.
See the picture.
The idea was to make that "10" a preference value, and to change the tools like "History" to respect the preference. Because usually we don't need to look back more than 10 versions, but when we did it'd retrieve it automatically, dynamically, silently.
And to use that same concept to speed up our trunk-development process because how much time do we spend waiting on "Updating www.source.squeak.org/trunk" progress bar?
On 09-04-2014, at 11:53 AM, Chris Muller asqueaker@gmail.com wrote:
I agree about what is wanted (except I’d like to know how we could get rid of the other 2500 version-thingies as well) and the proxy problems.
See the picture.
The idea was to make that "10" a preference value, and to change the tools like "History" to respect the preference. Because usually we don't need to look back more than 10 versions, but when we did it'd retrieve it automatically, dynamically, silently.
Nice idea in general though I’m not often a fan of the ‘silent’ bit. And especially not a fan of the ‘unasked massive file loading’ aspect. Replacing the ancestry with a stub that can fetch the rest of the history is an excellent idea but how about making it ask the user first? It may well be inconvenient or even impossible to fetch the files, for example. I can see that there might be places where allowing the user to prevent loading something might cause other problems, but surely catching those cases would be preferable to getting the error from a failed network probe?
And to use that same concept to speed up our trunk-development process because how much time do we spend waiting on "Updating www.source.squeak.org/trunk" progress bar?
If it only needs doing once for a particular image/repository (?) then I’m not sure that it is a bad thing to notify the user about, give them a chance to decline, proceed if wanted.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet
The idea was to make that "10" a preference value, and to change the tools like "History" to respect the preference. Because usually we don't need to look back more than 10 versions, but when we did it'd retrieve it automatically, dynamically, silently.
Nice idea in general though I'm not often a fan of the 'silent' bit. And especially not a fan of the 'unasked massive file loading' aspect.
Replacing the ancestry with a stub that can fetch the rest of the history is an excellent idea but how about making it ask the user first? It may well be inconvenient or even impossible to fetch the files, for example. I can see that there might be places where allowing the user to prevent loading something might cause other problems, but surely catching those cases would be preferable to getting the error from a failed network probe?
You want to have a 100% guaranteed interruption prompt box to avoid a _possible_ network error box 1% of the time?
What is the scenario that has you wanting to stub ancestry and then get it back in the first place? In my world, the only use-case I can think for that is "debugging in production". I'm in one of my production images which had been previously "shrunk", and sometimes viewing change-history is a useful part of debugging. But if I'm in the production image then I've got network access so, no problem..?
On 09-04-2014, at 1:43 PM, Chris Muller ma.chris.m@gmail.com wrote:
The idea was to make that "10" a preference value, and to change the tools like "History" to respect the preference. Because usually we don't need to look back more than 10 versions, but when we did it'd retrieve it automatically, dynamically, silently.
Nice idea in general though I'm not often a fan of the 'silent' bit. And especially not a fan of the 'unasked massive file loading' aspect.
Replacing the ancestry with a stub that can fetch the rest of the history is an excellent idea but how about making it ask the user first? It may well be inconvenient or even impossible to fetch the files, for example. I can see that there might be places where allowing the user to prevent loading something might cause other problems, but surely catching those cases would be preferable to getting the error from a failed network probe?
You want to have a 100% guaranteed interruption prompt box to avoid a _possible_ network error box 1% of the time?
Given an ancestry stubbed by the current proxy based mechanism, yes I’d like to be warned if something causes the proxies to trigger and want to fetch stuff from the net. Errors may be rare but the *time* it takes can be considerable. I have fairly fast net access at home but lots of people don’t. I may simply want to stop the operation because it was triggered by something not really relevant - like accidentally doing so as part of chasing pointers. It isn’t only network failures.
What is the scenario that has you wanting to stub ancestry and then get it back in the first place? In my world, the only use-case I can think for that is "debugging in production". I'm in one of my production images which had been previously "shrunk", and sometimes viewing change-history is a useful part of debugging. But if I'm in the production image then I've got network access so, no problem..?
Not all production images have network access. So there needs to be a way to handle the attempt cleanly.
My scenario is simply an attempt to find out what is occupying so much space in my image and attempt to remove or at least reduce them. Your mechanism for getting rid of a lot of MC version stuff is useful but the proxies cause later issues.
In any sort of production image I suggest that we’d be better off with a way to just remove the MC data completely, and thus avoid the entire proxy discussion. Given a default image distributed with the accent of developer usage - a perfectly reasonable approach - it would be nice to have easily findable, effective tools to remove as much as possible and practical that can be dumped. 2-3Mb of ancestry data could be argued to have value for developers but not really in production.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- During evolution his ancestors were in the control group.
On Wed, Apr 9, 2014 at 1:37 PM, Chris Muller asqueaker@gmail.com wrote:
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
How about not downloading megabytes of data from the network when I didn't tell it to do that? Tim stumbled over the proxies in a completely different way than I did, and was similarly surprised at what happened. Proxies are a useful tool, but they should be kept in the bottom of the toolbox and only used in special circumstances. The vanilla image shouldn't have proxies.
Colin
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
How about not downloading megabytes of data from the network when I didn't tell it to do that?
There are lots of operations in the IDE that cause network accesses, and none of them advertise in advance that they'll access the network. So this argument is not really a good one against.
In fact, for it to happen with this, one _first_ had to explicitly tell it to stub it out! So assuming one knows what that means, and then subsequently "told" it to do something related to ancestry -- I think the software should be "impressive" more than surprising. :) It's simply doing what you told it, without question or hassles or interruptions or excuses why it can't. (although it may need a performance tweak),
Tim stumbled over the proxies in a completely different way than I did, and was similarly surprised at what happened.
Tim is surprised by everything. :)
Proxies are a useful tool, but they should be kept in the bottom of the toolbox and only used in special circumstances. The vanilla image shouldn't have proxies.
I think this is your best argument. I agree Proxies are a powerful tool to be used sparingly with deliberate care, but it basically boils down to using a become:, which we already use in numerous other places in the image.
On Wed, Apr 9, 2014 at 3:31 PM, Chris Muller ma.chris.m@gmail.com wrote:
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
How about not downloading megabytes of data from the network when I
didn't
tell it to do that?
There are lots of operations in the IDE that cause network accesses, and none of them advertise in advance that they'll access the network. So this argument is not really a good one against.
Good grief. If I click on something in the IDE, I've told it do something. Depending on what I click on, network access may be quite reasonable. I'm not going to be surprised if opening a repository inspector on a remote repository needs to download data from the network.
On the other hand, network access when you're using "chase pointers" is not expected. It's also surprising when "Smalltalk fixObsoleteReferences" starts downloading packages from SqueakSource.
Proxies are a useful tool, but they should be kept in the bottom of the toolbox and
only
used in special circumstances. The vanilla image shouldn't have proxies.
I think this is your best argument. I agree Proxies are a powerful tool to be used sparingly with deliberate care, but it basically boils down to using a become:, which we already use in numerous other places in the image.
Become is fine. The problem is #doesNotUnderstand:, combined with not subclassing Object. Operations like chasing pointers, which are normally safe, become decidedly unsafe when applied to these proxies. Again, they shouldn't be in the vanilla image.
On Wed, Apr 9, 2014 at 2:23 PM, Colin Putney colin@wiresong.com wrote:
On Wed, Apr 9, 2014 at 3:31 PM, Chris Muller ma.chris.m@gmail.com wrote:
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
How about not downloading megabytes of data from the network when I
didn't
tell it to do that?
There are lots of operations in the IDE that cause network accesses, and none of them advertise in advance that they'll access the network. So this argument is not really a good one against.
Good grief. If I click on something in the IDE, I've told it do something. Depending on what I click on, network access may be quite reasonable. I'm not going to be surprised if opening a repository inspector on a remote repository needs to download data from the network.
On the other hand, network access when you're using "chase pointers" is not expected. It's also surprising when "Smalltalk fixObsoleteReferences" starts downloading packages from SqueakSource.
+1
Proxies are a
useful tool, but they should be kept in the bottom of the toolbox and
only
used in special circumstances. The vanilla image shouldn't have proxies.
I think this is your best argument. I agree Proxies are a powerful tool to be used sparingly with deliberate care, but it basically boils down to using a become:, which we already use in numerous other places in the image.
Become is fine. The problem is #doesNotUnderstand:, combined with not subclassing Object. Operations like chasing pointers, which are normally safe, become decidedly unsafe when applied to these proxies. Again, they shouldn't be in the vanilla image.
-1. Proxies should be safe in the debugger and using chase pointers. We have the mirror primitives and these are used in the debugger and hence one can debug proxies. Chase pointers needs to be rewritten to use the mirror primitives too. IMO, a solid proxy implementation is a base facility.
On Wed, Apr 9, 2014 at 4:31 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
-1. Proxies should be safe in the debugger and using chase pointers. We have the mirror primitives and these are used in the debugger and hence one can debug proxies. Chase pointers needs to be rewritten to use the mirror primitives too. IMO, a solid proxy implementation is a base facility.
Agreed, that would be great. Until that happy day, though, these proxies cause problems.
Colin
Except for a proxy bug which needs fixed, I'd love to know how you would possibly improve it even if you could do so by the mere snap of your finger. Because I wanted the best of both worlds. I want 1) the ability to clean / reduce an image, 2) WITHOUT losing the ability to retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do a special UI operation to "retrieve the ancestry", just have the system retrieve it automatically please only if I do something in the IDE that requires it.
Again, assuming all the proxy-bugs fixed, what more could one want in terms of meeting all the demands we want as developers?
How about not downloading megabytes of data from the network when I didn't tell it to do that?
There are lots of operations in the IDE that cause network accesses, and none of them advertise in advance that they'll access the network. So this argument is not really a good one against.
Good grief. If I click on something in the IDE, I've told it do something. Depending on what I click on, network access may be quite reasonable. I'm not going to be surprised if opening a repository inspector on a remote repository needs to download data from the network.
On the other hand, network access when you're using "chase pointers" is not expected. It's also surprising when "Smalltalk fixObsoleteReferences" starts downloading packages from SqueakSource.
That's true, but those are just shallow bugs. I'm not willing to sacrifice chasePointers any more than am willing to sacrifice using Proxy's. That's why I make them work together, rather than restrict my toolbox.
On a related issue, whilst looking at preferences for Dave’s recent question, I spotted two puzzling options -
menuButtonToolInPane, which appears to have no users at all
traceMessages, which looks like it used to add an interesting option for message browsing but seems not to actually get used right now. If you turn it on, then you get MessageTrace browsers in response to cmd-m/n and so on, but the code in MessageTrace>browseAllCallsOn: (etc) doesn’t seem to be used. Even stuck breaks in there to see if I could catch it. That seems a pity; all that work to write MessageTrace and it can’t be used?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
traceMessages, which looks like it used to add an interesting option for message browsing but seems not to actually get used right now. If you turn it on, then you get MessageTrace browsers in response to cmd-m/n and so on, but the code in MessageTrace>browseAllCallsOn: (etc) doesn't seem to be used. Even stuck breaks in there to see if I could catch it. That seems a pity; all that work to write MessageTrace and it can't be used?
Dude, what are you talking about? That method is called, you didn't try hard enough.
traceMessages has worked since 4.1 or 4.2, at least. I can hardly use Smalltalk at all without it. If you think it doesn't work then you should just leave it on and see... :)
On 10-04-2014, at 11:34 AM, Chris Muller ma.chris.m@gmail.com wrote:
traceMessages, which looks like it used to add an interesting option for message browsing but seems not to actually get used right now. If you turn it on, then you get MessageTrace browsers in response to cmd-m/n and so on, but the code in MessageTrace>browseAllCallsOn: (etc) doesn't seem to be used. Even stuck breaks in there to see if I could catch it. That seems a pity; all that work to write MessageTrace and it can't be used?
Dude, what are you talking about? That method is called, you didn't try hard enough.
traceMessages has worked since 4.1 or 4.2, at least. I can hardly use Smalltalk at all without it. If you think it doesn't work then you should just leave it on and see... :)
I turn it on. I browse some selector’s implementations. A MessageTrace is built (I trapped that ok) but if I ask for implementors or senders of any method in the list I get a separate browser rather than the added methods in the same list. If I toggle break in MessageTrace>browseAllCallsOn: it never gets run.
Open a plain image straight out of a download. The preference is already set. Open a system browser and pick a method. Click on the ‘implementors’ button - the browser that opens has a model that is a MessageTrace. That seems to demonstrate that the preference is actually ‘true’. Click on ‘senders’ in the method browser & choose one of the menu of selectors. I expected to see the senders added to the method browser.
Looking at the code I see that the button’s selector is #browseSendersOfMessages, which is implemented in StringHolder. Following that seems to lead to #browseAllCallsOn: in SystemNavigation and not in MessageTrace.
Maybe I’ve just misunderstood how to use the facility. If using the obvious buttons and/or menu options isn’t the right way, what is? It may be a wonderful tool, but if I can’t work out how to get one, what use can I make of it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
The thing to learn is that the hotkey (ALT + m in Win on a selected method) reuses the window but the button open new ones. And for senders (ALT + N) you have to use the list and not the code pane.
Which I' reminded to every now and then because only very seldom I use the buttons.
Cheers,
Herbert
Am 10.04.2014 21:15, schrieb tim Rowledge:
On 10-04-2014, at 11:34 AM, Chris Muller ma.chris.m@gmail.com wrote:
traceMessages, which looks like it used to add an interesting option for message browsing but seems not to actually get used right now. If you turn it on, then you get MessageTrace browsers in response to cmd-m/n and so on, but the code in MessageTrace>browseAllCallsOn: (etc) doesn't seem to be used. Even stuck breaks in there to see if I could catch it. That seems a pity; all that work to write MessageTrace and it can't be used?
Dude, what are you talking about? That method is called, you didn't try hard enough.
traceMessages has worked since 4.1 or 4.2, at least. I can hardly use Smalltalk at all without it. If you think it doesn't work then you should just leave it on and see... :)
I turn it on. I browse some selector’s implementations. A MessageTrace is built (I trapped that ok) but if I ask for implementors or senders of any method in the list I get a separate browser rather than the added methods in the same list. If I toggle break in MessageTrace>browseAllCallsOn: it never gets run.
Open a plain image straight out of a download. The preference is already set. Open a system browser and pick a method. Click on the ‘implementors’ button - the browser that opens has a model that is a MessageTrace. That seems to demonstrate that the preference is actually ‘true’. Click on ‘senders’ in the method browser & choose one of the menu of selectors. I expected to see the senders added to the method browser.
Looking at the code I see that the button’s selector is #browseSendersOfMessages, which is implemented in StringHolder. Following that seems to lead to #browseAllCallsOn: in SystemNavigation and not in MessageTrace.
Maybe I’ve just misunderstood how to use the facility. If using the obvious buttons and/or menu options isn’t the right way, what is? It may be a wonderful tool, but if I can’t work out how to get one, what use can I make of it?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
I turn it on. I browse some selector's implementations. A MessageTrace is built (I trapped that ok) but if I ask for implementors or senders of any method in the list I get a separate browser rather than the added methods in the same list. If I toggle break in MessageTrace>browseAllCallsOn: it never gets run.
Open a plain image straight out of a download. The preference is already set. Open a system browser and pick a method. Click on the 'implementors' button - the browser that opens has a model that is a MessageTrace. That seems to demonstrate that the preference is actually 'true'. Click on 'senders' in the method browser & choose one of the menu of selectors. I expected to see the senders added to the method browser.
Ah, okay. Long-story short -- use the Command+n hot-key.
A little background. For a Trace to be useful, you can only browse senders of the method that is selected. If you select a different method, then that would be a new Trace, and so starting a new window is necessary.
But, I see that even selecting the top entry in that menu (the one that it selected) still opens a new window. That should be enhanced to call the same as the hot-key.
To trace inward, only swipe the code in the code pane and press Command+m. But if your code-pane is dirty you'll get a new window, of course.
When you get too many methods in the list, you can swipe a range of them and Command+d to remove them from the list. Typically, after browsing senders or implementors of something like #at: you'll have more than you want. A short-cut for paring all but the one(s) you want is, 1) select/swipe the one(s) you want to keep. 2) Press Command+Shift+I (capital letter "eye") to invert the selection at that level, followed by Command+Shift+d to remove the inverted selection.
Looking at the code I see that the button's selector is #browseSendersOfMessages, which is implemented in StringHolder. Following that seems to lead to #browseAllCallsOn: in SystemNavigation and not in MessageTrace.
Maybe I've just misunderstood how to use the facility. If using the obvious buttons and/or menu options isn't the right way, what is? It may be a wonderful tool, but if I can't work out how to get one, what use can I make of it?
Yes, that first choice in the menu should be checked for the traceMessages pref..
On 10-04-2014, at 12:49 PM, Chris Muller ma.chris.m@gmail.com wrote:
I turn it on. I browse some selector's implementations. A MessageTrace is built (I trapped that ok) but if I ask for implementors or senders of any method in the list I get a separate browser rather than the added methods in the same list. If I toggle break in MessageTrace>browseAllCallsOn: it never gets run.
Open a plain image straight out of a download. The preference is already set. Open a system browser and pick a method. Click on the 'implementors' button - the browser that opens has a model that is a MessageTrace. That seems to demonstrate that the preference is actually 'true'. Click on 'senders' in the method browser & choose one of the menu of selectors. I expected to see the senders added to the method browser.
Ah, okay. Long-story short -- use the Command+n hot-key.
Suggestion; change the help text in the preferences browser to make that a bit clearer. A useful tool that you can’t easily discover and use isn’t really there.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPM: Change Programmer's Mind
On Wed, Apr 9, 2014 at 1:27 PM, tim Rowledge tim@rowledge.org wrote:
It may be that Chris's technique for dumping the ancestry was less than perfect, but I'd say the real problem would likely be the ancestry code. Is there any plausible reason for a 'clean' image to have 9000 version-doohickeys taking up a couple of MB?
Sure. It's the same reason we ship 40MB of sources/changes files, rather than condensing sources frequently. This the revision history of the code in the image, and the fact that it's already there with no effort makes it easier to contribute to Squeak. That's helpful to newbies, and convenient for experienced developers.
It wouldn't be that hard to come up with a scheme for shipping the version history separately and loading it when needed, but nobody has found that important.
Colin
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Colin Putney -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
Herbert König -
tim Rowledge