| 26 Apr 2026 |
andromeda | that... seems like overkill. I'mma go with keeping the cabal.project in sync enough with the flake. | 14:21:01 |
sterni | cabal-install v2 commands expect build-tool-depends to be registered in the package db which Nix environments don't do because it is wrong from the perspective of the dependency separation: build tools go to nativeBuildInputs and not into (propagated)BuildInputs. Only the latter get folded into the package db. There is an open issue about this. Only affects developer environments.
Easiest workaround is to use the cabal-install v1 commands which check PATH for tools as well. | 14:33:49 |
sterni | ah alex already answered, nvm. | 14:34:29 |
sterni | aiya: I bumped Hackage two days ago, you can follow the progress there: https://github.com/NixOS/nixpkgs/pull/510883. Giving a timeline is hard, but the answer is weeks unfortunately at the moment. | 14:36:14 |
aiya | sterni i see, so maybe it is worth fixing, could you please elaborate on your latest comment here (https://github.com/NixOS/nixpkgs/pull/506489#discussion_r3110806985)? apologies, i don't fully understand it | 20:02:42 |
| 27 Apr 2026 |
| Mr Mayhem's Dumbass Labradoodle changed their display name from M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ Houston, we've had a Microsoft to M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐. | 00:11:10 |
| Mr Mayhem's Dumbass Labradoodle changed their display name from M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ to 👿👿👿M̸̙̜̔̇Ǎ̴͎̙͔G̸̞̈N̸͔͍̝͗͋̾Ő̷͖̼͈̽̚L̷̻͚̓̔I̷̛͔̰̟̔Å̴̩̍ ̷̦̒̇͝M̷̱̠̺̉̎A̵̼̎͗͘Ỹ̸̬̲͂̕H̷̙̖͂Ē̷͉̦̌͒M̶͈̥̽̐ 👹👹👹👹😈😈😈. | 00:12:37 |
| @psy1ynce:matrix.org left the room. | 01:34:06 |
| Ninja joined the room. | 14:26:22 |
| cat joined the room. | 23:41:34 |
| 30 Apr 2026 |
| whomstcall joined the room. | 07:52:14 |
alexfmpe | getting a duplicate symbol '_hourglass_clock_calendar' in: error when linking, but only on mac (or maybe it's a clang thing) I'm assuming it's because this fork of a vincent package defines the same C function?
https://github.com/vincenthz/hs-hourglass/blob/master/cbits/unix.c#L16 https://github.com/mpilgrem/time-hourglass/blob/main/cbits/unix.c
| 20:45:12 |
alexfmpe | huh it might be a gcc bug actually? https://stackoverflow.com/questions/64610024/duplicate-symbols-with-global-template-variable-using-clang | 20:48:37 |
alexfmpe | * huh the fact it works on gcc might be a bug actually? https://stackoverflow.com/questions/64610024/duplicate-symbols-with-global-template-variable-using-clang | 20:48:53 |
alexfmpe | * huh the fact it works on gcc might be a bug actually?
https://stackoverflow.com/questions/64610024/duplicate-symbols-with-global-template-variable-using-clang | 20:48:56 |
alexfmpe | are c-sources always exposed globally by GHC? can any two packages out there cause these collisions? | 20:51:31 |
alexfmpe | if so, should we, I dunno, patch the vincent package to rename the symbol? | 20:52:23 |
alexfmpe | In reply to @alexfmpe:matrix.org if so, should we, I dunno, patch the vincent package to rename the symbol? FWIW this worked locally | 22:18:17 |
winston | heya, I only just saw the recent-ish merge of the microhs changes, thanks for the work on that! ❤️
I think I've read up on the PR, but will hugs be the way microhs is getting build in the foreseeable future? I'm trying to add an override to get the mhseval binary to build, and was trying to understand the build process. Am I seeing this correctly that building with hugs currently closes off the possibility of building mhseval/mhseval.js?
https://github.com/augustss/MicroHs/blob/master/mhs/MhsEval.hs | 22:54:07 |
Alex | Yes, building with Hugs is currently the preferred way because it does not depend on any pre-generated code.
The stage 1 build uses a pre-existing mhs (usually runhugs wrapped mhs) with make.
The stage 2 build uses the stage 1 mhs with mcabal.
It's not immediately obvious to me how exactly mhseval.js is generated, but is there any reason you can't generate it using the stage 1 or stage 2 compiler? | 23:37:10 |
Alex | Since it seems to be a separate output, I would recommend using a different derivation instead of overriding the existing ones. | 23:39:01 |
winston | I was trying to get it to work via
mhseval = pkgs.haskell.compiler.microhs.overrideAttrs (prevAttrs: {
microhs-stage1 = prevAttrs.passthru.microhs-stage1.overrideAttrs {
nativeBuildInputs = [ pkgs.breakpointHook ];
postBuild = ''
make bin/mhseval
'';
postInstall = ''
cp bin/mhseval $out/bin/mhseval
'';
};
});
and didn't manage to get a useful output that way, I did try to copy it from stage1 to stage2 later, but I've changed a bunch of code around this
| 23:39:42 |
winston | currently I'm just doing a mkDerivation inheriting from src etc from pkgs.haskell.compiler.microhs, then postInstall'ing mhseval, so that works | 23:40:24 |
Alex | Is your ultimate desired hostPlatform one of the JS platforms? | 23:40:37 |
winston | not doing JS at the minute, so I haven't tried that yet, I just anticipate that there'll be some interest for that as well | 23:41:07 |
Alex | The other problem here is that mhseval is not in the Cabal file, so naturally the stage 2 build won't include it either. | 23:48:31 |
Alex | Unless JS is supported as a buildPlatform, I think it might be best to first make microhs compatible with cross.
I'm not sure what's missing for cross, but I suspect it has to do with the targetPlatform not being passed to the build. | 23:51:42 |
| 1 May 2026 |
Alex | Well, cross isn't terribly difficult. I've just gotten it working. | 00:46:32 |
| VegOwOtenks joined the room. | 14:58:29 |
VegOwOtenks | I'm starting out with nix and having trouble with system library fiddling. GHC cannot load the shared object for z3, though the C headers are found just fine.
This is my flake definition:
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
flake-utils.url = "github:numtide/flake-utils";
};
outputs = { self, nixpkgs, flake-utils }:
flake-utils.lib.eachDefaultSystem (system:
let
pkgs = import nixpkgs { inherit system; };
in {
devShells.default = with pkgs; mkShell
{
packages =
[ haskell.compiler.ghc914
z3
stack
libllvm
libclang
];
};
}
);
}
| 15:02:18 |