On M1 Macs, the compiler seems to infinite-loop, consuming ever more RAM
and CPU, while trying to build `noun/allocate.c` with `-O3 -g`. `-O3` is
fine, `-g` is fine. Both at once seems to try to summon demons.
Other possible solutions aside from this:
- try lower levels of optimization until we find one that doesn't hang,
and ship that.
- do not support M1 Mac until the underlying issue here is fixed.
- ship debug binaries on M1 for now.
The path of least resistance is of course the second option, as that's
what is already tacitly happening.
This seems to be what nix settled on.
(As of now, I can build urbit on M1 Mac with stock nix. nix-build -A
urbit hangs for some reason, but nix-shell ./configure && make works.)
Get some space between the IO driver and vane, since the driver is
mostly self-contained now and only depends on %khan for thread running.
"Conn" is a nautical term; it is the status of being in control of a
ship's movements, or the act of controlling a ship.
Before this, u3v_lily would erroneously accept atoms bigger than 64 bits
that, when truncated to 64 bits, were 31-bit numbers.
Decided to drop _cv_mole altogether. Another option would be to write a
u3r_chub_fit, write _cv_mole in terms of that, and check width in
u3v_lily as it currently does.
I tried to add a test case, but it seems that tests don't have access to
an ivory pill for +scot / +slaw. This would be the test case, more or
less:
{
c3_l lit_l;
c3_w big_w[] = {0, 0, 1};
u3_atom big = u3i_words(3, big_w);
u3_noun cod = u3dc("scot", c3__ux, big);
if ( c3y == u3v_lily(c3__ux, cod, &lit_l) ) {
printf("fail\n");
}
}
(The refcounting was also messed up, possibly from my refactor to use
+slaw instead of +slay, but this seems to have been unrelated.)
- Caught a couple potential leaks.
- Reworded error messages to be more @tas-compliant.
- Used unique error codes in bal_f calls.
- Moved u3z calls onto same line as returns.
Not sure we actually want to guarantee exactly-once response semantics,
so you can't rely on request ordering to correlate requests even if you
never send simultaneous requests.
Also do a worked example of a %urth scry, which hopefully raises the
question of whether %urth should try to support views.
It was if 0'd out in noun/vortex.c. That seems like a more reasonable
place to put it then a whole other self-contained file.
The commented version used slay instead of slaw and had an extra paren;
I opted to replace it with the impelementation from reck.c from http.c.
Inlines the server initialization in _khan_io_talk. Adds a van_o loobean
that differentiates between having the vane and missing the vane; van_o
is c3n if the %born event failed. In that case, we don't bother
forwarding %fyrd requests at all, but %peek requests still go through.
It was a mistake to call it except from _khan_close_chan, so just inline
it at the one call site. Also lets us stop doing our own pointer
juggling in _khan_io_exit.
While we're at it, flip argument order in _khan_close_chan;
superordinate first seems more natural.
- Have _khan_read_wire take a tag rather than produce it; if the tag is
not the one passed, it assumes it knows nothing of the rest of the
wire structure and simply returns c3n.
- rename _khan_search_chan to _khan_find_chan, the latter being more
flwy.
- Reformat %peek responses to start with request-id.
- Send %fyrd errors back over the channel that started the %fyrd.
- Factor out _khan_read_wire, reused by both _khan_poke_bail and
_khan_io_kick.
- Move _khan_search_chan up above _khan_poke_bail to use it there.
liv_o was always c3n without the vane. The pier was waiting for all
drivers to report liv_o == c3y. Tragedy ensued.
Maybe now we want to open the socket for peeks and moves even if the
vane is not present, so this may need to be rethought even further.
This is just the simple resolution for the culprit unearthed by
git-bisect.
