Compiling lots of method source without debugger
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
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 -- View this message in context: http://forum.world.st/Compiling-lots-of-method-source-without-debugger-tp495... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
participants (4)
-
Henrik Sperre Johansen -
Patrick Scherer -
Peter Uhnak -
Stephane Ducasse