128200+ entries in 0.071s
trinque: sure it is; I proposed before
that
the antecedent hash ought
to be
the hash of
the concatenation
trinque: db.cpp is nothing by itself, other
than "ono
this file was
too big"
trinque: you do not see how it's fundamentally retarded
to consider db.cpp a distinct
thing, rather
than
the scroll "trb" as
the *thing*
trinque: patch A1 and A2 are peers, happened
to different files with same starting codebase state. you proposed writing a B
that encompases whatever changes plus
the bodies of A1 and A2.
trinque: how does
this not expand
to still more antecedents dragged into child patch as
time goes on?
ben_vulpes: or
to put it a different way,
that one *must* create an invalid state in order
to patch atop
two divergent patches.
☟︎ ben_vulpes: what irks me about
this is
that one can make a patch
that depends on a state of
the codebase
that is not a valid press.
trinque: you edit db.cpp. I edit main.cpp. how does someone now use both of
those pieces of work in a 3rd patch.
☟︎ trinque: the opacity of
this question is by now baffling
to me.
☟︎ trinque: question
there wasn't just moves. it was how
to ever have
two patches with same parent,
that edited different files, end up same item.
a111: Logged on 2017-12-27 04:52 mircea_popescu:
trinque because it'll get a mess ; ben_vulpes it's just a counter. increments 1 from prev line. shall i do a sample pastebin ?
a111: Logged on 2017-12-27 04:52
trinque: why not have one file, manifest, and you edit it,
then vdiff
the whole shebang.
ben_vulpes: very specific with
the accusation history
too, in
the office is where she accused him!
shinohai: It's Alabama journalism, so don't expect
too much ....
ben_vulpes: i know
that it shouldn't, but i do like
to actually
test
things
ben_vulpes: oh man i didn't even
test against hex values
ben_vulpes: (ch 4 puzzle accessible
to noob as well, but still
took me much grinding of headgears)
ben_vulpes: nah, dun expect such of me; i draft plans for field construction of catapaults i don't invent
them
ben_vulpes: oh sorry sorry, i meant a solution
to
the ch4 puzzle
ben_vulpes: i haven't bitten off
the patch yet, and might not get
to it by
the
time you release ch6,
this all
takes me a lot longer
than phf or lobbes
ben_vulpes: well, gonna reread vpatch for ch04 and
then submit with my seal but sure, gimme a sec
a111: Logged on 2018-01-03 17:17 asciilifeform:
http://btcbase.org/log/2018-01-03#1763202 << i've been
thinking of abolishing
the artifact where a 0 stays on
the stack after
the 'else' branch. it'd require only 1 extra state variable ( a WBool )
a111: Logged on 2018-01-03 17:07 phf: using
the boolean we execute an if/else branch which either swaps
the
two numbers and drops
the
top most '_, or drops
the
top most without swapping _.
the final drop _ is an artifact of conditional implementation
that always leaves a value on
the stack.
ben_vulpes: i am having just a
terrible
time with
the else-clause pushing a zero
to
the stack
ben_vulpes: a modern IRC client
that keeps you connected, with none of
the baggage
ben_vulpes: i
thought
that's what irccloud advertised
ben_vulpes: dude
The20YearIRCloud
the fuck even is
the point of a bouncer
that's constantly disconnecting
a111: Logged on 2018-01-03 17:17 asciilifeform:
http://btcbase.org/log/2018-01-03#1763202 << i've been
thinking of abolishing
the artifact where a 0 stays on
the stack after
the 'else' branch. it'd require only 1 extra state variable ( a WBool )
mod6: then ill dig into
the
tmpdir
thing. i want
to ensure
that
the bug fix i've made is correct before I proceed.
a111: Logged on 2018-01-05 15:40 mod6: I went
through each one, looks
to be doing
the sane
thing. I'm probably going
to write it up in a little post
that can be looked at, as opposed
to
trying
to explain all of
that in 3 lines of irc.
mod6: Ok, will look into a better way
to handle
this. I appreciate your passionate want
to make
this better.
ben_vulpes: the important
thing is
that it not be
the same
tempdir every
time so
that interrupted executions don't block
the next execution
ben_vulpes: it is fine
to leave
the
tempdir in place so long as it is uniquely named
mod6: in
the case of failure, i could
try
to remove
the
tmpdir during
the 'Death()' call or something. But with interrupted execution,
there's no way
to know when
the interrupt is coming. Nothing
to do about it here.
mod6: So here's what I'll do: I'll revisit
this, and
try
to come up with a unique
tempdir.
This
tempdir is
to be used exactly once. Created at run
time. Removed at
the end of run
time. If execution fails or is interrupted, nothing will be done. It'll be left hanging
there until
the user removes it manually.
mod6: And I've
taken a bit of a different direction, perhaps because of 'File::Tempdir' or some nonsense.
mod6: It seems
that asciilifeform has been saying
the same
thing all along.