Am 10.12.2003 um 00:39 schrieb Doug Way:

>
> 1. Enter some code in a workspace (e.g. "3 factorial"), highlight it 
> and select "debug it" from the menu
> 2. A code simulation error occurs.  See stack below.  (Side note: we 
> should really include the debugger titlebar text (in this case, "Code 
> simulation error") in the "mail to list" debug text.)
>
> This happens in a fresh 5595 image, but didn't happen in a fresh 5526 
> image, so it's pretty recent.  May be related to SmaCC changes, I'm 
> not sure... If it's because we're still in the middle of those 
> changes, maybe it's nothing to worry about for now.
No, not directly related.

The offending method CompiledMethod>>methodNodeDecompileClass:selector: 
  was part of Changset 5308ContextCleanUp-ajh.

As Andreas said: going to the source-file for the class is very bad. I 
really wonder if we need this at all, the methods gets called
with a class, so why don't we simply omit the call to sourceClass?

methodNodeDecompileClass: aClass selector: selector
	"Return the parse tree that represents self"

	| source |
	^ (source _ self getSourceFromFile)
		ifNil: [self decompileClass: aClass selector: selector]
		ifNotNil: [self parserClass new parse: source class: aClass]



Hmm... generaly I'd really like to see some effort to clean up the 
whole source-handling.
Many of the reasons that lead back then to the design we have now are 
really not valid any
more... my 3-year old laptop has 320MB ram, not 320Kb ...

e.g. I would like to just save the whole source inside the image. it's 
only 4MB compressed, so
it adds just 1/3 to a standard image. So why not just have a "source" 
instvar in CompiledMethod?

I just don't care if my image is 16 or 20MB if I have ram in the 
hundrets of MB.

Or, if that's too large: The idea of having some stuff live on disk, 
some in ram could be generalised
to be usefull for all objects, be totally transparent and much more 
efficient. (c.f. the stuff Ted Kahler 25
years ago).

       Marcus

--
Marcus Denker marcus at ira.uka.de