asciilifeform: BingoBoingo: do you dine on guinea pig with the peruana ?
asciilifeform: mircea_popescu: possibly. i can think of a scenario where your bufferizer could become necessary again.
asciilifeform: lobbes: again, we are discussing permanent (and quite complex) solutions to a temporary problem. after current batch, it'll be 1-2 pops a week if we're lucky.
asciilifeform: but if someone stands up to write something for me to debug -- i will 1) say 'thank you' 2) debug it.
asciilifeform: i am not averse to the pain of debugging.
asciilifeform: situation is that parcels 11 and 12 already added to db; ( 13 would take about 6hrs to swallow , i held off on feeding any moar until we have this thread ) ; werker cron job is currently off, if i switch it on, 45min later we get 1k lines in log ( or alternatively we switch off feed and sleep through 1k pops , take yer pick ) or i go and write a ~new phuctor and nfi when finish.
asciilifeform: asciilifeform does not say this to raise mircea_popescu's blood pressure, but strictly out of truth.☟︎
asciilifeform: yes, i can write this program. but no i do not know how long it'll take. and yes it would be to the detriment of other projects.
asciilifeform: alternatively you then are asking for entirely different program, that cannot be easily made out of the existing db.
asciilifeform: my writer writes to the factors table. this ought to suffice.
asciilifeform: if this is so -- then it should be possible to make it in a separate process that simply reads from db ( can write to own table, even, if it wants, so long as i do not have to know about it )
asciilifeform: mircea_popescu: i simply went with your hypothesis, which is that the desired feature is truly implementable independently from the rest of the proggy.
asciilifeform: however it must not interfere with the function of the existing code, nor require werker to do anything other than what it presently does, which is to test ALL factors ( bernestein returns ALL factors EVERY time it runs ) against 'factors' table, and , if novel , add factor to it.
asciilifeform: if the volunteered proggy makes sense to me, i will emplace it on dulap and say 'thank you'
asciilifeform: anyone who wants to volunteer to write this, can use the db snapshot i previously published ( it contains, naturally, the schema. ) to test, remove some entries from factors table, then add'em back in ( ideally several dozen at a time )☟︎
asciilifeform: and how is anyone to get access to said table ?
asciilifeform: the whole notion of 'put into a table' implies ~100% of the requested functionality to be already present
asciilifeform: possibly mircea_popescu does not yet grasp how it works ? if you run it today 1000 times, it will return exactly the same 20 items 1000 times
asciilifeform: the actual number of factors known has not increased at anything like the rate of popped moduli, on account of most of said factors being from the debian pool
asciilifeform: ( and ffa correspondingly delay by a new month ... )
asciilifeform: if you can live with stalling phuctor for , potentially, whole month -- we can have it. otherwise not.
asciilifeform: mircea_popescu: this is the correct algo, and i drew it on own chalkboard last night, but my entire point is that i do not know with confidence how long it will take to implement and debug.
asciilifeform: i deliberately crafted the thing to enable dirty reads one day, whenever i find out how to obtain them at all
asciilifeform: jurov: no, massive slowdown, it's a reading-strictly process
asciilifeform: there is no state and thereby no possibility of a wedge.
asciilifeform: mircea_popescu: unless i catastrophically misunderstand own proggy, this 'tick' is an illusion, it is same db query every time, but returns different things, but at same time proggy does not keep any state to know that they are different from prev query
asciilifeform: the 'newness' presently is determined 100% by the rss ~receiver~
asciilifeform: mod6: where would you plug it in ? there is no 'new tick' event.
asciilifeform: mircea_popescu: this is pretty much your 'cleaned air filter of lada' story from c3
asciilifeform: and observe, i put on heaviest gas mask , and sat with postgres docs for week+, and nao reward 'go and write another 1000ln of postgresolade'
asciilifeform: wwwism is foreign and repulsive to asciilifeform , and it was to his grief that he ever stepped into it.
asciilifeform: the utter undebuggability and nonfitting-in-asciilifeform's-head of the pertinent components, results in this.
asciilifeform: based on earlier github run, i suspect that it's good for maybe a dozen ticks.
asciilifeform: i do not have a deedbot to throw into a dedicated channel, nor do i have a month in which to write a phuctor-compatible channel-talker.
asciilifeform: once the Framedragger fodder runs out.
asciilifeform: mircea_popescu: see, it will spit out another thou or 2, and then it'll be oncie-twocie per week.
asciilifeform: ( i cannot with good conscience say how many weeks it will take to do this. )
asciilifeform: we're talking about an unbounded amount of sweat
asciilifeform: honestly i had nfi that fixing the db would be to my grief.
asciilifeform: still requires a stateful machine in a place where i currently have none.
asciilifeform: but i can definitely see the merits of 'only publish 1st factor'. problem is that this is even ~more~ complicated to implement than the earlier scheme.
asciilifeform: mircea_popescu: actually for quite some time i've had it so that it finds both factors in 1 day ( when we're dealing with a proper 2-large-primes mod, rather than random liquishit )
asciilifeform: so i made no fundamental provision for it.
asciilifeform: see,it did not occur to asciilifeform even in bad dreams that anyone would ever ask for the thing to be rate-limited !
asciilifeform: jurov: the way it works is, every time /rss pg is generated , we go select mods from factors order by whenfound desc limit N ( n is 20 currently ) ; call this M, it is a list of moduli affected by that factor being known. afterwards , ~each~ of these lists is tested against the set of ~gpg keys~ , in the shape of select * from gpgkeys where [the list from earlier] && mods , and this yields up a list of most-recently-popped ~keys~, w☟︎
asciilifeform: the greeks knew what they were doing.
