Compiling lots of method source without debugger

Patrick Scherer wrote

Hello everyone,

This is my first time here so I hope this is the right place to ask
questions.

In an attempt to move lots of code from VA Smalltalk to Pharo, I need to
compile a lot of methods whose code may or may not work due to missing
classes in Pharo etc.
I want to be able to compile these methods programatically without
interruptions (using method source strings only) and gather all compiler
errors that occur. What would be the best way to go about this?

Also: How do I control in which package a compiled method ends up if the
target class is in a different package (Method extension)?

Any help would be greatly appreciated!

Kind regards,
Patrick Scherer

IIRC, Stephanne recently listed preservation of unloaded supers / extensions of unloaded classes as an area the INRIA group was working on, with a paper scheduled for ESUG, he might be able to help.

I also recently went through roughly the same to import VSE code (for inspection in Moose, not execution).
Can't say it was the best way, but I ended up creating a custom CodeImporter with several error/notification handlers around the "normal" loading code, and modifying the base system to raise said exceptions at appropriate places (rather than as currently, invoking dialogs directly)
For instance, a MissingClass notification in MethodChunk >> handleMissingBehavior, and a MissingPool from TClass >> #sharing:, (both with defaultAction implemented as per current dialog-raising behavior, so they work the same unless explicitly handled).

For my case, it was sufficient to have the handlers put classes/pools auto-generated by handlers in predetermined packages.

The biggest pain / time drain was dealing with creating instvars in autogenerated classes when referenced from imported code (ie in methods on classes with missing superclasses) so the analysis wouldn't treat them as unknown globals, so if you don't initially need that, I'd skip it.

I also did a compiler plugin to be able to rewrite certain selectors on import (mostly base class extensions from VSE clashing with existing implementations in Pharo), if you go that route, beware that the compiler doesn't really like you actually redefining source from outside an editor, and there will be some pains to have it store the correct(ed) source strings.

To create a method as an extension in Package MyX, you need to give it a categoriy of *MyX (with an optional -originalCategory suffix if you want that)

Good luck!

Cheers,
Henry

Hi,

> This is my first time here so I hope this is the right place to ask
> questions.

It is. :)

> I want to be able to compile these methods programatically without
> interruptions (using method source strings only) and gather all compiler
> errors that occur. What would be the best way to go about this?

It is certainly a way.

Compilation errors will raise SyntaxErrorNotifications that you can capture, e.g.

sthClass := Object subclass: #Something.
[ sthClass compile: '^^' classified: 'protocol-name' ]
        on: SyntaxErrorNotification
        do: [ :err | err inspect ]

> Also: How do I control in which package a compiled method ends up if the
> target class is in a different package (Method extension)?

Methods are stored in protocols (accessing, initialization, as yet unclassified).
If you however start the name with an asterisk *, then the method will become an extension method and will be stored in the package name following the asterisk.


e.g.

sthClass := Object subclass: #Something.
sthClass compile: 'methodName self lives somewhere else' classified: '*SomewhereElse'.

>
> Any help would be greatly appreciated!

I would (shameless self-promotion) also recommend looking at this https://github.com/peteruhnak/pharo-changes-builder , so you could review the changes before actually compiling them.

Peter

Hi Patrick

Welcome :)

> Hello everyone,
>
> This is my first time here so I hope this is the right place to ask
> questions.

Yes it is.

> In an attempt to move lots of code from VA Smalltalk to Pharo, I need to
> compile a lot of methods whose code may or may not work due to missing
> classes in Pharo etc.
> I want to be able to compile these methods programatically without
> interruptions (using method source strings only) and gather all compiler
> errors that occur. What would be the best way to go about this?

The compiler insfrastructure should be improved to stop "logging"
error by writing on the Transcript
but instead produce tractable objects representing error
(shadowing...). But this is not there yet.

To support your task and other scenario we worked on UndefinedClasses
The idea is to be able to load a class even if its superclass does not
exist and without losing information.

MCHttpRepository
   location: 'http://smalltalkhub.com/mc/StephaneDucasse/PetitsBazars/main'
   user: ''
   password: ''

Package UndefinedClasses

Let us know. We did several iterations but this may be still green.



> Also: How do I control in which package a compiled method ends up if the
> target class is in a different package (Method extension)?

In pharo the importer is based on *AAA => method in package AAA


> Any help would be greatly appreciated!

Another pattern that I used to load several versions of squeak into
VisualWorks a while ago was:

Capturing exceptions
Walking the stack to extract information
Compile on the fly the superclas
Resume

Now if you have a lot of code to load, may be it is worth to
extend/modify the parser/compiler to raise
better exceptions. If you do so, please let us know because we can
introduce your hook in Pharo.
Marcus is on vacation until 21 of August.
Any feedback to support better your scenario is precious to us. Now we
did not get the incentive
to push too much (besides the UndefinedClasses), but it is the occasion.

Stef


>
> Kind regards,
> Patrick Scherer