[Oberon] Re: painfull edit/compile/run cycle !

eas-lab at absamail.co.za eas-lab at absamail.co.za
Sat Mar 1 17:52:29 CET 2003

> > How do I identify a module's callers, so that I can 
> > System.Free <client-list> , instead of  rebooting
> > for each edit/compile/run cycle  ?

Doug wrote:
> I usually create a file with a list of all the modules that are being 
> used for the current project on which I am working.  The list is ordered 
> from no dependency to maximum dependency so that 
> System.Free <selection> 
> will free all the working set modules.  I know the dependency since I 
> created the project. Some versions of free (Browser.Free?) do the 
> ordering for you.

OK. But I just want to wrap a 3 line routine in an existing module
of mine, to avoid file proliferation.   I have'nt got a list of it's callers,
and the matter is suposed to be trivial - not a 'project'.

John M. Drake wrote:
> System.ShowModules shows the list of currently loaded modules from
> the top down.  So I usually mark everything from the top down to
> the module I actually wish to unload and click the "Free" button.
> And you're right, before I figured this out that was quite painful.
> Also you might want to try Watson.ShowExports .  This worked on
> System 3 for Windows version 2.3, but not Plugin Oberon.

> That way you might unload even more modules than necessary.
> The reference count yields the number of modules that have 
> to be unloaded first before the module in case can be freed. 
> To find out which modules actually refer to the module in case 
> you easily check the loaded modules' import lists. It is not 
> necessary to take care of indirect imports because there would 
> be at least one directly importing module which has to be freed 
> first.

Yes, that's what I mean by 'painful'.
Why is this not automated ?

OK.  Desktops.OpenDoc  Popups.Tool ~   [System] > System.Free ^ 
tries to remove the selected set. But the listing sequence is chronological
not 'dependancy'.
Interestingly since I don't use Popups.Tool , it was near the top of the list
and trapped when I tries to free modules below it. eg. because it uses
ColorWells , Clocks. OTOH we see:
   ColorWells	7542	0
   Clocks	9771	0

This is confusing: I understand that the Popups.Tool panel can't 
remove the gadget which belongs to itself - whereas System.Free ^ 
can.  But why are ColorWells and Clocks ref-count shown as zero
while Popups.Tool panel is still 'alive' ?

Ulrich <whywouldyousendspam at microsoft.com> wrote:
> Rebooting! This is the best joke for a long time :-)

No. Re-booting takes a few seconds. Plus 10 seconds to find  & re-load
the needed frames.

OK let's automate this  often needed task ?
How does System.ShowModules know the reference count ?

PROCEDURE ShowModules*;
VAR M: Modules.Module; ..
  Texts.WriteInt(W, M.refcnt, 1);  Texts.WriteLn(W); <-- there's the refCount.

Watson.ShowDef Modules  ==
		Module  = Kernel.Module;
Kernel.Def  ->
		Module= POINTER TO ModuleDesc;    ->
		ModuleDesc= RECORD
			refcnt, sb: LONGINT;     <-- there's the refCount.

Without giving much though, I hoped for perhaps a linked-list of mod-names.
Apparently not.

Let's extend Watson ?

	PROCEDURE Imports;	(* writes import list to W *)
		VAR i, j: INTEGER; first, ln: BOOLEAN;
		PROCEDURE OutCmnt(cmnt: Cmnt);
	IF first THEN first:= FALSE; 
                        Keywords(cmnts.next, "IMPORT",mod[0].ln, TRUE)
	ELSE Char(",")
Or just let Watson export the "Imports" proc, and recursively use
it to list the dependancy tree - or is it a DAG ?

Who's going to do it ?  I'm busy these days.

-- Chris Glur.

PS. I found the caller modules by searching 
  *.Mod for  "<ModuleToBeReloaded>"  ,
but this is not good since the sources may not be available.

More information about the Oberon mailing list