<OriansJ>mihi: 1) you don't have to use lseek; just read 20MB the kernel will return less than the count of read bytes if the file is smaller. (we can deal with the special case of files being exactly 20MB the same way we treat files that are larger than it.) 2) good idea of using lseek to record file system in the struct if the read returns the full 20MB. 3) Let us assume files in M2-Planet programs are for either read or write and never switch <OriansJ>between those cases. And if they do raise a big freaking flag and kill the program. 4) writes only need support being flushed (on reaching end of buffer, \n (per the glibc standard behavior) or on fflush/fclose) and maybe lseek (Haven't seen an example of that yet which is a good idea on a write only file.) 5) I was simply thinking of moving all of the syscalls to unistd.h for each architecture and putting all common code written in C <OriansJ>that uses those syscalls into a libc folder; so I can stop doing the same fix 5 times. 6) yeah that seems to be the behavior with glibc but honestly it doesn't matter if we match that behavior or not. <OriansJ>siraben: the largest files M2-Planet is compiling are those being generated in blynn-compiler. As mes-m2 is only 6,599 lines of code (totaling 172,342 chars over 30 files) and M2-Planet is only 2,427 lines of code (totally 106,168 chars over 16 files) <siraben>fossy: yes, hopefully the next step is an r5rs interpreter, this is also where I hope we can get some Haskellers on board as well <siraben>i'm going to raise the CI timeout to 15 minutes, updating m2-planet fixed it but now the build is nearly 10 minutes <siraben>OriansJ: I opened a PR on oriansj/blynn-compiler <OriansJ>now comes the hard part for blynn-compiler. Remove blobs and make it do something useful. <siraben>One of the first things to check is if/how blynn-compiler supports tail calls <siraben>i'm concerned about heap exhaustion but since we've managed to compile larger and larger Haskell programs, it probably won't be a problem. <pder>Its about 12 minutes on my i7-3630QM CPU @ 2.40GHz <siraben>Before writing a Scheme I'll fix the blob issue <OriansJ>pder: well 12 minutes for all of the steps; isn't half bad. MesCC used to have 45minute compile times <OriansJ>wow, things have been so crazy this week, I missed a stage0 pull request. <siraben>i'm sure some of the blynn-compiler steps can be combined <OriansJ>siraben: honestly the smaller the steps, the easier to audit and remove bugs <siraben>If I rewrite the blynn-compiler bootstrap in Guile, could someone help make it mes compatible? <janneke>siraben: it would be good to know that mes does currently not support syntax-case <siraben>janneke: that I know, I will macro-expand as needed <janneke>it would be good to have a glance at mes/module/*.scm; you'll see that many basic guile constructs are available <janneke>notable omissions are: modules are faked (should not be a problem) and no match (syntax-case) <siraben>i only need lambdas, primitives and some special forms <janneke>mes doesn't have (ice-9 textual-ports), it's using the older (ice-9 rdelim) procedures <yt_>janneke: how does mes fake modules? I'll probably want to do something similar in mes-m2 <janneke>yt_: something like: mes/module/mes/boot-0.scm <janneke>(define-macro (define-module module . rest) basically-no-op) <janneke>and then include-from-path on a shadow tree with .mes files <janneke>yt_: i guess that's what mes-m2 does, unless that was removed from the fork <yt_>I think OriansJ turned mes-m2 into a rewrite from scratch, so it doesn't support modules at all at the moment <janneke>a good thing i gave up merging improvements back <janneke>adding proper module support shouldn't be too hard <janneke>it's basically lifting the module code from boot-9.scm, and supporting a couple of basic module-lookup procedures <yt_>my Scheme background is pretty weak, so for me most of the work is figuring out what it's *supposed* to do <janneke>yt_: yeah, i guess we're all learning a lot <deesix>What's the rationale for the "$arch/Development/" dirs in mescc-tools-seed? I mean, what goes there instead of into "$arch/"? <yt_>deesix: I believe only files that are actually needed for the bootstrap go in $arch/ for example hex0.hex0. while creating the hex0.hex0 file, you probably go through an M1 and hex2 version of the same program, which for readability and verification is useful to keep around. those files go in $arch/Development <siraben>What's the relationship between stage0 and mescc-tools-seed? <siraben>blynn-compiler uses the latter for bootstrapping <mihi>OriansJ, thanks for the feedback. I will only reluctantly create a commit with my name on it which will (speculatively) calloc a 20MB buffer on every fopen/read even if the file may only be 10K, but on the other hand I still start up my scratch Linux VMs with 512MB RAM (used to be 384 MB a few years ago) and mostly get away with that... <mihi>I will try to implement your suggestions after the holidays. <mihi>BTW I have seen programs that write binary file formats where there needs to be some offset to a structure in the header, that first write zeroes and when the file is finished, seek back and fill the gaps. Not sure if this will ever be needed for M2-Planet or its libc, probably depends on how early in the bootstrap mes-m2 compiled programs can be discarded/replaced. <mihi>(or they will get changed to write .hex files and have hex2 fixup the offsets instead) <mihi>BTW would be great if any of the ARM guys could try my changes on the ARM architecture if they work out of the box or if they also fail like on AMD64. <mihi>s/mes-m2 compiled/M2-Planet compiled/ <stikonas>siraben: stage0 is more or less similar thing but for custom "knight" architecture and it also has knight VM <stikonas>whereas mescc-tools-seed is for i386, amd64, arm, arm64 <stikonas>siraben: knight is some simple architecture with two tapes (input and output) which can in principle be implemented on TTL logic... <stikonas>but mescc-tools-seed depends on stuff like kernel, etc... which can't be bootstrapped withing messcc-tools-seed <siraben>stikonas: Ah I see, so stage0 is even more independent. <stikonas>siraben: kind of but at the moment it only runs on vm.c <stikonas>so in practice right now it is not more independent <siraben>VMs everywhere, blynn-compiler has its own graph reduction VM <xentrac>weird, I thought knight wasn't custom, wasn't simple, and had in fact been implemented in TTL 45 years ago <xentrac>what's your metric of "simple", stikonas? <stikonas>I guess by simple I meant fewer instructions... <stikonas>oh I didn't know knigt was implemented 45 years ago... <stikonas>but in any case I wasn't talking about any strict "metric". You can have one instruction architecture, but it wouldn't be easier to read and understand <xentrac>doesn't knight have like 100+ instructions? <xentrac>I mean that's simple compared to an i7 but it's not really in the territory of Wirth RISC, the PDP-8, the MuP21, or the LGP-30 <stikonas>in any case, at some early point bootstrap has to be hardware specific... <stikonas>if you don't want to rely on any software already rynning <stikonas>and mescc-tools-seed has to rely on some software already running... <xentrac>yeah, although I think a simple virtual machine that anyone can implement would probably help some with that ***ChanServ sets mode: +o rekado