Hi there,
During a coding party, a student caused a quite strange bug easy to reproduce in the stable squeak 3.7 :
In a workspace, LanguageEditor := Morph new. (for instance)
Yes I know, this is a non sense, but all is possible with beginners ! What surprised me is that it shouldn't work, but it works actually. So, then in a browser (tested with RB and System Browser), try to browse the class LanguageEditor -> Bug. And unfortunately, the bug message does not indicate to the beginner the nature of his error. Anyway I didn't manage to get rid of this bug.
Ideas ?
Samir
Samir>In a workspace, Samir>LanguageEditor := Morph new. (for instance)
Samir>Ideas ?
Constants are your friend.
Class globals should not be assignable using the normal syntax. One should be forced to code something like <(Smalltalk bindingAt: #LanguageEditor) setValue: Morph new.> (for example)--if that's what you really want to do.
Such devices would make it much more unlikely that beginners would know the necessary arcania to unsafely 'mess with the system' (that's a technical term.)
--Alan
"Samir Saidani" saidani@info.unicaen.fr wrote:
Hi there,
During a coding party, a student caused a quite strange bug easy to reproduce in the stable squeak 3.7 :
In a workspace, LanguageEditor := Morph new. (for instance)
This assignment destroys a class definition. The unpleasant thing is that after evaulation of the statement, LanguageEditor is still an entry in the system dictionary, but its value is not a class anymore. This causes the browser failure that you reported.
Anyway I didn't manage to get rid of this bug.
Destruction of a live-critical class will cause irreparable damage to your image. (Sounds like a warning on a cigarette box :-) ) I think you have to file in a complete change set for the destroyed definition to restore the image. Image restauration may be entirely impossible when you have destroyed a class that is really fundamental.
Ideas ?
It is perhaps desireable to have a paser that tells you that you should not assign a value to a class. Attached you find a very tentative attempt to do that, but frankly spoken, I hope that the maintainers of the compiler will say a word about such changes.
Gretings, Boris
FWIW, there was a period of time when the variable holding a class could not be written like this, for precisely the same error. I thought that was still the case, actually.
Mark Guzdial pointed out this lovely example, which new students do frequently:
myStuff := OrderedCollection new. "make a collection" myStuff add: 3. "put some stuff in it" OrderedCollection := nil. "okay, I'm done with the collection" This is a very easy mistake, quite similar to mixing up a sentence while speaking. I have mixed feelings on how to fix such things, though. On the one hand, I hate to see students stumble into mines like this. On the other hand, it is really nice that Squeak gives you access to everything, that everything is exactly what it looks like.
If I imagine a Squeak image that was set up to really allow (almost) arbitrary changes without destroying the system, it would be more like an operating system. It would have some sort of execution space, analagous to a process, and most work would take place outside of the "kernel" space. Doing "OrderedCollection := nil" in one of the spaces, would blow up the space, but then -- like in Self -- you could go to "Oz", another space, and debug the screwed up space from there.
But such a system, cool as it is, would lose the current coolness that Squeak is exactly what it looks like. Mark gets a gasp every time he does the "Line example" demo and shows that, yes, even though you see windows on the screen, you can still access the screen directly if you prefer and draw on top of everything. Occasionally he even gets someone to say "but... you can't do that!"
-Lex
"Lex Spoon" lex@cc.gatech.edu writes:
I have mixed feelings on how to fix such things, though. On the one hand, I hate to see students stumble into mines like this. On the other hand, it is really nice that Squeak gives you access to everything, that everything is exactly what it looks like.
Hi Lex,
Something important for me is that a beginner can figure out by itself what is the *nature* of an error (and not simply the error), and Squeak Debugger could say : "Hey, you can do that but you are binding the name of a class with an object, which is quite weird. But do what you want, guy :-) ". Then the student has a question to explore : why Squeak says to me that it is weird *to bind the name of a class with an object* ?
But at this point, the message is not understandable, Squeak only tells what you do is weird and the beginner is left with this poor question : why Squeak says to me that it is weird ?
Maybe could we modify the debugger to add a more user-friendly message (euh let's not say "just do it", we are exploring for the moment ;-). For instance, take the example you gave, I tried it and discover that OrderedCollection := nil become OrderedCollection value: nil and the debugger message says that this class method does not exist, but it's quite hard for a beginner to figure out that := become a class method, and the message "MessageNotUnderstood OrderedCollection class>> value:" is quite rough ! How can it relate the := and value: ? Note that if I replace OrderedCollection := nil by OrderedCollection value: nil, the error message are indistinguishable.
So I think that there is a finite numbers of typical misunderstanding from beginners, and allowing beginners understanding their own misunderstanding is a kind of bootstrap, I mean a bootstrap towards a feeling or insight of the language where the beginner is no longer a beginner ; and thus can figure out more deeply its own error without a beginner help. I feel that the debugger tool is the right tool to implement these views, but how ? Ideas ?
Regards, Samir
On 08-Feb-05, at AM 12:45, Samir Saidani wrote:
So I think that there is a finite numbers of typical misunderstanding from beginners, and allowing beginners understanding their own misunderstanding is a kind of bootstrap, I mean a bootstrap towards a feeling or insight of the language where the beginner is no longer a beginner ; and thus can figure out more deeply its own error without a beginner help. I feel that the debugger tool is the right tool to implement these views, but how ? Ideas ?
I'm not sure what kind of learning environment you are looking at (eg. a lone student exploring without guidance, etc), but I think for this specific case, just a simple FAQ document will do, no? -- HweeBoon MotionObj (65) 6764-9774
Yar Hwee Boon hboon@motionobj.com writes:
On 08-Feb-05, at AM 12:45, Samir Saidani wrote:
So I think that there is a finite numbers of typical misunderstanding from beginners, and allowing beginners understanding their own misunderstanding is a kind of bootstrap, I mean a bootstrap towards a feeling or insight of the language where the beginner is no longer a beginner ; and thus can figure out more deeply its own error without a beginner help. I feel that the debugger tool is the right tool to implement these views, but how ? Ideas ?
I'm not sure what kind of learning environment you are looking at (eg. a lone student exploring without guidance, etc), but I think for this specific case, just a simple FAQ document will do, no?
Mmm, sorry, I'm not clear. In fact, I'm interested in the general case : a beginner makes a mistake and the debugger tells it *clearly* what is the nature of the error (for instance, the debugger ask a question to the beginner "are you sure that you want really to do a binding ... ?). a FAQ assumes that you have a question, but the beginner (alone, without guidance) has no question at the point of its error, or more exactly, the poor question : "why there is an error ?" due to the lack of friendship (be understandable at the level of the beginner) of the debugger. The debugger assumes that you are a power smalltalker. The idea is that Squeak offer the beginner some questions to explore (and then -> FAQ).
On 08-Feb-05, at AM 02:42, Samir Saidani wrote:
Mmm, sorry, I'm not clear. In fact, I'm interested in the general case : a beginner makes a mistake and the debugger tells it *clearly* what is the nature of the error (for instance, the debugger ask a question to the beginner "are you sure that you want really to do a binding ... ?). a FAQ assumes that you have a question, but the beginner (alone, without guidance) has no question at the point of its error, or more exactly, the poor question : "why there is an error ?" due to the lack of friendship (be understandable at the level of the beginner) of the debugger. The debugger assumes that you are a power smalltalker. The idea is that Squeak offer the beginner some questions to explore (and then -> FAQ).
I was thinking more along the lines of having no code changes, instead just having a few tutorials, faqs including what to do and what not to do or to look out for. Anyway, perhaps you can also consider hooking into the parser/compiler, so that you can run "safe" code. ie. you can catch the assignment before the debugger is involved. Just a suggestion that, not sure if it might be more difficult to do.
-- HweeBoon MotionObj (65) 6764-9774
Some time ago a new class of variable binding was introduced (ReadOnlyVariableBinding, a subclass of LookupKey) so that global class names could be 'protected' in the Smalltalk global dictionary. The classes around at that time appear to have been converted to use of it. However, a load of new classes still have plain old Associations and are thus not protected in this manner. I guess the compiler related code wasn't altered; another unfinished job.
Try Smalltalk associations select:[:assn | assn class ~= ReadOnlyVariableBinding] to see a list of the classes not protected. I find 671 in a 3.8-6527 image I've done a bit of fiddling in, along with 1128 that are protected.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Result of a first cousin marriage.
squeak-dev@lists.squeakfoundation.org
-
Alan Lovejoy -
Boris Gaertner -
Lex Spoon -
Samir Saidani -
Tim Rowledge -
Yar Hwee Boon