127900+ entries in 0.619s
a111: Logged on 2018-01-06 12:54 asciilifeform:
http://btcbase.org/log/2018-01-06#1765918 << if mircea_popescu sees himself as
the 1 fella with a working head, and sole fountain of sanity, and errybody else is a peculiar sort of animated furniture -- i am quite powerless
to cure. ( occasionally i'll
try curing anyway, as it sometimes seems
to work , e.g. seems
to be finally cured of 'plain
text' after 3+ yrs of 'wie sind sie eigentlich... !' )
phf: asciilifeform: snarfed, but i
think i'm missing ch2 for benvulpes
phf: and
the log keeps on logging
shinohai: Heh I had one of
those Sharp calcs when I was a kid, loved
the
thing.
a111: Logged on 2015-04-28 20:06 ascii_field: not
the git
thing again
PeterL: nah, simmilar layout but about
twice as many buttons
PeterL:
http://btcbase.org/log/2018-01-05#1765051 << when I was little my dad had (might still have)
this nice calculator
that asciilifeform would like, it was a scientific calculator, used rpn, was about
the size of a mans palm, landscape, solid metale housing
☝︎ PeterL: yes, I had a couple
that included BASIC "games"
a111: Logged on 2018-01-02 16:10 mircea_popescu: similarily if you went with machine guns into campus of your choice,
the output will be pile of bodies, not red army.
PeterL: and how do I know if I
take random patch from you and stick it in my different patch
tree
that it will not break something? wouldn't I want
to have
the same world as you before adding your patch?
PeterL: and I don't see it as cut-and paste, you would just be changing
the one line in
the patch
to merge it into your own flow?
PeterL: isn't
that why we have a main-line version of software, so everybody is working on
the same
thing? does it make sense for everybody
to be wroking on something slightly difference and expect my changes
to fit your
thing?
PeterL: couldn't having a standard of "touch readme file each patch" be a form of "don't do
that"?
PeterL: you don't
think it is broken
that you were able
to commit
the "warcrime" so easily?
PeterL: so you want
to
touch comments in pertinent files after-the-fact, while I am suggesting
touching a comment in a central file (README?) each
time so
that doesn't have
to happen
PeterL: the problem I see with
the current system is
that you can make a change in one file which relies on a change in behavior of a function defined in a different file. You end up with
two "sister" patches, but
the second one is invalid without
the first.
PeterL: if
the is are sister patches A and B, and you want
to make C using both of
them you just regrind B
to B',
the only difference would be
the one patch version file, and
that difference would be readily vissible by diffing B and B',
then make C ontop of B', works with current v IIUC
a111: Logged on 2018-01-06 00:00 asciilifeform: i'ma summarize
the v
thing : if you have a proposed new v algo ; and it would
turn my 1kB patches into 1MB, and my readable 3 lines into 100kLoc of ?#@%$*(@%% , and my
trivial machine-diff-verifiable changes into 'why dontcha sit for 5 years doing eyeball-powered diff' -- it is NOT an improvement. and i won't
touch it. sign it. sign anything made on it. etc
PeterL:
http://btcbase.org/log/2018-01-06#1765616 << I dun see why patches have
to change much?
Thinking of
the system proposed by mircea_popescu you would have one line change in a "patch version" file,
the rest of
the patch would be identical
to what we have now
☝︎ a111: Logged on 2018-01-06 06:28 mircea_popescu: as
to
the peculiar way in which
http://btcbase.org/patches?patchset=eucrypt&search= renders
the various arrows : it makes
the implication
that eg ch4 parents are ch3 "as well as ch1" for
the coincidental reason
that ch1 is included in ch4s parents both "indirectly" via c3 and "directly" in
the lateral and unimportant sense
that ch4 changes both files which were changed by ch3 and files
that weren't changed since c1.
this DOES
a111: Logged on 2018-01-06 06:17 mircea_popescu: first off,
the ENTIRE edifice of sanity you partake in is built ENTIRELY on my writing cheques on other people's
time. you're welcome
to like or not like
this, but it is not open
to your review.
mircea_popescu: but in general,
this excursion in wank and nonsense could continue ad infinitum and i have reports
to write.
mircea_popescu: e contextless, nor because
they could not fucking be so
tooled.
mircea_popescu: so no, at no fucking point does any patch have anything other
than a single parent, which is properly speaking "the previous press", rather
than "a random collection of files scattered about". like it or not, files don't have
the sort of semantic power whereby a db.cpp "of
the right hash" will always be useful when imported into some random project. files are not contextless ; neither because
they aren't currently
tooled
to b
mircea_popescu: if instead of
this we look at
the other kind of "two parents", whereby ch3 supposedly has both ch2 and mpi_fix_copy as parents,
this is specifically
the situation discussed by
the problem A :
that
two patches, which ARE STILL IN A CHAIN, nevertheless happen
to
touch disjunct filesets, and so
the question of
their order is open (which phf renders "correctly" in
the sense of acceptably as he does ; but which is NOT meaningful i
mircea_popescu: NOT make ch4 have "two parents" in
the sense contemplated here. it only has one, because
the ch1 as included by ch3 is necessarily
the same as
the ch1 as included "directly".
mircea_popescu: as
to
the peculiar way in which
http://btcbase.org/patches?patchset=eucrypt&search= renders
the various arrows : it makes
the implication
that eg ch4 parents are ch3 "as well as ch1" for
the coincidental reason
that ch1 is included in ch4s parents both "indirectly" via c3 and "directly" in
the lateral and unimportant sense
that ch4 changes both files which were changed by ch3 and files
that weren't changed since c1.
this DOES
☟︎ mircea_popescu: either manage
to discuss in
the sense of, as part of
the discussion, or else go discuss in
the sense of,
talking
to yourself.
mircea_popescu: second off,
this approach where you
take some vague fragment of what was said, respin it into some bit of nonsense meaningful
to some random other interest in your own head and proceed as if
that's what's said is not a game anyone in my experience willingly entertained.
mircea_popescu: first off,
the ENTIRE edifice of sanity you partake in is built ENTIRELY on my writing cheques on other people's
time. you're welcome
to like or not like
this, but it is not open
to your review.
☟︎ mircea_popescu: every single fucking line you produced in
this attempt
to double down on
the "lalala i can't hear anything" idiocy is flaming, offensive bullshit.
mircea_popescu: there's a very strict limit on
the complexity of any discussion (which -- correlates
to its utility) imposed by
the propensity of bad actor
to inject nonsense in
the conversation.
a111: Logged on 2018-01-06 04:18 mircea_popescu:
this is
the discussion, proceed but proceed like sane fucking people, save me blood pressure.
a111: Logged on 2018-01-06 04:31 mircea_popescu: but yes,
there is no other kind of code besides monolith ; i've had enough "bazaar" for
three lifetimes of other people i don't particularly like ; and moreover code ambiguity is fucking nuts.
a111: Logged on 2017-12-24 16:11 asciilifeform: kurchatov, supposedly, sat and
thought, and few minutes later answered, 'perhaps from philosophical pov
this'd be consistent. but
then we will have
to forget about obtaining
the bomb.'
a111: Logged on 2016-12-23 19:53 asciilifeform: if i had any reason
to
think
that
turning v
tree into a forest of vertical stakes , exponentially crowded with IDENTICAL payloads
that cannot be machine-compared , would make it easier
to
tell friend from foe and wisdom from folly -- i would agree with mircea_popescu's algo. but i do not.
a111: Logged on 2018-01-06 04:29 mircea_popescu:
http://btcbase.org/log/2018-01-05#1765580 << eh get
the hell out of here, so you want someone
to
take
that patch and put it into some random other
tree which happens
to have a db.cpp
that matches its hash ?
this is insanity on
the level of early organ
transplantation experiments.
mircea_popescu: i'm gonna skip
the rest of
this nonsense, jesus f christ.
mircea_popescu: but yes,
there is no other kind of code besides monolith ; i've had enough "bazaar" for
three lifetimes of other people i don't particularly like ; and moreover code ambiguity is fucking nuts.
☟︎ a111: Logged on 2018-01-05 23:40 asciilifeform:
think, if EVERY patch requires global regrind of all of world history, you ain't using v, may as well
throw out all of
the unnecessary equipment -- you're passing a monolithic
turd around
a111: Logged on 2018-01-05 23:39 asciilifeform: if instead it demanded
that your
tree,
to apply it, be bitwise-identical
to asciilifeform's
tree when he made it -- you could only build on
this patch if you reground ALL of EVERYONE's work every single fucking
time
mircea_popescu:
http://btcbase.org/log/2018-01-05#1765580 << eh get
the hell out of here, so you want someone
to
take
that patch and put it into some random other
tree which happens
to have a db.cpp
that matches its hash ?
this is insanity on
the level of early organ
transplantation experiments.
☝︎☟︎ mircea_popescu: this is
the discussion, proceed but proceed like sane fucking people, save me blood pressure.
☟︎ mircea_popescu: through some discussion it emerged
that A.1 and A.2 are not practically distinct, one just provides
the memory for
the implementation fo
the other as a foremost feature.
mircea_popescu: problem A has
two possible legitimate answers : A.1 : introduce a further parentage chain (so patch does not discuss merely file hashes but also somehow a hash of prev patch) and A.2 : introduce a magic file which must (by protocol) be
touched by all patches.
mircea_popescu: problem S will not be considered ; problem X is resolved by answering yes. because god fucking help you, if your patch has
two antecedents you are a heretic anathema.
mircea_popescu: 1. problem S (alf's) is entirely spurious and not part of
this confersation, go
talk
to dreamweaver about it ; 2. problem A (trinque's) : "if
two patches with same antecedent
touch disjunct filesets, how does establish which came first" ; 3. problem X ( ben_vulpes 's) : "if i
totally sabotage v into a piece of shit entirely contrary
to its everything, will you hit me in
the head ?"
a111: Logged on 2018-01-05 23:24 ben_vulpes: or
to put it a different way,
that one *must* create an invalid state in order
to patch atop
two divergent patches.
a111: Logged on 2018-01-05 23:18
trinque:
the opacity of
this question is by now baffling
to me.