Absolut import does not work.

[aosenkidu]

See:

Idunn2:absolut_import_bug angelos$ ls
main.wren       to_import.wren
Idunn2:absolut_import_bug angelos$ 

Source of the files (main.wren):

Idunn2:absolut_import_bug angelos$ cat main.wren 
import "/Users/angelos/development/kestrel-devel/absolut_import_bug/to_import"
System.print("we do not get here, as the import above will fail!") 

And the imported file:

Idunn2:absolut_import_bug angelos$ cat to_import.wren 
// the main.wren trys to import this with an absolut path
System.println(" ... this fails - and is never printed")

Now running wrenc_d (debug version on my Mac, hence the _d)

Idunn2:absolut_import_bug angelos$ wrenc_d main.wren 
Could not load module './Users/angelos/development/kestrel-devel/absolut_import_bug/to_import'.
at (script) (./main.wren line 1)
Idunn2:absolut_import_bug angelos$ 

As you can see at the output: the resolving/loading adds an erroneous dot ('.')

I guess the culprit is this line in _wren.inc (around line 54):

    if (PathType.resolve(module) == PathType.SIMPLE) return module

SIMPLE should be ABSOLUT, or not?

EDIT: no, that is not the spot with the error - I investigate more.

[aosenkidu]

Same for relative imports that do not use a dot in front of the imported module:
The files:

Idunn2:kestrel-devel angelos$ cd relative_import_bug/
Idunn2:relative_import_bug angelos$ ls
main.wren               to_be_imported.wren
Idunn2:relative_import_bug angelos$ 

Files content:

Idunn2:relative_import_bug angelos$ cat to_be_imported.wren 
// this module is about to get imported
System.print(" ... however this line never runs!")

And main.wren

Idunn2:relative_import_bug angelos$ cat main.wren 
import "to_be_imported"

System.print("we never end here, as the import above fails")

Running main:

Could not load module 'to_be_imported'.
at (script) (./main.wren line 1)
Idunn2:relative_import_bug angelos$ 

Does also not work if I'm in a different directory:

Idunn2:relative_import_bug angelos$ cd ..
Idunn2:kestrel-devel angelos$ wrenc relative_import_bug/main.wren 
Could not load module 'to_be_imported'.
at (script) (./relative_import_bug/main.wren line 1)

[joshgoebel]

Not sure if it would help, but I largely rewrote all the module/importing code in my own CLI - it's now all pure Wren. Since Wren isn't re-entrant I run a second Wren VM to handle the more "complex" lifting to avoid as much low-level C.

https://github.com/joshgoebel/wren-console

I don't imagine it could be back-ported here though because it's a very different approach.

[aosenkidu]

Oh, that explains why you call the second VM "resolver VM". Did not realize it is a second VM, I thought it is an odd way of naming your variables.

Well, the error is in your code (in wren-console, perhaps wren-cli works fine?). I guess I should have posted the issue in "wren-console"?

Why is "not reentrant" a problem? I was about to extract the resolving and importing into a wren module as well, but then I realized it is mostly wren already. Is it generally not possible (not advised) to execute the VM and let foreign methods call back into the same VM?

I had assumed it is enough to change the VM to first check if a wren module is registered to do the loading of an import, and if not call the function provided by the host. What am I missing?

EDIT: I was thinking about working on two "APIs" aka "interfaces", one for wren code to call into the VM, aka writing a foreign class that resembles the VM, and one module for the VM to externalize everything that can be done in wren. That is basically how the Java Virtual Machine works. Nearly everything you would assume to be done by the VM is actually done in pure Java, e.g. Byte Code Verifying etc.

Oki, I dig around - perhaps I can fix it, but for some reason (perhaps my post COVID problem) I have a hard time, lol. But it is fun anyway.

[joshgoebel]

I guess I should have posted the issue in "wren-console"?

Please do and I'd be happy to take a closer look.

Why is "not reentrant" a problem?

Because importing is a hook in C... so you're stuck in C... and you can't enter the running Wren VM to run resolver code there since that would be re-entry - hence the second VM which we can enter freely even when the first VM is already running.