Sounds like you are arguing with a bot? em-dashes are a giveaway (nobody sane uses these "—")
I go through periods of loving em dashes--but I always just write them as two dashes! (And LaTeX at least does the right thing.)
Readit Newsmsully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
msully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
> Our nightly CI machines run on Amazon AWS, which has the advantage of giving us a real, uncontainerized root user.
> We don’t have the necessary files outside of the container, and our containers are quite minimal and don’t allow us to easily install gdb.
Have people lost the ability to build and debug their code locally, without clouds and containers?
> Have people lost the ability to build and debug their code locally, without clouds and containers?
No, of course not, but it didn't crash on our machines!
msully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
We had so many of these issues that we ended up LD_PRELOAD-ing patch getenv / setenv / putenv
With a fixed implementation that leaks environments (like the one that just landed in glibc)?
msully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
The problem is that applications sometimes need to set environment variables which will be read by libraries in the same process. This is safe to do during startup, but at no later times.
Ideally all libraries which use environment variables should have APIs allowing you to override the env variables without calling setenv(), but that isn't always the case.
Yeah, the cows have certainly gotten out already.
msully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
Why requiring unsafe when the std implementation could take care of the synchronisation?
Because it can still race with C code using the standard library. getenv calls are common in C libraries; the call to getenv in this post was inside of strerror.
msully4321 commented on C stdlib isn't threadsafe and even safe Rust didn't save us edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
Env vars are good if you treat them as read-only within the process
Yeah, setenv should probably just not exist, and environment variables should be only set when spawning new processes.
I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
I talked a bit about this in my release day talk (https://www.youtube.com/watch?v=WRZ3o-NsU_4&t=8151s), but:
* Every edgedb type has a postgres table
* "single" properties and links are stored as columns in that table (links as the uuid of the target)
* "multi" properties/links are stored as a link table
So it's basically just translated to a relational database in normal form
Dumb question, how do you exit the shell? I feel like I've scoured the docs and can't find it.
What colin said, or (in every terminal emulator I've used), ctrl-d to send end of file, which will close it.
How do I join tables 1:1 without creating a subfield, i.e.:
table1: id, name
table2: table1_id, level
Desired result:
{id, name, level}
The most direct implementation of what you want would be:
SELECT (Table1.id, Table1.name, Table2.level, Table2.table1_id)
FILTER Table1.id = Table2.table1_id;
If you want to use edgeql's shapes but still keep the essential join flavor, then something like:
SELECT (Table1 { id, name }, Table2 { level })
FILTER Table1.id = Table2.table1_id;
SELECT (Photo {uri}, User {name, email})
FILTER Photo.author.id = User.id;