asciilifeform: mostly indian/chinese d00dz embedded in usg.academitardia, doin' their india thing.
asciilifeform: faux-fpga-worx aint exactly the most fashionable scamolas, we're looking at obscure, vs 'sexy', frauds.
asciilifeform: in this case it's simple madoff fraud, imho, rather than any sort of peculiar freudism. i.e. simple 'we lied for moneys and dun wanna to jail'
asciilifeform: i expect academitards-with-seekric-sauce are 98% 'if i published, errybody will know that it never worked', 1% 'if i published, errybody will know that it consists of ripped off old open sores' ( personally met one of these ! ) , and 1% 'it worx and we're gonna patent!111 and getrichquick' , bolix-whisperer style ( i have no direct evidence that these exist, but some indirect clues )
asciilifeform: simple morons would be an improvement.
asciilifeform: ( 'electric' serpent is actually somewhat nontrivial, on acct of the gnarly 'key schedule' algo and the arrayed sboxes )
asciilifeform: mircea_popescu: in re these lulz, at one point asciilifeform dug for 'anybody ever verilog-ified serpent?' and found a stack of 'papers'. any src ? mno. but plenty of 'discussion' of supposed 'implementation', in the traditional nadia henninger style .☟︎☟︎
asciilifeform: it is even possible that they 'cheated' and passes System.Address's around, reverting to c monkeyism.
asciilifeform: diana_coman: i happen to know that i'm not the only one who swore off secondarystack -- the 1990s space probes folx did also. but unsurprisingly they never published anyffing re how they filled the resulting cavity in functionality. ( at least they did not have to deal with linux kernel, afaik, ran on bare iron , so no To_C etc horrors )
asciilifeform: mircea_popescu: 'patch' is not the applicable name for the required ragnarok. whole kernel is like this, 9000 layers deep.
asciilifeform: so apparently i gotta reimplement bounded strings nao..
asciilifeform: to continue in these lulz : ada std has a 'bounded string' type, that superficially is defined as exactly how i wanted to do 'path' type earlier. but! but! if actually invoked, it -- for no logical reason afaik -- prevents the invoking package from being declared stateless ( i.e. pragma Pure ), and this propagates ad infinitum , to caller.
asciilifeform: ( bvt's point re inet_addr applies here -- the actual syscall in fact demands a tardstring, i.e. nulltermed )
asciilifeform: on top of this, i'm thinking all of this spackle, oughta be unified, the paths, open(), udpism, tempism, etc. and eventually rolled into tmsr.gnat .
asciilifeform: aanyway i'ma stop here for nao, lest head expload.
asciilifeform: and errything else i've written worked a++ as them.
asciilifeform: 1 obvious solution, that iirc diana_coman at one point resorted to somewhere, is to discard the 'librariness' and make the thing a 'put this in your src' type of lib, rather than linkable one. but i ~like~ linkable/separately-compilable static libs.
asciilifeform: (i.e. does not properly plug the abstraction leak of unix idjicy, which is the whole point of the proggy)
asciilifeform: tho even if it existed, and i had memmap package eat a FD that it shat out on instantiation, this would be stupefyingly ugly still, because then memmap cannot be a troo finalized type (i.e. one that cleans up entirely after itself on death, incl. closing its fd)
asciilifeform: the real enigma is, why the fuck gnat does not include an interface to ordinary unix open(), why is it that i gotta write it.
asciilifeform: the braindamage of unix open()'s demand for a null-termed string, percolates all the way up.
asciilifeform: my only remaining notion here is that possibly gotta implement a 'paths' lib ! i.e. would represent paths as arrays of permanently fixed length , 255 octets, iirc this is the max permitted on unixlikes.☟︎
asciilifeform: diana_coman, phf , et al ^ invited to think/comment...
asciilifeform: and if it ain't available at birth, then it never gets set.
asciilifeform: so then sat down and implemented it in http://p.bvulpes.com/pastes/RJjFb/?raw=true form. however this cannot be made to go , because if MemMap package does not know the path at instantiation time, it cannot run,
asciilifeform: currently i'm in a zugzwang in re the mmap lib : the http://p.bvulpes.com/pastes/extOl/?raw=true invocation form is The Right Thing, but it requires passing in a String for Path, which dun work without secondarystackism;
asciilifeform: my current hypothesis is that we're literally the only folx ever to bake static libs (i.e. in .gpr, for Library_Kind use "static"; ) .☟︎
asciilifeform: meanwhile, in gnat bugs : apparently ( and this is documented or mentioned nowhere ) : it is impossible to have a Ada.Finalization.Limited_Controlled type ANYWHERE inside a static library, unless it is generic all the way down (i.e. if the lib package is generic, any sub-packages must also be instantiated as generics )☟︎☟︎☟︎☟︎☟︎☟︎☟︎
asciilifeform: anyway i'ma leave it at this, will bbl:meat.☟︎
asciilifeform: one thing to shit on an enemy's door step, deliberately, entirely other thing to shit errywhere because not realizing that shit -- stinks
asciilifeform: it is not possible to live life wholly without exhaust product, errybody exhales, shits, occasionally drops a crumb. but imho good form is to at least recognize that litter is unwanted.
asciilifeform: at the risk of repeating ancient thread -- 'the best machine is no machine', it weighs nuffin, needs no maintenance. and the best proggy, is no proggy at all, if a problem can be solved without writing proggy, it ought to be. erry line of coad can be rightfully pictured as an act of intellectual littering. y'know, like throwing cig butt or bottle on the ground in the park.☟︎☟︎
asciilifeform: when you add compatibility spackle, serious reader is not saved from reading the thing you spackled over -- on the contrary nao he has to read the ~original~ rubbish ~plus~ your spackle, however much it weighs.☟︎☟︎☟︎☟︎
asciilifeform: let's reformulate this way : we want the ~net~ complexity of the orchestra to decrease. if we cannot yet decrease ~net~, the Right Thing is to at least refrain from adding, when possible.
asciilifeform: ( if you have a 1460 , it had better include whole ip stack and driver for iron nic, lol )
asciilifeform: but i aint particularly interested in 'improvement' that turns the 146 into 1460.
asciilifeform: if somebody can show how to do same in 100, or 10, i'ma read and sign the patch and take off my hat.
asciilifeform: it is ~much~ easier to demonstrate the correctness of 600, no matter what else.
asciilifeform: for so long as we're stuck on a linux box, i'd rather spackle over the c-ism with 600 ln, than with 6000 .
asciilifeform: right up until we finally ditch unix c kernels.
asciilifeform: any spackle over the orig unix liquishit, is doomed to be ugly. so imho the smallest possible spackle that does the job, is Right Thing
asciilifeform: bvt: linux kernel is fundamentally retarded, it expects null-termed rubbish, at times, at other times, char * and length, not to mention a pile of untyped ptrs inside structs, really oughta eat ada structs , ada fixed strings, properly typed arrays, etc instead
asciilifeform: otherwise why not just write 0xfbadf00d.... etc
asciilifeform: whole point of using a compiled lang is that this garbage dun have to live in yer proggy !☟︎
asciilifeform: port it once per iron/os and then fughet it.
asciilifeform: really, the os-platforming crapola belongs inside gnat.
