1.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2+++ b/.hgignore Sun Apr 28 19:51:45 2024 -0400
1.3@@ -0,0 +1,1 @@
1.4+[.]html
1.5\ No newline at end of file
2.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
2.2+++ b/20230730.org Sun Apr 28 19:51:45 2024 -0400
2.3@@ -0,0 +1,36 @@
2.4+* VC infrastructure
2.5+In heptapod we have a root group named =comp=, containg a variety of
2.6+subgroups. Some of these groups should be public, while others are
2.7+internal to comp members exclusively. Within each subgroup, we should
2.8+have the root group members automatically granted privileged access to
2.9+projects. This is relevant for the =startup= subgroup in particular,
2.10+where each project is potentially maintained by multiple non-root
2.11+contributors.
2.12+
2.13+We also need to consider how we will manage subrepos across the
2.14+organization. It is about time we start integrating HG bundles and
2.15+potentially mirrors. For our core VC pipeline we should have no
2.16+reliance on Git, but this may be difficult. It depends on the behavior
2.17+of HG bundles.
2.18+
2.19+Bookmarks/tags should be used for milestones in the root group and are
2.20+infrequent. They are more frequent in projects with a regular release
2.21+life-cycle.
2.22+* Approaching Webapps
2.23+I started poking around in the webapp space again so that I can launch
2.24+a landing page for NAS-T quickly. The Rust situation has improved
2.25+somewhat on the frontend side, and the axum backend stack is nice.
2.26+
2.27+This might seem like a lot of Rust and not a lot of Lisp, which it is,
2.28+but there's still room for Lisp wherever we need it. It mostly plays a
2.29+role in the backend, servicing the database and responding to requests
2.30+from the Rust edges. All of the important tests for the web APIs are
2.31+also written in Lisp. We will almost certainly use Lisp for all static
2.32+processing and HTML generation at compile-time.
2.33+
2.34+This I believe, is the appropriate way to integrate Lisp into a
2.35+cutting-edge web-app. You get the good parts of Lisp where you need
2.36+them (interactive debugging, dynamic language, REPL) and avoid the bad
2.37+parts (OOB optimization, RPS performance) in areas where the customer
2.38+would be impacted. In this domain, Lisp takes the form of a glue
2.39+rather than the bricks and mortar it sometimes appears to us as.
3.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
3.2+++ b/20231024.org Sun Apr 28 19:51:45 2024 -0400
3.3@@ -0,0 +1,59 @@
3.4+* virt
3.5+** QEMU
3.6+** KVM
3.7+** Hyper-V
3.8+** Firecracker
3.9+** Docker
3.10+** Vagrant
3.11+** LXC
3.12+** LXD
3.13+** containerd
3.14+** systemd-nspawn
3.15+** VirtualBox
3.16+
3.17+* Concatenative
3.18+** Factor :factor:
3.19+- [2023-07-04 Tue]
3.20+ Factor is a cool concatenative lang but unfortunately the C interface
3.21+ (vm/master.h) no longer exists on the master branch.
3.22+** Joy :joy:
3.23+
3.24+*** https://hypercubed.github.io/joy/html/j02maf.html
3.25+
3.26+*** [[https://builds.openlogicproject.org/content/incompleteness/arithmetization-syntax/arithmetization-syntax.pdf][arithmetization of syntax]]
3.27+* Lisp :lisp:
3.28+These notes pertain to Lisp. More specifically, ANSI Common Lisp in
3.29+most places.
3.30+
3.31+- https://github.com/lispnik/iup/ - doesn't support MacOS yet, looks
3.32+ cool though
3.33+ - what we really need is wasm compiler.. TBD
3.34+* Rust
3.35+** Serde
3.36+- [2023-07-05 Wed] \\
3.37+ important part of the Rust ecosystem, another dtolnay
3.38+ contribution. If you want to program a /data/ format in the Rust
3.39+ ecosystem, this is how you do it.
3.40+
3.41+ The way it works is that you define some special structs, a
3.42+ Serializer and a Deserializer which implement the Serialize and
3.43+ Deserialize traits provided by serde, respectively.
3.44+
3.45+ You can use these structs to provide your public API. The
3.46+ conventional choice is public top-level functions like from-str
3.47+ and to-string. That's it, your serialization library can now read and
3.48+ write your data format as Rust data types.
3.49+
3.50+ [[https://serde.rs/enum-representations.html][enum-representations]]
3.51+ - the default behavior is an externally tagged representation (verbose)
3.52+
3.53+ The docs use strings as core IO when implementing a custom format,
3.54+ but the convention is to implement for T where T is bound by std::io
3.55+ Read or Write trait. Then you can provide a more robust public API
3.56+ (from_bytes, from_writer, etc).
3.57+* C
3.58+* CPP
3.59+* Nu
3.60+[[https://www.nushell.sh/][~]]
3.61+[[https://www.nushell.sh/cookbook/][cookbook]]
3.62+[[https://github.com/nushell/nu_scripts][nu_scripts]]
4.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
4.2+++ b/20231101.org Sun Apr 28 19:51:45 2024 -0400
4.3@@ -0,0 +1,18 @@
4.4+* AWS usage
4.5+We're leveraging AWS for some of our public web servers for now. It's
4.6+really not realistic to expect that my home desktop and spotty Comcast
4.7+internet can serve any production workflow. What it /is/ capable of is
4.8+a private VPN, which can communicate with AWS and other cloud VPN
4.9+depots via WireGuard ([[https://dev.to/gabrieltetzner/setting-up-a-vpn-with-wireguard-server-on-aws-ec2-4a49][article]]).
4.10+
4.11+I currently use Google Domains for nas-t.net, otom8.dev, and
4.12+rwest.io - but that business is now owned by squarespace, so I would
4.13+rather move it to Route53.
4.14+
4.15+We have archlinux ec2 image builds [[https://wiki.archlinux.org/title/Arch_Linux_AMIs_for_Amazon_Web_Services][here]] and [[https://gitlab.com/anemos-io/archlinux-ec2][here]] - only half work and not
4.16+maintained, but it's a start. I'm not even sure if I should stick with
4.17+arch or cave and use Ubuntu or AWS Linux. We can serve the static
4.18+services with little cost, the only big spender will be the heptapod
4.19+instance which requires a larger instance and some workers.
4.20+
4.21+We'll try to keep the cost at or around $30/month.
5.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
5.2+++ b/20231102.org Sun Apr 28 19:51:45 2024 -0400
5.3@@ -0,0 +1,82 @@
5.4+* IDEAS
5.5+** TODO shed
5.6+:PROPERTIES:
5.7+:ID: fc9a94e1-91c5-4915-90b8-73218fa3b8bc
5.8+:END:
5.9+:LOGBOOK:
5.10+- State "TODO" from [2023-04-07 Fri 23:24]
5.11+:END:
5.12+rlib
5.13+> ulib
5.14+> ulib
5.15+> ulib
5.16+> ulib
5.17+
5.18+*** TODO sh* tools
5.19+:PROPERTIES:
5.20+:ID: c0613a13-7ccb-4af9-b47e-e14a41c782c2
5.21+:END:
5.22+:LOGBOOK:
5.23+- State "TODO" from "TODO" [2023-04-07 Fri 23:22]
5.24+:END:
5.25+shc,shx,etc
5.26+** WIP packy
5.27+:LOGBOOK:
5.28+- State "TODO" from [2023-04-07 Fri 23:33]
5.29+:END:
5.30+*** WIP rust
5.31+*** WIP common-lisp
5.32+*** WIP emacs-lisp
5.33+*** python
5.34+*** julia
5.35+*** C
5.36+*** C++
5.37+** TODO tenex
5.38+:LOGBOOK:
5.39+- State "TODO" from [2023-04-07 Fri 23:52]
5.40+:END:
5.41+** TODO mpk
5.42+:LOGBOOK:
5.43+- State "TODO" from [2023-04-07 Fri 23:52]
5.44+:END:
5.45+** TODO cfg
5.46+:LOGBOOK:
5.47+- State "TODO" from [2023-04-07 Fri 23:34]
5.48+:END:
5.49+** TODO obj
5.50+:LOGBOOK:
5.51+- State "TODO" from [2023-04-07 Fri 23:51]
5.52+:END:
5.53+split out from rlib to separate package
5.54+- a purely OOP class library
5.55+** TODO lab
5.56+:LOGBOOK:
5.57+- State "TODO" from [2023-04-07 Fri 23:34]
5.58+:END:
5.59+** TODO source categories
5.60+- need a way of extracting metadata from a repo
5.61+- need ability to search and query libs/packages
5.62+- separate modules based on where they belong in our stack?
5.63+ - app
5.64+ - lib
5.65+ - script?
5.66+ - dist
5.67+ - software distros
5.68+** TODO generic query language
5.69+from obj protocol?
5.70+sql compatibility?
5.71+
5.72+/check out kdb/
5.73+** TODO bbdb
5.74+:LOGBOOK:
5.75+- Note taken on [2023-10-24 Tue 22:16] \\
5.76+ graph database, build on rocksdb
5.77+:END:
5.78+insidious Big Brother database.
5.79+- an application built with obj
5.80+- sql
5.81+
5.82+** TODO NAS-TV :nas:t:
5.83+- media streaming
5.84+- gstreamer backend
5.85+- audio/video
6.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
6.2+++ b/20231105.org Sun Apr 28 19:51:45 2024 -0400
6.3@@ -0,0 +1,136 @@
6.4+* DRAFT dylib-skel-1
6.5+- State "DRAFT" from [2023-11-05 Sun 22:23]
6.6+** Overview
6.7+Our core languages are [[https://www.rust-lang.org/][Rust]] and [[https://lisp-lang.org/][Lisp]] - this is the killer combo which will allow NAS-T
6.8+to rapidly develop high-quality software. As such, it's crucial that these two very
6.9+different languages (i.e. compilers) are able to interoperate seamlessly.
6.10+
6.11+Some interop methods are easy to accomodate via the OS - such as IPC or data sharing,
6.12+but others are a bit more difficult.
6.13+
6.14+In this 2-part series we'll build a FFI bridge between Rust and Lisp, which is something
6.15+that /can/ be difficult, due to some complications with Rust and because this is not the
6.16+most popular software stack (yet ;). This is an experiment and may not make it to our
6.17+code-base, but it's definitely something worth adding to the toolbox in case we need it.
6.18+
6.19+** FFI
6.20+The level of interop we're after in this case is [[https://en.wikipedia.org/wiki/Foreign_function_interface][FFI]].
6.21+
6.22+Basically, calling Rust code from Lisp and vice-versa. There's an article about calling
6.23+Rust from Common Lisp [[https://dev.to/veer66/calling-rust-from-common-lisp-45c5][here]] which shows the basics and serves as a great starting point
6.24+for those interested.
6.25+*** Rust != C
6.26+The complication(s) with Rust I mentioned early is really just that /it is not C/. =C=
6.27+is old, i.e. well-supported with a stable ABI, making the process of creating bindings
6.28+for a C library a breeze in many languages.
6.29+
6.30+For a Rust library we need to first appease the compiler, as explained in [[https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c][this section]]
6.31+of the Rustonomicon. Among other things it involves changing the calling-convention of
6.32+functions with a type signature and editing the Cargo.toml file to produce a
6.33+C-compatible ABI binary. The Rust default ABI is unstable and can't reliably be used
6.34+like the C ABI can.
6.35+
6.36+*** Overhead
6.37+Using FFI involves some overhead. Check [[https://github.com/dyu/ffi-overhead][here]] for an example benchmark across a few
6.38+languages. While building the NAS-T core, I'm very much aware of this, and will need a
6.39+few sanity benchmarks to make sure the cost doesn't outweigh the benefit. In particular,
6.40+I'm concerned about crossing multiple language barriers (Rust<->C<->Lisp).
6.41+
6.42+** Rust -> C -> Lisp
6.43+*** Setup
6.44+For starters, I'm going to assume we all have Rust (via =rustup=) and Lisp (=sbcl= only)
6.45+installed on our GNU/Linux system (some tweaks needed for Darwin/Windows, not covered in
6.46+this post).
6.47+**** Cargo
6.48+Create a new library crate. For this example we're focusing on a 'skeleton' for
6.49+/dynamic/ libraries only, so our experiment will be called =dylib-skel= or *dysk* for
6.50+short.
6.51+src_sh[:exports code]{cargo init dysk --lib && cd dysk}
6.52+
6.53+A =src/lib.rs= will be generated for you. Go ahead and delete that. We're going to be
6.54+making our own =lib.rs= file directly in the root directory (just to be cool).
6.55+
6.56+The next step is to edit your =Cargo.toml= file. Add these lines after the =[package]=
6.57+section and before =[dependencies]=:
6.58+#+begin_src conf-toml
6.59+[lib]
6.60+crate-type = ["cdylib","rlib"]
6.61+path = "lib.rs"
6.62+[[bin]]
6.63+name="dysk-test"
6.64+path="test.rs"
6.65+#+end_src
6.66+
6.67+This tells Rust to generate a shared C-compatible object with a =.so= extension which we
6.68+can open using [[https://man.archlinux.org/man/dlopen.3.en][dlopen]].
6.69+**** cbindgen
6.70+***** install
6.71+Next, we want the =cbindgen= program which we'll use to generate header files for
6.72+C/C++. This step isn't necessary at all, we just want it for further experimentation.
6.73+
6.74+src_sh[:exports code]{cargo install --force cbindgen}
6.75+
6.76+We append the =cbindgen= crate as a /build dependency/ to our =Cargo.toml= like so:
6.77+#+begin_src conf-toml
6.78+[build-dependencies]
6.79+cbindgen = "0.24"
6.80+#+end_src
6.81+***** cbindgen.toml
6.82+#+begin_src conf-toml :tangle cbindgen.toml
6.83+language = "C"
6.84+autogen_warning = "/* Warning, this file is autogenerated by cbindgen. Don't modify this manually. */"
6.85+include_version = true
6.86+namespace = "dysk"
6.87+cpp_compat = true
6.88+after_includes = "#define DYSK_VERSION \"0.1.0\""
6.89+line_length = 88
6.90+tab_width = 2
6.91+documentation = true
6.92+documentation_style = "c99"
6.93+usize_is_size_t = true
6.94+[cython]
6.95+header = '"dysk.h"'
6.96+#+end_src
6.97+***** build.rs
6.98+#+begin_src rust :tangle build.rs
6.99+fn main() -> Result<(), cbindgen::Error> {
6.100+ if let Ok(b) = cbindgen::generate(std::env::var("CARGO_MANIFEST_DIR").unwrap()) {
6.101+ b.write_to_file("dysk.h"); Ok(())}
6.102+ else { panic!("failed to generate dysk.h from cbindgen.toml") } }
6.103+#+end_src
6.104+*** lib.rs
6.105+#+begin_src rust :tangle lib.rs
6.106+//! lib.rs --- dysk library
6.107+use std::ffi::{c_char, c_int, CString};
6.108+#[no_mangle]
6.109+pub extern "C" fn dysk_hello() -> *const c_char {
6.110+ CString::new("hello from rust").unwrap().into_raw()}
6.111+#[no_mangle]
6.112+pub extern "C" fn dysk_plus(a:c_int,b:c_int) -> c_int {a+b}
6.113+#[no_mangle]
6.114+pub extern "C" fn dysk_plus1(n:c_int) -> c_int {n+1}
6.115+#+end_src
6.116+*** test.rs
6.117+#+begin_src rust :tangle test.rs
6.118+//! test.rs --- dysk test
6.119+fn main() { let mut i = 0u32; while i < 500000000 {i+=1; dysk::dysk_plus1(2 as core::ffi::c_int);}}
6.120+#+end_src
6.121+*** compile
6.122+#+begin_src sh
6.123+cargo build --release
6.124+#+end_src
6.125+*** load from SBCL
6.126+#+begin_src lisp :tangle dysk.lisp
6.127+(load-shared-object #P"target/release/libdysk.so")
6.128+(define-alien-routine dysk-hello c-string)
6.129+(define-alien-routine dysk-plus int (a int) (b int))
6.130+(define-alien-routine dysk-plus1 int (n int))
6.131+(dysk-hello) ;; => "hello from rust"
6.132+#+end_src
6.133+*** benchmark
6.134+#+begin_src shell
6.135+time target/release/dysk-test
6.136+#+end_src
6.137+#+begin_src lisp :tangle test.lisp
6.138+(time (dotimes (_ 500000000) (dysk-plus1 2)))
6.139+#+end_src
7.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
7.2+++ b/20231124.org Sun Apr 28 19:51:45 2024 -0400
7.3@@ -0,0 +1,33 @@
7.4+* cl-dot examples
7.5+#+begin_src lisp
7.6+(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object cons))
7.7+ (make-instance 'cl-dot:node
7.8+ :attributes '(:label "cell \\N"
7.9+ :shape :box)))
7.10+(defmethod cl-dot:graph-object-points-to ((graph (eql 'example)) (object cons))
7.11+ (list (car object)
7.12+ (make-instance 'cl-dot:attributed
7.13+ :object (cdr object)
7.14+ :attributes '(:weight 3))))
7.15+;; Symbols
7.16+(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object symbol))
7.17+ (make-instance 'cl-dot:node
7.18+ :attributes `(:label ,object
7.19+ :shape :hexagon
7.20+ :style :filled
7.21+ :color :black
7.22+ :fillcolor "#ccccff")))
7.23+(let* ((data '(a b c #1=(b z) c d #1#))
7.24+ (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
7.25+ '(:rankdir "LR" :layout "twopi" :labelloc "t"))))
7.26+ (cl-dot:dot-graph dgraph "test-lr.svg" :format #+nil :x11 :svg))
7.27+#+end_src
7.28+
7.29+#+RESULTS:
7.30+
7.31+#+begin_src lisp
7.32+(let* ((data '(a b))
7.33+ (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
7.34+ '(:rankdir "LR"))))
7.35+ (cl-dot:print-graph dgraph))
7.36+#+end_src
8.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
8.2+++ b/20231205.org Sun Apr 28 19:51:45 2024 -0400
8.3@@ -0,0 +1,5 @@
8.4+* global refs
8.5+need a way of indexing, referring to, and annotating objects such as
8.6+URLs, docs, articles, source files, etc.
8.7+
8.8+What is the best way to get this done?
9.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
9.2+++ b/20231209.org Sun Apr 28 19:51:45 2024 -0400
9.3@@ -0,0 +1,5 @@
9.4+
9.5+* doc best practices
9.6+https://rust-lang.github.io/api-guidelines/documentation.html
9.7+
9.8+also: https://lisp-lang.org/style-guide/
10.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
10.2+++ b/20231212.org Sun Apr 28 19:51:45 2024 -0400
10.3@@ -0,0 +1,89 @@
10.4+* On Computers
10.5+If you've met me in the past decade, you probably know that I am
10.6+extremely passionate about computers. Let me first explain why.
10.7+
10.8+On the most basic level computers are little (or big) machines that
10.9+can be programmed to do things, or /compute/ if we're being
10.10+technical.[fn:1]
10.11+
10.12+They host and provide access to the Internet, which is a pretty big
10.13+thing, but they do little things too like unlock your car door and
10.14+tell your microwave to beep at you. They solve problems. Big or small.
10.15+
10.16+They're also /everywhere/ - which can be scary to think about, but
10.17+ultimately helps propel us into the future.
10.18+
10.19+There's something pretty cool about that - when you look at the
10.20+essence of computation. There are endless quantities of these machines
10.21+which follow the same basic rules and can be used to solve /real/
10.22+problems.
10.23+
10.24+** The Programmer
10.25+Now, let us consider the /programmer/. They have power. /real/
10.26+power. They understand the language of computers, can whisper to them
10.27+in various dialects. It can be intimidating to witness until you
10.28+realize how often the programmer says the wrong thing - a bug.
10.29+
10.30+In reality, the programmer has a symbiotic relationship with
10.31+computers. Good programmers understand this relationship well.
10.32+
10.33+#+begin_annecdote
10.34+One day after I got my first job at a software company, I remember
10.35+being on an all-hands meeting due to a client service outage. We had
10.36+some management, our lead devs, product team, and one curious looking
10.37+man who happened to be our lead IT consultant who had just joined. He
10.38+was sitting up on a hotel bed, shirtless, vaping an e-cig, typing
10.39+away in what I can only imagine was a shell prompt.
10.40+
10.41+After several minutes he took a swig from a bottle of Coke and said
10.42+"Node 6 is sick." then a few seconds later our services were
10.43+restored. For the next hour on the call he explained what happened and
10.44+why, but that particular phrase always stuck with me. He didn't say
10.45+Node 6 was down, or had an expired cert - his diagnosis was that /it/
10.46+was /sick/.
10.47+#+end_annecdote
10.48+
10.49+The more you work closely with computers, the more you start to think
10.50+of them this way. You don't start screaming when the computer does the
10.51+wrong thing, you figure out what's wrong and learn from it. With
10.52+experience, you start to understand the different behaviors of the
10.53+machines you work with. I like to call this /Machine Empathy/.
10.54+
10.55+** Programs
10.56+I already mentioned bugs - I write plenty of those, but usually I try
10.57+to write /programs/. Programs to me are like poetry. I like to think
10.58+they are for the computer too.
10.59+
10.60+Just like computers, /computer programs/ come in different shapes and
10.61+sizes but in basic terms they are sets of instructions used to control
10.62+a computer.
10.63+
10.64+You can write programs to do anything - when I first started, my
10.65+programs made music. The program was a means to an end. Over time, I
10.66+started to see the program as something much more. I saw it as the
10.67+music itself.
10.68+
10.69+[fn:1] ... perform computations
10.70+
10.71+
10.72+* On Infra
10.73+Something that is missing from many organizations big or large, is an
10.74+effective way to store and access information, even about their own
10.75+org.
10.76+
10.77+It can be difficult problem to solve - usually there's the official
10.78+one, say Microsoft Sharepoint and then the list of unofficial sources
10.79+which becomes tribal corporate hacker knowledge. Maybe the unofficial
10.80+ones are more current, or are annotated nicely, but their very
10.81+existence breaks the system. There's no longer a single source of
10.82+truth.
10.83+
10.84+My priority in this department is writing services which process and
10.85+store information from a variety of sources in a distributed knowledge
10.86+graph. The graph can later be queried to access information on-demand.
10.87+
10.88+My idea of infrastructure is in fact to build my own Cloud. Needless
10.89+to say I don't have an O365 subscription, and wherever possible I'll
10.90+be relying on hardware I have physical access to. I'm not opposed to
10.91+cloud services at large but based on principle I like to think we
10.92+shouldn't be built on them.
11.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
11.2+++ b/20231223.org Sun Apr 28 19:51:45 2024 -0400
11.3@@ -0,0 +1,3 @@
11.4+* https://cal-coop.gitlab.io/utena/utena-specification/main.pdf
11.5+from the author of cl-decentralise2. draft specification of a
11.6+/Maximalist/ Computing System.
12.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
12.2+++ b/20231224.org Sun Apr 28 19:51:45 2024 -0400
12.3@@ -0,0 +1,4 @@
12.4+* public datasets
12.5+https://github.com/awesomedata/awesome-public-datasets
12.6+https://docs.openml.org/Datasets/
12.7+https://wiki.pathmind.com/open-datasets
13.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
13.2+++ b/20231228.org Sun Apr 28 19:51:45 2024 -0400
13.3@@ -0,0 +1,40 @@
13.4+* useful internals
13.5+#+begin_src lisp
13.6+ sb-sys:*runtime-dlhandle*
13.7+ sb-fasl:+fasl-file-version+
13.8+ sb-fasl:+backend-fasl-file-implementation+
13.9+ sb-debug:print-backtrace
13.10+ sb-debug:map-backtrace
13.11+ sb-pretty:pprint-dispatch-table
13.12+ sb-lockless:
13.13+ sb-ext:simd-pack
13.14+ sb-walker:define-walker-template
13.15+ sb-walker:macroexpand-all
13.16+ sb-walker:walk-form
13.17+ sb-kernel:empty-type
13.18+ sb-kernel:*eval-calls*
13.19+ sb-kernel:*gc-pin-code-pages*
13.20+ sb-kernel:*restart-clusters*
13.21+ sb-kernel:*save-lisp-clobbered-globals*
13.22+ sb-kernel:*top-level-form-p*
13.23+ sb-kernel:*universal-fun-type*
13.24+ sb-kernel:*universal-type*
13.25+ sb-kernel:*wild-type*
13.26+ sb-kernel:+simd-pack-element-types+
13.27+ (sb-vm:memory-usage)
13.28+ (sb-vm:boxed-context-register)
13.29+ (sb-vm:c-find-heap->arena)
13.30+ (sb-vm:copy-number-to-heap)
13.31+ (sb-vm:dump-arena-objects)
13.32+ (sb-vm:fixnumize)
13.33+ (sb-vm:rewind-arena)
13.34+ (sb-vm:show-heap->arena)
13.35+ (sb-vm:with/without-arena)
13.36+ (sb-cltl2:{augment-environment,compiler-let,define-declaration,parse-macro})
13.37+ (sb-cltl2:{declaration-information, variable-information, function-information})
13.38+ sb-di:
13.39+ sb-assem:
13.40+ sb-md5:
13.41+ sb-regalloc:
13.42+ sb-disassem:
13.43+#+end_src
14.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
14.2+++ b/20240103.org Sun Apr 28 19:51:45 2024 -0400
14.3@@ -0,0 +1,27 @@
14.4+* [[https://github.com/sigmf/SigMF][SigMF]]
14.5+#+begin_quote
14.6+Sharing sets of recorded signal data is an important part of science
14.7+and engineering. It enables multiple parties to collaborate, is often
14.8+a necessary part of reproducing scientific results (a requirement of
14.9+scientific rigor), and enables sharing data with those who do not have
14.10+direct access to the equipment required to capture it.
14.11+
14.12+Unfortunately, these datasets have historically not been very
14.13+portable, and there is not an agreed upon method of sharing metadata
14.14+descriptions of the recorded data itself. This is the problem that
14.15+SigMF solves.
14.16+
14.17+By providing a standard way to describe data recordings, SigMF
14.18+facilitates the sharing of data, prevents the "bitrot" of datasets
14.19+wherein details of the capture are lost over time, and makes it
14.20+possible for different tools to operate on the same dataset, thus
14.21+enabling data portability between tools and workflows.
14.22+#+end_quote
14.23+
14.24+the-spec: https://github.com/sigmf/SigMF/blob/sigmf-v1.x/sigmf-spec.md
14.25+* [[https://www.libvolk.org/][LibVOLK]]
14.26+Vector-Optimized Library of Kernels (simd)
14.27+* [[https://docs.kernel.org/fb/framebuffer.html][/dev/fb*]]
14.28+framebuffers, used by fbgrab/fbcat program
14.29+* [[https://docs.kernel.org/block/ublk.html][ublk]]
14.30+https://github.com/ming1/ubdsrv
15.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
15.2+++ b/20240104.org Sun Apr 28 19:51:45 2024 -0400
15.3@@ -0,0 +1,6 @@
15.4+goals:
15.5+make problems smaller.
15.6+
15.7+sections:
15.8+why lisp?
15.9+- doesn't need mentioning more and more
16.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
16.2+++ b/20240120.org Sun Apr 28 19:51:45 2024 -0400
16.3@@ -0,0 +1,36 @@
16.4+* TODO taobench demo
16.5+:LOGBOOK:
16.6+- State "TODO" from [2024-01-21 Sun 00:32]
16.7+:END:
16.8+https://github.com/audreyccheng/taobench - shouldn't have missed this :)
16.9+obviously we need to implement this using core -- in demo/bench/tao?
16.10+* TODO clap completion for nushell
16.11+:LOGBOOK:
16.12+- State "TODO" from [2024-01-20 Sat 23:23]
16.13+:END:
16.14+https://github.com/clap-rs/clap/tree/master/clap_complete_nushell
16.15+* Dataframe scripting
16.16+https://studioterabyte.nl/en/blog/polars-vs-pandas
16.17+nushell supports DFs, polars underneath?
16.18+https://www.nushell.sh/book/cheat_sheet.html
16.19+
16.20+#+begin_src nushell
16.21+
16.22+#+end_src
16.23+* Cloud Squatting
16.24+** Google
16.25+- [[https://cloud.google.com/free/docs/free-cloud-features][Free Cloud Features]]
16.26+ + 90-day $300 credits
16.27+ + e2-micro - free hours worth 1 instance/month
16.28+ +
16.29+** Amazon
16.30+- AWS Free Tier
16.31+** Akamai
16.32+- Linode Free Trial
16.33+** Oracle
16.34+- [[https://www.oracle.com/cloud/free/?intcmp=ohp052322ocift][OCI Free Tier]]
16.35+ + always free: 2 x oracle autonomous DB
16.36+ + 2 x AMD Compute VMs
16.37+ + up to 4 x ARM Ampere A1 with 3k/cpu/hr and 18k/gb/h per month
16.38+ + block/object/archive storage
16.39+ + 30-day $300 credits
17.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
17.2+++ b/20240129.org Sun Apr 28 19:51:45 2024 -0400
17.3@@ -0,0 +1,67 @@
17.4+* NOTE trash as block device
17.5+:LOGBOOK:
17.6+- State "NOTE" from [2024-01-29 Mon 20:53]
17.7+- State "NOTE" from [2024-01-29 Mon 20:53]
17.8+:END:
17.9+in nushell there is option for rm command to always use 'trash' -
17.10+AFAIK the current approach is via a service (trashd).
17.11+
17.12+An interesting experiment would be to designate a block device as
17.13+'trash' - may be possible to remove reliance on a service
17.14+
17.15+may be an opportunity for ublk driver to shine - instead of /dev/null
17.16+piping we need a driver for streaming a file to /dev/trash
17.17+* NOTE compute power
17.18+:LOGBOOK:
17.19+- State "NOTE" from [2024-01-29 Mon 16:28]
17.20+:END:
17.21+- mostly x86_64 machines - currently 2 AWS EC2 instances, some podman containers, and our home beowulf server:
17.22+- beowulf:
17.23+ - Zor
17.24+ - mid-size tower enclosed (Linux/Windows)
17.25+ - CPU
17.26+ - Intel Core i7-6700K
17.27+ - 4 @ 4.0
17.28+ - GPU
17.29+ - NVIDIA GeForce GTX 1060
17.30+ - 6GB
17.31+ - Storage
17.32+ - Samsung SSD 850: 232.9GB
17.33+ - Samsung SSD 850: 465.76GB
17.34+ - ST2000DM001-1ER1: 1.82TB
17.35+ - WDC WD80EAZZ-00B: 7.28TB
17.36+ - PSSD T7 Shield: 3.64TB
17.37+ - My Passport 0820: 1.36TB
17.38+ - RAM
17.39+ - 16GB (2*8) [64GB max]
17.40+ - DDR4
17.41+ - Jekyll
17.42+ - MacBook Pro 2019 (MacOS/Darwin)
17.43+ - CPU
17.44+ - Intel
17.45+ - 8 @
17.46+ - RAM
17.47+ - 32G DDR4
17.48+ - Hyde
17.49+ - Thinkpad
17.50+ - CPU
17.51+ - Intel
17.52+ - 4 @
17.53+ - RAM
17.54+ - 24G DDR3
17.55+ - Boris
17.56+ - Pinephone Pro
17.57+ - CPU
17.58+ - 64-bit 6-core 4x ARM Cortex A53 + 2x ARM Cortex A72
17.59+ - GPU
17.60+ - Mali T860MP4
17.61+ - RAM
17.62+ - 4GB LPDDR4
17.63+ - pi
17.64+ - Raspberry Pi 4 Model B
17.65+ - CPU
17.66+ - Cortex-A72 (ARM v8) 64-bit SoC
17.67+ - 4 @ 1.8GHz
17.68+ - RAM
17.69+ - 8 GB
17.70+ - DDR4 4200
18.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
18.2+++ b/20240210.org Sun Apr 28 19:51:45 2024 -0400
18.3@@ -0,0 +1,13 @@
18.4+* BigBenches
18.5+#+name: 1trc-nu
18.6+#+begin_src nushell
18.7+ let ms = '1trc/measurements-0.parquet'
18.8+ dfr open $ms
18.9+ | dfr group-by station
18.10+ | dfr agg [
18.11+ (dfr col measure | dfr min | dfr as "min")
18.12+ (dfr col measure | dfr max | dfr as "max")
18.13+ (dfr col measure | dfr sum | dfr as "sum")
18.14+ (dfr col measure | dfr count | dfr as "count")
18.15+ ]
18.16+#+end_src
19.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
19.2+++ b/20240218.org Sun Apr 28 19:51:45 2024 -0400
19.3@@ -0,0 +1,75 @@
19.4+* NOTE WL vs X
19.5+:LOGBOOK:
19.6+- State "NOTE" from [2024-02-18 Sun 11:55]
19.7+:END:
19.8+In the past few months there has been drama regarding Wayland vs X. It
19.9+seems to be on everyone's minds after Artem's freakout issue and the
19.10+follow up YT vids/comments.
19.11+
19.12+I admit that it made me reconsider the fitness of WL as a whole -
19.13+there was a github gist that made some scathing arguments against it.
19.14+
19.15+It's an odd debate though. I think there are many misunderstandings.
19.16+
19.17+So first off, if we look at the homepage
19.18+https://wayland.freedesktop.org/, Wayland claims it is a replacement
19.19+for X11. It now has /manifest destiny/, which in my opinion is a great
19.20+shame.
19.21+
19.22+X-pros seem to agree that Wayland has /manifest destiny/ - like if you
19.23+are building softwares that look remotely like a window system, it's a
19.24+successor to X. That's the model of doing things and there's no way
19.25+around it.
19.26+
19.27+The disagreement starts with how this destiny - of an X2 - should be
19.28+fulfilled. X-pros want a fork of X, but it's too late for
19.29+that. WL-pros want X to run on top of Wayland compositor:
19.30+https://wayland.freedesktop.org/xserver.html.
19.31+
19.32+Xwayland is a problem for me. From the project description: 'if we're
19.33+migrating away from X, it makes sense to have a good backwards
19.34+compatibility story.' Full disclosure: I have never done significant
19.35+work on Xwayland, so perhaps my opinion is unwarranted. But I have no
19.36+intention of attempting to maintain a computer system that uses
19.37+Wayland and X clients at the same time.
19.38+
19.39+To me, X is ol' reliable. Every distro has first-class X support, and
19.40+it runs on most systems with very little user intervention. Where it
19.41+doesn't, there is 20+ years of dev history and battle-tested
19.42+workarounds for you to find your solution in.
19.43+
19.44+Wayland is the new kid on the block, born just in 2008. It's a fresh
19.45+start to one of the most difficult challenges in software - window
19.46+systems. A re-write would be pointless though, and so the real
19.47+value-add is in design. Wayland is designed as a protocol and
19.48+collection of libraries which are implemented in your own
19.49+compositor. Coming from Lisp - with ANSI Common Lisp and SRFIs, this
19.50+feels right even if the implementation is something very different
19.51+(compositor vs compiler).
19.52+
19.53+With X, it is assumed to be much harder to write an equivalent
19.54+'compositor'. Here's the thing though - with a significantly complex X
19.55+client implementation, it is /impossible/ to replicate in WL. This is
19.56+really the crux of Artemi's argument in his issue. He asked for a 1:1
19.57+equivalent X/WL comparison when no such thing exists, and in my
19.58+opinion it is a waste of time.
19.59+
19.60+The WL core team is fully aware of this dichotomy, but also that this
19.61+is in no way a problem or weakness in either system. It means they're
19.62+different systems, goddammit.
19.63+
19.64+If it was up to me, Xwayland wouldn't exist. I understand why it does,
19.65+and that it does make things easier for developers who need to support
19.66+both, and users who have multiple apps with multiple windowing
19.67+requirements. It's a bandaid though, and one that is particularly
19.68+dangerous because it re-enforces the idea that Wayland is just X2 and
19.69+that they're fully compatible.
19.70+
19.71+What interests me in the Wayland world right now is the idea of a
19.72+small, modular, full-stack Wayland compositor API. There are several
19.73+'kiosk' based compositors for single applications (cage), but these
19.74+aren't complete solutions. It is possible to get much closer to the
19.75+metal, and that's where I want to be so that I can build my own APIs
19.76+on top - I don't want to live on top of X, and I certainly don't want
19.77+to live on top of X on top of WL. I want a /pure/ solution that hides
19.78+as little as possible, exposing the interesting bits.
20.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
20.2+++ b/20240301.org Sun Apr 28 19:51:45 2024 -0400
20.3@@ -0,0 +1,6 @@
20.4+* TODO collect more data
20.5+:LOGBOOK:
20.6+- State "TODO" from [2024-03-01 Fri 15:27]
20.7+:END:
20.8+https://www.csie.ntu.edu.tw/~cjlin/libsvmtools/datasets/
20.9+weather - music - etc
21.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
21.2+++ b/20240302.org Sun Apr 28 19:51:45 2024 -0400
21.3@@ -0,0 +1,117 @@
21.4+* NOTE On blocks and devices
21.5+:LOGBOOK:
21.6+- State "NOTE" from [2024-03-02 Sat 21:30]
21.7+:END:
21.8+[[https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/dev.html][/dev]]
21.9+In Linux, everything is a file.
21.10+
21.11+/dev/ contains special device files - usually block or character
21.12+device.
21.13+
21.14+major, minor = category, device
21.15+0, 5
21.16+
21.17+mknod - create special device files
21.18+
21.19+[[https://www.redhat.com/en/blog/linux-block-devices-hints-debugging-and-new-developments][redhat hints]]
21.20+
21.21+#+begin_src shell
21.22+ dd if=/dev/zero of=myfile bs=1M count=32
21.23+ losetup --show -f myfile
21.24+ ls -al /dev/loop0
21.25+ losetup -d /dev/loop0 #teardown
21.26+#+end_src
21.27+
21.28+#+begin_src shell
21.29+ echo "sup dude" > /dev/loop0
21.30+ dd if=/dev/loop0 -bs=1
21.31+ dd if=/dev/nvme0 of=/dev/null progress=true
21.32+ #pacman -S hdparm
21.33+ hdparm -T /dev/nvme0
21.34+#+end_src
21.35+
21.36+#+begin_src shell
21.37+modprobe scsi_debug add_host=5 max_luns=10 num_tgts=2 dev_size_mb=16
21.38+#+end_src
21.39+
21.40+sparsefiles: create with C, dd, or truncate
21.41+
21.42+#+begin_src shell :results output
21.43+truncate --help
21.44+#+end_src
21.45+
21.46+#+RESULTS:
21.47+#+begin_example
21.48+Usage: truncate OPTION... FILE...
21.49+Shrink or extend the size of each FILE to the specified size
21.50+
21.51+A FILE argument that does not exist is created.
21.52+
21.53+If a FILE is larger than the specified size, the extra data is lost.
21.54+If a FILE is shorter, it is extended and the sparse extended part (hole)
21.55+reads as zero bytes.
21.56+
21.57+Mandatory arguments to long options are mandatory for short options too.
21.58+ -c, --no-create do not create any files
21.59+ -o, --io-blocks treat SIZE as number of IO blocks instead of bytes
21.60+ -r, --reference=RFILE base size on RFILE
21.61+ -s, --size=SIZE set or adjust the file size by SIZE bytes
21.62+ --help display this help and exit
21.63+ --version output version information and exit
21.64+
21.65+The SIZE argument is an integer and optional unit (example: 10K is 10*1024).
21.66+Units are K,M,G,T,P,E,Z,Y,R,Q (powers of 1024) or KB,MB,... (powers of 1000).
21.67+Binary prefixes can be used, too: KiB=K, MiB=M, and so on.
21.68+
21.69+SIZE may also be prefixed by one of the following modifying characters:
21.70+'+' extend by, '-' reduce by, '<' at most, '>' at least,
21.71+'/' round down to multiple of, '%' round up to multiple of.
21.72+
21.73+GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
21.74+Full documentation <https://www.gnu.org/software/coreutils/truncate>
21.75+or available locally via: info '(coreutils) truncate invocation'
21.76+#+end_example
21.77+
21.78+test mkfs.btrfs on 10T dummy block device
21.79+#+begin_src shell
21.80+ dd if=/dev/zero of=/tmp/bb1 bs=1 count=1 seek=10T
21.81+ du -sh /tmp/bb1
21.82+ losetup --show -f /tmp/bb1
21.83+ mkfs.btrfs /dev/loop0
21.84+#+end_src
21.85+
21.86+diagnostics
21.87+#+begin_src shell
21.88+ iostat # pacman -S sysstat
21.89+ blktrace # paru -S blktrace
21.90+ iotop # pacman -S iotop
21.91+#+end_src
21.92+
21.93+bcc/ trace: Who/which process is executing specific functions against
21.94+block devices?
21.95+
21.96+bcc/biosnoop: Which process is accessing the block device, how many
21.97+bytes are accessed, which latency for answering the requests?
21.98+
21.99+at the kernel level besides BPF we got kmods and DKMS,
21.100+
21.101+compression/de-duplication can be done via VDO kernel mod
21.102+
21.103+https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
21.104+
21.105+* NOTE save-lisp-and-respawn
21.106+:LOGBOOK:
21.107+- State "NOTE" from [2024-03-02 Sat 22:57]
21.108+:END:
21.109+#+begin_src lisp
21.110+ sb-ext:*save-hooks*
21.111+#+end_src
21.112+
21.113+* NOTE syslog for log
21.114+:LOGBOOK:
21.115+- State "NOTE" from [2024-03-03 Sun 16:35]
21.116+:END:
21.117+sb-posix:
21.118+- openlog syslog closelog
21.119+- levels: emerg alert crit err warning notice info debug
21.120+- setlogmask
22.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
22.2+++ b/20240313.org Sun Apr 28 19:51:45 2024 -0400
22.3@@ -0,0 +1,6 @@
22.4+* RESEARCH [[https://github.com/guicho271828/sbcl-wiki/wiki/][sbcl-wiki]]
22.5+:LOGBOOK:
22.6+- State "RESEARCH" from [2024-03-13 Wed 21:49]
22.7+:END:
22.8+** IR1
22.9+** IR2
23.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
23.2+++ b/20240317.org Sun Apr 28 19:51:45 2024 -0400
23.3@@ -0,0 +1,49 @@
23.4+* NOTE DB Benchmarking
23.5+:LOGBOOK:
23.6+- State "NOTE" from [2024-02-04 Sun 20:40]
23.7+:END:
23.8+[[https://github.com/facebook/rocksdb/wiki/Benchmarking-tools][RocksDB benchmarking tools]]
23.9+
23.10+* NOTE packy design
23.11+:PROPERTIES:
23.12+:ID: 76ae24f5-46e8-4b91-8991-41245383d337
23.13+:END:
23.14+:LOGBOOK:
23.15+- State "NOTE" from [2024-01-25 Thu 22:39]
23.16+:END:
23.17+- API root: https://packy.compiler.company
23.18+- source packs: https://vc.compiler.company/packy
23.19+** Lib
23.20+*** Types
23.21+**** Pack
23.22+Primary data type of the library - typically represents a compressed
23.23+archive, metadata, and ops.
23.24+**** Bundle
23.25+Collection data type, usually contains a set of packs with metadata.
23.26+**** PackyEndpoint
23.27+Represents a Packy instance bound to a UDP socket
23.28+**** PackyEndpointConfig
23.29+Global endpoint configuration object
23.30+**** PackyClientConfig
23.31+Configuration for outgoing packy connections on an endpoint
23.32+**** PackyServerConfig
23.33+Configuration for incoming packy connection son an endpoint
23.34+**** PackyConnection
23.35+Packy connection object
23.36+*** Traits
23.37+**** PackyClient
23.38+***** query
23.39+***** install
23.40+***** update
23.41+***** login
23.42+***** logout
23.43+***** pull
23.44+***** push
23.45+**** PackyServer
23.46+***** start_packy_server
23.47+***** stop_packy_server
23.48+***** start_packy_registry
23.49+**** PackyRegistry
23.50+***** register_pack
23.51+***** register_user
23.52+***** register_bundle
24.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
24.2+++ b/20240325.org Sun Apr 28 19:51:45 2024 -0400
24.3@@ -0,0 +1,8 @@
24.4+* TBD investigate alieneval for phash opps
24.5+:LOGBOOK:
24.6+- State "TBD" from [2024-03-25 Mon 18:56]
24.7+:END:
24.8+* TBD
24.9+:LOGBOOK:
24.10+- State "TBD" from [2024-03-25 Mon 18:57]
24.11+:END:
25.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
25.2+++ b/20240419.org Sun Apr 28 19:51:45 2024 -0400
25.3@@ -0,0 +1,86 @@
25.4+#+title: demo-old-readme
25.5+* How it works
25.6+The backend services are written in Rust and controlled by a simple
25.7+messaging protocol. Services provide common runtime capabilities known
25.8+as the /service protocol/ but are specialized on a unique /service
25.9+type/ which may in turn register their own /custom protocols/ (via
25.10+core).
25.11+
25.12+Services are capable of dispatching data directly to clients, or
25.13+storing data in the /database/ (sqlite, postgres, mysql).
25.14+
25.15+The frontend clients are pre-dominantly written in Common Lisp and
25.16+come in many shapes and sizes. There is a cli-client, web-client
25.17+(CLOG), docker-client (archlinux, stumpwm, McCLIM), and native-client
25.18+which also compiles to WASM (slint-rs).
25.19+
25.20+* Guide
25.21+** Build
25.22+- *install dependencies*
25.23+ #+begin_src bash
25.24+ ./tools/deps.sh
25.25+ #+end_src
25.26+- *make executables* \\
25.27+ Simply run =make build=. Read the ~makefile~ and change the options
25.28+ as needed.
25.29+- MODE :: Mode (debug, release)
25.30+- LISP :: Lisp (sbcl, cmucl, ccl)
25.31+- CFG :: Config (default.cfg)
25.32+** Run
25.33+#+begin_src shell
25.34+ ./demo -i
25.35+#+end_src
25.36+** Config
25.37+Configs can be specified in JSON, TOML, RON, or of course SEXP. See
25.38+=default.cfg= for an example.
25.39+** Play
25.40+The high-level user interface is presented as a multi-modal GUI
25.41+application which adapts to the specific application /instances/
25.42+below.
25.43+*** Weather
25.44+This backend retrieves weather data using the NWS API.
25.45+*** Stocks
25.46+The 'Stocks' backend features a stock ticker with real-time analysis
25.47+capabilities.
25.48+*** Bench
25.49+This is a benchmark backend for testing the capabilities of our
25.50+demo. It spins up some mock services and allows fine-grained control
25.51+of input/throughput.
25.52+* tasks
25.53+** TODO DSLs
25.54+- consider tree-sitter parsing layout, use as a guide for developing a
25.55+ single syntax which expands to Rust or C.
25.56+- with-rs
25.57+- with-c
25.58+- with-rs/c
25.59+- with-cargo
25.60+- compile-rs/c
25.61+*** TODO rs-macroexpand
25.62+- rs-gen-file
25.63+- rs-defmacro
25.64+- rs-macros
25.65+- rs-macroexpand
25.66+- rs-macroexpand-1
25.67+*** TODO c-macroexpand
25.68+- c-gen-file h/c
25.69+- c-defmacro
25.70+- c-macros
25.71+- c-macroexpand
25.72+- c-macroexpand-1
25.73+*** TODO slint-macroexpand
25.74+- slint-gen-file
25.75+- slint-defmacro
25.76+- slint-macros
25.77+- slint-macroexpand
25.78+- slint-macroexpand-1
25.79+*** TODO html (using who)
25.80+** TODO web templates
25.81+create a basic static page in CL which will be used to host Slint UIs
25.82+and other WASM doo-dads in a browser.
25.83+** TODO CLI
25.84+using clingon, decide on generic options and write it up
25.85+** TODO docs
25.86+work on doc generation -- Rust and CL should be accounted for.
25.87+** TODO tests
25.88+We have none! need to make it more comfy - set up testing in all Rust
25.89+crates and for the lisp systems.
26.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
26.2+++ b/20240425.org Sun Apr 28 19:51:45 2024 -0400
26.3@@ -0,0 +1,1 @@
26.4+* https://docs.gitlab.com/ee/administration/backup_restore/migrate_to_new_server.html
27.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
27.2+++ b/refs.bib Sun Apr 28 19:51:45 2024 -0400
27.3@@ -0,0 +1,169 @@
27.4+@article{btrfs,
27.5+author = {Rodeh, Ohad and Bacik, Josef and Mason, Chris},
27.6+year = {2013},
27.7+month = {08},
27.8+pages = {},
27.9+title = {BTRFS: The linux B-tree filesystem},
27.10+volume = {9},
27.11+journal = {ACM Transactions on Storage (TOS)},
27.12+doi = {10.1145/2501620.2501623}
27.13+}
27.14+@INPROCEEDINGS{zfs,
27.15+ author={Rodeh, O. and Teperman, A.},
27.16+ booktitle={20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003. (MSST 2003). Proceedings.},
27.17+ title={zFS - a scalable distributed file system using object disks},
27.18+ year={2003},
27.19+ volume={},
27.20+ number={},
27.21+ pages={207-218},
27.22+ doi={10.1109/MASS.2003.1194858}}
27.23+
27.24+@inproceedings{tmpfs,
27.25+ title={tmpfs: A Virtual Memory File System},
27.26+ author={Peter Snyder},
27.27+ year={1990},
27.28+ url={https://api.semanticscholar.org/CorpusID:54156693}
27.29+}
27.30+
27.31+@Article{nvme-ssd-ux,
27.32+AUTHOR = {Kim, Seongmin and Kim, Kyusik and Shin, Heeyoung and Kim, Taeseok},
27.33+TITLE = {Practical Enhancement of User Experience in NVMe SSDs},
27.34+JOURNAL = {Applied Sciences},
27.35+VOLUME = {10},
27.36+YEAR = {2020},
27.37+NUMBER = {14},
27.38+ARTICLE-NUMBER = {4765},
27.39+URL = {https://www.mdpi.com/2076-3417/10/14/4765},
27.40+ISSN = {2076-3417},
27.41+DOI = {10.3390/app10144765}
27.42+}
27.43+
27.44+@inproceedings{ext4,
27.45+author = {Djordjevic, Borislav and Timcenko, Valentina},
27.46+title = {Ext4 File System Performance Analysis in Linux Environment},
27.47+year = {2011},
27.48+isbn = {9781618040282},
27.49+publisher = {World Scientific and Engineering Academy and Society (WSEAS)},
27.50+address = {Stevens Point, Wisconsin, USA},
27.51+booktitle = {Proceedings of the 11th WSEAS International Conference on Applied Informatics and Communications, and Proceedings of the 4th WSEAS International Conference on Biomedical Electronics and Biomedical Informatics, and Proceedings of the International Conference on Computational Engineering in Systems Applications},
27.52+pages = {288–293},
27.53+numpages = {6},
27.54+keywords = {Linux, journaling, ext4/ext3/ext2, filesystems, inodes, disk performances, file block allocation},
27.55+location = {Florence, Italy},
27.56+series = {AIASABEBI'11}
27.57+}
27.58+
27.59+@Article{hd-failure-ml,
27.60+AUTHOR = {Zhang, Mingyu and Ge, Wenqiang and Tang, Ruichun and Liu, Peishun},
27.61+TITLE = {Hard Disk Failure Prediction Based on Blending Ensemble Learning},
27.62+JOURNAL = {Applied Sciences},
27.63+VOLUME = {13},
27.64+YEAR = {2023},
27.65+NUMBER = {5},
27.66+ARTICLE-NUMBER = {3288},
27.67+URL = {https://www.mdpi.com/2076-3417/13/5/3288},
27.68+ISSN = {2076-3417},
27.69+DOI = {10.3390/app13053288}
27.70+}
27.71+
27.72+@inproceedings{smart-ssd-qp,
27.73+author = {Do, Jaeyoung and Kee, Yang-Suk and Patel, Jignesh M. and Park, Chanik and Park, Kwanghyun and DeWitt, David J.},
27.74+title = {Query Processing on Smart SSDs: Opportunities and Challenges},
27.75+year = {2013},
27.76+isbn = {9781450320375},
27.77+publisher = {Association for Computing Machinery},
27.78+address = {New York, NY, USA},
27.79+url = {https://doi.org/10.1145/2463676.2465295},
27.80+doi = {10.1145/2463676.2465295},
27.81+booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
27.82+pages = {1221–1230},
27.83+numpages = {10},
27.84+keywords = {smart ssd},
27.85+location = {New York, New York, USA},
27.86+series = {SIGMOD '13}
27.87+}
27.88+
27.89+@inproceedings{ssd-perf-opt,
27.90+author = {Zuck, Aviad and G\"{u}hring, Philipp and Zhang, Tao and Porter, Donald E. and Tsafrir, Dan},
27.91+title = {Why and How to Increase SSD Performance Transparency},
27.92+year = {2019},
27.93+isbn = {9781450367271},
27.94+publisher = {Association for Computing Machinery},
27.95+address = {New York, NY, USA},
27.96+url = {https://doi.org/10.1145/3317550.3321430},
27.97+doi = {10.1145/3317550.3321430},
27.98+booktitle = {Proceedings of the Workshop on Hot Topics in Operating Systems},
27.99+pages = {192–200},
27.100+numpages = {9},
27.101+location = {Bertinoro, Italy},
27.102+series = {HotOS '19}
27.103+}
27.104+
27.105+@article{flash-openssd-systems,
27.106+author = {Kwak, Jaewook and Lee, Sangjin and Park, Kibin and Jeong, Jinwoo and Song, Yong Ho},
27.107+title = {Cosmos+ OpenSSD: Rapid Prototype for Flash Storage Systems},
27.108+year = {2020},
27.109+issue_date = {August 2020},
27.110+publisher = {Association for Computing Machinery},
27.111+address = {New York, NY, USA},
27.112+volume = {16},
27.113+number = {3},
27.114+issn = {1553-3077},
27.115+url = {https://doi.org/10.1145/3385073},
27.116+doi = {10.1145/3385073},
27.117+journal = {ACM Trans. Storage},
27.118+month = {jul},
27.119+articleno = {15},
27.120+numpages = {35},
27.121+keywords = {storage system, solid state drive (SSD), flash translation layer (FTL), Flash memory}
27.122+}
27.123+
27.124+@INPROCEEDINGS{emmc-mobile-io,
27.125+ author={Zhou, Deng and Pan, Wen and Wang, Wei and Xie, Tao},
27.126+ booktitle={2015 IEEE International Symposium on Workload Characterization},
27.127+ title={I/O Characteristics of Smartphone Applications and Their Implications for eMMC Design},
27.128+ year={2015},
27.129+ volume={},
27.130+ number={},
27.131+ pages={12-21},
27.132+ doi={10.1109/IISWC.2015.8}}
27.133+
27.134+@inproceedings{xfs-scalability,
27.135+ author = {Adam Sweeney and
27.136+ Doug Doucette and
27.137+ Wei Hu and
27.138+ Curtis Anderson and
27.139+ Mike Nishimoto and
27.140+ Geoff Peck},
27.141+ title = {Scalability in the {XFS} File System},
27.142+ booktitle = {Proceedings of the {USENIX} Annual Technical Conference, San Diego,
27.143+ California, USA, January 22-26, 1996},
27.144+ pages = {1--14},
27.145+ publisher = {{USENIX} Association},
27.146+ year = {1996},
27.147+ url = {http://www.usenix.org/publications/library/proceedings/sd96/sweeney.html},
27.148+ timestamp = {Wed, 04 Jul 2018 13:06:34 +0200},
27.149+ biburl = {https://dblp.org/rec/conf/usenix/Sweeney96.bib},
27.150+ bibsource = {dblp computer science bibliography, https://dblp.org}
27.151+}
27.152+
27.153+@inproceedings{xfs,
27.154+ title={xFS: A wide area mass storage file system},
27.155+ author={Wang, Randolph Y and Anderson, Thomas E},
27.156+ booktitle={Proceedings of IEEE 4th Workshop on Workstation Operating Systems. WWOS-III},
27.157+ pages={71--78},
27.158+ year={1993},
27.159+ organization={IEEE}
27.160+}
27.161+
27.162+@inproceedings {zns-usenix,
27.163+author = {Matias Bj{\o}rling and Abutalib Aghayev and Hans Holmberg and Aravind Ramesh and Damien Le Moal and Gregory R. Ganger and George Amvrosiadis},
27.164+title = {{ZNS}: Avoiding the Block Interface Tax for Flash-based {SSDs}},
27.165+booktitle = {2021 USENIX Annual Technical Conference (USENIX ATC 21)},
27.166+year = {2021},
27.167+isbn = {978-1-939133-23-6},
27.168+pages = {689--703},
27.169+url = {https://www.usenix.org/conference/atc21/presentation/bjorling},
27.170+publisher = {USENIX Association},
27.171+month = jul,
27.172+}
27.173\ No newline at end of file
28.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
28.2+++ b/vocab Sun Apr 28 19:51:45 2024 -0400
28.3@@ -0,0 +1,19 @@
28.4+;;; docs/vocab --- project glossary -*- mode:outline;outline-regexp:"[-]+" -*-
28.5+- wrt : With Respect To
28.6+- nyi : Not Yet Implemented
28.7+- rt : Regression Testing
28.8+- vm : Virtual Machine
28.9+- asm : Assembly
28.10+- comp : Compiler
28.11+- eval : Evaluate
28.12+- alloc : Allocate
28.13+- ret : Return
28.14+- tco : Tail-call Optimization
28.15+- reg : Register
28.16+- sbcl : Steel Bank Common Lisp
28.17+- rs : Rust (the language)
28.18+- el : Emacs Lisp
28.19+- cl : Common Lisp
28.20+- pcl : Practical Common Lisp
28.21+- taomop : The Art of the Meta Object Protocol
28.22+- lol : Let Over Lambda
