138200+ entries in 0.074s
mircea_popescu: item scheduled for eucrypt lib so keep watch of diana_coman 's blog. can be just
taken from
there put here.
mircea_popescu: if we start fucking with vdiff,
this is
the first mover.
mircea_popescu: i expect his method (add
the
terminating ---s
the
thing expects even if spurious) works even if implementation may need work.
tho i dun wanna go down
this road.
mircea_popescu: vdiff should be fixed
to search for
the full 4 char header also.
mircea_popescu: they utterly don't belong
there. you got a .sig mechanism for
this.
mircea_popescu: still, ironclad argument
that current grep is broken : looks for PART OF
the header it should.
trinque: but it appears
to say anything starting with --- must be diffheaderstuff
trinque: as if
that ball of hair is readable
trinque: vdiff just needs
to match diff chunk header lines better, and fixed.
mircea_popescu: idiotparser has
the extreme advantage of not even being a parser, ie, simplicity.
mircea_popescu: stylistic rules happen all
the
time. "name variables like
this".
mircea_popescu: and a rule whereby ada comments are "-- " not "--" is not
the end of
the world either.
phf: and
that doesn't in any way require breaking
the files?
mircea_popescu: asciilifeform you shouldn't put gpg clearsigned bits in a patch in
the first place.
phf: you want me
to write a second_cut by hand
that presses cleanly?
phf: you can hand produce a second_cut
that's not broken by
tooling
phf: in
this case "better parser" is a parser
that actually understands
the format it's processing
phf: _but it will require either writing a vdiff from scratch, or else adding a better parser
to vdiff_
phf: but it will require either writing a vdiff from scratch, or else adding a better parser
to vdiff
phf: well, diff produces enough information for you
to not have
to do
that.
phf: the problem is not diff or diff format,
the problem is
that vdiff does a naive grep for a prefix and breaks a perfectly valid
traditional patch
mircea_popescu: nah. keep
the current death word (---) ; replace all conflicts in raw input
to ===.
a111: Logged on 2016-12-11 20:15 asciilifeform: and haha,
there are
TWO +++ lines !
a111: Logged on 2017-01-05 00:43 asciilifeform: incidentally you will blow up on
the +++ mine if you
try and diff a vdiff.
phf: asciilifeform: you're misrepresenting
the problem
a111: Logged on 2017-12-06 22:07
trinque: ah so
the vdiff script wrapping diff probably did
that?
a111: Logged on 2017-12-06 22:05 phf: if you just run a diff -uNr on
the
two readmes,
the resultant patch works. if you run a diff on
the resulting patch and
the vpatch in
the
tar,
then you can see
that
there's something wrong with
the vpatch specifically
trinque: ah so
the vdiff script wrapping diff probably did
that?
☟︎ phf: ah, so what's actually broken in
this particular case, is
the original v implementation
phf: if you just run a diff -uNr on
the
two readmes,
the resultant patch works. if you run a diff on
the resulting patch and
the vpatch in
the
tar,
then you can see
that
there's something wrong with
the vpatch specifically
☟︎ phf: there's nothing wrong with
the diff, asciilifeform is
thrashing
mircea_popescu: i suppose
the
third alternative is
to actually implement a proper diff as part of vtron
BingoBoingo: trinque:
Their move
to clang as default compiler makes pain
trinque: who was? just
trying a patch with bsd stubble vs gnu moss-hair
BingoBoingo: Well, when discussing
trb on Openbsd we are
talking something
that spans 5.5-ish and ends no later
than 6.1
trinque: a read of
the manfile of linux patch suggests *massive* fuckery
to allow idjits
to pull patches out of other
text, email, newsgroups, etc
mircea_popescu: in
that
there's no reason
to have
them, and
their presence is in itself sign of babbage's braindamage, much like say a canister for light, or a faucet for patience.
mircea_popescu: alternately, of course... "no clearsigned material within patches".
this may even be a right
thing independently of
the actual bug.
BingoBoingo recalls diff being an issue, forgets
the context
mod6: <+asciilifeform> i recall a similar boojum in my 1st attempt at
the FG release,
that
time it was a '+++' inside a uuencoded blob << lol, ok i see
the problem
too. you're right,
this similar
thing happened before.
mod6: mircea_popescu:
that's kinda neat really
mircea_popescu: on a long enough
timeframe,
there's going
to exist a vtron in ~any language anyway, i expect.
mircea_popescu: i'm not going
to pick a wife for you, "here,
THIS is
the woman you should be comfortable with". pick your own. languages idem.
mod6: It /is/ a bit worrysome
that I believe
that I'm
the only person who knows how it works. And since it's
the only version in existence
that encompasses all of
the rules arbitrated in our chamber,
that a new version
that is easier
to understand is warranted.
mircea_popescu: original mod6 perl vtron was important prototype in
the early life of v, made all sorts of latter
things possible. exactly like original bitcoin. nobody said you have
to marry it now
though ; or divorce it for
that matter.
mircea_popescu: mod6 it's not a crime
to have a perl vtron. however, if you plan as your own strategy
to move away from perl and you're judging it more of a liability
than anything,
then by all means, eschew.
mod6: because what i don't want
to do is have a perl genesis,
then some vpatch
that deletes everything and inflates a bunch of ada stuffs. prolly be better
to start in
the lang you expect
to say within for
the lifetime of
the application.