![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
https://github.com/jerryscript-project/iotjs/tree/master/docs/api
---
---
on 'sleep' and related syscalls:
http://jehanne.io/2018/11/15/simplicity-awakes.html
---
the syscalls in jehanne, a descendent of plan9 which amongst other things prides itself on its small # of syscalls, has the following syscalls, according to https://gitea.it/JehanneOS/jehanne/src/branch/master/sys/src/sysconf/syscalls.rc.confs :
ID=1; NAME=await; RET=int; ARGS=('char*' 'int') ID=2; NAME=awake; RET=long; ARGS=('long') ID=3; NAME=bind; RET=int; ARGS=('const char*' 'const char*' 'int') ID=4; NAME=close; RET=long; ARGS=('int') ID=5; NAME=create; RET=long; ARGS=('const char*' 'long' 'long') ID=6; NAME=errstr; RET=int; ARGS=('char*' 'int') ID=7; NAME=exec; RET=uintptr_t; ARGS=('const char*' 'const char') ID=8; NAME=_exits; RET=int; ARGS=('const char*') ID=9; NAME=fauth; RET=int; ARGS=('int' 'const char*') ID=10; NAME=fd2path; RET=int32_t; ARGS=('int32_t' 'char*' 'uint32_t') ID=11; NAME=fstat; RET=long; ARGS=('int' 'uint8_t*' 'int') ID=12; NAME=fversion; RET=int; ARGS=('int' 'int' 'const char*' 'int') ID=13; NAME=fwstat; RET=long; ARGS=('int32_t' 'const uint8_t*' 'uint32_t') ID=14; NAME=mount; RET=int; ARGS=('int' 'int' 'const char*' 'uint32_t' 'const char*' 'int') ID=15; NAME=noted; RET=int; ARGS=('int') ID=16; NAME=notify; RET=int; ARGS=('const void*') ID=17; NAME=open; RET=long; ARGS=('const char*' 'uint32_t') ID=18; NAME=pread; RET=long; ARGS=('int' 'void*' 'long' 'long') ID=19; NAME=pwrite; RET=long; ARGS=('int' 'const void*' 'long' 'long') ID=20; NAME=remove; RET=long; ARGS=('const char*') ID=21; NAME=rendezvous; RET=void*; ARGS=('const void*' 'void*') ID=22; NAME=rfork; RET=int; ARGS=('uint32_t') ID=23; NAME=seek; RET=long; ARGS=('int' 'long' 'int') ID=24; NAME=semacquire; RET=int; ARGS=('int*' 'int') ID=25; NAME=semrelease; RET=int; ARGS=('int*' 'int') ID=26; NAME=unmount; RET=int; ARGS=('const char*' 'const char*') ID=27; NAME=alarm; RET=long; ARGS=('unsigned long')
see also http://jehanne.io/2018/11/15/simplicity-awakes.html
the names are: await awake bind close create errstr exec _exits fauth fd2path fstat fversion fwstat mount noted notify open pread pwrite remove rendezvous rfork seek semacquire semrelease unmount alarm
in one line: await awake bind close create errstr exec _exits fauth fd2path fstat fversion fwstat mount noted notify open pread pwrite remove rendezvous rfork seek semacquire semrelease unmount alarm
---
http://nsl.cs.columbia.edu/papers/2016/posix.eurosys16.pdf
---
" Timeline of POSIX abstractions and interfaces. ... Year Abstraction Example Interfaces Version ’69 Filesystem open, read, write V0 ’69 Processes fork V0 ’71 Processes exec V1 ’71 Virtual memory break1 V1 ’73 Pipes pipe V3 ’73 Signals signal V4 ’79 Signals kill V7 ’79 Virtual memory vfork2 3BSD ’83 Networking socket, recv, send 4.2BSD ’83 I/O multiplexing select 4.2BSD ’83 Virtual memory mmap3 4.2BSD ’83 IPC msgget, semget, shmget SRV1 ’87 I/O multiplexing poll SRV3 ’88 Virtual memory mmap SunOS? 4.0 ’93 Async. I/O aio_submit POSIX.1b ’95 Threads pthread_create POSIX.1c
...
POSIX’s abstractions – processes, filesystems, virtual memory, sockets, and threads
...
A process is an abstraction for the execution of an application in a system. Specifically, the application is represented as an image that abstracts its execution environment comprising of, among others, the program code (text), processor register values, and open files
...
Inter-process communication (IPC)
Abstractions for inter-process communication enable one or more processes to interact with each other. . Early versions of Unix supported signals and pipes [2]. Signals enabled programmers to programmatically handle hardware faults, and this mechanism was generalized to allow a process to notify other processes. For instance, a shell process can use signals to stop processes. Pipes are special files that allow processes to exchange data with each other. Pipes do not allow arbitrary processes to exchange data, because a pipe between two processes must be set up by their common ancestor.
With the limitations of pipes and signals, sockets were added to BSD to provide a uniform IPC mechanism for both local and remote processes, i.e., processes running on different host machines. Sockets have become the standard way of networking, however they are not as widely used as platform-specific IPC mechanisms for local IPC [24].
The mmap interface for shared memory was envisioned as a IPC mechanism [25], [26], but never quite caught on. Additional IPC mechanisms (semaphores, IPC-specific interface for shared memory, and message queues) were added in POSIX.1b, released in 1993, but have since then been largely replaced by vendor-specific IPC mechanisms [24].
...
Asynchronous I/O ... Linux’s io_uring interface aims to address these shortcomings, and provide a true asynchronous I/O interface
...
still largely CPU-centric, which makes it hard to efficiently utilize special-purpose accelerators and disaggregated hardware without resorting to custom solutions
"
-- [1]
---
https://openjfx.io/ UI lib rec'd by Mike Hearn [2]
---
https://www.jetbrains.com/lp/compose-mpp/ UI lib rec'd by Mike Hearn [3]
--- the cover photo for Byte vol 8 no 8 (aug 1983) has the following function names in its picture:
putchar write read isalpha atoi atol getchar isdigit exit strcmp isascii scanf calloc brk index printf qsort
-- [4]
---
https://www.opengl.org/resources/libraries/glut/glut_downloads.php
---
10000truths 23 hours ago
| root | parent | prev | next [–] |
Embryonic processes. Basically:
1. Call a function that creates an empty child process in a suspended state.
2. Call functions that: map/write memory into the child process’s address space; add file descriptors to the child process; set the child process’s initial register values; and so on.
3. Call a function to unsuspend and run the child process.
reply
lgg 22 hours ago
| root | parent | next [–] |
fork() is terrible, but embryonic processes also have a lot of performance issues and prevent a number of valuable security mitigations. In general a spawn() style mechanism seems like a better approach (despite the deficiencies of specific examples like posix_spawn()).
reply
matu3ba 19 hours ago
| root | parent | next [–] |
What is better in an unfixable race condition (the time before the execve where stuff leaks)?
reply
lgg 17 hours ago
| root | parent | next [–] |
I think it goes without saying that since I stated fork() is terrible that I am not advocating for spawning new processes via any of the variants of exec() since they all depend on fork(). I directly stated posix_spawn() was the right technique (despite its deficiencies and a somewhat terrible interface).
My point was that embryonic processes aren't really the right solution since they require exposing a whole bunch to powerful primitives like read/write of remote address spaces in order to spawn processes. That ends up being slow (because each one of those calls is necessarily a syscall and requires manipulating page tables to mess with the other process). It also means to prevent abuse you need to be very carefully control when to revoke those privileges.
The obvious solution is to take all the operations you would have done to the remote process, encode them in some form, and pass them off to a secure agent (in this case the kernel) that can do them in bulk. That solves both perf issues (1 syscall, and no repeated round tripping through multiple address spaces), and the security issue (you no longer need to expose primitives to manipulate the remote process to every process that is allowed to spawn a new one).
reply
---
https://github.com/google/guava
fs111 10 hours ago (unread)
| link | flag |
friends don’t let friends use guava!
Whenever I have a chance I remove it from code-bases. apache-commons-* is usually good enough. guava is not worth all the grey hair it is causing.
---
https://github.com/google/nsync "a C library that exports various synchronization primitives, such as mutexes "
---
https://github.com/maxhumber/redframes "A pythonic dplyr"
" jcmkk3 4 hours ago
| link | flag |
I was excited to see this pop up on github a few days ago. I think that it has made a lot of smart decisions and practiced restraint in its capabilities. There have been quite a few attempts at a grammar of data manipulation for python, but most seem to be obsessed with creating an infix pipe operator. This one feels the most pythonic of the ones that I’ve seen.
Python’s data ecosystem has a lot of very strong libraries. I feel like array libraries (numpy, pytorch, etc) have solid APIs, scikit-learn has a great API, and Altair + seaborn’s new object interface are good grammar of graphics implementations. Pandas has been the biggest sore spot when comparing usability between R (tidyverse) and python. Don’t get me wrong, pandas is a great library, but there is only so far that it can adapt to ideas and new standards in API design without breaking a bunch of code or creating more confusion in its users.
I don’t necessarily think that redframes is the answer, but I think that it could be some good inspiration for future API designs or a base to build upon. Ibis and polars are currently the best alternative options. Ibis has been undergoing heavy development as of recently and I think that with the duckdb and arrow/datafusion backends, it will start to become more appealing for local data analysis, while also having the flexibility to operate on remote analytic engines/databases. "
---
https://www.google.com/search?client=firefox-b-1-d&q=mike+burrows+chubby
--- "Can I Use a System Call?"
https://justine.lol/cosmopolitan/functions.html https://web.archive.org/web/20220920161257/https://justine.lol/cosmopolitan/functions.html
list of which syscalls currently work on which platforms in Cosmopolitan Libc. My analysis (using the page as of 220920, which is when i first saw it and also when the first Internet Archive entry is for this page):
note: "metal" means "Running on bare metal, ie directly from a boatloader, in ring 0, with no OS" according to https://lobste.rs/s/hdbb22/can_i_use_system_call#c_hrrxle
calls with all green boxes: file: read write pread pwrite readv writev preadv pwritev close fstatat fstat lseek fopenat(O_RDONLY) memory: mmap(MAP_SHARED) munmap process: sigprocmask sigsuspend sigpending misc: getrandom security: issetugid
other calls with an orange box on metal (the "worst" platform) but otherwise green: process: _Exit sched_yield misc: reboot
other calls with exactly one orange box, not on metal, and no red boxes: memory: mmap(MAP_PRIVATE) mmap(MAP_STACK) asyncio: poll
other calls with orange boxes but no red boxes: process: _Exit1 futexes memory: tls asyncio: ppoll
note: there are no calls with exactly one red but the red is not on metal other calls with all greens except on metal, which is red: files: statfs fstatfs fopenat(O_RDWR) flock sync truncate ftruncate faccessat dup dup2 fcntl(F_DUPFD F_DUPFD_CLOEXEC Advisory_Locks F_GETFL F_GETFD F_SETFD) process: fork clone sigaction(ucontext_t) ioctl(FIOCLEX) nanosleep setitimer gettid getpid wait4 tkill memory: mprotect terminal: ioctl(TCGETS TCSETS TIOCGWINSZ) sockets: ioctl(FIONBIO) socket bind connect accept sendto recvfrom sendmsg recvmsg getsockname getpeername getsockopt setsockopt(SO_TYPE SO_DEBUG SO_ERROR SO_BROADCAST SO_REUSEADDR SO_REUSEPORT SO_KEEPALIVE SO_ACCEPTCONN SO_DONTROUTE SO_SNDBUF SO_RCVBUF SO_SNDLOWAT SO_RCVLOWAT TCP_NODELAY TCP_CORK) shutdown internet: ioctl(SIOCGIFCONF SIOCGIFADDR SIOCGIFNETMASK SIOCGIFBRDADDR SIOCGIFDSTADDR SIOCGIFFLAGS) gethostname pipes: pipe socketpair filesystems: getcwd chdir fchdir renameat mkdirat linkat unlinkat readlinkat opendir misc: uname getlogin_r time: clock getrusage
other calls with one red plus one orange:
~obsolete process: select pselect file: fsync fdatasync file/mmap: msync madvise time: clock_gettime(REALTIME) pipe: pipe2
process: getppid execve kill security: umask setuid setgid setrlimit socket: accept4
other calls with one red plus multiple oranges: process: vfork misc: arch_prctl time: clock_gettime(MONOTONIC) clock_getres file: sync_file_range dup3 utimensat security: setresuid setresgid
note: some of those orange boxes are more important than others
in long form:
calls with all green boxes:
read best best best best best ok good write best best best best best ok good pread best best best best best ok zipos pwrite best best best best best ok zipos readv best best best best best ok best writev best best best best best ok best preadv 2009+ v2.1+ v2.1+ v2.1+ v2.1+ v2.1+ v2.1+ pwritev 2009+ v2.1+ v2.1+ v2.1+ v2.1+ v2.1+ v2.1+ close best best best best best slow best fstatat best best best best best smudged best fstat best best best best best spotty best
fopenat O_RDONLY best best best best best best zipos
mmap MAP_SHARED best best best best best best best
lseek best best best best best best best
munmap best best best best best best best
sigprocmask best best best best best simulated no-op sigsuspend best best best best best simulated no-op sigpending best best best best best simulated no-op
getrandom 2014+ sysctl getentropy sysctl getentropy SysFun?036 rdrand issetugid best best best best best best zero
other calls with an orange box on metal (the "worst" platform) but otherwise green:
_Exit best best best best best best reset sched_yield best best best best select best no-op reboot notest notest notest notest notest notest fault
other calls with exactly one orange box, not on metal, and no red boxes:
mmap MAP_PRIVATE best best best best best no cow best
mmap MAP_STACK fast+safe fast+safe safe safe safe faked safe
poll best best best best best polling best
other calls with orange boxes but no red boxes:
_Exit1 best best rc=0 rc=0 rc=0 best reset
futexes best sched_yield good sched_yield select millis n/a tls %fs %fs %fs %fs %gs %gs %fs
ppoll best best best best non-atomic polling best
note: there are no calls with exactly one red but the red is not on metal
other calls with all greens except on metal, which is red: statfs best best best best best best fault fstatfs best best best best best best fault fork best best slow best best slow fault clone best thread thread thread thread thread enosys
fopenat O_RDWR best best best best best best todo
mprotect best best best best best best todo
sigaction ucontext_t best best best best best best enosys
ioctl TCGETS best best best best best ok wip ioctl TCSETS best best best best best ok wip ioctl TIOCGWINSZ best best best best best good wip ioctl FIOCLEX best best best best best best wip ioctl FIONBIO best best best best best best fault ioctl SIOCGIFCONF best best best best best best fault ioctl SIOCGIFADDR best best best best best best fault ioctl SIOCGIFNETMASK best best best best best best fault ioctl SIOCGIFBRDADDR best best best best best best fault ioctl SIOCGIFDSTADDR best best best best best best fault ioctl SIOCGIFFLAGS best best best best best best fault
flock good good good good good good fault sync notest notest notest notest notest flush fault
truncate best best best best best best fault ftruncate best best best best best best fault faccessat best best best best best best fault pipe best best best best best best fault
socketpair best best best best best best fault getcwd best best best best best best fault chdir best best best best best hairy fault fchdir best best best best best hairy fault renameat best best best best best best fault mkdirat best best best best best best fault linkat best best best best best admin-only fault unlinkat best best best best best hairy fault readlinkat best best best best best best fault
dup best best best best best best fault dup2 best best best best best best fault
fcntl F_DUPFD best best best best best best fault
fcntl F_DUPFD_CLOEXEC 2008+ best best best best best fault
fcntl Advisory Locks good good good good good best (v2.1) fault
fcntl F_GETFL best best best best best best fault
fcntl F_GETFD best best best best best best fault fcntl F_SETFD best best best best best best fault nanosleep best best best best micros millis enosys setitimer best best best best best kludge fault gettid best good good good good good fault getpid best best best best best best fault
socket best best best best best best fault bind best best best best best good fault connect best best best best best good fault accept best best best best best good fault
sendto best best best best best good fault recvfrom best best best best best good fault sendmsg good ok ok ok ok ok fault recvmsg good ok ok ok ok ok fault shutdown best best best best good best fault getsockname best best best best best best fault getpeername best best best best best best fault getsockopt best narrow narrow narrow narrow narrow fault setsockopt SO_TYPE best best best best best best fault setsockopt SO_DEBUG best best best best best best fault setsockopt SO_ERROR best best best best best best fault setsockopt SO_BROADCAST best best best best best best fault setsockopt SO_REUSEADDR best best best best best n/a fault setsockopt SO_REUSEPORT superior best best best best best fault setsockopt SO_KEEPALIVE best best best best best best fault setsockopt SO_ACCEPTCONN best best best best best best fault setsockopt SO_DONTROUTE best best best best best best fault setsockopt SO_SNDBUF best best best best best best fault setsockopt SO_RCVBUF best best best best best best fault setsockopt SO_SNDLOWAT best best best best best best fault setsockopt SO_RCVLOWAT best best best best best best fault setsockopt TCP_NODELAY best best best best best best fault setsockopt TCP_CORK best best best best best best fault sendto best best best best best good fault recvfrom best best best best best good fault sendmsg good ok ok ok ok ok fault recvmsg good ok ok ok ok ok fault shutdown best best best best good best fault getsockname best best best best best best fault getpeername best best best best best best fault getsockopt best narrow narrow narrow narrow narrow fault setsockopt SO_TYPE best best best best best best fault setsockopt SO_DEBUG best best best best best best fault setsockopt SO_ERROR best best best best best best fault setsockopt SO_BROADCAST best best best best best best fault setsockopt SO_REUSEADDR best best best best best n/a fault setsockopt SO_REUSEPORT superior best best best best best fault setsockopt SO_KEEPALIVE best best best best best best fault setsockopt SO_ACCEPTCONN best best best best best best fault setsockopt SO_DONTROUTE best best best best best best fault setsockopt SO_SNDBUF best best best best best best fault setsockopt SO_RCVBUF best best best best best best fault setsockopt SO_SNDLOWAT best best best best best best fault setsockopt SO_RCVLOWAT best best best best best best fault setsockopt TCP_NODELAY best best best best best best fault setsockopt TCP_CORK best best best best best best fault
wait4 best best best best best messy fault
tkill best ok ok ok ok ok fault uname best best best best best best enosys
clock cgt cgt cgt cgt getrusage gpt fault getrusage some best best best best some fault
opendir best best best best best best fault gethostname best best best best best best fault getlogin_r getenv sys sys sys sys sys enoent
other calls with one red plus one orange:
select best best best best best polling fault pselect best best best best best polling fault msync best best best best best partial todo
clock_gettime REALTIME fastest good good good gettimeofday fastest enosys
fsync notest notest notest notest notest flush fault fdatasync notest notest notest notest notest flush fault
pipe2 2008+ best best best non-atomic best fault
madvise best best best best best some fault getppid best best best best best slow fault umask best best best best best no-op fault setuid best best best best best no-op fault setgid best best best best best no-op fault accept4 2009+ best best best non-atomic good fault execve best best best best best kludge fault kill best best best best best limited fault setrlimit best ok ok ok ok RLIMIT_AS fault
other calls with one red plus multiple oranges: vfork best best fork best fork fork fault arch_prctl best best restricted best restricted forbidden best
clock_gettime MONOTONIC fastest good good good rdtsc rdtsc enosys
clock_getres kinda good good ok faked rdtsc enosys sync_file_range notest fdatasync fdatasync fdatasync fdatasync fdatasync fault dup3 2008+ non-atomic best best non-atomic best fault setresuid best best best faked faked enosys fault setresgid best best best faked faked enosys fault utimensat 2008+ 1e-9 1e-9 1e-9 1e-6 1e-7 fault
a comment on this page on lobse.rs:
" david_chisnall 10 minutes ago
| link | flag |
That’s pretty impressive.
On FreeBSD?, memfd_create is spelled shm_open. There’s a libc shim that provides a Linux-compatible interface. futex is spelled _umtx_op, so could also be supported to some degree (except for the complex bitmap versions). Since FreeBSD? 12, getrandom has been a system call (though the sysctl mechanism still works), to play better with sandboxing mechanisms that block sysctl access. The equivalents of sched_{set,get}affinity are cpuset_{set,get}affinity, though the mapping isn’t quite 1:1. kqueue can implement epoll, there’s a shim compat library, but it’s a much nicer API to work with so I’d prefer a portable libc exposed it and used libkqueue on Linux.
The sad thing about Linux being the base platform is that you miss out on things like cap_enter and cap_rights_limit. I’ve written compartmentalised software with the APIs that Linux gives you and it is incredibly painful in comparison.
"
---
my summary of the previous:
we probably want to initially implement the following:
basic file descriptors: all green boxes: read write pread pwrite readv writev preadv pwritev close fstatat fstat lseek fopenat(O_RDONLY) (since the 'metal' platform can only open files in read-only mode, i'm guessing these are there in metal not to deal with ordinary files in a filesystem on disk, but to read special files of some sort; later update: actually it's b/c you can package your executable as a zip and then read other files in the zip: https://lobste.rs/s/hdbb22/can_i_use_system_call#c_85fgv4 )
fancy file descriptors: other calls with all greens except on metal, which is red: dup
files in a filesystem: other calls with all greens except on metal, which is red: files: statfs fstatfs fopenat(O_RDWR) flock sync truncate ftruncate faccessat other calls with one red plus one orange: file: fsync fdatasync: (orange b/c on Windows, implemented via FlushFileBuffers?; on those platforms we can just use 'sync' instead for now) other calls with one red plus one orange: utimensat (oranges just b/c precision limits)
filesystems: other calls with all greens except on metal, which is red: getcwd chdir fchdir renameat mkdirat linkat unlinkat readlinkat opendir
memory: all green boxes: mmap(MAP_SHARED) munmap other calls with exactly one orange box, not on metal, and no red boxes: mmap(MAP_PRIVATE) : the orange box is on Windows, and says not COW, so we won't provide COW either
process: all green boxes: sigprocmask sigsuspend sigpending
misc: all green boxes: getrandom other calls with all greens except on metal, which is red: uname getlogin_r
security: all green boxes: issetugid
process stuff that doesnt need an OS: other calls with an orange box on metal (the "worst" platform) but otherwise green: _Exit sched_yield other calls with orange boxes but no red boxes: _Exit1 (oranges b/c sometimes result code is lost) futexes (oranges b/c some platforms is emulated with sched_yield or select)
process stuff that seems to need an OS: other calls with all greens except on metal, which is red: fork clone sigaction(ucontext_t) ioctl(FIOCLEX) nanosleep setitimer gettid getpid wait4 tkill other calls with one red plus one orange: execve (orange b/c on Windows "kludge: "Parent process stays alive as shelled zombie to propagate exit code"") kill (orange b/c on Windows "limited")
asyncio: other calls with exactly one orange box, not on metal, and no red boxes: poll (the orange box is on Windows, and it says "polling", which i don't understand what the problem is; the docs say " Note: Polling works best on Windows for sockets. We're able to poll input on named pipes. But for anything that isn't a socket, or pipe with POLLIN, (e.g. regular file) then POLLIN/POLLOUT are always set into revents if they're requested, provided they were opened with a mode that permits reading and/or writing. ") other calls with orange boxes but no red boxes: ppoll (orange box on Windows says "polling" same as for "poll"; also on MacOS? says "non-atomic", so we just won't guarantee atomicity
terminal: other calls with all greens except on metal, which is red: ioctl(TCGETS TCSETS TIOCGWINSZ)
sockets: other calls with all greens except on metal, which is red: sockets: ioctl(FIONBIO) socket bind connect accept sendto recvfrom sendmsg recvmsg getsockname getpeername getsockopt setsockopt(SO_TYPE SO_DEBUG SO_ERROR SO_BROADCAST SO_REUSEADDR SO_REUSEPORT SO_KEEPALIVE SO_ACCEPTCONN SO_DONTROUTE SO_SNDBUF SO_RCVBUF SO_SNDLOWAT SO_RCVLOWAT TCP_NODELAY TCP_CORK) shutdown (do we really need all that tho?)
pipe: other calls with all greens except on metal, which is red: pipe socketpair
time: other calls with all greens except on metal, which is red: time: clock getrusage other calls with one red plus one orange: time: clock_gettime(REALTIME) (orange b/c only microsecond precision on MacOS?, that's fine)
stuff we might want to implement (oranges besides metal):
fancy file descriptors: other calls with all greens except on metal, which is red: dup2 fcntl(F_DUPFD F_DUPFD_CLOEXEC Advisory_Locks F_GETFL F_GETFD F_SETFD) i dunno if we really need all those fcntls tho
memory: other calls with orange boxes but no red boxes: tls: oranges b/c "%gs" with notes: on MacOS?: "uses Apple internals; adds startup latency because binary is code-morphed upon initialization; you have to use -mno-tls-direct-seg-refs" on Windows: "uses TlsAlloc?() and MSVC ABIs; adds startup latency because binary is code-morphed upon initialization; you have to use -mno-tls-direct-seg-refs" other calls with one red plus one orange: file/mmap: msync madvise: on Windows, 'msync' says 'partial' and 'madvise' says 'some'. Do we really need madvise at all? Can we just use 'sync' instead of 'msync'?
fancy memory: other calls with all greens except on metal, which is red: memory: mprotect
internet: other calls with all greens except on metal, which is red: ioctl(SIOCGIFCONF SIOCGIFADDR SIOCGIFNETMASK SIOCGIFBRDADDR SIOCGIFDSTADDR SIOCGIFFLAGS) gethostname (do we really internet stuff at all tho?)
pipe and socket: other calls with one red plus one orange: pipe2: orange b/c non-atomic on MacOS?. Do we really need this if it's not guaranteed to be atomic? accept4: orange b/c non-atomic on MacOS?. Do we really need this if it's not guaranteed to be atomic?
we probably don't want to implement:
other calls with an orange box on metal (the "worst" platform) but otherwise green:
misc: reboot: b/c too systems-y other calls with exactly one orange box, not on metal, and no red boxes:
memory: mmap(MAP_STACK): b/c has some orange boxes on Windows, and doesn't seem absolutely necessary, although mb i just don't understand it well enuf other calls with one red plus one orange:
~obsolete process: select pselect: b/c seems obsolete; just use the newer "poll/ppoll" instead
process: getppid: on Windows, iterates process tree
security: umask setuid setgid setrlimit (no-ops in many cases on Windows)
other calls with one red plus multiple oranges:
process: vfork
misc: arch_prctl
time: clock_gettime(MONOTONIC) clock_getres
file: sync_file_range dup3of course, we may not want to include even all of the stuff the stuff that cosmopolitan has on all of its platforms, b/c we also want to sit on top of HLL platforms like Java/JVM, Python, etc. So we'll need to check which of those things that we said we wanted to implement are easily available from the Java stdlib, the Python stdlib, etc. And on the other side, there might be some stuff that we don't want b/c it's not on embedded.
---
graphics libs
https://tsoding.org/olive.c/ https://news.ycombinator.com/item?id=32932631
---
haskell-y effect elm
" Could you list some Haskell libraries that your team found very useful while working on NoRedInk? and that you would like to feature?
postgresql-typed.
We rely mostly on our [https://github.com/NoRedInk/haskell-libraries own libraries]. We created our own prelude that is very close to the core libraries of Elm. You can read about it here.https://blog.noredink.com/post/658510851000713216/haskell-for-the-elm-enthusiastWhat kind of an effect system do you use: RIO, mtl, fused-effects, Polysemy, or something else?
We switched from something similar to RIO (parametrized environment of a ReaderT?) to the handle pattern. It simplified our code drastically – no classy lenses and simpler type signatures – while offering the same benefits as different implementations of the effects, mostly for running tests. " -- [5]
---
https://en.wikipedia.org/wiki/Meta-Object_Facility
https://www.omg.org/spec/MOF/2.5.1/PDF
---
---
https://github.com/oconnor663/duct.py/blob/master/gotchas.md "This document describes the colorful variety of issues that come up when you use child processes, and the solutions that Duct chooses for them" "Duct is a library for running child processes. Duct makes it easy to build pipelines and redirect IO like a shell"
---
" …but ignore the language's culture wars.
Pay attention to community, but when it slows you down, just do whatever you want, man. If this is your 3rd or 4th major project in that language, then yes, consider forming Hard Opinions on whatever their culture war is. But until then, don't let Fun Narrative distract you from writing the program.
Examples:
Haskellers will tell you not to use default Strings (or the default Prelude), and/or any combination of their favorite language extensions. They're all quite compelling, but just use strings if you want.
Scala had something of a holy war over scalaz vs. cats. Honestly just ignore Scala entirely if you don't like mess, but if you have to, pick cats and go on with your life.
OCaml has a split on how to do asynchronicity: Lwt or Async. Pick one, who cares.
Elixir has several HTTP libraries: HTTPoison, Tesla, Mint, Finch, Mojito, hackney. Pick one, you're on the BEAM, you'll be fine.
"
---
about printf type stuff:
david_chisnall 26 hours ago
| link | flag |
For a couple of embedded use case, I ended up implementing a small subset of C++’s std::format. Mine handles integer, string, and pointer arguments (including CHERI capabilities), but no positional arguments or format specifiers. It compiles down to tiny code and is type safe (it can also work with a static buffer and silently truncate the input, or write directly to a UART, with different template arguments). I can’t imagine trying to hit the same efficiency and usability point in C without a lot of macros and GCC extensions.
~
gsempe 18 hours ago | link | flag | Your solution seems very good. Is it open source? I run a newsletter on embedded systems and I’ll be happy to share your work in it.
~
david_chisnall 5 hours ago | link | flag | There’s an old version in the snmalloc repo (that’s what I wrote it for originally: I wanted to be able to do rich logging from a memory allocator, where we can’t have external dependencies and, in our error paths, can’t depend on anything other than raw system calls working). In the CHERI RTOS I have an improved version. That has a few more features (and more tuned use of always/never inline attributes to keep code size down), so I’ll probably sync it back to snmalloc at some point. I hope the repo it’s in now will be open sourced at some point soon but I want to have our red team attack it a bit more first: it’s embarrassing to releases a new secure OS and have the first security vulnerability reported in less than a day (just ask the seL4 team…).
---
https://dercuano.github.io/notes/prototyping-environment.html
---
---
https://derctuo.github.io/notes/logsl.html
LOGSL: Lisp object-graph serialization language
---
https://blessed.rs/crates https://lib.rs/ https://lobste.rs/s/smrik5/blessed_rs_unofficial_guide_rust https://old.reddit.com/r/rust/comments/yp65kq/crate_list_blessedrs/ivj4kvm/
---
smaller variants of opengl:
opengl ES (rant: https://web.archive.org/web/20221122141924/https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ ) minigl https://web.archive.org/web/20221122141924/https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ tinygl https://bellard.org/TinyGL/
---
" The OS interop layer has been completely abstracted into a handful of WASI functions to be implemented in the WASI interpreter:
(import "wasi_snapshot_preview1" "args_sizes_get" (func (;0;) (type 3))) (import "wasi_snapshot_preview1" "args_get" (func (;1;) (type 3))) (import "wasi_snapshot_preview1" "fd_prestat_get" (func (;2;) (type 3))) (import "wasi_snapshot_preview1" "fd_prestat_dir_name" (func (;3;) (type 6))) (import "wasi_snapshot_preview1" "proc_exit" (func (;4;) (type 11))) (import "wasi_snapshot_preview1" "fd_close" (func (;5;) (type 8))) (import "wasi_snapshot_preview1" "path_create_directory" (func (;6;) (type 6))) (import "wasi_snapshot_preview1" "fd_read" (func (;7;) (type 5))) (import "wasi_snapshot_preview1" "fd_filestat_get" (func (;8;) (type 3))) (import "wasi_snapshot_preview1" "path_rename" (func (;9;) (type 9))) (import "wasi_snapshot_preview1" "fd_filestat_set_size" (func (;10;) (type 36))) (import "wasi_snapshot_preview1" "fd_pwrite" (func (;11;) (type 28))) (import "wasi_snapshot_preview1" "random_get" (func (;12;) (type 3))) (import "wasi_snapshot_preview1" "fd_filestat_set_times" (func (;13;) (type 51))) (import "wasi_snapshot_preview1" "path_filestat_get" (func (;14;) (type 12))) (import "wasi_snapshot_preview1" "fd_fdstat_get" (func (;15;) (type 3))) (import "wasi_snapshot_preview1" "fd_readdir" (func (;16;) (type 28))) (import "wasi_snapshot_preview1" "fd_write" (func (;17;) (type 5))) (import "wasi_snapshot_preview1" "path_open" (func (;18;) (type 52))) (import "wasi_snapshot_preview1" "clock_time_get" (func (;19;) (type 53))) (import "wasi_snapshot_preview1" "path_remove_directory" (func (;20;) (type 6))) (import "wasi_snapshot_preview1" "path_unlink_file" (func (;21;) (type 6))) (import "wasi_snapshot_preview1" "fd_pread" (func (;22;) (type 28)))
This is the entire set. In order for the Zig compiler to compile itself to C, these are the only syscalls needed. " -- https://ziglang.org/news/goodbye-cpp/
---
date format
https://ijmacd.github.io/rfc3339-iso8601/
---
"
16K lines of gnarly shell generated by GNU autoconf
Running in our shell interpreter, written in ~40K lines of typed Python.
But, it's translated to ~80K lines of pure C++!
That generated C++ runs on top of a ~4K line runtime of garbage collected data structures, and ~3K lines of OS bindings (May 2022 blog post with background)." -- https://www.oilshell.org/blog/2023/01/garbage-collector.html---
https://www.pagetable.com/c64ref/kernal/
---
https://twitter.com/JustineTunney/status/1621415193296388096
---
" anyfoo 14 hours ago
| parent | context | flag | favorite | on: Wi Flag (2002) |
Around 15 years ago, when casual little games on Facebook were still a thing (actually when Facebook itself was still a thing), I used to play Yahtzee on the site while watching TV shows or whatever. It was one of the most popular games on there. For me it was something to fidget with (there was no money involved or anything, just a personal high score), so I played it a lot.
I felt more and more that dice values of specifically 1 and 6 were harder to come by than other values, so one day I sat down for a few minutes and logged the value of 100 or so dice throws. Turns out I was right, the distribution was not uniform: 2-5 were fine, but it seemed that it was twice as hard to get a 1 or a 6 compared to any other value.
I even did a chi-squared hypothesis test, because I was crazy. (And because I was studying for my statistics minor in university at the time).
Seeing the result, the problem was pretty clear, without even knowing the source code. Almost certainly, they had a random number generator giving a number in a uniform range, let's say from 0 to 1, and did something like the following to get a dice value from 1 to 6:
value = round(random()*5)+1
Do you spot the issue?
The problem is that round() rounds to the nearest integer. So any value between, say, 1.5 and 2.5 (exclusive at one end) rounds to 2, 2.5-3.5 rounds to 3, and so on. Add 1, and you have the dice value.
But the ranges for dice values 1 and 6, are only 0 to 0.5 and 4.5-5 respectively, so ranges that are only half the size.
The fix should be extremely simple:
value = floor(random()*6)+1
The crucial point being to use floor() or ceil() instead of round(), to only round towards one direction.
I wrote up exactly this in a short email to the company that made the Yahtzee game. They did not reply and just silently fixed the bug, right after my email. I was disappointed and stopped playing. "
---
"
12 BenjaminRi? edited 9 hours ago
| link | flag |
I fully agree with this article. One of the most annoying things about the C standard library, apart from all the things mentioned here, is that the atoi function returns 0 for invalid strings. So there is no way to distinguish the input string horse from 0 and there is no way to properly verify input with that function. The entire C standard library is fraught with such really quite obvious and terrible API mistakes, and it sucks the fun out of writing correct software in C. I usually just reimplement the standard library functions with correct and sane replacements… But you really don’t want to reimplement the standard library as your first task when you write a C program. The C standard library didn’t just not age well, it was terrible from the get-go.
What I’m really curious about is whether the author has some kind of standard library alternative that he is using, and if so, which one and can we use it too?
~
phoebos 9 hours ago | link | flag | I agree with your frustration at much of the standard library, but the solution to atoi’s crap is to use strtol and friends (along with errno checking) - POSIX even requires atoi to be equivalent to
(int) strtol(str, (char )NULL, 10)
except for error handling. The only reason atoi remains in POSIX is “because it is used extensively in existing code”.
~
BenjaminRi 8 hours ago | link | flag | I know, but atoi just strikes me as a prime example of what is wrong with the C standard library design. A lot has to go wrong for such a function to find its way into a language standard library. And as you said, it is used extensively in existing code - probably all of it buggy and full of parsing issues.
"
---
6 david_chisnall 4 hours ago
| link | flag |
Mostly agreed. The locales stuff is a mess, though the _l versions in POSIX are nicer (at least the locale is explicit).
Without libc you don’t have to use this global, hopefully thread-local, pseudo-variable. Good riddance. Return your errors, and use a struct if necessary.
Most of libc doesn’t use errno, it’s primarily used as the return from system calls. Without libc, you need some other way of doing system calls. The FreeBSD? calling convention for system calls can’t actually be represented directly in C because it uses the carry flag to differentiate between valid and error returns.
Types are not atomic, loads and stores are atomic
C screwed this up trying to localise a C++ API into C. The intent of the standard was to allow std::atomic<T> (translated into C as _Atomic(T)) and T to have different representations. For example, if you do _Atomic(struct SomeBigStruct?) may have a lock word at the start (or end). Instead, atomics have some interesting ptifalls where you can put them in shared memory and they’re not actually atomic.
However, I don’t think the atomic functions require _Atomic-qualified arguments
They do, though the wording of the standard is somewhat impenetrable. They also require the arguments to be volatile, which is just bizarre.
Introduced in C11, but never gained significant traction. Anywhere you can use C threads you can use pthreads, which are better anyway.
Don’t use pthreads on Windows if you can possibly avoid it, the wrappers are bad. The C APIs are there as the result of a horrible compromise:
The standards committee felt that they couldn’t introduce atomics without adding threads in the standard.
No one wanted a threading API that was an exact match for another platform.They ended up standardising a terrible set of APIs. PHK has some good rants about this.
calvin 1 hour ago
| link | flag |
Don’t use pthreads on Windows if you can possibly avoid it, the wrappers are bad. The C APIs are there as the result of a horrible compromise:
What’s really funny is that a lot of non-Unix OSes other than Windows adopted pthreads (VMS and i).
---
spc476 12 hours ago
| link | flag |
I can’t really argue with the article, although it would have been nice to know it’s more of a reaction to the standard C library on Microsoft Windows (which is only visible if you follow the links) where most of the issues stand out.
~
kornel 1 hour ago | link | flag | Sigh, MSVC’s libc is so bad. Even fopen is unusable due to lacking Unicode support. mingw is nice enough to support UTF-8 paths out of the box, but with MSVC that needs ifdef one way or another.
---
snej 5 hours ago
| link | flag |
Pretty right-on, although I still use the standard library since I don’t want to rewrite it and make it work on all platforms. Why don’t we have a better alternative? C++’s library does provide a lot of replacements but they have their own issues (e.g. iostreams has pretty poor performance.)
I wish the OP had said what they use for strings. A different implementation of the same data structure? IMHO using nul-terminated char strings is itself bad design; strings should (a) have an explicit length and (b) use unsigned chars (interpreted as UTF8.) C++’s string_view handles (a) pretty well — it’s a struct with a pointer to the beginning and the end.
~
Ada_Weird 5 hours ago | link | flag | If I had to guess what the author was using it’d either be a ranged pointer with a pointer to the beginning and ending of a string or a pointer and length bundled into a struct. Those are the most reasonable implementations of strings imo.
~
snej 39 minutes ago | link | flag | I sometimes wonder which of those is more optimal. (In terms of performance; the API can be the same, of course.) I’ve used both on different projects. They both seem to involve similar amounts of arithmetic — in the first form size() requires subtracting, while in the other one end() requires adding. It probably comes down to gory details of ISA addressing modes, and may vary by CPU.
Ada_Weird 17 hours ago (unread)
| link | flag |
I honestly expect that the performance impact is extremely small. An extra add is hardly going to show up in profiling.
--- "My review of the C standard library in practice" https://nullprogram.com/blog/2023/02/11/
---
ef one way or another.
5 dcreager edited 18 hours ago
| link | flag |
For those who haven’t seen it, CCAN is a great collection of reusable C code, much of which specifically exists to work around the kinds of issues mentioned in OP. It turns “oh crap I should probably roll my own” into “wait I bet someone has already re-rolled this”.
Edit: See below re the ccodearchive.net link belonging to a squatter now! I’ve updated the link to CCAN’s GitHub? repo, which is still active and not spammy. h/t @taal for pointing this out!
8
taal edited 18 hours ago (unread) | link | flag | Please note that it seems this is NOT the right link anymore. Giveaway: the link to the online casino at the bottom. See: https://lists.ozlabs.org/pipermail/ccan/2022-September/001411.html
However, also good warning to not include other peoples code found on the internet without looking at the actual code in detail - a lot of nasty things can be done by a squatter… especially with this kind of code that is outsourcing magic and goes into.low level parts people might not monitoring.
---
?”
~ chbarts 20 hours ago (unread)
| link | flag |
Aside from iostreams having poor performance, I haven’t seen it demonstrated that it even covers all of the same use cases, and what it does do can be needlessly obscure. For example, printing an integer as a hexadecimal value of a given width is not obvious, and that kind of thing fits on a cheat-sheet for printf style functions.
~
davmac edited 18 hours ago (unread) | link | flag | cout << setfill('0') << setw(2) << hex << 4;
I don’t think it’s any less obvious that it is for printf, probably more so since the names are meaningful (and could easily also fit on a cheat sheet). Granted it’s verbose (especially if you need to prepend std:: to each of those identifiers) but I wouldn’t call it “needlessly obscure”.
edit: for C++20, the following would also work:
cout << format("{:02x}", 4);
~
distributed 12 hours ago (unread) | link | flag | Unfortunately, on top of being very verbose and burying what is going on below half a line of stuff, the cout version leaves the stream in hex mode. The next number printed will be in hex as well, which you may or may not realize when looking at the output.
std::format is clearly much nicer for basically doing the same as printf, just type safe.
~
davmac 11 hours ago (unread) | link | flag | I’m not saying it’s a great API at all, but it’s hardly obscure.
~ snej 14 hours ago (unread)
| link | flag |
The new C++20 fmt library is much better in that regard (it’s inspired by Python.) My only complaint is that making a custom type format table is an exercise in ugly template grunge.
--- cli commandline python tui ui
https://textual.textualize.io/
---
https://lobste.rs/s/h4j3lg/killer_libraries
---
https://pointersgonewild.com/2023/02/24/building-a-minimalistic-virtual-machine/ https://github.com/maximecb/uvm/blob/main/doc/syscalls.md
---
pandas, polars (polars = "essentially Pandas written in Rust with new design decisions" -- https://news.ycombinator.com/item?id=35425835)
---
Cosine Implementation in C (github.com/ifduyue)
" okaleniuk 4 days ago
| next [–] |
I love these things! Approximation is art.
I have a similar example in my book Geometry for Programmers (https://www.manning.com/books/geometry-for-programmers). There I make a polynomial approximation for sine that is: 1) odd (meaning antisymmetric); 2) precise at 0 and Pi/2 (and -Pi/2 automatically); 3) have precise derivatives and 0 and Pi/2 (and -Pi/2); 4) have better overall precision than the equivalent approximation with Taylor series; and it only consists of 4 members! Adding more members makes it impractical in the modern world since we have hardware implementations for sine on CPUs and GPUs.
Spoiler alert, the secret sauce is the integral equation ;-)
reply
okaleniuk 4 days ago
| parent | next [–] |
Oh, and I have a free explanation too: https://wordsandbuttons.online/sympy_makes_math_fun_again.html
reply "
-- https://news.ycombinator.com/item?id=35381968
---
https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html
~
jcmkk3 27 hours ago | link | flag | This article was written in 2018. As of Python 3.9, there is now the “zoneinfo” standard library which I believe should be considered best practice when working with time zones. https://docs.python.org/3/library/zoneinfo.html#module-zoneinfo
https://lobste.rs/s/whvzyp/pytz_fastest_footgun_west_2018
---
booniepepper 7 hours ago
| link | flag |
Thanks, I’m generally optimistic that it could be useful and be used!
I’ve also made an effort to have zero dependencies and statically compile to increase portability, although I may take some dependencies to handle things like utf-8 properly.
~
andyc Oil Shell Developer 5 hours ago | link | flag | One library I was looking at was this, used by Julia: https://juliastrings.github.io/utf8proc/
Seems like it could be pretty small and self-contained? (Let me know, as I might use it for Oils :) )
~
booniepepper 5 hours ago | link | flag | Ooh thanks, I’ll definitely take a look!
I’m tentatively also looking into “zigstr” since it might fit into my current Zig implementation without needing to FFI over the C ABI:
https://github.com/jecolon/zigstr
https://zig.news/dude_the_builder/unicode-string-operations-536e ~
booniepepper edited 5 hours ago | link | flag | (Not that I’m at all opposed to C or C++ of course! Also vice versa, Zig can also produce C ABI .so or .a artifacts for libraries)
---
16 jturner OpenBSD? Developer 22 hours ago
| link | flag |
This is slightly off topic, but I’m also a big fan of Lua’s patterns library this is what OpenBSD? uses for their httpd.conf(5) patterns(7) matching.
~
catwell 16 hours ago | link | flag | Agreed. Lua has a different trade-off than most languages. For simple things you use the patterns library, which is less powerful than PCRE but much simpler. And if you need something more powerful you go straight to LPEG.
I started programming with Per and did a lot of text processing l so I am actually comfortable with regular expressions, but I find Lua’s approach better.
Another approach, if you want to stay close to regexps but need more power or a more readable syntax, is Ragel, which can be used with several programming languages.
---
ppl seem to like pytest: https://lobste.rs/s/j8xgym/pytest_fixtures_are_magic
---
https://zine.dev/2023/07/strlcpy-and-strlcat-added-to-glibc/
---
Inbox Threads Saved bshanks (461)
13
strlcpy and strlcat added to glibc c zine.dev
via river 4 hours ago | suggest | flag | hide (hidden by 2 users) | save | archive | 2 commentsMarkdown formatting available
~ mordae 1 hour ago
| link | flag |
Ulrich Drepper was both right and wrong at the same time. Using these to e.g. build file paths is risky, but at the same time using them to process non-critical printable strings fro untrusted inputs can save you the headache of dynamic allocation.
I seem to keep using snprintf for almost all string concatenations, though.
~
peter 45 minutes ago | link | flag | Or just use format!.
Sorry, I had to.
~
icefox 10 minutes ago (unread) | link | flag | You have been deducted one Rust Evangelism Strike Force token. Please be aware of how many you have remaining in your quota. :-P
---
https://tonyg.github.io/squeak-actors/ rec. by https://lobste.rs/s/gpar6n/weaknesses_smalltalk_are_strengths#c_56ucht https://eighty-twenty.org/2019/01/30/actors-for-squeak
---
" optparse and getopt, two modules that used to be a de-facto solution for parsing script arguments in their time, are now marked as "soft-deprecated". You can use them forever, but you probably should not.
First, argparse is the more modern stdlib solution, and we have a good article on it.
Second, 3rd party projects like typer and click exist. "
---
---
https://pkg.go.dev/log/slog https://lobste.rs/s/3o0lpm/proposal_enhance_go_s_http_router
15 alec 8 days ago
| link |
These changes will make stdlib mux actually pretty usable. This is one (there are others of course) area where the Go community’s dogmatic insistence on using the stdlib for everything, is just plain wrong. The stdlib mux is anaemic and has footguns.
The {$} marker is a bit of a hack, but something is obviously necessary for backwards compatibility.
5
scraps 7 days ago (unread) | link | This is one (there are others of course) area where the Go community’s dogmatic insistence on using the stdlib for everything, is just plain wrong.
not really sure what you mean in this regard, almost everyone I’ve talked to use gorilla mux or chi, not the stdlib mux on its own.
.
9 worr 7 days ago
| link |
Man, like the author, I really dislike the choice of embedding a string to indicate the HTTP method. That feels like too easy if a mistake for folks to make.
4
paulsmith 7 days ago (unread) | link | While in general I agree it’s better to have enums or similar names rather than strings for interface arguments like this, HTTP methods are conventionally just ASCII strings. There are 8 standardized methods, an IANA registry of 40 (including “*”), but all the main HTTP RFC says is that new methods “ought” to be registered. So having an enum of methods that’s required in APIs wouldn’t be realistic given there are (likely very many) extant non-standard/non-registered methods, and likely would be a maintenance and backwards-compatibility headache for the library authors.
7
worr 7 days ago (unread) | link | That’s not the part I have an issue with, it’s combining the route and the method as a single string argument to Handle*. I’ve worked at places that have used custom HTTP methods before, I totally get why it’s useful to allow them.
But I don’t like that it’s so easy for someone to accidentally specify "GET/foo/bar" and not have the compiler catch such an easy mistake. I’d much rather have a separate method, as the author mentioned. It’d make the distinction more obvious, and you could even take advantage of the http.Method* constants (without resorting to string concat).
---
Python vs Golang stdlib: "To be honest, I’d still probably reach for Python first for throwaway scripts, because of its terser syntax, list (and other) comprehensions, and exception handling by default. However, for anything more than a throwaway script, I’d quickly move to Go. Its standard library is better-designed, its io.Reader and io.Writer interfaces are excellent, and its lightweight static typing helps catch bugs without getting in the way." -- https://benhoyt.com/writings/gogit/
---
" Support many kinds of terminals. The minimal demands are cursor positioning and clear-screen. Commands should only use key strokes that most keyboards have. Support all the keys on the keyboard for mapping" -- https://github.com/vim/vim/blob/531da5955e03afadb2f0cf72264fe8deb4bf430e/runtime/doc/develop.txt#L145-L153
---
9 nikki93 27 hours ago
| link | flag |
I like Raylib’s API a lot these days for doing graphics from C. Also works well on Emscripten.
~
Sirocco 10 hours ago | link | flag | I’ve converted quite a few people from SDL to Raylib in the last two years. It really feels like a spiritual successor to Allegro 3, back when you could bang out a quick project in a matter of minutes.
---
https://www.raylib.com/cheatsheet/cheatsheet.html
---
"std vs core vs alloc -- it'd be better if std didn't actually re-export core, because then more programs could be no_std implicitly. alloc is kinda a red-headed stepchild in this hierarchy; Zig's approach of explicit allocator objects everywhere may or may not be superior. Talk to some of the stdlib or embedded people about how they'd want to arrange it if they could; papering over weird platforms like wasm is a known annoyance. Maybe something like core for pure computational things, sys for platform-specific low-level stuff like threading and timekeeping primitives that may appear in a microcontroller or low-level VM without a full OS, then os or something for stuff like filesystems, processes, etc. Need better names though. I do like the idea of splitting out specific capabilities into specific parts that may or may not be present on all platforms though, instead of having a strictly additive model." -- https://sr.ht/~icefox/garnet/
---
https://learn.microsoft.com/en-us/cpp/cpp/run-time-type-information?view=msvc-170
---
https://ares-os.org/docs/helios/
"
System calls
writecons
yield
identify
send
recv
signal
wait
nbsend
nbrecv
nbwait
call
reply
poll
pollx"
" Capabilities
Null
ASID control
ASID pool
CSpace
Device memory
Endpoint
Memory
Notification
Reply
Task
VSpace
x86_64"---
https://vmartin.fr/understanding-automatic-differentiation-in-30-lines-of-python.html
---
