glsp-engine v0.2.0 compilation - errors

[sarini68]

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

[fleabitdev]

Thanks for the report!

Seems like the origin was probably rust-lang/rust#89413. We were relying on the fact that #[rustc_unsafe_specialization_marker] permits marker traits to have supertraits which aren't, themselves, specializable. Turns out that was simply a bug!

Without this rustc "feature", large parts of wrap.rs can't work as currently designed. They'll need to be redesigned and rewritten, as per this comment. (This will change if rustc's specialization support sees rapid progress, but I don't think that's likely.)

The fix will be intrusive. It will almost certainly remove features from the crate, so I'll need to rewrite documentation, change my own client code, and so on. I can't currently spare that much time for this library, due to time pressures from my day job - but when my situation changes, this bug will be a priority. The good news is that, when I do implement this fix, it will probably enable us to switch to stable rather than nightly Rust.

In the meantime, the only workaround would be to use a nightly version of rustc older than 30th September 2021. Sorry that I couldn't be more help!

[sarini68]

Thanks for the prompt and detailed answer. I used the workaround and it worked. I have a question for running some examples but it is not an issue, so where can I ask some help about this?

[fleabitdev]

It breaks my heart to say it, but right now I'd caution against using GameLisp for any new projects - progress stalled when the libraries and tooling were still quite immature, and I don't have the time to act as a mentor, to review pull requests, or even to fix critical bugs like this one. At least one other person has recently tried to use the language for a game-jam-style project, but they had to stop due to the weak tooling.

If you're just tinkering with the language out of curiosity, though, I'm happy to answer any simple questions here!

[sarini68]

Many thanks for your attention. Yes, I'd like tinkering with the language, so I would be glad just to start running a simple hello_world.glsp code opening a window and printing text and then trying by myself for more complex scenarios. So I'd be very grateful to have a skeleton file for this minimal GameLisp code and the indication where to put this file in relation with the main.rs file you wrote in the getting started section. Many thanks

[fleabitdev]

Even with these modest ambitions, I'm afraid you've overestimated the tooling. GameLisp doesn't come with any code for windowing or rendering, and there are no bindings to third-party libraries. If it isn't in the standard library, you need to write it yourself, using Rust rather than GameLisp.

The recipe:

• Write your windowing code and main loop in pure Rust, using a crate like ggez
• Write some Rust functions which could be called from GameLisp (it wouldn't make much sense to script windowing using GameLisp, but a text-rendering function might work)
• Initialise GameLisp, as per chapter 2.1 of the reference manual
• Bind your functions to the GameLisp Runtime, as per chapter 2.3
• Create a file named example.glsp, in your crate's working directory (next to Cargo.toml)
• Write GameLisp code in that file, calling your functions

[sarini68]

Many thanks for your detailed explanations. Now it's clearer to me

[jgarvin]

I ran into the specialization errors too and ended up here. Just wanted to affirm that there are still people out there who think this is a cool project! Needing to use an older version of the compiler is less of a concern for me than the possibility of depending on something unmaintained. I looked at some of the alternative rust lisp implementations but many of them are immature (a surprising number don't support macros!), are not written in pure Rust which complicates web assembly targeting, or just lack some of the game oriented features that game lisp has like the per frame garbage collection and making the default container type VecDeque. Game Lisp seems to be targeting a niche nobody else is filling.

[Machine-Jonte]

2023, this project is still interesting! Any chance of reviving it?