ossabot: Logged on 2020-03-10 13:38:48 jfw: mp_en_viaje: does the idiot list include me this time? I could try to be more mindful of when a discussion should be moved or started here
mp_en_viaje: there ~is~ of course substantial cost involved in i dunno, keeping a capitalized company on the books while alf derps about re-doing the same mistakes on the chickenfeed he's found in his couch cushions. there's similarily a substantial cost involved in maintaining all these trilema herramientas
mp_en_viaje: this is of course my problem ; you can do it elsewhere cheaper / better / whatever, i'm the last dood to get in the way of any such a thing.
ossabot: Logged on 2020-03-10 14:02:20 jfw: mp_en_viaje: is that all clear?
ossabot: Logged on 2020-03-10 13:51:09 diana_coman: mp_en_viaje: to my mind there wasn't anything new/unknown/controversial in there really; (or I'd have moved it to #t earlier anyway).
mp_en_viaje: lobbes, so you want a sample of the logstory file ? lesee here
lobbes: mp_en_viaje, yeah that'd be great. Ty!
mp_en_viaje: lobbes, im digging through the stuff here, because i suspect there might;ve been more to it all than just that, so a sec
lobbes: mp_en_viaje, yeah that was the discussion. I think the script that ended up working for you was in
this comment mp_en_viaje: but the point is : the whole logstory thing was simply me wranglin gwith the xchat historical format most of the early logs were in.
mp_en_viaje: there's entirely no point in reproducing that.
lobbes: mp_en_viaje, ahh okay.
mp_en_viaje: now, what you really want is a look at say log8.txt, which is what in the end was finally used,
lobbes: mp_en_viaje, hm, I can't find a reference to a log8.txt in that discussion, but if that was what you used for your input file then yeah definitely I'd want to see that
mp_en_viaje: the ~problem~ is though that these are 1-logday-per-line humongo files. can you even meaningfully process it ?
lobbes: mp_en_viaje, ah I see what you mean. Yeah I guess that may be a bit of a pain trying to produce something in that format. Hm
mp_en_viaje: i for one'd have expected the structural definition in the comments'd be more useful than the actual dump file ; but in any case, there's more problems even higher up.
mp_en_viaje: specifically, until we have the process such that the bot actually produces logs, reliably, for each day, it makes 0 sense imo to even start this discussion. because what, so we do it YEY AGAIN, and then there's yet another gap once we're done ?
lobbes: mp_en_viaje, this is a point. You mean we ought to just get the bot up and producing logs first and worry about the history later?
mp_en_viaje: omfg, the coffee in this country. idiot germans come in and buy all the best sorts anyone can be arsed to sell them ; then you go to germany and can't have a decent cup of coffee. i just can't set it down.
mp_en_viaje: lobbes, it seems unavoidable, otherwise we'll just be doing this chasing gaps forver, like achilles.
lobbes: mp_en_viaje, agreed (btw if I ever do make it to CR real coffee will be one of the first things I try)
lobbes: I could bring it in now even, it just is logging to my test site
deedbot: pizdi voiced for 30 minutes.
lobbes: command is '!y' for the time-being
pizdi: lobbes: I am MP-WP bot version 598170.
mp_en_viaje: lobbes, did you do a buncha testing on this then ? all sorta lines, changes in say topic, etc ?
lobbes: I just incremented the old one from the stanlogger
lobbes: mp_en_viaje: I don't think it'll record line changes. Though I honestly did not test if it would break it
mp_en_viaje: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mp_en_viaje: ----- 20:00 ----- << oh it's still doing that thing, iirc we wanted it out eventually.
lobbes: ah shit, I must've missed that. Well easy enough to remove in any case
mp_en_viaje: honestly, the stuff pizdi's dumping in the test blog is perfectly fine. why can't you just dump the missing logs into her ?
lobbes: that's what I tried to do last time; ended up faffing about. I'm a little hesitant to try again but I guess I'll need to at some point
mp_en_viaje re-reads the init of this convo to figure out wth the problem was
lobbes: it seemed simple: instead of eating IRC lines live just eat lines from Postgres. But you know, looking back I used way too many middleman steps
ossabot: Logged on 2020-03-10 19:08:58 lobbes: Instead, I figure why don't I just cut out 2,3,4,5 and instead I just alter my 1) to pull logs from my Postgres database in the same format of your input into your backfill process (which has already been
proven to function to spec)?
lobbes: yeah, I was misunderstanding your process there
mp_en_viaje: now that said, i'm still thinking about how the fuck to get mp-wp working on two machines best.
mp_en_viaje: technically there exists mysql "federated" tables ; but everyone seems to hate them. prolly for no reason.
mp_en_viaje: on the other hand there exists the obvious "have logs category on trilema.net, have trilema.net use trilema.com for everything (including comment post say). which is about as derpy as it sounds.
mp_en_viaje: there could be a sync script, but then how often does it run
lobbes: hm, I am not familiar with federated tables myself. I'd need to look into them a bit.
lobbes: as for the sync script, yeah that would be interesting. As for the frequency does mysql do triggers on database changes?
mp_en_viaje: honestly i think what i'll go for will be : (using trilema.com for current trilema and trilema.net for pizdi's box), hve a mysql server run on both, have t.com update both rather than just its own, and have it read the day's logs at some point tomorrow. this way people can use t.net for any purpose except write a comment.
mp_en_viaje: perhaps easier said than done ; but we see
lobbes: mp_en_viaje: okay, sounds like a plan then. So, I guess for my part I'll go back and see what I can do about a sane history-backfill process.
lobbes: k. And I guess just let me know whenever / however you wanna try to get that t.com > t.net update process going. I'll try to find time where needed
ericbot: Logged on 2020-03-11 01:03:20 lobbes: I just incremented the old one from the stanlogger
lobbes: mp_en_viaje, roger that
trinque: dorion: yes, I haven't had time to complete the final post, but last I checked y'all were pretty opposed to using busybox-only for the userland.
trinque: so where are we at with that?
trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
trinque: I'll point out again for the logs that my picking busybox wasn't just "whatever, it's small, and it's all there"
trinque: it's that we can cleave shit out of busybox source permanently trivially by using the config flags.
trinque: so it's not only the smallest candidate, but it can be miles smaller still
jfw: trinque: I'm also tardy on jumping back into the OS fray, for one thing my wallet project has dragged out way longer than I naively expected, but I look forward to doing so shortly. But in hopes of advancing the discussion a bit: is there a particular merit to busybox-1.31.1 ? For all I know it's an entirely different thing from the older one I've been looking at and we'll need some common basis
jfw: for what we're talking about.
jfw: that's 1). 2) what do you mean by "busybox-only" - because far as I know you can't possibly mean exactly that, it doesn't have an mkfs or make for example, let alone a compiler. Do you mean, "system which selects components outside busybox only if busybox $version does not contain them"? I'll note that busybox is an amalgam of code from a variety of sources and, ahem, "Adjusted by so many folks,
jfw: it's impossible to keep track" to quote its init.c. One thing I take from this is one's not likely to get a good sense of the code quality of a given part from a random sampling of the overall tree.
ossabot: Logged on 2020-03-11 02:01:59 trinque: dorion: yes, I haven't had time to complete the final post, but last I checked y'all were pretty opposed to using busybox-only for the userland.
dorion: 1 was out of ignorance and it was
conceded MAKEDEV can be dropped.
ossabot: (trinque) 2020-01-24 jfw: trinque: I was ignorant of mdev, looks like just the thing!
dorion: 2 was out of poorly documented dissatisfaction with bb ash, yet he
said, "perhaps his pdksh can be of use."
dorion: jfw can correct me if I'm wrong but I don't think he knew busybox includes
runit. since he was already used to using daemontools and daemontools is the predecessor to runit anyways he went with that.
dorion: please correct me if I'm missing something, but how do you draw "pretty opposed" from the above ?
jfw: I haven't actually tried mdev so I'm not quite at "makedev can be dropped" but I'm certainly open to it.
jfw: If we're adding runit to the mix on the busybox side, then it becomes fair to compare their 800+ LoC init.c to my 30-line one.
ossabot: Logged on 2020-03-11 02:02:05 trinque: so where are we at with that?
ossabot: Logged on 2020-03-11 02:03:07 trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
dorion: if you've made progress on the selecting and organizing into a source tree, why not be satisfied with publishing that and getting feedback ?
ossabot: Logged on 2020-03-11 02:03:07 trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
dorion: ^^ mp_en_viaje jfw bvt spyked diana_coman and any other parties interested in tmsr os ^^