87100+ entries in 0.054s
mircea_popescu: hm,
this "write line as long as you wish, program will split" fix
turns out
to not play so well with logreader...
mircea_popescu: just because it happens
that in all other cases of "you're in charge of so-and-so-chapter of defense budget/film budget/family budget" one gets a fixed number
to work with, whereas here
the number's not aforeknown... makes entirely no difference. it's still budgetary exercise,
that superficial difference is meaningless given
the substantial identity.
a111: Logged on 2018-07-07 18:19 mircea_popescu: esthlos welcome
to
the mechanisms of lordship. it's your project, it's your job
to make
this sort of decisions. "should
this be rewritten in lisp, imported in ada, be
turned into a point of grafting on eucrypt
tree ?"
mircea_popescu: specifically, writing software is not some kind of hired work, like polishing boots or cutting hair. writing software is a dignity, in
the exact sense
there contemplated : republic gives you, ivan ivanovich, a budget of so many lines, as if it were so many bitcoins,
to ~EXPEND~ in a defensible, meaningful, useful an' rational fashion ( hence
http://btcbase.org/log/2018-07-07#1832667 discussion ).
☝︎ a111: Logged on 2017-12-05 14:17 asciilifeform: as for asciilifeform , he would actually prefer if mircea_popescu shot straight and said 'hell no i won't pay for no stinkin' software', rather
than
the peculiar ritual of having a contest,
then
to proclaim
the submitters as a whole 'self-indulgent indolent' and
then in
the end
to
take s.nsa crypto lib and use for phree anyway
a111: Logged on 2018-06-21 15:33 asciilifeform: Mocky:
to function as a
troo vtronicist, gotta grasp
the concept, described by e.g. dijkstra,
that a line of code you have written is not an asset, but an expense. (specifically, an expense against
the
time budget of other
thinking people, who must read and grasp what you have written. )
mircea_popescu: though if you're willing
to spend money on silver
tootpick why not just fix
the holes.
mircea_popescu: silver ones were kinda common during one of
the silver crazes
mircea_popescu: broke
them all
trying
to stab various butts & parts over
time.
mircea_popescu: and it shames me
to admit just exactly how i came
to not have any.
mircea_popescu: i'm having for breakfast leftover sandwiches
that were originally made for camping on
the beach, so i figure... what
the hell... and made myself a little model campfire out of
toothpicks in
the middle of
the
table.
RusAlex: hi,
thanks for voicing. just found a link on bitcoin.foundation and Im here.
mircea_popescu: in other similar news, star quest
tcg is a pretty fucking great game. polished and shit, apparently you can still have web development
that's not crap
a111: Logged on 2018-01-05 23:18
trinque: you edit db.cpp. I edit main.cpp. how does someone now use both of
those pieces of work in a 3rd patch.
mircea_popescu: fwiw, memory never was anything other
than "personally advantageous".
them wetram cells gotta pay
the glucose bills.
phf: personally-advantageous-obfuscation by reference-by-memory, we're reinventing
the empire here
mircea_popescu: then
ten years later memory's faded and nobody alive can untangle
the yarn anymore.
mircea_popescu: and
the smalle
third brother is reference-by-memory, where i say dumb shit like "that @@ discussion" instead of putting in a link.
phf: i figured
that's not
the case, i'm just reiterating
the logs for
the logs, because
the evil
twin of not reading
the logs is apparently forgetting what was read in
the logs
phf: btcbase (being a sprawling common lisp beast) has one of
the possible solutions actually implemented and working. i'm wrestling
the essence of it out, enough
to add some kind of graph sorter
to vtools
phf: originally my replacement was for diffing and patching exclusively, not
the graph resolution problems. i was
tasked with a replacement around
the
time when my food work got heavy, and i'm only now revisiting it.
the problem wasn't even verbalized until closer
the
the end of vtools development, because particular choice of vtools delivery demonstrated
the problem
to begin with
mircea_popescu: however much
time you might need
to
think,
there isn't very much
time altogether, because we can't sit around with an unresolved dilemma of both "this is
the grapher use it" and "don't use it, doesn't work".
phf: i haven't
thought about it very much?
phf: well, i'm having hard
time
thinking about it, yet alone articulating it. like i
told ascii (before we continued
talking about it anyway), i need some
time
to reupload
the problem, because i haven't
thought about it in a while.
phf: mircea_popescu:
the problem i describe exists in every single V implementation, hence none of
them can press a particular graph
mircea_popescu: so if it's built around patches and
the patches are different what difference does it make
that
two different patches might apply
the same
tranforms
to
the same files ?
mircea_popescu: the only reason i can imagine someone'd have
the problem you describe is if
they built
their
thing around
the primitive "file" rather
than around
the primitive "patch"
phf: actually, i
think i have a memory of
that, and no btcbase is entirely hash first
mircea_popescu: let me ask you
this : is your visualizer essentially a by-file processor ? because
this'd be wrong,
the concept of "file" is meaningless, entirely just like "new line".
text administration flows by viewport and so on.
mircea_popescu: i don't understand
this, you mean patch A having changes a, b, d, e (ie, 4 different patch sections) and B having c, d, e, f ?
phf: mircea_popescu: i didn't say more
than one vpatch are identical, i said
that
they shouldn't contain identical changes. a single vpatch can contain changes for several files. if
two vpatches have a same subset of changes
to individual files you have a problem.
mircea_popescu: how are you distinguishing
those more
than one patches of
the same content by
the same name ?
mircea_popescu: moreover, how can "more
than one" vpatch be ~identical~ ? items of
the same name and contents are
the only items
that have
the same hash, which is
the only basis for identity.
a111: Logged on 2018-07-10 14:43 phf: so policy wise, like you say "no cyclical graphs" you can say "no identical changes in more
than one v patch"
phf: (btcbase doesn't choke on circular graphs,
though in a general case it bails. if
the circle is in
the descendants order is determined by walk's order of entry, a circle back
to genesis
though can still be broken by explicitly designated something as "genesis", etc.)
phf: well, i kind of dig
the emergent v graph behaviors, so i don't mind it either way,
though btcbase doesn't press cleanly either (^ "all extant V's"). nothing keeping one from
tacking on additional state
to a crystalized vpatch either, and
then you're stuck with another "though shall not, because reasons"
phf: yeah, obviously
total state eliminates all
the "multiple state
transitions in a single vpatch" related problems
phf: manifest doesn't solve
this problem, because manifest doesn't get any kind of priority
treatment. if you hinged your press purely on a manifest descendent/antecedent chain
then everything else will just work™
phf: so policy wise, like you say "no cyclical graphs" you can say "no identical changes in more
than one v patch"
☟︎ phf: if you want
to reduce
the problem
to a "don't do
this" policy,
then it stems from repeated hunks across multiple vpatches, i.e. if you have
two or more vpatches
that have identical state
transitions. something like
that is bound
to happen when you're attempting
to port a feature between branches, as is
the case with vtools. (i.e. you patched foo.c in one file "remove broken behavior", you now want
to also introduce same fix
to
the other branch)
phf: in order
to produce a graph
there's a walk
to root phase,
the walk keeps
track of press state at each node and dismisses connections edges
that result in an invalid state. now WHY
this is needed is because each individual vpatch doesn't keep
track of
the entire state, but only about its particular subset of state
that changed.
phf: ah see
the graph is misleading, because btcbase base grapher culls it. we've ran into similar issue back in
the heavy experimental
trb days, so one of
the very first
things
that
the btcbase distinguished itself on is producing a graph of possible presses, rather
than pure antecedent/descendent.
this was discussed and documented in
the logs, in before "why you do
that!1"
phf: there is a manifest in
this version of vtools
phf: asciilifeform: well, i'm not sure what "spuriously bifurcated
tree" means in
this case,
the goal was stated in
the one of
the posts,
that i'm explicitly maintain
two separate branches,
that hinge on
two separate manifest paths.
this is
the kind of stuff v is designed for neh? press
to vdiff_sha_static
to get one
thing, press
to vtools_vpatch_newline
to get
the other
phf: asciilifeform: i need
to upload it into my brain first, let me get back
to you on
that one
phf: asciilifeform: nope, another form
that as of now doesn't have a name
phf: let me retest it, but as far as i recall it was producing a patch order
that doesn't press
phf: like i said couple of days ago i'm going
to forward merge
that whole right side, right now
the only advise is
to delete
the right hand side because none of
the extant V's can resolve
that graph, obviously a suboptimal suggestion. i'm working on a better grapher, but until
then..
☟︎ mod6: i just realized
that i want pancakes
diana_coman: aha, I just entirely forgot
that discussion until spyked mentioned it
mod6: oh nb. deleted one side of
the
tree, now it's ok eh?
diana_coman: not bad, at least some
things are working! heh
mod6: how goes
today diana_coman?
diana_coman: I even remember
the issue being discussed now
that you mention it
diana_coman: right you are, it does work!
thank you spyked, you saved me a
ton of
time really
spyked: that oughta work. I can't find
the discussion where phf recommended
this approach of keeping just one side of
the
tree in
the patchset.
diana_coman: or what, I need
to delete
the patches from
the other side? hmmm, let me
try
that
a111: Logged on 2018-05-21 11:48 spyked: it might also in a way be interesting
to report how I stumbled upon
this: I
tried
to recompile gnupg-1.4.10 on my broken debian system and got
the same "multiple definition" linking errors as in vtools' case (though I *did* use gcc<5). so I dug and found
the usual kochs "fixing"
things
to compile gnupg on newer gccs.