73100+ entries in 0.046s
a111: Logged on 2018-09-27 15:36 phf: asciilifeform: but if you want a full "v replacement and i don't want
to
think about none of
that"
then just use esthlos's item. i believe he has a working keccak already
BingoBoingo: For
the longs: Peso Argentino went from 0.85/1.45
to 0.55/1.25 in one month.
a111: Logged on 2018-09-27 21:02 mircea_popescu:
http://btcbase.org/log/2018-09-27#1855089 << i have no fucking idea how. i read
the logs daily atm, mostly impelled by... outright fear.
the best heuristic i know of, but otherwise
this promises
to be a first caliber bane as
time goes by.
a111: Logged on 2018-09-27 20:58 mircea_popescu: more's
the point : HOW do we establush "100is much, 10k is enough, etc"
a111: Logged on 2018-09-27 20:21 asciilifeform:
http://btcbase.org/log/2018-09-27#1855078 <<
trickier item. recall 'the song of
the sirens, some have escaped, but
their silence -- no one' . how
to deal with 'but ~was~ it in
the l0gz'.
mircea_popescu: more's
the point : HOW do we establush "100is much, 10k is enough, etc"
☟︎ mircea_popescu: asciilifeform no, i understand
the principle, just... nothing, not even mozilla went
through 10k versions
to date.
diana_coman: it's
the move
to generic + relaxation of some constraints (because of generic and because of using Calendar for local
time
to log)
diana_coman: but otherwise
the udp_tester.vpatch makes some changes
to udp lib
that are really just for
testing (i.e. I
think
they should not be part of production use of udp lib)
diana_coman: the rest
then are for
the
tester only - let me know if you give it a spin and how it behaves
diana_coman: asciilifeform, ^
there is also a small .vpatch for
that issue with null chars at ip
a111: Logged on 2018-09-27 19:52 mircea_popescu: in any case shit in
the logs ain't gonna
to "just go away",
this isn't linuslands. ignoring it is like ignoring hot coals.
a111: Logged on 2018-09-27 19:17 BingoBoingo: asciilifeform: I have returned from
the envirorast office, about
to fire off a message
to DHL informing
them
to
try again as I am a provisionally acredited importer of packaged goods for commercial use
a111: Logged on 2018-09-27 19:52 mircea_popescu:
http://btcbase.org/log/2018-09-27#1854952 << what you apparently did was completely ignore
the matter for five months,
then discover like children
that you actually need
tools at
the
time you started on
the
task (late at night etc) and so forth.
a111: Logged on 2018-09-18 18:22 asciilifeform:
this is
the other
thing, 'changes are expensive' promote imho a sane view of software, where you actually
try
to perma-stabilize yer proggy, rather
than
to keep up
the classic 'open sores' eternal cauldron of bubbling liquishit
a111: Logged on 2018-09-27 20:00 mircea_popescu:
http://btcbase.org/log/2018-09-27#1854988 << we came up with
this clever
thing sometime in 2015 or so iirc. not sure what is gained by doing 99995 --> 99994 etc in light of experience, but i clearly recall how cool it looked at
the
time.
a111: Logged on 2018-09-27 15:12 asciilifeform: ( fughot
that
they decrement ! )
mircea_popescu: in any case shit in
the logs ain't gonna
to "just go away",
this isn't linuslands. ignoring it is like ignoring hot coals.
☟︎ mircea_popescu: keep your
tools in state of good repair, you won't have
to start fixing fence by fixing hammer and nails.
a111: Logged on 2018-09-27 13:35 asciilifeform: call me an idjit, but i
thought
there were a new vtron...
BingoBoingo: asciilifeform: I have returned from
the envirorast office, about
to fire off a message
to DHL informing
them
to
try again as I am a provisionally acredited importer of packaged goods for commercial use
☟︎☟︎ phf: right vpatch applies 'diff -ruN' style patches exactly. it also keeps
track of both
the hash of
the patched file and
the hash of
the result state as it's reading/patching (there's no double read happening), and errors out if either fails
to match
the hashes in
the header
trinque: tonail-eater
tier mental rigor.
trinque: the "hunk succeeded at offset $hurrr"
thing is abominable
trinque: phf: in principle I'm entirely in favor of
the "unix philosophy" approach of simple, single-purpose
tools
mod6: yeah,
this is
the right approach imho. it's what i'd do with my ada-vtron, if it ever does breathe.
phf: re esthlos's work i
think it's a shame
that he chose
to reimplement own keccak, but is still calling out
to gnu patch. he could just focus on graph resolution/signature/wot checking, and offload
the validation on vpatch: construct
the press list, feed
the patches in-order
to vpatch, if vpatch succeeds
then you know _for certain_
that
the sequence of patches is valid, hashes and all
phf: trinque: vtools has not been design or intended
to compete with any particular v implementation. it's a set of
tools
that you can use in a v workflow (hence
the name). at least initially it was
two matching
tools vdiff and vpatch
that know how
to produce and consume a canonical vpatch.
the conflation came up, because i also published vtools in a form
that broke existing canonical v, v.pl, and was
tasked with fixing
the situation.
☟︎ phf: trinque: it hasn't been, and i'm doing omission by not mentioning
that vtools had a later mandate for graph resolution. meanwhile esthlos v was supposed
to supposed
to fix
the issue, i suspect
that different v's will eventually catch up.
trinque: however it'll need a vdiff
too, so was going
to pull in also phf's work
trinque: afaik it's
the most didactic of
the items
trinque: v-esthos if it's finished, and works,
though I'm willing
to hear counterarguments
trinque: trinquebrain clearly not handling
the swaps between v.pl and v.py in
thread just yet
trinque: phf: did
the problem which caused folks
to have
to delete one branch of your vpatch
tree
to press
the other get fixed in v.pl?
a111: Logged on 2018-09-27 15:33 phf: asciilifeform:
this has been extensively discussed in
the logs.
there was never a need for "new style v". v works just fine. one of
the design goals of vtools was
to nail down (and improve upon)
the patch format. vtools are explicitly designed
to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses
them ensuring
that
the format is valid and
that
the hashes stand.
there's no
phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect
the resulting press
to be fully valid, hashes and all
☟︎ phf: re standalone keccak hasher: i'm not sure
that it's needed, i
think
the relevant phase can just be dispensed with altogether. `vpatch' verifies
the hashes as it goes along
phf: asciilifeform: well, you're one of
the v maintainers, i'd
think you would want
to do it
to your own
tool.
phf: i guess it's presumptuous on my part
to
think
that it's exactly obvious how
to
take vtools and plug it directly into an existing v's, but
that's all
that's needed
☟︎ phf: i
think v.pl is a venerable
tool, it's battle
tested, it has established interface, it's been worked on for
three years now. i don't see any reason
to
throw it out.
☟︎ mod6: Anyway, lack of
time is a problem here
too.
mod6: The string handling, discussed previously in
the logs, is basically a solved problem - would just need something similar
to what alf or others have done before - character by character.
mod6: I had started on a ada vtron last year, but I got hung up with some of
the string handling, and
the fact
that I had
to use shell-outs for pgp. I'd like
to get back
to it at some point. I would love
to dispense with
the shell outs - and can probably do so, but not until 'peh' is finished.
phf: when i started working on vtools
there was already a handful of battle
tested V implementations,
that relied on vdiff.sh/gnu patch combination. vtools is a "drop in" replacement for
the later. you get valid vpatch on
the input, valid press on
the output.
the purpose is
to nail down
the format, and gradually replace out its parts (e.g.
transparent sha->keccak
transition)
phf: asciilifeform: you already have
the shaft, it's v.py