Inform 7: How Raise Inform 7 Limits Above a 'Limit Bug?'
Zero
to use the GBLORB format for the Glulx interpreter [specifically
Windows Glulxe 0.4.5 (Windows Glk 1.37) ] due to it's enhanced
features--namely it's space.
The enormous problem I'm facing now is that progress has been halted
by an "Out of Memory" error. I've thoroughly researched the
documentation and example files on how to raise the limits on the prop
tables, etc. Here are the memory enhancements and the extensions I'm
using in my Inform 7 program:
Include Locksmith by Emily Short.
Include Punctuation Removal by Emily Short.
Include Basic Screen Effects by Emily Short.
Include Menus by Emily Short.
Include Basic Help Menu by Emily Short.
Include Simple Followers by Emily Short.
Include Armed by David Ratliff.
Include Glulx Boxed Quotation by Eliuk Blau.
Use American dialect and the serial comma.
Use full-length room descriptions.
Use undo prevention.
Use MAX_PROP_TABLE_SIZE of 70000.
Use MAX_ZCODE_SIZE of 70000.
Use memory economy.
There are two additional directives that are supposed to help from the
manual but when I use them, it causes Inform 7 to crash with the same
'prop table exceeded' error. Figure out why. Maybe the 'at least'
statement isn't high enough. Here are the two additional directives
I'm not using due to that:
Use dynamic memory allocation of at least 16384.
Use maximum indexed text length of at least 2000.
Perhaps they were conflicting with one of the directives above? In any
event I should be able to continue to raise the prop tables, but when
I put in a larger, number, I'm getting the same error. My GBLORB file
is only 1.17 MB; my Inform folders for this project are 11.0 MB
(11,587,285 bytes) with 13.8 MB (14,516,224 bytes) on the disk.
According to Chapter 2 of the Inform 7 documentation, "Glulx has a
huge capacity, so we need never worry about size limits again." In
Chapter 19.2. Memory limitations with indexed text, is speaks of
Glulx, "Glulx story files have the advantage here that, if they find
themselves running on version 3.1.0 or later of the Glulx machine,
they can use Glulx's new memory allocation features to grow their own
memories as necessary, so that there are no hard limits at all."
So, if anyone out there can help me properly raise the limits of part
I so I can get to part II, I'd really appreciate it. I'm probably in
over my head in programming as it is. Thank you! :)
-Zero
Below is the exact error Inform 7 gives me:
Translating the Source - Inform 6 ran out of memory
The application ran your source text through the Inform 7 compiler, as
usual, and it found no problems translating the source as far as a
sort of intermediate-level code - a program for Inform 6, which would
ordinarily then be used to make the final working IF.
Unfortunately, the program must have been too demanding for Inform 6
to handle, because it reported that one of its memory settings had
been broken. These are upper limits, usually on the number of things
of a particular sort which can be created, or on the amount of memory
available for a given purpose.
To get around this, look at the actual output produced by Inform 6 to
see which memory setting was broken. For instance, suppose it said:
The memory setting MAX_PROP_TABLE_SIZE (which is 30000 at present) has
been exceeded.
You then need to amend your Inform 7 source text to take account of
this, by adding a sentence like the following:
Use MAX_PROP_TABLE_SIZE of 50000.
With sentences like this, you can make Inform 6 raise its limits until
there's no longer any problem: see Chapter 2 of the documentation.
Sorry for the inconvenience.
Adam Thornton
Zero <zero.o...@gmail.com> wrote:
>I've been working on an IF7 RPG project for some time now; I decided
>to use the GBLORB format for the Glulx interpreter [specifically
>Windows Glulxe 0.4.5 (Windows Glk 1.37) ] due to it's enhanced
>features--namely it's space.
>
>The enormous problem I'm facing now is that progress has been halted
>by an "Out of Memory" error. I've thoroughly researched the
>documentation and example files on how to raise the limits on the prop
>tables, etc. Here are the memory enhancements and the extensions I'm
>using in my Inform 7 program:
>
>Translating the Source - Inform 6 ran out of memory
>The application ran your source text through the Inform 7 compiler, as
>usual, and it found no problems translating the source as far as a
>sort of intermediate-level code - a program for Inform 6, which would
>ordinarily then be used to make the final working IF.
There's nothing on the error tab explaining *where* I6 ran out of
memory?
Adam
Otto Grimwald
On 07/01/2010 00:30, Zero wrote:
>
> To get around this, look at the actual output produced by Inform 6 to
> see which memory setting was broken. For instance, suppose it said:
>
And what is this panel saying?
you should add the one found according to this error.
If it can help you, here are some options I generally set (even if my
games are not that huge):
Use MAX_VERBSPACE of 8000.
Use MAX_PROP_TABLE_SIZE of 60000.
Use MAX_ZCODE_SIZE of 60000.
Use MAX_ARRAYS of 1500.
Use MAX_CLASSES of 200.
Use MAX_VERBS of 254.
Use MAX_STATIC_DATA of 135000.
Use MAX_INDIV_PROP_TABLE_SIZE of 20000.
Use MAX_DICT_ENTRIES of 1600.
Zero
> In article <3389dd5f-22a4-40bd-99f5-ae9a4cc55...@s31g2000yqs.googlegroups.com>,
>
> - Show quoted text -
Adam,
The errors tab displays:
Translating the Source - Inform 6 ran out of memory
The application ran your source text through the Inform 7 compiler, as
usual, and it found no problems translating the source as far as a
sort of intermediate-level code - a program for Inform 6, which would
ordinarily then be used to make the final working IF.
Unfortunately, the program must have been too demanding for Inform 6
to handle, because it reported that one of its memory settings had
been broken. These are upper limits, usually on the number of things
of a particular sort which can be created, or on the amount of memory
available for a given purpose.
To get around this, look at the actual output produced by Inform 6 to
see which memory setting was broken. For instance, suppose it said:
The memory setting MAX_PROP_TABLE_SIZE (which is 30000 at present) has
been exceeded.
You then need to amend your Inform 7 source text to take account of
this, by adding a sentence like the following:
Use MAX_PROP_TABLE_SIZE of 50000.
With sentences like this, you can make Inform 6 raise its limits until
there's no longer any problem: see Chapter 2 of the documentation.
Sorry for the inconvenience.
Thanks for responding. :)
Zero
Zero
Otto,
Thanks for your suggestions. I'll try that and see if it helps
any. Many, many thanks. :) Have a fantastic day! :)
Thanks again,
Zero
Zero
Otto,
I tried adding those "Use" statements and again hit upon the same
problem with the last two. I had to comment them out and take out my
addition of a woman in a room and then it compiled. I can't add any
new people or objects to the game it seems without it giving the above
error.
Here are the "Use statements" I'm using at the beginning of the
program now:
Include Locksmith by Emily Short.
Include Punctuation Removal by Emily Short.
Include Basic Screen Effects by Emily Short.
Include Menus by Emily Short.
Include Basic Help Menu by Emily Short.
Include Simple Followers by Emily Short.
Include Armed by David Ratliff.
Include Glulx Boxed Quotation by Eliuk Blau.
Use American dialect and the serial comma.
Use full-length room descriptions.
Use undo prevention.
Use MAX_PROP_TABLE_SIZE of 60000.
Use MAX_ZCODE_SIZE of 60000.
Use MAX_VERBSPACE of 8000.
Use MAX_ARRAYS of 1500.
Use MAX_CLASSES of 200.
Use MAX_VERBS of 254.
Use MAX_STATIC_DATA of 135000.
Use MAX_INDIV_PROP_TABLE_SIZE of 20000.
Use MAX_DICT_ENTRIES of 1600.
Use memory economy.
[!
Use dynamic memory allocation of at least 16384.
Use maximum indexed text length of at least 2000.
]
----------------------------------------------------------------------------------------
My natural inclination is to try to raise some of these higher, but
without knowing the limits I'm not sure if that will help or hurt.
When it raised it to 70000, it complies but I still run into the same
error when I try to add the woman in a room with the same error above.
Only by taking out the woman and not adding any new objects does it
work. And I'm trying to finish some puzzles for part I. If anyone has
any suggestions...
Thanks,
Zero
Andrew Plotkin
>
> My natural inclination is to try to raise some of these higher, but
> without knowing the limits I'm not sure if that will help or hurt.
> When it raised it to 70000, it complies but I still run into the same
> error when I try to add the woman in a room with the same error
> above.
With MAX_PROP_TABLE_SIZE, just keep cranking it up. If 70000 isn't
enough, try 100000. Or 200000.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Adam Thornton
Zero <zero.o...@gmail.com> wrote:
>To get around this, look at the actual output produced by Inform 6 to
>see which memory setting was broken. For instance, suppose it said:
>
>
>The memory setting MAX_PROP_TABLE_SIZE (which is 30000 at present) has
>been exceeded.
>You then need to amend your Inform 7 source text to take account of
>this, by adding a sentence like the following:
>
>
>Use MAX_PROP_TABLE_SIZE of 50000.
>With sentences like this, you can make Inform 6 raise its limits until
>there's no longer any problem: see Chapter 2 of the documentation.
>
>
>Sorry for the inconvenience.
>
>Thanks for responding. :)
There should have been something *somewhere* in the output which told
you what blew up.
How much memory does the actual computer itself have?
Adam
Zero
> In article <35a58ef2-3973-4430-b2ff-16336579f...@j5g2000yqm.googlegroups.com>,
>
> - Show quoted text -
Adam,
The actual pc has 2.00 GB of Memory(RAM) and a 32-bit operating system.
Zero
Andrew,
Thanks for responding. Otto's response did fix the bug for adding new
items not characters, or people per se, but this should fix the
latter. Your answer gives me an idea for the upward threshold for the
format; I'm assuming that also applies to the lesser things like
MAX_VERBS and MAX_CLASSES, etc. I just implemented your advice and
hopefully shouldn't have any more issues with this post. Thank you
again, and thanks to everyone who responded!
Sincerely,
Zero
Tatiana
to just set these really, really high for Glulx such that it's
unlikely to ever come into play. This reminds of when I worked on
software where the timeout setting was too low. (This was a feature
where there was really no need for a timeout, but it was built into
the framework.) So a change was made to make it a little higher. Then
it was still low. So a change was made to make it a little higher. And
then a little higher again when the problem surfaced. What really
worked was just setting it to a really high value such that it was
very, very unlikely anyone would hit the problem during any sort of
conceived of usage.
Andrew Plotkin
> Why should users even have to worry about this crap?
No good reason. But updating the I6 compiler to support reallocable
storage buffers would be a lot of work, and nobody's done it.
Andrew Plotkin
> Here, Tatiana <tatma...@yahoo.com> wrote:
> > Why should users even have to worry about this crap?
>
> No good reason. But updating the I6 compiler to support reallocable
> storage buffers would be a lot of work, and nobody's done it.
By the way, when I say "no good reason", I'm not dissing Graham or
anybody else. I mean something specific:
This change (removing the MAX_PROP_TABLE_SIZE limit, and other such I6
compiler size options) would only require changes to one program --
the I6 compiler. It would not have to be coordinated with interpreter
changes, I7 changes, or changes to the I6 language, Z-code spec, or
Glulx spec.
That's the easiest kind of change. There are no reasons against it
*except* the labor itself. Unfortunately, that's significant.
(My point is, other sorts of Inform platform improvements are
exponentially more complicated to achieve, *aside* from the
development work involved.)
James Jolley
> Here, Tatiana <tatma...@yahoo.com> wrote:
>> Why should users even have to worry about this crap?
>
> No good reason. But updating the I6 compiler to support reallocable
> storage buffers would be a lot of work, and nobody's done it.
>
> --Z
I see what you're saying about this, but what about just adding in a
shed load of use options within the standard rules? Perhaps I'm
completely clueless but that might help those with issues?
Andrew Plotkin
> On 2010-01-08 00:23:36 +0000, Andrew Plotkin <erky...@eblong.com> said:
>
> > Here, Tatiana <tatma...@yahoo.com> wrote:
> >> Why should users even have to worry about this crap?
> >
> > No good reason. But updating the I6 compiler to support reallocable
> > storage buffers would be a lot of work, and nobody's done it.
>
> shed load of use options within the standard rules?
There are. Take a look.
Use MAX_ARRAYS of 1500.
Use MAX_CLASSES of 200.
Use MAX_VERBS of 255.
Use MAX_LABELS of 10000.
Use MAX_ZCODE_SIZE of 50000.
Use MAX_STATIC_DATA of 120000.
Use MAX_PROP_TABLE_SIZE of 200000.
Use MAX_INDIV_PROP_TABLE_SIZE of 20000.
Use MAX_STACK_SIZE of 65536.
Use MAX_SYMBOLS of 20000.
Use MAX_EXPRESSION_NODES of 256.
James Jolley
I wonder why there are so many issues then? Even with those settings
most projects should be fine surely?
I don't know - I'll get my coat then.
Best
-JAmes-
mwigdahl
> On 2010-01-08 02:38:57 +0000, Andrew Plotkin <erkyr...@eblong.com> said:
>
>
>
> > Here, James Jolley <jrjol...@me.com> wrote:
> >> On 2010-01-08 00:23:36 +0000, Andrew Plotkin <erkyr...@eblong.com> said:
>
> >>> Here, Tatiana <tatmasl...@yahoo.com> wrote:
> >>>> Why should users even have to worry about this crap?
>
> >>> No good reason. But updating the I6 compiler to support reallocable
> >>> storage buffers would be a lot of work, and nobody's done it.
>
> >> I see what you're saying about this, but what about just adding in a
> >> shed load of use options within the standard rules?
>
> > There are. Take a look.
>
> > Use MAX_ARRAYS of 1500.
> > Use MAX_CLASSES of 200.
> > Use MAX_VERBS of 255.
> > Use MAX_LABELS of 10000.
> > Use MAX_ZCODE_SIZE of 50000.
> > Use MAX_STATIC_DATA of 120000.
> > Use MAX_PROP_TABLE_SIZE of 200000.
> > Use MAX_INDIV_PROP_TABLE_SIZE of 20000.
> > Use MAX_STACK_SIZE of 65536.
> > Use MAX_SYMBOLS of 20000.
> > Use MAX_EXPRESSION_NODES of 256.
>
> > --Z
>
> I wonder why there are so many issues then? Even with those settings
> most projects should be fine surely?
>
> I don't know - I'll get my coat then.
>
> Best
>
> -JAmes-
I'm guessing that most of these are set low enough to keep .z5
projects at least theoretically possible under I7. I wonder if there
should be separate sets of default settings in the Standard Rules for
Z-machine vs Glulx projects?
Matt
Andrew Plotkin
> On Jan 8, 6:37�am, James Jolley <jrjol...@me.com> wrote:
> > On 2010-01-08 02:38:57 +0000, Andrew Plotkin <erkyr...@eblong.com> said:
> >
> >
> > > Use MAX_ARRAYS of 1500.
> > > Use MAX_CLASSES of 200.
> > > Use MAX_VERBS of 255.
> > > Use MAX_LABELS of 10000.
> > > Use MAX_ZCODE_SIZE of 50000.
> > > Use MAX_STATIC_DATA of 120000.
> > > Use MAX_PROP_TABLE_SIZE of 200000.
> > > Use MAX_INDIV_PROP_TABLE_SIZE of 20000.
> > > Use MAX_STACK_SIZE of 65536.
> > > Use MAX_SYMBOLS of 20000.
> > > Use MAX_EXPRESSION_NODES of 256.
> >
> > most projects should be fine surely?
Zero originally came in with an error message saying that
MAX_PROP_TABLE_SIZE was too low at 30000 (or was it 50000?) That's
odd, and I didn't notice the discrepancy until now. Maybe some old
extension "raised" it, not realizing that the defaults would go up so
drastically?
(Then Otto suggested setting it to 60000, which obviously wasn't
enough by any standard.)
> I'm guessing that most of these are set low enough to keep .z5
> projects at least theoretically possible under I7.
Nope. All the settings listed above are for *compiler* memory usage.
They have no effect on the generated game file. That's why we can say
"crank 'em up" without hesitation.
In contrast, "maximum indexed text length" affects VM RAM usage.