411200+ entries in 0.281s
punkman: BingoBoingo: I dunno why anyone humors
the license derps
BingoBoingo: Even qt.pro as implemented in bitcoin, for people who still use it
that way, seems more organized
fluffypony: too many disparate environments for
that
fluffypony: BingoBoingo:
that's a CMake best practices
thing,
the guy
that did
that (Ben Boeckel) is one of
the CMake developers
BingoBoingo: The way everything is organized now is also very hard
to work with. cmake scattered all over every directory
fluffypony: BingoBoingo: well it's either
that or we have
to refactor every exception into functions_windows.cpp / functions_bsd.cpp / functions_linux.cpp etc., which would make
the code splintered and extremely hard
to work with
BingoBoingo: fluffypony: Seriously
though all
the ifdefs scattered everywhere
BingoBoingo: mircea_popescu:
Time machine could also work
mircea_popescu wouldn't feel safe fucking kim w/o a coupla wrestler wingmen ready
to
tag.
fluffypony: I just fixed it
to use gettimeofday instead of ftime on BSD
BingoBoingo: So much #ifdef, seeding with
time and process id
fluffypony: BingoBoingo: you'd have
to complain
to
the author of
the OpenAES library :)
BingoBoingo: prolly skip port 25
though, MSExChange servers pissing spam everywhere prolly ruined
that one
mircea_popescu: this notion where we respect ~anything~ has got
to go.
mircea_popescu: incidentally,
the "bitcoin uses port 8333"
thing is retarded.
mircea_popescu: anyway,
the "blocking ports" bs has been going on for nigh on 20 years now.
mircea_popescu: <asciilifeform> 'v' is a double-edged sword, however, i must say, in
that it makes it possible
to build
therealbitcoin without reading patches or giving a fuck << blind
trust is only a problem
to
the blind
trustor.
assbot: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in
the cable box ... (
http://bit.ly/1JIwQce )
phf: for example
this code
http://paste.lisp.org/display/154625 validates signatures (using ccl's ffi generator and slightly patched gnupg 1.4.19), but on failure verify_signature either prints
to stdout, with no notable return code or sometimes exit(...)'s
the whole process
phf: which wouldn't be a problem in a
traditional c code, but in case of gnupg half of
the code seems
to have hidden, side channel concerns,
that i just don't have yet enough experience in practical crypto
to grok
mod6: <+asciilifeform> rather
than roasting in
the hell of figuring my patch
topology out with a pencil << imagine how much easier it is now for a person
to literally pick a place in
the flow and patch directly
to it. instead of wading
through mutliated corpses
trying
to find
the least smelly ones.
phf: sure, but i did some large scale projects using ffi (including
things like modifying arrays on heap from inside c libraries), so i don't
think it's necessarily dead end. just
that gnupg doesn't make it easy at all and requires basically full environment scaffolding before you can do anything useful
mod6: fair assesment
there. but, i
think it's great, and clean, and "works". responsibility is on
the signer
to read what
they sign. same in life.
phf: i spent some
time going
through exercise of getting rid of main in gnupg 1.*, compiling it into a dynamic library, loading into a lisp and calling c functions
through ffi. it's doable, but yeah environment very hostile
to librarification: often
times reporting is done only as a printf, with no status codes, so impossible
to do simple (= (ffi-call...) 0) without unpacking
the c level function
assbot: Logged on 24-08-2015 15:42:03; asciilifeform:
thing
to realize is
that gpg was written
to be maximally un-librarifiable. like gcc.
mod6: and for
taking
the
time
to explain some of it
to me.
assbot: Logged on 24-08-2015 15:42:03; asciilifeform:
thing
to realize is
that gpg was written
to be maximally un-librarifiable. like gcc.
mod6: anyway,
thanks for putting all
this
together!
mod6: i guess i don't mean
to confuse.. was just
thinking about it in
the capacity where a stripped down box is being used.
mod6: i saw punkman say something about dropping in a python-gnupg side-by-side with V -- i've gotta
try
that yet. might be cool for an airgap box or something.
mod6: but yeah, i just `mkdir -p ~/.seals ~/.wot` and dropped
the sigs into ~/.seals and
the pub keys in ~/.wot and off it went.
mod6: sure. i was able
to figure
that out straight off np. helped by having a few bundled up in v99/wot/
mod6: the origin cmd is pretty neat
too
mod6: i know nothing of python... although from reading your code, i'm starting
to grasp it.
mod6: heheh, my fingers didn't want
to
type what my brain was
trying
to say. it's a little baked from
the sun
today at
the fair.
mod6: <+asciilifeform> descendants ! << mean
this, my apologies.
mod6: well,
the 2 i just mentioned come last. is
there any reason on
the sort order of
the last 2? or i just need
to grok
toposort more?
mod6: but
the rest do, so
they come last.
mod6: ok, i
think i get it. neither patches/asciilifeform_maxint_locks_corrected.vpatch or patches/asciilifeform_add_verifyall_option.vpatch have any dependants (d's)
mod6: i suspect
that I'll need
to look at
the
touched files and
the hashes
to make sense of
this.
mod6: yeah, i don't grasp
that part fully yet. but it does make sense from genesis up
through patches/bitcoin-asciilifeform.4-goodbye-win32.vpatch
mod6: *chronologically
too
mod6: i was mechanically cross checking
the output file checksums against
the v054-TEST2 bundle and noticed
that i didn't come out with -verifyall in
there. was really wondering for a minute lol.
mod6: but in
this case, it is. i get it. sorry.
mod6: which isn't
the case chronoligicaly
mod6: i see, when i check flow, i see
that 'verifyall' comes /after/ maxint
mod6: asciilifeform: qq, I was under
the impression
that when using press, if I picked something like 'maxint_corrected', it would patch all
the way up
through
that one. but it didn't seem
to apply
the -verifyall patch? or do I misunderstand how its supposed
to work?
http://dpaste.com/1J2BS40.txt thoughts?
mircea_popescu: there's a finite count of failing
to goal
that
these
things can survive.
mircea_popescu: "Alydian Inc., a unit of CoinLab Inc., on Friday filed for Chapter 11 protection in U.S. bankruptcy court in Seattle.
The 10-page court filing didn't disclose why Alydian filed for bankruptcy or how it hopes
to repay its debts."
mircea_popescu: you kidding me
they just
took even more millions at whatever dilution
mircea_popescu: how many alfs are
there ? how many do
they need,
to cover
their immense if fictitious debt base ?