macos support

[joelmccracken]

I just tried building this via nix and ran into some issues. I did hack the flake.nix file a little bit to get x86_64-darwin to have package, but I find that it still doesn't build for some reason that I really don't understand.

I wanted to try it out, but this is a blocker for me.

I haven't tired to build via other toolling, I may install ghcup and see if I can get it to build that way.

[joelmccracken]

Poked at it a bit more and I think this is where it goes wrong?

https://github.com/podenv/hspkgs/blob/main/flake.nix#L181-L184

at first I skimmed past it because I thought the commend above indicated that it was just used for testing, but if I am reading this code, it is used here, which is how it gets used elsewhere: https://github.com/podenv/hspkgs/blob/main/flake.nix#L255

I could be mistaken tho, I am not great at nix.

[TristanCacqueray]

Oh right, I'm not sure how to support different system with nix, and I only have Linux for testing, that's why I hardcoded the system value. For a non nix build, I could set the version bound and provide a cabal.project with the unreleased dependencies.

I think most apps will work on macos, however I tweaked the posix-pty (branch) library to use close_range, and by doing so I broke support for non linux target because I could not get it to build with the util library. So the terminal and the REPL are probably not usable on macos as of now.

[TristanCacqueray]

Also you might want to give Hyperbole a try: https://discourse.haskell.org/t/ann-hyperbole-interactive-html-applications-with-type-safe-serverside-haskell-like-typed-htmx/9607

[joelmccracken]

makes sense. If I hacked until it worked for macos, would you accept a PR (assuming it meets code expectations etc al)?

And FYI since github actions has macos runners, I would set up a macos runner to build it so you can work on it and see if something is broken.

hyperbole is interesting, though it seems essentially very different in terms of project goals to butler, which IIUC is a sort of OS-like framework for running individual apps with standardized services like what the OS would provide, right?

On Thu, May 23, 2024 at 11:44 AM Tristan de Cacqueray < @.***> wrote:

Also you might want to give Hyperbole a try: https://discourse.haskell.org/t/ann-hyperbole-interactive-html-applications-with-type-safe-serverside-haskell-like-typed-htmx/9607

— Reply to this email directly, view it on GitHub https://github.com/ButlerOS/haskell-butler/issues/57#issuecomment-2127458950, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACVODHT4ZXZNRQTXD6X63ZDYFHNAVCNFSM6AAAAABIEXFKOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXGQ2TQOJVGA . You are receiving this because you authored the thread.Message ID: @.***>

[TristanCacqueray]

Sure I would accept a PR, thank you for offering.

You are correct, butler provides extra facilities to host the applications, in particular leveraging ki to create a supervision tree. Though beware it's not exactly production ready, for example guest sessions are not garbage collected and this might results in a bad memory leak depending on your use case. That being said, I have been running the desktop demo for quite a while without much issues :)

I suggested Hyperbole because I think the display implementation is better as it seems like it takes care of sending the diff to the client, whereas butler relies on htmx update and apps need to manually send the parts that are updated (or send the whole html on each update), see for example the text editor logic when the file is saved:

https://github.com/ButlerOS/haskell-butler/blob/94fe2d1d043b50fe8cc41e308629cc701932a5e0/source/libraries/desktop/Butler/App/Noter.hs#L250

Here we explicitly update the fileNameForm, and I believe Hyperbole would do that automatically for you.

Another difference is that butler works for collaborative applications, see the difference between Butler.Display.serveApps and Butler.Display.serveDashboardApps.

Cheers!

[joelmccracken]

Cool, thanks. I've been wanting to make/use something like butler for years.

I have this vision of being able to make myself lots of tools in a style similar to what you're doing here: provide standardized OS-like services (file storage, user auth, etc), and you can then make lots of simple tools that work together within this environment (i.e. how you can write a lot of small shell scripts to solve tasks and customize workflows)

perhaps butler could be adapted to use that tech?

[TristanCacqueray]

That's the idea yes, but I can think of two shortcomings:

One of the missing piece is my implementation is the lack of linking between processes, for example to update one app structure (e.g. the list of connected client), when one of the client crashed unexpectedly.

The other tricky piece is to make two apps work together, here are a couple of example:

• The jira-client can start a poker-planner app which submit back the results through a websocket event:

Starting code: https://github.com/ButlerOS/haskell-butler/blob/94fe2d1d043b50fe8cc41e308629cc701932a5e0/source/libraries/desktop/Butler/App/JiraClient.hs#L96-L97

Reply code: https://github.com/ButlerOS/haskell-butler/blob/94fe2d1d043b50fe8cc41e308629cc701932a5e0/source/libraries/desktop/Butler/App/PokerPlanner.hs#L171

• The noter editor can forward the content to a REPL:

https://github.com/ButlerOS/haskell-butler/blob/94fe2d1d043b50fe8cc41e308629cc701932a5e0/source/libraries/desktop/Butler/App/Noter.hs#L103

… using the application event pipe and this helper:

https://github.com/ButlerOS/haskell-butler/blob/94fe2d1d043b50fe8cc41e308629cc701932a5e0/source/libraries/butler/Butler/App.hs#L76

That works, but I'm not super happy with this implementation, it looks a bit fragile.

Hope that helps, you should give it a try!