Hi, I am very interested to the project, I followed the instructions. Unfortunately when running cargo run I get twenty errors on the file wrap.rs:

error: cannot specialize on Binder(OutlivesPredicate(T, ReStatic), []) error: cannot specialize on trait StdError error: cannot specialize on trait std::fmt::Display error: cannot specialize on trait Debug error: cannot specialize on Binder(OutlivesPredicate(T, ReStatic), []) (three times at lines 1552, 1887, and 2021 error: cannot specialize on trait Default error: cannot specialize on trait BuildHasher error: cannot specialize on trait Eq error: cannot specialize on trait PartialEq error: cannot specialize on trait Hash error: cannot specialize on trait Ord error: cannot specialize on trait PartialOrd error: cannot specialize on trait PartialEq error: cannot specialize on trait Eq error: cannot specialize on Binder(OutlivesPredicate(T, ReStatic), []) (lines 2492 and 2522) error: cannot specialize on trait engine::RGlobal (lines 2566 and 2586)

How could I fix all of these? Thanks in advance best

Hello, I'm having issues when I try to compile!() my GameLisp code. The compilation is fine, but once I execute the resulting binary, there's the following error:

unhandled error in run() call:

stack trace:
    glsp::load_compiled()
    (load) at compile-proc-macro:1
    glsp::load("./game/main.glsp")
    (require) at ./game/main.glsp:1
    glsp::require("game/structs.glsp")

errors:
    invalid filename 'game/structs.glsp' passed to glsp::require
    The specified path cannot be found. (os error 3)
thread 'main' panicked at 'global type roguelike_glsp::api::KeyPressed was never registered, or it has been dropped', [redacted]\.cargo\registry\src\github.com-1ecc6299db9ec823\glsp-engine-0.2.0\src\engine.rs:2595:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I solved this problem by replacing all the (require) calls with (load) so it's not really an issue right now, but it seemed cleaner to call (require).

My repository is here

(also, any critic on my rust/glsp code is welcome)

Thank you

I am experimenting with a language server extension and I am trying to highlight areas of the code that fail to parse. I am not sure if my approach is the best or even correct.

At the moment I am calling parse_all(&code, None), and I am inspecting the error value. Unfortunately I can only get a message, with no information about line and column (or span) where the error is.

In a project, I have a state struct that contains a glsp runtime and a struct that holds callbacks:

struct Callbacks {
  //various callbacks of type: Option<Root<GFn>>
}

struct State {
  callbacks: Callbacks,
  runtime: Runtime,
  ...
}

At the very end of the program, when the state is dropped, it panics with the error: a Root or Gc has outlived its originating Runtime - aborting process

I then tried manually dropping the callbacks before the end of the program, and it seems the panic occurs there, so it looks like I can't drop Roots unless I'm in a runtime environment. Is this intentional?

The glsp namespace is currently cluttered with around 100 toplevel functions. When a new user looks at the docs.rs page, I expect this doesn't make a great first impression. The functions are also quite verbose (glsp:: is six characters), they're not very self-documenting at the call site (glsp::arr_from_iter is debatably less clear than Arr::from_iter), and they introduce name-collision problems in the prelude.

Many of the toplevel constructors could be converted into associated functions. For example, glsp::coro could become Coro::new, and glsp::step_by could become GIter::step_by. A quick headcount suggests that this would eliminate around 40 toplevel functions.

Possible downsides:

• Most of the constructors would return a Root, which might be counterintuitive
• This change could make constructors less discoverable
• It would make the codebase less organised (we would need to add many with_engine invocations outside of engine.rs)

The reference says:

When the parser encounters a sequence of characters which could represent a symbol, or could represent a number or abbreviation, then the number or abbreviation will take priority.

Currently this means that numbers starting with a period are parsed as meth-name, so e.g. (let decay-rate .05) fails with an "error: unbound symbol 'meth-name'" This is never helpful, as 05 is not a valid method name.