339700+ entries in 0.224s
ascii_butugychag: jurov: sure but now every vtron would need
to be rewritten
to actually break down filenames
polarbeard: I mean a
timestamp in
the filename author_patch_thing_$(date +%s).vpatch
jurov: anyway, matching
the signature against all versions of one patch isn't so big
thing
to swallow
polarbeard: you're
talking about
the file metadata?
ascii_butugychag: and i have no intention of asking people
to use a patched pgptron simply so
they can use v
ascii_butugychag: existing pgptrons do not, afaik, allow you
to specify a custom
timestamp
☟︎ polarbeard: for
the rate
that patches get built I
think it will be fine
polarbeard: it happens
to be
the unix
time because is pseudo-universal
ascii_butugychag: polarbeard: because sigs submitted arbitrarily later
than
the patch !!!
polarbeard: ascii_butugychag: why can't sigs have
the same
timestamp?
jurov: punkman i said
that,
there were screams it's not vtronic
punkman: submitting patches with
the same name kinda confuses
things, maybe we could not do it instead?
ascii_butugychag: also all existing vtrons, afaik, match sigs
to patches by using
the filename.
ascii_butugychag: jurov: how will you deal with sigs produced after
the patch submission date ?
jurov: since name+date was decided, will use
that
ascii_butugychag: the
trees, as i understand, ought
to be ~the same~ after each scenario
jurov: sha1 because i wanted
to
track files by contents and sha1 was at hand
ascii_butugychag: i wanted
to see a diff of my
tree (pvs, and my pvs fix, and shiva, and
the shiva fix) vs yours (where
the patches and
their bugfixes were agglomerated)
mod6: the left hand side is just
the ~original~ patches + shiva
mod6: its only on
the right hand side.
mod6: <+ascii_butugychag>
the
two
trees, diffed. << i believe
this is what I have and what you're looking for, is it not?
polarbeard: jurov: sha would be large and annoying, date +%s would be enough I
think
jurov: not really, sigs were supposed
to carry SHA1 of
the patch
they apply
to
mod6: i did vdiff of
the pressed out stuff.
mod6: scroll
to
the bottom.
ascii_butugychag: i wanted a diff of a)
the result of applying my original patches b)
the result of applying yours
mod6: please explain again so i can get
this completed.
mod6: ascii_butugychag: is
this kinda what you were asking for yesterday? A vdiff of a pressed original patches (minus PVS fix) + shiva with pressed mod6's integrated patch + malleus regrind + shiva ?
jurov: (latter bring
the original idea)
jurov: so won't you
take exception with branches in lxr named vpatchname_YYYMMMDD or vpatchname_SHA1 ?
polarbeard: but actually you need
to store all versions in some common place
to do further checking,
they should come with different filenames...
ascii_butugychag: so long as every patch ever submitted can be pressed
to,
the
thing works correctly.
ascii_butugychag: jurov: for humans, but
the idea here is
that it ought
to be able
to swallow new patches
polarbeard: otherwise just check
the sig date using pgp, last patch wins
☟︎ jurov: iirc whole lxr
thing is for humans
polarbeard: well names are for humans, I
think humans is what jurov is concerned with
jurov: since renaming is out of
the question
jurov: lxr may be vtronic *if and when* someone
takes my questions serious. so, asking again, what
to do with reground or otherwise resubmitted patches?
☟︎ polarbeard: yep, but I didn't know such
thing existed
polarbeard: I'll definitely have
to checkout gcov itself first
ascii_butugychag: how
to determine, without major surgery, what a wedged node is doing
assbot: Logged on 03-02-2016 17:03:09; ascii_butugychag: do you have
the log scrolling 24/7 ?
assbot: Logged on 03-02-2016 14:12:43; PeterL: looks like
there is no bet for cruz
to get nomination?
PeterL: ascii_butugychag>
http://log.bitcoin-assets.com/?date=03-02-2016#1395141 << when americans stuff ballot box,
they like
to set it up as 'dark horse candidate' << I wouldn't call Cruz a dark horse,
there are just so many candidates he must have been overlooked, we didn't get bets for huckabee, santorum, fiorina, christie, etc, either
☝︎ phf: can probably add something like lxr, but i need a better idea of how
they do c++ parsing/indexing
thestringpuller: where node stops responding, last
time
though it brought
the whole machine down
tho.
ascii_butugychag: incidentally, i found
that a blackholed node won't respond
to rpc
ascii_butugychag: but
thing is, i specifically am interested in what
the
thing is doing when it is ~unable
to produce log~
ascii_butugychag: mircea_popescu: sorta why i'd rather plot externally
than grep
mircea_popescu: also,
the
timing as presented by
the node is not
terribly reliable.
thestringpuller: Reminds me of when gf is like "eat
these vegetables
they won't kill you"
thestringpuller: ascii_butugychag says "LISP is you friend" so I'll give it a
try.
ascii_butugychag: thestringpuller: it doesn't
tell you worth shit re: a stuck node.
ascii_butugychag: and
then you people wonder why your
tx is stuck on mars without a return
ticket
thestringpuller: i
thought
tail -f debug.log was
the only way
to see what was actually going on
thestringpuller: the power rangers seem
to be able
to line up gullible investors better
than zuckerberg and
that napster guy...justin
timberlake was it?
ascii_butugychag: is so
that we can get
to a place where
there is NEVER a situation of 'i wonder wtf
the node is doing'
ascii_butugychag: nor does idem, running on SAME BOX as zoolag in parallel with it and -connected
to it and
the other
trbs.
mircea_popescu: obviously. why not be useless
to
the bitter end. power rangering ftw!
ascii_butugychag: what i do know is
that -connect nodes within my walls do not ever blackhole.
ascii_butugychag: blackhole results when
the worker
thread (the one
that handles nearly everything) is wedged
☟︎ mircea_popescu: i dunno what it is, i've never seen it before
trb myself, nor a really good one since.