Young Hands
ossasepiaeuloratrilemaspykedtrinquetrilema-hanbotagriculturalsupremacy
14h 10m7d 2h 29m78d 1h 22m4d 2h 47m24d 14h 39m6d 22h 31m10h 42m
Ossasepia



118 entries found in trilema for 'f:diana mess' :

diana_coman: basically timestamps have always been a total mess.
diana_coman: hm, in my memory the int64 kind of merges with eviscerating the gem mess out of the server
diana_coman: re paster though tbh this attempt (coming as it does on top of the previous mess with python and its flask) left me looking again for not using either.
diana_coman: jfw: Keksum's 3rd genesis is now signed and mirrored; as you've gathered already the previous comments on your article directly, I linked that and there's no need that I see for an additional article; also, you messed up something with your Keksum's article title now.
diana_coman: http://logs.ossasepia.com/log/trilema/2019-12-13#1955265 - maybe it's something specific to the 3d block there that messes it up though it's not all that likely (if for no other reason than the basic 1. at first it worked 2. it still works as a separate footnote); anyways, I don't think it's worth the time right now to chase it fully.
diana_coman: mp_en_viaje: uhm, it is, apparently it's some messed up footnote, lemme see.
diana_coman: well, tbh I saw way worse from others ie not-packing-at-all, literally left as an overflowing mess; it's still funny though, certainly.
diana_coman: hanbot: iirc there was some issue if one messed up something in that additional spam filtering change because it touches indeed the same file and it's ~easy to make a mistake so it just kills all comments; but then it kills all really so hm.
diana_coman: spyked: ah, so you mean that the trouble is just that the message queue is lifo instead of fifo really?
diana_coman: if it weren't such a horrible mess to get them all the way to here, ugh.
diana_coman: I ...know it; still mess it up repeatedly, grrr.
diana_coman: (obv, other than if I publish with messed up/changed dates)
diana_coman: (heh, reading back in jfw quotes re footnotes, yes: he avoided (()) because of lisp-code worries so ended up on the <fn> mess).
diana_coman: at the point with ben_vulpes I admit I couldn't figure out who was really messing up more there, honestly.
diana_coman: which is nice and fine but sadly crystalspace is a mess and won't compile static only just yet :(
diana_coman: mp_en_viaje: can report that dev server is also built and had a test run locally with dev client; compilation there messier because of the whole stuff with gnat.
diana_coman: bot & reader deployed to latest head (aka no shlex-mlex mess); searches with ' should not fail anymore
diana_coman: hanbot you need to turn off that comment-pagination thing on your blog as it's messing up your recent comments links e.g. http://thewhet.net/2013/09/your-feelings-are-out-to-get-you/comment-page-2/#comment-55392
diana_coman: http://logs.ossasepia.com/log/trilema/2019-09-16#1936741 - fixed and dump manually updated; it turned out the mess-up was caused by a mix-up of local log formats (ie ran like an idiot the awk script on the not-matching format; basically I have too many logs all around)
diana_coman: given this, I seriously wonder if it can be much worse to make it in ada on top of all the gnat-mess including unbounded strings and gnat.sockets and everything else; at least the full gnat so far *is* more transferable
diana_coman: fwiw, I diffed the 2 and looked, couldn't find further issues; the nick is now indeed first word of payload when * is nick (on action); + the one case with messed up lines because of Day changed vs. Log opened is corrected too.
diana_coman: lmao; I puzzled when first saw there "flask" - but then again, not sure one can bake www-anything quickly without importing any mess
diana_coman: tbh I never used several pages of comments and having them broken at a random place seems like a stupid idea indeed; but then again, I probably messed about with all the knobs around there at one time or another.
diana_coman: http://btcbase.org/log/2019-07-17#1923053 - funnily enough not even *just* the playing; kid pleaded and asked so in the end got him through ~20 lines of Ada doing a little "guess the number" text-game and he's more hooked to mess around with it than with heroes because obv "can look inside"
diana_coman: http://btcbase.org/log/2019-06-25#1919888 -> this is usually precisely my experience too when sorting out some mess.
diana_coman: meanwhile I'm trying to disentangle here the cs/ps mess and I'm scratching my head at various bits: the CS engine works everywhere with names (strings) as ids (i.e. there are FindX functions only with string param, not with some numeric id despite the fact that internally it DOES HAVE them ffs) BUT then in some places it keeps various hashmaps with numeric ids for "common strings"
diana_coman: "a break" as in taking a break (from the mess)
diana_coman: open-ended lists like that are always a mess and doubly so via messages
diana_coman: what is the gain in forcing every request -> a message to server?
diana_coman: the point is not about "how fresh the final data is" but rather simply that: how many messages get generated for x requests
diana_coman: so you say there is no difference between caller asking for it 10 times and this resulting guaranteed in 10 messages to the server because requester does not keep track of anything on one hand and on the other hand 10 requests resulting in only 1 message to server because requester does keep track?
diana_coman: might add also, since it's perhaps not obvious: there is no exact "repeat request" as such because anyway, how could that be (counter of messages at the very least is different!) but more importantly, every time Requester asks the server for something, it simply asks about as many pending things as it can, there is no "oh, I asked about those and not yet here so let's ask exactly those again"
diana_coman: the idea here being that well, if the caller still wants that stuff and it's not there, they will just request it again anyway so it gets again into the queue and at some point it will make it into a message
diana_coman: now there is the apparently disputed bit: in the simplest implementation, requester can now consider that it's job is done and therefore go to sleep until next time when it might send a message
diana_coman: whenever it decides it CAN actually send a message to the server to ask for something, it packs together as many of those pending requested stuff as it can in one message (protocol allows a request for several files/obj in same message) and it sends it on its way
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
diana_coman: anyway, since I'm not going to jump through those silly hooks now, I'll leave it here: you can message deedbot/any user privately directly, you don't need to join some channel first; and re newcomers, it's usually safer for themselves to join one of the lords' channels first, really (e.g. #asciilifeform, #trinque, #eulora)
diana_coman: guess so re derping hq; re fonts, I took that mess of a font out, yes; anyway, this was just on the side while stripping down the "login" window of useless password etc.
diana_coman: hanbot: maybe I messed up at some point all themes; I'll press the genesis again and unpack a clean theme from there and see if that sorts it
diana_coman: mircea_popescu, in short, the keccak spec in its current form really since it considers input at bit-level and then goes on to mess about with some assumptions at bit-level and some at octet-level and making a lot of confusion without any good reason e.g. http://ossasepia.com/2018/02/08/eucrypt-chapter-9-byte-order-and-bit-disorder-in-keccak/#selection-55.383-63.563 ; one needs to disentangle that and put it in octet-only shape, octet stre
diana_coman: hopefully I won't mess it up again the same way at least
diana_coman: I think I'll take a break and leave it until I have the smg test box back so at least I don't mess about with all sorts of versions of everything or I'll go nuts
diana_coman: sorry, the ref to previous mess wasn't quite clear, you're right
diana_coman: there was the earlier mess-up with the 2 datasets hence my current stress of the fact, that's all
diana_coman: http://btcbase.org/log/2019-02-11#1894896 -> ha, apparently you caught old hosting precisely when they messed up; thank you for reporting it, I'll have to sort it out (I had redirection set up from dianacoman->ossasepia since I'm sure it's not only my internal links but atm it's broken, will fix)
diana_coman: it was more of a confusion/mess rather than real problem as such
diana_coman: at the very least, dubious messages if/when it gets them
diana_coman: BingoBoingo, but how *many* accounts did you message out of how many in the db, over what time, what filter(s) did you use and with what results?
diana_coman: I still think it's a mess basically and I wrote it there like that with bullet points precisely because I know I will keep tripping over this so at least I know where to go to ...
diana_coman: mircea_popescu, hmm basically a client can end up "making an account" with Eve and not even knowing it/getting then stuck/receiving unexpected messages at next attempt with legitimate server; I'm sure a client can basically recover/notice in the end but it pushes a bit more complexity on client
diana_coman: for all my hate of them, atm they...build the whole mess of plugins and whatnots so sweeping them aside would take some effort, not insignificant
diana_coman: mainly because the whole thing is anyway only one thread of the mess as it were; but yes, reentrant should work too
diana_coman: asciilifeform, the concrete mess is this: smg_comms is in Ada, has sender and receiver task types so one can create those as needed, perfect; onth eulora client is this ball of CPP mess and it's unclear to me if it can even be made to use smg comms as it is or what
diana_coman: 3. I think that's to be a dynamic thing basically aka at a higher level server looks and if it needs to, it creates more workers to process those messages accumulating there
diana_coman: 1. expected bottleneck is message processing: encrypting/decrypting sounds most likely but in principle whatever further processing since not even specified yet fully! 2. the everything else is raw udp (aka udp lib) and feeding it/reading from it aka those would be sender/receivers
diana_coman: asciilifeform, the q is basically: how many messages/sec clogs the socket essentially
diana_coman: kk; meanwhile I still have on the list to figure out what's the diff that messes up the python installation thing on the other machine...
diana_coman: onth it makes easier to avoid the mess since it's all at one time, can't quite complain
diana_coman: re are still all those parts that are anyway no concern of upper layers (e.g. crc, padding) so there is still some part that has to walk the thing component-by-component anyway. The more I look at it, the more I get the impression that the idea of "serialize in 1 statement the whole stuff" is not worth pushing beyond simple types (i.e. yes, serialize in one line unsigned_32 but not the whole content of one message)
diana_coman: i.e. it should be the last thing in the message
diana_coman: this is what I had in mind; it helps but: diana_coman> in which case fine, it can perhaps even work like that for most messages except stuff that has max>message size and/or stuff that has meaningful data *after* this variable part
diana_coman: in which case fine, it can perhaps even work like that for most messages except stuff that has max>message size and/or stuff that has meaningful data *after* this variable part
diana_coman: you're asking me? lol; look at implementation that it becomes exactly that: http://ossasepia.com/2018/11/10/smg-comms-chapter-7-readwrite-serpent-keysets-tofrom-serpent-messages/#selection-71.1721-71.1777
diana_coman: http://btcbase.org/log/2018-11-10#1870620 -nitpick away! I actually DID consider that and I decided it's not really fitting because think of it: if I make it enumeration that *also* means you can actually go succ and prev which however isn't something that makes sense for message types; it's not like they are an actual ordered thing
diana_coman is still pondering the best way to treat that so it doesn't make a mess
diana_coman: and for the other it's the C style thing where it allocates memory the way it sees fit and the caller is supposed afterwards to clean up the mess when it likes
diana_coman: in other news from the smg comms front: the rsa pack/unpack turned a bit nastier than the nice serpent because (of course!) of the C element; basically the rsa operations are in C (mpi mess) while the oaep is in Ada and the current eucrypt wrapper is fine but doing the ugly dance of C to Ada *and back*; my solution to this is to decree that there will be only ONE direction of calls namely from Ada to C (because Ada is the main, desired par
diana_coman: sounds like a mess though
diana_coman: http://btcbase.org/log/2018-10-14#1862213 -> it's more than just one if statement (although unnecessary branches in themselves are not great anyway); basically it's the udp code itself that has to be messed up to accommodate this particular thing - either using generic or otherwise using the largest of the two and then filtering one level higher
diana_coman: the tester does not pack them in rsa or serpent proper so it's the "package" there rather than protocol message, I guess that might be confusing, I'll update
diana_coman: strictly from an implementation perspective I'd certainly prefer to have only ONE size of message to deal with - even if it means potentially that one has to check wtf it is; still, I'll wait for mircea_popescu to weigh in on this
diana_coman: apparently I'll have to get all those unexpected messages in some readable format and post them, myeah
diana_coman: asciilifeform, no, weird, single UDP message received from it by the UY node during tests
diana_coman: Mocky, btw sorry for the mess up with your public key; did it actually create a problem other than the wrong wot.deedbot graph?
diana_coman: but hm, does this mean that basically anyone can register the public keys and mess up the http://wot.deedbot.org/ ?
diana_coman: sorry about the mess there trinque
diana_coman: it certainly does look like some chopped off part of one of the messages sent around
diana_coman: come to think about it, I can see the case for calling them "messages" since it's not the network level there, indeed
diana_coman: http://btcbase.org/log/2018-09-27#1855101 -> it turns out Eulora actually needs precisely this since its communication protocol specifies different lengths of messages, hm
diana_coman: uhm, correction re above since I messed up the pilot test earlier (sender sent 100 as shown, but receiver waited for only 50 and then turned off so not much use); updated pilot test with receiver properly looping forever and sender sending 100 packets: 81 of those made it; sender log: http://p.bvulpes.com/pastes/zs4p5/?raw=true ; receiver log: http://p.bvulpes.com/pastes/4qiPb/?raw=true
diana_coman: http://btcbase.org/log/2018-09-25#1854219 -> tiny new pilot test seems to suggest it's not as bad as that: all 100 packets of a batch (sent in burst mode, no delays) made it, with pseudo-randomly chosen sizes between 6 and 2048; predictably though, order was messed up at times
diana_coman: that would certainly fit this observed mess, yes
diana_coman: heh, asciilifeform has it: the way I see it, ave1's work will come in very handy at a later date when we can get rid of more of the C mess
diana_coman: as it is, the selected minimal set of ops seems ok, except perhaps the fixed message length - I think it's more of a maximum length needed in practice, at least for current version of S.MG protocol
diana_coman: ugh, sounds like a mess
diana_coman: at any rate, from server's point of view, it doesn't care - it will answer to legitimate messages and that is that; it's more of a client concern and up to them how they handle that i.e. indeed pretty much how long they wait/when do they consider server unreachable and what they do
diana_coman: last time I tried to figure out exactly what is what and where re portage I ran out of time to disentangle the mess, so I'll be very happy indeed to not have to go back to that
diana_coman: after reading around on this mess with the usb speeds, the summary + questions would be: 1. the dwc_otg seems actually specific to raspberry pi so I don't see how it's directly useful atm; am I missing something? 2. the manual/runtime pill so far relies on the companion mechanism to force a USB port down from "high speed" to "full speed" so basically from ehci to uhci/ohci; wouldn't it make more sense to blacklist ehci, xhci and whatever
diana_coman goes to read that code again maybe something is messed up there
diana_coman: http://btcbase.org/log/2018-07-04#1831631 -> I messed it up because pay instead of pay-invoice so it didn't go through, fine; but now it seems still stuck
diana_coman: uhm, weird stuff: sent the !!v on that !!pay to deedbot but no answer; and otherwise it does answer to further !!ledger (not showing the payment) -> did I mess something up there, trinque ?
diana_coman: lobbes, re php 7.2 I'm totally lost as to what new (as opposed to old) mess it brings in
diana_coman: at any rate it's not the sort of thing I'd try directly on a remote machine as it messes up with the local gcc so this will be fun
diana_coman: alternatively the hello message stays single-packet and uses a keccak hash of the public key (n,e,comment) as "account ID" so 3.1.5; then key is sent via Data packages and basically I need to define another type for RSA public key; server can ask/expect the RSA key *every time* to preserve same answer behaviour or otherwise only if it doesn't know the key
diana_coman: http://btcbase.org/log/2018-04-17#1801097 <- mircea_popescu looking at it again from all sides I think the consideration is not necessarily misplaced in itself i.e. multi-packet there does make a mess out of the neat "these are the only *packets* you may ever send"; this being said though, I don't quite see the solution that would *also* preserve the desired "whatever it is, server responds the same: with a set of X keys"
diana_coman: ok, so then there is hello-new-account with the R public key; there are otherwise *only* X messages? and if no X key then ...account lost or can it re-send "new account" and basically retrieve the old one?
diana_coman: the idea was that if client loses all his X keys, he can send a hello message again
diana_coman: hanbot, try it now; wp messed up the link, gah
diana_coman: obviously, I could also null-terminate specifically for this but overall I'm not convinced anymore it's worth the mess
diana_coman: ave1, aha, byte by byte was what I ended up doing at testing stage just to see it really working; hopefully I'll still get it working properly with To_C as such and then I can still avoid the C.Strings, stick with the procs To_Ada and To_C; it's not going to be pretty but at least the mess is as small as I can see a way to do it now
diana_coman: ave1, tbh I've been trying to avoid .c.strings at least but atm it looks set to still make its way in because calling ada stuff from c and getting char * result is an even worse mess with interfaces.c only (i.e. with char_array vs chars_ptr)
diana_coman: as all my non-adacore environments proved a mess
diana_coman: fwiw it looks like some mod_security mess
diana_coman: the trouble with current version is that it's still messed up by endianness (the keccak constants are 64 bit *values* rather than bit streams)
diana_coman: mircea_popescu, and then when client enciphers with 1 from a set of 8 selected from those 16: does this mean reusing that 1 key for as many 128 chunks that particular eulora message has? or do you mean 1 per chunk ?
diana_coman: asciilifeform, possibly I managed to screw it up in an even more basic way; here's the test function itself (this one gets called repeatedly for each key and each message)
diana_coman: I think there'll be some crypto play in this house, lol; tbh as a child this part of "secret" messages was terribly fun even as idea only
diana_coman: he hates mess, lol
diana_coman: not even a mess, he's good with it : on top of bath tub
diana_coman: planeshift is an open source mess that was used to jumpstart eulora basically
diana_coman: Framedragger, it's not the syntax, it's the whole "approach"; though if you find *that* acceptable, I guess you'll find planeshift code just as acceptable with all its 20-level dependency hell, mix-and-match mess of concepts (hey, what IS a concept anyway and what do you mean there is something other than interface anyway)
diana_coman: iirc I *did* mention dwarf fortress some time ago precisely because of some similarities; I think mircea_popescu left a message on their wiki/forum/whatevs but nothing/nobody materialised as a result
diana_coman: I tend to agree with that, BingoBoingo ; so I guess some mess is cleared up, no splitting of the coin allowed
diana_coman: http://btcbase.org/log/2016-11-04#1562842 <- I find myself agreeing and disagreeing with everyone on this so it's a right mess; agreeing with mircea_popescu on it being close, quite disagreeing with him on this newly found democratic idea of passing on the hot potato; agreeing with BingoBoingo on the importance of one voting for oneself first, I'll do just that and vote for myself first; will vote for hanbot 2nd for her rectibu
diana_coman: ha! welcome shinohai to the mess of planeshift legacy code
diana_coman: mircea_popescu, asciilifeform currently eulora messages exchanged between client and server are between 43 and 2048 bytes (really upper limit and rarely seen); this being said, the current system of messages/ exchanges between eulora client and server is quite a mess from many points of view, so it's set to be changed too
diana_coman: I'll add only the message that considered to be "what Tolkien had to say" (even though he did it through "not-real-life universe") namely that all and everyone (yeah, the ordinary and no, they are not made anything by gandalf quite pointedly not made anything by him) is in some way responsible /called to do something when shit hits the fan; that is all I guess
diana_coman: well, a pgp message at this point quite serves as that letter I guess

Random(trilema) | Download daily DB snapshot | Get Source Code