| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This also allowes me to make 'repl' into a universal command. This makes
it much easier to work across different projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I wanted to even further simplify the build tooling overhead. My general
goal is to not have to think about declaring packages, or dependencies,
or really anything that you might find in a cabal file. Not all of these
goals are possible, but we can get pretty close. With this commit all I
need for the 'buildGhc/buildGhcjs' functions is the path to the
entrypoint file; everything else is either inferred by the Nix code or
declared in the Haskell code comments.
The strategy is to map a Haskell module to an executable artifact, and
pass just that module to 'ghc --make'. Then we can rely on ghc to handle
walking the local filesystem for imports. The only thing ghc really
needs to know is a name for the output executable; it is hard to
automatically infer this, so we have a simple comment syntax to declare
this in the file. The comment syntax is inspired by existing Haskell
'LANGUAGE' pragmas; having this in the same file keeps the configuration
as close to the real code as possible. The Nix code then extracts this
info from the code comments, and sets the required ghc flags.
Second, we need to declare the set of 3rd-party packages that our
program relies on. For this we can re-use the same comment syntax and
just list the dependencies, then extract them in Nix and construct a
package set as we were before.
This reduces the amount of "package declaration" code we have to write
in default.nix, and reduces the amount of time we have to spend
switching between the Haskell code and the Nix code (I find such context
switching super annoying). I also think having the configuration in with
the Haskell code encourages us to write smaller, simpler modules and
only write code that we need.
Additionally, I refactored the bild and ghci (now called 'repl') scripts
to work in any directory. The .envrc uses direnv to set the path so that
you can run these scripts anywhere. That means the following works:
$ cd Run/Que
$ bild Website
$ repl Server
λ> :l Run.Que.Server
I find this to be a rather nice workflow.
|
|
|
|
I also block before taking, instead of doing a mult and tap. This is a
simple way to fix the memory issue, and makes them conceptually simpler
to work with I think.
The channels are still mutli-consumer and multi-producer, which is
fine. I'm not sure now I will implement the regular pubsub, but I'm not
sure there is a great usecase for that anyway.
|
|
If we've gotten past the first auth check then we are already
"authenticated", or whatever.
|
|
|
|
|
|
|
|
|
|
|
|
Turns out the ultimate reason was that I wasn't actually returning out
of the handler, I was just setting the HTTP status. Now I'm sure that it
works correctly.
|
|
|
|
First problem was that my `extract` function wasn't working. Second
problem was that nginx wasn't passing along the headers anyway.
|
|
|
|
So now _ is the special namespace that only I can post to. Unfortunately
I think the guardIP function is still broken.
|
|
curl was throwing an exception if the file got too long, because I was
passing the entire file contents in the arguments to curl. I tried using
a tmp file but that didn't work for some reason. So I switched to req
and that seems to work well.
I also made it faster by serving all pages concurrently, and I spruced
up the CSS a ton.
|
|
The scheme version of this is currently useless anyway.
|
|
|
|
Apparently guardIP wasn't working because it wasn't matching on the
right string, *and* I had typo'ed my IP address. I took this opportunity
to also organize the Scotty code a bit better with some comments.
|
|
|
|
This is a simple website server that uses que.run itself to host the que
webpages.
I had to rename Run.Que to Run.Que.Server because nix was
complaining about Run.Que being both a derivation and an attrset with
Run.Que.Website in it.
|
|
|
|
|
|
|
|
I'm using serval.simatime.com as a catch-all production app server for
now. The 'que.run' domain is pointed at that instance, and the service
is just installed as a regular NixOS systemd service.
I had to do some troubleshooting because I wasn't getting any DNS names
to resolve. I think changing the nameservers fixed it. Don't know why
the 127 number was in there.
Another issue concerns how to add our packages to the set of nixpkgs in
the generated NixOS. I played around with this for a while and landed on
using an overlay to put our set of packages under 'pkgs.biz.<name>', and
then passing that in to the 'buildOS' function. This isn't really the
best solution because it is confusing and rather disconnected. I'm
starting to realize that it might be good to separate nix artifacts into
"machines" and "programs", but I don't want to do that just yet. I'd
like to finish designing my bild program before making any large design
decisions or re-organizations.
|
|
|
|
|
|
|
|
|
|
Now that I have the domain name que.run! Aw yeah.
|
|
|
|
|
|
The performance is reportedly better. The API is simpler. Also with STM
channels, I couldn't get multiconsumer to work. I was able to get it to
work with unagi. Also I could write 'mult' and 'tap' which bring me back
to my Clojure days.
|
|
|
|
More generally, we could extend this to other settings, like 'main-is'
and target architecture to compile for and so on. It would be best to
define the parameters in Nix first, then later inline them to the
code comments after we've worked out the interface.
|
|
|
|
As much as I like these operators, I have to remove them because they
don't work as expected. Haskell doesn't allow you to have unary prefix
operators. I can't find a way around this, and it's not that important
anyway.
|
|
It's easier to remember what operators do, and thus easier to write and
read condens code, if they follow some symbolic pattern or visually
represent the concept to which they map. This is in part inspired by
hoon, in part by OCaml's operators.
I'm not married to these operators specifically, but I think they are
good so far.
|
|
|
|
|
|
|
|
|
|
Two functions makes it simpler to reason about what is being built and
when, even if it is a bit more explicit. I also removed the dumb
Apex/Aero naming thing because Server/Client is just easier to remember.
|
