113500+ entries in 0.076s
mod6: which is
the only version i've been able
to stand up
that seems
to work 100% with ffa.
mod6: for what its worth, at
the bottom of my paste, i've denoted
that im using gcc 4.9.4 and adacore 16
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
mod6: (the new rules in my V99993 do not allow for pressing
to multiple leaves, so just was curious
to what
the blessed press path (required vpatches) was
to get
these)
mod6: yup, ok. but as far as my "V" usage, was
this correct?
phf: mod6: pressing
to different
tails should produce alternative builds without any conflicts. but
the issue has been discovered, and it requires a patch. spyked originally found both
the problem and
the solution
☟︎ mod6: But what I ended up doing is pressing
to leaf 'vdiff_sha_fixes_newline_gcc.vpatch' into 'vtools', and pressing
to leaf 'vtools-vpatch.vpatch' into 'vtools_2'. I went into vtools_2, and found
the similar problems as hanbot.
mod6: So
there are a few
things
that I probably should ask about, as it wasn't wholly clear
to me about
the pressing side of
things. Since
there are multiple roots, and multiple leaves,
there are
two different press paths. Now, maybe I'm not supposed
to have all of
these in
there?? But it looked
to me from
the
thread at phf's site,
that I needed
to have
them all.
phf: well, it's an alternative methodology. malloc keeps
track of allocation chains, defragmentation etc.
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: yeah,
that warning made me patch and recompile libc 10 years ago, might've been one of
the first excursions into pre-tmsr rage holes
mircea_popescu: myeah. but
taki8ng out libc ALTOGETHER seems very appealing right now
phf: in
this case
the issue is
the "legacy" diff code, removing autotools scaffolding means having
to
track down
these kind of portability issues,
that appear exclusively around "optimized" code. ada core is its own, separate can of worms
mircea_popescu: this is pretty
terrible altogether. ave1 you got a moment ? how close is alf's "quite close" ?
☟︎☟︎ 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: "Making a function an inline function suggests
that calls
to
the function be as fast as possible.
The extent
to which such suggestions are effective is implementation-defined."
spyked: there is another (non-)solution: #define bla(arg1,arg2) { code_to_be_inlined } while(0); results in no duplicate function definitions, but also no
type checking is performed on
the args, so no warnings etc. quite
the ugly.
phf: this gnulib solution actually wants you
to define FOO_INLINE, which is set
to "inline" when defined, and "extern inline" when used, so you can't even avoid
the #define hackery with "extern inline". "Other non-C99 compilers use static inline so
they suffer from code bloat, but
they are not mainline platforms and will die out eventually."
☟︎ mircea_popescu: asciilifeform i dunno
that it's entirely wrong ; "don't link libc if you're making a library" is right!
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: these kind of flags are set by ~xml~ files inside gnat's gprbuild support files, so
there can be a general patch on gnat
to do
the right
thing
mircea_popescu: anyway,
the pile of ad-hoc name systems in legacy unix is starting
to get on my heads. PATH, really ? amnd
then "use mkdtemp" and fucking hell already
mircea_popescu: and also,
this isn't so much hanbot's gnat, but really
the copy diana_coman 's maintaining
that's for all intents and purposes
the candidate for standardization.
mircea_popescu: i am
thinking
this is actually something
that needs changing in vdiff and being made a general rule.
mircea_popescu: anyway, whole issue seems
to be
that mktemp could "guess" a file
that's about
to be created by root and wipe it.
mod6: smh. im gonna
take a few minutes here and
try
to build phf's
thing. will report back in a bit.
mircea_popescu: let's just make idle pointless strongly worded warnings
to maintain
the general state of pantsuit mindset!@!1
mircea_popescu: fucking idiots put it in
the linker, but NEVER INCLUDED ANY DISCUSSION of why
the fuck.
mod6: oh
this is all C call related stuff.
mod6: huh, well
that's news
to me -- I was prodded
to use
that in
the latest version of my vtron. I'll have
to look into
that. Not
that my
thing is related
to hanbot's problem.
mod6: The size of
the claws on
that
thing
tho!
mod6: "oh shit, it
thinks my schlong is a snake!
take cover!"
mircea_popescu: like
two-three meters out on
the balcony, you know... at first i
thought it's swooping in for my dick.
mod6: diana_coman:
thanks for your careful reading of
the Pizarro Feb statement,
the error has been corrected, I believe.
mod6: it's pretty fortunate
to see such a
thing!
mircea_popescu: bird was
there for a good half hour,
trying
to figure out how
to best extract
the quarry, it was something else.
mod6: btw, I enjoyed
the pics from
the eagle (falcon) post. how majestic was
that 'eh?
mod6: <+mircea_popescu> eggs can
totally do it
though. << yeah, I
think you're probably right. i was fine until about 3-4 hours after breakfast.
mircea_popescu: in other unrelated not-news, "gun crazy" is a
terrible "film". just
thought nobody'd like
to know.
mod6: it /is/ possible
that it could have been some ahi
tuna from
the day previous. but no one else who ate it got sick.
mod6: How's it goin
today all?
hanbot: yeah, dling nao,
thanks
diana_coman: hanbot,
try it now; wp messed up
the link, gah
mod6: jurov: Excellent,
thank you!
diana_coman: (I mirrored
the gnat I recommend
too, given previous experience with everything pretty much)
hanbot: phf listen, i failed
to anticipate my build environment being incapable of making yer patcher. wouldja mind sharing how you put
together what you compiled your keccak vpatch with?
mircea_popescu: mmm pretty sure diana_coman has a holy gnat incarnation somewhere, part of
the eucrypt writeup.
hanbot: i haven't put
together anything special for ada yet. what was
that supposed
to be, install gnat (which ?)?
mircea_popescu: (bash) error 127 just means
the command's not found in your path.
mircea_popescu: hanbot anyway, are you using jam/ftjam or what's
the connection ? leftover build process from eulora basically ?
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
mod6: jurov^
The above is a Pizarro invoice for services rendered
to
The Bitcoin Foundation during
the Month of March. Please remit
the amount indicated
to
the address indicated in
the deed.
Thanks in advance! Please let me know if you have any questions.
a111: Logged on 2018-03-27 05:21 ben_vulpes: mod6: please approve ^^ and ping
teh
treasurer for payment
mod6: <+hanbot> ooo
ty asciilifeform, quite right. now how did i end up with old vtron and new usermanual, lol << oh, herp, didn't even see
this.
mod6: (where 'vtools' is
the press output directory)
mod6: <+hanbot> p.bvulpes.com/pastes/Sqn1u/?raw=true << anyone else ever seen
this wonder? << you're missing a output directory
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: (but just
to further clarify, vtools patchset is all SHA512, so pressing it will work with all
the existing
tooling. vtools's vdiff can be pressed
to have either keccak or sha512 support. vtools's vpatch at
the moment can be pressed
to have keccak support only.)
phf: vtools graph
that's on btcbase is all sha512
a111: Logged on 2018-03-27 18:06 mircea_popescu: phf does your new vdiff (that's supposed
to introduce keccak into
the build flow) actually REQUIRE
the presser ALREADY HAVE keccak ?
mircea_popescu: phf does your new vdiff (that's supposed
to introduce keccak into
the build flow) actually REQUIRE
the presser ALREADY HAVE keccak ?
☟︎ BingoBoingo: Pigs also do more bad sports drugs
than most ballsketsport players
mircea_popescu: in other lulz, did you know pigs actually have lower fat ratios
than human females ? 70% or so muscle dem ripped oinkers.
hanbot: oh man, you have any idea how much
time you prolly just saved me? phew
hanbot: ooo
ty asciilifeform, quite right. now how did i end up with old vtron and new usermanual, lol
trinque: just want
to cogitate on which implementation will least obstruct future sanity
trinque: certainly
the
thing is needed in
the abstract. service exists and user wants a stream of happenings.