← | Results 17751 ... 18000 found in all logged channels for 'f:diana' | →
(trilema) diana_coman: http://btcbase.org/log/2018-10-01#1856937 -> yes, please; also yes, can leave the old disk plugged in to see when it dies, why not (iirc there should still be 1 usb2 empty slot on my RC as the other one has an FG)
(trilema) diana_coman: http://btcbase.org/log/2018-10-02#1857110 -> if it's anything like mine, it'll be mostly loud complaints from php because "time zone not set!!!" and similar (apparently php version on the RC is too new for its own good)
(trilema) diana_coman: BingoBoingo, asciilifeform ^
(trilema) diana_coman: http://btcbase.org/log/2018-10-01#1856931 -> today works anytime really, just let me know in the logs
(trilema) diana_coman: http://btcbase.org/log/2018-10-02#1857131 -> afaik obesity does increase risk of miscarriage
(trilema) diana_coman: heh, my next line there :P
(trilema) diana_coman: mod6, I know what you mean re too-many-things-at-once (from my pov also, ideally 1 at a time but that's a luxury that I rarely get to fully indulge in, what can I say)
(trilema) diana_coman: yes, it's better stated that way: focused but not limited to trb
(trilema) diana_coman: I certainly think mod6 is and has been doing a great job in maintaining the v-tree for trb - and as I said before, I don't think it's something linked to tbf chair position
(trilema) diana_coman: http://btcbase.org/log/2018-10-01#1856404 -> ugh; to my mind a chair position is precisely not a "here's detailed list of tasks" position, it can't be
(trilema) diana_coman: PeterL - was waiting on your patch for the 255 instead of 256 error on keccak but since it didn't come, I patched it http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/comment-page-1/#comment-4254 ; ref http://btcbase.org/log/2018-10-01#1856345
(trilema) diana_coman: so then that, fine; not to do with trb though per se, cool
(trilema) diana_coman: I don't see that related to one specific chair, I guess; i.e. I don't even see a problem if mod6 wants to continue testing the patches and maintaining the tree even if he is not trb chair (not that he has to continue, but neither does he have to pass the job on if he is not chair anymore)
(trilema) diana_coman: I agree that there is plenty of work to be done on trb, sure; but I don't see the subtraction thing
(trilema) diana_coman: i.e. what does one have to do with the other? what, hanbot should now start working on trb if she becomes chair?
(trilema) diana_coman: I don't follow your reasoning there
(trilema) diana_coman: I think that's precisely what the chairs need to figure out: "what might fit under this " and be useful, ofc
(trilema) diana_coman: i.e. tbf going into uncharted territory and thriving
(trilema) diana_coman: sure it is, but that's more of the point from what I see
(trilema) diana_coman: yes but further afield - not even focused on *code*
(trilema) diana_coman: asciilifeform, my understanding is that tbf's scope is not limited to trb, nor focused specifically mainly on trb
(trilema) diana_coman: ave1, you forgot to change manifest file for your zfp_4_assert.vpatch? (i.e. it's missing from the list in manifest)
(trilema) diana_coman: I mean: please "snarf" as per existing term of art
(trilema) diana_coman: ah, that makes more sense
(trilema) diana_coman: http://btcbase.org/log/2018-09-30#1856174 -> I suppose new world hostels might be better than old world ones, esp italian ones (though I'll grant that they were best for meeting people, yes)
(trilema) diana_coman: uhm, what unknown?
(trilema) diana_coman: anyways, I'll get around to patch my node and see what that gets
(trilema) diana_coman: that is the most useful yes; but also 1 block from 192.187.99.74
(trilema) diana_coman: ah, BingoBoingo's, yes
(trilema) diana_coman: and hm, it seems that it's more like ~all from one single node actually? (pizarro hosted, yes but is that the only one that is hosted by pizarro?)
(trilema) diana_coman: I don't see 149.56.19.79 in the list of advertised nodes
(trilema) diana_coman: really? I thought there was a site you were recommending precisely for "good ada code", wasn't there?
(trilema) diana_coman: asciilifeform, aha! let the code stay there though for future reference now
(trilema) diana_coman: possibly even buy a bunch of cheap ones, unlock and then just plug into them whatever/wherever sim(s)
(trilema) diana_coman: fwiw Mocky I'd suggest unlocking your phone anyway
(trilema) diana_coman: asciilifeform, what's the shortest delay you tried?
(trilema) diana_coman: asciilifeform's published test data seems to match what I got on my initial tests with 1 second delay; my current plan is to collect first at least 1 week worth of data and then to repeat the experiment with a. smaller delays b. several senders perhaps
(trilema) diana_coman: also, note that eulora does not enforce "all players within sight get position update" because server does not push basically; it's up to clients to request what they want, when and if they want it
(trilema) diana_coman: it's the move to generic + relaxation of some constraints (because of generic and because of using Calendar for local time to log)
(trilema) diana_coman: but otherwise the udp_tester.vpatch makes some changes to udp lib that are really just for testing (i.e. I think they should not be part of production use of udp lib)
(trilema) diana_coman: the rest then are for the tester only - let me know if you give it a spin and how it behaves
(trilema) diana_coman: asciilifeform, ^ there is also a small .vpatch for that issue with null chars at ip
(trilema) diana_coman: I kept waiting on phf and esthlos since they were working on it as far as I could tell; and http://btcbase.org/log/2018-09-27#1854921
(trilema) diana_coman: asciilifeform, not that I know of; I use: http://btcbase.org/log/2018-09-27#1854956
(trilema) diana_coman: fwiw I *did* specifically state in the manifest that it's using Keccak hashes
(trilema) diana_coman: I'll have to, since the sigs need to fit the .vpatch file name, yes
(trilema) diana_coman: asciilifeform, ok, I'll mirror your sigs too and link to the page anyway; a bit later today
(trilema) diana_coman: I added the manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches
(trilema) diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron
(trilema) diana_coman: I'll add the patches for the tester on top of the above, later today
(trilema) diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19
(trilema) diana_coman: adding to the above: old v can still be used to check the sigs, to avoid manual check; so use old v to check the sigs and once satisfied, just feed patches to vpatch
(trilema) diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be?
(trilema) diana_coman: re using vtools, I currently first check sig (so by hand, separate 1-line) and if ok, then feed patch to vtools
(trilema) diana_coman: http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!
(trilema) diana_coman: asciilifeform, yes, that one
(trilema) diana_coman: asciilifeform, hm? I can't quite parse that q; if it helps: I'm using phf's vtools, yes
(trilema) diana_coman: as said above: it can certainly wait 24 hours and preserve history, what; and anyway, the tester part I see more as a branch only, because of the modifications required for testing purpose only (e.g. making the udp generic)
(trilema) diana_coman: asciilifeform, works; publishing code is anyway good excuse for another review, so it'll take me some time too anyway
(trilema) diana_coman: or whatever, "keccakhash"
(trilema) diana_coman: out of curiosity: why "asciilifeform_keccak" rather than "keccak"?
(trilema) diana_coman: asciilifeform, I'm not aware of a converter but pinging phf to correct me if I'm wrong
(trilema) diana_coman: I'm also not sure re naming convention for patches as I thought it was to use "_" ? i.e. why is the errata named udp_errata.asciilifeform?
(trilema) diana_coman: asciilifeform, udp tester seems to be nicely running uk->uy and uy->uk so my next step on this will be to publish all the relevant code; since this is effectively on top of udplib, I'd patch it on your tree; mind moving it though to keccak?
(trilema) diana_coman: mircea_popescu, 1s delay seems to result at least on UK->UY direction on preserving even order at destination, at least at this hour; at any rate, I'll look at it tomorrow and unless I can spot some trouble, it should then be chugging along
(trilema) diana_coman: my point above was that "derping for week+" + obscure "fault you have to fix" sounds precisely like "I keep asking for a bribe and I did not get any!!"
(trilema) diana_coman: asciilifeform, tsk, that's a fee!
(trilema) diana_coman: to me it sounds very much like the usual bakshish/peshkesh request, lol
(trilema) diana_coman: what'd DINAMA asciilifeform ?
(trilema) diana_coman goes to tweak the knobs again, will bbl
(trilema) diana_coman: to recap so I don't miss anything: no counter sent in header for packets; packets will have sizes between 6 (header length so minimum) and 2048; sender will have a 1second delay between each new package sent
(trilema) diana_coman: (it can be done though, if one really wants it, basically an Ada task to be repeated hourly, but I don't see the benefit to that)
(trilema) diana_coman: receiver is always on, but there's not much point in sender being always on
(trilema) diana_coman: btw, there is no "idle", no; sender sends and finishes, what idle? it'll get started again by a cron task
(trilema) diana_coman: k, will add delay 1 sec between packets at sender, not a problem
(trilema) diana_coman: http://btcbase.org/log/2018-09-25#1854302 -> I took that to mean he wants to select only those of a given size, hence ..yes, easy
(trilema) diana_coman: http://btcbase.org/log/2018-09-25#1854304 -> burst is burst so yes, dumping all without any delay; among other things that's why those pilot tests, to decide on/if delay
(trilema) diana_coman: asciilifeform, that sounds possible
(trilema) diana_coman: got 31/75 even when all sizes were below 300
(trilema) diana_coman: asciilifeform, apparently there is also various sizes bursts
(trilema) diana_coman: aha; meanwhile playing here with the dubious UY->UK direction and I'd say it's pretty clear that bursts of more than 50 packets or so increase packet loss visibly; I suppose this makes for a nice thing to look at specifically once I get one week of data or so
(trilema) diana_coman: isn't this something more for next step at data analysis? (i.e. minus the two logs and highlight missing stuff)
(trilema) diana_coman: asciilifeform, well, how can it know? i.e. they might come...later, no?
(trilema) diana_coman: asciilifeform, any feedback re latest logs? anything else you'd want in there?
(trilema) diana_coman: if/when they wait for specific replies
(trilema) diana_coman: asciilifeform, that sounds very useful for eulora clients basically
(trilema) diana_coman: mod6, certainly; I'll wait pretty much for any feedback on it all and otherwise it's quite ready to run for a week or more (receiver always on, sender as some hourly cron taks)
(trilema) diana_coman: from the previous UK->UY run, here's the latest version of logs (new: counter so that order of packages can be followed more easily): sender log http://p.bvulpes.com/pastes/zktb9/?raw=true receiver log http://p.bvulpes.com/pastes/2YPqs/?raw=true
(trilema) diana_coman: I wanted to run this because it mimics much closer eulora client<->server communications but otherwise might set up different end nodes
(trilema) diana_coman: tbh if anything I start suspecting at most the router
(trilema) diana_coman: I had tcpdump sniffing at same time and it reported same 19, not more
(trilema) diana_coman: mod6, as far as I can tell they got lost in transit but I don't know *how close* to the machine itself (this UK machine is behind a router, I've set up port forwarding for it); basically atm the UK->UY vs UY->UK is pretty much client->server vs server-> client communication
(trilema) diana_coman: mod6, yes! onth a batch of 20 packets only rather than 100 made it fully
(trilema) diana_coman: but it does seem to be just too much for local setup/saturating basically
(trilema) diana_coman: asciilifeform, ftr, just ran a batch 100 packets from UY to UK and... 19 made it! oh boy
(trilema) diana_coman: will do; I can think of a few other routes as well but possibly first have it run on one route for a while and then expand
(trilema) diana_coman: no, I am still fuzzing about; but will try in a bit
(trilema) diana_coman: logically speaking, one wouldn't expect them to be, no; the foggiest part atm for me is that interval from ~512 up to ~1500
(trilema) diana_coman: I can certainly run such a test too if we want to check that specific situation; now that I got ~everything in place, knobs can be easily turned for sure
(trilema) 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
(trilema) diana_coman: the pilot test is UK -> UY (same as yesterday's)
(trilema) diana_coman: the last column in the receiver log is now a count of payload octets that are different from what is expected - if any such octets are observed, the receiver will log now their actual position + value in a different log file; so far I haven't seen any error of this type
(trilema) diana_coman: for completeness, the logs from the new pilot test: sender log is http://p.bvulpes.com/pastes/SdU8P/?raw=true and corresponding receiver log is http://p.bvulpes.com/pastes/OXUWa/?raw=true
(trilema) diana_coman: ftr tester sends as above payloads between 6 and 2048 rather than 0 and 2048 because the first 6 octets are the header part (things like size sent and time when sent)
(trilema) diana_coman: following from the above: currently order and order-mismatches *can* be calculated at data analysis time based on the 2 logs; alternatively, I could add another 2 octets to the tester's own header to store an order number so receiver can also report directly any order-mismatch - not sure if that's worth it though, any thoughts on it?
(trilema) 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
(trilema) diana_coman: http://btcbase.org/log/2018-09-24#1853827 -> sounds at least like something worth getting some data on, yes; I wouldn't even be surprised if ~any frag results in mostly lost packets
(trilema) diana_coman: anyway, the above examples show also current logs on both sides - if anyone has feedback on it/wants to see something else logged, talk now
(trilema) diana_coman: that would certainly fit this observed mess, yes
(trilema) diana_coman: anyways, this is just tiny pilot, not yet worth much analysis as such
(trilema) diana_coman: basically one of each batch except one batch that was fully lost
(trilema) diana_coman: asciilifeform, yes: http://p.bvulpes.com/pastes/1DmdC/?raw=true (IP edited out; you can easily match them by sizesent+timeSent
(trilema) diana_coman: yes, will do
(trilema) diana_coman: yes, I'm trying to figure out mainly if I can at least make sure that it IS sent out of sender; then it can ofc get dropped anywhere on the route
(trilema) diana_coman: well, technically speaking 6-65535; specifically: http://p.bvulpes.com/pastes/b2MqA/?raw=true
(trilema) diana_coman: hm, you mean it's guaranteed that the package is sent and out of the buffer before you can call send again ?
(trilema) diana_coman: asciilifeform, yes, but if one sends a burst of 4 packets , they can overflow that buffer and get dropped, don't they?
(trilema) diana_coman: hm, a first tiny pilot test of the UDP send/receive looks quite dire (4 in 20 made it, when sent in batches of 4, random lengths); however, I don't know if it's not just overflowing the out buffer to start with (since default value in /proc/sys/net/core/wmem_default is 212992 so real would be half that iirc)
(trilema) diana_coman: makes sense, will replace any nulls with spaces
(trilema) diana_coman: and no, certainly not variable-length strings
(trilema) diana_coman: asciilifeform, I combed your patch and did not see any fix for this - did I miss anything? (I did not press it because my code was already changed anyway in all sorts of ways; I read the patch though)
(trilema) diana_coman: asciilifeform, the IP_To_String will return a string with null chars (in Ada: Character'Val(0)) at the end for IPs that are shorter than 16 chars (e.g. 98.20.105.41); I'm in 2 minds whether to make it change those to spaces (keeps size same) or otherwise return some len; since it's your lib though: what is your take on it?
(trilema) diana_coman: asciilifeform, thanks!
(trilema) diana_coman: nicoleci, I think my comment is in your blog's moderation queue
(trilema) diana_coman already sees the log summary: "Asciilifeform cleaned the mouse in ccl4 after briefly clicked."
(trilema) diana_coman: mod6, glad to hear you are fine!
(trilema) diana_coman: nicoleci, lol
(trilema) diana_coman: ahahah, I can see where she's coming from
(trilema) diana_coman: mircea_popescu, yes, it's not exactly a rare thing unfortunately
(trilema) diana_coman: <mircea_popescu> this seems even perfectly reasonable, who wouldn't want to be right, until you understand the undertone. which eminently was "and perfectly willing to put on the adequate blinders for this effect" -> imo that is better expressed as "only interested in not being wrong" - quite different from being interested in being right
(trilema) diana_coman: aha, got it; mixed up there, ok
(trilema) diana_coman: or the engineers? lol
(trilema) diana_coman: mircea_popescu> asciilifeform in the girl's own words, "only interested in their being right". -> is this re her summaries being right or what?
(trilema) diana_coman: ah, as in: in them being what you asked of her? that's fine, sure
(trilema) diana_coman: mircea_popescu, well, how does she evaluate if they are right?
(trilema) diana_coman: tbh if I were to critique her summaries I'd start pretty much from same point as with the 5yo i.e. the way they are know they read as if she doesn't actually have any idea what those terms she uses there mean even at a basic level and she doesn't even flag them as such (i.e. "hey, this afiejif wtf is it???"); to the extent that it all ends up as mechanical re-phrasing, it's quite stupid
(trilema) diana_coman: all I insist on is that he either asks someone or otherwise check in dict for words he doesn't yet know
(trilema) diana_coman: heh, if I'd insist my child read *only* what he understood, he couldn't possibly read ~anything!
(trilema) diana_coman: fwiw I was talking strictly of *new* stuff for now; notice that I did *not* regrind eucrypt either - that can wait; new stuff however should use keccak imo
(trilema) diana_coman: once it's ready, I'll publish it anyway and I don't see any reason why one couldn't run it anywhere they want it, ofc
(trilema) diana_coman: anyways, will wait for mircea_popescu to weigh in on this too; atm I still need to set up the main stuff and then those are params to adjust/set as required
(trilema) diana_coman: heh, that would be interesting to see at least, yes
(trilema) diana_coman: not a bad idea at all; at it's simplest I was thinking simply serial numbering the payloads and logging on both sides since putting together the 2 logs afterwards is straightforward, 1-line thing
(trilema) diana_coman: if you have a better idea, please expand
(trilema) diana_coman: atm I'm just playing around with generic to wrap my head around it! lol; but receiver can haz max size and then report, no?
(trilema) diana_coman: asciilifeform, yes, atm I'm looking at it for the test harness, for which I think it fits great (since I wouldn't want to go writing 1-65535 explicitly if I can help it)
(trilema) diana_coman: in other pleasant surprises, this generic thing in ada is very useful
(trilema) diana_coman: I can fully see the point to that, certainly
(trilema) diana_coman: my approach has been: try with keccak; if fails, for now at least, try with old sha-based
(trilema) diana_coman: asciilifeform, I can see the point given how often I went already "oh, this is /not is keccak/sha"
(trilema) diana_coman: asciilifeform, not full as far as I'm aware; there is http://trinque.org/2018/06/02/v-manifest-specification/ re manifest
(trilema) diana_coman: possibly because I did not yet fully digest the new one (or not as well as old one)
(trilema) diana_coman: I pressed only the keccak branch of phf's
(trilema) diana_coman: and I actually have both on for now, hence yeah, I just pressed your patch with old V
(trilema) diana_coman: asciilifeform, I know that pain, honestly; I still trip over this change and I wouldn't even say that I have as convenient a workflow with new tooling as I had with old
(trilema) diana_coman: cool; I was just surprised + trying to understand what is going on
(trilema) diana_coman: uhm, wait; you mean you think it might still change and *not* be keccak? or current keccak version not surely if keccak? or...dunno, what?
(trilema) diana_coman: the issue at hand is more simply that being sha means it will have to go through regrind at some point and so I'm not very keen on adding to it patches just to have what to regrind later; but maybe that's just me
(trilema) diana_coman: I wouldn't expect there is such a thread, no; at any rate, last discussion on this I think starts here: http://btcbase.org/log/2018-07-06#1832406
(trilema) diana_coman: asciilifeform, I don't get it: are you saying you need mircea_popescu to officially declare it something or the other or what?
(trilema) diana_coman: asciilifeform, since your udp genesis is using the sha hashes + a "history" file I'm not sure: do you have something against the move to keccak + standard manifest file for v-trees?
(trilema) diana_coman: anyways, rounding up, it seems my next step here is to 1. set up the testing harness http://logs.bvulpes.com/trilema?d=2018-9-18#431515 2. put asciilifeform's lib to use in smg.comms
(trilema) diana_coman: asciilifeform, the timeout was the only one I hesitated on too (and the only one I'm using in the original test for that matter) but precisely like you, when I thought of it, I came up with "well, threading should be enough anyway " and uhm, no reason why it's *needed* there
(trilema) diana_coman: fwiw, I'm also quite grateful that ave1 published it now - it pointed me to ada inline assembler (I hadn't really looked at it before!) and it gives me some time to hopefully get a bit more used to it *before* I'll need it anyway
(trilema) 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
(trilema) diana_coman: and I actually think it is a step in the right direction since it gets rid of C
(trilema) diana_coman: it's certainly NOT a waste!
(trilema) diana_coman: asciilifeform, precisely my point, right?
(trilema) diana_coman: http://logs.bvulpes.com/trilema?d=2018-9-18#431566 -> I'm thinking of 2 there ; asciilifeform's lib also provides I think a good interface - I don't see any reason why one couldn't just change /swap the underlying .c file with ada or asm at a later date without having to change otherwise anything of whatever one builds on top of the lib (i.e. relying on the lib's interface)
(trilema) diana_coman: asciilifeform, ahahaha, fits
(trilema) diana_coman: I guess what happened is that deedbot gave a lot of voice!!
(trilema) diana_coman: asciilifeform, ah, I forgot to mention it explicitly but yes, my tests include ave1's gnat as well as adacore's gnat; this is pretty much for any ada code I test
(trilema) diana_coman: anyways, will give this some more thought
(trilema) diana_coman: it's not fully clear to me if it's something needed /desired atm; at any rate, compared to where I was 2 days ago, it's great - all of a sudden it went from "need to do this from scratch, ugh" to "there are 2 republican libs with 2 approaches, which one fits best my needs?" ; I'm rather delighted to be honest
(trilema) diana_coman: I'd expect that, yes; it was re <asciilifeform> user is told e.g. 'bind eggoged', 'send eggoged', rather than linux-specific whys ( and for that matter, on a working box udp never eggogs , i haven't even any notion presently how to make it , aside from bind()ing a nonexistent local ip)
(trilema) diana_coman: re eggogging udp on a machine, perhaps trying to send something above the UDP packet limit I'd say (it's ~64k iirc)
(trilema) diana_coman: asciilifeform, the udp lib can request it in a certain format; the rest is layered on top, I don't really see why it needs string representation or eating a string; anyways, splitting hairs on this
(trilema) diana_coman: right; in terms of simplicity I can't say atm that I'm able to see anything that can be further cut off from the udp part itself indeed (the string <-> ip part doesn't seem to fit in there necessarily but that's not udp per se anyway)
(trilema) diana_coman: ah, because send/recv will return -1 for error whatever it might be anyway
(trilema) diana_coman: on a different note: I really had trouble coming up with a *full and reliable* set of errors that the UDP ops in linux might throw up; from linux man pages I gathered the unhelpful "all errors from IP may be returned by recv /send" - and looking at that list, it makes for a waaay bigger set than what I see you considered
(trilema) diana_coman: asciilifeform, myeah, the actual length is likely to be different at the very least, but that's not a big issue
(trilema) diana_coman: as I was saying earlier: atm the fixed packet length might clash a bit with what I need but it's not even fully clear it's not *better* to have a fixed packet length anyway
(trilema) diana_coman: I can see your point there; it was literally a question to understand the reasoning behind the choice, nothing more
(trilema) diana_coman: yes, I'm not crying over those
(trilema) diana_coman: asciilifeform, any reason why your lib does not support any options at all to be set for the UDP socket?
(trilema) 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
(trilema) diana_coman: asciilifeform, if I understand your lib correctly, it aims to expose only a strict & minimal set of UDP calls; atm it uses C code for the actual socket part but in principle this layer could be replaced at a later time by some Ada layer while keeping the rest as it is, correct?
(trilema) diana_coman: version 4. GNAT.Sockets that is built on top of 3. above and mainly serves to force Streams for everything
(trilema) diana_coman: for completeness, version 3. GNAT.Sockets.Thin that is an Ada wrapper on C system calls containing however questionable approaches (e.g. returning access to String so effectively a pointer but worse than this: allocating memory on the heap and leaving the de-alloc to the caller...)
(trilema) diana_coman: to round this whole thing up: 2 days ago it seemed I had only the gnat.sockets/ thin layer option which wasn't fit for purpose; now I have 2 more options: 1. ave1's ADA implementation of UDP sockets using directly ASM inline 2. asciilifeform's light UDP sockets lib that uses C code for needed UDP sockets calls but provides an Ada wrapper so that any code using the lib can call Ada methods only
(trilema) diana_coman: asciilifeform, confirmed working nicely with its own tests + adapted client/server test as used previously
(trilema) diana_coman: thanks asciilifeform! I'll read it and get back to you
(trilema) diana_coman: the question+kick&ban sounds good to me - kicking "silent" aka "I'm part of it because I hang about in here doing nothing" is even needed by now, I'd say; I can also see very well its usefulness for other channels; while atm #eulora tolerates the allah-spam, it could certainly do without it especially at less-quiet times
(trilema) diana_coman: ah, I did not mean torvalds!!! I meant ave1's code
(trilema) diana_coman: mircea_popescu, read on, he published it meanwhile and I am looking at it right now
(trilema) diana_coman: yay, thanks lobbes
(trilema) diana_coman: ahhhh, it returns that value, nm
(trilema) diana_coman: does it just block until it reads to fill the buffer or how does that work?
(trilema) diana_coman: ave1, hm, the recv_from doesn't return the length of the received string?
(trilema) diana_coman: at any rate ave1 this doesn't look bad at all in that it is an ada layer rather than just wrapping the c calls
(trilema) diana_coman: I can just about see next version of linux-with-feelings
(trilema) diana_coman: sounds quite likely; and tbh that http://btcbase.org/log/2018-09-17#1850713 makes for weird/sad/hysterical reading depending on pov
(trilema) diana_coman: ugh, sounds like a mess
(trilema) diana_coman: ave1, if I get the structure right there, you have an empty root package Suckit and then children packages net and types; there seems to be also Suckit.Syscall that I see listed as dep in suckit.types but I can't find the source for?
(trilema) diana_coman: I'll read and get back to you
(trilema) diana_coman: thank you ave1 ! I'll take it
(trilema) diana_coman: ave1, the basic thing is that it's a proper hierarchy (so each post in one (sub)category and not in 10)
(trilema) diana_coman: lobbes, esthlos, hanbot, ave1 - do you have something against using categories on your blogs? I find well-defined categories to be really helpful in finding stuff but on your blogs everything is in the "Uncategorized" category
(trilema) diana_coman: looking forward to it
(trilema) diana_coman: ave1> I'm aiming at a small library with support for UDP, TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. -> mind publishing somewhere this part then?
(trilema) diana_coman: arguably it helps if others know what you are working on - perhaps one can help at some point or at least not duplicate the effort, that's all
(trilema) diana_coman: gah, null terminator and zero starter and what next
(trilema) diana_coman: ave1 hey, that would be very useful! but honestly, why not say it earlier?
← | →
Download hourly DB snapshot | Get Source Code