<vagrantc>janneke: i apparently forgot about the file collisions with mes and libc6-dev and such in /usr/lib/<triplet>/ <vagrantc>it occurred to me at some point ... not sure if those can be moved elsewhere meaningfully <vagrantc>i can obviously move them around in the package itself <oriansj>all M1 based binaries are location independent and include their own library can can be treated as standalone static binaries <oriansj>the contents of crt1.o if I remember correctly are hex2 <vagrantc>ok, then i can just move the files around or pass a different --libdir= argument <oriansj>one could say this was spawned from me spamming #guix about the bootstrap seeds and civodul getting annoyed <oriansj>I honestly think janneke was the first person on #guix who actually took my plan seriously. <vagrantc>i remember civodul and janneke talking about "bootstrappable.org" at the reproducible builds summit in 2016 <vagrantc>looks like the initial mes commit was may 2016 <oriansj>vagrantc: about 1 year before janneke's FOSDEM talk that got me to reach out to janneke for the first time <oriansj>stage0's first commit was may 1st 2016 and that was about ~1 Month after I showed my initial hex0 in #guix and got into a big argument with civodul <vagrantc>civodul seems to have come around on the idea since :) <oriansj>honestly, it kind of surprised me when I first saw that because he seemed to believe this was impossible and would never work and the best we could do involved building gcc until the checksum stopped changing <oriansj>FOSDEM 2017 was when I first discovered janneke's work <oriansj>and I sent him an email on March 30th and he replied back on March 31st and we have been working together ever since <oriansj>at which point I already bootstrapped all the way up to hex2+M0+FORTH+Slow_lisp <oriansj>fosslinux: the first stage0 lisp interpreter; now radically reengineered in C <oriansj>I literally wasted about 1 year trying to get a sufficient Lisp in Assembly <oriansj>fosslinux: M2-Planet C is a subset of ANSI C <oriansj>but yes it is written in the subset provided by M2-Planet <oriansj>that way people can work on it with GCC <oriansj>and I can still bootstrap it from M2-Planet when we need to finish the bootstrap entirely <fosslinux>so I'm slowly coming to understand the bootstrap chain <oriansj>basically I learned the really really hard way, that scheme is easier to make in C than in Assembly <oriansj>fosslinux: just making slow_lisp good enough to run MesCC and Guix <oriansj>which is entirely work to be done in C (M2-Planet's subset of course) <oriansj>fosslinux: it is the replacement for mes-m2 <oriansj>because getting Mes.c buildable by M2-Planet broke alot <oriansj>but slow_lisp was always buildable by M2-Planet <oriansj>and much simpler to understand and debug <fosslinux>oriansj: and slow_lisp is written in the m2-planet subset? <oriansj>So all I need is people to write good scheme tests and I'll build the functionality required to get the results identical to guile's output <fosslinux>are there any particular gotchas for working in m2-planet? <oriansj>fosslinux: No C macros of any kind # is a line comment and // is ignored to allow M2-Planet CONSTANT to be in the same file with #define constants 1 sort of things <oriansj>hence why you see // CONSTANT foo 1 and #define foo 1 together <fosslinux>I guess after the bootstrap chain is finished we still need things like bootloader, kernel and shell <oriansj>#define is needed for gcc and CONSTANT is the M2-Planet equivelent <fosslinux>ah so it's compatible with both m2-planet and gcc <oriansj>actually we have scheme replacements for the shell which will be running on slow_lisp by the time we are done <oriansj>basically the only bit of M2-Planet that isn't compatible with gcc is the inline assembly <oriansj>but that is only needed for implementing syscalls like write or execve <fosslinux>haha "kaem is the world's worst build tool." <oriansj>well no variables, only comments and commands to do real work <oriansj>fosslinux: all of the C code I have written in stage0, mescc-tools, M2-Planet and Mes-m2 are that subset <oriansj>it honestly is not hard to restrict ones self to that subset <fosslinux>Looking at the bootstrap chain writing all these things in assembly would be hell <oriansj>implementing it in assembly was fun (the cc_* family) <oriansj>well I kinda did that too if you take a look in mescc-tools-seed <oriansj>hex2's minimal x86 core to build M1's minimal x86 core (M0) and then build cc_x86 and everything else is C code from there <oriansj>I took alot of time and effort to try to make it as trivial as possible for anyone to know how it all works <fosslinux>Well it worked because I could understand it relatively easily <oriansj>Lack of clarity about any detail is a major bug that needs to be fixed <smithras>It's a little incredible that it can be made simple enough for one person to meaningfully go through and check it all <oriansj>well the most important part of bootstrapping is I want absolutely no one to trust me <oriansj>Assume I am an evil genius inserting bad things; <fosslinux>oriansj: is blood-elf the magic that changes what all the hex stuff into elf binaries <oriansj>blood-elf just generates dwarf stubs <fosslinux>how do those tapes from stage0 get changed into elfs <oriansj>that way when you do objdump -d binary, it has useful names and instruction decoding to show you <smithras>I'm looking forward to eventually playing with this project, unfortunately exams have stolen all of my hacking/exploration time at the moment :( <oriansj>fosslinux: the tapes in stage0 are for the bare metal and the elfs are for the linux bootstrap <fosslinux>so for Linux bootstrap mescc-tools-seed is what I should look at right <oriansj>basically the Linux bootstrap pieces are for those who feel safe starting on a linux blob with nothing else <oriansj>the stage0 pieces are all bare metal <oriansj>hence the next stage0 piece is a posix kernel that cc_* can build <oriansj>then one doesn't have to trust Linux at all <oriansj>fosslinux: this is a long term project routing out places where attacks could hide <fosslinux>yeah I get that, but this POSIX kernel dosent exist yet right <oriansj>the mescc-tools-seed is just to give guix their 257byte bootstrap seed <oriansj>fosslinux: because I nor anyone else has started writing it <oriansj>now in theory one could find a Posix kernel written in C and convert it to M2-Planet <oriansj>but I haven't found any simple enough <oriansj>just like how the knight hardware in stage0 isn't in TTL yet (it is delayed so we can get the guix win done) <smithras>oriansj: even though the posix kernel is still TBD, I imagine we could still semi-verify the stage0 bootstrap by running it on linux,bsd, etc and comparing results? <fosslinux>is it possible to run stage0 from the initial hex0 on x86 today? I guess this is kind of out of scope in a way but how would someone bootstrap up to cc_x86, seeing as we no longer use punch cards and tapes? <oriansj>smithras: yes that is true and the results are the same on BSDs <oriansj>../kaem-optional-seed --strict --verbose and you are done <oriansj>everything from hex0 to M2-Planet on x86 and AMD64 is done <fosslinux>yeah but then isn't the kernel and shell trusted? I guess this is the same problem we were talking earlier <oriansj>fosslinux: only the kernel is trusted (as the kaem-optional-seed doesn't use the shell) <oriansj>that being said the stage0 bare metal cc_x86 build of x86 M2-Planet is identical to the mescc-tools-seed generated x86 M2-Planet <oriansj>(because M2-Planet is cross-platform reproducible) <smithras>So would the end goal be a custom minimalist x86 board specifically for running the hex0 editor off of a tape without a running kernel? <oriansj>and the steps are rather simple to build everything else <smithras>oriansj: sorry, what does TTL stand for? <oriansj>think building directly in NAND, AND, OR and XOR gates <oriansj>The original plan was always assume nothing <oriansj>No kernel, no firmware, no bios and no microcode <oriansj>Nothing that can't be inspected by hand <xentrac>oriansj: oh, really? I didn't think they'd written anything more complicated than dc in B <xentrac>fwiw Jonathan Rees, who wrote "A Security Kernel", was one of the authors of Macros That Work too <smithras>There would be something really special about building that and then watching it build the foundation of the entire software ecosystem <xentrac>but now I see that the B compiler was eventually rewritten in B <oriansj>smithras: well that is what everyone is going to get from guix "real soon" <oriansj>xentrac: basically B was used to build New B which instantly was used to build Embryonic C <oriansj>and everything was C from that point on <oriansj>So yeah, technically I might actually be the first dumbass to ever write a C compiler in assembly <oriansj>smithras: have you played with slow_lisp yet? <xentrac>surely Turbo C was written in assembly, for example <smithras>oriansj: not yet, I'm a bit late to the bootstrapping party :) <xentrac>certainly there were plenty of Tiny C compilers for CP/M that were written in assembly, but maybe those don't count <oriansj>xentrac: The Tiny C compilers are all based on Cain C <oriansj>which was built using an AT&T C compiler <oriansj>and it sure as shit wasn't written in assembly <xentrac>but a lot of the people who worked on Tiny C compilers didn't have a C compiler or a machine that could run AT&T C <oriansj>And I can not find nor anyone else I have talked to could find a C compiler written in Assembly <oriansj>but Pascal was readily availbe and so was basic <xentrac>right, but it wasn't practical to write a C compiler in them on a CPM machine <xentrac>Turbo Pascal compiled super fast but the code it emitted wasn't tight <oriansj>xentrac: Turbo Pascal was written in Assebmly <xentrac>in general it's hard to get decent code out of a C or Pascal compiler on an 8-bit machine <oriansj>but Turbo C was written in Turbo Pascal <xentrac>that's why i was so sure Turbo C was written in assembly <oriansj>that it was dog slow relative to Turbo pascal <oriansj>cc_x86 supports structs, unions, inline assembly, gotos <oriansj>and Turbo C did have alot of optimizations <xentrac>but strongly suggests that cc_x86 wasn't compiled with itself <oriansj>cc_x86 is a C compiler written in Assembly; so yeah <xentrac>that's what I was suspecting from the 48KiB number <oriansj>That is what is required to build M2-Planet <oriansj>hence why I say I might be the first dumbass to actually write a C compiler in assembly <oriansj>now there was a poster on Hacker news who claimed to have done it first but when pressured, they were unable to provide proof <oriansj>I'll have to findthe hacker news post about cc_x86 built in knight assembly <xentrac>there sure were a lot of C compilers in 1983, some of which ran on CP/M machines <xentrac>it wouldn't be terribly surprising if someone who had actually written a C compiler in assembly in 1984 had lost all of the copies of it <xentrac>also people could be lying of course <oriansj>and I'll happily give anyone who wants the first dumbass crown to anyone who wants it <oriansj>just show me the source for any C compiler you wrote for CPM/DOS and I'll be happy to say nope they beat me to it <oriansj>I just never managed to find 1 in 20 years of looking <oriansj>a whole raft of C compilers written in C <oriansj>but the number of compilers written in Assembly which is actually publicly available <oriansj>Yeah Turbo Pascal was written in Assembly (I can't find the source anywhere) <oriansj>DEC Bliss Compiler was written in Assembly (no Sources anywhere) <oriansj>I could find interpreters written in Assembly <oriansj>Basic and Lisp (Neither of which buildable) <oriansj>I found a RAFT of FORTHs written in Assembly <oriansj>xentrac: at the same time; C compilers written in Assembly would have sold like hot cakes back in the 1980s <oriansj>so anyone who did it in the 1980s could have made alot of money, just selling copies for $40 a pop <oriansj>Think about it a 10Kloc/s C compiler in the 1980s <oriansj> Turbo pascal was a 1Kloc/s compiler <oriansj>who cares if the binaries are slow; it would have been a revolution for C developers <oriansj>So we have to imagine someone smart enough to write a C compiler in Assembly but dumb enough not to think hey sell a few copies for $10+ <oriansj>now in the 1990s maybe that speed wouldn't have been so huge but would someone not share it on usenet or IRC? I can't imagine that not spreading <oriansj>by the 2000s; it is probably slower than C compilers written in C (thanks to modern optimizations) but again it would still make slashdot <oriansj>by the 2010s it would be a front page article on Hacker News (it was for 3 days straight when I did it) <oriansj>and something that big for that long, everyone was seen it atleast once <oriansj>so I ask, is it actually reasonable that anyone ever wrote a C compiler in assembly before me? because the more I look at it; the less likely it seems <oriansj>please someone prove me wrong because it feels weird being the first person to do something so freaking trivial <oriansj>literally something that could have been done in a single day trivial <oriansj>which everyone kind of thinks of like landing on the moon hard <oriansj>fosslinux: hopefully my stage0 work helped you get past that <oriansj>fosslinux: well that is the thing about assembly, it is the reflection of what the programmer cares about <oriansj>if you want clean code, you can have it. If you want speed above all you can have it. If you want to just slam something simple out fast you can <oriansj>The only thing you can't do in assembly is portablity or rapid prototype <oriansj>If you want total control of memory to make it impossible for an attacker to do any injection attacks of any kind, you can. <oriansj>If you want to build the stack up or down, you can in assembly <oriansj>If you want to efficiently go from an Int32 to a string of hex values you can <oriansj>and only requiring 10 more bytes to support 64 <oriansj>(:hex32l and :hex64l in M0 if you are curious) <fosslinux>Ive mainly been looking at NASM assembly so far <oriansj>M2 is C code; so technically I guess you could call C portable assembly <oriansj>you actually have to define the Instructions you plan on using in M1 <fosslinux>what about M0 then, how does it differ from M1? Is M0 not architecture neutral? <oriansj>M0 is a single architecture port of M1 <oriansj>aka M1 --architecture x86 is the same as x86's M0 <oriansj>M1 --architecture aarch64 is the same as aarch64's M0 <oriansj>One can make a set of instructions that are architecture neatural and seperate definition files, such that the code writtin in M1 works on all of the architectures <oriansj>The instructions in the nasm version of M0 include that little trick too <xentrac>oriansj: BDS C for CP/M was written in assembly language, according to Byte <xentrac>"On the positive side, the BDS C compiler is exceptionally well suited to the CP/M environment. Its library is equipped with the special functions you really need to use the machine: inp() and outp() for doing port I/O, bdos() and bios() for communicating with the operating system, and convenience functions like kbhit() for testing console status. <xentrac>"More important, the compiler is written in assembly language and optimized to give acceptable performance even on a relatively slow 8080-based microcomputer. (I've never seen another <xentrac>compiler under CP/M-80 that could match its speed of compiling and linking; debugging sessions can be quite lively, which is normally only true with interpreted languages." <xentrac>BDS didn't support longs, doubles, floats, static variables, or initializers <xentrac>but small-C didn't support pointers to pointers, structs, or multidimensional arrays, so BDS C is pretty much real C <xentrac>however, small-C was written in small-C, so it could compile itself; it didn't need AT&T C once it was ported. So I was pretty wrong about that <fosslinux>oriansj: is slow_lisp branch of mes-m2 essentailly where you are doing work now? <fosslinux>oriansj: also, does M2-Planet not support array declerations? <fosslinux>maybe I should try allocating some memory on the heap instead as a workaround instead of the stack <janneke>xentrac: the whole macro thing is interesting. mes integrates a very early psyntax but it's too slow to use and not compatible enough with guile. <janneke>currently, mes has define-macro in C and creates syntax-rules from that <janneke>that code is two years old (very old for mes :-) and i'm not happy with it, but currently it gets the job done <janneke>i have looked into Andre van Tonder's syntax-case, which might be bootstrappable, but i didn't get it to work afte putting in some serious effort <janneke>that still might be one of our best bets at reaching full guile compatibility while being bootstrappable <janneke>currently, i am slowly working towards booting guile-1.8's psyntax to reach full guile compatibility <janneke>fosslinux: yw, i am working on the scheme-only bootstrap integration first <janneke>after that i will focus on finishing the intermediate mes-m2 -> mes merge <oriansj>xentrac: thank you, I feel much better now <oriansj>fosslinux: well supporting of int foo[4] wasn't required as int* foo = calloc(4, sizeof(int)); works fine and allows foo to be passed to other functions and I haven't added that complexity to the stack yet <oriansj>fosslinux: and yes slow_lisp is my current work, with the hope that it becomes the next mes-m2 and thus saves janneke from further work on the Mes.c side of the bootstrap <oriansj>xentrac: so assuming BDS-C retailed for just $9.95, he made about $1M; if it was $49.95-> $5M but I can't find the retail price yet <oriansj>if he priced it as a complete development suite (say $200); one could say $20M from a 1 year project in 1988 <oriansj>and the fact; he personally provided phone support 24/7 the retail price might have been even higher ***ChanServ sets mode: +o rekado
<oriansj>odd that guile doesn't support list=? and vector=? <oriansj>and it looks like I crossed the definitions of pair? and list?; easy to fix <smithras>oriansj: is vector=? shorthand for (vector= eq? ...) ? <oriansj>smithras: in scheme there is char=?, string=? and I am pointing out there should be a vector=? which has similiar behavior (compare objects of that type together) <oriansj>eq? is the short hand of first matching types and then using the type specific comparison to determine the result <smithras>oriansj: oh okay. I agree it's odd that there isn't a builtin for it <smithras>although I suppose that's just scheme being minimal again <oriansj>smithras: well if one were to think only in terms of counting symbols you would be absolutely right but in terms of cognative expectations, no <zig>eq? is pointer equivalence <oriansj>aka if you know type=? then not having vector=? and list=? is overhead <zig>outside scheme world, eq? is pointer equality. equal? is what oriansj describe. <zig>yes, if you know the type use the precise predicate for a faster comparison. <oriansj>and there is also eqv? which is minimal how? <zig>I never use eqv? because I do not remember the definition. <oriansj>hence the cognative load is higher; despite having fewer keywords <zig>eqv? is between eq? and equal? it is precisely defined in R7RS pdf but it dubbed a historical procedure, that kept for backward compatibility. <oriansj>why the half-steps between speed of knowing the exact types and a proper universal comparision? <zig>like say python, if you forget a few things (like the order of the application of arguments is not defined) it is simpler ;) <oriansj>zig: to implement that is true but that is shifting the problem to the users <zig>eqv? john cowan wrote that eqv? is in r7rs for historical reasons. <zig>john cowan is the R7RS editor. <oriansj>zig: I never got the historical reasons argument; when one can trivially add (define eqv? equal?) <zig>yeah, one could do (define eqv? equal?). The summary, it is safe to do equal? all the time, if you need performance use eq?, =, char=?, bytevector=? etc... in particular comparison between numbers is = <zig>(where a number can be a signed integer, float, double and in guile bigint) <zig>(it can also be a complex...) <oriansj>zig: correct, hence why eqv? is kept for historical reasons if simply adding (define eqv? equal?) to any file that needs it will work? <zig>I am too lazy to ask... and reading r7rs page 30, it is written: "obj1 and obj2 are pairs, vectors, bytevectors, records, or strings that denote the same location in the store". That is, when obj1 and obj2 are compound object (objects made of other object) in that case eqv? returns the result of eq? <zig>so one can not replace eqv? with equal? for backward compatibility. I agree that is very odd. <zig>if for some reason, someone relied on one of the numerous behavior of eqv? that sometime behave like eq? sometime like equal? <oriansj>zig: well I guess one could write (define (eqv? a . rest) (cond ... to implement identical functionality. if one required exact compatibility... <zig>yeah, I agree, also I never faced the backward compatibility hell of any sort. When I upgrade a software, I don't except to get everything for free. <zig>minimalism in the sense of scheme is not "only the required primitives to make it turing complete" <oriansj>also I find it freaky that (eq? 2 2) is not specified <oriansj>zig: I always viewed minimalism in terms of cognative load rather the number of items <zig>yes, minimalism is not the number of items. I also agree that cognitive load of scheme could be improved e.g. removing eqv? or making string of chars immutable. <zig>There is different forces at play in the standard, one can not please everyone. <zig>in the above: forces is people with different interests. <oriansj>zig: I guess that is one advantage of C; a single mind choosing what should be in the minimal core <zig>I already noted the undefined order of arguments evaluation. There is similarly, let, letrec, letrec* and let* that exists because of the same reason. <zig>The one that works in most situations is letrec* <oriansj>I'm sure M2-Planet's current lack of switch statement support probably bugs someone <oriansj>(and I wouldn't reject a patch that added support for it if it were in a form cc_x86 could build) <oriansj>I'll probably just have =, char=?, string=?, list=?, vector=? and equal? as eq? and eqv? can be implemented in scheme from those <zig>there is no vector=? in guile, there is bytevector=? <oriansj>vannila guile doesn't include bytevector=? nor vector= <oriansj>one gets ;;; <stdin>:1:0: warning: possibly unbound variable `bytevector=?' <oriansj>and ;;; <stdin>:2:0: warning: possibly unbound variable `vector=' <oriansj>now, yes those are loadable via modules if I remember correctly <oriansj>I could also do symbol=? if I wanted to be cheeky <oriansj>janneke: now slow_lisp handles (make-vector 0) and (make-vector 42 (cons 1 2)) perfectly <oriansj>janneke: since mes.c doesn't support circular references [a la (let ((x (list 'a 'b 'c))) (set-cdr! (cddr x) x) x)] would it be fair to say slow_lisp doesn't have to support it? <janneke>oriansj: i am not sure how useful it is, but i am pretty sure mes supports it <janneke>$ src/mes -c "(display (let ((x (list 'a 'b 'c))) (set-cdr! (cddr x) x) (list-head x 20)))" <janneke>(a b c a b c a b c a b c a b c a b c a b) <janneke>oriansj: like so many other choices... <janneke>if we can get away with not supporting them for now, why not drop it? <janneke>i am sure that circular lists are essential to a mathematician, not sure if they are used in the bootstrap process <oriansj>well, I am mostly focused on making slow_lisp optimal for bootstrapping <oriansj>thus anything that wouldn't be useful for someone doing real bootstrapping work will be tossed <oriansj>just close enough to run guix and MesCC without code changes <oriansj>aka no difference is code paths between guile and slow_lisp <janneke>my first step in that direction is booting the guile module system <oriansj>janneke: I could help if you had some trivial tests available <janneke>this needs only some changes to hash.c and module.c, so in the builtins area <oriansj>janneke: you remember I am still merging mes.c with slow_lisp right? <janneke>oriansj: yes! crazy, exciting and scary :-) <janneke>oriansj: i am still working on the mes-m2 -> mes @wip-m2 merge just when you got pointer cells to run; just before the new boot sequnce, test revamp, builtins rewrite etc <oriansj>janneke: it might go faster if we just rip the bandaid off and just switch to the slow_lisp branch entirely <janneke>the guile module thing is after the full source bootstrap release <janneke>hmm, we are going more than fast enough right now for me :-) <janneke>i just pushed wip-bootstrap to guix for a first review round of the scheme-only bootstrap with mes-0.21 <janneke>one of the things we need most i think, is simpler, easier, more "boring" code <janneke>you are doing great things there for mes; we also need that for mescc <janneke>but first, after merging the scheme-only bootstrap, releasing mes-0.22 and merging wip-full-source-bootstrap <oriansj>blog post and rubbing it in other distros faces... International tech headlines for your great work of course <janneke>yes! getting people informed and on board <janneke>althogh the full source bootstrap is prototyped, i first really want to make the most of scheme-only bootstrap <oriansj>janneke: that is why I argued for keeping stage0 out of the guix root and stopping at mes.c at the bottom <oriansj>aka let other people use stage0 to build mes.c and guix bootstraps only from scheme and nothing else <oriansj>thus you still get the we bootstrapped from 257bytes and our base is lisp <oriansj>With only a single kaem script outside of guix itself leveraged in the bootstrap <oriansj>also I have an idea to simplify MesCC further in its next major release <janneke>hmm, it may just be cool to keep stage0/m2-planet-boot0 in guix -- but bootstrapping from scheme only (staying with that theme) could be nice too <janneke>it's always good to have several options <oriansj>once we get Mescc able to build binutils directly, the next major version of Mescc can output pure gas assembly and get alot simpler <oriansj>but that requires us to get MesCC good enough to build GCC directly and that would make MesCC on par with Clang and GCC in terms of importance <oriansj>a very long term important project indeed <oriansj>janneke: this might just be an insanely stupid question but I noticed Mes.c's apply is of the form: (SCM fn, SCM x) <oriansj>but does anything in MesCC actually leverage tail calls? <janneke>oriansj: no, mes.c does not do tail call elimination <janneke>*optimization / call-ret elimination <oriansj>no as it the returning to something other than the caller part <janneke>well, as the continuation is R3, it might be pretty cheap/easy to add something like that <oriansj>janneke: I know it would be cheap to add; I am wondering how much farther I can strip down the eval for simplicity and keep running MesCC <xentrac>oriansj: eq? can't be implemented in terms of the things you suggest <oriansj>xentrac: because (eq? 2 2) is unspecified? <oriansj>or because (eq? (list 'a) (list 'a)) must be false? <xentrac>no, because (begin (define a '(a)) (define b '(a)) (list (eq? a a) (eq? a b))) <xentrac>(begin (define a (cons 'a '())) (define b (cons 'a '())) (list (eq? a a) (eq? a b))) <xentrac>but presumably list=? would give you #t #t <xentrac>BDS C sold for US$150 in 1983; I don't know if that price was higher or lower than before <xentrac>so yeah that suggests several million dollars in revenoo <oriansj>xentrac: list=? would just give #t in that case <oriansj>also (eq? '(a) '(a)) is also unspecified <oriansj>but (eq? '() '()) is specified to be #t <xentrac>because my point is that eq? can reliably distinguish between them <oriansj>well that is why I need a good test set for eq? to ensure slow_lisp does it perfectly <xentrac>(eq? '(a) '(a)) is indeed unspecified because the compiler can implement it as either of those two cases <oriansj>xentrac: but what about eqv? can it be implemented using eq? and equal? <xentrac>and the appropriate type tests of course <zig>"full source bootstrap" reads like a magic spell. <oriansj>janneke: I think I solved the need for space between #;()#t <oriansj>zig: but the source code reads like I need to learn to spell <janneke>it's amazing how well it work to just let something rest and not worry <fosslinux><oriansj> fosslinux: well supporting of int foo[4] wasn't required as int* foo = calloc(4, sizeof(int)); works fine and allows foo to be passed to other functions and I haven't added that complexity to the stack yet <fosslinux>that's what I figured the best way to do it was <theruran>so uh, is mes-m2 supposed to segfault when run without any options or with a non-existent file? I traced it down to line 52 of mes_read.c where it calls fgetc(source_file) when source_file is 0x0. <janneke>ah, that's prolly straight from mes; pretty silly not to give a proper warning <dddddd>janneke, do you mind a guix question? I drop it on #guix but maybe is so silly (I'm not familiar with the distro yet) that everyone ignore it. <dddddd>Let's say I want to always download from guix servers, not any random upstream server. <dddddd>Is that supported? Much like in debian one downloads always from debian mirrors. <janneke>dddddd: oh, you prolly just picked a bad moment ;) <dddddd>someone was asking something somehow related, and I tried (: <janneke>dddddd: i tried to answer my best on #guix <dddddd>I guess they don't like my nick xD <theruran>janneke: I'm sorry, I don't understand. I am running bin/mes-m2 from oriansj's mes-m2 repo on the slow_lisp branch. I don't see where your patch would apply. <janneke>theruran: ah sorry -- i think mes-m2 has a mes_posix.c file? <janneke>oh, and even open_input_file is gone :) <janneke>a good thing i started the merge early <theruran>this one is compiled with GCC c99 + glibc <janneke>yes, i don't think mes-m2 can be compiled in all weird configurations that plain mes can :-) <janneke>mes_builtins.c: spinup(make_sym("open-input-file"), make_prim(builtin_open_read)); <janneke>so there would the patch go; if mes-m2 still has error and throw, etc. <janneke>theruran: i very much like remarks such as yours; this open-file segfault has been bothering me but never enough to look a it and it can be addressed very easily <dddddd>heh, ironic that so much conversation about bootstrapping in #guix eclipses the guix questions :P I'll try again in another moment. <oriansj>essentially because the default code path attempts to be compatible with mes.c but a few things are not done yet <oriansj>and MES_CORE simply skips the loading of the file and goes straight the REPL by default <theruran>I see, so it will be fixed when the rest of the system is implemented. It's a bit confusing to use, and I don't know if that's because it is meant for bootstrapping and not other real-world use. I am still trying to understand what's missing. <janneke>i think what's missing is person-power <janneke>i am in the process of releasing mes-0.21 and just found yesterday that on x86_64, starting mes as a repl was broken <janneke>turned out it has been broken for many releases <janneke>the bootstrap in guix uses x86 exclusively, so i almost never build 64 bits <janneke>also, the bootstrap does not use the repl <theruran>I was just expecting it to give me a REPL with a > PS or give a help message, or spit out an error. But segfaulting is kinda rude :P <janneke>instead of rude, you could say: implemented with a rigourous focus on bootstrapping :P <oriansj>theruran: are you on commit 68ba63f3e82861b243deb55bee92dc4292027961 ? <theruran>I have been getting segfaults in other software like GNUcash on startup so I figured this might have been because I have a lot of compiler and kernel hardening features enabled.