" 6/30/10 stupid idea 247: worlds smallest vector maths library Here is a tiny 3d vector maths library:
typedef float vec3[3]; vec3 *vec(vec3 *v, float x) {v[0]=v[1]=v[2]=x;return v;} float *mav(vec3 *v1,vec3 *v2,vec3 *v3,vec3 *v4,vec3 *v5){ for (int i=0; i!=3; i++) v3[i]=v1[i]*v4[i]+v2[i]*v5[i]; return v3[0]+v3[1]+v3[2]; } vec3 VZERO={0,0,0}; vec3 VONE={1,1,1}; vec3 VMONE={-1,-1,-1};
Thats it. It can do zero, set, add, sub, length2, dotprod, negate, lerp, centroid. e.g add is : mav(&v1, &v2, &v3, &VONE, &VONE ); v3=v2+v1
Lerp means that centroid (the centre vertex of a quad) can be found without a division by using two lerps. For a moment it seems cool until you realise the calls to it dont compress all that well. The challenges remaining are xprod, normalise and max/min. then I have everything for handling my 3d modeller qoob.If I can make minor adjustments to get those, this might be worth persuing. "
-- [1]
the author is trying to make a small (or compressible) CGI file format and renderer for demo intros. But for us the most notable thing here is the list of vector math library functions that e considers important:
---
https://github.com/japaric/steed
rec. by [2]
"
Current functionality
Check the API docs, but to summarize the functionality that interfaces with the Linux kernel:
Standard I/O (stdin, stdout, stderr)
File I/O
Filesystem operations (std::fs)
std::net: TCP, UDP. lookup_host is missing.
Dynamic memory allocation (thanks to ralloc!)
std::time
Minimal thread support.
Yup, that's all! I did say it was very early days, didn't I? "
https://japaric.github.io/steed/steed/index.html
---
" In its minimum configuration, SQLite requires only the following routines from the standard C library:
memcmp()
memcpy()
memmove()
memset() strcmp()
strlen()
strncmp() In a more complete build, SQLite also uses library routines like malloc() and free() and operating system interfaces for opening, reading, writing, and closing files. "
---
rec. by [3]:
https://www.codeproject.com/Articles/15156/Tiny-C-Runtime-Library
"Ever designed a simple utility program, such as a hex-dump program, only to find your simple program is a full 64K, optimized for size, when all it does is read a file and print to stdout? Ever wonder what happened to those good ol' DOS days where programs had to be small? Where a COM file was limited to 64K? Or when you can write a bare-bones DOS-style protected mode operating system kernel in about 64K?
...
Of course, by replacing the CRT, programs that rely on specifics of the Microsoft CRT will fail. For instance, if you go digging into the FILE structure, or expect a certain header on your memory allocations, or rely on the buffering features of stdio, or use locales, runtime checks, or C++ exception handling, you can't use this library. This library is aimed for use by small, simple programs, such as a hex-dump command line program or the many UNIX-style tools like cat or grep. "
---
knightOS, an OS for calculators. Seems like mostly a small and cool stdlib:
http://www.knightos.org/documentation/reference/
---
https://github.com/Quuxplusone/from-scratch
---
some immutable data structure libraries:
a Rust one: https://docs.rs/im/10.0.0/im/
a popular C++ one: https://github.com/arximboldi/immer
a misc/random one: http://smallcultfollowing.com/babysteps/blog/2018/02/01/in-rust-ordinary-vectors-are-values/
---
" A good list of system calls can be found here, but a common list of important ones is:
open()
close()
read()
write()
lseek()
stat()
mmap()
munmap()
madvise()
mprotect()
fcntl()
ioctl()
connect()
accept()
bind()
access()
select()
getpid()
getuid()
gettimeofday()
clock_gettime/()
time()
mkdir()" [4]
---
" Results
After recompiling the program with libctiny and the method above, the EXE jumped from a giant 64K to a much more reasonable 4K! (4096 bytes to be exact). For comparison, the entire code section of the linker map file is reproduced below: Hide Copy Code
0001:00000000 ?DumpFile?@@YAXPAD@Z 00401000 f hd.obj 0001:0000013d _main 0040113d f hd.obj 0001:0000021a _fopen 0040121a f libct:file.obj 0001:000002a7 _fread 004012a7 f libct:file.obj 0001:000003c2 _fwrite 004013c2 f libct:file.obj 0001:0000048b _fgetc 0040148b f libct:file.obj 0001:000004b6 _printf 004014b6 f libct:printf.obj 0001:000004ef _memset 004014ef f libct:memory.obj 0001:0000050e __doexit 0040150e f libct:initterm.obj 0001:0000053a _mainCRTStartup 0040153a f libct:crt0tcon.obj 0001:000005f5 _malloc 004015f5 f libct:alloc.obj 0001:00000607 __init_args 00401607 f libct:argcargv.obj 0001:00000705 __ismbcspace 00401705 f libct:isctype.obj
"
---
small GUI library:
https://github.com/ocornut/imgui
---
https://github.com/fantasyland/fantasy-land https://github.com/rpominov/static-land https://github.com/sanctuary-js/sanctuary-type-classes https://github.com/sanctuary-js https://github.com/sanctuary-js/sanctuary https://github.com/fluture-js/Fluture
https://monet.github.io/monet.js/
---
How does Fluture differ from other solutions?
The description of Fluture states that it's an alternative to Promises, so it's only natural that people want to compare it. In my article comparing Futures to Promises I write:
On the surface Futures are just like Promises, but with the different behaviors of the .then method extracted into three distinct functions, each with a single responsibility.
The then method of a Promise is massively overloaded: You can give it zero to two arguments, both are mixed types (Nil and Function). The return values of the functions are also overloaded: You can return any value, but returning something with a then-method has a particular meaning. Throwing an error also has special meaning.
Extracting all of these behaviors to separate functions makes it easier to abstract over, and clarifies developer intent, making it simpler to detect mistakes.
I've also written about the differences between Fluture and other libraries which have a similar structure, in my article comparing them. I'll go into this when answering why I developed Fluture.
---
" The colors: the color format has been chosen so that more sensible and neutral colors are more likely than "coder colors". YUV has been chosen over HSV because there is relatively universal hardware support for YUV buffers (and I also think it is easier to get richer gradients with YUV than with HSV).
Trigonometric functions: I pondered for a long while whether to include SIN and ATAN2 and I finally decided to do so. A lot of demoscene tricks depend, including all kinds of rotating and bouncing things as well as more advanced stuff such as raycasting, depends on the availability of trigonometry. Both of these operations can be found in the FPU instruction set of the x86 and are relatively fundamental mathematical stuff, so we're not going into library bloat here. " [6]