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?
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: (I mirrored the gnat I recommend too, given previous experience with everything pretty much)
jurov: mod6: ben_vulpes: invoice paid
mod6: jurov: Excellent, thank you!
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
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.
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
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: bird was there for a good half hour, trying to figure out how to best extract the quarry, it was something else.
mod6: it's pretty fortunate to see such a thing!
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: "oh shit, it thinks my schlong is a snake! take cover!"
mod6: The size of the claws on that thing tho!
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.
mircea_popescu: i am thinking this is actually something that needs changing in vdiff and being made a general rule.
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: but anyway, yes, "forbid linking libc ~in libraries~".
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
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
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: 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
mircea_popescu: asciilifeform i dunno that it's entirely wrong ; "don't link libc if you're making a library" is right!
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."
☟︎ 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 :)
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
mircea_popescu: that "warning" utterly offends me, if it wasn't obvious.
mircea_popescu: then doods walk in here with "oh, rms gotta be respekted for his contribution"
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
phf: there's a bunch of others, around i think gets/getc, brk/sbrk, 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: well, it's an alternative methodology. malloc keeps track of allocation chains, defragmentation etc.
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: 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: 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)
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!
xanthyos: yeah mircea_popescu dpb told you to tell you he did this
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)
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: 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.
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?