lib-modules Public

Watch 0 Fork 0 Star 0
markdown · 2823 bytes Raw Blame History

Reference Libraries

This repo keeps tracked package code out of the umbrella tree, but it is still useful to study existing libraries before we start a new module.

Local comparison checkouts live under .refs/ and stay untracked. The tracked part of the workflow is:

  • this manifest
  • scripts/sync-refs.sh

Run the sync script from the umbrella root:

./scripts/sync-refs.sh

Current Read

The best next flagship still looks like fgof-keys.

Why:

  • it builds directly on fgof-termios, fgof-pty, and fgof-lineedit
  • terminal key handling is still undersupplied compared with process, fs, PTY, and raw terminal mode helpers
  • it creates a cleaner foundation for future fgof-screen and richer CLI or TUI work

The most interesting "crowded area we might still beat" is not another raw ncurses binding. It is a higher-level screen or rendering library such as a future fgof-screen.

Seed Reference Set

The first seed is intentionally small and focused. It is meant to support the next few likely package decisions without turning .refs/ into a dumping ground.

Group Repo Why it matters
stdlib fortran-lang/stdlib Standard-library baseline and overlap check
terminal-ui interkosmos/fortran-ncurses Modern thin ncurses binding baseline
terminal-ui urbanjost/M_ncurses Mature ncurses binding baseline
system urbanjost/M_process Existing process wrapper comparison
system urbanjost/M_system Existing POSIX and OS wrapper comparison
system interkosmos/fortran-unix Thin POSIX binding comparison
testing fortran-lang/test-drive Test utility baseline for fgof-proc-test
testing everythingfunctional/vegetables Alternate test utility baseline

What To Look For

When we compare against a deferred or already-served area, we should be asking:

  • Is the existing package a thin binding or a genuinely ergonomic library?
  • Does it have strong fpm support and examples?
  • Does it expose low-level C semantics directly to users?
  • Does it preserve literal strings and path data cleanly?
  • Does it provide a stable, app-author-friendly API or mainly raw wrappers?
  • Does it cover current compiler and CI expectations on macOS and Linux?

If the answer is "mostly thin wrappers," there is still room for an fgof-* package that offers a better developer surface.

Shortlist After The First Wave

  • fgof-keys
  • fgof-expect
  • fgof-proc-test
  • fgof-temp
  • fgof-clipboard
  • fgof-screen

Notes

  • .refs/ is intentionally untracked.
  • Add new comparison targets to the sync script and this manifest together.
  • If we decide to study a crowded area in depth, create a short audit note in this docs/ directory instead of committing cloned source.
View source
1 # Reference Libraries
2
3 This repo keeps tracked package code out of the umbrella tree, but it is still
4 useful to study existing libraries before we start a new module.
5
6 Local comparison checkouts live under `.refs/` and stay untracked. The tracked
7 part of the workflow is:
8
9 - this manifest
10 - `scripts/sync-refs.sh`
11
12 Run the sync script from the umbrella root:
13
14 ```bash
15 ./scripts/sync-refs.sh
16 ```
17
18 ## Current Read
19
20 The best next flagship still looks like `fgof-keys`.
21
22 Why:
23
24 - it builds directly on `fgof-termios`, `fgof-pty`, and `fgof-lineedit`
25 - terminal key handling is still undersupplied compared with process, fs, PTY,
26 and raw terminal mode helpers
27 - it creates a cleaner foundation for future `fgof-screen` and richer CLI or
28 TUI work
29
30 The most interesting "crowded area we might still beat" is not another raw
31 ncurses binding. It is a higher-level screen or rendering library such as a
32 future `fgof-screen`.
33
34 ## Seed Reference Set
35
36 The first seed is intentionally small and focused. It is meant to support the
37 next few likely package decisions without turning `.refs/` into a dumping
38 ground.
39
40 | Group | Repo | Why it matters |
41 | --- | --- | --- |
42 | `stdlib` | `fortran-lang/stdlib` | Standard-library baseline and overlap check |
43 | `terminal-ui` | `interkosmos/fortran-ncurses` | Modern thin ncurses binding baseline |
44 | `terminal-ui` | `urbanjost/M_ncurses` | Mature ncurses binding baseline |
45 | `system` | `urbanjost/M_process` | Existing process wrapper comparison |
46 | `system` | `urbanjost/M_system` | Existing POSIX and OS wrapper comparison |
47 | `system` | `interkosmos/fortran-unix` | Thin POSIX binding comparison |
48 | `testing` | `fortran-lang/test-drive` | Test utility baseline for `fgof-proc-test` |
49 | `testing` | `everythingfunctional/vegetables` | Alternate test utility baseline |
50
51 ## What To Look For
52
53 When we compare against a deferred or already-served area, we should be asking:
54
55 - Is the existing package a thin binding or a genuinely ergonomic library?
56 - Does it have strong `fpm` support and examples?
57 - Does it expose low-level C semantics directly to users?
58 - Does it preserve literal strings and path data cleanly?
59 - Does it provide a stable, app-author-friendly API or mainly raw wrappers?
60 - Does it cover current compiler and CI expectations on macOS and Linux?
61
62 If the answer is "mostly thin wrappers," there is still room for an `fgof-*`
63 package that offers a better developer surface.
64
65 ## Shortlist After The First Wave
66
67 - `fgof-keys`
68 - `fgof-expect`
69 - `fgof-proc-test`
70 - `fgof-temp`
71 - `fgof-clipboard`
72 - `fgof-screen`
73
74 ## Notes
75
76 - `.refs/` is intentionally untracked.
77 - Add new comparison targets to the sync script and this manifest together.
78 - If we decide to study a crowded area in depth, create a short audit note in
79 this `docs/` directory instead of committing cloned source.