89300+ entries in 0.05s
trinque: phf: harping on it because I don't see evidence
that reason for
the manifest has been internalized
a111: Logged on 2018-06-15 17:26 phf:
http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using manifest
though: normally it requires a regrind where manifest is built up as you go, so
the press order is enforced
through graph. right now your manifest gives a press order,
that's not enforced by anything
phf: trinque: ftr we have
the "introduce manifest now without regrind, use it moving forward" pattern already implemented once
mod6: Perhaps we need
to 1: Formally adopt
the manifest spec proposed by
trinque, 2: build a V
that supports it.
ben_vulpes: s/after makefiles/in
the makefiles patch/
mod6: I read
this all a while back when posted, liked it, will
think on it some more -- but off hand, can't
think of anything we might be missing.
mod6: we'll cross
that bridge when we come
to it. but first and foremost,
the manifest items seems alright
to me; "$blockCount $patchTitle $patchAuthor $comment".
mod6: then perhaps all
the
things
that are still not folded in can be in a second release, or just folded in without release.
mod6: I can delcare
the v054 release with a manifest of my own ala:
To declare a "release", an author's GNS pointer for a project would point
to his selected manifest.
mod6: opting
to regrind
the entire
tree, and whatever other vpatches
that need
to be folded in
that currently are not.
trinque: wherever you introduce
the manifest, if it is not
the root, in order
to involve it in
the flow of
the
tree,
that patch must also edit some other file.
mod6: i see ben's point, but i'd rather
trb one whole
thing, instead of a 'before manifest' and 'after manifest'.
trinque: this must be
that orthogonal language I've heard about.
ben_vulpes: well in
theory, but in practice everything below makefiles already needs a regrind; aggression
to request newblocks if none have been advertised recently; hash
truncation atop
that. so
there's an opportunity
to significantly reduce
the amount of regrinding by introducing
the manifest after
the makefiles release and just regrinding 2 patches instead of
the whole
tree. unless i misread
the situation.
trinque imagines a house which required a
tattoo on your neighbor's wife
to keep standing
trinque: as
the
tree stands now, one in makefiles.vpatch, iirc
trinque: ben_vulpes: because
the manifest has no antecedent, and you're gonna have
to go graffiti other files like an idiot
☟︎ ben_vulpes: mod6: my original q was in re why regrinding
the whole
tree is necessary instead of introducing
the manifest now and using it going forward
mod6: alright, gents, I'll have
to dig into all of
this sometime.
mod6: ben_vulpes: im
trying
to look at
the big picture.
the manifest spec is a part of
that, ya.
trinque: the words I wrote right
there gave it as an example of "this needs a manifest"
ben_vulpes: it's a single file
that collapses
the
tree into a pillar
trinque: there ~are no~ manifest capabilities
to be had
mod6: is his lisp version of V
to become
the new defacto
thing
that has manifest capabilities?
ben_vulpes: shouldn't matter in
the slightest which v impl is used
ben_vulpes: mod6: focus on
the manifest design, not
the v implementation linked in
trinque 's post
mod6: anyway, I guess I'll have
to put
this on
the conveyor and work
through all of
this.
mod6: Step
two of
the guide says "Ensure at least one of
the following is installed:" "sbcl" or "ccl"
trinque: the blog post
there is
talking about
the manifest file format.
mod6: so
this is all in lisp. is it going
to be simple for n00bs
to get lisp installed and
to run V?
mod6: that said, everything must be pretty much "firmly" in place with V rules, manifest, naming conventions, what have you, before I wanna move on
that.
mod6: i'll regrind
the whole
trb
tree. however, I
think if we -must- do
this, we should only do it one
time. and i really don't even want
to do it at all.
ben_vulpes: for
the sake of exploring
the state space; it is more desirable
to regrind
the whole
tree rather
than
to introduce
the manifest at
this point and use it going forward?
trinque: so if
there's a hero around
that wants
to
take
that on, we can start getting
trb patches out
the door again.
☟︎ trinque: they're ready, being held because I haven't reground
the entire
tree around a manifest.
ben_vulpes: and yeah, i could possibly put
this
time into humping
trinque's wallet patches down
the field
ben_vulpes: heh, last
time i
took a crack at *that* i got mired in finding unspent outputs with
trb
☟︎ ben_vulpes: and
to
think i spent all
that
time poring over
the boost docs
mod6: so
that might need
to be fixed.
mod6: which also leads me
to see
that in your code, you're attempting
to use an iterator
to loop over a map<string, string> , and add
the keys
to argKeys. but you never did set
the iterator
to mapArgs.begin()
mod6: you could do it with an iterator
too, but
that's not quite as clean.
mod6: i'll
take a look here in a sec.
a111: Logged on 2015-03-23 21:11 mircea_popescu: if i want
to make a
txn
that's 1mb, i do.
mimisbrunnr: Logged on 2018-06-26 02:33 ben_vulpes: i'm not familiar with
the design imperative driving
the individual
transaction size limitation, is
there a reason
to keep an individual from making a 1mb
transaction if
they'd like
to?\
mod6: thanks for
the script mircea_popescu!
☟︎ BingoBoingo: In
the latest update sometime within
the next
three days
the fiber company will call
to set up an appointment
to install a pipe
to
the apartment.
BingoBoingo: I mean
the part where a fob exists
that isn't infineon
BingoBoingo: The chromebook appliance
thing just keeps getting weirder
mircea_popescu: asciilifeform nothing better
than
the short fp available
to identify
that #1 ?
a111: Logged on 2018-06-23 20:39 phf: "beware of dog"? seems unlikely
though..