[Coco] new problem with unpack

[Aaron Wolfe]

Just a quick question, I haven't read carefully enough probably, but you
aren't trying to access a file path opened in one module from a different
module are you? I wouldn't think that could work.  Ignore me if this is
irrelevant.

Also to add another possible mechanism for sharing data between processes
check out "data" modules.  These can be accessed from multiple processes
simultaneously and can be used to implement simple locking/synchronization
mechanisms.  You could (for instance) have one program load the data
module, chain to a program that parses it, chain to another that outputs
it.  Stuff like that, with each step in the chain having access to all the
memory used by any of the steps.
 On Oct 31, 2013 2:27 PM, "Wayne Campbell" <asa.rand at gmail.com> wrote:

> Well, the problem isn't what I was thinking it was. I removed DRPN from the
> equation by packing it separately so that instruction would be small enough
> to execute. That was when I realized that instruction was not executing at
> all. The error is being generated by the system (or runb), not by my
> program. I looked again at my code in instruction. The first instruction
> is:
>
> PRINT #2,"Building Instruction Statements";
>
> I thought, maybe that is the problem, and somehow #2 is not being
> recognized by runb or the system as stderr. I replaced it with:
>
> PRINT "buildSrc";
>
> The same error occured. The first instruction is not being executed,
> period. The error occurs as soon as an attempt to execute instruction is
> made. Since instruction and hex$ both fit well under 8k and the data space
> requirements for instruction are <8k, something else must be causing the
> problem.
>
> One change I made to make instruction smaller was I replaced 2 of the 3
> records with only the variables needed to hold those fields, and passed the
> fields from unpack. I thought, maybe runb doesn't like me trying to pass a
> filepath number contained in a record. I changed unpack so it contained the
> necessary variables, assigned those variables the necessary field values,
> and passed just those variables. The same error occurs in the same place.
>
> I know I can use a path number in a record field because I do it in every
> procedure in unpack. The only difference here is, instead of passing the
> entire record I am passing a specific field of the record. And now I am not
> even doing that. I am assigning a different variable of the same type as
> the field the value of the field, and passing that variable instead.
>
> ERROR #201 (as the system displays it) is displayed by ErrorCodes as:
>
> Error#: 201 ILLEGAL PATH NUMBER The path number is too large or you
> specified a non-existent path.
>
> since the error occurs when the first attempt to execute instruction is
> made, instruction is small enough to fit in memory now, and the error
> report is coming from the system (or runb) (and not through my program's
> error trap system), I can only think that runb is the problem. I do not
> know what to do about it.
>
> Anyone out there have any ideas?
>
> Wayne
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>