Hi Folks,
You read right, I'm going to talk about vaporware ;-). Well, not quite in fact, as some of you might on their computers something close to what I'd like to do, albeit in a different area : iTunes.
Specifically, I have played a bit with iTunes' "smart playlists", and I think something similar could be implemented for browsing code in squeak (the concept is not quite new in fact, these playlists are just requests to a database in disguise, such as "select all songs form artist X longer than 5 minutes that I have rated 4 stars of more").
You could then perform requests such as :
-tests : select all methods from package X, starting with "test" -non-tests : select all methods from package X, except those in "tests" -tested : select all methods in "non-tests", who are sent by methods in "tests" -hierarchy : select all methods from class X's hierarchy -recent : select the 50 latest methods accepted -private : select all methods from class C only sent by methods in C -protected : select all methods from class X only sent methods in C's hierarchy -public : select all methods in class X who are not in "private" or "protected" -undocumented : select all classes who's comment is nonexistant ;-)
The interface could be the one of a message list, maybe stealing iTunes' browser, which looks really a lot like a smalltak browser already ;-).
I think this kind of tool is currently missing as it could allow a much faster navigation in the system, as there is a lot of information that could be used this way.
Regular browsers, or stacked code panes like Whisker's ones could then be used to actually edit code ;-).
What do you think of that ?
Romain
On Monday 24 May 2004 07:52 am, Romain Robbes wrote:
Hi Folks,
You read right, I'm going to talk about vaporware ;-). Well, not quite in fact, as some of you might on their computers something close to what I'd like to do, albeit in a different area : iTunes.
Specifically, I have played a bit with iTunes' "smart playlists", and I think something similar could be implemented for browsing code in squeak (the concept is not quite new in fact, these playlists are just requests to a database in disguise, such as "select all songs form artist X longer than 5 minutes that I have rated 4 stars of more").
You could then perform requests such as :
-tests : select all methods from package X, starting with "test" -non-tests : select all methods from package X, except those in "tests" -tested : select all methods in "non-tests", who are sent by methods in "tests" -hierarchy : select all methods from class X's hierarchy -recent : select the 50 latest methods accepted -private : select all methods from class C only sent by methods in C -protected : select all methods from class X only sent methods in C's hierarchy -public : select all methods in class X who are not in "private" or "protected" -undocumented : select all classes who's comment is nonexistant ;-)
The interface could be the one of a message list, maybe stealing iTunes' browser, which looks really a lot like a smalltak browser already ;-).
I think this kind of tool is currently missing as it could allow a much faster navigation in the system, as there is a lot of information that could be used this way.
Regular browsers, or stacked code panes like Whisker's ones could then be used to actually edit code ;-).
What do you think of that ?
Sounds great to me, although I don't know why you would need to on another browser to edit. Perhaps when you click on a method or class declaration the browser could extend to show an editor pane (or just have the editor pane always available).
On May 24, 2004, at 11:17 AM, Jason Rogers wrote:
Sounds great to me, although I don't know why you would need to on another browser to edit. Perhaps when you click on a method or class declaration the browser could extend to show an editor pane (or just have the editor pane always available).
Actually I was thinking of having an editing pane at the bottom, but I wanted to let people use their favorite browser if they wish to do some extended editing. Another solution would be to steal whisker's stacking code to keep a working set of methods.
After the last update 5923, the instruction self halt did not work. With a new image, it's the same thing, "self halt" produces nothing. J-M Zajac
"jmzajac2002" jean-marie.zajac@laposte.net wrote:
After the last update 5923, the instruction self halt did not work. With a new image, it's the same thing, "self halt" produces nothing.
Damn. It seems to be some interaction between recent (post 5816) changes, probably to do with event handling and so on, and my primitiveYield; in a 5816 image enabling the prim works fine, post 5816 it prevents the debugger from opening.
The immediate fix is to withdraw the update but I suspect a proper fix is a bit more complex.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Managing programmers is like herding cats.
the update 5898 FixImplIn-gk from Göran Krampe is the problem. I don't understand why but this update makes that "self halt" does not work. A new update ?
Say guys, am I the only one who is NOT seeing this issue? "self halt" never stopped working for me so I'm slightly puzzled by what might possibly cause it on your systems to fail...
Cheers, - Andreas
----- Original Message ----- From: "jmzajac2002" jean-marie.zajac@laposte.net To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, June 01, 2004 6:08 PM Subject: Re: [BUG] self halt
the update 5898 FixImplIn-gk from Göran Krampe is the problem. I don't understand why but this update makes that "self halt" does not work. A new update ?
Andreas and others,
I have the same problem. Interestingly it seems to depend on the used VM: with
3.7b-5 #2 Fri May 28 22:37:32 CEST 2004 gcc 3.3.3 Squeak3.7beta of '1 April 2004' [latest update: #5868] Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-5/*.so
there is this problem, but with
3.6-3 #2 Wed May 12 03:17:53 CEST 2004 gcc 2.95.4 Squeak3.6 of '6 October 2003' [latest update: #5429] Linux karl 2.4.18 #6 Wed Apr 28 03:22:16 CEST 2004 i686 default plugin location: /usr/local/lib/squeak/3.6-3/*.so
not (starting the same image including the newest updates).
Greetings,
Stephan
Andreas Raab wrote:
Say guys, am I the only one who is NOT seeing this issue? "self halt" never stopped working for me so I'm slightly puzzled by what might possibly cause it on your systems to fail...
Cheers,
- Andreas
----- Original Message ----- From: "jmzajac2002" jean-marie.zajac@laposte.net To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, June 01, 2004 6:08 PM Subject: Re: [BUG] self halt
the update 5898 FixImplIn-gk from Göran Krampe is the problem. I don't understand why but this update makes that "self halt" does not work. A new update ?
Stephan Rudlof sr@evolgo.de wrote:
Andreas and others,
I have the same problem. Interestingly it seems to depend on the used VM: with
As I implied on the 26th of may, there is some interaction between the primitiveYield and a post-5878 update. If you run on a pre-3.7 vm the prim is not there and so there can't be any such interaction.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Had a head crash.
same here, never got this problem (update 5923)
Stef
Andreas Raab wrote:
Say guys, am I the only one who is NOT seeing this issue? "self halt" never stopped working for me so I'm slightly puzzled by what might possibly cause it on your systems to fail...
Cheers,
- Andreas
"jmzajac2002" jean-marie.zajac@laposte.net wrote:
the update 5898 FixImplIn-gk from Göran Krampe is the problem. I don't understand why but this update makes that "self halt" does not work.
Hmm, not at all what I see; if I revert the method Debugger>contextStackMenu:shifted: to the earlier version there's no change in halt behaviour. This is in a 5923 image on a 3.7b4 VM.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Caboose seems to be pulling the engine.
Tim,
Tim Rowledge wrote:
"jmzajac2002" jean-marie.zajac@laposte.net wrote:
After the last update 5923, the instruction self halt did not work. With a new image, it's the same thing, "self halt" produces nothing.
Damn. It seems to be some interaction between recent (post 5816) changes, probably to do with event handling and so on, and my primitiveYield; in a 5816 image enabling the prim works fine, post 5816 it prevents the debugger from opening.
The immediate fix is to withdraw the update but I suspect a proper fix is a bit more complex.
I'm working with the last VM for improving and testing the LargeIntegers plugin. Therefore I have problems now...
Do you - or any other one - plan to provide a fix in the near future? Otherwise - if it takes longer than a week or so (currently I'm busy with a mechanism for automatically switching external prim calls on and off and not with the plugin) - I vote for withdrawing the update until it works with the last VMs.
Greetings Stephan
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Managing programmers is like herding cats.
The immediate fix is to withdraw the update but I suspect a proper fix is a bit more complex.
Probably not. Just change one line in primitiveYield from:
(self isEmptyList: processList) ifFalse:[ self addLastLink: activeProc toList: processList. self wakeHighestPriority]
to:
(self isEmptyList: processList) ifFalse:[ self addLastLink: activeProc toList: processList. self transferTo: self wakeHighestPriority] ^^^^^^^^^^^^^^^^
and all should be fine.
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
The immediate fix is to withdraw the update but I suspect a proper fix is a bit more complex.
to:
(self isEmptyList: processList) ifFalse:[ self addLastLink: activeProc toList: processList. self transferTo: self wakeHighestPriority] ^^^^^^^^^^^^^^^^and all should be fine.
Yup, that'll do it ok. I even know how come it was wrong before - I transliterated the code from a primitive yield I wrote in 1989 (!) for the Acorn version of BrouHaHa. That vm handled the effect of transferTo: in the process checking and so had no transferTo analogue.
Testing the original version presuambly had no problems because of the lack of other processes at that priority. Just goes to show how important real testing is...
It'll be fixed in the next VMMaker release, which will be out quite soon.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: DPC: Double Precision Crash
Revised prim in development VMMaker. Dumb mistake. Remember not to steal my own old code without checking it really carefully.
Tim,
Tim Rowledge wrote:
...
Testing the original version presuambly had no problems because of the lack of other processes at that priority. Just goes to show how important real testing is...
Hmm, I've just worked with my actual image, not the worst testing for these kinds of bugs... After these updates the things had become weired.
Just working yourself in ST a short while with your newest changes (and these are central!) could avoid some pain ;-)
I say this also to myself, since the LargeIntegersPlugin changes have been quiet fast.
It'll be fixed in the next VMMaker release, which will be out quite soon.
Thank you: this sounds well!
Greetings Stephan
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: DPC: Double Precision Crash
Stephan Rudlof sr@evolgo.de wrote:
Just working yourself in ST a short while with your newest changes (and these are central!) could avoid some pain ;-)
Oh, I work with my latest changes in the VM all the time. How else could I test them? Don't forget that we've fairly dramatically changed the input event related processing since 5816, so that may have somethnig to do with why there was no problem then. Mind you, if you look for uses of #yield there aren't many that seem to have any relevance. But never mind - Andreas spotted the mistake and it's fixed.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: SDP: Search and Destroy Pointer
Stephan Rudlof sr@evolgo.de wrote:
Do you - or any other one - plan to provide a fix in the near future? Otherwise - if it takes longer than a week or so (currently I'm busy with a mechanism for automatically switching external prim calls on and off and not with the plugin) - I vote for withdrawing the update until it works with the last VMs.
So far as I can see it's not a VM bug per se; more an interaction with some process/signal related recent image update. For example, self halt works just fine in an MVC project. It works fine in a 5816 image.
The best candidate must surely be in the area around all the input process changes we've made recently. Right now though I really can't see how using a prim to do a yield instead of the image code could impact that. The interrupt key works ok. I note that even installing Anthony's latest context cleanup doesn't fix this one.
The short term answer is to rescind the 5909 update - but I don't get to do that, it's up to Doug.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Programming Department: Mistakes made while you wait.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Jason Rogers -
jmzajac2002 -
Romain Robbes -
Stephan Rudlof -
Stéphane Rollandin -
Tim Rowledge -
tim＠sumeru.stanford.edu