hanbot: "$ make vpatch gprbuild -Pvpatch.gpr make: gprbuild: Command not found make: *** [vpatch] Error 127" << is this https://www.jamf.com/jamf-nation/discussions/17322/problems-with-good-scripts-failing-exit-code-127 then?
mircea_popescu: ugh.
mircea_popescu: it's certainly the "things work" thing.
mircea_popescu: hanbot anyway, are you using jam/ftjam or what's the connection ? leftover build process from eulora basically ?
mircea_popescu: (bash) error 127 just means the command's not found in your path.
hanbot: i haven't put together anything special for ada yet. what was that supposed to be, install gnat (which ?)?
mircea_popescu: mmm pretty sure diana_coman has a holy gnat incarnation somewhere, part of the eucrypt writeup.
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: in other ancient t-lulz asciilifeform might've missed, http://trilema.com/2011/bai-deci-m-am-indragostit-de-un-barbat/
diana_coman: hanbot, if it's an ada project, you don't need make, just go "gprbuild" in its dir
diana_coman: (it'll even figure out which .gpr you mean if it's only one)
diana_coman: obv you need gnat; see here: http://www.dianacoman.com/2018/03/08/eucrypt-compilation-sheet/
diana_coman: (I mirrored the gnat I recommend too, given previous experience with everything pretty much)
jurov: mod6: ben_vulpes: invoice paid
asciilifeform bought his tickets to BingoBoingostan
BingoBoingo: asciilifeform: Welcome
mod6: jurov: Excellent, thank you!
BingoBoingo: Hollywood whistleblower Corey Feldman maybe stabbed? https://archive.is/CLM2L
mod6: heh
mircea_popescu: with a pencildick or ?
BingoBoingo: Well, during the 1980's
BingoBoingo: Charlie Sheen's and maybe Martin's too
mircea_popescu: heh
hanbot: <diana_coman> obv you need gnat; see here: http://www.dianacoman.com/2018/03/08/eucrypt-compilation-sheet/ << thanks for the pointer --looks like relevant gnat & shasum 404 though?
diana_coman: hanbot, try it now; wp messed up the link, gah
hanbot: yeah, dling nao, thanks
mod6: How's it goin today all?
mod6 feels much better after a nasty round of food poisoning
mircea_popescu: ow
mircea_popescu: seafood ?
mod6: naw, eggs :/
mod6: (i speculate)
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: so, maybe?
mircea_popescu: nah, not over a day like that.
mircea_popescu: eggs can totally do it though.
mircea_popescu: in other unrelated not-news, "gun crazy" is a terrible "film". just thought nobody'd like to know.
lobbes: !!pay-invoice ben_vulpes 1
deedbot: Get your OTP: http://p.bvulpes.com/pastes/G0aZK/?raw=true
lobbes: !!v 4D9E62426F146A1493B9C37CD1076860ACF3BB9A0286332F3948EF9CE8AB661F
deedbot: lobbes paid ben_vulpes invoice 1
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.
mod6: btw, I enjoyed the pics from the eagle (falcon) post. how majestic was that 'eh?
mircea_popescu: you know ?
mircea_popescu: bird was there for a good half hour, trying to figure out how to best extract the quarry, it was something else.
mircea_popescu: they got grace!
mod6: it's pretty fortunate to see such a thing!
mod6: was kinda jelly.
mod6: diana_coman: thanks for your careful reading of the Pizarro Feb statement, the error has been corrected, I believe.
mircea_popescu: like two-three meters out on the balcony, you know... at first i thought it's swooping in for my dick.
mod6: i'd be scared too.
mod6: lol
mod6: "oh shit, it thinks my schlong is a snake! take cover!"
mircea_popescu: lol
mod6: The size of the claws on that thing tho!
hanbot: phf : installed gnat with diana_coman's help; vpatch.gpr looks alright (maybe? http://p.bvulpes.com/pastes/LwAtx/?raw=true), but vdiff.gpr won't build for me: http://p.bvulpes.com/pastes/yS82H/?raw=true
mircea_popescu: mktemp is dangerous ?
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: oh this is all C call related stuff.
mod6: I might be in over my head, phf, enlighten us when you have a moment plz.
mircea_popescu: fucking idiots put it in the linker, but NEVER INCLUDED ANY DISCUSSION of why the fuck.
mircea_popescu: let's just make idle pointless strongly worded warnings to maintain the general state of pantsuit mindset!@!1
mod6: smh. im gonna take a few minutes here and try to build phf's thing. will report back in a bit.
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.
asciilifeform: funnily enuff, if working rng were standard on pc, 128bits from it would give unique-gensym ( the supposed problem , according to the gcc nitwits, with mktemp , is collision ) without O(N) searching ( as in mkstemp) with probability ~1
asciilifeform: hanbot, mircea_popescu , et al : observe in phf's http://btcbase.org/patches/vtools-vpatch/tree/vtools/vdiff.gpr , he did not forbid the linking of libc into the library ( as i did in http://btcbase.org/patches/ffa_ch1_genesis/tree/ffa/libffa/ffa.gpr#L46 ) . apparently this worx on some gnat, but on hanbot's -- barfs
mircea_popescu: asciilifeform yes ; and yeah!
mircea_popescu: i am thinking this is actually something that needs changing in vdiff and being made a general rule.
asciilifeform: which this
mircea_popescu: "forbid linking libc"
asciilifeform: we still dun have a gnat-for-pc that shits out a binary ~wholly~ without libc ( although ave1 iirc is working on one and is quite close ) . but hanbot's issue is that libc got linked ~into the lib~ which results in attempting to link with 2 copies of libc (1 goes into the main) .
mircea_popescu: yes.
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: at least until/unless ave1 publishes a superseder.
asciilifeform: right
mircea_popescu: but anyway, yes, "forbid linking libc ~in libraries~".
asciilifeform: ( even superceder, should really be a vpatch on diana_coman's artifact imho )
mircea_popescu: if feasible, ideally, yeah.
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: gns, when.
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: o hey you're right aren't you.
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)
asciilifeform: phf: i also was unable to reproduce. but i have not yet switched to the exact 'candidate gnat' in question.
asciilifeform: but in principle the answer seen in my gpr, is the pill. no libc in libs, it makes for duped linkage. (incidentally just as barfy in a c/cpp proggy as in gnat)
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
asciilifeform: it's a libc function
asciilifeform: and does. not. belong. in. a. library
asciilifeform looks again
phf shakes head.
asciilifeform: oh hmm
asciilifeform: ha, ~xnmalloc~, not xmalloc
asciilifeform: strike my observation, then, it is entirely wrong.
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☝︎
a111: Logged on 2018-03-01 13:52 spyked: anyway, comment was that I managed to compile and run vdiff with small mods; error: http://p.bvulpes.com/pastes/BiBTI/?raw=true and fix patch: http://p.bvulpes.com/pastes/9mOiz/?raw=true (tested this with the generated vdiff); I can try to link this reply later in a comment to test.
mircea_popescu: asciilifeform i dunno that it's entirely wrong ; "don't link libc if you're making a library" is right!
asciilifeform: mircea_popescu: it is a correct pill but not the culprit in hanbot's case : phf however just nao found the actual culprit
mircea_popescu: possibru
asciilifeform: phf: inline + extern would have also worked
phf: https://www.gnu.org/software/gnulib/manual/html_node/extern-inline.html is specific issue
asciilifeform: ^
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."
phf: hmpf
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: "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."
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: if you sign your patch, i can include it in the vtools graph, a "collaborative" experience :)
spyked: sure! one sec.
mircea_popescu: heh
mircea_popescu: this is pretty terrible altogether. ave1 you got a moment ? how close is alf's "quite close" ?
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: myeah. but taki8ng out libc ALTOGETHER seems very appealing right now
phf: yes.
mircea_popescu: that "warning" utterly offends me, if it wasn't obvious.
asciilifeform: libc has been musting-die for many many yrs.
mircea_popescu: then doods walk in here with "oh, rms gotta be respekted for his contribution"
mircea_popescu: dudes take glibc and fucking shove it.
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
asciilifeform: even a musl gnat would be considerable improvement.
phf: there's a bunch of others, around i think gets/getc, brk/sbrk, etc.
asciilifeform: heapless proggies dun even need brk/sbrk.
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.
asciilifeform: every malloc i know of is implemented on top of sbrk
asciilifeform: so 'alternative' is not exactly right word imho
asciilifeform: but yes on linux the only 2 ways to get moar memory than the loader loaded you with, is sbrk and mmap
phf: well, it's an alternative methodology. malloc keeps track of allocation chains, defragmentation etc.
mod6: Ok, so I have replication : http://p.bvulpes.com/pastes/YPdvz/?raw=true
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.
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.
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: yup, ok. but as far as my "V" usage, was this correct?
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)
phf: mod6: yes
mod6: ok. gotcha.
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: ah, i see.
mod6: for what its worth, at the bottom of my paste, i've denoted that im using gcc 4.9.4 and adacore 16
mod6: which is the only version i've been able to stand up that seems to work 100% with ffa.
mod6: (which is why i chose this particular environment to build your vtools upon)
mircea_popescu: !!up xanthyos
deedbot: xanthyos voiced for 30 minutes.
phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one
mod6: if there's a way to check, let me know, be happy to paste you the results.
xanthyos: mircea_popescu: dpb just said he'd give me free btc if i had enough presence in the wot to be able to !up myself
mod6: wow, can i get the same deal dpb?
xanthyos: i installed gpg software on this machine when he knew full well i wouldnt 'be able to do anything with it
xanthyos: danielpbarron: 18GC2RatxcABtidXksR6ry5E6hvBkgzf2t
mod6: well, read some docs, make a key, register it. then up yourself. 1 BTC is a hefty prize!
mircea_popescu: good for you.
danielpbarron: he has a key
xanthyos: not a full coin
xanthyos: some btc
mod6: ah
danielpbarron: his rep in the WoT is not enough to voice
xanthyos: yeah mircea_popescu dpb told you to tell you he did this
xanthyos: told me to tell you*
xanthyos: we're in voice chat right now
xanthyos: https://discord.gg/j7TNPqk
spyked: my v-fu really leaves to be desired. so: http://btcbase.org/log/2018-03-28#1790147 <-- patch: http://lucian.mogosanu.ro/v/patches/vdiff_lib_xalloc_static_xnmalloc.vpatch and seal: http://lucian.mogosanu.ro/v/seals/vdiff_lib_xalloc_static_xnmalloc.vpatch.spyked.sig --> so I based those on vdiff_fixes_newline_gcc (parent of vdiff_keccak in http://btcbase.org/patches?patchset=vtools ) and while the patch verifies, it doesn't show up in my☝︎
a111: Logged on 2018-03-28 20:37 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
spyked: v.pl flow. not sure how to debug this yet, but I can take a look at it tomorrow
spyked: (also, I had to redo the patch anyway, since I initially used the keccak vdiff; but I'm pretty sure this should be a child of vdiff_fixes_newline_gcc, since the hashes for vtools/lib/xalloc.h match)
mod6 looks
spyked: thanks mod6. I wonder if it's one of those cases that spawned the discussion which led to the idea of a manifest file. in any case, it looks like the patch above (vdiff_lib_xalloc_static_xnmalloc) can have multiple children.
trinque: sure, antecedents are per-file, so if you want to have one line of history, gotta have a file that is the line.
trinque: my thinking on the thing is that it's as simple as each patch introducing a new line in HISTORY that matches the patch's name.
mod6: spyked: http://p.bvulpes.com/pastes/gUr8Y/?raw=true
mod6: so here's the deal, your vpatch & sig do verify by hand, so that part is fine. the problem lies in the fact with all of phf's vpatches in your 'patches' directory, your vpatch tries to come from two separate antecedents.
mod6: This is not ok. And is rejected. I simply removed the two vpatches that are not required for the latter path (see the paste above where i simply pressed 'vtools_2', the second press-path) then your vpatch is included to the flow no problem.
spyked: hm. I understand the specific problem with my vpatch set now. I'll reread the whole discussion to make sure I've wrapped my head around this.
mod6: ok, cool.
spyked: so the idea is to keep either vtools_genesis -> vtools_vdiff_sha -> vdiff_sha_fixes_newline_gcc or vtools_genesis -> vdiff_fixes_newline_gcc -> ... patches, but not both at the same time. because in this case v.pl will see that my patch has two antecedents and will reject it.
spyked bbl, will replicate the output in the morning
BingoBoingo: <xanthyos> we're in voice chat right now << How has your injury recovered?
asciilifeform utterly fails to grasp the appeal of 'voice chats', esp. as commonly implemented ( i.e. on closed shitware )
deedbot: http://qntra.net/2018/03/ecuador-cuts-communications-from-assange-as-brits-go-on-tilt/ << Qntra - Ecuador Cuts Communications From Assange As Brits Go On Tilt
asciilifeform: achtung any and all phpists : plox to see thread in #pizarro