1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105

{:paths ["src"]

 ;; glimmer owns the reactive half (ratom, components, reconciler);
 ;; glimmer-vidya paints it as Vidya/egui through libvidya's retained-tree ABI.
 ;; Our fork of glimmer, until the reconciler fixes in it land upstream. A
 ;; component unmounted between a cell firing and the queued render running
 ;; used to render anyway, into widgets the backend had already freed and
 ;; handed out again — which took the message list apart in a busy channel.
 ;; And replacing a native node with one of another tag left every watcher
 ;; under it subscribed, so swapping the phone layout for the split one and
 ;; back shredded the chat: one component's props painted onto another's
 ;; widget.
 :deps {jolt-lang/glimmer   {:git/url "https://gitlab.com/nandithebull/glimmer"
                             :git/sha "399df371c790d690fb6e4560c3d4d7f838502857"}
        nandi/glimmer-vidya {:git/url "https://gitlab.com/nandithebull/jolt-native"
                             :git/sha "d970307ccf1fe67e2e971f2837d2282d8ba79a62"
                             :deps/root "glimmer-backends/glimmer-vidya"}}

 ;; Both objects come from gitlab.com/nandithebull/jolt-native, one crate each,
 ;; out of one target directory:
 ;;
 ;;   libvidya   the retained-tree ABI glimmer-vidya binds, on egui
 ;;   libjoltmoq the AV media plane — MoQ over QUIC, Opus, H.264, capture
 ;;
 ;; Calls are the one thing this client cannot do in jolt. Signaling is IRC and
 ;; lives in src/frq/av.clj; the media half is three thousand lines of codec
 ;; and transport that would only be written badly a second time here.
 ;;
 ;;   just run
 :jolt/native [{:name "vidya"
                :darwin ["libvidya.dylib"]
                :linux ["libvidya.so"]}
               {:name "joltmoq"
                :darwin ["libjoltmoq.dylib"]
                :linux ["libjoltmoq.so"]}
               ;; moq-ffi's own object, fetched from its release. Not a
               ;; second media plane: it is the TRANSPORT alone — MoQ over
               ;; QUIC, the one piece of a call with no C implementation
               ;; anywhere — and it is here so `frq.moq.*` has something to
               ;; load while the port off libjoltmoq happens. Both are
               ;; declared for now, and the day frq.av stops calling
               ;; joltmoq_* is the day that entry goes.
               ;;
               ;; The codecs are NOT in it: moq-ffi's audio and video
               ;; features are off in every Linux artifact upstream
               ;; publishes, and turning them on means compiling a
               ;; 1062-crate workspace. Opus and H.264 come from their own C
               ;; libraries instead, which is the whole point of doing this
               ;; over FFI rather than over a Rust facade.
               ;;
               ;; No :darwin: :systems is x86_64-linux and aarch64-linux, so
               ;; a .dylib named here would name a file nothing fetches.
               {:name "moq_ffi"
                :linux ["libmoq_ffi.so"]}

               ;; The codecs, as C libraries rather than as somebody's
               ;; bindings to them. Opus first; openh264 beside it when the
               ;; video half lands.
               ;;
               ;; The SONAME, not the bare .so: a `libopus.so` is the -dev
               ;; symlink and is not what a runtime closure carries. The
               ;; loader looks these up by name in one directory, which the
               ;; flake's `nativeAll` is.
               {:name "opus"
                :linux ["libopus.so.0"]
                :darwin ["libopus.0.dylib"]}

               ;; H.264, one step removed. openh264's C API is a vtable —
               ;; `ISVCEncoder` is `const ISVCEncoderVtbl*` — and jolt.ffi
               ;; can only call a literal C symbol, never a function
               ;; pointer. c/frq_h264.c walks the vtable and exports flat
               ;; symbols; this is that. libopenh264 itself comes along as
               ;; its DT_NEEDED and is never named here.
               {:name "frqh264"
                :linux ["libfrqh264.so"]
                :darwin ["libfrqh264.dylib"]}

               ;; Audio devices. No :darwin — CoreAudio is the other side of
               ;; that door and is not this library.
               ;;
               ;; V4L2 is deliberately absent from this list: the camera is
               ;; ioctls against libc and the kernel, so there is nothing to
               ;; load. See frq.capture.v4l2.
               {:name "asound"
                :linux ["libasound.so.2"]}]

 :aliases {:frq {:main-opts ["-m" "frq.app"]}

           ;; The same screens in a terminal. glimmer-tui is the other backend
           ;; for the same reconciler — libjolttui's tree ABI is libvidya's
           ;; with cells under it — so `frq.tui` requires it after `frq.app`
           ;; and renders the hiccup that is already written.
           ;;
           ;; A path rather than a sha, like glimmer-vidya's would be if this
           ;; alias were the way in: `just tui` builds jolt-native out of the
           ;; flake and hands both Jolt halves over with -Sdeps, so this is for
           ;; a checkout beside the tree and nothing else reads it.
           ;;
           ;;   just tui
           :tui {:extra-deps {nandi/glimmer-tui
                              {:local/root "../jolt-native/glimmer-backends/glimmer-tui"}}
                 :main-opts ["-m" "frq.tui"]}}

 :tasks {frq "jolt -M:frq"
         tui "jolt -M:tui"}}