IRC channel logs
2023-07-02.log
back to list of logs
<pabs3>Zig moving away from LLVM, among the advantages: "The compiler becomes trivial to build from source and to bootstrap with only a C compiler on the host system." <stikonas[m]>They'll still have zig code in zig and will generate C file that they'll commit to repo <stikonas[m]>This is only about removing dependency on C++ compiler <stikonas[m]>Or possibly WASM instead of C but the point stands... <pabs3>hmm, I thought zig didn't have generated C code <stikonas>but as far as I understand zig has various output backends <stikonas>i.e. it can generate C code or webassmebly <stikonas>so their bootstrap path is basically run zig compiler on zig source code and output WASM <stikonas>then tell others to use that WASM binary too bootstrap zig on new platforms <stikonas>that might remove some practical problems for people compiling zig on the new machine, but it is in not bootstrapping in our sense <stikonas>in a sense it's not so different from saying you can bootstrap gcc if you have x86 virtual machine, just need to run gcc binary in it <fossy>hey, oriansj (or anyone else who knows), is any way in M2-Planet to have two structs that have a member of each other? (eg struct a {struct b *b;}; struct b {struct a *a;}; -- is there any way to do that?) <kerravon>oriansj - thanks for that comparison of paper tape vs punched cards. sounds like i need to switch to paper tape <kerravon>hmmm. maybe not. maybe i'll write some basic OCR software instead and make use of photocopiers <kerravon>how many characters would i get on an A4 page using a good fixed width font? <stikonas>have you tried and something didn't work? <stikonas>fossy: though we don't test it in M2-Planet test suite <oriansj>fossy: well M2-Planet can only use types it knows of to include a type in a struct definition. so if you define B first, you can include B (or a pointer to B) in A but as A is not defined yet, you can't include A in B but if you use void pointers; and do something like struct A* temp = obj->A_object; you can kinda work around it <oriansj>like struct B {void* A_object; ...}; and you can always do struct B* foo = calloc(1, struct B); foo->A_object = calloc(1, struct A); sort of deal <oriansj>honestly you can have hundreds of types sharing the same void* but that is just bad programming. <nimaje>does M2-Planet support forward declarations? that way you could have a correctly typed pointer instead of a void* <stikonas>at least for functions it does support forward declarations <oriansj>nimaje: in regards to functions absolutely, in regards to structs; there hasn't been any justifiable need to add that yet but if a suitable example exists, it wouldn't be hard to add <muurkha>kerravon: a standard 12-point typewriter font traditionally gets you 80×66 on US-letter or A4 paper, with some margins <muurkha>kerravon: is that the information you were looking for? <muurkha>I'd recommend putting several letters of Reed-Solomon coding per line and per column to enable correction of inevitable OCR errors, on the theory that Reed-Solomon coding is powerful enough and simple enough <stikonas>janneke: are mescc C tests only meant to work under mescc? <stikonas>i.e. gcc built binaries are not expected to run <janneke>stikonas: no, the tests should also run with gcc <janneke>stikonas: hmm right, f is not initialized and could contain garbage under gcc <janneke>not sure why that hasn't been a problem before <stikonas>janneke: the next test in your list does the same thing <stikonas>it defines int f; and then does assert (f == 0); <janneke>ACTION adds " = 0" to those two tests <janneke>stikonas: but 70-extern.c is skipped for x86_64... <muurkha>kerravon: another measure that might help with OCR errors is adding some random pixels to the font, for example making the 4×6 font into a 4×7 font, to increase the Hamming distance between letterforms that are otherwise very similar, like 'c' and 'a' in my 4×6 font above. decreases readability slightly for humans and normal OCR, but ought to dramatically diminish OCR errors with a <muurkha>custom-built OCR that knows where those pixels are supposed to be <muurkha>I think a major problem for qr-backup is the nonlinearity of laser printer scanning; they have fancy optics to correct it but that only works up to a point <stikonas>janneke: so what are the next steps then? should we ask efraim to retest? <janneke>yes, i guess so; the mescc tests should be much more interesting <stikonas>but at least we would gather some useful data <kerravon>muurkha - thanks a lot for that excellent information and ideas <kerravon>i was planning on having a CRC in lowercase hex (as well as data in lowercase hex) on each line <kerravon>and I would like to stay within the limits of an early dot matrix printer <kerravon>(excellent idea of error correction on columns too) <kerravon>C:\devel\pdos\src>zcalc 49152+30208+172032+69632+27360 <stikonas>crc doesn't have error correction though... <kerravon>I would need to publish a say 150 page book in 1986 <kerravon>or 2086 depending on the time of recovery from Putin's nuclear war or meteor strike <kerravon>what do you think would have happened if i had published that book in 1986? <kerravon>i don't necessarily need error correction - a human can reconcile so long as it is detected <stikonas>janneke: I'm now running make check on amd64 and getting ./../build-aux/check-mescc.sh: line 316: syntax error: unexpected end of file <muurkha>kerravon: typically early dot-matrix printers used a 5×9 or 10×9 font <stikonas>janneke: thanks, now it runs to completion with some failures <muurkha>in a lot of cases the timing of firing a hammer could be controlled pretty precisely, but you couldn't fire it that fast <janneke>stikonas: weird, so the f = 0 initialization did not help? <muurkha>so you might be able to fire it 5 times during a single character, but you could control when those 5 times were to within a tenth of a character. you probably could have done better than that but I don't think anybody did <stikonas>janneke: one moment, let me double check and make sure <kerravon>muurkha - this "timing" issue has what implication? <janneke>stikonas: could be that you have to use recheck=true <muurkha>kerravon: well, it means you could get significantly more readable output from a 9-pin dot-matrix printer than you'd expect from "5×9" <stikonas>the last section all failed for me, probably environment setup issue <muurkha>I think the Heathkit dot-matrix printer was like 7 or 8 pins <muurkha>the Radio Shack one was weird as hell and instead just had a single hammer, but used a rotating platen behind the paper to kind of get a helical scan <kerravon>muurkha - so you mean i should target 10 * 9 dot matrix instead of 5 * 9? <muurkha>I don't know what you should target because I don't really understand your goals <muurkha>did you say you were going to time travel back to 01986 to publish a book? <kerravon>yes, basically. with the knowledge i have now - what would i have done differently? <kerravon>theoretically i could have legally left school late 1982 <muurkha>go work for Microsoft, invest in Autodesk and Adobe and Apple. not Commodore <kerravon>no, i don't want to work for another company <muurkha>nobody is going to accept your $20 bills that say "2021" on them, you'll get arrested <muurkha>the great lacuna in this plan is where to get the time machine tho. are you going to steal Guido's? <kerravon>it's not just a time machine - it's what someone else could have done - what did they need to do? <kerravon>just trying to ascertain technical requirements to challenge microsoft <kerravon>note that my goal is vague and probably pointless, but i've spent nearly 30 years on it so far <muurkha>I think you probably need a community of free-software programmers to challenge microsoft; by 01986 they were already in a position to defeat all the proprietary software companies. I mean look at DR DOS <kerravon>other people restore vintage cars - also pointless <muurkha>what was missing for free-software programmers in 01986 was widespread internet access. but actually usenet was probably good enough <muurkha>something like zstd or brotli might have made a difference, but the bigger difference between Fidonet and Usenet was the capabilities of the software I think <kerravon>this is C programming - you don't need anything fancy <muurkha>trn was a lot fancier than Opus BBS when it came to reading discussions <muurkha>maybe Van Jacobson's "content-centric networking" or "named data networking" might have enabled better routing on Usenet/Fidonet <kerravon>even if true, i think that's a trivial difference when it comes to the hard work of writing an OS <muurkha>there's also been some work on "weak sense of direction" that might have enabled smarter routing <muurkha>I don't think so; the BBS world was dominated by single-author shareware that wasn't in Microsoft's league <muurkha>the community enabled by the internet made it possible for Linux to kick Microsoft's butt <muurkha>one fancy technology that was a kind of secret weapon for Microsoft was compact bytecode, which enabled teensy little PCs to do a lot more in Excel than in competing spreadsheets <kerravon>sorry, i don't understand. why does the software used on the BBS world matter? So long as you can get to C_ECHO, who cares? <muurkha>because you could fit like three times as much code in RAM as when you were running native 8086 code <muurkha>the software used in the BBS world mattered because it failed to cohere as a free-software community the way the internet did <muurkha>which is the major reason 4DOS wasn't Linux <muurkha>a lot of that was just better connectivity on Usenet and the Internet than in Fidonet <kerravon>on osdev.org there are heaps of OSes - but almost all are one-man shows. getting a team is not due to the internet <stikonas>janneke: so all mescc tests pass now on x86_64, fixed that setup issue that I had (my MES variable had relative path) <muurkha>kerravon: the reason people don't join those one-man shows is that they have another show to join <muurkha>that wasn't the case in the heyday of Fidonet and 4DOS <muurkha>maybe, you haven't beaten it yet because you still don't have multitasking ;) <janneke>stikonas: great, and thenks for checking! <kerravon>multitasking can be added by a commercial derivative <muurkha>also the Mac, the Atari ST (the Jackintosh), the Amiga, and Smalltalk <kerravon>none of them are free, with public domain source code <stikonas>hmm, but debug symbols are borked on 64 bits... <stikonas>even though mescc seems to call blood-elf with --64 <muurkha>yes, that is true! there are Smalltalks now that are free software, but there weren't at the time <muurkha>it's true, you don't seem to be very interested in GUIs and IDEs <muurkha>in 01986 the 80386 was super expensive <kerravon>affordable if i saved a year's wage or something <muurkha>earlier in the year there wasn't a 386 IBM-compatible on the marqet at all <muurkha>I don't know anything about the conditions there. how were local telephone calls charged? <muurkha>so you could phone up your buddy's computer and transfer data all night long for 20¢? <muurkha>there was a lot of brilliant hacking at the time, but so little of it resulted in anything of lasting value or reusability <kerravon>yeah - that's basically what i'm trying to challenge <stikonas>janneke: what's the magic evn variable to get extra logging from mescc? <muurkha>8 hours at 2400 bps is 8.6 megabytes <kerravon>but yeah - i'm assuming i have saved my money hard <muurkha>so most of your data was on floppies <kerravon>i can't remember how much data i put on floppies (360k) <muurkha>huh, I didn't know Commodore did that <muurkha>you probably had more than 60 floppies tho <janneke>stikonas: mimicking GNU's standard V=1, V=2 <muurkha>you could imagine a world where your computer spent the day compressing data and calculating network routing <kerravon>that isn't the barrier to writing PDOS/386 <muurkha>and spent the night interchanging data with like-minded people in a local community <muurkha>no, but a 386 OS wouldn't have been very useful in 01986 <stikonas>janneke: hmm, that doesn't show invoked commands... it's probably easier to strace it... <kerravon>why do you say a 386 OS wouldn't be useful in 1986? <muurkha>because the Compaq Deskpro 386 cost US$6499 <muurkha>you might as well write an OS for the VAX <kerravon>i was already working in 1986 (i was 18) <kerravon>as a tape jockey (assistant computer operator) <muurkha>yeah, if you can write the whole thing yourself quickly, it doesn't matter what hardware other people can afford <muurkha>but lots of people were trying to challenge Microsoft that way and they all failed until Linux <kerravon>yeah - but none of them created the win32 API <muurkha>so I think you need a free-software community to work with <kerravon>but that's a bit like those viral youtube videos <muurkha>which would probably mean focusing on networking and running on smaller machines like the XT <kerravon>no-one really knows what is going to take off <kerravon>well - from the same/similar source base i produce pdos/86 too <muurkha>Excel, Oberon, and Smalltalk demonstrated you could do a shitload on an XT with a bytecoded VM <muurkha>it may not be to your taste but it's amazing <muurkha>not talking about competing but about taking inspiration <kerravon>pdos/386 is literally what i want to produce <kerravon>i don't need inspiration - i'm already inspired to work on it for 30 years <kerravon>theoretically someone similar to me could have written it in 1970 in K&R C <kerravon>or it would have been on floppy disk passed around already <stikonas>janneke: next issue is I think elf headers on amd64 are wrong <muurkha>in 01970 I don't think Kernighan had even started working at Bell Labs, and C didn't exist <muurkha>the first versions of Unix were written in assembly, up to 01972 <muurkha>but you could write your own compiler too <stikonas>hmm, it's far more complicated header than in case of stage0-posix-amd64... <kerravon>regardless, universities or something could have organized this <muurkha>I mean in theory you could have written a C compiler in 01965 for an IBM 360 <stikonas>or at the very least header from M2libc/stage0-posix-amd64 seems to create files with correct debug info <muurkha>or you could have written a C compiler in 01932 on paper <kerravon>yeah - that's a very interesting question actually <kerravon>1910 i think is the crucial year. let me find it <muurkha>the issue is that it took a long time for people to figure out what to want. when C came out, BCPL was maybe the closest thing to a portable low-level language, and it was too big to fit on minicomputers <muurkha>even C was too big to fit on the PDP-7 that Unix started on, and the PDP-7 wasn't byte-oriented, and C really wants a byte-oriented machine <muurkha>(which is why I namechecked the 360) <muurkha>in the 80s it wasn't obvious that the internet was going to rule the world; in fact without Al Gore it probably would have been eclipsed by commercial networks, crippled by the NSFNet AUP <muurkha>it wasn't obvious the 386 was going to rule the world; the 68000 seemed like a better bet, and plenty of people were still buying C64s in 01986 <muurkha>in fact it wasn't discontinued until 01994 <muurkha>and plenty of people thought the triumph of RISC would be pretty immediate. ARM did eventually surpass the 386 line in popularity but probably not until 02010 or so <muurkha>when OS/2 split from Microsoft in 01990 lots of people bet on IBM, and OS/2 had its own non-Win32 32-bit API in 01992 <muurkha>plenty of people were also betting on Smalltalk too, which could do things no mainstream software could do <muurkha>I mean most of Win32 was Microsoft trying to reach feature parity with Smalltalk without taking the order-of-magnitude slowdown that Smalltalk involved <muurkha>even today Alan Kay blames that slowdown on CPU vendors not dedicating resources to Smalltalk-style dynamic dispatch, based on his experience with microcoded Smalltalk implementations on Dirty Genitals NOVA clones in the 01970s, but I think he's mistaken about it <kerravon>sure - i'm talking about with the knowledge we have now <kerravon>haven't found the year yet - got interrupted by rl <kerravon>and yeah - people didn't know what to want <muurkha>it might be the case that things would have worked out very differently with slight changes <muurkha>the right executive having a heart attack at Xerox, most obviously <muurkha>and the Al Gore thing I suggested above <kerravon> In principle theory of parsing, finite automata, etc could be developed say around 1910. <kerravon>> requires experience: you need to know that it is <kerravon>> useful to describe programming languages using <kerravon>> context free grammars, you need experience to <kerravon>> know that LL(1) and LALR work for practical languages. <muurkha>I think segmentation was intended to be a lot more full-featured than what they actually shipped; they wanted PDP-11-style base+bounds segments <muurkha>I think they managed to finally get that into the 80286, but the 80286 came out pretty late for a PDP-11; lots of people had more than a meg of RAM <muurkha>I still think the 4-bit shift was one of the biggest engineering mistakes of the 20th century <kerravon>i think what was wrong was HARDCODING the number 4, not the actual principle <muurkha>but hardcoding 6 or 7 would have been a lot better <muurkha>F-83 did implement paging on the 8086, btw <muurkha>I think `far` and `huge` pointers in programs compiled with other memory models were reasonably common <kerravon>it just needed an API to retrieve the shift <kerravon>huge memory model in microsoft C uses AHSHIFT in the family API <muurkha>but then you'd have to use the variable shift in all your huge-address computations, which would make them even slower <muurkha>although I guess maybe your could provide an instruction or two that solves that problem <muurkha>oh, the issue with PC-relative instructions is that they allow dynamic loading, Win16-style <muurkha>on the 8086 this is achieved with call $+2 <muurkha>Oberon did its dynamic linking without PC-relative instructions or other position-independent code by running a full link pass at load-time, which was workable but not fast <muurkha>downside of PC-relative instructions is that they're annoying as hell to assemble and disassemble in your head <muurkha>LALR parser generators are nice not just because they allow you to write a parser for a pretty expressive class of languages just by annotating a context-free grammar with semantic actions, but also because they tell you where the ambiguities in your grammar are so you can resolve them <muurkha>also, the LALR parser they generate is pretty fast and compact and uses very little memory, less than a recursive-descent parser would <muurkha>PIC is in some sense inherently slower than non-position-independent code; PC-relative addressing requires an extra full-width addition on each effective address computation. But it compensates for that by permitting higher code density, and in hardware doing more additions isn't always slower because they may not be on the critical path