FileContentsBrowser

Bijan Parsia bparsia at email.unc.edu
Mon Apr 23 04:47:31 UTC 2001


On Mon, 23 Apr 2001, Richard A. O'Keefe wrote:

> I asked about documentation for FileClassBrowser,
> and Bijan Parsia provided some.

You're welcome!

[snip]
> In the text pane, the yellow-button menu includes "show bytecodes"
> (just above "more...") but if you select it, you get 
> 	PseudoClass doesNotUnderstand: (a Message with selector:
> 	#compiledMethodAt: and arguments: #(#itemsForAnyFile))
> 
> You never know, it *might* have worked...  If it doesn't work, shouldn't
> that menu item be disabled or remove?

Yes. That's a bug, IMHO. This is due to the fact that the code pane is
just using #codePaneMenu:shifted: to generate the menu (rather than
generating a custom, tailored menu). If this wasn't a subclass of Browser,
we'd just get the default "flash" behavoir of StringHolder>>showBytecodes.

So, the simplest fix is to overrided #showBytecodes in
FileContentsBrowser, e.g.,:

showBytecodes
	"We don't actually have bytecode, so we shouldn't try to get it."

	^ self changed: #flash

Not the most enlightening response. It'd be nicer to have customized
menus. Bit more work.

On the other hand, we could still probably generate a bytecode listing for
what *would* be the compiled code, if it were compiled. Looking in
Browser>>contents gives this clue to bytecode display:

	editSelection == #byteCodes ifTrue:
		[^ (self selectedClassOrMetaClass compiledMethodAt: self
			selectedMessageName)
			symbolic asText].
Now we don't *have* any pre-compiledMethods in the PseudoClass, but it's
good to know about the "symbolic asText" bit.

So, if we can get a CompiledMethod of the method, we can extract the
bytecode listing. Of course, this means that we *shall* compile it, thus
we won't be *merely* browsing text, i.e., syntax errors will hurt. But
hey! If you're looking at bytecodes, you should be cool with that :)

The relevant factory method for CompiledMethod seems to be
#newMethod:header:, where the header is an index into the source
files. Which we don't have for this, or rather, don't want. And this is
just an allocating method. But what calls it? (cmd-N is your friend)

Ah, Compiler>>evaluate:in:to:notifying:ifFail: (it just *rolls* off the
tongue!). This is used by the various class side evalute methods (for
processing doits, for example) and thus has a null header, indeed, I see:

	method _ methodNode generate: #(0 0 0 0).

(MethodNode>>generate: turns ou to call #newMethod:header:, so if we can
get this far, we're golden. And to get this far, we just need a
MethodNode, which typically heads up a parse tree, which the Compiler can 
give us! Indeed, if we peek up #evalutate:in:to:notifying:ifFail: we see
how to do it.)

Ok, a little nip and tuck and we're done. First I add a helper method in
the FBC, edit pane protocal (modeled on selectedMessage):

selectedBytecode
	"Compile the source code for the selected message selector and
extract and return
	the bytecode listing."
	| class selector |
	class := self selectedClassOrMetaClass.
	selector := self selectedMessageName.
	contents := class sourceCodeAt: selector.
	contents := Compiler new
			parse: contents
			in: class
			notifying: nil. "This gives us the parse tree.
					A MethodNode heads it."
	contents := contents generate: #(0 0 0 0). "This generates
						the CompiledMethod"
	^ contents symbolic asText

Then we just change the bottom of FileContentsBrowser>>contents to:

...
     editSelection == #byteCodes ifTrue:
                [^ self selectedBytecode]. 
	^super contents

And voila, you can now do show bytecodes in the FileContentsBrowser. A
much more satisfactory ending than either deleting that menu item or just
making it "flash".

> "browse code" in a file list is really nice.  GREAT!
> It's such a fine tool that I'd like to know more about driving it.
> The "differences" are really nice.

Note that differences abound in the system, change browser, version
browser, etc.

[snip]
> It wouldn't let me change things.

Ok! That's definitely the next step. Really shouldn't be too hard.

> 	Ok!  There's a topic for a SqueakNewsletter article, and
> 	probably far more than Richard wanted :)
> 	
> Far LESS, actually.  

It was a joke. But here's some more (see above) anyway.

So Tansel, how about something like this for SqueakNews? "Undocumented
Corners"? ;)

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list