Show Idle (> d.) Chans
← | Results 501 ... 633 found in asciilifeform for 'from:cgra'
cgra: trinque: i've been playing with your item some more, specifically seems like i've managed to build an arm64 equivalent. but wanted to ask: did you find out yet why does gnat build get ill if using multiple build jobs?
cgra: i must switch to async mode again, talk you later!
cgra: basically, one program runs at a time
cgra: yeah, pretty tiny market
cgra: asciilifeform: yeah, gotten this impression from the logs too
cgra: asciilifeform: is the slim-os peh box going to resemble the 'cardano' item as originally thought?
cgra: asciilifeform: re dump-scos, right
cgra: asciilifeform: did you have a specific 'os' approach already in mind for this iron rts? apparently not linux, also 'dos-like' mentioned, but maybe not exactly a 'dos'?
cgra: asciilifeform: as a curiosity, another gnat quirk was a compiler switch '-fdump-scos', only '-gnateE' worked, which appeared to be the same, only older name
cgra: ubuntu 16.04 gnat (mine) didn't accept these pragmas: No_Fixed_Io, No_Implicit_Protected_Object_Allocations, No_Implicit_Task_Allocations, No_Multiple_Elaboration, No_Task_At_Interrupt_Priority, Pure_Barriers
cgra: (for me specifically)
cgra: right. trinque's bootstrap ought to solve these issues too
cgra: and copyright year up to 2014
cgra: 'gnat --version' says 'GNAT 4.9.3'
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-12-16#1026187 << asciilifeform, wasn't aware of exact details when, but i assumed musl-based, yeah. also, personally already had to drop a handful of ffa's restrictions, and tweak a ffa build param, because so far i've been using the gnat in ubuntu 16.04, which is older than the adacore 2016
cgra: i got it to finish this way, and didn't run into any other, obvious issue afterwards
cgra: the still-dirty part here is that i had to copy the help2man 'software package' with a new 'help2man_binonly' name
cgra: considering various approaches, the least dirty way to get around it was to add a "help2man_binonly" trinque-designed install target, with a simple "cp help2man /bin/help2man; chmod 755 /bin/help2man" install commands
cgra: texinfo generates it's manpages using help2man, and help2man generates its info pages using texinfo
cgra: the stage 2 didn't work for me as is, because texinfo seems to depend on help2man, *and* vice versa
cgra: the course i'm now attending for my sane computing curriculum, is binary auditability. atm i'm carving out the glibc bloat and trinque's musl bootstrap seemed like a suitable ingredient. i just finished building it and came to report the results so far
cgra: asciilifeform: now registered, and ty for waiting
cgra: !!key cgra
cgra: trinque: re keys, i'll try my key then, once it's ready
cgra: asciilifeform: feel free to ask if you come across difficult-to-grasp finnish expressions :)
cgra: trinque: i don't have a genuine point of comparison, haven't traveled much... or doin things. generally, played too much computer games of my youth. but my impression is, cannot be of worst places
cgra: i'm from finland. i'm atm less caught up with the saltmines, so can concentrate on things i find more meaningful
cgra: been following btc and altcoin events since maybe 2012-2013, eventually found out about tmsr/associated things, and been a reader since then (not sure at what exact point did i notice)
cgra: asciilifeform: thought i'd ask trinque first, him being the bot owner. plus, this is still just a test key, not the final one
cgra: and the other, non e-specific differences were achieved with existing gpg levers
cgra: asciilifeform: i got the large e in by modifying the gpg, but unmodified gpg seems to handle it afterwards without apparent problem
cgra: asciilifeform: re deadline, ok ty
cgra: trinque: re deedbot, would you oppose any of this to be offered to it: 1) a large 'e' gpg key that 'appears to work' (tried signing, encryption and decryption, export), 2) no subkeys, only a primary key, 3) no email or comment, just key name
cgra: asciilifeform: i could likely use extra ~24h, unless you really want to publish today
cgra: hmm, ok, then i guess it's back to mid-term gen plan
cgra: i wonder if gpg will choke on a large e
cgra: well, asked a q of both, and fully answered :)
cgra: yeah, meant exclusively private exponent, and got the answer
cgra: (meant also that d = private exponent)
cgra: is my assumption correct that private exponent is a function of those, so in theory can replace d later if didn't generate optimally?
cgra: exact same process as p and q?
cgra: asciilifeform: what did you have in mind re public exponent, for ffa keygen?
cgra: this would mean to me that i could make a long-term key already, only if i can stuff it down gpg's throat for the short term
cgra: asciilifeform: is it that you don't have to use separate keys with gpg if you don't want to?
cgra: and primary key apparently suffices for signing, even though gpg has this separate 'signing and encryption key'
cgra: primary and sign/encrypt key separately, apparently at minimum. but those peh conversion samples have only one key, the primary key
cgra: gpg generates multiple keys,
cgra: well, with rfc on the side at least
cgra: yeah, had a giggle staring at it after initial confusion
cgra: yes :)
cgra: this 'rsa packet' isn't used either, just another skip
cgra: asciilifeform: it aligns, because you have this 'rsa packet' to cover up the lack of skip. it reads the remaining byte of the two-byte length field and finishes the skip job
cgra: i mean <256 bytes
cgra: because: unhashed sub section is almost always(?) <255 bytes long
cgra: asciilifeform: easiest way to check this is print in the litmus code the supposed skip length
cgra: and from then on, just happens to align. 'rsa packet' helps in this accidental alignment, but it remains a mystery to me, why this piece exists in the code
cgra: litmus attempts to skip the unhashed section, per one byte, the high byte of the actual size field. so it ends up skipping 0 bytes. actual length is <256, so the high byte is 0
cgra: yes, and i'm arguing: by accident
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-11-20#1025074 << sorry i didn't immediately check your link. here's the problem: in this case, 0 bytes get ignored! even though, some should've been.
cgra: in 'ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig' the 'rsa packet' coincides with a unhashed sub-packet section. the two hash bytes and a signature section comes after that
cgra: can you give an example? example i mentioned, is not so
cgra: ok, i see. and inspecting more of gpg 1.4.x droppings would explain the current wording better?
cgra: right. do you still think the 'rsa packet' is a proper label for the section?
cgra: asciilifeform: do you mean it's safe to assume "unhashed sub-packet" section will always be <256 bytes?
cgra: well, pgpdump says the unhashed sub-section contains one item "issuer key id". but litmus labels this unhashed sub-section "rsa packet", which doesn't parse in my head
cgra: i walked through 'ffa_w_borrow_expr.kv.vpatch.asciilifeform.sig' byte by byte, and also stared at 'pgpdump -il <sigfile>' of the same file
cgra: per rfc4880, unhashed sub-packet section length should be 2 bytes, not 1. and so far i couldn't figure out what 'rsa packet' could mean here. litmus.sh appears to work as long as signature's unhashed sub-packet section is shorter than 256 bytes
cgra: 2) i'm comparing litmus.sh to rfc4880, and i fail to get a match: this 'rsa packet' coincides with signature's unhashed sub-packet section when the section is less than 256 bytes long. in part, it's because the unhashed section length is read as a 1-byte value, and yields 0 (the high byte).
cgra: asciilifeform: something about litmus.sh. 1) as peh is an external too, should check externals before calling peh
cgra: ok, i'll keep in touch by then so you know how it went
cgra: asciilifeform: sunday 11pm utc, is that an acceptable deadline? if i'm not in wot by then, just pull the publish trigger
cgra: right... just put to the coldest of storages
cgra: so smth like sign the new peh key with the old key, with a message saying "this is new me", destroy the old key and be done with it?
cgra: asciilifeform: if one wanted to switch to ffa once it matures, would there be any point in 'converting' the old gpg identity, or just need a fresh key?
cgra: asciilifeform: how much do i have time before you publish?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-11-17#1024914 << or, rather not add carry anywhere, but to just let it wrap around properly? so to fix this, can merely lift the 'NoCarry' restriction
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-11-17#1024921 << you must mean 'yields 1' and a borrow bit 1?
cgra: trinque: ok
cgra: asciilifeform: i mean, i thought i'd learn some rsa etc first, to be able to decide what's 'good enough'. in case i have more choices avail than the current wot people had at their registration time
cgra: i've been delaying the wot registration, because i don't have a proper understanding of best realistic approach to it yet
cgra: right
cgra: asciilifeform: how much do you have currently half-complete material for ffa?
cgra: i dunno if i'd have spotted the issue by walking through the physical bounds proof. i stumbled upon it while experimenting
cgra: np, glad i could provide finally some useful input
cgra: hehe :)
cgra: sha256sum of the test tape in q is "b6388e30fb881ebd7a37bf45fb07003e0420f2c923495dfc60c0705f22cca6a2"
cgra: i'll re-check
cgra: as a side note, a 256-bit test tape "10k_shots_256bit_ffa_slid_rnd.tape" also bombs the same way on me
cgra: say, for example: if X := 2**255 and M := 2**255 - 1, X - Q would end up negative (as that tape does in my case), because of the optimization.
cgra: i haven't followed exactly a linear learning schedule, so some of the earlier chapters are somewhat unfamiliar to me... but, the reason appears to be this optimization.
cgra: asciilifeform: a 256-bit peh tape like ".1 .FF LS .1 .3 MX" will bomb on me at here.
cgra: laters
cgra: asciilifeform: i gotta split as well, had really small window of contact here. i'll consider your comments and return when got anything to talk about
cgra: asciilifeform: i'll take notes of those "zig-zag" issues and let you know sometime in the future
cgra: yours
cgra: i suppose in the long run, shouldn't hurt to exercise my brain though (for reading versatility), asciilifeform have any idea from where did this model of thinking got stuck?
cgra: right
cgra: asciilifeform: yeah this, sounds what i meant
cgra: my brain wants words to be in same order as in intra-word bits, does that make any more sense?
cgra: asciilifeform: is "paper order" senior-word first in your mind?
cgra: i keep wanting to think the bignum in "paper order", and i get zig-zag on shifts if they're junior-first, ie. not paper order
cgra: heh, yes. this must be why it isn't talked much. it's exactly how i feel, too. my brain was wired "left-handed" apparently
cgra: just dig libs' code?
cgra: where should i look for to understand why junior-word-first?
cgra: shifting left contents of "QR", would imply by name that whatever is on R, drifts into Q. which is not true in this case. when i try to get my head around of the reality, this is where i end up thinking zig-zag.
cgra: possibly only in my brain, i'll try and open it up more:
cgra: i didn't understand how ada index syntax would've helped anything. my brain keeps insisting on "why not senior word on FZ'First, junior word on FZ'Last", and get rid of extra "shift zig-zag" thinking pattern
cgra: personally, my brain melts at this point (i have no issue with ch 10 diagrams), because while Q's bits really step into R, shifting QR contents *left* strongly suggests the opposite, "QR" has "R" on the right, from where going left, ends up in "Q".
cgra: the context strongly suggests i just atm suck at binary thinking, so i came looking for advice to better understand the thought model related to FZ word order. It's been discussed previously, but I didn't get a clue from there enough to understand why isn't junior-word-first worse than senior-word-first
cgra: asciilifeform: i've taken a break from trb study and sat on your FFA course bench
cgra: asciilifeform: thanks for sharing. i'll be off again, but hopefully return sometime later, wiser
cgra: right... i'm still playing around with heights between 160 and 200k. highly unrepresentative
cgra: and assumed you could perhaps interleave that across multiple sources
cgra: it seemed to me the advertised series of blocks i get in response to "getblocks" is in correct order
cgra: asciilifeform: sounds like i need here too, a better picture of what the cause of the current slowness exactly is. i might assume too much
cgra: asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2020-08-26#1020514 << can't i have a small enough buffer that doesn't bother me being full if under attack, but help when syncing from friendly nodes?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-08-26#1020507 << ah, ok. though still hoping to hear comments re the q, from whoever has any
cgra: or maybe having a bounded block buffer?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-08-25#1020449 << to educate a noob: what's wrong with the headers-first sync?
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2020-08-25#1020446 << i meant the block ~advert~ (an "inv" message), it was a convoluted, pre-trb way of resuming the sync chain where it left off last cycle, and what the 'hashContinue' variable was part of. just clarifying myself, i still must finish my homework.
cgra: back to trb school bench, but will follow the logs for a while.
cgra: ... i might have been too early in making conclusions, i need to learn more trb mechanics. i realized i don't really know enough about the subject yet.
cgra: the angle i'm looking at this, is specifically the initial sync. i have no experience of long term node operation.
cgra: 3) if parallel sync is desired, some kind of buffering must be reintroduced - perhaps just the block hashes the source peers advertise in their "inv" responses. i have no obvious fix to offer, i just wanted to get this out sooner rather than later.
cgra: 2) trb's chained sync stops right after the initial cycle, because "asciilifeform_orphanage_thermonuke.vpatch" got rid of "PushGetBlocks()" in the "inv" message handler: the node being behind doesn't react to the magic current block advert anymore.
cgra: 1) chained sync is a repeating sequence of "getblocks" query, "inv" response, "getdata" query, 1+ "block" responses, and one last magic "inv" response advertising the most current block (see "pfrom->hashContinue" in the code).
cgra: it appears that trb's "chained sync" (like the initial sync) doesn't currently work, because it depended on originally buffering the bastard blocks. further details follow:
cgra: hi all, i've been a reader of anything tmsr related, is why i knew of this channel. i came here, because i might have something useful to say re trb sync issue.
← |
Random(asciilifeform) | Download hourly DB snapshot | Get Source Code