log☇︎
348 entries in 0.953s
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
asciilifeform: the memory gymnastics in mpi. and 'for your convenience, we will package the defective transistors separately!11' , i'll call it here
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.
a111: Logged on 2017-12-22 11:20 diana_coman: for fun: http://www.dianacoman.com/2017/12/21/eucrypt-correcting-mpi-implementation/#comment-1011
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
asciilifeform: 1 way, would be by going to his own cellar and fetching optical disk where he has ~his~ mpi
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: take mpi as a fine example in this vein.
asciilifeform: mpi_tdiv_q_2exp is in fact used in primegen.c , but in such a way that its brokenness doesn't affect the output , 'accidentally'
asciilifeform: grep for q = mpi_copy( nminus1 );
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.
a111: Logged on 2017-12-22 11:20 diana_coman: for fun: http://www.dianacoman.com/2017/12/21/eucrypt-correcting-mpi-implementation/#comment-1011
diana_coman: for fun: http://www.dianacoman.com/2017/12/21/eucrypt-correcting-mpi-implementation/#comment-1011 ☟︎☟︎
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
deedbot: http://www.dianacoman.com/2017/12/21/eucrypt-correcting-mpi-implementation/ << Ossasepia - EuCrypt: Correcting MPI Implementation
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)
asciilifeform: mpi_size_t _i; \
asciilifeform: mpi_size_t _i; \
asciilifeform: MNP_COPY_INCR we find in include/mpi-internal.h , and is a straight memcpy-style copier.
diana_coman: so mpi_tdiv_q_2exp(result, number, 0)
diana_coman: and even more to the point: what is the result in mpi sane?
asciilifeform: ( replacing 'mpi' with 'mpz' )
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
asciilifeform: asciilifeform's cut of mpi did not include primegen or rsa.c
asciilifeform: it ain't in mpi
mircea_popescu: woman just announced she found an allocated and unused mpi in mpi.
asciilifeform: at one point asciilifeform planned to cut out the allocator from mpi entirely, but ditched whole thing before ever getting there.
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
asciilifeform: ( it was perhaps 80% of how asciilifeform cut koch-mpi , by similar proportion )
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.
asciilifeform: !~later tell phf plox to intern http://www.loper-os.org/pub/mpi/ffa_ch1_genesis.vpatch.benvulpes.sig
a111: Logged on 2017-12-15 01:57 phf: diana_coman: since you basically split from mpi, i put you into a separate project http://btcbase.org/patches?patchset=eucrypt
phf: diana_coman: since you basically split from mpi, i put you into a separate project http://btcbase.org/patches?patchset=eucrypt ☟︎
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?
mircea_popescu: mpi ?
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
asciilifeform: incidentally if mircea_popescu wanted to go 'whole hog' re http://btcbase.org/log/2017-12-14#1751589 , could even throw out asciilifeform's mpi and make new one from the source material. see if it ends up same, possibly find new cuts. ☝︎
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'
mircea_popescu: http://btcbase.org/log/2017-12-14#1751448 << because it's not a fucking sibling to fucking 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
asciilifeform: take mpi . dir is 'mpi'.
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/... ☟︎
asciilifeform: though i'll admit that i personally dun get the fixation with moving mpi to being a subdir of $newproj.
asciilifeform: now let's come back to my much earlier pill, which i suggested in the mircea_popescu thread. which is imho even uglier. in that one, diana_coman would have to introduce the three mpi-ism vpatches comprising her working set, as ~files~ into eucrypt. and a sed script, and a vtron invocation, into her eucrypt makefile.
asciilifeform: it's not eucrypt, of course, but the helloworld i originally included in mpi . but shows what i meant above.
asciilifeform: http://www.loper-os.org/pub/mpi/pseudo_eucrypt.vpatch << demo
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
asciilifeform: i.e. why can't 'eucrypt' be a ~sibling~ dir to 'mpi' ☟︎
asciilifeform: it isn't required for the linker, nor for maintaining v-lineage ( the latter works just as well if diana_coman were to simply add a comment to 1 or more items in mpi dir , that 'this is nao part of eucrypt' )
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
phf: diana_coman: fyi http://btcbase.org/patches/sane_mpi_eucrypt
phf: diana_coman: your mpi_second_cut.vpatch.asciilifeform.sig links to http://dianacoman.com/vpatches/mpi-genesis.vpatch.asciilifeform.sig
mircea_popescu: diana_coman i don't mean re this, necessarily. mpi as an import is one thing
asciilifeform: i do regret having used name 'sane-mpi', there is very little sane about it except strictly in contrast with the original material
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
asciilifeform: ( what was asciilifeform going to do with mpi ? there was plan, for 1 further cut, of the logger and the allocator. but i put it in cold storage when began work on ffa . )
asciilifeform: ftr i have no intention of amending mpi myself . if at some time i discover a new kochism therein, i will vdiff against diana_coman's mpi-containing entity
asciilifeform: the other is to preserve the two lineages as separate, but to link your item against e.g. mpi.a , and to insert the latter's hash into your vtree, to proclaim the linkage -- as i did with the binariola schematic jpegs in FG genesis.
asciilifeform: diana_coman: in the contemplated example, are eucrypt/mpi and eucrypt/serpent plug-in alternatives for each other ?
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?
mircea_popescu: so how do i patch mpi to become eucrypt/mpi ?
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
asciilifeform: Binary files a/tests/test_mpi.o and b/tests/test_mpi.o differ
asciilifeform: Binary files a/tests/test_mpi and b/tests/test_mpi differ
asciilifeform: if there isn't 'mpi' in each -- your patch is off
diana_coman: but apparently I should have done it on a containing mpi containing the code
asciilifeform: diff/patch is not insensitive to directory structure, or it could not handle dirs at all. in original we have 'a/mpi/bin/README', in yours there is instead 'a/bin/README'.
asciilifeform: you stripped the dir 'mpi' when you made your diff
asciilifeform: cab965c726b50f98e3d74a1be4b119dcf65c9900749d33707525c94c1432b855f2e3d39043a4fbb9d907fe3853242fccd773017a2d3763bdd76fbc9a6f6a01dd mpi_second_cut.vpatch.asciilifeform.sig
asciilifeform: b05ca401ecfe3f5bfa8794377241db12f5dc302fc552075ab3c78e7379b5b6a838af6d37d725798556cb27bc57213c388c92fa9b06f2e9233264b3ea8f89824f mpi-genesis.vpatch.asciilifeform.sig
asciilifeform: fba9ea0ece4c138f9510f20a91942dde57ca2273da2ee776004dc2404dbdf815283b05aa2487689c13043882ce65a09a2a9ef33bde444b4a9fedc5971fdf8a3a mpi_second_cut.vpatch
asciilifeform: fa32a27b8ac0753d6052abd37f56df545490315c3019ab0c9e695543f1f14b6bf70aba29a88982eea82a1e8c4a112e6cb9d4e4553062a977bb0bac38ddd91981 mpi-genesis.vpatch
a111: Logged on 2017-12-06 20:12 asciilifeform: http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch.asciilifeform.sig for the l0gz.
phf: http://btcbase.org/data/mpi_second_cut.vpatch
asciilifeform: i will point out that the mpi genesis was created in oct. of 2015, when v was 2 mo. old.
phf: so this error wouldn't surface until very last mile, in my case http://btcbase.org/patches/mpi_second_cut/tree/mpi/README fails to press
phf: http://btcbase.org/patches/mpi_second_cut#L5316 you can also see it in mpi_second_cut http://btcbase.org/patches/mpi_second_cut#L5316
asciilifeform: http://www.loper-os.org/pub/mpi/wtf.tar.gz