131800+ entries in 0.079s

mircea_popescu: so for instance, "genesis a proper db ;
then patch in
three different branches for
the
three different
types of node envisaged" doesn't seem on
the face problematic.
trinque: anyhow lemme run at it again. you can't modularize because you have
to fake work in a disparate part of
the
tree
to merge
mircea_popescu: ie, i don't expect
the
trb cut as described
to have a
trb genesis necessariyl, or even probably.
mircea_popescu: there's nothing wrong either in principle or in practice with making a correct item as
the genesis and
then patching in various parts of
trb.
trinque: in
that
these are distinct items.
mircea_popescu: well, i am kind of a fan of
the whole "v doesn't permit you
to lie
to yourself about having supposedly designed what's utterly an ad-hoc item".
trinque: this is what I meant actually, by "can't modularize" within same walk of
the v
tree
mircea_popescu: now, is
this enforcement a problem with v, is
the proposition ? or is
the aforegoing a misrepresentation of
the discussion ?
mircea_popescu: v doesn't permit
this backwards in
time ; and if you run in
this situation where johnny needs an experts' sex change
to become evvie, it's high fucking
time you hand-rewrote your whole steaming pile of crap.
mircea_popescu: let me put it
this way, maybe resolves problem : v unpermits a specific kind of hack within
the purview of
this discussion, wherein one
tries
to design after
the fact. correctly designed items will have
the larger bits (by footprint) earlier in
the patch
tree ; and fray out correctly. github-style nonsensica commonly attempts
to discover
that "hey,
this johnny come lately item should have been an evie-comes-early MODULE, let'
☟︎ trinque: I'm actually writing right now on how
the hypertext
thing relates
trinque: cannot without
the 'add comment
to files you needed' ritual
trinque: means for example
that db-interaction routines are in one file, network interactions in another.
mircea_popescu: "hey, aren't you worried your shitcoin will get altcoin'd in
the near future ?" "no, i am dog and i don't understand anything. vote me!"
mircea_popescu: lmao fucktard. a)
the "pirate party" scam utterly fucking failed, how about addressing
THAT ; b) kinda hard
to have anyone ditch an empty ship, huh.
trinque will put some pen
to paper
this evening
a111: Logged on 2017-12-19 18:04 asciilifeform: we actually had
the ast-diff
thread, re phf's lisp diff lament.
trinque: asciilifeform: is possible, but deserves
to be in
the logs
trinque: to my mind
the hash is currently putting
too narrow a constraint on
the context within which
the current patch is
to be applied, where we could broaden
the context at no detrimental, and possibly beneficial cost
a111: Logged on 2017-12-26 21:22
trinque:
http://btcbase.org/log/2017-12-26#1758679 <<
to my mind
this suggests
the hashes present in vpatch blocks are wrong. if
they were rather
the hash of
the entire concatenation of
the diffed item before and after applying
that block,
there'd be no need
to pointlessly edit files
to continue on
the same branch.
trinque: only way
to make a 3rd improvement rely on
two distinct improvements in past is
to put cruft in both.
☟︎ trinque: should someone pressing
think he has a coherent whole after pressing any patch? if not why?
trinque: what is
the meaning of
the hashes in a vpatch?
a111: Logged on 2017-12-21 17:38 mircea_popescu: anyway, continuing
the
trinque discussion, it seems entirely unavoidable
that
trb will become 3
things : a wallet node, optimized for pumping out local signed
tx ; a block node, optimized for keeping
the blockchain, getting blocks, no mempool nonsense ; and a spy node, optimized
to keeping
track of
the lies and nonsense flowing
through
the relay network (mempool,
timing nodes, what have you).
trinque: so
then, when
things get so modular
that you have frayed rope, author makes clean separation, as V has
told him he has distinct items.
trinque: in either case, what does asciilifeform
think of
the ritual of "add comment
to unrelated file
to merge paths", not symptomatic of a problem?
trinque: it again runs into
the unix idiocy of "file",
though, because file does sometimes mean module, sometimes means subcomponent of module.
BingoBoingo: Eh, give it 10 years and everything Republican will be inconel while
the last USG
trinkets come in Chinese potmetal
mircea_popescu: damned
thing was
the size of a god damned depth charge
BingoBoingo: Will probably start upping
the blog frequency
to let some more vemon out
BingoBoingo: Anyways
thinking on
the noob roughing up earlier, could be a side effect of
tranquility overdose. Gotta
torture betas.
BingoBoingo: Hence
the spankings and vacuum cleaner
tube
a111: Logged on 2017-12-26 22:22 danielpbarron: wasn't indiancandy/sofiababy looking for a way
to make bitcoin?
BingoBoingo: <mircea_popescu>
http://btcbase.org/log/2017-12-26#1758819 << she kinda got sent off for NOT being looking dedicatedly enough ;
then she got pissy because i imagine in her dumb head she had self-delusions as
to self-importance as dear as
they were baseless. << Ah, gets BTC once returns years later and has less sense and more ideas
☝︎ mircea_popescu: if you register a key you can self-voice don't have
to keep doing
this voicing
thing
mircea_popescu: anyway, maybe
the correct approach re
the l0de
thing would be something like a simulcast interview. you do interviews l0de ?
a111: Logged on 2017-12-27 00:23 asciilifeform:
http://btcbase.org/log/2017-12-26#1758779 << i see e.g.
trb
tree, as
the frayed end of a rope. in long
term, observe,
the loose ends
that dun get built on -- fade away, like orphan chains. btc is actually more or less same kind of system. but iirc we had
this
thread.
a111: Logged on 2017-12-27 00:06 asciilifeform: let's say every homo redditus alive -- suddenly interested.
then WHAT? what's gained, other
than a great mass of meat
that now gotta be put somewhere far from
the reactor rods
a111: Logged on 2017-12-26 20:29 mircea_popescu just dumped a whole sack of coal on
teh grill,
teh girls happily cleanning up a grosse of pleurotus... if anyone needs me ima be at
teh rancho bbqing.
a111: Logged on 2017-12-26 21:22
trinque:
http://btcbase.org/log/2017-12-26#1758679 <<
to my mind
this suggests
the hashes present in vpatch blocks are wrong. if
they were rather
the hash of
the entire concatenation of
the diffed item before and after applying
that block,
there'd be no need
to pointlessly edit files
to continue on
the same branch.
a111: Logged on 2017-12-26 21:42 phf: we also at some point had a
thread, where i believe ascii but also others were leaning
towards
the idea of a single file vpatches (i.e.
that a vpatch should only ever contain hunks for a single file). i'm starting
to
think
that multi-file solutions in general are a hack ("we can't fit
the entire compilation in memory"), but
then i've been looking at
TeX on one hand, and
the "millions of support files" in diff/patch on
the other
a111: Logged on 2017-12-26 21:36 ben_vulpes:
this still leaves me in
the pickle of producing a vpatch from a press
to a
that won't actually descend linearly from a without
touching a file, and adding "this line necessary
to ensure
this vpatch descends from a and not genesis"
a111: Logged on 2017-12-26 21:42 ben_vulpes: phf:
this exposes another problem: in ideal vtronics it is an illegal operation
to press
to multiple leaves at
the same
tree level, which is
the only way
to have a codebase against which
to create a makefiles-type patch
that
ties multiple patches
together