32300+ entries in 0.019s
a111: Logged on 2019-05-27 22: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
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER
TIME
than in
the middle of heavy gameplay, such
that all
the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather
than en masse whenever
teleporting
to a large market
town" you have a solid point. but it's
☝︎☟︎ mp_en_viaje: 2. case careful -- request is sent (p=1), if received correctly (p=2)
then all is well, else new request sent (p=2.5) and if now received correctly all is well but if not yet new request sent (p=3.5) and if not well again you're looking at... well, depends how noisy/lossy
the channel is, but it seems
to me
the careless case saves a good chunk of bw, roughly speaking
the square of
the noise rate.
a111: Logged on 2019-05-27 22: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
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915699 << model for me how
this waste of
traffic would look ? seems exactly
the opposite
to me, specifically : 1. case careless -- request is sent ; were resppnse receinved, all
the better ; otherwise, whatever.
total sent : 1 request ; maybe 1 answer. say symbolically 1.5 "packets"
☝︎ a111: Logged on 2019-05-13 17:09 asciilifeform: meanwhile , in ru heathendom , (translation mine) : 'there is a sign
that distinguishes a
troo programmer from an impostor. a
true programmer , before going
to bed, will put on his nightstand
two glasses. one with water -- in case in
the night he becomes
thirsty. and one empty -- in case not.'
mp_en_viaje: and more generally i believe a lot of software systems would greatly improved
through liberal application of just
this kind of carelessness.
the idiots are careless at
the wrong ends -- by all means, DO
http://btcbase.org/log/2019-05-13#1912968 ; do NOT "hi
this is
the glass from last night, how would you rate your drinking experience please fill out
this form".
☝︎ a111: Logged on 2019-05-27 22: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
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915697 <<
trist da'
tru.
the fucking problem with solving problems is
that as
the problem solvers get old
the next generation
takes over, and
they only ever dealt with
the solution ; didn't ever deal with
the problem. consequently
they limply expect
the solution, in
the sad
terms of "oh, do we still have
to", without any appreciation for
the difficulty of
the problem, resulting in fucking amer
☝︎ mp_en_viaje: (obviously "forevermore" means -- for as long as he's wearing
that
type of armor, and include all other dudes wearing
the same
type, yes, i'm not looking for dwim here.)
mp_en_viaje: (the programmatic logic being
that as i focus on
the game again,
the screen will have
to be redrawn, which will suck from
the cache ; obviously
this may not work ~exactly~ like
this for a number of reasons -- which is why it's called an ideal. it should work like
this.)
mp_en_viaje: whether i can be arsed or not
to do
this is one
thing ; but if i am arsed i should encounter no further difficulty.
mp_en_viaje: in
the vhs-unix-that-never-existed ideal in my own mind, i should be able
to, upon encountering for
the first
time a dude i don't like, alt-tab out of
the game, edit
the cached file representing
this dude's armor, write "dickhead" in spray paint all over
the breastplate, and without any further interaction on my part see
the dickhead appropriately labeled all over
the game forevermore.
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915695 << what would
this "nothing fits" look like ? for instance, if a client makes himself a modfile,
to have all
the characters move lasciviously and otherwise sit about nude, or if joe
the manga fan makes his shield sport a
tentacle pattern,
the server should periodically re-enact
the one-true-look with medieval officialness ? why ?
☝︎ mp_en_viaje: (the fundament of
the male world,
this division, btw. not permitting any-thing-whatsoever being discussed is what repressing
the female mind, worldview and experiential approach is all about)
mp_en_viaje: in another statement :
there's
two classes of data : erste klasse, which is data which
the client may reference (such as, move me
two
to
the left), and buluk klasse, which is data
the client may never reference (such as, make my armor one iota shinier).
mp_en_viaje: therefore will necessarily have
to be resolved by
the client. in many important fields (such as where
the client
thinks its located),
the server has
the important mechanism of denial,
to support fast correction. but when it comes
to, eg, what icon should represent x item, or how its 3d
texture shoudl look etc,
there's no shits given. client can display
the world any way it does, and
the server will not care.
mp_en_viaje: practically, yes it;s undesirable, but
the overwhelming consideration is
that
this undesirableness can not be managed for
the client by
the server, because
the server suffers from a serious knowledge problem wrt it.
☟︎ a111: Logged on 2019-05-27 22: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?
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915694 << philosophically,
the situation where player is happy offline, and unaware of it does not require fixing.
take asciilifeform for instance, he's been happily playing eulora offline for years, and hasn't yet noticed!
☝︎ mp_en_viaje: diana_coman, sorry about last night lol. had
to order another
truckful of internet.
diana_coman will go
to sleep now, will read any replies/continue in
the morning.
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.
☟︎ 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
☟︎ 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
☟︎ 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
☟︎ 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 "
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?
☟︎ mp_en_viaje: but if it's not happy with
theresult, not only does it not die -- it doesn't even retry.
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?
mp_en_viaje: that part is fine, "client asks server
through its dedicated monopoly on askings"
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
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.
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.
mp_en_viaje: at
t7 client decides "well, wtf, it's an armor, so ima show a wearing default armor, and whatever"
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".
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 ?"
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".
diana_coman: so a-f are data and
therefore stored in cache as such;
there are
those
things a-f ; nothing more
mp_en_viaje: client notices it doesn't know wtf
these are ; so at
t2 says "what's an a ?"
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
mp_en_viaje: so, server
tells client at
t1 "and
then you came upon five persons, a, b, c, d, e, f".
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)
mp_en_viaje: let me model an interaction
to make sure we're on
the same page here.
diana_coman: yes but
there is no generic client asks as such; from pov of client ALL
the asks always get - defaults.
diana_coman: but so what, should
that
then be requested 5
times ?
mp_en_viaje: well, cuz client may well discover "shit, i never heard of
this armor before, wtf is it"
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.
mp_en_viaje: mentioned means
the client sees an object it doesn't have in a server communication.
diana_coman: something still seems rather mixed in
there; let me see if I can untangle it
mp_en_viaje: this seems
the correct capitalistic split of
the request pie : by mentions. rather
than "everyone gets 100"
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.
diana_coman: it keeps
them in a queue,
those items here are demanded
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
diana_coman: because it picks up again whatever it can stuff in
the request
diana_coman: it is not as such a "retry" i.e.
the request will not be a new one
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.
mp_en_viaje: i'm not even sure it's worth producing
the retry mechanism.
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;
mp_en_viaje: every
time
the server mentions an object it doesn't have, it asks for it.
that's it.
diana_coman: die
trying aka after x successive
timeouts (timeouts aka NO data received in
the whole interval*x )
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)
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?
mp_en_viaje: sure. now suppose client asks for 185, 186, 187 and 188, and gets
them, within an hour.
diana_coman: I suspect I'll need
to detail
the data model
too for it all
to make sense
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
diana_coman: nope,
there is no such
thing as "everything but
the icon"
mp_en_viaje: let's leave a breadcrumb for billymg,
too, whynot.
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.
mp_en_viaje: (there's also a js doing wordcount on pressing enter, and a few other sugar cubes like
that)
mp_en_viaje: ]there;s also a js autosave if you have js enabled in browser ;
these may have interracted weirdly i guess.
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.
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.
diana_coman: ugh, now ofc can't quite reproduce it i.e. it was something more subtle
than what it seemed...
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
diana_coman: so apparently
the numeric
title is borked or at least borked on my installation
mp_en_viaje: diana_coman, no, it saves it with a numeric
title.
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
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)
☟︎ mp_en_viaje waves from
the lovely
transylvanian capitol.
Mocky: just got back from a hiking
trip. catching up on logs
☟︎ diana_coman: BingoBoingo: I got
that same spam!
tbf all spam is rather similar, sort of
trying
to work out which specific belief
to latch on: is it how great one's blog is or is it how dangerous being online is.