1.1--- a/.hgsub Wed Jan 10 19:02:43 2024 -0500
1.2+++ b/.hgsub Tue Apr 30 22:16:29 2024 -0400
1.3@@ -1,2 +1,4 @@
1.4 blog=https://vc.compiler.company/comp/blog
1.5-docs=https://vc.compiler.company/comp/docs
1.6\ No newline at end of file
1.7+docs=https://vc.compiler.company/comp/docs
1.8+notes=notes
1.9+roadmap=roadmap
1.10\ No newline at end of file
2.1--- a/.hgsubstate Wed Jan 10 19:02:43 2024 -0500
2.2+++ b/.hgsubstate Tue Apr 30 22:16:29 2024 -0400
2.3@@ -1,2 +1,4 @@
2.4-b6380832df99ead6c390a664bdf3b5623444a978 blog
2.5-2601788ab8056c66fed0fb2c63acbda1fb617576 docs
2.6+d77884ec2b44578aed4268cd374d559cd7643470 blog
2.7+6932edcf60ecc20bc51f89e8131a962a8aa58b7c docs
2.8+87b04952fb18f2eb67d3ca17ae1c745c6aa91c44 notes
2.9+70c3464617973e82b02ff481bf300f2bdbe9de01 roadmap
3.1--- a/notes/20230730.org Wed Jan 10 19:02:43 2024 -0500
3.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
3.3@@ -1,36 +0,0 @@
3.4-* VC infrastructure
3.5-In heptapod we have a root group named =comp=, containg a variety of
3.6-subgroups. Some of these groups should be public, while others are
3.7-internal to comp members exclusively. Within each subgroup, we should
3.8-have the root group members automatically granted privileged access to
3.9-projects. This is relevant for the =startup= subgroup in particular,
3.10-where each project is potentially maintained by multiple non-root
3.11-contributors.
3.12-
3.13-We also need to consider how we will manage subrepos across the
3.14-organization. It is about time we start integrating HG bundles and
3.15-potentially mirrors. For our core VC pipeline we should have no
3.16-reliance on Git, but this may be difficult. It depends on the behavior
3.17-of HG bundles.
3.18-
3.19-Bookmarks/tags should be used for milestones in the root group and are
3.20-infrequent. They are more frequent in projects with a regular release
3.21-life-cycle.
3.22-* Approaching Webapps
3.23-I started poking around in the webapp space again so that I can launch
3.24-a landing page for NAS-T quickly. The Rust situation has improved
3.25-somewhat on the frontend side, and the axum backend stack is nice.
3.26-
3.27-This might seem like a lot of Rust and not a lot of Lisp, which it is,
3.28-but there's still room for Lisp wherever we need it. It mostly plays a
3.29-role in the backend, servicing the database and responding to requests
3.30-from the Rust edges. All of the important tests for the web APIs are
3.31-also written in Lisp. We will almost certainly use Lisp for all static
3.32-processing and HTML generation at compile-time.
3.33-
3.34-This I believe, is the appropriate way to integrate Lisp into a
3.35-cutting-edge web-app. You get the good parts of Lisp where you need
3.36-them (interactive debugging, dynamic language, REPL) and avoid the bad
3.37-parts (OOB optimization, RPS performance) in areas where the customer
3.38-would be impacted. In this domain, Lisp takes the form of a glue
3.39-rather than the bricks and mortar it sometimes appears to us as.
4.1--- a/notes/20231024.org Wed Jan 10 19:02:43 2024 -0500
4.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
4.3@@ -1,59 +0,0 @@
4.4-* virt
4.5-** QEMU
4.6-** KVM
4.7-** Hyper-V
4.8-** Firecracker
4.9-** Docker
4.10-** Vagrant
4.11-** LXC
4.12-** LXD
4.13-** containerd
4.14-** systemd-nspawn
4.15-** VirtualBox
4.16-
4.17-* Concatenative
4.18-** Factor :factor:
4.19-- [2023-07-04 Tue]
4.20- Factor is a cool concatenative lang but unfortunately the C interface
4.21- (vm/master.h) no longer exists on the master branch.
4.22-** Joy :joy:
4.23-
4.24-*** https://hypercubed.github.io/joy/html/j02maf.html
4.25-
4.26-*** [[https://builds.openlogicproject.org/content/incompleteness/arithmetization-syntax/arithmetization-syntax.pdf][arithmetization of syntax]]
4.27-* Lisp :lisp:
4.28-These notes pertain to Lisp. More specifically, ANSI Common Lisp in
4.29-most places.
4.30-
4.31-- https://github.com/lispnik/iup/ - doesn't support MacOS yet, looks
4.32- cool though
4.33- - what we really need is wasm compiler.. TBD
4.34-* Rust
4.35-** Serde
4.36-- [2023-07-05 Wed] \\
4.37- important part of the Rust ecosystem, another dtolnay
4.38- contribution. If you want to program a /data/ format in the Rust
4.39- ecosystem, this is how you do it.
4.40-
4.41- The way it works is that you define some special structs, a
4.42- Serializer and a Deserializer which implement the Serialize and
4.43- Deserialize traits provided by serde, respectively.
4.44-
4.45- You can use these structs to provide your public API. The
4.46- conventional choice is public top-level functions like from-str
4.47- and to-string. That's it, your serialization library can now read and
4.48- write your data format as Rust data types.
4.49-
4.50- [[https://serde.rs/enum-representations.html][enum-representations]]
4.51- - the default behavior is an externally tagged representation (verbose)
4.52-
4.53- The docs use strings as core IO when implementing a custom format,
4.54- but the convention is to implement for T where T is bound by std::io
4.55- Read or Write trait. Then you can provide a more robust public API
4.56- (from_bytes, from_writer, etc).
4.57-* C
4.58-* CPP
4.59-* Nu
4.60-[[https://www.nushell.sh/][~]]
4.61-[[https://www.nushell.sh/cookbook/][cookbook]]
4.62-[[https://github.com/nushell/nu_scripts][nu_scripts]]
5.1--- a/notes/20231101.org Wed Jan 10 19:02:43 2024 -0500
5.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
5.3@@ -1,18 +0,0 @@
5.4-* AWS usage
5.5-We're leveraging AWS for some of our public web servers for now. It's
5.6-really not realistic to expect that my home desktop and spotty Comcast
5.7-internet can serve any production workflow. What it /is/ capable of is
5.8-a private VPN, which can communicate with AWS and other cloud VPN
5.9-depots via WireGuard ([[https://dev.to/gabrieltetzner/setting-up-a-vpn-with-wireguard-server-on-aws-ec2-4a49][article]]).
5.10-
5.11-I currently use Google Domains for nas-t.net, otom8.dev, and
5.12-rwest.io - but that business is now owned by squarespace, so I would
5.13-rather move it to Route53.
5.14-
5.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
5.16-maintained, but it's a start. I'm not even sure if I should stick with
5.17-arch or cave and use Ubuntu or AWS Linux. We can serve the static
5.18-services with little cost, the only big spender will be the heptapod
5.19-instance which requires a larger instance and some workers.
5.20-
5.21-We'll try to keep the cost at or around $30/month.
6.1--- a/notes/20231102.org Wed Jan 10 19:02:43 2024 -0500
6.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
6.3@@ -1,82 +0,0 @@
6.4-* IDEAS
6.5-** TODO shed
6.6-:PROPERTIES:
6.7-:ID: fc9a94e1-91c5-4915-90b8-73218fa3b8bc
6.8-:END:
6.9-:LOGBOOK:
6.10-- State "TODO" from [2023-04-07 Fri 23:24]
6.11-:END:
6.12-rlib
6.13-> ulib
6.14-> ulib
6.15-> ulib
6.16-> ulib
6.17-
6.18-*** TODO sh* tools
6.19-:PROPERTIES:
6.20-:ID: c0613a13-7ccb-4af9-b47e-e14a41c782c2
6.21-:END:
6.22-:LOGBOOK:
6.23-- State "TODO" from "TODO" [2023-04-07 Fri 23:22]
6.24-:END:
6.25-shc,shx,etc
6.26-** WIP packy
6.27-:LOGBOOK:
6.28-- State "TODO" from [2023-04-07 Fri 23:33]
6.29-:END:
6.30-*** WIP rust
6.31-*** WIP common-lisp
6.32-*** WIP emacs-lisp
6.33-*** python
6.34-*** julia
6.35-*** C
6.36-*** C++
6.37-** TODO tenex
6.38-:LOGBOOK:
6.39-- State "TODO" from [2023-04-07 Fri 23:52]
6.40-:END:
6.41-** TODO mpk
6.42-:LOGBOOK:
6.43-- State "TODO" from [2023-04-07 Fri 23:52]
6.44-:END:
6.45-** TODO cfg
6.46-:LOGBOOK:
6.47-- State "TODO" from [2023-04-07 Fri 23:34]
6.48-:END:
6.49-** TODO obj
6.50-:LOGBOOK:
6.51-- State "TODO" from [2023-04-07 Fri 23:51]
6.52-:END:
6.53-split out from rlib to separate package
6.54-- a purely OOP class library
6.55-** TODO lab
6.56-:LOGBOOK:
6.57-- State "TODO" from [2023-04-07 Fri 23:34]
6.58-:END:
6.59-** TODO source categories
6.60-- need a way of extracting metadata from a repo
6.61-- need ability to search and query libs/packages
6.62-- separate modules based on where they belong in our stack?
6.63- - app
6.64- - lib
6.65- - script?
6.66- - dist
6.67- - software distros
6.68-** TODO generic query language
6.69-from obj protocol?
6.70-sql compatibility?
6.71-
6.72-/check out kdb/
6.73-** TODO bbdb
6.74-:LOGBOOK:
6.75-- Note taken on [2023-10-24 Tue 22:16] \\
6.76- graph database, build on rocksdb
6.77-:END:
6.78-insidious Big Brother database.
6.79-- an application built with obj
6.80-- sql
6.81-
6.82-** TODO NAS-TV :nas:t:
6.83-- media streaming
6.84-- gstreamer backend
6.85-- audio/video
7.1--- a/notes/20231105.org Wed Jan 10 19:02:43 2024 -0500
7.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
7.3@@ -1,136 +0,0 @@
7.4-* DRAFT dylib-skel-1
7.5-- State "DRAFT" from [2023-11-05 Sun 22:23]
7.6-** Overview
7.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
7.8-to rapidly develop high-quality software. As such, it's crucial that these two very
7.9-different languages (i.e. compilers) are able to interoperate seamlessly.
7.10-
7.11-Some interop methods are easy to accomodate via the OS - such as IPC or data sharing,
7.12-but others are a bit more difficult.
7.13-
7.14-In this 2-part series we'll build a FFI bridge between Rust and Lisp, which is something
7.15-that /can/ be difficult, due to some complications with Rust and because this is not the
7.16-most popular software stack (yet ;). This is an experiment and may not make it to our
7.17-code-base, but it's definitely something worth adding to the toolbox in case we need it.
7.18-
7.19-** FFI
7.20-The level of interop we're after in this case is [[https://en.wikipedia.org/wiki/Foreign_function_interface][FFI]].
7.21-
7.22-Basically, calling Rust code from Lisp and vice-versa. There's an article about calling
7.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
7.24-for those interested.
7.25-*** Rust != C
7.26-The complication(s) with Rust I mentioned early is really just that /it is not C/. =C=
7.27-is old, i.e. well-supported with a stable ABI, making the process of creating bindings
7.28-for a C library a breeze in many languages.
7.29-
7.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]]
7.31-of the Rustonomicon. Among other things it involves changing the calling-convention of
7.32-functions with a type signature and editing the Cargo.toml file to produce a
7.33-C-compatible ABI binary. The Rust default ABI is unstable and can't reliably be used
7.34-like the C ABI can.
7.35-
7.36-*** Overhead
7.37-Using FFI involves some overhead. Check [[https://github.com/dyu/ffi-overhead][here]] for an example benchmark across a few
7.38-languages. While building the NAS-T core, I'm very much aware of this, and will need a
7.39-few sanity benchmarks to make sure the cost doesn't outweigh the benefit. In particular,
7.40-I'm concerned about crossing multiple language barriers (Rust<->C<->Lisp).
7.41-
7.42-** Rust -> C -> Lisp
7.43-*** Setup
7.44-For starters, I'm going to assume we all have Rust (via =rustup=) and Lisp (=sbcl= only)
7.45-installed on our GNU/Linux system (some tweaks needed for Darwin/Windows, not covered in
7.46-this post).
7.47-**** Cargo
7.48-Create a new library crate. For this example we're focusing on a 'skeleton' for
7.49-/dynamic/ libraries only, so our experiment will be called =dylib-skel= or *dysk* for
7.50-short.
7.51-src_sh[:exports code]{cargo init dysk --lib && cd dysk}
7.52-
7.53-A =src/lib.rs= will be generated for you. Go ahead and delete that. We're going to be
7.54-making our own =lib.rs= file directly in the root directory (just to be cool).
7.55-
7.56-The next step is to edit your =Cargo.toml= file. Add these lines after the =[package]=
7.57-section and before =[dependencies]=:
7.58-#+begin_src conf-toml
7.59-[lib]
7.60-crate-type = ["cdylib","rlib"]
7.61-path = "lib.rs"
7.62-[[bin]]
7.63-name="dysk-test"
7.64-path="test.rs"
7.65-#+end_src
7.66-
7.67-This tells Rust to generate a shared C-compatible object with a =.so= extension which we
7.68-can open using [[https://man.archlinux.org/man/dlopen.3.en][dlopen]].
7.69-**** cbindgen
7.70-***** install
7.71-Next, we want the =cbindgen= program which we'll use to generate header files for
7.72-C/C++. This step isn't necessary at all, we just want it for further experimentation.
7.73-
7.74-src_sh[:exports code]{cargo install --force cbindgen}
7.75-
7.76-We append the =cbindgen= crate as a /build dependency/ to our =Cargo.toml= like so:
7.77-#+begin_src conf-toml
7.78-[build-dependencies]
7.79-cbindgen = "0.24"
7.80-#+end_src
7.81-***** cbindgen.toml
7.82-#+begin_src conf-toml :tangle cbindgen.toml
7.83-language = "C"
7.84-autogen_warning = "/* Warning, this file is autogenerated by cbindgen. Don't modify this manually. */"
7.85-include_version = true
7.86-namespace = "dysk"
7.87-cpp_compat = true
7.88-after_includes = "#define DYSK_VERSION \"0.1.0\""
7.89-line_length = 88
7.90-tab_width = 2
7.91-documentation = true
7.92-documentation_style = "c99"
7.93-usize_is_size_t = true
7.94-[cython]
7.95-header = '"dysk.h"'
7.96-#+end_src
7.97-***** build.rs
7.98-#+begin_src rust :tangle build.rs
7.99-fn main() -> Result<(), cbindgen::Error> {
7.100- if let Ok(b) = cbindgen::generate(std::env::var("CARGO_MANIFEST_DIR").unwrap()) {
7.101- b.write_to_file("dysk.h"); Ok(())}
7.102- else { panic!("failed to generate dysk.h from cbindgen.toml") } }
7.103-#+end_src
7.104-*** lib.rs
7.105-#+begin_src rust :tangle lib.rs
7.106-//! lib.rs --- dysk library
7.107-use std::ffi::{c_char, c_int, CString};
7.108-#[no_mangle]
7.109-pub extern "C" fn dysk_hello() -> *const c_char {
7.110- CString::new("hello from rust").unwrap().into_raw()}
7.111-#[no_mangle]
7.112-pub extern "C" fn dysk_plus(a:c_int,b:c_int) -> c_int {a+b}
7.113-#[no_mangle]
7.114-pub extern "C" fn dysk_plus1(n:c_int) -> c_int {n+1}
7.115-#+end_src
7.116-*** test.rs
7.117-#+begin_src rust :tangle test.rs
7.118-//! test.rs --- dysk test
7.119-fn main() { let mut i = 0u32; while i < 500000000 {i+=1; dysk::dysk_plus1(2 as core::ffi::c_int);}}
7.120-#+end_src
7.121-*** compile
7.122-#+begin_src sh
7.123-cargo build --release
7.124-#+end_src
7.125-*** load from SBCL
7.126-#+begin_src lisp :tangle dysk.lisp
7.127-(load-shared-object #P"target/release/libdysk.so")
7.128-(define-alien-routine dysk-hello c-string)
7.129-(define-alien-routine dysk-plus int (a int) (b int))
7.130-(define-alien-routine dysk-plus1 int (n int))
7.131-(dysk-hello) ;; => "hello from rust"
7.132-#+end_src
7.133-*** benchmark
7.134-#+begin_src shell
7.135-time target/release/dysk-test
7.136-#+end_src
7.137-#+begin_src lisp :tangle test.lisp
7.138-(time (dotimes (_ 500000000) (dysk-plus1 2)))
7.139-#+end_src
8.1--- a/notes/20231124.org Wed Jan 10 19:02:43 2024 -0500
8.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
8.3@@ -1,33 +0,0 @@
8.4-* cl-dot examples
8.5-#+begin_src lisp
8.6-(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object cons))
8.7- (make-instance 'cl-dot:node
8.8- :attributes '(:label "cell \\N"
8.9- :shape :box)))
8.10-(defmethod cl-dot:graph-object-points-to ((graph (eql 'example)) (object cons))
8.11- (list (car object)
8.12- (make-instance 'cl-dot:attributed
8.13- :object (cdr object)
8.14- :attributes '(:weight 3))))
8.15-;; Symbols
8.16-(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object symbol))
8.17- (make-instance 'cl-dot:node
8.18- :attributes `(:label ,object
8.19- :shape :hexagon
8.20- :style :filled
8.21- :color :black
8.22- :fillcolor "#ccccff")))
8.23-(let* ((data '(a b c #1=(b z) c d #1#))
8.24- (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
8.25- '(:rankdir "LR" :layout "twopi" :labelloc "t"))))
8.26- (cl-dot:dot-graph dgraph "test-lr.svg" :format #+nil :x11 :svg))
8.27-#+end_src
8.28-
8.29-#+RESULTS:
8.30-
8.31-#+begin_src lisp
8.32-(let* ((data '(a b))
8.33- (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
8.34- '(:rankdir "LR"))))
8.35- (cl-dot:print-graph dgraph))
8.36-#+end_src
9.1--- a/notes/20231205.org Wed Jan 10 19:02:43 2024 -0500
9.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
9.3@@ -1,5 +0,0 @@
9.4-* global refs
9.5-need a way of indexing, referring to, and annotating objects such as
9.6-URLs, docs, articles, source files, etc.
9.7-
9.8-What is the best way to get this done?
10.1--- a/notes/20231209.org Wed Jan 10 19:02:43 2024 -0500
10.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
10.3@@ -1,5 +0,0 @@
10.4-
10.5-* doc best practices
10.6-https://rust-lang.github.io/api-guidelines/documentation.html
10.7-
10.8-also: https://lisp-lang.org/style-guide/
11.1--- a/notes/20231212.org Wed Jan 10 19:02:43 2024 -0500
11.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
11.3@@ -1,89 +0,0 @@
11.4-* On Computers
11.5-If you've met me in the past decade, you probably know that I am
11.6-extremely passionate about computers. Let me first explain why.
11.7-
11.8-On the most basic level computers are little (or big) machines that
11.9-can be programmed to do things, or /compute/ if we're being
11.10-technical.[fn:1]
11.11-
11.12-They host and provide access to the Internet, which is a pretty big
11.13-thing, but they do little things too like unlock your car door and
11.14-tell your microwave to beep at you. They solve problems. Big or small.
11.15-
11.16-They're also /everywhere/ - which can be scary to think about, but
11.17-ultimately helps propel us into the future.
11.18-
11.19-There's something pretty cool about that - when you look at the
11.20-essence of computation. There are endless quantities of these machines
11.21-which follow the same basic rules and can be used to solve /real/
11.22-problems.
11.23-
11.24-** The Programmer
11.25-Now, let us consider the /programmer/. They have power. /real/
11.26-power. They understand the language of computers, can whisper to them
11.27-in various dialects. It can be intimidating to witness until you
11.28-realize how often the programmer says the wrong thing - a bug.
11.29-
11.30-In reality, the programmer has a symbiotic relationship with
11.31-computers. Good programmers understand this relationship well.
11.32-
11.33-#+begin_annecdote
11.34-One day after I got my first job at a software company, I remember
11.35-being on an all-hands meeting due to a client service outage. We had
11.36-some management, our lead devs, product team, and one curious looking
11.37-man who happened to be our lead IT consultant who had just joined. He
11.38-was sitting up on a hotel bed, shirtless, vaping an e-cig, typing
11.39-away in what I can only imagine was a shell prompt.
11.40-
11.41-After several minutes he took a swig from a bottle of Coke and said
11.42-"Node 6 is sick." then a few seconds later our services were
11.43-restored. For the next hour on the call he explained what happened and
11.44-why, but that particular phrase always stuck with me. He didn't say
11.45-Node 6 was down, or had an expired cert - his diagnosis was that /it/
11.46-was /sick/.
11.47-#+end_annecdote
11.48-
11.49-The more you work closely with computers, the more you start to think
11.50-of them this way. You don't start screaming when the computer does the
11.51-wrong thing, you figure out what's wrong and learn from it. With
11.52-experience, you start to understand the different behaviors of the
11.53-machines you work with. I like to call this /Machine Empathy/.
11.54-
11.55-** Programs
11.56-I already mentioned bugs - I write plenty of those, but usually I try
11.57-to write /programs/. Programs to me are like poetry. I like to think
11.58-they are for the computer too.
11.59-
11.60-Just like computers, /computer programs/ come in different shapes and
11.61-sizes but in basic terms they are sets of instructions used to control
11.62-a computer.
11.63-
11.64-You can write programs to do anything - when I first started, my
11.65-programs made music. The program was a means to an end. Over time, I
11.66-started to see the program as something much more. I saw it as the
11.67-music itself.
11.68-
11.69-[fn:1] ... perform computations
11.70-
11.71-
11.72-* On Infra
11.73-Something that is missing from many organizations big or large, is an
11.74-effective way to store and access information, even about their own
11.75-org.
11.76-
11.77-It can be difficult problem to solve - usually there's the official
11.78-one, say Microsoft Sharepoint and then the list of unofficial sources
11.79-which becomes tribal corporate hacker knowledge. Maybe the unofficial
11.80-ones are more current, or are annotated nicely, but their very
11.81-existence breaks the system. There's no longer a single source of
11.82-truth.
11.83-
11.84-My priority in this department is writing services which process and
11.85-store information from a variety of sources in a distributed knowledge
11.86-graph. The graph can later be queried to access information on-demand.
11.87-
11.88-My idea of infrastructure is in fact to build my own Cloud. Needless
11.89-to say I don't have an O365 subscription, and wherever possible I'll
11.90-be relying on hardware I have physical access to. I'm not opposed to
11.91-cloud services at large but based on principle I like to think we
11.92-shouldn't be built on them.
12.1--- a/notes/20231223.org Wed Jan 10 19:02:43 2024 -0500
12.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
12.3@@ -1,3 +0,0 @@
12.4-* https://cal-coop.gitlab.io/utena/utena-specification/main.pdf
12.5-from the author of cl-decentralise2. draft specification of a
12.6-/Maximalist/ Computing System.
13.1--- a/notes/20231224.org Wed Jan 10 19:02:43 2024 -0500
13.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
13.3@@ -1,4 +0,0 @@
13.4-* public datasets
13.5-https://github.com/awesomedata/awesome-public-datasets
13.6-https://docs.openml.org/Datasets/
13.7-https://wiki.pathmind.com/open-datasets
14.1--- a/notes/20231228.org Wed Jan 10 19:02:43 2024 -0500
14.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
14.3@@ -1,40 +0,0 @@
14.4-* useful internals
14.5-#+begin_src lisp
14.6- sb-sys:*runtime-dlhandle*
14.7- sb-fasl:+fasl-file-version+
14.8- sb-fasl:+backend-fasl-file-implementation+
14.9- sb-debug:print-backtrace
14.10- sb-debug:map-backtrace
14.11- sb-pretty:pprint-dispatch-table
14.12- sb-lockless:
14.13- sb-ext:simd-pack
14.14- sb-walker:define-walker-template
14.15- sb-walker:macroexpand-all
14.16- sb-walker:walk-form
14.17- sb-kernel:empty-type
14.18- sb-kernel:*eval-calls*
14.19- sb-kernel:*gc-pin-code-pages*
14.20- sb-kernel:*restart-clusters*
14.21- sb-kernel:*save-lisp-clobbered-globals*
14.22- sb-kernel:*top-level-form-p*
14.23- sb-kernel:*universal-fun-type*
14.24- sb-kernel:*universal-type*
14.25- sb-kernel:*wild-type*
14.26- sb-kernel:+simd-pack-element-types+
14.27- (sb-vm:memory-usage)
14.28- (sb-vm:boxed-context-register)
14.29- (sb-vm:c-find-heap->arena)
14.30- (sb-vm:copy-number-to-heap)
14.31- (sb-vm:dump-arena-objects)
14.32- (sb-vm:fixnumize)
14.33- (sb-vm:rewind-arena)
14.34- (sb-vm:show-heap->arena)
14.35- (sb-vm:with/without-arena)
14.36- (sb-cltl2:{augment-environment,compiler-let,define-declaration,parse-macro})
14.37- (sb-cltl2:{declaration-information, variable-information, function-information})
14.38- sb-di:
14.39- sb-assem:
14.40- sb-md5:
14.41- sb-regalloc:
14.42- sb-disassem:
14.43-#+end_src
15.1--- a/notes/20240103.org Wed Jan 10 19:02:43 2024 -0500
15.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
15.3@@ -1,27 +0,0 @@
15.4-* [[https://github.com/sigmf/SigMF][SigMF]]
15.5-#+begin_quote
15.6-Sharing sets of recorded signal data is an important part of science
15.7-and engineering. It enables multiple parties to collaborate, is often
15.8-a necessary part of reproducing scientific results (a requirement of
15.9-scientific rigor), and enables sharing data with those who do not have
15.10-direct access to the equipment required to capture it.
15.11-
15.12-Unfortunately, these datasets have historically not been very
15.13-portable, and there is not an agreed upon method of sharing metadata
15.14-descriptions of the recorded data itself. This is the problem that
15.15-SigMF solves.
15.16-
15.17-By providing a standard way to describe data recordings, SigMF
15.18-facilitates the sharing of data, prevents the "bitrot" of datasets
15.19-wherein details of the capture are lost over time, and makes it
15.20-possible for different tools to operate on the same dataset, thus
15.21-enabling data portability between tools and workflows.
15.22-#+end_quote
15.23-
15.24-the-spec: https://github.com/sigmf/SigMF/blob/sigmf-v1.x/sigmf-spec.md
15.25-* [[https://www.libvolk.org/][LibVOLK]]
15.26-Vector-Optimized Library of Kernels (simd)
15.27-* [[https://docs.kernel.org/fb/framebuffer.html][/dev/fb*]]
15.28-framebuffers, used by fbgrab/fbcat program
15.29-* [[https://docs.kernel.org/block/ublk.html][ublk]]
15.30-https://github.com/ming1/ubdsrv
16.1--- a/notes/20240104.org Wed Jan 10 19:02:43 2024 -0500
16.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
16.3@@ -1,6 +0,0 @@
16.4-goals:
16.5-make problems smaller.
16.6-
16.7-sections:
16.8-why lisp?
16.9-- doesn't need mentioning more and more
17.1--- a/notes/refs.bib Wed Jan 10 19:02:43 2024 -0500
17.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
17.3@@ -1,169 +0,0 @@
17.4-@article{btrfs,
17.5-author = {Rodeh, Ohad and Bacik, Josef and Mason, Chris},
17.6-year = {2013},
17.7-month = {08},
17.8-pages = {},
17.9-title = {BTRFS: The linux B-tree filesystem},
17.10-volume = {9},
17.11-journal = {ACM Transactions on Storage (TOS)},
17.12-doi = {10.1145/2501620.2501623}
17.13-}
17.14-@INPROCEEDINGS{zfs,
17.15- author={Rodeh, O. and Teperman, A.},
17.16- booktitle={20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003. (MSST 2003). Proceedings.},
17.17- title={zFS - a scalable distributed file system using object disks},
17.18- year={2003},
17.19- volume={},
17.20- number={},
17.21- pages={207-218},
17.22- doi={10.1109/MASS.2003.1194858}}
17.23-
17.24-@inproceedings{tmpfs,
17.25- title={tmpfs: A Virtual Memory File System},
17.26- author={Peter Snyder},
17.27- year={1990},
17.28- url={https://api.semanticscholar.org/CorpusID:54156693}
17.29-}
17.30-
17.31-@Article{nvme-ssd-ux,
17.32-AUTHOR = {Kim, Seongmin and Kim, Kyusik and Shin, Heeyoung and Kim, Taeseok},
17.33-TITLE = {Practical Enhancement of User Experience in NVMe SSDs},
17.34-JOURNAL = {Applied Sciences},
17.35-VOLUME = {10},
17.36-YEAR = {2020},
17.37-NUMBER = {14},
17.38-ARTICLE-NUMBER = {4765},
17.39-URL = {https://www.mdpi.com/2076-3417/10/14/4765},
17.40-ISSN = {2076-3417},
17.41-DOI = {10.3390/app10144765}
17.42-}
17.43-
17.44-@inproceedings{ext4,
17.45-author = {Djordjevic, Borislav and Timcenko, Valentina},
17.46-title = {Ext4 File System Performance Analysis in Linux Environment},
17.47-year = {2011},
17.48-isbn = {9781618040282},
17.49-publisher = {World Scientific and Engineering Academy and Society (WSEAS)},
17.50-address = {Stevens Point, Wisconsin, USA},
17.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},
17.52-pages = {288–293},
17.53-numpages = {6},
17.54-keywords = {Linux, journaling, ext4/ext3/ext2, filesystems, inodes, disk performances, file block allocation},
17.55-location = {Florence, Italy},
17.56-series = {AIASABEBI'11}
17.57-}
17.58-
17.59-@Article{hd-failure-ml,
17.60-AUTHOR = {Zhang, Mingyu and Ge, Wenqiang and Tang, Ruichun and Liu, Peishun},
17.61-TITLE = {Hard Disk Failure Prediction Based on Blending Ensemble Learning},
17.62-JOURNAL = {Applied Sciences},
17.63-VOLUME = {13},
17.64-YEAR = {2023},
17.65-NUMBER = {5},
17.66-ARTICLE-NUMBER = {3288},
17.67-URL = {https://www.mdpi.com/2076-3417/13/5/3288},
17.68-ISSN = {2076-3417},
17.69-DOI = {10.3390/app13053288}
17.70-}
17.71-
17.72-@inproceedings{smart-ssd-qp,
17.73-author = {Do, Jaeyoung and Kee, Yang-Suk and Patel, Jignesh M. and Park, Chanik and Park, Kwanghyun and DeWitt, David J.},
17.74-title = {Query Processing on Smart SSDs: Opportunities and Challenges},
17.75-year = {2013},
17.76-isbn = {9781450320375},
17.77-publisher = {Association for Computing Machinery},
17.78-address = {New York, NY, USA},
17.79-url = {https://doi.org/10.1145/2463676.2465295},
17.80-doi = {10.1145/2463676.2465295},
17.81-booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
17.82-pages = {1221–1230},
17.83-numpages = {10},
17.84-keywords = {smart ssd},
17.85-location = {New York, New York, USA},
17.86-series = {SIGMOD '13}
17.87-}
17.88-
17.89-@inproceedings{ssd-perf-opt,
17.90-author = {Zuck, Aviad and G\"{u}hring, Philipp and Zhang, Tao and Porter, Donald E. and Tsafrir, Dan},
17.91-title = {Why and How to Increase SSD Performance Transparency},
17.92-year = {2019},
17.93-isbn = {9781450367271},
17.94-publisher = {Association for Computing Machinery},
17.95-address = {New York, NY, USA},
17.96-url = {https://doi.org/10.1145/3317550.3321430},
17.97-doi = {10.1145/3317550.3321430},
17.98-booktitle = {Proceedings of the Workshop on Hot Topics in Operating Systems},
17.99-pages = {192–200},
17.100-numpages = {9},
17.101-location = {Bertinoro, Italy},
17.102-series = {HotOS '19}
17.103-}
17.104-
17.105-@article{flash-openssd-systems,
17.106-author = {Kwak, Jaewook and Lee, Sangjin and Park, Kibin and Jeong, Jinwoo and Song, Yong Ho},
17.107-title = {Cosmos+ OpenSSD: Rapid Prototype for Flash Storage Systems},
17.108-year = {2020},
17.109-issue_date = {August 2020},
17.110-publisher = {Association for Computing Machinery},
17.111-address = {New York, NY, USA},
17.112-volume = {16},
17.113-number = {3},
17.114-issn = {1553-3077},
17.115-url = {https://doi.org/10.1145/3385073},
17.116-doi = {10.1145/3385073},
17.117-journal = {ACM Trans. Storage},
17.118-month = {jul},
17.119-articleno = {15},
17.120-numpages = {35},
17.121-keywords = {storage system, solid state drive (SSD), flash translation layer (FTL), Flash memory}
17.122-}
17.123-
17.124-@INPROCEEDINGS{emmc-mobile-io,
17.125- author={Zhou, Deng and Pan, Wen and Wang, Wei and Xie, Tao},
17.126- booktitle={2015 IEEE International Symposium on Workload Characterization},
17.127- title={I/O Characteristics of Smartphone Applications and Their Implications for eMMC Design},
17.128- year={2015},
17.129- volume={},
17.130- number={},
17.131- pages={12-21},
17.132- doi={10.1109/IISWC.2015.8}}
17.133-
17.134-@inproceedings{xfs-scalability,
17.135- author = {Adam Sweeney and
17.136- Doug Doucette and
17.137- Wei Hu and
17.138- Curtis Anderson and
17.139- Mike Nishimoto and
17.140- Geoff Peck},
17.141- title = {Scalability in the {XFS} File System},
17.142- booktitle = {Proceedings of the {USENIX} Annual Technical Conference, San Diego,
17.143- California, USA, January 22-26, 1996},
17.144- pages = {1--14},
17.145- publisher = {{USENIX} Association},
17.146- year = {1996},
17.147- url = {http://www.usenix.org/publications/library/proceedings/sd96/sweeney.html},
17.148- timestamp = {Wed, 04 Jul 2018 13:06:34 +0200},
17.149- biburl = {https://dblp.org/rec/conf/usenix/Sweeney96.bib},
17.150- bibsource = {dblp computer science bibliography, https://dblp.org}
17.151-}
17.152-
17.153-@inproceedings{xfs,
17.154- title={xFS: A wide area mass storage file system},
17.155- author={Wang, Randolph Y and Anderson, Thomas E},
17.156- booktitle={Proceedings of IEEE 4th Workshop on Workstation Operating Systems. WWOS-III},
17.157- pages={71--78},
17.158- year={1993},
17.159- organization={IEEE}
17.160-}
17.161-
17.162-@inproceedings {zns-usenix,
17.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},
17.164-title = {{ZNS}: Avoiding the Block Interface Tax for Flash-based {SSDs}},
17.165-booktitle = {2021 USENIX Annual Technical Conference (USENIX ATC 21)},
17.166-year = {2021},
17.167-isbn = {978-1-939133-23-6},
17.168-pages = {689--703},
17.169-url = {https://www.usenix.org/conference/atc21/presentation/bjorling},
17.170-publisher = {USENIX Association},
17.171-month = jul,
17.172-}
17.173\ No newline at end of file
18.1--- a/notes/vocab Wed Jan 10 19:02:43 2024 -0500
18.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
18.3@@ -1,19 +0,0 @@
18.4-;;; docs/vocab --- project glossary -*- mode:outline;outline-regexp:"[-]+" -*-
18.5-- wrt : With Respect To
18.6-- nyi : Not Yet Implemented
18.7-- rt : Regression Testing
18.8-- vm : Virtual Machine
18.9-- asm : Assembly
18.10-- comp : Compiler
18.11-- eval : Evaluate
18.12-- alloc : Allocate
18.13-- ret : Return
18.14-- tco : Tail-call Optimization
18.15-- reg : Register
18.16-- sbcl : Steel Bank Common Lisp
18.17-- rs : Rust (the language)
18.18-- el : Emacs Lisp
18.19-- cl : Common Lisp
18.20-- pcl : Practical Common Lisp
18.21-- taomop : The Art of the Meta Object Protocol
18.22-- lol : Let Over Lambda
19.1--- a/pitch.org Wed Jan 10 19:02:43 2024 -0500
19.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
19.3@@ -1,4 +0,0 @@
19.4-{{{header(pitch,
19.5-Richard Westhaver,
19.6-ellis@rwest.io,
19.7-The Big Picture)}}}
20.1--- a/readme.org Wed Jan 10 19:02:43 2024 -0500
20.2+++ b/readme.org Tue Apr 30 22:16:29 2024 -0400
20.3@@ -6,5 +6,5 @@
20.4 * [[file:blog][blog]]
20.5 ** [2023-11-19 Sun] [[https://compiler.company/blog/hello-world][hello-world]]
20.6 * [[file:docs][docs]]
20.7-* [[file:roadmap.org][roadmap]]
20.8-* [[file:pitch.org][pitch]]
20.9+* [[file:roadmap][roadmap]]
20.10+* [[file:pitch][pitch]]
21.1--- a/roadmap.org Wed Jan 10 19:02:43 2024 -0500
21.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
21.3@@ -1,16 +0,0 @@
21.4-{{{header(roadmap,
21.5-Richard Westhaver,
21.6-ellis@rwest.io,
21.7-The Compiler Company Roadmap)}}}
21.8-* WIP 2023
21.9-SCHEDULED: <2023-01-01 Mon>--[2023-12-31 Tue]
21.10-- State "WIP" from [2023-11-05 Sun 21:47]
21.11-** TODO NAS-T charter
21.12-- State "TODO" from [2023-11-05 Sun 21:51]
21.13-** TODO compiler.company web services
21.14-- State "TODO" from [2023-11-05 Sun 21:52]
21.15-** TODO hello-world blog post
21.16-- State "TODO" from [2023-11-05 Sun 21:53]
21.17-* TODO 2024
21.18-SCHEDULED: <2024-01-01 Mon>--[2024-12-31 Tue]
21.19-- State "TODO" from [2023-11-05 Sun 21:47]
