Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing occurrences of Unsafe.toLinear from ghengin-vulkan #1

Open
alt-romes opened this issue Jun 24, 2023 · 0 comments
Open

Removing occurrences of Unsafe.toLinear from ghengin-vulkan #1

alt-romes opened this issue Jun 24, 2023 · 0 comments

Comments

@alt-romes
Copy link
Owner

Amidts the gigantic refactor that brough linear types and backpack to the engine, some corners were cut (making the underling monad the Linear IO Monad was already a huge endeavour).

The engine is still somewhat broken after that giant refactor (e.g. textures still don't work), and some bad decisions were made (linear-apecs, leaking linear types out of the implementation onto the user)

Great things have happened, however. Especially the modularity of it all (because of backpack)
Now there are a couple of independent packages that depend on each other

  • ghengin-core, where the ideal "core" of the engine, with which anything in the engine can be expressed (albeit less easily) (this is in light of GHC.Core). This module is abstract in the implementation of the renderer using backpack.
  • ghengin-vulkan, is the renderer implementation using vulkan
  • ghengin, which depends on ghengin-core and instances it with ghengin-vulkan (that's the beauty of backpack)
  • some others like ghengin-core-indep which are depended on both by ghengin-core and ghengin-vulkan (since having ghengin-vulkan depend on ghengin-core doesn't yet work)

Currently,

  • ghengin-core is unsafe-free! we don't use Unsafe.toLinear anywhere
  • ghengin-core-indep exposes some safe functions which use unsafe.toLinear under the hood -- those are part of our trusted base
  • ghengin-vulkan still uses Unsafe.toLinear extensively where it shouldn't -- it was required for me to see the refactor to the end, but I think there are bugs lurking (especially wrt reference-counted things, the wrong handling of which causes big problems)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant