phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one ☟︎☟︎

phf: maintaining two separate builds in the same patch tree is sort of experimental, and i'm happy that it seems to work out of the box

phf: i think brk/sbrk is a reasonable alternative to malloc, since it makes a claim on a certain amount of processes's address space, without allocator's bookkeeping, that you then can use for heterogenous purposes. it's a dynamic alternative to having something like a static int heap[HEAP_SIZE] in your code.

phf: there's a bunch of others, around i think gets/getc, brk/sbrk, etc.

phf: spyked: if you sign your patch, i can include it in the vtools graph, a "collaborative" experience :)

phf: in other words, it's either static inline or the #define { ...} while(0); trick, because extern inline/inline doesn't make any guarantees. i think it'll be adequately tmsr solution to just moved those definitions into own functions and not worry about "speed"

phf: spyked actually fixed it before, http://btcbase.org/log/2018-03-01#1786600 unfortunately i don't understand the problem/solution, http://archive.is/w6W7P i think originally difftools had some conditional #define there ☝︎

phf: i'm not sure it's the correct solution then, i thought you reproduced. xn* is defined by differ itself in xalloc.c, so it might have something to do with multiple includes and specific combination of static/inlines

phf: the issue was already reported by someone else, but at the time the suggested fix was to put a bunch of C level annotations (some combination of static inlines), which i didn't think was an adequate solution, given that i don't understand why it does or doesn't work. but ascii's explanation makes sense, though i can't reproduce the issue on any of the machines i have with adacore's gnat (freebsd, osx, debian)

phf: asciilifeform: building weechat on a work laptop using homebrew. i mean, that's deep behind enemy lines, so it's not surprising, but i'm fascinated by the increasing levels of fail

phf: i've avoided any particular scheme, because it might introduce equivalence that doesn't exist. sha512 as an "alternative" vs. sha512 as aggressively deprecated.

phf: right now keccak/sha512 vpatches are not differentiated in any way, so having both of them in the same workflow might result in confusion (in fact it did when i was testing things at some point). it might be worthwhile to introduce some kind of hash tagging scheme, eg keccak:<hash> vs sha512:<hash> and keep <hash> without prefix as sha512 for legacy reasons.

phf: i took a long walk over sf hills, and wanted to take an ocean dip at the end, but the last 15km on the way to the ocean were on flats, with a piercing cold wind. i was cold wearing a shirt and a sweater, so no swimming, but still it was a pleasant walk. there's really nothing bad to say about the weather here.

phf: http://btcbase.org/log/2018-03-26#1789697 << not as hot as palm springs (which is full blown summer at this point), but basically spring. it was raining last week, but right now it's a shirt weather. if you're close to the ocean, then it's blowing cold wind. what i'm trying to say is that the weather is excellent, and i'm loathing going back to the swamps. ☝︎