#oxxi ram full message
21 messages in this thread
I downloaded the chaoss.arc file and tried to compile chaoss.mod from the EMACS
editor in Benchmark. After fiddling with the heap size, I was able to get the
program to compile with no errors, but when I went to link I was told that it
could not open chaos.obj file. (I had set the output of obj to go to ram:progs
directory.) When I try to compile again (after remembering to set the cd to
ram:progs) I only get to about line 13 and get a Volume RAM is full requestor.
Can anyone tell from this where my error is?
Thanks.
// Jim
Jim,
I'm not sure, but I think that the new OBJ file is written separately before
the old one is erased. Try deleting the existing one first.
Regards, Larry.
Thanks, Larry.
I am still kinda confused by Benchmark. I hope the final release of the
documentation is clearer and perhaps aimed at first-time folks too.
I just discovered with ICON that the trick is to cd to the place where the
.icn program is and then invoke the icnontranslation program with a path name.
That way, I can have the programs in their own directories and the Icon system
in its own.
I imagine once I either stumble across or am told exactly what the steps are
in Benchmark it will all seem obvious, but it isn't at this point.
I hope some kind person will upload an introduction.
// Jim
Jim – You mentioned you got a RAM: disk full. It would seem possible that was
the case. Depending on how much you have in memory, and how fragmented it's
become, you may not be able to write more to RAM:.
I guess I should have considered that obvious possibility. Maybe I was thrown
by the absence of a colon after the word RAM in the message. I will try again
with m2l on disk to see what happens.
What is a DEF file? Suppose you have a module that works–lets say it reads
the mouse or something–how do you incoroporate it in a program? Do you put
all the working modules in the source and compile the whole thing? Someone on
another net told me to let the compiler and linker find it, but I do not
understand that. Does that mean that a Modula program consists of a bunch of
programs or does it just mean that they are all in the same directory when you
invoke the comipler.
Also, what is an OBJ file? Can you erase it after the execuatble program
with no extension is createed?
Thanks. (Sorry for the typos.)
// Jim
Jim,
There are a few kinds of files in M2 that are identified with extensions.
Most compilers recognize these extensions, and in fact require them for proper
operation. This is right off the top of my head, and I hope it's right. The
extensions are .DEF, .SYM, and .OBM
DEF modules are DEFinition modules. When you write one, you are laying out the
specifications of the module you want to compile. When you compile it, it will
generate a .SYM file. The .SYM file contains the information you put into the
.DEF file, but in a more compact form, suitable for the compiler to read. At
compile time, the compiler looks in the .SYM file for the DEFinitions of any of
the identifiers you IMPORTed in order to be able to do its type checking. The
.DEF file is normally kept as a human readable definition of the module, and
may be freely passed on to other programmers who will be using the module. This
can be done with no worries about the other programmer mucking about with a
module and causing problems of compatibility.
The IMPLEMENTATION module, when compiled, produces a .OBM module that is read
by the linker, and contains tha actual code to be generated for the functions
included in the module. Note that you must compile the .DEF module before
compiling the IMPLEMENTATION module.
So, here's how… Write the DEFinition and IMPLEMENTATION module (.MOD). Write
a MODULE (another .MOD) to test the .SYM/.OBM modules produced. Compile the
.DEF module, then the IMPLEMENTATION module, then the MODULE itself. Link the
.OBM module resulting from the compilation of the MODULE, and the output will
be a program that will, we hope, work.
more to come….
Cont….
As for the compiler and linker "finding" the files, that's what the ASSIGN is
for. You tell the system where to look for files it needs. They can also be in
the current dir, and I think they can be in multiple directories by specifying
subsequent dir in the editor (in Benchmark), but I'm not sure.
A "good" M2 program normally has a faily small main MODULE that IMPORTs
functions from a lot of other small modules that are compiled and ready to be
linked.
Regards, Larry.
Thanks, Larry.
Your explanation was clear and helpful. I am slowly getting the hang of the
system.
BTW–I am amused to see all the hoopla in InfoWorld and BYTE about Microsoft
QuickBASIC 4.0. These guys are awe stricken; it has what COMAL for the 64 has
had for years. O well.
// Jim
Jim,
Glad the explanations helped.
Of course they are awe stricken. This is a common happening in the computer
biz, where authors tend to ignore any ideas that fall outside their own narrow
circles. If you think they are awestricken now, wait til they discover
multitasking, lots of colours, blitters, coprocessors, shared libraries, etc.
Of course we will be hearing all about how <Apple | IBM> invented all these
marvels. <sigh>
Regards, Larry.
This reminds me of something that occured while I was visiting a Computerland
just after IBM introduced the microcomputer to the world. I had been chatting
with the owner when a real customer came into the store. After checking out
all the advances of the "new" IBM PC (with 16 K and cassette input) he began to
look over an Apple II plus. After a few minutes, the customer commented how
unfair it was that IBM should bring out a great new product idea like the
microcomputer and right away, some small company comes out with the same thing.
AAAAAARRRRRRRRG!!!!!!
<Sobbing into folded arms on the desktop>
Rick
Larry – For most programs, though, I feel that keeping all the source in one
file helps to maintain clarity. I have a little trouble, for example, with some
of the source files I've dl'd that are so split up into seperate modules that I
can't follow what's being done. I tend to think of compiling seperate modules
for those TYPEs and PROCEDUREs that I feel will be re-usable in a variety of
programs. Most of the Modula-2 text extoll the virtues of seperate compilation
explaining how well they hide the implementation details from the programmer.
Personnally, I'd rather not have all the details hidden from me.
Erv,
You are definitely right about having the appropriate stuff for that program
in the file if you are one who likes to see everything in the source, and to
compile separately only the "reusable" modules. Best part of M2 is that you
have the choice. Compiling into separate modules also has its advantages in
terms of putting the already done parts out of the way to be called as if they
were library routines. To each his own.
Regards, Larry.
The other side of the issue comes in when tweaking programs. Why have to do
the big compile when you can just compile a much smaller module and then
re-link. Of course, one can take this to extremes. Let reason prevail.
..Bob
Seperate compilation is definitely important when one is working on larger,
commercial quality programs such as you've done. Most of the things I do tend
to be self-tutorials and amount to very few lines of code. The biggest source
file I've originated amounts to about 600 lines of code; not very much compared
to serious programs. And with my present set-up, i.e. no hard drive and limited
ram, compiles take so long I just go do the dishes or do some other trivial
task while the programs compiling. Oh well….
If you use EMACS, you shouldn't have a problem with keeping track of code in
separate modules, as you can load all the pertinent modules into Emacs buffers
and search for the desired stuff. I definitely think that splitting things
(logically of course) into module helps you create better code in the long run.
It also forces you to think about the overall design of your program.
– Steve –
Jim,
One partial solution for you would be to leave Benchmark's libraries on
floppy (in df1: let's say). Benchmark isn't too slow in the initial link, but
if (when) you must re-edit and re-link the Libraries that you just used will be
pulled out of FACCII's RAM. It will save you a LOT of room, and is not that
much more inconvenient.
cat/des
Lloyd
Thanks Lloyd. I have indeed stopped putting the libs in ram. It saves me the
initial time it takes to get them there, solves the ram full problem, and
causes no problem since I am just starting to 'learn and the programs I compile
are teeny-tiny ones.
// Jim
Jim,
Show up Saturday night starting sometime between 7PM and 8PM PST on the CO
for the Modula-2 group. rooM-2, of course.
Thanks for the tip, Vic. I will try to make it.
Data Hiding is not meant to hide details from YOU but to protect YOUR details
from ignorant or malicious (anti-social) members of a large (i.e. more than
one) programming team. Seems to work too.