| 07:53 |
Mocky |
just got back from a hiking trip. catching up on logs |
| |
↖ |
| |
~ 1 hours 50 minutes ~ |
| 09:44 |
BingoBoingo |
Welcome back |
| |
~ 54 minutes ~ |
| 10:38 |
Mocky |
thanks BingoBoingo |
| |
~ 4 hours 24 minutes ~ |
| 15:03 |
BingoBoingo |
And the stolen Iodine-131 has been found https://www.elobservador.com.uy/nota/aparecieron-en-malvin-las-tarrinas-con-material-radioactivo-robadas--20195271514 |
| |
~ 1 hours 9 minutes ~ |
| 16:13 |
feedbot |
http://qntra.net/2019/05/eu-parliament-centrist-pantsuits-lost-ground-brexit-party-takes-uk/ << Qntra -- EU Parliament: "Centrist" Pantsuits Lost Ground, Brexit Party Takes UK |
| 16:25 |
* |
mp_en_viaje waves from the lovely transylvanian capitol. |
| |
~ 46 minutes ~ |
| 17:12 |
mp_en_viaje |
holy shit the internet is terribru |
| |
~ 20 minutes ~ |
| 17:32 |
diana_coman |
mp_en_viaje: lolz, where in ro did you find it? |
| 17:32 |
feedbot |
http://ossasepia.com/2019/05/27/euloras-client-core-the-dedicated-requester/ << Ossa Sepia -- Eulora's Client Core: The Dedicated Requester |
| 17:35 |
diana_coman |
in other stepping-in-all-the-holes : it seems I found a fail-mode of mp-wp browser interface namely if one pastes the content of a post first and only then (possibly after it rushes to quick save it or whatevers) the title, it fails miserably as it apparently tries to save it with title "" (notwithstanding that no, it should not, there is actually a title to it) |
| |
↖ |
| |
~ 22 minutes ~ |
| 17:57 |
mp_en_viaje |
diana_coman, cluj |
| 17:57 |
mp_en_viaje |
speaking of which, if anyone is in the area and wants to meet, speak up, i'll be around for a few days |
| 17:58 |
mp_en_viaje |
diana_coman, no, it saves it with a numeric title. |
| 17:58 |
diana_coman |
o.O ; I wouldn't have expected lousy net connection in Cluj, huh. |
| 17:58 |
mp_en_viaje |
you can edit the slug if you want later |
| 17:58 |
mp_en_viaje |
me either, but what can you do. |
| 17:58 |
diana_coman |
mp_en_viaje: it keeps failing i.e. saying can't |
| 17:59 |
mp_en_viaje |
can't what, save ? |
| 17:59 |
diana_coman |
so apparently the numeric title is borked or at least borked on my installation |
| 17:59 |
diana_coman |
yes |
| 17:59 |
mp_en_viaje |
sounds like borked install. what's preview do ? |
| 17:59 |
mp_en_viaje |
doesn't preview, either ? |
| 17:59 |
diana_coman |
lemme try to reproduce it and see. |
| 18:00 |
mp_en_viaje |
what you describe specifically was debugged ; i suppose entirely possible php/whatever stack versioning shenanigans may have managed to regression it, like that insane case we ran into recently with the comments not working |
| 18:00 |
mp_en_viaje |
but in principle should not fail in any combination. |
| 18:03 |
diana_coman |
ugh, now ofc can't quite reproduce it i.e. it was something more subtle than what it seemed... |
| 18:03 |
mp_en_viaje |
ah |
| 18:03 |
mp_en_viaje |
well anyway, regardless of implementation, the design idea there is that article title always has a ready gensym in the shape of the numeric id of the table entry, which is unique and always known and therefore should be the fallback default. |
| 18:05 |
diana_coman |
that makes perfect sense and is pretty much what I'd have expected; hence the surprise earlier when it apparently refused the title and insisted it was ""; anyway, if I run into it/something else again I'll document it better on the spot I guess. |
| 18:05 |
mp_en_viaje |
yeah |
| 18:07 |
mp_en_viaje |
]there;s also a js autosave if you have js enabled in browser ; these may have interracted weirdly i guess. |
| 18:07 |
mp_en_viaje |
js is fucking impossible to debug. |
| 18:07 |
mp_en_viaje |
(there's also a js doing wordcount on pressing enter, and a few other sugar cubes like that) |
| 18:08 |
diana_coman |
I quite suspect it is the autosave thing because this much I remember that it was after it auto-saved, hence my suspicion at it; but at least atm it the autosave did not fire and tbh I'm not extremely keen on chasing this right now. |
| 18:08 |
mp_en_viaje |
myeah. |
| 18:09 |
mp_en_viaje |
let's leave a breadcrumb for billymg, too, whynot. |
| 18:11 |
mp_en_viaje |
diana_coman, speaking of http://ossasepia.com/2019/05/27/euloras-client-core-the-dedicated-requester/#selection-41.2-41.111 i don't see the wisdom in this position. suppose your client sees a new type of whatever, and manages to get everything but the icon. a) your path would require it to die trying but b) evidently going ahead while using a ~default~ icon until gets a better one is perfectly acceptable. |
| 18:12 |
mp_en_viaje |
in limine, an eulora client which plays with 100% default data objects, everyone-is-an-axe-cutting-axes-with-axes-on-axe-planet is a-ok. |
| 18:13 |
diana_coman |
nope, there is no such thing as "everything but the icon" |
| 18:13 |
mp_en_viaje |
why not ? |
| 18:14 |
diana_coman |
because the requester does not request "x and y and z of 187" ; all it requests is "187" and then it simply checks in EuCache: do you now have 187? Now WHAT EuCache has for 187 is not something requester can know in advance |
| 18:14 |
diana_coman |
I suspect I'll need to detail the data model too for it all to make sense |
| 18:14 |
mp_en_viaje |
sure. now suppose client asks for 185, 186, 187 and 188, and gets them, within an hour. |
| 18:14 |
mp_en_viaje |
should game be unplayable for the hour ? |
| 18:15 |
diana_coman |
why would the game be unplayable for the hour? for one thing: why would the game be unplayable at all at any moment anyway? |
| 18:15 |
mp_en_viaje |
cuz "die trying". |
| 18:15 |
mp_en_viaje |
either it dies, or it doesn't die. if it dies, you can't play it. if it doesn't die, it somehow manages to make do w/o the item (ie, uses defaults) |
| 18:15 |
diana_coman |
die trying aka after x successive timeouts (timeouts aka NO data received in the whole interval*x ) |
| 18:16 |
mp_en_viaje |
i do not believe it should die at all. |
| 18:16 |
mp_en_viaje |
imo it should try ~once~ per mention. |
| 18:16 |
mp_en_viaje |
every time the server mentions an object it doesn't have, it asks for it. that's it. |
| 18:16 |
diana_coman |
uhm; on one hand the "does it die or not" is a tiny thing i.e. it is a decision of what-do if not received; |
| 18:17 |
diana_coman |
it can pass on to next one, sure |
| 18:17 |
diana_coman |
i.e. drop it simply |
| 18:17 |
mp_en_viaje |
i'm not even sure it's worth producing the retry mechanism. |
| 18:17 |
diana_coman |
not a big issue or change of core there |
| 18:17 |
mp_en_viaje |
logically speaking, if it's unimportant it's unimportant ; this is a game world criterion your retry cache can't figure out. |
| 18:17 |
diana_coman |
it is not as such a "retry" i.e. the request will not be a new one |
| 18:17 |
mp_en_viaje |
ah ? |
| 18:17 |
diana_coman |
it will be a different one ANYWAY |
| 18:18 |
diana_coman |
because it picks up again whatever it can stuff in the request |
| 18:18 |
mp_en_viaje |
how do you mean / |
| 18:18 |
diana_coman |
the ~only consideration is perhaps whether to re-include whatever it hasn't yet received or just drop them and if they are demanded again then they'll make it again another time |
| 18:18 |
diana_coman |
hm; requester received demands for x and y and z, right? |
| 18:19 |
diana_coman |
it keeps them in a queue, those items here are demanded |
| 18:19 |
mp_en_viaje |
in the capitalistic perspective : if 100 objects are mentioned 10`000 times and requested 10`000 times, then i'd like the one object mentioned 1`000 times be requested 1`000 times and the object mentioned once be requested once. |
| 18:19 |
mp_en_viaje |
this seems the correct capitalistic split of the request pie : by mentions. rather than "everyone gets 100" |
| 18:20 |
diana_coman |
something still seems rather mixed in there; let me see if I can untangle it |
| 18:20 |
mp_en_viaje |
aite. |
| 18:20 |
diana_coman |
what is "mentioned" there? demanded ? |
| 18:21 |
mp_en_viaje |
mentioned means the client sees an object it doesn't have in a server communication. |
| 18:21 |
diana_coman |
why would it even request it *there*? |
| 18:21 |
mp_en_viaje |
ie, if 10 people go on a raid and 5 of them wear armor of the stars, said armor will be mentioned by server 5 times. |
| 18:21 |
mp_en_viaje |
well, cuz client may well discover "shit, i never heard of this armor before, wtf is it" |
| 18:21 |
diana_coman |
but so what, should that then be requested 5 times ? |
| 18:21 |
diana_coman |
yes, but ...once |
| 18:21 |
mp_en_viaje |
well presuming it doesn't get it. |
| 18:22 |
diana_coman |
uhm |
| 18:22 |
mp_en_viaje |
whole discussion is predicated on comms failure, client asks but doesn't for some reason get. |
| 18:23 |
diana_coman |
yes but there is no generic client asks as such; from pov of client ALL the asks always get - defaults. |
| 18:23 |
mp_en_viaje |
as a fall through you mean ? |
| 18:24 |
mp_en_viaje |
let me model an interaction to make sure we're on the same page here. |
| 18:24 |
diana_coman |
as a higher-level concern than Requester's ; requester is specifically concerned with trying to get whatever is asked of it *from the server*; it can of course decide on what it requests first for instance (perhaps the item that was demanded of it most times since last request) |
| 18:24 |
mp_en_viaje |
so, server tells client at t1 "and then you came upon five persons, a, b, c, d, e, f". |
| 18:24 |
diana_coman |
and it can also decide on what to do on timeout e.g. drop that item and if it's important it will be demanded again hence it will make it into another request and if not , no |
| 18:25 |
diana_coman |
yes |
| 18:25 |
mp_en_viaje |
client notices it doesn't know wtf these are ; so at t2 says "what's an a ?" |
| 18:25 |
diana_coman |
so a-f are data and therefore stored in cache as such; there are those things a-f ; nothing more |
| 18:25 |
mp_en_viaje |
and at t3 server replies : "a is a so and so and back and forth... and on his chest wears the armor of the stars, and bla bla bla". |
| 18:26 |
mp_en_viaje |
at t4 client continues its inquiry, "what's a b ?" ; at t5 client notices it doesnt know wtf such an armor is, so asks sefver "what's an armor of the stars ?" |
| 18:26 |
mp_en_viaje |
at t6 server replies : "b is a so and so and back and forth... and on his chest wears the armor of the stars, and bla bla bla". |
| 18:26 |
mp_en_viaje |
at t7 client decides "well, wtf, it's an armor, so ima show a wearing default armor, and whatever" |
| 18:27 |
mp_en_viaje |
then at t8 client notices AGAIN "hm, i'm using default for this armor of the stars, wtf is it ?" and asks the server again. |
| 18:27 |
mp_en_viaje |
but because an item it uses a default for is mentioned again, not because of any retries. |
| 18:28 |
mp_en_viaje |
at this juncture, if it finally gets a workable armor of the stars, it dresses both a and b in it ; but if not, whatever. |
| 18:28 |
mp_en_viaje |
it doesn't die nor does it retry. just plods along. |
| 18:28 |
diana_coman |
myeah, this "asks again" is not "asks the server" but "ask the requester" ; i.e. "client" does not directly talk to the server from anywhere because that is how mess is made |
| 18:28 |
mp_en_viaje |
alright. |
| 18:29 |
mp_en_viaje |
that part is fine, "client asks server through its dedicated monopoly on askings" |
| 18:30 |
diana_coman |
yes; and the requester (this dedicated monopoly on askings) will pack and send specific requests: server, what is an armor of the stars and a sword of the pigs? |
| 18:30 |
mp_en_viaje |
okay. |
| 18:30 |
mp_en_viaje |
but if it's not happy with theresult, not only does it not die -- it doesn't even retry. |
| 18:32 |
diana_coman |
you mean if it timeouts on a request then it lets it just lets it be? it makes it even simpler from my pov, not as if it's an issue but essentially I'm not sure how do you then avoid the case where you play happily offline and ...not notice it? |
| |
↖ |
| 18:33 |
diana_coman |
not notice it until all of a sudden nothing fits |
| |
↖ |
| 18:34 |
diana_coman |
at which point recovery is a bitch way worse than restart; I suppose the point might be "don't die, just make it clear there's nobody answering " |
| 18:35 |
diana_coman |
lol, internet a la cluj |
| |
↖ |
| 18:41 |
diana_coman |
anyway, if it shouldn't even retry the correct way to put it is that it doesn't *care* at all about the result; i.e. it sends the request, it goes to sleep for timeout interval and then when it wakes up it simply makes and sends the next request, without any care in the world re anything |
| |
↖ |
| 18:51 |
diana_coman |
while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity a bit higher up at the added cost of a lot of waste traffic |
| |
↖ |
| 18:54 |
diana_coman |
if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still a look "is it in the cache now?" just that it's pushed higher up |
| |
↖ |
| 18:58 |
diana_coman |
basically I don't actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's a relative (and changing) ordering of requests at most, not a traffic-generator essentially. |
| |
↖ |
| 18:59 |
* |
diana_coman will go to sleep now, will read any replies/continue in the morning. |
| |
~ 46 minutes ~ |
| 19:46 |
* |
asciilifeform back from meat; slowly eats log |