This works -- I can define a module using an argument for the name, and access it by name in a different abstraction.

But this modified version of @60-hz 's gl.image abstraction doesn't accept this style. The image loader shows no errors but the smaller 'bind' abstraction can't find m.img.

Same design: abs1 puts something into its M, abs2 "require"s that module and accesses a known variable name. But in the second case, require isn't getting the thing.

hjh

@ddw_music Hi, Can you upload a simplified patch that doesn't work? Does it happen when you require a variable name using "$1" symbol?

I'll try... simple cases are still working -- this prints "OK."

My initial approach did use $1 in the variable name and it seemed to construct the variable name correctly. But I removed $1 from the variable name when I realized I could keep it local to the module.

hjh

Is there any sort of established debugging methodology for this? It seems rather difficult to debug if one can't inspect the contents of the table.

hjh

I was basing my patch on @60-hz 's gl.image abstraction.

In the original, there's an [ofelia define image-$0] and also an [ofelia function image-$0].

I had inferred from this that sharing a name would allow the boxes to share data -- but now I see this was an incorrect design (both in my version and in the original). The second box sharing the name overwrites the table for that name, making data from the first box inaccessible elsewhere.

There should be one and only one box declaring a name. Other boxes that need to use data from the first box should use require but not specify a name.

After I deleted the function box from my broken test abstraction, then all was working.

So that looks like it -- multiple ofelia objects with the same name seems to be a counterindicated practice.

hjh