Yeah, you definitely don't want to hang things off the wrong seams, or you'll end up with quite the blast radius
215 karma · joined January 10, 2014
It certainly doesn't feel like there's a trillion-dollar-company difference between those two and Tahoe.
My biggest annoyance at the moment (and this may be me missing something), is that I have two directories: "thing" and "thing-api". I'm doing work in "thing" much more often than in the "thing-api", but whenever I run "z thing", it takes me to "thing-api" first, and I have to "z thing" again to get to where I wanted to go. It ends up being more effort than if I'd just tab-completed or history searched a plain cd command.
I think my actual issue is that the "most package managers do something like this" example code snippet at the start of [1] doesn't seem to quite make sense - or doesn't match what I guess would actually happen in the decompress-in-a-loop scenario?
As in, it appears to illustrate building up a buffer holding the compressed data that's being received (since the "// ... decompress from buffer ..." comment at the end suggests what we're receiving in `chunk` is compressed), but I guess the problem with the decompress-as-the-data-arrives approach in reality is having to re-allocate the buffer for the decompressed data?
[1] https://bun.com/blog/behind-the-scenes-of-bun-install#optimi...
> Bun takes a different approach by buffering the entire tarball before decompressing.
But seems to sidestep _how_ it does this any differently than the "bad" snippet the section opened with (presumably it checks the Content-Length header when it's fetching the tarball or something, and can assume the size it gets from there is correct). All it says about this is:
> Once Bun has the complete tarball in memory it can read the last 4 bytes of the gzip format.
Then it explains how it can pre-allocate a buffer for the decompressed data, but we never saw how this buffer allocation happens in the "bad" example!
> These bytes are special since store the uncompressed size of the file! Instead of having to guess how large the uncompressed file will be, Bun can pre-allocate memory to eliminate buffer resizing entirely
Presumably the saving is in the slow package managers having to expand _both_ of the buffers involved, while bun preallocates at least one of them?
Is there a different POST request in the readme or are you saying that this example is going to send the "user" and "password" params in the request body?
> POST https://example.org/login?user=toto&password=1234
That seems really surprising to me - how would you then send a POST request that includes query string parameters? The documentation on form parameters [1] suggests there's an explicit syntax for sending form-encoded request parameters
Then you don't use property promotion. It's optional: it only happens if you add a visibility modifier before the parameter name.
[1]: https://www.php.net/manual/en/language.types.string.php#lang...
[1]: https://www.gamesindustry.biz/articles/2020-08-20-valve-assu...
00 01 10 11
00000 NUL Spc @ `
00001 SOH ! A a
00010 STX " B b
00011 ETX # C c
00100 EOT $ D d
00101 ENQ % E e
00110 ACK & F f
00111 BEL ' G g
01000 BS ( H h
01001 TAB ) I i
01010 LF * J j
01011 VT + K k
01100 FF , L l
01101 CR - M m
01110 SO . N n
01111 SI / O o
10000 DLE 0 P p
10001 DC1 1 Q q
10010 DC2 2 R r
10011 DC3 3 S s
10100 DC4 4 T t
10101 NAK 5 U u
10110 SYN 6 V v
10111 ETB 7 W w
11000 CAN 8 X x
11001 EM 9 Y y
11010 SUB : Z z
11011 ESC ; [ {
11100 FS < \ |
11101 GS = ] }
11110 RS > ^ ~
11111 US ? _ DEL