<OriansJ>fossy: not yet but we should be reasonably close <OriansJ>eeeww: *(sp = spTop) = app(app(app(root, app('0', '?')), '.'), app('T', '1')); <OriansJ>now everything up to line 345 is M2-Planet compatible <OriansJ>assuming the current changes pass; all the way up to line 524 <OriansJ>I just realized I might have missed a couple steps in the makefile but should be simple to fix <OriansJ>oh well, I can deal with that after I get vm.c M2-Planet buildable tonight <fossy>how long does it take m2 planet to compile it <OriansJ>fossy: M2-Planet can compile 100Kloc/second <OriansJ>at 1081 lines of code for vm.c; we are looking at about 1/100th of a second <OriansJ>but the resulting binary will be 10times slower than what GCC would produce <fossy>as long as it isnt a day like the original mes tinycc bootstrap was <OriansJ>assuming it doesn't abuse the C standard too hard and depend upon undefined behavior; once M2-Planet can compile it. We will be off and to the races. <OriansJ>well I can give you an approximate compile time to bootstrap to precisely in just 1 minute <fossy>well, how much more work is there to do after that to bridge the gap to mes? <OriansJ>fossy: don't know that is siraben's plan <fossy>i believe there was a replacement for like finally and virtually with lispy and schemey or something?? <OriansJ>I am just doing the M2-Planet work required to make it possible <siraben>fossy: yes there was, but I decided it would be a lot of work that way <fossy>which of the proposed ones is more likely <siraben>It's the same as a few days ago but I compare two different approaches <OriansJ>also there are some questions about vm.c that might become an issue (nearly binary blobs and all) <siraben>Which part of vm.c? The first four compilers? <OriansJ>ok from make clean ALL to precisely is 204.82 seconds wall time; so say 2048.2 seconds for M2-Planet instead of gcc doing the bootstrap <siraben>OriansJ: Ah, it's not that opaque once you know the translation <siraben>Also, it can be inspected that no IO is performed <OriansJ>the char *parenthetically, char *exponentially, char *practically, and char *singularity <siraben>How many bytes do they total in all? <siraben>We could potentially rewrite what they do in C instead <fossy>but then what about lonely and those afterwards? <OriansJ>siraben: I want the translation if we are to use them inline for trivial inspection <siraben>Hm yeah, trusting trust of sorts. exponentially and practically have a small diff of two lines by the way <OriansJ>it is big enough to hide a compiler in <fossy>OriansJ: won't we need to make sure that bin/vm run creates M2-Planet compatible C <fossy>and convert rts.c to M2-Planet <OriansJ>so; we are going to have to figure out something workable <OriansJ>fossy: that is the next step after we get bin/vm happy <OriansJ>there is no point working on those if there is a trusting trust attack in vm.c <siraben>OriansJ: Is it more important to get the bootstrap working in the first place, then we can go back and rewrite the earlier stages in C? <OriansJ>siraben: personally I believe in getting the foundation correct first <fossy>how would we make char *singularity and friends into C, siraben ? <siraben>They're just syntactic transformations initially <siraben>parenthetically wouldn't be hard to rewrite <fossy>i don't think this is going to be easy to implement in C <siraben>They all use higher-order functions and parser combinators already <OriansJ>hence why I say, I don't know the correct solution yet <siraben>OriansJ: so to clarify, it's ok proceeding without rewriting all of vm.c in C for now? <OriansJ>siraben: right now; I am doing minimal changes to vm.c <OriansJ>with the goal of enabling it to be built via M2-Planet <OriansJ>after that; we can start figuring out how to make it something people can trust. <OriansJ>just take some time to think would be less work for us but also would be something trivial to trust. <siraben>Do you have string routines in mes-m2? We could use that to bootstrap blynn-compiler <siraben>i.e. rewrite the first four stages in Scheme <fossy>it would be much easier to rewrite that in a functional language <OriansJ>if you look at mes-m2/s mes_init.c you'll see the full list of primitives <fossy>although i think all of us would be leaning on you, siraben quite a bit <fossy>OriansJ: on a slightly different topic. I know that gash exists, but before that, especially if we go the route we are talking about now, we would need something like cp i reckon to make the code cleaner <fossy>a simple cp command would be easy to write in M2-Planet <fossy>what's the catm syntax again <OriansJ>catm output input1 input2 ... inputN <OriansJ>as if you look at the C code in mescc-tools for catm <siraben>OriansJ: could you look at parsing.scm i sent above, would it be possible to translate to mes-m2? <OriansJ>it is so that I can be lazy when writing it in assembly. <siraben>We can do without the use of hygienic macros <OriansJ>siraben: sure; give me a moment to parse <OriansJ>well we don't have object->string yet but it could be an easy add. string-concatenate/shared we could do in scheme, so not a problem. syntax-rules nope; the rest of it seems fine (assuming we expand to eliminate the need for syntax-rules) <siraben>string-concatenate/shared could just be string-concat <siraben>I see. Haha, bootstrapping Scheme via Haskell via Scheme <OriansJ>a simple test: (define (foo a) (+ (bar (- a 1)) (bar (- a 2)))) (define (bar a) (if (> 0 a) 1 (+ (foo (- a 1)) (foo (- a 2))))) (foo 3) <OriansJ>mes-m2 is as proper of a scheme as I could do (minus syntax-case and more advanced macros and modules) <OriansJ>and (define (fib a) (cond ((= a 0) 1) ((= a 1) 1) (else (+ (fib (- a 1)) (fib (- a 2)))))) self recursion as well <fossy>lol, M2-Planet -> mes-m2 -> blynn -> blah blah blah -> mes -> blah blah -> gcc <OriansJ>fossy: well more like M2-Planet ->mes-m2; M2-Planet -> vm.c; mes-m2-> blynn -> scheme in haskell -> mescc -> blah -> gcc <siraben>Indeed hygienic macros is one thing I want to get right, because it significantly reduces the special forms needed <OriansJ>well technically no because of the number of steps in blynn but it will be interesting regardless <siraben>Right. A better measure might be code size as you go along <OriansJ>22 steps to precisely but 10 to gcc 4.7.4 (7 to gcc 2.95.3) <fossy>did any kernel work come to frutition <OriansJ>siraben: no need for comparison; just which ever is more fun <OriansJ>fossy: are you talking of bauen1's work? <OriansJ>ok; assuming all tests pass. I'll have a version of vm.c that M2-Planet can compile with the command: M2-Planet --architecture amd64 -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/file.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f functions/file_print.c -f functions/match.c -f vm.c <OriansJ>well it compiles but doesn't yet run <OriansJ>the version of vm.c that can be built by M2-Planet is up <OriansJ>but it doesn't run successfully. I look deeper into that tomorrow. ***dongcarl4 is now known as dongcarl
<bauen1>fossy: i currently don't quite have the time to work on it <bauen1>fossy: essentially all that is needed now is to write a syscall layer and implement some form of processes (threads and really simple scheduling should already work) <bauen1>just how much closer has mes come to run mescc ? <fossy>We are exploring a diff path <bauen1>modifying musl is actually the annoying part, since now i need to look into multiple repos and what not <bauen1>without a libc testing any form of processes (the clone and mmap syscall) becomes a lot more annoying <OriansJ>bauen1: proper scheme macro support in C is *HARD* enough that we are taking a little bit of time to see if bootstrapping Haskell would be easier. <OriansJ>siraben: looks like it is a game of hunting down pointer arithmetic in vm.c <siraben>OriansJ: IIRC he indexes into mem and sp all the time <OriansJ>as in M2-Planet when you do a = a + 1; a is actually incremented by 1 but in C proper a = a + 1; could mean a is incremented by 1 or sizeof(type_of_a); depending on what type a is <siraben>you could have a `mem(unsigned x)` function that converts this `x` into the right size and indexes into the memory, so `mem(n+1)` would mean the `n+1`th cell <OriansJ>well a[1] means the same thing in M2-Planet and C; address of a + sizeof(type_of_a) <OriansJ>or simply //CONSTANT CELL_SIZE sizeof(unsigned) #define CELL_SIZE 1 <OriansJ>and it then does the exact same thing <OriansJ>and people can tell at a glance what is expected behavior <siraben>ah and you can still compile with GCC and override the define <OriansJ>I like simple and easy to understand code; when possible. <OriansJ>code is for humans to read and understand and for computers to incidentially execute. <OriansJ>I think it is a very old thought too. <OriansJ>At the end of the day, it is about having things that humans can reason about and fix <OriansJ>otherwise, we get stuck in hell with no way to escape. <OriansJ>it is one of the reasons why source code *MATTERS*; without it, there is no hope of understanding some of the bugs that occur. <siraben>OriansJ: would it be possible to run m2-planet on x86-64? <OriansJ>siraben: x86-64 is just Intel marketing for the AMD64 instruction set <OriansJ>AMD designed it and shipped it and named it; Intel copied it and renamed it so they wouldn't have to give credit to AMD <OriansJ>Intel processors run the AMD64 port just fine <OriansJ>well it works just fine on FreeBSD and NetBSD (even when bootstrapped in mescc-tools-seed) <OriansJ>It could also rather easily be ported; on needs only replace the syscalls <siraben>I see. I could give that a go on macOS <siraben>Not sure about the BSD <→ macOS compatibility <OriansJ>siraben: well the only thing that needs changing is the syscalls, everything else is bare metal behavior. <OriansJ>but if you use GCC or clang to Compile it; it should run just fine too <OriansJ>as there are no embedded syscalls in the source code that GCC or Clang would compile <OriansJ>The tests might fail as they currently don't check for host OS type only host CPU architecture <OriansJ>but the checksums should still match (and if they do, effectively the tests passed) <OriansJ>essentially you should be able to do: make M2-Planet and it should work regardless of the host OS <OriansJ>then you can just do ./bin/M2-Planet and type in a little C code and then ctrl-d to finish and it should dump the assembly it should generate <siraben>clang-11: error: cannot specify -o when generating multiple output files <siraben>Looks like readme needs some updating, there's no bootstrap directory <OriansJ>siraben: well I do need to get better about the documentation <OriansJ>all of the source code is given to M2-Planet, it produces a big M1 file as output <OriansJ>and hex2 converts it all into one statically compiled binary <OriansJ>(M1 one using a definition file of course and hex2 with an elf header file written in hex2) <OriansJ>as it makes it trivial to find bugs in the compilation process <OriansJ>M2-Planet doesn't care what the host is at all; it always produces identicial output given the same input (and same options) <OriansJ>So if you don't specify --architecture amd64 or --architecture x86 or --architecture armv7l or --architecture AArch64; it'll default to Knight assembly output <OriansJ>blood-elf only cares if you want elf32 or elf64 (--64) formatted output <OriansJ>M1 requires you to specify --little-endian (to generate correct output for little endian architectures) and again to specify the output --architecture; otherwise it'll be big endian and Knight <OriansJ>hex2 requires you to specify --little-endian (to generate correct output for little endian architectures) and again to specify the output --architecture; otherwise it'll be big endian and Knight. (formerly you had to specify if you wanted the output file to executable but we have since switched that behavior to be executable by default) <OriansJ>I just don't get why C programmers love pointer arithmetic so much <OriansJ>just having a proper struct or array is all that it takes to have easy to reason about behavior. But no that would be too obvious. <xentrac>Pike had a really interesting rebuttal to that <fossy>I am a C programmer and I have a "meh" approach to pointer arithmatic <OriansJ>let someone else deal with what (*--(*p++)**) means <xentrac>well, the ** on the end is a syntax error <xentrac>he pointed out that if you call a function and pass in a pointer to an array and an index <OriansJ>fossy: the great sin of C; all of the really useful things in C are in the world of undefined behavior. <xentrac>a pointer conveniently packs together the array and the index into it in such a way that you can't accidentally use the pointer on the wrong array <xentrac>hmm, I guess you're right that *--(*p++) is not UB <OriansJ>still defined then, but just pointless <xentrac>well, you might want to do what that code does, but that code is a gratuitously unreadable way of doing it <OriansJ>xentrac: welcome to the world of "Enterprise Grade Programming tm" <xentrac>you might, for example, be iterating over an array of stacks and popping an item from each stack <OriansJ>xentrac: a proper struct type for the stack would be a better idea <xentrac>the other thing that's nice about pointer arithmetic is that it means that any function that is written to operate on an array that's passed in can also automatically operate on any subrange of such an array <OriansJ>a = stack->contents[stack->index]; sort of thing <xentrac>so I think Pike is correct that there are significant correctness and generality benefits to C's pointer arithmetic <xentrac>unsurprisingly Golang has an improved version of all this with its "slices" <OriansJ>xentrac: I am not saying it *CAN'T* be useful; I am saying more often than not people are not using it properly <xentrac>yeah, that's true, and the struct type is probably better in most contexts too <OriansJ>in mes-m2 there is only a single place where there is pointer arithmetic <xentrac>it's always optional; Pike's point was just that there are ways that it's a less bug-prone alternative <OriansJ>in mes_cell.c: i = i - CELL_SIZE; (because we are garbage collecting a massive array of everything) <xentrac>certainly you are correct that most C code is not very good, and pointer arithmetic is an attractive nuisance <xentrac>especially with the astonishing number of things that are UB <OriansJ>pointer arithmetic is where I find treasures like **********************************p+++++++++++++++++++++++++++++++++++++++++ <xentrac>that's not legal; p++ isn't an lvalue <xentrac>neither GCC nor Visual C++ will compile that <xentrac>so what is this productioncode built with? <OriansJ>that would be HP's C compiler for HP-UX <OriansJ>siraben: the clang error is because it doesn't like .h files <OriansJ>so to build M2-Planet with clang: clang -D_GNU_SOURCE -O0 -std=c99 -ggdb functions/match.c functions/in_set.c functions/numerate_number.c functions/file_print.c functions/number_pack.c functions/string.c functions/require.c functions/fixup.c cc_reader.c cc_strings.c cc_types.c cc_core.c cc.c cc_globals.c -o bin/M2-Planet <xentrac>I'm skeptical that HP-UX's C compiler will compile that either, but I admit I haven't actually tried it <OriansJ>xentrac: its tokenizer is SOOO borked, one has to do funky things to keep names working <OriansJ>like not start your variable name with O (not 0 but upper case o) <OriansJ>porting that piece of shit to GCC compatible was a *BITCH* <xentrac>in colorforth chuck moore used a character code that used the same codepoints for 0 and O, and l and 1 <OriansJ>and get a compile error because you renamed onPoweron to On_power_on <OriansJ>fuck that noise; numbers are numbers and letters should just be letters <OriansJ>I don't want to worry about a function named Oxload being treated like the numeric constant 0x10AD <xentrac>colorforth uses a different way to distinguish numeric constants from function names <OriansJ>xentrac: braille terminals give not shits about that <xentrac>chuck moore wasn't using a braille terminal <xentrac>although he was getting a bit blind in his old age so he was using a pretty huge font <xentrac>actually function names can be either of two different colors <OriansJ>xentrac: guess he should have invested in braille support earlier on. <xentrac>investing in anything earlier on is the antithesis of everything he believes in <OriansJ>xentrac: so no retirement saving either? how sad <OriansJ>50+ years of interest can really make a difference to someone's retirement. <xentrac>the patent royalties from intel and amd have enabled him to start up a chip company in his retirement <OriansJ>but I am serious on the investing early bit; retirement is surprising something that people usually never plan on. <OriansJ>but then again Social Security benefits were created because of that very common behavior. <OriansJ>Too many old people dying in the streets from starvation. <xentrac>well, as you also experienced, betrayal can also strip you of your savings <OriansJ>xentrac: better to learn it young than old <xentrac>like you, Chuck was betrayed by his business associates, in his case a man named Leckrone. and, yes, old <OriansJ>xentrac: interest is only a good bet if you can average better than inflation <xentrac>right. it's difficult to get interest rates that keep up with inflation <xentrac>that is improbable with a fiat currency <OriansJ>xentrac: well no plan for the future can predict all possible outcomes <OriansJ>I could die at any minute because a block of iron the size of a chevy block falls from the sky and lands on my head. Either as a meteor or as a jumbo jet <xentrac>I think Chuck probably thought of using a Braille terminal as meriting a similar degree of consideration <OriansJ>I like to think: plan for people with disabilities who might use your software; because it might end up being you. <OriansJ>the problem is some people only care about *PRETTY* and *LATEST* and *COOL* and don't bother to even write man pages <xentrac>the kids these days, what's got into them? <OriansJ>xentrac: our bad behavior; they learned by watching us. <xentrac>I think you're trying to universalize a standard of behavior that shouldn't be universalized <OriansJ>I hope to be wrong no more than 90% of the time. <xentrac>if you're writing a novel, it's likely a good idea to write an outline and multiple drafts <xentrac>probably not if you're writing a shopping list <OriansJ>xentrac: I am a huge fan of emacs org-mode <xentrac>I don't have a machine that lets me take emacs to the supermarket <OriansJ>print the list first before going to the store <xentrac>if you're writing an entry to the IOCCC you probably don't need to write man pages for it <OriansJ>heck they caused RMS to start the FSF <xentrac>I don't think keratines.sendat would be improved by having a man page <OriansJ>xentrac: fair but the point was more about the software you release for others to use <xentrac>I think I just did that by posting the link here <xentrac>anyway, so I think in a more general sense there are only a small number of things that are inherently good or evil <xentrac>everything else may be good or evil in an instrumental sense <xentrac>man pages belong to the latter category <OriansJ>xentrac: or perhaps nothing in inherently good or evil but the context that makes it so. <OriansJ>fail2ban + ssh/sftp having different behavior in regards to -l 120 = annoying <OriansJ>(sftp it means rate limit, ssh it means login name) <OriansJ>thank god for terminal servers but that is annoying. <xentrac>yeah, Unix command-line flags are pretty inconsistent, but it's less forgivable when it's ssh vs. sftp ;) <fossy>OriansJ: which commit should i be looking to revert relating to kaem <fossy>and if so then would you want me to drop the kaem branch <fossy>i can't remember exactly why that commit was made. <fossy>so i hadn't init'd the submodules <fossy>which caused +> ./catm hold ../M2-Planet/test/common_x86/functions/file.c ../M2-Planet/test/common_x86/functions/malloc.c ../M2-Planet/functions/calloc.c ../M2-Planet/test/common_x86/functions/exit.c ../M2-Planet/functions/match.c ../M2-Planet/functions/in_set.c ../M2-Planet/functions/numerate_number.c ../M2-Planet/functions/file_print.c ../M2-Planet/functions/number_pack.c <fossy>../M2-Planet/functions/string.c ../M2-Planet/functions/require.c ../M2-Planet/functions/fixup.c ../M2-Planet/cc.h ../M2-Planet/cc_globals.c ../M2-Planet/cc_reader.c ../M2-Planet/cc_strings.c ../M2-Planet/cc_types.c ../M2-Planet/cc_core.c ../M2-Planet/cc.c to produce a fed up hold file which cc_x86 segfaulted on? <OriansJ>fossy: the reason why the commit was done; was because I wanted to get a working mescc-tools-seed release and kaem kept segfaulting for reasons I could not figure out at the time. So I reverted to the older known good kaem and used that. <OriansJ>make sure to run your new kaem through M2-Planet to catch the most common reason for those segfaults (declaring variables inside of loops) <OriansJ>or if it makes it easier for you; just do the revert in mescc-tools and I can handle the mescc-tools-seed upgrade <fossy>OriansJ: ah ok, so i will attempt to make it work properly in mescc-tools-seed, and if that is successful, subsequently push to mescc-tools master and PR to mescc-tools-seed, i guess? <OriansJ>if you want to do all of that work, go for it. <OriansJ>but it'll probably be easier just to get mescc-tools master back to having the more advanced kaem; then we can hammer out the mescc-tools-seed problems together.