Misleading error message and docs suggestion for Enumerations

bgrommes

Summary

The docs state "Use zero-based indexing to read or write byte values" of a MemoryBlock. And this works if you do the following where _charInfoTable is a MemoryBlock and CharacterType is an Integer-backed Enumeration.
return _charInfoTable[codePoint] = Integer(CharacterType.Whitespace)
But this fails:
return _charInfoTable[codePoint] = CharacterType.Whitespace

I'm not 100% sure it SHOULD fail, however the error message is:
TypeMismatchException: Only arrays, dictionaries and indexable objects support indexing.

It seems to me that the problem isn't that MemoryBlock doesn't support indexing, but that I'm trying to compare something of type CharacterType rather than type Integer. The error message is a bit overloaded.

The reason I initially did this is because the docs for Enumeration give this example:

Enum HttpStatus
    OK = 200
    NotFound = 404
    ServerError = 500
End Enum

Print(HttpStatus.OK)          # 200
Print(HttpStatus.NotFound)    # 404

If Print prints an integer, I figured it treats it as the underlying type and not an Enumeration. Apparently all it's doing is calling an overridden ToString() on the type?? Anyway it makes more sense that I'd have to cast CharacterType to Integer explicitly, but I read too much into those docs and then the error message was making me say, "wait a minute, MemoryBlocks most certainly DO support indexing" and it took me a minute or so to clear the resulting cognitive dissonance.

Objo Studio Version

26.6.4

Garry

Thanks for the detailed report. There are two separate things going on here.

First, the docs were too easy to misread. Enum members have integer backing values, and printing an enum member displays that backing value, but that display form is not meant to imply that enum values are freely interchangeable with Integer values. I’ve updated the enum docs to call this out explicitly and to show that Integer(MyEnum.Member) is the right form when an Integer is required.

Second, the runtime error itself was a bug. MemoryBlock does support indexed byte access. The problem was a VM optimisation for global values indexed by local variables/function parameters: it fused the bytecode into a fast array/dictionary-only path and accidentally bypassed the normal native indexer path that MemoryBlock uses (oops!). That’s why the error talked about arrays and dictionaries even though your MemoryBlock indexing syntax was valid.

I’ve fixed the optimiser/runtime path and added a regression test for this shape. Until the fix is in the next build (already done), a reliable workaround is to copy the global MemoryBlock into a local before indexing it:

Var table As MemoryBlock = _charInfoTable
Return table[codePoint] = Integer(CharacterType.Whitespace)

https://feedback.objo.dev/bug/521

bgrommes

Garry I am still getting the "doesn't support indexing" error in 26.6.5, even with the correct cast on the Enumeration, it just doesn't happen until I try to run the project. As before, _charInfoTable is a MemoryBlock (specifically, if it matters, it's Shared).

return _charInfoTable[codePoint] = Integer(CharacterType.Whitespace)

"TypeMismatchException: Only arrays, dictionaries and indexable objects support indexing."

Garry

Thanks, I investigated this against my current main branch.

The fix I mentioned earlier covered a VM peephole optimisation for module/global variables, and the regression test for that path still passes.

I can reproduce your exact runtime message, but only when the shared MemoryBlock is still Nothing at the point it is indexed. For example:

Shared Property _charInfoTable As MemoryBlock

Shared Function IsWhitespace(codePoint As Integer) As Boolean
    Return _charInfoTable[codePoint] = Integer(CharacterType.Whitespace)
End Function

If _charInfoTable has not been assigned a New MemoryBlock(...) before IsWhitespace runs, the VM currently reports:

TypeMismatchException: Only arrays, dictionaries, and indexable objects support indexing.

That message is misleading in this case. It should probably say that you are trying to index Nothing.

I could not reproduce a failure when the shared table is initialised before use. These both work locally:

initialise _charInfoTable in App.Constructor
initialise _charInfoTable in App.Run before calling IsWhitespace

Could you share the small section where _charInfoTable is declared and initialised, plus where IsWhitespace is first called? In particular I want to check whether the initialisation code definitely runs before the first lookup. If it does, then there is still another bug here and I’ll need that exact shape to reproduce it.

bgrommes

Garry I'll review this soon as I get a chance today. It is initially Nothing and is (supposed to be) lazy initialized in the getter. Come to think of it I should probably be using CharInfoTable instead of _charInfoTable which is the backing field.

What's unaccustomed for me here is that I usually handle lazy static field initialization in the static constructor, particularly for private or protected internals like this. I'm going to have to tread more carefully as I learn these new tradeoffs. Anyway -- I'll confirm as soon as I'm able.

bgrommes

Garry You correctly diagnosed this -- I was referencing a backing field and never triggered the getter on the computed property. So the sole issue is the error thrown, which should have been the Objo equivalent of NullReferenceError (NothingReferenceException?) That would have put me right onto the problem.

Garry

The error message provided in the next build should be much more explicit and helpful.