(require "something") not working on windows

[Borwe]

On windows, I can install steel and it's cogs fine, but I can't require modules that are in current path, or giving a module via absolute path like is the default on your fork of helix with steel support showin in the image bellow.

Next is an example of using steel directly with using a module that is in the same directory, but I get an error that it can't be found.

[mattwparas]

Unfortunately I don't have easy access to a windows machine at the moment - for the first one, it looks like I'll have to escape the path which I'm currently not doing.

Per the second one - what are the contents of imp.scm and also test.scm?

[Borwe]

test.scm:

(require  (prefix-in impl. "imp.scm"))
(imp.yolo)

imp.scm:

(require "provide.scm")

(define (yolo)
    (displayln "YOLO"))

(provde yolo)

[mattwparas]

Does provide.scm exist?

[Borwe]

How do I check if it exists? I thought it is in built to steel, and not one of the cogs we install, or atleast that's the idea I got from looking at the README.md

[mattwparas]

Ah I see - this is just an example, where provide.scm is its own file - I was just designating that provide.scm had those contents with that filename.

Can you remove the (require "provide.scm") from your file and also fix the type in (provide yolo) ?

[Borwe]

Here is my new imp.scm

It now gives the following error when I try run test.scm:

[mattwparas]

Just add (provide yolo) at the top of that file (imp.scm)

[Borwe]

Works fine now. thanks. So I guess on the helix side is the only issue left?

[mattwparas]

Yeah, I'll take a look there

[gabydd]

for the first one, it looks like I'll have to escape the path which I'm currently not doing.

Would the \ have to be escaped by the user not by steel? Or am I reading this weekend

[mattwparas]

So in helix I just construct a require statement from the module location, like this:

        let res = guard.run_with_reference(
            cx,
            "*helix.cx*",
            &format!(r#"(require "{}")"#, helix_module_path.to_str().unwrap()),
        );

The biggest thing is that I neglected to remember that 1. windows existed and 2. Steel from what I understand does work agnostically of the paths, but in general if you want the code to be portable there should be a single representation that gets used for referring to modules. At the moment, that representation is just the unix one - so for this I think I can just get away with properly escaping the / in the string when requiring - and then everything from there should work as intended.

Moving forward I'd like to have a windows machine set up so I can test against it every once in a while, but I haven't made the time for that

[mattwparas]

latest commit on my fork should have the update which I think will fix this for windows. I can't test it myself just yet, but if you're willing you can give it a shot in the mean time while I get an environment set up in the next few days

[Borwe]

latest commit on my fork should have the update which I think will fix this for windows. I can't test it myself just yet, but if you're willing you can give it a shot in the mean time while I get an environment set up in the next few days

Works, I can do basic stuff on the fork now on windows, THANKS! I think issue can be closed if you want.