60900+ entries in 0.035s

a111: Logged on 2018-11-19 21:44 bvt: alternatively, i could add new functions at common
tree part if i don't
touch any files included in later vpatches (so adding entries
to manifest would be not possible). seems like some quite unnatural acrobatics
to me.
bvt: but i would agree
that one's understanding of vtronics is determined by ones
toposorter implementation.
bvt: alternatively, i could add new functions at common
tree part if i don't
touch any files included in later vpatches (so adding entries
to manifest would be not possible). seems like some quite unnatural acrobatics
to me.
☟︎ bvt:
http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first,
then diverging system-specific branches, i still could add new functionality on
top of *each* of
these branches. i don't like
this option.
☝︎ diana_coman: asciilifeform, read on, not as if recommended for
the
task, no
diana_coman: asciilifeform, in my understanding he wanted
to cement "common api" hence possibly root since
that's
the only common part for
the 2
trees, hence "regrind" if new (because not in root etc)
a111: Logged on 2018-11-19 20:52 bvt: i hope
that for
tmsr.os most of
these
things will become unnecessary; lower levels of libc/libada are not
the right place
to fix
the underlying problem.
a111: Logged on 2018-11-19 20:45 bvt:
http://btcbase.org/log/2018-11-19#1873573 << i will have
to
think more about vtree organization. if i use api as
the foundation for
the
tree, adding new system calls would cause regrind; in
this case,
the api should be complete from day one.
bvt: i
totally agree with all
these points.
tree diverging after empty genesis is separate enough in my view.
diana_coman: keeping
the
trees in sync is probably cheaper
than regrinding
the whole
thing anyway; and if /when it's not,
then...regrind it as a single
tree and
that's
that
diana_coman: so if you are not sure, I'd even keep
the
trees separately, I still don't quite see
the problem with
this (the benefit being
that it doesn't force you
to decide NOW on something you don't yet ...know)
diana_coman: regrinds are not evil or anything of
the sort but
they do have a cost ; and if you get others
to sign your patches,
the cost increases since you lose
the original signatures basically
diana_coman: bvt, precisely because it can't be fully clear in advance I'd suggest
to choose
the more flexible v-structure rather
than something with set in stone requirements (such as API as root of
the v
tree sort of
thing);
this is NOT
to say or guarantee you won't regrind but simply
to not make ~surely needed
bvt: i hope
that for
tmsr.os most of
these
things will become unnecessary; lower levels of libc/libada are not
the right place
to fix
the underlying problem.
☟︎ a111: Logged on 2018-11-19 11:50 mircea_popescu: experience kinda seems
to indicate
trying
to have
the same model for
two
things is a recipe for
tears in
this "industry" of apes and aping, but
then again... man gotta
try.
bvt: ftr, i don't expect
that i will make
this
tree without a single regrind
diana_coman: anyway,
the purpose of V is not
to force something onto
the user
bvt: yes, i can definitely see
that. scope of
the
tree must be fixed at
the moment of creation. which is not necessarily a bad
thing.
diana_coman: the only case in which such a
thing makes sense is if it's already a fixed /known /set in stone set
diana_coman: basically it's just a way
to cause yourself
trouble, I wouldn't recommend
diana_coman: bvt, from experience I can
tell you
that "complete from day one" is not likely
to ever happen
bvt: otoh, if system call asm packages are at
the
tree foundation,
the api uniformity will be enforced by convetion only, and
the branches will diverge right after genesis.
☟︎ a111: Logged on 2018-11-19 11:46 diana_coman: bvt,
that sounds like you want
to start
then
the
tree with ..the API? otherwise at any rate,
the user CAN use
the same API with whatever provides it, no?
bvt:
http://btcbase.org/log/2018-11-19#1873573 << i will have
to
think more about vtree organization. if i use api as
the foundation for
the
tree, adding new system calls would cause regrind; in
this case,
the api should be complete from day one.
☝︎☟︎ a111: Logged on 2016-11-07 18:27 mircea_popescu: im sure nobody had
the sense
to create a "total payout
to defecting miners" watch, because hey,
they're "developers" not
thinkers.
a111: Logged on 2016-11-07 18:26 mircea_popescu: well, it slowly builds, until
the miners defect.
a111: Logged on 2017-08-24 14:23 mircea_popescu:
http://btcbase.org/log/2017-08-24#1702759 << eventually
this will necessarily happen, yes. "segwit"
transactions are stored on
the bitcoin network as "anyone can spend", so eventually miners will unroll
the segwit chain. how soon is not easily predicted (which is why
the idea is stupid/usg-like, introduces impredictability in
the currency)
mod6: Yeah, makes sense
to me. I remember
that.
mod6: Ah, ok BingoBoingo.
Then
that'd be it, since
the 0.1 BTC back and forth
took place in mid-August.
BingoBoingo: mod6: I started my ledger in
the Pizarro notes on September 1st.
mod6: Hope
this helps. Cheers.
mod6: I won't speak for BingoBoingo as
to why his ledger copy does not show
the 0.1 BTC sent from me
to him, and
then back from him
to me. I'll let him speak
to
that.
a111: Logged on 2018-11-19 05:30 ben_vulpes: BingoBoingo: why does mod6's ledger show a
transaction for 0.1 btc
to you on august 12th and
then back from you on august 17th? it doesn't affect
the accounting, but i am perplexed as you both stated
that your ledgers in
these shared notes contained all of your pizarro
transactions with noted exceptions
that do not include
that
transaction.
a111: Logged on 2018-11-19 05:06 ben_vulpes: mod6: why does
the net change in pizarro's cash account for august not equal
the difference between
the sum of incoming and outgoing cash
transactions?
a111: Logged on 2018-11-19 07:54 bvt: mircea_popescu: i understand
that empty genesis (well, it's not precisely empty,
there is a manifest file) is suboptimal, however:
a111: Logged on 2018-11-19 07:09 ben_vulpes: asciilifeform: i've sketched out a set of
tables
that could hold all pizarro data accounting data and generate statements;
the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me
to complete
the design, put sql
to disk and
turn
this into an accounting spreadsheet for pizarro?
mircea_popescu: experience kinda seems
to indicate
trying
to have
the same model for
two
things is a recipe for
tears in
this "industry" of apes and aping, but
then again... man gotta
try.
☟︎ mircea_popescu: bvt
this is laudable, provided of course it actulaly works out.
diana_coman: bvt,
that sounds like you want
to start
then
the
tree with ..the API? otherwise at any rate,
the user CAN use
the same API with whatever provides it, no?
☟︎ bvt: i want
the platform-specific branches
to be glued
together because API for users should be
the same in all of
them. so
that user can press a branch for aarch64 or x86 without changing anything in his code.
a111: Logged on 2018-06-25 16:40 mircea_popescu: spyked> I
think
there's great benefit in
the ffa chapter-based approach <<
that ~started with a genesis~.
diana_coman: bvt, while I don't see a big problem per se with an empty genesis,
the question for your specific situation is why glue
together 2
trees if
they diverge right from
the start anyway?
diana_coman: phf, I wanted
to sign your vtools patches but I realised
that
they are using sha so I don't really know: do you plan
to regrind
them with keccak?
mircea_popescu: i mean, it certainly has
the virtue of signalling, "Hey guise, i intend
to do
this" sorta
thing
mircea_popescu: bvt i dunno
that it's a huge deal, but maybe dig up
the log reference ?
bvt: 2. i seem
to remember but can't find right now a discussion (around
time spyked published adalisp)
that making such a genesis should be ok. perhaps i am confused about
the context of
that discussion and did something stupid.
bvt: 1. x86 and arm
trees will diverge pretty much from
the start, i can't see how anything useful and complete can be packed into genesis.
bvt: mircea_popescu: i understand
that empty genesis (well, it's not precisely empty,
there is a manifest file) is suboptimal, however:
☟︎ ben_vulpes: asciilifeform: i've sketched out a set of
tables
that could hold all pizarro data accounting data and generate statements;
the only remaining puzzlers are modeling subscriptions, prepay, and asset depreciation. would you like me
to complete
the design, put sql
to disk and
turn
this into an accounting spreadsheet for pizarro?
☟︎ ben_vulpes: asciilifeform: i believe
this report settles
the reported discrepancies. i will have
to respond
to queries asynchronously, as i'm
traveling for
the next week.
ben_vulpes: amend
that question
to include
the detail
that *your* submitted ledger does not contain either of
those
transactions.
ben_vulpes: BingoBoingo: why does mod6's ledger show a
transaction for 0.1 btc
to you on august 12th and
then back from you on august 17th? it doesn't affect
the accounting, but i am perplexed as you both stated
that your ledgers in
these shared notes contained all of your pizarro
transactions with noted exceptions
that do not include
that
transaction.
☟︎ ben_vulpes: mod6: why does
the net change in pizarro's cash account for august not equal
the difference between
the sum of incoming and outgoing cash
transactions?
☟︎ mircea_popescu: bvt but i mean... what's
the logic of an "empty genesis" ?
BingoBoingo: mircea_popescu: I'll give it a play with as I work
through more punch list items
BingoBoingo: What else can you expect from
the prototypical Pantsuit slave society
mod6: I do appreciate
the wake up call, and I
take your words
to hard. I'll do better
to
take a long rest/break and stop spinning my damn brain so hard.