asciilifeform: this, by all rights, ought to be a batch query. and probably will be in next version.

asciilifeform: if answer is 'no', it is inserted in 'factors' table.

asciilifeform: phf: nope. the only thing that happens to db as a result of bernsteinization is N queries 'do we already know this factor'

asciilifeform: and postgres is ~the~ albatross.

asciilifeform: the whole thing working at all is predicated on these seemingly 'abusive' design choices

asciilifeform: where i have O(1) access to them.

asciilifeform: have to live in MY data structure, in ram.

asciilifeform: so no, they can't 'live in db' while it happens

asciilifeform: trinque: i need random-access in O(1) to them for bernsteining

asciilifeform: oh and then, factors are found, largely the same set every time (how bernsteinization works) and each one is queried to the db

asciilifeform: this is easily 10% of the load on the db

asciilifeform: (the moduli have to turn into an array of bignum*)

asciilifeform: also did i mention that the entire db get shat out every time we bernstein ?

asciilifeform: (and, painfully, i had to find the offending garbage by hand!)

asciilifeform: (this scenario actually played out once.)

asciilifeform: the db absolutely has to be in a consistent state at all times, or 0 phuctoring takes place.

asciilifeform: makes connections.

asciilifeform: ah

asciilifeform: 0 joins. 0 anythings. just plain old queries and inserts.

asciilifeform: 0 anything fancy.

asciilifeform: mircea_popescu: 0 temp tables

asciilifeform: mircea_popescu: i'd first like to know what this'll do to integrity-on-mains-failure

asciilifeform: (because apparently 'thousands of queries / sec is abuse, get a cluster' is the 'state of the art')

asciilifeform: but i do not expect miracle.

asciilifeform: mircea_popescu: probably. i'ma run with new knob settings as soon as it is safe to reset the db.

asciilifeform: the fastest sync method, supposing one has access to a synced node, but also supposing that it won't do to simply copy the blocks (and it won't, you want to verify) is an eater-shitter system ☟︎

asciilifeform: or hm, nm, 1 night

asciilifeform: http://btcbase.org/log/2016-12-30#1593456 << iirc it took me ~3 days to sync via direct eatblock ☝︎

asciilifeform: 'boeing c-17'

asciilifeform: jurov: lulzily, searching for 'c++17' i get... airplanes

asciilifeform has a relative who, until recently retiring, programmed in PL/I ! i shit thee not

asciilifeform: but yes, cpp standardization is beginning to resemble that of PL/I

asciilifeform: jurov: догоним и перегоним ! (tm) (r) (hruschev)

asciilifeform brb

asciilifeform: (which is only half gui toolkit, it is also datastructure lib)

asciilifeform: btw , the unusability of naked cpp was also why we got horrors like 'qt'

asciilifeform: 'library issue'

asciilifeform: jurov: notice how some of the more appealing 11isms (e.g., bounds checking) dun work

asciilifeform: jurov: i am guilty of referring to anything that wasn't in my childhood borland3.1 as cpp11

asciilifeform: in the old days, every major cpp project had one

asciilifeform: and looks like jurov answered my q earlier. eulora folx are using crystalspace's adhoc boostron.

asciilifeform: aah

asciilifeform: ah hm. i have nfi what is 'planeshift'. 3dengine?

asciilifeform: mircea_popescu: presently i have nfi what part is published, or where

asciilifeform: postscript?!

asciilifeform: ps?

asciilifeform: i'ma have to gather the courage and read this thing with own eyes, at some point.

asciilifeform: how about iterators? they are all explicit? million temp vars?

asciilifeform: so what do the data structures look like ?

asciilifeform: mircea_popescu, diana_coman : so you folx wrote own 'boost'-like horror? fwiw most games firms did, in the golden olden days. my brother's co, for instance, did.

asciilifeform: brings own set of problems. it is where monstrous thigs such as 'boost' came from - lack of cpp11

asciilifeform: because cpp11 is how folx typically end up reluctantly grunting in the stake of gcc5

asciilifeform: btw while we're on this subj, does eulora eschew cpp11?

asciilifeform: it will.

asciilifeform: 'was this linus-key or linus-flipolade key'

asciilifeform: well here's one typical scenario, i find a pgp-signed historic patch (e.g., linus) and want to see what vintage key etc

asciilifeform: deedbot key getter dun work in heathens, does it..?

asciilifeform: it's a total replacement (if slow) for sks.

asciilifeform: most of the time i paste in a key from somewhere, there it is, from april.

asciilifeform: because it is what 'phuctor as keyserver' stands on, also

asciilifeform: there is 1 serious reason why gotta check for existing key/fp:

asciilifeform: the one obvious optimization i was considering was to avoid all dupe checks on key submit and simply deduplicate prior to each bernsteining. but this has serious cost in ui consistency, no more could submitters expect to see a result that is guaranteed to make sense after they submit.

asciilifeform: when you do not know that you oughta restore from backup

asciilifeform: problem is ~silent~ data loss.

asciilifeform: jurov: there is always 'possibility of data loss', machine could be stolen (as it once was!) or burn down

asciilifeform: writecache, on other hand, is a major Do Not Want here, for reasons described above

asciilifeform: mircea_popescu: linux by default uses all spare ram as disk readcache

asciilifeform: jurov: fs does have the journal

asciilifeform: the thing is a 1,001-layer shit sandwich

asciilifeform: Framedragger: may as well run whole thing off a ramdisk then

asciilifeform: i'm not convinced that they are separable.

asciilifeform: moreover, it's either ~completely-readable~ or 'dragons in a cave'.

asciilifeform: gnupatch, as i warned long ago, MUST die.

asciilifeform: ^^

asciilifeform: they must've moved some king-sized cockroach sofa.

asciilifeform: mircea_popescu: tbh i had a 'what the hell is all this' reaction to reading ben_vulpes and phf vtron problemz

asciilifeform: Framedragger: no losses plox.

asciilifeform: mircea_popescu: that's a straight (and spam-encrusted) translation of an english article that was posted here ('against hardforks' iirc) a while back.

asciilifeform: but could again if i gave it a multi-GB writecache

asciilifeform: Framedragger: well it doesn't lose work nao.

asciilifeform: mircea_popescu -- switched hosts, i -- slowly, painfully, rewrote the thing...

asciilifeform: it was ~immediately~ and ~permanently~ afflicted by 'mysterious' reboots

asciilifeform: Framedragger was not yet here, but phuctor-1 was quite vulnerable to pulled mains cord ( would lose weeks of work ) and as soon as this became publicly known,

asciilifeform: the machine isn't at my house and i have no control over the mains supply.

asciilifeform: Framedragger: nope

asciilifeform: (parcels are eaten by script that, presently, has no convenient pause button. and, because unix was dropped as a baby, suspending a process doesn't yield locks, so ~that~ doesn't safely work)

asciilifeform: that means i won't be trying it for couplea weeks. i don't restart db until a current parcel is through submitting.

asciilifeform: i'ma try it soon. ☟︎

asciilifeform: the 'do we haves' could benefit from bigger read cache

asciilifeform: and no, no sorts there

asciilifeform: Framedragger: as per http://btcbase.org/log/2016-11-19#1570951 ☝︎

asciilifeform: Framedragger: they aren't only inserts, every key turns into half a dozen to a dozen queries interleaved with inserts

asciilifeform: guten morgen mircea_popescu !

asciilifeform: correct

asciilifeform: then -- static html phuctor.

asciilifeform: now if only i had a pill against http://btcbase.org/log/2016-07-18#1505027 ☝︎

asciilifeform: *returning

asciilifeform: i absolutely can't have a db req returnig before disk is written.

asciilifeform: because nobody cancelled physical reality, write-caching means vulnerability to mains yanking

asciilifeform: and what effect will this have on the consequences of yanked mains cord