[Oberon] Unloading a project

Aubrey.McIntosh at Alumni.UTexas.Net Aubrey.McIntosh at Alumni.UTexas.Net
Mon Dec 24 22:59:04 CET 2012

I do the inverse problem, create a correct compile list from a seed list of

I build a job list from all the parameter file names.
I enumerate the job list.
I scan the IMPORT statement of the next file.
I build standard file names from all the imported modules and add them to
the job list.
Then I enumerate the internal data structure and write a correct compile
order list.

I can seed the list with library files first, such as  AlmGather.Order
Oberon.Mod MyModule.Mod ~
Then all the Oberon dependencies are compiled before the remaining modules
that are unique to MyModule.

On Mon, Dec 24, 2012 at 3:44 PM, Douglas G. Danforth <
danforth at greenwoodfarm.com> wrote:

> On 12/23/2012 9:02 AM, Aubrey.McIntosh at Alumni.UTexas.Net wrote:
> > There is a command, System.Free, that will unload a module.  Normally
> > it is not used, only when debugging a module.
> > This is really powerful.  You can use everything in the system as it
> > is, while unloading only 1 module (and any modules that call it).
> >
> In BlackBox, for my own convenience, I wrote a module called MyProject
> what allows me to specify a single root module from which I can compile
> all dependent modules and unload all dependent modules.  This is useful
> if one modifies a module somewhere in the hierarchy and then needs to
> test the result (hence all modules need to be unloaded).  MyProject
> scans the IMPORT lists of all modules starting at the root.  It excludes
> BlackBox system modules.
> -Doug Danforth
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

Aubrey McIntosh, Ph.D.
211 E. 5th St.
Morris MN 56267
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20121224/cd2e09b5/attachment.html 

More information about the Oberon mailing list