Works in WinGlulxe, Doesn't in Quixe

Authoring Inform 6
1

Hello hello! I’ve hit something that’s odd. I suspect I’ve missed something obvious but I can’t see what it is.

This code:

[ CreateFileReference fileName nameLength   buffer fileReference;
    print "fileName: ", (StringOrArray)fileName, "^";
        
    if (fileName ofclass String){
        nameLength = fileName.print_to_array(createFileReferenceBuffer, MAX_ARRAY_LENGTH);
        buffer = createFileReferenceBuffer;
    } else {
        nameLength = fileName-->0;
        buffer = fileName;
    } 

    print "fileName result: ", (StringOrArray)buffer, "^";

    print "length: ", nameLength, "^";

Called like:

print (StringOrArray)JSCOMM_EVAL_FILE, "^";
jsCommEvalFile = CreateFileReference(JSCOMM_EVAL_FILE);

Produces this output in WinGlulxe:

/JSCommunication/JSCommEval
fileName: /JSCommunication/JSCommEval
fileName result: /JSCommunication/JSCommEval
length: 27

But produces this in Quixe:

/JSCommunication/JSCommEval
fileName: /JSCommunication/JSCommEval
fileName result:
length: 0

I’m stumped. Up until now, everything run has been the same in both.

I’m sure I’ve done something somewhere that’s created the problem, I just don’t see how I could have managed to affect variable assignments…

2

So I investigated further and now I have this code:

print (StringOrArray)JSCOMM_EVAL_FILE, "^";
len = (JSCOMM_EVAL_FILE).print_to_array(returnValueResultBuffer, UTILITY_BUFFER_LENGTH);
print len, "^";
print returnValueResultBuffer-->0, "^";

Which produces this in WinGluxe:

/JSCommunication/JSCommEval
27
27

And this in my implementation:

/JSCommunication/JSCommEval
0
0

So, somehow, I’ve managed to disrupt whatever mechanism print_to_array relies on and, I suspect, that has had a trickle-down effect onto other routines.
Importantly, besides creating my own GlkOte, I haven’t been modifying anything else in Quixe and this is a new issue so it’s a recent change I’ve made, just have no idea where it could come from…

Any thoughts?

Perhaps @zarf will know :smiley:

3

Ah ha!

It was because I was mucking about with glk_stream_close. I guess I wasn’t closing the streams correctly.

1 Like