[Oberon] new symbol file
eas lab
lab.eas at gmail.com
Tue May 7 19:26:30 CEST 2013
I suddenly spotted the elusive "Display.Mod" mentioned while cleaning this out.
> > In ETHO, when a new variable is exported from SVGA.Display.Mod
> > and Compiler.Compile is applied, it yields this error.
> >
?! IIRC Display.Mod was the one that I couldn't find, and I claimed tha
it was 'hidden'. Except that I eventually found the LEO version.
G. Feldmann has also done a fine job of making the LEO files available.
> > arrow1 is new
> > pos 0 err 155 generation of new symbol file not allowed
> >
> > The \s option will allow the new variable in the interface of the
> > module, if that is the right terminology.
> >
> > Is recompilation of all modules importing Display.Mod essential?
> > For example, if the new variable is exported from SVGA.Display.Mod
> > but not used in Oberon.Mod and Oberon.Mod is not recompiled, will
> > the system be broken?
> >
Yes.
> > Auxilliary question: what exactly is "symbol file"? Just a synonym
> > for "object file"?
> Read section 12.6 'Searching the symbol table, and symbol files' in Wirth's
> 'Project Oberon' book for a thorough explanation. You will probably find the
> answer to your other question there as well.
>
> http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf
I disaprove of the wave of Twitter replies, so popular these days.
We should try to ADD-VALUE:-
The compiler generates 'machine' code AND the addresses of
items which are exported.
Modules which import these exports, don't nee to know the
machine-code of the exported procedures, just their addresses.
So for economy, these addresses of the exports can be made
available, in what is often called the symbol-file.
Clearly, any recompile which changes the location of any export,
will be disasterous for the importer, unless the <symbol file> is
updated.
Rather than being a twitterer, I want to pass on some example
of how powerfull the 'System.Execute' facility in LEO is:-
I wanted to see If/What/Where is Display.Mod
Obviously I did a: System.Directory
Since that found nothing, I called the heavy-artillery of *nix:
System.Execute locate Display.Mod
and 1 sec later, you see:
/home/Softwr/LEOmenu/Display.Mod
/usr/local/bin/V4/oberon-1.7.02/Source/Display.Mod
The first one is G. Feldmann's fetched version and the 2nd is from V4.
== Chris Glur.
PS. What advantage would I have from using UnixAos instead
of LEO? Can it do TLS email -- like for gmail?
PSS. Perhaps it wasn't obvious that the *nix:locate is all
done from the superior/familiar ETHO-screen/interface.
More information about the Oberon
mailing list