Yazoo Help: Runtime errors

ID	name	ID	name
0	passed (no error)	24	invalid block size
1	out of memory	25	not numeric
2	illegal command	26	not a variable
3	code overflow	27	unequal data sizes
4	inaccessible code	28	error reading number
5	jump to middle of sentence
6	number out of range	30	mismatched indices
7	division by zero	31	variable is jammed
8	member not defined	32	unjammed member
9	variable has no member	33	unjammed proxy
10	invalid index	34	not composite
11	member is void	35	undefined string
12	proxy is void	36	multiple indices not allowed
13	cannot step to multiple members	37	wrong number of arguments
14	cannot step to multiple proxies	38	string expected
15	underflow	39	invalid index
16	type mismatch	40	error in argument
17	argument out of range	41	nonexistent register
18	self reference	42	nonexistent Yazoo function
19	illegal target	43	can't find external function
20	no member associated with variable	44	recursion depth too high
21	target was deleted	45	I/O error
22	incomplete member	46	return flag
23	incomplete variable	47	finished signal

Runtime errors, by number

A built-in function was passed a numeric argument that was outside of the allowed range. The functions that cause this error are: extract() or find() (if a string position is either zero or greater than the length of the string, or if the second range element is greater than the first); and any function that pulls up information about a member (e.g. member_type(), GetParentScriptInfo()) or code (such as variable_code()), as the member/code number must be on the interval 1 through the top of that list.

Yazoo encountered a path which spans multiple members at some juncture. This is not allowed; the user can step to multiple indices of a given member, but never two members. So, for example,

causes an error on the second line. Both the [*] and [^...] operators require there to be only one member in the variable.

Yazoo tried to step into multiple proxies at the same time. The restriction on proxies is that only one can be accessed at any given time, since they all generally point to different variables.

A call() statement was instructed to run a C/C++ function that does not seem to exist. call() takes either a function name or a function ID. If it is a name, a string corresponding to that name must appear in the UserFunctionSet array (in userfn.c/cpp). If it is an ID, it must be on the interval 1-N (if there are N user-defined C/C++ functions). Thus

A transforming script did not seem to end in the way it was supposed to. For example, the constant-string command gives a string length followed by the characters of the string; if the length of the string is greater than the remaining length of bytecode, this error will be thrown. All scripts must end with a 0 terminating code word (long integer).

This warning is caused when the user tries to divide by zero at runtime. Yazoo still tries to perform the division as normal, so it will likely generate an infinity or a not-a-number value. And if for some reason a divide-by-zero crashes the computer, then the computer will crash.

There was a problem with a parameter passed to a built-in function. This is a catch-all error for miscellaneous problems with arguments, but only two functions actually throw it: compile() and find(). In the case of compile(), it means that the user passed a nonsensical namespace: either it was smaller in size than a single long integer, or it didn't end in a null (zero) character. In the case of find() it means that the mode argument (whether to find or count, and which way to search) was not in the range -1 -- 1. (It is supposed to be -1, 0 or 1, but if it is within the allowed range any fractional part is simply discarded).

The read_string() function tried to read a number into a numeric variable and failed (because the number was written incorrectly). This always occurs as a warning, not an error. It is the equivalent of the "not a number" compile-time error, except that it occurs at runtime since that is when read_string() parses its arguments.

This error code, thrown by the exit statement, is a bookkeeping device that causes Yazoo to fall out of the program. It does not mean that anything went wrong in the code. If an exit command is written inside of a trap() function, the program does not quit, but instead falls out of the trap() with error code 47. Typing throw(47) is equivalent to typing exit.

Yazoo found a nonsensical command in bytecode that it was trying to transform into memory. For example, the addition operator expects two numeric arguments: if one argument is the constant-string operator, this error will be thrown. Or, Yazoo may hit a command ID that simply doesn't exist in any of its tables, which will also cause this error. The final cases are that the user tried to run the Nth code of a user function where N < 0, or tried to define a N-length string where again N < 0.

This transformation `error' is always thrown as a warning, so it does not stop the transformation. It occurs when a null end-of-script operator was encountered before transform() hit the end of the compiled-code string. The code will still run, but the spurious code-terminating marker will likely cause it to finish early.

The user tried to do something with part of a member that was not allowed. The most basic situation is in referencing some (more than one), but not all, of a member's indices -- legal, but that must then be the last step in the path. Each step before the final step in a path must go either into a single index or complete member (all indices of that member). So, the following causes an incomplete-member error:

It is a purely technical limitation -- this error is the only thing preventing the user from referring to several non-contiguous blocks of memory at once, which is a situation that Yazoo is not equipped to handle.

Other situations that require complete members are the redefinition and removal of members. In these cases the member must really be complete: a single index is not allowed if the member spans multiple indices. Continuing our last example, the following command

Only a partial variable was referenced where Yazoo expected to find an entire variable. Certain operations can only be performed sensibly on whole variables (all indices): resizing, re-aliasing and redefining variables, or adding or removing members. For example, for a hypothetical array a[3][2] :: ubyte the following causes an incomplete-variable error.

It is worth noting that Yazoo generally ignores incomplete-member and incomplete-variable references in define statements if the redefinition won't change the type. Thus it is legal to call a[5] :: ulong twice, even though the second time that would be construed as a redefinition of just the fifth element of `a'.

The user tried to define a block-typed variable with either a negative number of bytes, or a byte-count greater than the maximum unsigned long, which is not allowed. This error will also be generated if the byte-count is plus/minus infinity or NaN.

The most common cause of this error is that the user requested an index of a variable that does not exist: e.g. array[5] when only four members exist, or array[0] under any circumstance. Remember that hidden members do not contribute to the total index count. A second possibility is that an index range was given where the second index was (more than one) lower than the first, which is not allowed: array[4, 2] for example. (array[+4, 3] is not allowed, but array[4, 3] is actually legal and just returns zero indices.) Finally, the index-addition operators [+...] and +[...] only enlarge existing members, so if the variable does not contain any members this error will be thrown.

Unfortunately, this error tends to crop up any time something goes wrong inside of an index expression, irrespective of the cause. An example is the case below, where `b' is not defined.

This currently causes an invalid-index error, although a better error message would be: member `b' not found. This may change in the future.

There are also a few wild possible ways to generate an invalid-index error: by resizing arrays beyond the maximum signed long value, or by adding infinite or NaN indices.

The fact that this error has two error codes is irrelevant to the user. It has to do with the way Yazoo keeps its books: error code 10 signifies that, if it happened in the left-hand argument of a define operator, the problem might be fixed by adding a new member, whereas 39 always stops execution.

One of the following built-in functions couldn't perform the action instructed of it: load(), save(), input() or print(). The usual cause of this is that the user tried to read a non-existent file, or read or write a file with a bad pathname or without the necessary read/write permissions. Specifically, this error is thrown if a file cannot be opened or closed, or if data could not be read or written properly to a file or the standard input or output.

Yazoo found a goto statement leading to the middle of a compiled sentence. One thing that Yazoo checks before it transforms code is that each goto is a jump to the beginning of a compiled sentence. (This applies to both conditional and unconditional jumps.)

Usually this means that Yazoo attempted to step into a void member (one that had no target). For example, if we unlink some variable via x =@ *, and then try to use x in any way before reassigning it, then we will probably get this error. Many of the built-in functions throw this error if any of their parameters are void.

The user gave a pathname with some member name that Yazoo could not find. If the offending member is at the beginning of the path, as in

where `list' causes the error, then Yazoo is telling us that list was not to be found anywhere along the search path: the current function or any enclosing object (unless the path was clipped at some point). If the problematic member was some intermediate point in the path, as in

assuming the error was due to the `header' member, then that only means that header was not immediately inside data[5].

If possible, Yazoo gives the member name in single quotes along with the error message, as in: "member 'header' not defined".

The user either tried to copy or compare data between arrays of different sizes, or else alias one array to another of a different size. For example, the following will cause this error regardless of how `a' and `b' were defined.

One common cause of this error is for multiple indices of a constructor to be running at once:

Note that arrays of different dimensions can be copied/compared if their indices are specified manually and the total number of indices is the same (and each is a contiguous block of memory -- see the section on arrays). So, for example, the following is legal:

If the last index of the array on the left-hand side of a compare or equate is a `[*]', then Yazoo will automatically resize it if that will prevent a mismatched-indices error. Sometimes this does not work; for example, in the case below:

we will get a mismatched-indices error because only the last index of `a' can be resized, which is incompatible with `b' having an odd number of indices. We would also get this error if the first dimension of `a' was sized to zero, even if `b' was also of zero size.

Several instances of a variable were given where only one was expected. Whenever Yazoo expects either a number or a string, only variables or single array indices are allowed. For example, the following causes this error.

Likewise, the following expression is also (at present) disallowed for the same reason.

Most cases of a multiple-indices error involve the built-in Yazoo functions, since many of their parameters require single numbers or strings.

Yazoo attempted an operation that involves a member, not just a variable, and it didn't have one. For example, the define operator specializes the member type as well as the variable type. The following code

will generate this error since the return command returns only a variable, not the member of the function that points to it.

In addition to the define operator, both equate and forced-equate require a member in order to resize an array via the [*] operator. (That is because both the variable and the member have to be resized.) Finally, both of the member-insert operators `[+...]' and `+[...]', as well as remove, operate on members and therefore will generate this error if none is provided.

Yazoo tried to transform code that somewhere invokes to a register that does not exist. The step-to register operator in compiled bytecode is followed by a register ID, which as a signed long must be in the range 0-9 (because there are ten registers). Any number outside this range causes a non-existent-register error. Yazoo's compiler should never generate fake register IDs, so this error should only happen if the user wrote or modified the bytecode by hand.

The user invoked a Yazoo function with a function ID that does not exist. The function ID appears immediately following the built-in-function operator in compiled bytecode. As a signed long it must fall in the range 0-44 because there are 45 built-in functions; another number generates this error. This error should only happen if the user wrote or modified the bytecode by hand, since the compiler theoretically should only produce valid ID numbers.

Yazoo expected a composite variable but was given a primitive variable instead. All of the `step' operators -- `.', `[]', `[^]', `[+]', etc. -- require that the starting variable be composite. For example, the following generates a not-composite error:

This error will also be generated if there is something other than a composite variable in the left-hand argument of a code-substitution operator (`<<'), or in the argument of a top() function.

Something that was not a variable was passed to an operation that needs a variable. Both equate and forced equate require an existing variable to copy data into, and either a constant expression or a variable to copy the data from. Likewise, the comparison operator `==' requires two arguments that are either constants or variables. In addition, all the step commands (step-to-member, step-to-index, resize, etc.) require that the user start from some variable. So if we define:

A common cause of this error is to attempt to copy a scalar into an array -- e.g. a[1, 3] = 2 -- because when it sees multiple indices on the left it expects an array on the right as well. For the same reason, writing tp :: { (a :: double) = 3 }, arr[5] :: tp will also cause this error.

Yazoo was given a non-numeric expression where it expected a number. For example:

generates this error. In different contexts one can also get compile-time or other runtime errors; the phrase "2 + "7" generates "illegal command".

Note that this is a different error from the "not a number" compile-time error, which occurs when a number was mistyped.

This error is usually thrown as a warning. Yazoo tried to assign a numeric variable a value beyond what it can store. For example, trying to assign 255 to a signed byte, or -100 to an unsigned byte, will cause this warning. This warning is not caused by rounding-off errors: for example, we can assign the value 1.9 to an integer variable, and Yazoo will quietly round it off to 1 without raising any warning flag.

There are two instances in which this message is generated as an actual error. The first is when print_string() is given a precision-argument outside the range 0 - 255. The second case is when throw() is given an error code outside the range 0 - ULONG_MAX.

Yazoo was not able to allocate memory while it was running a script. Any memory error will cause this message: for example, if the computer is out of memory, or if the memory manager for some other reason refuses to allocate a block of the requested size. Yazoo is not particularly well-designed to recover from run-time memory errors -- or at the very least, it has not been well-tested in this regard -- so it is recommended that the program be restarted if this error occurs.

The usual cause of a memory error is frequent creation and removal of variables within a loop. Due to Yazoo's incomplete garbage collection the deleted variables often do not get erased from memory until the loop is finished and the command prompt is brought up again. Calling SpringCleaning() periodically within the loop will force complete garbage collection.

Yazoo tried to step into a proxy that was void. Before this proxy can be used, it must be assigned a target via the equate-at `=@' operator.

Too many nested functions are being run. In order to avoid blowing the program stack, Yazoo sets a limit to the number of functions that can be run simultaneously within one another. This limit is set in the GL_MaxRecursions variable in hobbsh.c -- Yazoo comes with it set to 100. So if we have f1 call f2 which then calls f3, then there is no problem because the total depth is only 4 (the three functions plus the calling script). On the other hand, if we try

then we will immediately get this error because this requires an infinite level of recursion. (f creates f2 which creates its own f2, etc.)

This error code is used internally to cause Yazoo to fall out of a function when it hits a return statement. Since returning from functions is a perfectly legitimate thing to do, the error code is always set to 0 (no error) after the function has been escaped.

A variable with an alias to itself was given to an operation in which self-aliases are not allowed. It is fine to have aliases to oneself or to an enclosing variable, which is what the `self-reference' refers to. However, one cannot, say, copy data to that variable since it has an infinite depth. For example, if we define:

then me contains me.self, which contains me.self.self, etc. Therefore if we try to use this variable, or any enclosing variable, in an equate, comparison, forced equate, or the built-in functions print_string(), read_string, size(), load() or save(), we will get this error. If we try to print this variable, then print() will simply skip any part it has already printed and generate a self-reference warning instead of an error.

A built-in Yazoo function requiring a string argument was passed something that was manifestly not a string. For example, transform() expects a string (since compiled code is stored as a string), so writing

A variable was deleted while it was being aliased. One has to try hard to get this error; in this newer version of Yazoo it may well not be possible. The author tried and was unsuccessful.

Two variables/members do not have matching types. This error can occur either when data is being copied or compared, or when a variable or member is having its type altered (e.g. via the define operator).

When copying or comparing two variables, Yazoo is quite puritanical about ensuring that they have very similar (though not necessarily identical) structures. If (any part of) the first variable is composite, the (corresponding part of) the second variable must also be composite, have the same number of (non-hidden) members, and each member must have the same number of indices. Primitive variables and variable members must also match: numeric with numeric variables (though their types may be different), strings with strings, and blocks with blocks of the same size.

The read_string() function copies data from a string into a variable. It reads block data directly byte-for-byte from the string, so if there is not enough data in the string to fill the block then this error will be thrown. If it has to fill a recipient string variable with a null string, as in the case below:

then it throws a type-mismatch warning, on the assumption that there probably should have been something more substantive to read.

Yazoo is fastidious in a different way when it comes to redefining members and variables: it doesn't care about the structure of the variables, but it does require that their types exactly match or be compatible, with the new types. Two different numeric types are not compatible. Two block types of different sizes are also incompatible. Trying to redefine an existing non-proxy member with the proxy flag also causes this error.

One composite type can be changed (specialized) into another only if all of the existing N codes are also the first N codes in the new type, in the same order. Thus if we define var1 to be of type a:b, then we can specialize it into a:b:c but not c:a:b or b:a:c.

For example, if arr2 had not been previously defined, then both arr2 and the target of its only member (which has 3 indices) would have been defined implicitly; only the member of that first member would be typed to a string. On the other hand, if arr2 or its member had already been defined to a primitive type, the above would have caused either a not-composite error if arr2 had a target, or a type mismatch error if it was void.

Trying to apply the inheritance operator to two primitive types, even outside of a define clause, causes this error if the types are not the same. Concatenation of primitive types is totally meaningless, by the way, even when it works --- it doesn't generate a compound type.

A string was used in a comparison or passed to a built-in function before having been assigned a value. For example, if we define

Unlike other primitive variables, strings have to be actually initialized to a value before they can be used. Note that when s was first defined it did not contain a null string (those are perfectly legitimate values to hold). It had no value. If we had instead initialized string `s' with the code

The underflow warning alerts the user that read_string() attempted to read a number containing significant digits that are below the double-precision accuracy limit of the machine (DBL_MIN in C). Numbers as small as 5e-324 can be stored; however, reading "1e-310" gives an underflow warning since only the first 14 digits will be reliable.

Yazoo was not able to perform a forced equate because the byte-sizes of the left- and right-hand arguments were different. Before throwing this error, the forced-equate operator explores two options for making the data fit. 1) If the final step into the left-hand variable involved a [*] operator it tries to resize that last member. 2) If the left-hand variable contains a string, that can soak up excess bytes from the right-hand argument. If after (1) and (2) the data on the right still cannot fit into the variable on the left, then this error is thrown.

If both (1) and (2) apply (i.e. the user is forcing data into a string-containing array), Yazoo may not able to figure out how to resize the array correctly. In such a case the user must resize the array manually to avoid an unequal-data-sizes error.

Yazoo tried to step into a member that was `unjammed' -- i.e. a member that was defined as unjammable, and one whose target variable was later resized. When this happens the unjammable member immediately becomes obsolete: it has the wrong number of indices for its target. Therefore it cannot be used again until it has been redefined.

Unless the user does something sophisticated, unjammable members are only generated by the compiler, for example when it generates tokens. The following code will generate an unjammed-member error:

array[5] :: ubyte set :: { array[1, 5] } delete array[3] | unjams the token in our 'set' print( set[1][1] ) | the second '[1]' causes the error

Had we aliased array explicitly in our set variable, the alias would not have been defined as unjammable, and we would have gotten a jammed-variable error when we tried deleting the array element.

Yazoo tried to step through a proxy that had been `unjammed'. This is identical to the unjammed-member error, expect that the member was defined with the proxy flag set.

The user tried to resize a variable that has more than one member pointing to it. That is, indices are being added to or removed from an array, and there is an alias array that encompasses these same indices whose size would also change if this error did not prevent it. For example, consider the following setup:

Member `a' (and also `b') points to a composite variable containing one (unnamed) member spanning five indices; that member in turn points to five instances of a type-double variable. Member `c' is structured the same way; it points to a different variable, but that variable's width-3 member points to some of the same instances of the double-type variable. Now if we try

we will get a jammed-variable error. The culprit is `c' -- or more accurately, the width-3 member inside c's composite variable. `b' does not cause any problems, since it shares the same width-5 member that `a' uses; resizing `a' implicitly does the same to `b'.

then there would have been no error, since that part of the array is not shared between two members.

The alias coming from `c' is said to have jammed the variable we were trying to resize. Certain members (usually, members that Yazoo adds implicitly to the script during compilation) cannot jam variables, because they were defined with the unjammable flag set. No error jumps in to prevent the user from resizing an unjammable member's target variable by another member, so if this happens the unjammable member gets unjammed -- i.e. deactivated.

Either the `[*]' or the `[^...]' operator was used in a variable that does not have any members. Both these operators need at least one member to operate (`[*]' requires no more than one). The only exception is when the expression falls on the left-hand side of a define statement, which causes the members to be created if they do not already exist.

A built-in Yazoo function was called with the wrong number of arguments. For example, the following expression will cause this error