Mercerenies / gdlisp

Lisp on the Godot platform
GNU General Public License v3.0
139 stars 1 forks source link

When running gdlisp repl on Windows 10, crashes on setup #144

Open yumaikas opened 1 year ago

yumaikas commented 1 year ago

Trying to get GDLisp up and running on my Windows 10 laptop, using Godot 3.5.1, and when I run GDLisp without a file argument, I get the following error:

:\Users\yumai\JD\40-49 Programming\43 Source Installed Programs\43.18.GDLisp>target\release\gdlisp
GDLisp v1.0.0
Running under Godot
3.5.1.stable.official.6fed1ffa3
Version:
3.5.1.stable.official.6fed1ffa3
Given Absolute /tmp/REPL.lisp, expected an absolute path
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ExpectedAbsolute', src\repl.rs:134:100
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library\std\src\panicking.rs:575
   1: core::panicking::panic_fmt
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library\core\src\panicking.rs:64
   2: core::result::unwrap_failed
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library\core\src\result.rs:1791
   3: gdlisp::repl::Repl::run_code
   4: gdlisp::repl::Repl::parse_and_run_code
   5: gdlisp::repl::Repl::run_code
   6: gdlisp::repl::Repl::parse_and_run_code
   7: gdlisp::repl::Repl::force_load
   8: core::ptr::drop_in_place<std::sync::mutex::MutexGuard<thread_local::thread_id::ThreadIdManager>>
   9: core::ptr::drop_in_place<std::sync::mutex::MutexGuard<thread_local::thread_id::ThreadIdManager>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

(I added code to eprint the failed file path)

GIven that I'm running on Windows, it seems strange to be opening /tmp/REPL.lisp? Is this expected?

Mercerenies commented 1 year ago

Interesting. The REPL treats your user input as a synthetic file called /tmp/REPL.lisp, though I don't think it should ever actually go looking for the file at that location. This is definitely a bug; thank you for bringing it to my attention!

yumaikas commented 1 year ago

It might not be opening it, then, but the error is still getting thrown for some reason. I fixed it locally by using std::env::tempdir and pushing REPL.lisp onto it. Dunno if that's the proper fix, though.

Mercerenies commented 1 year ago

I've just pushed some fixes to master for the way GDLisp handles file paths on Windows. You should be able to access the REPL now.

yumaikas commented 1 year ago

Cool, I'll take a look when I get home to confirm that this works locally for me!