[Oberon] Doubt from Project Oberon book.
Aubrey.McIntosh at Alumni.UTexas.Net
Aubrey.McIntosh at Alumni.UTexas.Net
Sun Dec 23 18:02:39 CET 2012
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).
Oberon is not like anything else you have ever used. Like Drambuie, people
decide they hate it or love it without much uncertainty. Those of us
active on the list like it very much.
On Sun, Dec 23, 2012 at 10:48 AM, Srinivas Nayak
<sinu.nayak2001 at gmail.com>wrote:
> Dear Bob,
> Many thanks for making my doubt clear.
> Now I am able to see the whole idea.
> so the contents of
> their variables are still available and other modules can use them
> However, if somebody unloads the previous module before second command
> Or this case is not possible?
> With thanks and best regards,
> Yours sincerely,
> Srinivas Nayak
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
> Bob Walkden wrote:
> > He is describing some ways in which different software components can
> > communicate with each other.
> > In a system such as Unix, you execute a command by typing its name and
> > parameter list at the command line, and pressing<Enter>. The command can
> > pipe its result to another command, which is executed immediately after
> > first command. On completion of a command it is unloaded from memory and
> > contents of its variables are lost. If you want to use the command's
> > later, ie not immediately after you have executed the command, then you
> > to store the results in a file.
> > Oberon commands do not come with a built-in pipe mechanism. However,
> > modules are not automatically unloaded following execution - they remain
> > resident in memory until you unload them explicitly, so the contents of
> > their variables are still available and other modules can use them,
> > as global variables or by calling one of the module's procedures. This
> > that you don't have to use pipes / files to communicate between modules.
> > Of course if you want to retain the values between system restarts you do
> > have to store them in files.
> > B
> >> -----Original Message-----
> >> From: Srinivas Nayak [mailto:sinu.nayak2001 at gmail.com]
> >> Sent: 23 December 2012 08:03
> >> To: ETH Oberon and related systems
> >> Subject: [Oberon] Doubt from Project Oberon book.
> >> Dear All,
> >> From the book, Project Oberon, I read,
> >> 2.2.2. Commands
> >> The parameter text must refer to objects that exist before command
> >> execution starts and are quite likely
> >> the result of a previous command interpretation. In most operating
> >> systems, these objects are files
> >> registered in the directory, and they act as interfaces between
> >> commands. The Oberon System broadens
> >> this notion; the links between consecutive commands are not
> >> restricted to files, but can be any global
> >> variable, because modules do not disappear from storage after
> >> command termination, as mentioned
> >> above.
> >> What is the meaning?
> >> I couldnt understand this.
> >> Also I found that, this book uses technologies/terminologiesof 1980s
> >> which make things bit difficult to understand, for us who are used to
> >> with latest technologies/terminologies. Example, RAM/Memory is referred
> >> as "store".
> >> With thanks and best regards,
> >> Yours sincerely,
> >> Srinivas Nayak
> >> Home: http://www.mathmeth.com/sn/
> >> Blog: http://srinivas-nayak.blogspot.in/
> >> --
> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> >> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
Aubrey McIntosh, Ph.D.
211 E. 5th St.
Morris MN 56267
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon