log☇︎
102600+ entries in 0.061s
mircea_popescu: it seems to me ridiculous to a degree bordering on infantilism that it is "impossible" to get the data out after being so complexly massaged into utility ; but be that as it may, let phuctor run and report on its website, the interested will try and sift through whatever it publishes on their own time. ☟︎
asciilifeform: results will still be browsable on the www
asciilifeform: y'know, asciilifeform won't cry if mircea_popescu wants to dispense with the feed, also
asciilifeform: didnt think so
mircea_popescu: well certainly the whole "get expensive phuctor machine" thing wasn't on nsa books so that it works for three days and then waits forever.
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.
mircea_popescu: anyway. so what's the situation here, phuctor currently going through Framedragger 's and jurov 's set preparing ; reporting of results here disrupted until this is sorted out ?
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.
mircea_popescu: you have to write to it.
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 )
mircea_popescu: you still have to create and feed a new table.
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.
mircea_popescu: asciilifeform, did you just say "anyone who wants to do this must do it in the way it wasn't specified because i'm not making the principal element everything rests on" ?
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 ) ☟︎
mircea_popescu: well, you'd be running the rss script yourself. ever ran code you didn't write before ?
asciilifeform: and how is anyone to get access to said table ?
mircea_popescu: redundancy makes no difference here. they'll still only be reported once.
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
mircea_popescu: asciilifeform, how about this : you edit your current rss script, so that ~instead~ of what it does, it plunks its results down in a new table ; and someone (tm) writes you the py script to read that new table and put out usable rss for deedbot. how about that ?
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: mircea_popescu: this is correct. but there are so few factors known presently, that all operations on factors are ~O(1)
mircea_popescu: you understand the other algo would be about 100x less machine work ?
jurov: asciilifeform: at this point just add insert into the new table and leave its reading to mod6 or anyone who has irc bot?
a111: Logged on 2018-05-04 15:00 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
mircea_popescu: how do they go into rss if it writes ?
asciilifeform: and if it writes, they go into rss. and if feed is enabled, they appear here.
asciilifeform: right now it is the ~only~ thing that writes to factors table.
mircea_popescu: im unsure why phuctor would have to be stalled at all. you mean the reporting here of popped moduli ?
mircea_popescu: for some reason it seems trivial to me, but anyways.
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.
mircea_popescu: and yes, the reason it has separate table is so it doesn't mess up your locks on the main one.
mircea_popescu: 3. this will introduce no further state or anything else in the original process ; it just happily spits its output at whatever rate it wishes.
jurov: with new table it'll be slow, too?
mircea_popescu: 2. the proposed modification is to create a new table, of columns A B C D timestamp. this is to be indexed on whichever A B C D is the modulus. the proposed use is to have a process sort this table by unique index where timestamp = "" ; report ONE such item, and update ALL the lines with that modulus with current timestamp IF any only IF the highest timestamp found in the table is 900 seconds behind current timestamp.
asciilifeform: i deliberately crafted the thing to enable dirty reads one day, whenever i find out how to obtain them at all
jurov: asciilifeform: can't add timestamp column to gpgkeys "lastpopped" that gets updated?
asciilifeform begins to consider
mircea_popescu: 1. consider a process which produces tabular data, in the shape of lines of A B C D columns.
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
mircea_popescu: actually, maybe this'll help, let me formalize this for you :
mircea_popescu: asciilifeform, it generates its tick, that's what the whole "ave it add the timestamp whenever it reads ; push out one once the timestamp is old enough, and write the new timestamp next to it." is all about.
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.
mircea_popescu: however, he'd have to run a script he doesn't actually understand.
mircea_popescu: mod6, what i was going to propose is for someone to write his rss python script and needed queries.
mod6: This to me, seems like the most painless way.
mod6: What if someone pitched in a hand to make a new bot for ya, so like Mr. P. said, you just have own channel. Then it can just burp as it is necessary.
asciilifeform: mircea_popescu: this is pretty much your 'cleaned air filter of lada' story from c3
mircea_popescu: much in the vein proper smoked rib bean stu requires allspice.
mircea_popescu: well, the proper statement here isn't that "fixing db will be to my grief" ; the proper statement is that "fixing db, while a massive improvement to the $item, has the unfortunate drawback of requiring some trims i'm ill equipped to handle / have to send for across town"
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.
mircea_popescu: but, i confess i absolutely do not follow the logic here. so, making a new table, and a py script to update it and print it as described above, unbounded ammount of sweat, months of work ?
asciilifeform: ( but this is pure conjecture. )
asciilifeform: based on earlier github run, i suspect that it's good for maybe a dozen ticks.
mircea_popescu: asciilifeform, once the Framedragger fodder runs out there's the jurov fodder.
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. )
mircea_popescu: asciilifeform, yet another approach would be to do what ben_vulpes did, make a channel for it ?
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: 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.
mircea_popescu: yes, but only one need be reported, is the idea.
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 )
mircea_popescu: merely addressing the latter may well get you out of addressing the former for a while to come.
mircea_popescu: there's in fact two separate problems. one of them is that large walls of robot generated text are hostile to human habitation. the OTHER however, is that the news value of the first factor of a modulus exceeds the news value of all subsequent factors summed by degrees of magnitude, because of the 0, 1 infinity rule.
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: nope, nothing is separate or separable, if the rss generator has state, that's a whole new table and a 2x-as-long total program
asciilifeform: i sat down to write it yesterday and got mired in swamp.
mircea_popescu: index by modulus so you only report each once and there you go.
asciilifeform: mircea_popescu: this is 100x more state complexity than i have now, is the point
mircea_popescu: have it add the timestamp whenever it reads ; push out one once the timestamp is old enough, and write the new timestamp next to it.
asciilifeform: jurov: observe that a factor being found can potentially pop one key, ten, or a thousand.
mircea_popescu: asciilifeform, you could simply push that into a table and then have a script read from it to populate the rss
asciilifeform: hich forms the rss output.
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 ☟︎
mircea_popescu: in my country they go "oac", which admittedly makes 0 sense. (in fact, my country is famous in the harem for having apparently never heard any of the animal sounds it purportedly renders.)
asciilifeform: the greeks knew what they were doing.
asciilifeform: http://btcbase.org/log/2018-05-04#1808872 << only the literate frogs!11 ☝︎
mircea_popescu: so when "educators" ie child molesters claim they produce "familiarity" in children with so and so, this is PRECISELY what they mean.
diana_coman is not laughing as she met the belief irl...
mircea_popescu: (laugh if you will, but this is EXACTLY what they believe, http://trilema.com/wp-content/uploads/2011/11/arsdigita-greenspun.html etc).
diana_coman: well of course; once that stumbling block, annoying and unfair and barrier to entry and everything that is bad - aka comprehension is removed, all is plain sailing; no surprise there
mircea_popescu: (laugh if you will, however a) this is EXACTLY what alphabet imagines "artificial intelligence" means and b) this is EXACTLY what they teach them to do in school these days. so... joke's on you, mr barbarian bereft of bayesian behehehnologies.)
mircea_popescu: sort -u and then just read the histogram, see.
mircea_popescu: reading can go surprisingly fast if it doesn't make much difference what order the words come in.
diana_coman: mircea_popescu, hmmm, I had in mind an even faster she-reader but I can't seem to find ref; that works too I suppose although I suspect the fromdeedbot guy "read" even faster
mod6: Mornin' TMSR~
mircea_popescu: i'm still not certain he wasn't telling the truth even.
a111: Logged on 2018-05-04 12:49 diana_coman: asciilifeform, I suspect he "read" them like that tits-girl: in one night he "read" them all, what
mircea_popescu: item promises getting out of having to do some thinking ; the ill equipped towards humanity find it indistinguishable from refined sugar.