Hide Idle (>14 d.) Chans
← 2020-01-04 | 2020-01-06 → ↓
00:28 lobbes http://younghands.club/2019/12/24/ejb-plan-week-2-jan-2-jan-5/#comment-261 << diana_coman: I've not really ever tested in an automated fashion before. I just kinda manually try to break things as I go (and really even then I'm not too organized in exactly what to be testing for).
00:29 lobbes diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
~ 1 hours 38 minutes ~
02:07 whaack diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
02:14 whaack actually i may be able to use asdf:load-system instead, i see that in trinque's ircbot
02:14 whaack err in trinque's ircbot USAGE file
~ 31 minutes ~
02:46 whaack trinque: I think I may understand this if you never got around to it. The thread that normally calls ircbot-reconnect is the ircbot-ping-thread. However the ping-thread commits suicide because ircbot-disconnect calls (sb-thread:terminate-thread (ircbot-ping-thread bot)) . So when the ping thread calls ircbot-reconnect after calling ircbot-disconnect it never gets to the ir
02:46 whaack cbot-connect or ircbot-connect-thread. If you test ircbot-reconnect (in the repl or such) you will not see the bug because then ircbot-reconnect is being run from a different thread.
02:46 ossabot (trilema) 2019-02-07 trinque: now that we're at something of a cuntoo interude while folks are testing, I'll find some time to figure out what deedbot gags on time to time re: reconnecting
~ 3 hours 47 minutes ~
06:33 whaack diana_coman: EOD Report: I spent another long day on TheFleet and published my article. I said I would publish a plan for building my computer but instead all I had time for was to publish my disassembling notes. I also said I would take inventory of the parts but I did not yet go through all the cables.
06:33 ossabot Logged on 2020-01-02 16:22:49 whaack: I will do that now and publish a plan for building my computer as my article for tomorrow and otherwise get back to working on TheFleet for now.
06:37 whaack I should have my review / plan for the week done by tomorrow. But I am not 100% sure I will, because of my mother's arrival and everything having been pushed from me trying to get TheFleet running.
~ 1 hours 34 minutes ~
08:12 diana_coman http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014609 - how about Sundays 7:30pm utc ?
08:12 ossabot Logged on 2020-01-04 20:38:45 lobbes: diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
08:12 diana_coman http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014610 - ahahaha, the beauty of lisp, right? lmao.
08:12 ossabot Logged on 2020-01-04 22:17:17 whaack: diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
08:15 diana_coman whaack: in any case, 7 will have to do for the pilot test, so at least there's that.
08:20 diana_coman billymg: since you've been working on mp-wp anyway, what would your thoughts be on a mp-wp plugin for vpatches display+review? As hinted a bit earlier around here.
08:20 ossabot Logged on 2019-12-29 12:01:05 trinque: incidentally this is a tool I want, a commentary tool for vpatches.
~ 7 hours 6 minutes ~
15:27 whaack diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014610 - ahahaha, the beauty of lisp, right? lmao. << to see the beauty you just need Lisp Memory Usage Positivity
15:27 ossabot Logged on 2020-01-04 22:17:17 whaack: diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
~ 21 minutes ~
15:49 lobbes http://logs.ericbenevides.com/log/ossasepia/2020-01-05#1014632 << sounds good to me. Thank you!
15:49 ericbot Logged on 2020-01-05 08:15:57 diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014609 - how about Sundays 7:30pm utc ?
15:49 ossabot Logged on 2020-01-04 20:38:45 lobbes: diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
15:51 whaack diana_coman: I connected to 7 more networks on another VM.
15:55 whaack a few were banned / dropped so the total connected right now is ~9
~ 28 minutes ~
16:24 billymg diana_coman: yeah, i think that would be great to have. i'm imagining something like phf's patch viewer with the added ability to add inline comments
16:27 billymg btw, whaack: http://logs.ossasepia.com/log/ossasepia/2019-11-07#1009221 << finally did this
16:27 ossabot Logged on 2019-11-07 11:15:58 whaack: billymg: you should put an avatar on billymg.com
~ 19 minutes ~
16:47 billymg diana_coman: in mp-wp, i could see the addition of a new post type and comment type. let's say post_type="vpatch", and this is selectable from within the mp-wp UI when creating a new post. if this post type is selected, the user gets an additional <textarea> where they can paste the full contents of a vpatch. this text is stored in a new column in the posts table, e.g. post_code. when rendered, post_content will
16:47 billymg be rendered first, followed by post_code (which will be formatted similar to the existing patch viewer)
16:49 billymg alternatively, instead of pasting the vpatch contents into a <textarea>, it could prompt the user to upload a .vpatch file, store it in a sensible (organized) directory, and store a reference to the file in a new column on posts, e.g. post_code_filepath. the rendering would be the same
16:51 billymg i personally like the latter because it would result in a cleaner UI and doesn't require copy/pasting a vpatch into a text area (which just seems cumbersome). also, depending on the size of some patches, this avoids blowing up the mysql database
16:53 billymg line-level commenting would require a minimal amount of JS (just enough to insert an inline comment box at a given line number)
16:54 billymg less clear is how revisions after a discussion would be handled. perhaps just a new published article after the author addressed all of the comments in the first round
16:56 billymg and this is just off the top of my head, i figure after some discussion here i could spend some time publishing a formal spec for the feature (for review) before starting any code
17:00 diana_coman billymg: there might be 2 parts to it and not even necessarily tied together really
17:01 diana_coman the upload vpatch + store in sensible place is really a script that can even be outside mp-wp, not much to do with the mp-wp itself
17:01 diana_coman for the text/article itself though, why not make it simply a different type of tag? e.g. like one has (()) for footnotes, use [[]] or something else for "this is vpatch content"?
17:02 diana_coman I think the whole viewing + reviewing can happen perfectly fine on the existing blog article structure, can't it?
17:02 diana_coman all it needs is this new tag+corresponding plugin to do the formatting (perhaps similar to that vpatch viewer, sure)
17:03 diana_coman and then the comments to the post can simply reference that
17:03 diana_coman if/when there's a new version of the vpatch, it's up to whoever *signs* the new vpatch to publish it as a new article, no?
17:04 diana_coman I wouldn't really go otherwise much along the slippery path of "automate a vpatch's lifecycle" because of the fundamental of V that *reading* is authorship of code (and that can't be automated really).
17:06 diana_coman billymg: re inline comments - would it be possible for the plugin to update the article's content to provide perhaps inline links to the relevant comments or something of this sort?
17:07 billymg that makes sense. my reason for not suggesting the route of [[]] or similar was out of consideration for very large vpatches
17:07 diana_coman but tbh I think this is one of the situations where it's perhaps better to wait and see what is actually *needed* because it's unclear to me that at this stage, before any serious use, one can fully tell really
17:07 billymg i think [[]] works well for snippets of code, but not entire thousand+ line vpatches
17:07 diana_coman ie you risk overspecifying/making choices too quickly/before knowing the problem really
17:08 diana_coman billymg: very large vpatches are a bit of trouble in themselves
17:08 diana_coman I know we still end up with those but ...they *are* trouble so I wouldn't base the viewer on them.
17:08 diana_coman because also, who the fuck reads thousand+ line vpatch?
17:08 diana_coman maybe it's for the better if this even *forces* one to split the damned thing.
17:09 diana_coman billymg: also, why wouldn't it work well anyway? not like there aren't otherwise articles of thousands of words published fine with mp-wp?
17:10 diana_coman trinque: would you care to add your view/ideas on this thread?
17:11 billymg diana_coman: >billymg: also, why wouldn't it work well anyway? not like there aren't otherwise articles of thousands of words published fine with mp-wp? << yes, true
17:12 billymg re: uploading inside mp-wp, i think it was the concept of code shelves that brought me to this (along with the idea of separating code from article content)
17:13 billymg as in, if a code shelf is a concept inside mp-wp, then that justifies mp-wp having some features for managing that shelf
17:13 diana_coman billymg: on one hand I can see the appeal of having mp-wp basically maintain the code shelf as simply an automatically updated page with all vpatch+sigs uploaded, sure
17:14 diana_coman but otoh why mix it with the discussion /review of code (since perhaps I even want to discuss some vpatch *before*/without adding it yet to my shelf for instance?)
17:15 diana_coman and also: what's the separation you see between code and article content? the way I see it, for some code review, the code may very well *be* the article content, no? and the reviews are the comments, naturally.
17:15 diana_coman billymg: you might have made for yourself 2 pieces of work ([[]] + shelf mgm) instead of 1, heh.
17:20 diana_coman the additional potential trouble that I see if you go the route of having [[]] take directly the vpatch from disk rather than its text is that any annotations you add inline to it would then be separated from the text?
17:21 diana_coman aka you end up with that situation where the content of your article is partially in db and partially on disk; it's already rather annoying that this is the case to some extent for wp (eg categories iirc and at any rate, images...)
17:21 diana_coman not sure I see the case for extending that sort of situation.
17:25 diana_coman and uhm, I'd much, much rather have *no* JS whatsoever.
17:30 billymg i didn't mean that publishing an article would automatically add the vpatch to the code shelf, only that the concept of a code shelf hosted in mp-wp makes mp-wp somewhat of a code hosting tool as well. and since mp-wp is being used to host the code, it follows that this would be a logical place to discuss/review the code as well (not in the shelf, but elsewhere in mp-wp)
17:32 diana_coman billymg: sure.
17:33 * billymg is thinking about the other comments...
17:33 diana_coman no rush.
17:39 billymg ok, annotations from the author is something i didn't factor in. this would be much more complicated than necessary if the vpatch is stored on disk (UI would need to render the vpatch after upload and allow the user to annotate before publishing, ugh)
17:42 billymg re: stored in [[]] in post_content vs. stored in post_vpatch_code, i think with footnotes they are always tied to the article that contains them. vpatches are more portable. it makes sense to be able to display them inline in an article (for discussion/annotation), but they can also stand alone (be downloaded by a reader, be moved/promoted to the code shelf when ready)
17:44 billymg it gives more flexibility for later display or retrieval of all the code in ones mp-wp, rather than having to parse post_content looking for [[]]
17:45 diana_coman billymg: the .vpatch file + the .sig file surely need of course to be standalone files too, there was no idea of NOT having them separate too; just NOT mixing the two at all: there's .vpatch files and those are indexed by the code shelf (which is singular because it's meant as one single entry point) and then there is - to the extent the author makes/wants it- a bunch of articles that discuss vpatch contents (and this can be ...
17:45 diana_coman ... anything,even just parts of a vpatch at the end of the day, even not yet signed vpatch etc)
17:46 diana_coman so certainly not parsing post_content, no.
17:46 billymg re: no javascript. yes, inline commenting could be done in the regular comment box if the commenter adds some annotation, e.g. ">>path/to/file.php#L22 comment text follows..."
17:46 billymg and then when rendered that comment is displayed at the correct file/line number
17:46 diana_coman billymg: perhaps the [[]] can simply add html hooks for each line and then commenters can use those, right?
17:48 diana_coman my potential suggestion - but more of an idea for laters, if needed - was to have it work backwards as well ie when a comment is approved, to collect the ref to any line-html hook and then update to add there a link to the comment; it might be overkill, not needed anyway, I don't really know atm, just throwing it out there.
17:49 billymg what do you mean by an html hook?
17:52 diana_coman billymg: I meant an anchor for each line of code; but come to think of it, there's in principle already the selection mechanism, might even be enough, hm.
17:54 billymg ah, no, the anchor makes sense, e.g. <a href="#L22"> (the server-side selection mechanism still relies on a #select anchor to scroll to the selection)
17:55 diana_coman billymg: yes, exactly.
17:55 billymg i was thinking that file name would need to be encoded in the anchor as well, but i see now that in the existing patch viewer the line numbers are cumulative
17:55 billymg not per file
17:56 billymg typing "#L22" at the beginning of a comment to make it render inline doesn't seem too bad
17:56 diana_coman yeah, no need for more than that really; and it has this advantage that I see that one can in principle update the text too to list there for each line the links to comments that refer it (basically the non-js automated inline annotations if you want)
17:56 diana_coman something like that; if it turns out it's useful.
17:57 diana_coman I need to go now but I'll be back in ~1.5 hours or so.
17:57 billymg ok, i'll think on this some more, and watch for additional comments from others
17:57 diana_coman lobbes: btw, if you publish your plan, we can start with that later today.
17:58 diana_coman billymg: sure and if you publish some plan, I'll certainly read it.
17:58 * diana_coman will bbl
~ 1 hours 34 minutes ~
19:32 lobbes diana_coman: sounds good. I just published the plan now, should be coming through feedbot soon. I'll brb in ~7 mins
19:40 diana_coman lobbes: read it; what happened to the mp-wp polish idea as it seems entirely dropped?
19:43 lobbes diana_coman: well I'm still going to work through that today. Probably another 4 hours or so dedicated to it left
19:44 diana_coman lobbes: ah, so you aim to finish it today then?
19:44 lobbes diana_coman: I aim to at least get it up and running on the 'prod server' along with some rudimentary manual testing of bits
19:44 lobbes by the end of today, that is
19:45 diana_coman ok, just don't let it drop afterwards in that forever-started-on state
19:46 diana_coman taking the topics in order, there was the procrastination question - did you figure out anything re why?
19:46 lobbes diana_coman: this is a good point on the dropping. I will add it to my "Things that I need to think on" items in this week's plan just in case there is spillover
19:47 feedbot http://younghands.club/2020/01/05/ejb-plan-week-3-jan-6-jan-12/ << Young Hands Club -- ejb plan: week 3 (Jan 6 - Jan 12)
19:47 lobbes as for the procrastination q, the best thing I could up with besides "I'm just being lazy" is that it is some sort of instant gratification vs delayed gratification thing
19:49 diana_coman lobbes: hm; do/did you ever have any project/something you actually found it easy /fast to start on?
19:52 lobbes diana_coman: if it is something that I keep 'loaded in my head' already then I usually have no issue picking it up / putting it down day-to-day. If that makes sense.
19:53 diana_coman lobbes: it covers one part - it is easier to start on and therefore you start, yes.
19:54 diana_coman lobbes: do you procrastinate the same on relatively simpler tasks? because it starts sounding possibly related to the "too big jump in one step" simply.
19:55 lobbes diana_coman: it is true that I don't really procrastinate on small things that I can get my head around quickly. It does seem to be more with things that I am unsure of where to start on
19:56 diana_coman kind of ties in with your preference for clearly stated & neatly ordered stuff, yes.
19:57 diana_coman so break stuff into smaller & clearer steps and if unable /unsure of that, maybe just ask for more specific direction to get you started & anyway, until you start getting the hang of this part too
19:58 lobbes diana_coman: this makes sense. I will do just that
19:58 diana_coman laziness is essentially just a signal like many others.
20:00 lobbes I never really thought of it like that before, but it does make sense
20:00 diana_coman heh, I have yet to meet a single person (me included!) who has never been/can't be lazy, lol.
20:01 diana_coman lobbes: re bugs & testing, what was your question there to start with? because it seems more like an overall confusion tbh so not sure where to start you from on that.
20:04 lobbes diana_coman: well, I think I get your meaning on the "will eliminate possibility of bugs" point and on the "learning code is like writing well, you won't improve overnight by some series of steps"
20:04 lobbes but wrt to testing in an automated fashion, this is something I've never done
20:05 lobbes *will never eliminate possibility of bugs
20:05 diana_coman lobbes: you can improve anything by a series of steps - it just needs to be the steps that fit the cause of the trouble, not the steps that fit the result of the trouble, generally speaking, lol.
20:06 diana_coman lobbes: hm, let's see then from beginning: what's a bug?
20:07 lobbes I guess I'd generally define a bug as 'behavior that is unwanted'
20:07 diana_coman unwanted by whom?
20:08 lobbes by whomever is the authority of those using the code I suppose
20:09 lobbes or the authority of the environment that the code will run within
20:10 diana_coman lobbes: heh, in that case what are you even testing there? if I run it on my comp, I'll find bugs because my authority vs yours or what?
20:11 lobbes diana_coman: hm, well I mean in the case of the mp-wp-bot, MP is paying me for a product, and he gave a spec. So in this case he'd be the authority I reason; or the one to determine 'this is a bug / this is not a bug'
20:12 diana_coman lobbes: but in that case you can't test without him by your side, no?
20:12 lobbes diana_coman: well, I do have the specifications he gave me. I can test against that without him present
20:13 diana_coman lobbes: aha, so your def of bug is wrt to spec: a difference between specified behaviour vs actual behaviour of your code.
20:13 lobbes diana_coman: yeah, I would agree with that
20:14 diana_coman heh, it's one of the usual definitions, yes.
20:14 diana_coman anyway, next step then: since a bug is defined as above, what would "thorough testing" of some code mean?
20:16 lobbes I'm thinking at a minimum I'd be running a series of tests that would show me that the bot's actual behavior lines up to specified behavior
20:17 lobbes but I guess I see what you mean by "how to define thorough"
20:20 diana_coman lobbes: there is even quite a large body of uhm, effort let's say, poured into what is technically called formal specification precisely with a view towards formal verification aka "as thorough as it gets when testing god dammit" ; preferably even formal *proof* of correctness (which is even pushing it further).
20:24 diana_coman lobbes: at any rate, if you want "thorough", you'd need to take the spec, extract all desired behaviour at the very least and then check that; there is of course further trouble caused by all sorts, not least of which...how do you actually check?
20:25 diana_coman which brings us neatly to the very problem with testing itself as an activity: say you have a very neat and simple spec, it just says program should give result A to input B
20:25 diana_coman so you'll test that simple thing - how?
20:26 lobbes diana_coman: in that example I would input B, and see if I get A
20:26 diana_coman lobbes: right; how many times?
20:27 lobbes statistically, I think I 'should' do 20 times for a sample population. But now I'm starting to see the issues..
20:28 lobbes i.e. if I have 100 inputs..
20:28 diana_coman ahaha; statistically based on what ...assumptions? you do know that *each* statistical model in fact has some very cumbersome assumptions (although in general they are never mentioned and ~always silently assumed only, mainly because it's convenient)
20:28 diana_coman (or rather: because otherwise wtf are we to do???)
20:30 lobbes yeah, lol. I do recall some heavy assumptions back in my stats 101 days (and really with anything to do with 'models', be they financial models or whathaveyou)
20:30 diana_coman thing is: above your population of inputs has only one item so not exactly *that* the trouble even, no; the trouble is that your code is running in a whole environment and it's not in fact as isolated of it as you'd like to think; what if it's a pointerfuck that reads nonsense on the 100001th attempt for instance?
20:32 lobbes this does makes sense on the 'can't isolate' point; you'd need to know the totality of the environment, which is very expensive
20:32 diana_coman then there is of course the slightly more complicated spec that is still very simple: program should do simple addition of integers; how are you going to thoroughly test even the *inputs* on this one?
20:34 diana_coman lobbes: not to mention that then it will get run in a different environment anyway and given current state of "software", you can't guarantee anything really.
20:35 diana_coman lobbes: do you know what black box and white box testing are?
20:35 lobbes diana_coman: I do not
20:36 diana_coman eh, so there's a whole to say on testing alone to start with; but even beyond that, the fundamental there is essentially that a test that passes does *not* give you any information as to the correctness of the code really
20:36 diana_coman it's only a test that fails which tells you something useful
20:37 diana_coman and that something useful is "this is surely broken"
20:38 diana_coman however, the opposite of that (this is surely NOT broken) can *never* be found out just from testing, no matter how much you test it there.
20:39 lobbes hm, I see what you mean. So really, the most I can aim for is "simply not found to be broken yet"
20:39 diana_coman if you are really curious, there are even studies re how many bugs one finds on what amount of time spent for testing (and even when having a more informed approach to testing rather than the naive one)
20:40 diana_coman the main result though is that some tests are useful (because most bugs are found through some use, basically) but then it's too much trouble to search for them through this sort of method.
20:41 diana_coman lobbes: pretty much, yes.
20:42 diana_coman now back to black/white box because it's a simple and otherwise useful thing: black box means that you don't look inside - basically you consider it as a whole of which you are interested strictly only in inputs and outputs
20:42 diana_coman so you design tests based solely on whatever correspondence of inputs/outputs you have
20:43 diana_coman white box means that you DO take into account the insides of whatever it is, in this case of your code
20:43 diana_coman hence you design tests based *also* on the code itself
20:44 diana_coman for both of those, there are specific strategies based essentially on heuristics of "most likely ways/places in which code breaks"
20:46 diana_coman lobbes: the most useful part of this whole thing and the main reason why I went in such detail for you here is that the approach as a whole is more generally valid though, it's not just specific to software.
20:47 diana_coman whatever you are interested in and you are trying to understand or assess - if you go at it by "testing", you'll have quite the same type of trouble (only probably magnified because more complex than software)
20:49 lobbes diana_coman: hm okay. This is all helping quite a bit. So if I understand correctly, when testing something I should be focusing primarily on a black box testing approach with an eye towards tests that are most likely to illuminate the most bugs
20:49 diana_coman lobbes: why do you say focus on black box primarily?
20:51 lobbes diana_coman: hm, I misunderstood you above when you said 'approach as a whole'; I equated that to the black box testing (since you said that is when you consider it as a whole)
20:52 diana_coman lobbes: no; the approach is all the above, lol.
20:52 lobbes now I gotcha
20:52 lobbes so, I have a few q's: for one, what is the benefit anyway to testing separately like that (looking at code vs not), and two, how do I know which tests will illuminate the most bugs?
20:52 diana_coman black box means considering an item as a whole (different stuff!)
20:54 diana_coman lobbes: they tend to catch different bugs & black box frees you from what you "think/know the code should do" esp if it's your code & in some cases you can't do the white box; you can't know upfront really; if you want to choose only one approach, you'd go for white box rather than black box at all times.
20:54 diana_coman lobbes: or do you mean how to design the tests for either?
20:56 lobbes diana_coman: ah okay, I understand what you mean now on 'why do separate white/black box testing'.
20:57 diana_coman in a nutshell, for black box testing you'd partition the inputs space into whatever partitions are relevant + choose testing inputs so you cover each partition through at least one value + all boundaries (because that's the most usual case of fail)
20:57 diana_coman for white box testing, you'd aim in principle to cover at least once all the control and data flows in your code.
20:57 diana_coman this would be the most basic stuff really.
20:58 lobbes this makes sense, thank you!
20:59 diana_coman lobbes: see, the power of a few questions; you're welcome.
20:59 lobbes diana_coman: well, I definitely have a much better plan of attack for testing this bot now. However, I definitely think I'll need to plan more time to work on it as well
20:59 diana_coman re automated testing, the idea is that you write them once but you can run them as many times as you need and that is *very* useful for next time when you change something/add something to the code.
21:01 diana_coman lobbes: one important implication of that limitation of what you can find by testing is that it's *always* a much better pay off in the long term to not have to test much ie to know what it does rather than test for what it does.
21:01 diana_coman again, extremely relevant and valid for life, not only for code.
21:03 lobbes I can definitely see the general applications of that advice, that is for sure
21:04 diana_coman lobbes: did you have further stuff to implement for mp-wp?
21:04 diana_coman I seem to recall something else to enable a move from current display of logs.
21:06 lobbes diana_coman: hmm, well I mean that is the bot. It'll display the logs in the blogs (as seen in my haphazard testing blog)
21:07 lobbes though now that you mention it there was a related change to the xmlrpc.php I had to make; I'll need to vpatch that too at some point
21:07 diana_coman lobbes: does it update in db if it's current log?
21:08 diana_coman more to the point: what would I need to do in order to have the content of currently logged channels spit out in real time into corresponding daily articles on my blog?
21:09 lobbes diana_coman: you'd just need to press my mp-wp-bot vpatches, configure it for your mp-wp install database, and then run the bot
21:10 lobbes though I do still need to release a second vpatch that is not found in above link
21:10 diana_coman lobbes: so perhaps once you are done, you do that & illustrate it since you have a logger running anyway, right?
21:11 diana_coman lobbes: also, why the latency throughout?
21:11 lobbes diana_coman: sure thing, like put together an install manual on my blog?
21:11 lobbes diana_coman: am I slow to respond? I'm honestly just this slow lol
21:11 diana_coman lobbes: yes; preferably after you had it running and basically living proof that everything is working great.
21:12 lobbes diana_coman: I'd love that. Sounds like a plan to me
21:12 diana_coman lobbes: relatively slow, yes; and at times visibly slow, to the point I wonder if I lost you/ it's too much in one go, lol.
21:13 lobbes diana_coman: nah, sometimes I'll just be reading and grokking, though sometimes I can sense you are moving a point along so I'll let you finish
21:14 lobbes diana_coman: I'll let you know if it ever becomes too much in one go. So far it hasn't been for me
21:14 diana_coman lobbes: the let finish part is fine, obviously.
21:14 lobbes kk
21:15 diana_coman lobbes: btw, it's not like it has to be a meeting spec as such; you know I tend to be around from about 7pm on most days so you know, just ask then/say something, it's fine
21:15 diana_coman for that matter, anyone else
21:16 diana_coman lobbes: was there anything else?
21:16 lobbes diana_coman: makes sense, and good to know. Though (and I think dorion_road mentioned this at some point for himself) I kind of like scheduled meetings. idk why
21:16 lobbes diana_coman: nothing else from my end
21:16 diana_coman heh, you like scheduled everything, don't you
21:16 lobbes though this was very helpful, so thank you again for your time
21:17 lobbes hahaha for some things, yes I do!
21:17 diana_coman lobbes: do note though that you keep pushing those remaining 2 articles
21:18 lobbes diana_coman: noted
21:18 diana_coman there's always some reason to push them to next week, ahem; so I'd say 2 pushes is fine, but then can't push it 3rd time.
21:18 lobbes diana_coman: okay, I'll make sure I get working on article 2 by week 4
21:19 diana_coman good; and you're welcome.
21:21 * lobbes will bbl; food
← 2020-01-04 | 2020-01-06 → ↑

Random(ossasepia) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default