348 entries in 0.846s
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: the logic is actually very strict : only key can sign, therefore only key can genesis, and see all the discussions around
mpi re exactly what code production is deemed etc.
phf: so the weird graph indicates that some hunks are missing antecedents, in this case at least test_mpi.c is claiming a previous version that's not in btcbase
diana_coman: it does modify a lot of things so it's seen as having antecedents ch1, ch2 and the
mpi-fix iirc
mircea_popescu: trinque there's an ambiguity here i'm possibly responsible for though not intended : to "regrind", ie to take a pile of patches and make them into one single patch ; as opposed to re-genesis, which is what happened with eg
mpi.
diana_coman: ben_vulpes, he started sounding too much like
mpi-insane
mircea_popescu: but in point of fact the hook to hang by is there : at the present time how would someone who is hostile (ie, does not trust what we say) discern who originated
mpi ?
mircea_popescu: the fact that it was not used in
mpi anything might be an indication orig author just included some notes for later and forgot to mark them for anyone else.
mod6: speaking of tree-display... once I spit out the tree for eucrypt, then it makes sense. no reason that you should have to press 'eucrypt_mpi_fix_copy_incr.vpatch' to have pressed 'ch2_truerandom.vpatch'
mod6: So in this case, it is a problem, because you may not want to press 'eucrypt_mpi_fix_copy_incr.vpatch' leaf when pressing to only ch2.
mod6: Initial findings after digging into it here quickly, my V seems to have the leaves in a separate flow order than from Stan's (v99). Which, by itself, (as we've discussed before) isn't a problem per-se. It seems though that in the case here where the leaves are ordered differently, and you press (with my v (99994)) up through 'ch2_truerandom.vpatch', it also includes the 'eucrypt_mpi_fix_copy_incr.vpatch' a
diana_coman: it seems I also found a difference in press behaviour between asciilifeform's v99 and mod6's v: this new vpatch of mine si correctly identified as leaf and otherwise descendant of ch1_mpi.vpatch by both v ; however, when pressing ch2 vpatch, mod6's v presses this other leaf too from what I see, while asciilifeform's v99 does not press it; to me v99's behaviour seems correct but I don't know if this is something that was discussed before
diana_coman: thing is now I'm even *less* comfortable using that whole
mpi thing... makes me wonder what else is in there and not yet spotted
diana_coman: for the very impatient: caller fails on the cases where it uses that broken macro i.e. any shift by a multiple of BITS_PER_MPI_LIMB; 0 is just one case, not the only one; further up, caller avoids the issue, as stated
diana_coman: instead it does first copy(result, nminus1) and then mpi_tdiv_q_2exp(result, result, k)
diana_coman: namely: it needs to calculate nminus1 / 2 ^ k but it does NOT call mpi_tdiv_q_2exp(result, nminus1, k)
diana_coman: and even more to the point: what is the result in
mpi sane?
diana_coman: does anybody know precisely what function mpi_tdiv_q_2exp from "sane
mpi" does exactly? as we were talking of understanding of code earlier
mircea_popescu: woman just announced she found an allocated and unused
mpi in
mpi.
phf: well, autoconf is not just scripts. it's also compatibility shims, which is a bit tricky in case of a differ, since, unlike
mpi, it has a lot of file system interaction code, that might or might not be portable. anyway, we'll see
mircea_popescu: that said, a gmp version pushed out as a patch on
mpi might not be entirely without merit.
mircea_popescu: in other news : the
mpi m-r implementation has a fixed witness at 2.
diana_coman: to round up the previous thread: previous patch on
mpi remains in place but linked to standalone
mpi project; EuCrypt got is own genesis patch that creates *the whole currently known structure*; each chapter comes with its own patch adding content
phf:
mpi is a fraction of what gnupg is, are we then moving away from pgp keys and signatures?
a111: Logged on 2017-12-14 19:22 mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new"
mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
mircea_popescu: like how oral culture worked, the concept of a trope, as found in folk tales, is really simply equivalent to "and this is how
mpi goes, and this is how bubblesort goes..." and so on.
mircea_popescu: that could've meant tmsr-diff. what it means practically is that there's going to be a "new"
mpi in eucrypt, textually identical to the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of the same exact code as if new, resulting in a situation where instead of the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens to be exactly
☟︎ a111: Logged on 2017-12-14 16:13 phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/
mpi/...
mircea_popescu:
mpi is a SUB. and if it can't act the sub part it's getting cut out with hot irons and the ground where it stood salted.
a111: Logged on 2017-12-14 15:39 asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to '
mpi'
a111: Logged on 2017-12-07 16:52 mircea_popescu: so then why can't she simply move the
mpi/ dir into eucrypt/
mpi/ and proceed ?
phf: no what's shown is eucrypt ~inside~
mpi phf: but yeah in that model your press is / and you have /
mpi and /eucrypt, so if you want to link against /
mpi you do ../
mpi/... in your makefile
phf: rs~ might a little bit more meaning out of the press namespace. one pill to satisfy later group of people would be to come up with a filesystem hierarchy standard, i.e. you always press at the same root, but you're pressing into a tmsr namespace. so it'll be /bin/bitcoin/... /lib/
mpi/...
☟︎ phf: if she decides to replace bignum backing, presumably
mpi will get nuked and replaced with something else
phf: well, the project is called eucrypt, presses into eucrypt directory, inside it has support infrastructure like
mpi diana_coman: asciilifeform, I need to create a vpatch that performs the change of dir structure from a/
mpi to b/eucrypt/
mpi where the contents of the
mpi folder in both cases are identical; or more specifically for the task at hand: I want to create a vpatch that has as antecedent my previous sane_mpi_eucrypt.vpatch (whose output is an
mpi folder with all sorts) and results in eucrypt/
mpi where this new
mpi folder has precisely same contents
mircea_popescu: diana_coman i don't mean re this, necessarily.
mpi as an import is one thing
mircea_popescu: so then why can't she simply move the
mpi/ dir into eucrypt/
mpi/ and proceed ?
☟︎ mircea_popescu: diana_coman you'd make a new genesis, for eucrypt, and patch it with
mpi. this patch will share no .sigs with the other
mpi it is text-identical to
diana_coman: hm, I thought I need a/
mpi b/
mpi ; can I have ..what, a/
mpi and b/eucrypt/
mpi?
diana_coman: asciilifeform, I can compile it certainly wherever it is; but can I press with V eucrypt with eucrypt/
mpi and eucrypt/serpent let's say?
diana_coman: nesis of eucrypt itself and one the genesis of
mpi)
diana_coman: is there some documented process re how to create with V basically a new project that will contain as *internal* components derivations of existing projects? for example: eucrypt will have inside an
mpi component; as seen earlier, I can patch
mpi directly, but then how do I include the result in a higher structure? can I even do it while preserving the links? (I guess it would mean that resulting project has effectively 2 roots: one the ge
diana_coman: right; cleaned it again fully; put back in the readme file; made the structure a/
mpi and b/
mpi; can finally say that patch presses fine with both vtrons
diana_coman: but apparently I should have done it on a containing
mpi containing the code