log☇︎
65800+ entries in 0.039s
a111: Logged on 2018-10-25 18:52 asciilifeform: whole point of using a compiled lang is that this garbage dun have to live in yer proggy !
mircea_popescu: http://btcbase.org/log/2018-10-25#1866178 << or so you'd fucking think! ☝︎
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: 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: ( and btw the actual amt of c spackle in udp lib , http://btcbase.org/patches/udp_fix_ip_nullchars/tree/udp/libudp/unix_udp.c , is 146 ln. )
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: 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
bvt: well, i did not suggest learning/utilizing C api, on the contrary, a subset of kernel stuff in ada is the interesting thing. it just happens to be currently defined/documented as C code. ☟︎
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.
bvt: well, http://git.musl-libc.org/cgit/musl/tree/src/network/connect.c -- the structure is the same; digging is rather easy, if you don't look into glibc
asciilifeform: and .c is not the only os liquishit, tables of platform constants that one ends up with from avoidance of .c, is also liquishit.
a111: Logged on 2018-10-25 18:25 asciilifeform: my udp lib is ~600 line, and not 6000, because i went in this direction.
asciilifeform: as by asciilifeform -- the pill which weighs the least, is the Right Thing, per http://btcbase.org/log/2018-10-25#1866148 , an absolute minimum , line for line, of os-specific liquishit, is the ticket. ☝︎
asciilifeform: that was my point, this remains to be excavated
asciilifeform: bvt: i do not know for a fact whether it eats same struct as the userland call, or different
asciilifeform: ( and yes it is catalogued, in various places, e.g. http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ , but to go to implementation takes moar sweat )
bvt: syscalltronic = based on direct invocation of linux syscalls? how this would be possible without haveing sockaddr_in in ada?
asciilifeform: i'd luvv to see a syscall-tronic version of the udp transceiver thing, for instance.
asciilifeform: there's very little point in memorializing the c api liquishit imho
asciilifeform: really the shit to catalog is the actual kernel abi -- what ave1 is doing .
mircea_popescu: i suspect noboduy's getting out of cataloguing the shit that easily, but we see.
asciilifeform: and when we get own os, can rip out the c immediately in favour of for CuntLips'Address use 16#FF00ABCD# device interface, etc.
asciilifeform: the obvious alternative to cataloguing the liquishit, is to let it stay in gnat's c frontend where it belongs, a la the udp.c thing.
mircea_popescu: eg, to ~everyone the above open, and stack and etc were surprises.
mircea_popescu: just as soon as we figure ouyt wtf they even are.
asciilifeform: ( also to stop the gcc5ism gangrene, but this is a close second )
asciilifeform: it's why it made sense to fork off gnat to begin with, so that these can be done.
asciilifeform: to keep 9000 mutant copies of these basic things is insanity
asciilifeform: imho in long term we really gotta move the compat layers liquishit out of individual projects and into tmsr-gnat
asciilifeform: bvt: maptron is actually done aside from the strings horror raised last night
asciilifeform: i do not see how it would be improved by being 6000, if i were to try to adaize erry possible idjit unix's struct sockaddr_in .
bvt: but maybe, only the subset you need for mmaptron, for starters? full conversion is definitely not worth it
asciilifeform: my udp lib is ~600 line, and not 6000, because i went in this direction. ☟︎
asciilifeform: rather than baking it into 1000 manyears
asciilifeform: bvt: imho it's wasted work; oughta have just enuff coad to interoperate with the pot of c liquishit while we still must
bvt: the thing is, structure definitions and all sort of flag numbers appear in the libc via magic. having all this things in ada is possible, and would involve exactly same work that e.g. musl people are doing today
asciilifeform: cuz may as well; if we ever tear off unix , will have to replace those mechanisms anyway
asciilifeform: sorta why i went ahead and stuck ALL of the os-dependent crud in udp lib into 1 .c
bvt: everything system-dependent that i've seen in gnat runtime goes into C code.
bvt: Ada.Sequential_IO is wired straight into fopen/fread/fwrite, by the way.
asciilifeform: bvt: they differ for same reason as tit sizes -- nobody ever standardized, so naturally varies
mircea_popescu: cuz it must be there, yes.
asciilifeform: the funny/sad bit is that this is ALREADY in gnat, for e.g. http://btcbase.org/patches/ffa_ch8_randomism#L132 , but ~not exposed~ ! to user
bvt: re syscalls -- fair enough. but imo this shows extreme brokeness of linux portability -- i can't think about a sane reason for syscall numbers to differ across arches.
mircea_popescu: basically one step towards gnatos
asciilifeform: so any particular proggy can call e.g. open() with correct flaggisms, because it aint as if the gnat on the $box does not already know what os/iron it sits on.
asciilifeform: sorta what the orig authors lamely tried to do ( and mostly failed )
asciilifeform: the correct end of the funnel to plug, imho , would be a sane flags lib built ~into gnat~, and correct ~per gnat port~
mircea_popescu: i dunno, but this is brewing into a kettle of fish.
asciilifeform: bvt: syscalls were never guaranteed to be same errywhere tho
bvt: asciilifeform: re exotic flags -- sure. but i don't expect different results with syscall numbers as well. some subset will match, later in the table -- complete mess
asciilifeform: ( and from this we get to 'why didja not write the proggy in asm, if it only worx on linux 2.4 on mips ' etc )
asciilifeform: cuz it's either that or 1 v-branch per os/iron .
a111: Logged on 2018-10-24 15:25 asciilifeform: incidentally, https://www.adacore.com/gems/gem-59 apparently exists, tho i confess that i really dislike the idea of automatic converters for coad
asciilifeform: O_DIRECTORY might be a bitch in the fyootoor , i suppose
asciilifeform: ( i.e. none of these flags appear in my proggies, aside from the open() one )
asciilifeform: bvt: i'm not surprised; but these dun affect anyffing i considered to be essential posix knob
bvt: http://btcbase.org/log/2018-10-25#1866029 << asciilifeform, it seems that i accidentally made you believe that only mips is wrecked. Well, check this out http://p.bvulpes.com/pastes/sWrur/?raw=true ☝︎
a111: Logged on 2018-10-25 17:01 mircea_popescu: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3/ << i quite enjoyed reading this btw.
bvt: http://btcbase.org/log/2018-10-25#1866027 << thanks! ☝︎
a111: Logged on 2018-10-25 14:52 mircea_popescu: up to you whether to make a dir or not ; eventually these will end up in that http://btcbase.org/log/2018-10-23#1865314 -- but the only way that happens is if you try things and then productively disagree with people. i've nfi at the moment whether we do or we don't want single temp files in a tmp dir nevertheless, or anything else ; and i absolutely do not wish to ever do (or will ever permit anyone to) sit around and "think
bvt: http://btcbase.org/log/2018-10-25#1865825 << if you don't force the 'tempfiles ./tmp' scheme, i would much prefer to implement the 'temp. file in ./' variant. vpatch coming at latest tomorrow. ☝︎
asciilifeform: i would've naively imagined that massive 'contrabass' like this would may as well include the uv lamp. but apparently didn't.
asciilifeform: i suppose if i had a stable of trained seals, might entertain'em/self in this way.
mircea_popescu: not saying that whole new generation couldn't be baked for this purpose. but seems insanity.
mircea_popescu: not that much faster ; the padding helps speed, and familioarity also.
asciilifeform: goes smoother if you giv'em an 'autovon'-style keypad thing, instead of pc kbd
mircea_popescu: ever had slavegirls type out rsa stuff btw ? it's like 1girlhour/kb sorta deal.
asciilifeform: typically they kept privkeys on hole-tape
mircea_popescu: seems a fine way to put in a privkey :D
asciilifeform: resisted to buy, it's ~typewriter size/mass'd
asciilifeform: i saw a surplus box of this type for sale, not so long ago
asciilifeform: you enter addr, then hit FF, or B0, or whatever, then '->' button...
asciilifeform: tho funnily enuff, in '80s su the standard method of burning ROMs was actually this box with keypad
asciilifeform: we kinda have these already
mircea_popescu: "in an attempt to simplify computing, alf brings you, the computer that can only be programmed by a computer."
mircea_popescu: the code writing for tyhis will need some real men.
asciilifeform: ( think 'cellular automaton' )
asciilifeform: ( in '50s this was a best-selling 'ram' , but afaik nobody thought to de-rasterize it and make it the whole comp )
asciilifeform: for all i know, you could match 'z80' performance with simply modified cathode tube where the beam steers depending on what the state of the phosphor under it was, rather than moving in linear rasters.
asciilifeform: all of this is in re 'you may be able to get away with only metals, no dopants' subthread.
mircea_popescu: yes, but there's no rule saying "useful processor eats kW". for all you know it eats mW. there's a lot of eV in a mW.
asciilifeform: ( and can have almost anyffing as the core, even vacuum, all transformers saturate )
asciilifeform: and there isn't really a theoretically minimal size for it, afaik.
asciilifeform: ( for n00bz re earlier -- magnetic logic is based on the fact that a transformer core can 'saturate'. ergo you can bake a 'nand' simply from transformer with three windings.
asciilifeform: not even speaking of intelisms -- if you can't remove heat at the rate it is produced by resistance -- you get magic smoke, no matter how you cut it
mircea_popescu: "you want water for your engine" sorta thing
mircea_popescu: it's not clear to me the high power intelisms are ab solute necessity.
asciilifeform: btw -- and iirc we had the thread -- there are even deeper crackpotteries potentially in the mix : it is possible to have strictly magnetic logic, without semiconductor. if can simply etch fine metal mask, interleaved with insulator, potentially can have a kind of slow 'z80' from miniature toroid logic (as seen in '60s su)
asciilifeform: you want an end product that conducts thermally as well as electrically, or you get a lighter.