verisimilitude: I'm starting work on networking libraries in Ada; I've started with UDP; I'd appreciate receiving some thoughts on this package specification:
asciilifeform: verisimilitude: http://www.loper-os.org/?p=2557
verisimilitude: I'm aware of your library, asciilifeform, and I've taken a look at how you approach the problem for some things.
asciilifeform: verisimilitude: what do you propose to do differently ?
verisimilitude: My library is more abstract and uses an approach that entirely ignores the existence of Unix and C in the package specification.
asciilifeform: verisimilitude: how do you intend to put the os glue? inline asm ?
verisimilitude: I intend to only do so in the body of the package, which any user of the library wouldn't need be aware of.
verisimilitude: My library also makes fewer decisions than yours, such as the datagram size.
asciilifeform: i confess i do not see what is gained. it isnt as if user of my udp lib needs to know anything of the c glue.
asciilifeform: verisimilitude: diana_coman's variant already has a knob for packet size.
verisimilitude: Oh, that one uses indefinite types, then?
asciilifeform: i confess i utterly don't grasp : why not pick and open problem ? why this ?
asciilifeform: *an open
verisimilitude: This is work for other things.
verisimilitude: My UDP interface will resemble the TCP interface I've planned in several ways, but I've not started on that beyond some design, yet.
verisimilitude: I don't like POSIX Sockets, asciilifeform.
asciilifeform: verisimilitude: do you intend to make own ? how will it differ from traditional ?
asciilifeform must bbl. verisimilitude if you write at length on the subj, i'ma read when get the chance.
verisimilitude: I'm still muddy with some details, concerning the TCP library, but that's due to my more general being green to Ada; I should also note I want to design similiar libraries for Common Lisp, so I'm designing libraries to work roughly the same in both languages.
verisimilitude: Clearly, for TCP, the client should have little or no difference from the client of the file system.
verisimilitude: As for the server, I'd prefer a ``connection generator'' approach, where you have a server object which provides the means for different tasks to get bidirectional streams representing a single connection that they then handle independently.
verisimilitude: I could go into more detail, but I similarly have other things I could be doing, so it can wait.
shinohai: Reading #trilema logs yesterday got me thinking would be worthwhile to pick up where esthlos left off on his vtron (add diff function, etc) though now wonder if exercise in futility, since apparently this is nothing more than kindergarten Strafbataillon, and any discussion of subj merely fodder for asciilifeform to kek over with MP. http://logs.nosuchlabs.com/log/trilema/2019-09-03#1933448
snsabot: Logged on 2019-09-03 14:00:11 asciilifeform: ( a surprisingly well-populated штрафбат . and asciilifeform makes an effort to read its log and reply 2-3x / daily )
asciilifeform: shinohai: picture, fella knocks on your door. 'behold, my great invention' you : 'but this is bicicle' him : 'i am well aware of bicycles!' you : 'this looks exactly like the bike i had when i was 11, but with odd protrusions' him : 'no!! it has radar-absorbing paint ! and can drop chaff against surface-to-air rockets' you : '...'
shinohai: heh
shinohai: Anyway, this morning's experiments show that esthlos V won't press trb correctly. Barfs on asciilifeform's numbered bitcoin vpatches, eg:
shinohai: Checking bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch against bitcoin-asciilifeform.4-goodbye-win32.vpatch.asciilifeform.sig ..
shinohai: Renaming the patches allows press of sorts, but then only presses src/ folder. No makefile in sight.
asciilifeform: shinohai: afaik it was never upgraded to keccak
asciilifeform: shinohai: or are you speaking of the older patches
shinohai: http://blog.esthlos.com/esthlos-v-redux/ <<< this one
asciilifeform: which patches tho
shinohai: (using own keccack patchset from regrind earlier this year)
shinohai: afaik keccack trb not on btcbase
asciilifeform: a.
asciilifeform: then nfi ( i admit, have not tried this vtron 'in anger' )
asciilifeform: today i use diana_coman's ( which is actually a patch of my original v.py , to make use of phf's vdiff )
shinohai: Have up to this point used mod6's perl V, was merely curious as to whether anything useful was to be found in esthlos version.
shinohai: perl makes my head hurt.
asciilifeform: shinohai: ever think about writing your own vtron ?
shinohai: Started own lisp vtron, decided to take a look at a few other implementations to see if any ideas I could cobble.
asciilifeform: shinohai: i still even today recommend to people to start with reading mine, it is the shortest (if not 100% featureful)
shinohai: I actually did read yours and made horrid first attempt in pure bash just for shits and giggles.
asciilifeform: there's no reason you couldn't have a practical one in bash
asciilifeform: ( given as most of the work in all current vers is still gpg callout )
verisimilitude: So, no additional thoughts, asciilifeform?
asciilifeform: verisimilitude: not atm. ( i personally don't like oop , and don't see its addition as useful feature ) but will read whole proggy when you post it.
verisimilitude: Alright, then.
verisimilitude: This design seems rather finalized, so I'll start implementing it soon. I'm aiming to have it finished by or before 2019-09-09. I'll return then to show you, asciilifeform.
PeterL: https://www.washingtonpost.com/business/2019/09/05/tyson-launches-alt-shrimp-made-plants-it-could-be-jumbo/ << the march toward "I can't believe it's not meat" continues
asciilifeform: lol
bvt: asciilifeform: answered; btw, can you release the source of the 'm' kernel (in two steps - 4.9-genesised to 3.16, 3.16 to 3.16-m)?
asciilifeform: bvt: i was gonna release it as patch, but got stuck on 'hm which to genesis'
bvt: this way, perhaps will learn if the approach with rolling back by doing vpatches is working
asciilifeform: bvt: will put it as old-fashioned patch in near future (hands pretty full atm sadly)
bvt: currently i'm sure that we don't want to have multiple genesises for 3.x-m, 4.4-rockchip, 2.x-amd64 - but it's hard to tell how it will work in practice.
bvt: ty
asciilifeform: !q uptime
snsabot: asciilifeform: time since my last reconnect : 20d 8h 16m