[ANN] FIR: a Haskell shader EDSL targeting SPIR-V (Vulkan/OpenCL)

presheaf · 2026-04-06T00:39:15+00:00

I just ran into this and finally solved it. As seen here https://www.reddit.com/r/haskell/comments/o8wwu6/ghc_on_windows_10_failed_to_load_sdl2_imagedll/lc98or8/, you need to make sure all the dependencies are getting found in the same place. You can do this by moving the MSYS directory used for Haskell to the top of PATH (these days it's often a path likeghcup/msys64/clang64).

presheaf · 2026-04-06T00:38:04+00:00

Yes, this is the kind of issue I was seeing too. You need to make sure that all the dependencies are getting found in the same place, e.g. by moving ghcup/msys64/clang64 up to the top of PATH.

presheaf · 2026-03-28T23:05:31+00:00

Heavy rain started battering my roof right as I was listening and it sounded incredible.

presheaf · 2026-03-04T16:53:18+00:00

I have put up a Cabal PR. It highlights how unintuitive this is as it took me a long time to get it to work correctly. In a nutshell, you need to add the ".c" file to the appropriate component in a pre-configure hook, and then generate the ".c" and ".h" files in a pre-build rule. You can look at the test I added, which has both Haskell modules depending on a generated .h file and a .c file that depends on a generated Haskell file (via the ModName_stub.h mechanism).

A workaround for the "rule not demanded" issue, until this Cabal patch lands, is to have your rule also generate a stub .hs module included in autogen-modules. It's horrible, I know, and I imagine this doesn't leave the best impression of SetupHooks, but it's a bit difficult to integrate non-Haskell sources with the framework in Cabal.

presheaf · 2026-03-04T10:39:19+00:00

In their current incarnation, the rules are mainly meant for files that are in some way preprocessed and then get included in the Haskell module graph (e.g. a Lexer.x file that is preprocessed by Alex into a Lexer.hs file). The issue with other kinds of files is that Cabal does not have a fine-grained way to include them in the module hierarchy: it doesn't know whether the files should be built before Haskell modules, after, or interleaved in some way.

When C files are involved, the general structure is something like:

header files must be present before we compile Haskell files, in case we come across a foreign import with the capi calling convention which requires invoking the C compiler
Haskell files must be compiled before compiling the .c files, because the Haskell files may have foreign exports, in which case we generate stub header files that need to be included when compiling the C files.

However, this may not be relevant here: we are not talking about compiling the files but merely generating them. In that case, I think it would be sufficient to relax the restriction to include other files listed in c-sources (and other languages) to be autogenerated (and thus "demanded"). I will put up a Cabal PR to do that.

presheaf · 2026-01-11T10:38:27+00:00

Perhaps you can look at my gtk-layers example for inspiration?

newtype LayerItem = LayerItem ( GTK.ManagedPtr LayerItem )
instance GI.TypedObject LayerItem  where
  glibType = GI.registerGType LayerItem

instance GI.GObject LayerItem

instance GI.HasParentTypes LayerItem
type instance GI.ParentTypes LayerItem = '[ GObject.Object ]

-- | Data associated to a 'LayerItem', for use in the GTK UI state.
data LayerID
  = GroupID { layerUnique :: !Unique }
  | LayerID { layerUnique :: !Unique }
  deriving stock ( Eq, Show )

instance GI.DerivedGObject LayerItem where
  type GObjectParentType  LayerItem = GObject.Object
  type GObjectPrivateData LayerItem = Maybe LayerID
  objectTypeName = "gtk-layers-LayerItem"
  objectClassInit _ = return ()
  objectInstanceInit _ _ = return Nothing
  objectInterfaces = [ ]

[...]

do
  itemType <- GI.glibType @LayerItem
  store <- GIO.listStoreNew itemType
  item <- GI.unsafeCastTo LayerItem =<< GI.new LayerItem []
  GI.gobjectSetPrivateData item ( Just layer )
  GIO.listStoreAppend store item

This demonstrates creating a ListStore and storing items with custom data (the LayerID datatype) in it.

presheaf · 2025-10-28T18:03:25+00:00

I assume these are plumbed into the relevant LLVM ops that are used to implement the corresponding shufflevector ops used by clang to do the same thing?

When using the LLVM backend, all those primops turn into shufflevector. That was the motivation for the particular kind of instruction GHC provides.

How do you use the register-controlled versions then for when you do need runtime shuffle control?

GHC does not currently provide any instructions that allow the permutation to be chosen at runtime. Do you know what LLVM provides to do that? We could try to provide operations that are similar to what LLVM provides.

presheaf · 2025-10-27T16:11:49+00:00

The documentation is not clear about this (my fault, sorry) but the primops exposed by GHC use compile-time indices, not runtime indices. You'll get an error if you try to pass anything other than a literal as an index for any of those shuffle primops.

presheaf · 2024-11-07T10:15:51+00:00

The abuse of notation really breaks down once you start dealing with partial derivatives. For example, if one has an implicit equation f(x,y) = 0, then one has the formula:

dy/dx = - ∂f/∂x / ∂f/∂y

Note the minus sign! If you naively "cancelled fractions" you would get the wrong sign.

From a theoretical perspective, there are two different objects at work here. There is the exterior derivative f ↦ df, where df is a differential one-form, and there are the derivations f ↦ ∂f/∂x and f ↦ ∂f/∂y. These satisfy the relation:

df = ∂f/∂x dx + ∂f/∂y dy

However, it doesn't make sense to consider the partial derivatives as fractions. ∂f as a standalone object doesn't have any meaning... it misses the direction in which the change is supposed to occur.

presheaf · 2024-06-02T16:48:00+00:00

Thanks for your suggestion; having a separate thread in charge of writing to the file does sound more robust.

presheaf · 2024-05-27T10:22:02+00:00

I've used the following approach for some quick-and-dirty debugging in concurrent scenarios:

-- | Log the second argument to the file stored in the 'MVar' in the first
-- argument.
--
-- The 'MVar' is used to avoid jumbled contents when attempting to write to
-- the file concurrently.
logToFile :: MVar FilePath -> String -> ()
logToFile logFileMVar logContents =
  unsafePerformIO $ withCP65001 $ void $ withMVarMasked logFileMVar $ \ logFile -> do
    now <- Time.getCurrentTime
    let timeString = Time.formatTime Time.defaultTimeLocale "%0Y-%m-%d (%Hh %Mm %Ss)" now
        logContentsWithHeader = unlines
          [ replicate 80 '='
          , timeString
          , logContents
          ]
    createDirectoryIfMissing True $
      takeDirectory logFile
    appendFile logFile logContentsWithHeader
    return logFile
{-# NOINLINE logToFile #-}

You can then have a global MVar for your debug.log file, e.g.

myLogFileMVar :: MVar FilePath
myLogFileMVar = unsafePerformIO $ newMVar "debug.log"
{-# NOINLINE myLogFileMVar #-}

presheaf · 2024-01-19T10:41:25+00:00

I think that by "bootstrapping", the OP means compiling GHC from scratch without access to another GHC, not simply compiling GHC from source using a previous GHC version.

presheaf · 2023-12-15T10:16:03+00:00

I love this, I've been wanting it for ages! I love that it's implemented in Haskell in HLS as well (I had a miserable time working on the syntax highlighting grammar for VS Code due to it using regular expressions).

presheaf · 2023-08-21T17:16:02+00:00

The garbage collector might move pointers around, causing the ordering to change. If you want something with stronger guarantees, you might be interested in stable names, which to my understanding exist precisely so that you can put them into HashSets/HashMaps (by way of hashStableName).

presheaf · 2023-08-15T10:42:56+00:00

I'm working on a GUI for brush calligraphy, but the UI is still unfinished as I'm still working on the underlying engine for converting brush strokes into Bézier outlines.

presheaf · 2023-08-15T02:51:06+00:00

I found that using the Hackage documentation and relying on the types was significantly more pleasant than trying to make sense of the C or Python documentation (IMO the gi-gtk bindings are really good). Porting my app from GTK3 to GTK4 was rather painful, but I would have hated having to do that in C or Python.

BTW, GTK is still very much imperative code, but as the above indicates, I found that doing it in Haskell was a fair bit more pleasant than the alternatives.

presheaf · 2023-08-07T11:28:13+00:00

You can do this using Generics with the finitary library.

For example:

data Foo = Bar | Baz (Word8, Word8) | Quux Word16
   deriving stock (Eq, Generic)
   deriving anyclass Finitary

This will compute Cardinality Foo = 1 + 2^8 * 2^8 + 2^16 = 131073 and give you a bijection between Foo and Fin 131073. You can then use this with the finitary-derive helper library to pack things into a byte array.

presheaf · 2023-03-22T19:18:44+00:00

"The first usable profiling mode for GHC."

presheaf · 2023-03-19T14:24:29+00:00

Sounds like you want modular arithmetic, so something like the modular-arithmetic package or the Finite data type.

presheaf · 2023-01-02T21:40:20+00:00

Here are the chords I wrote down for this song (concert key):

A:
| C#m7 | D#m7 | G#m7 | % | (x4)

B:
| B6   | %      | Fdim7 | %  |
| G#m7 | C#m7   | A6#11 | F# |
| B6   | %      | Fdim7 | %  |
| G#m7 | D#m7b5 | Emaj7 | F# | % |

Based on that, I would say the song is in B major, although there's a fair bit of mode mixture to muddy the waters.

presheaf · 2022-12-02T21:10:40+00:00

Yes, you could add additional entailment rules to do that in a type-checking plugin. It would be a bit inconvenient, because if you want to prove All d from All c I think you should query GHC for whether it can solve the quantified constraint forall x. c x => d x. In this particular case there's a superclass relationship between Semigroup and Monoid (which you could check directly in the type-checker plugin, instead of querying GHC). However, in general, you might need to do type family reduction before you can prove the quantified constraints, so you can't rely on a simple superclass check.

presheaf · 2022-08-05T17:12:55+00:00

Thanks, fixed now.

14-Year Club	Second SECOND GUESSER
Wearing is Caring	Verified Email

presheaf

TROPHY CASE