<OriansJ`>more passing tests but I yet haven't figured out what in the C code could be causing the segfault ***mihi_ is now known as mihi
<OriansJ`>in the case MES_FUZZING is set, the first argument is set as the environment variable MES_BOOT; and it verifies that it does so with the getenv; yet somehow open_boot gets getenv ("MES_BOOT") != 0 to be false???? <OriansJ`>fuck it, I'll just set a C variable. That shit is crazy <Hagfish>hmm, despite my nick, i don't know much about fish, but i'm tempted to have a look <OriansJ`>literally setenv, the immediately following getenv returns the correct string but the getenv in a called function get NULL (because the environment magically changed between the two points????) <Hagfish>hmm, yeah, the code does look pretty reasonable <Hagfish>there isn't some weird scoping rule about calling getenv in a function, right? <OriansJ`>if you do export MES_FUZZING=1 and then ./bin/mes-m2 zero.scm it should echo back zero.scm and then exit with what exit code you set in zero.scm because fuzzing disables writing <Hagfish>and i guess you can't have two simultaneous copies of an environment <OriansJ`>so every called function would by definition have to be under its scope <OriansJ`>unless called functions get new environments???? <Hagfish>it's the first crazy thing that comes to mind, though <OriansJ`>enviroment is just an array passed to main as envp <Hagfish>and there's nothing over-riding the usual meanings of these functions, right? <Hagfish>does the fuzzer do some weird hooks? <OriansJ`>Hagfish: shouldn't as it is a GCC build with standard glibc functions for getenv and setenv <Hagfish>that should limit the craziness, yes <OriansJ`>it would be one thing if the first getenv returned a NULL but it didn't <Hagfish>yeah, i can't think of anywhere for unexpected stuff to be happening <Hagfish>and we're sure there isn't anything underhanded going on, right? :) <Hagfish>i haven't checked for unicode homoglyphs <OriansJ`>Hagfish: well there is always the possibility of understanding things going on since I am a bootstrapper <Hagfish>a bootstrap is the ultimate target for underhanded stuff, i suppose <Hagfish>i can't believe it's really sinless :) <Hagfish>are you sure this is running in a clean/sane environment? <Hagfish>there aren't old copies of broken binaries or libs lying around? <OriansJ`>I did sin mes.c instead of sin src/mes.c <OriansJ`>I should incorporate a proper error message for that case <Hagfish>it feels like it's always worth assuming that some error message or tool is lying <Hagfish>and i guess the person that's most able to fool someone is themselves <OriansJ`>ok so the only unicode is janneke's (c) line <Hagfish>have you tried building it on a different machine, or making a minimal test case? <stikonas>my PR is almost ready now: 46 files changed, 302 insertions(+), 342 deletions(-) <stikonas>(a lot of it is checksum changes though, so not as scary as it might look from diffstat but still) <OriansJ`>GCC wipes the local variable argv[1] as it is no longer referenced in main and thanks to undefined behavior optimizations; the global envp now is pointing to a null string. <OriansJ`>a local variable is almost invariably a bad choice to pass to setenv the exceptions are obscure to the point of almost not existing. ( you need to use malloc or calloc and do string copying) <OriansJ`>The riddle is now solved and it burned a bunch of time to figure it out. <OriansJ`>I'm just going to stick to global variables to pass info between functions and leave the environment manipulation to fossy's kaem. <fossy>stikonas[m]: i am currently away from home but in around 24 hrs I will be able to revirw <attila_lendvai_>hi! i have just found your community, and i'm wondering how broad is your scope... i'm playing with a tiny lisp that can bootstrap itself on top of the Linux kernel in 2-4 kLoC, including everything (besides gnu make, gas, and ld to produce a static binary. but there's proof of concept to get rid of them all with little extra code) it's at https://github.com/attila-lendvai/maru <attila_lendvai_>for whatever reason i myself don't understand, i'm passionate about the problem of bootstrapping, and i'm working out a way to preserve each developmental stage of the language to be able to bootstrap it all the way from a simpler C implementation using the build system ***attila_lendvai_ is now known as attila_lendvai
<attila_lendvai>there are various branches, some of them can be a "stage 0" to start the (reproducible) bootstrap process from. <attila_lendvai>(but for now only one of them is finished/tested/exercised: maru.0.c99) <xentrac>yeah, I've been reading your work on maru; Kartik Agaram mentioned it to me <attila_lendvai>xentrac, small world! :) it's so amazing how people interested in the same stuff can find each other! i didn't really expect an entire community around bootstrapping... and here we are! :) *attila_lendvai is reading the website <xentrac>it's a little tricky to distinguish the stuff you merged from maru-2.4 from the stuff you added yourself, but am I right that you wrote the LLVM backend but not the i386 backend? <attila_lendvai>xentrac, that's correct. i keep the old code untouched in the (divergent) 'piumarta' branch, and started my work from a simpler/smaller version of maru, then caught up feature-wise with piumarta's head be bootstrapping the necessary features <xentrac>I think mostly the channel focuses on live-bootstrap, including mes, stage0, mes-m2, m2-planet, hex0, hex1, ... <xentrac>myself, I've been looking a lot at META II and GPM this week <attila_lendvai>i should also learn about META II. it's only present on my radar, without any depth of understanding. it's an excellent candidate for a maru.0.meta2 branch... :) <xentrac>well, I think PEGs are mostly superior to the LL(1) predictive parsers you can write in META II <xentrac>so I think the main benefit of META-languages is that you can use them to write a PEG parser generator pretty easily <xentrac>because getting them to run is pretty easy <xentrac>Schorre's original paper claims that they're also easier to understand, and I guess in some sense that's true — I've found the error tracebacks from Meta5ix to be usually easier to debug than PEG parsing errors <attila_lendvai>well, maru's sexp syntax is pretty trivial. i'm no parser expert, but it must be parsable by the simplest parsers. <xentrac>yeah, S-expressions mostly avoid the problem of parsing. I was looking at a Henry Baker paper about META from I think 01992 earlier tonight <xentrac>he's pretty anti-enthusiastic about parsing algorithms :) and I think that to some extent that's a necessary reaction <xentrac>but I think there really are cases where a DSL with concrete syntax designed for the task at hand is superior. maybe it's too self-referential, but I think grammars themselves are a good example of this <xentrac>it's certainly possible to represent this as an S-expression, for example: <xentrac>- program: ["-" name @it ":" terms {return}, "#" [:notin ""]] <xentrac>(rule program (many (alt (seq "-" name (label it) ":" terms (emit "return")) (seq "#" (many (notin ""))))) <xentrac>but I would argue that the non-S-expression form is easier to write and to understand, although harder to manipulate in software *attila_lendvai is editing maru's readme to publicly capture the exciting TODO opportunities... :) <xentrac>and I think a variety of systems (OMeta, Prolog, Mathematica, Aardappel) have convincingly shown that general-purpose pattern-matching and -restructuring machinery can be applied to a lot of tasks <xentrac>and of course there's a lot of information out there that's already in some obnoxious format that it's useful to be able to analyze: amd64 machine code, MediaWiki markup, C, R, PDF, or HTML, for example <xentrac>I think it's actually pretty useful. especially for bootstrapping <xentrac>I'm not yet decided on whether the META approach is useful as a stepping stone to Packrat <attila_lendvai>xentrac, what does 'live-bootstrap' mean? i'm reading the mes project, and it's very interesting! it's baffling why i only got here just now. <attila_lendvai>i think i agree with Baker. if it's that complex, then admit that it's not a static thing, and express it as a program to be evaluated <attila_lendvai>and if you need a complex evaluation model, then express that in a simpler one -- which will be bootstrappable using a simple parser <gforce_d11977>attila_lendvai: it means all the steps from nothing to a linux-system are done one after another in a fashion/ready so that you can "just start it". <xentrac>oh, of course you want to express it as a program to be evaluated — the question is what makes that program easy to write <attila_lendvai>thanks! re syntax: i much prefer a simple tree of "words", where complexity is more captured into the words, and less into the structure that is used to combine them. but then, i'm mostly a lisper, so that should be obvious... :) but i'm not sure which came first: my preference, or delving into lisp. <xentrac>right, and if you get to choose how to write the tree down, you can choose to write it in a way that's easy to parse <xentrac>but if you want to, for example, render a TrueType font or scrape alloy melting points out of a Wikipedia dump, you can't <xentrac>I've been spending a fair bit of time over the last few weeks comparing the Lisp and ML views of the world, and I'm increasingly drawn to the ML approach (though I guess that's not really new for me) <xentrac>although I do wish ML had a Lispier syntax! <attila_lendvai>i'm not completely hostile to more complex syntax, but i'm utterly dismayed when i encounter complex syntax in contexts where a much simpler one would suffice <xentrac>but for example I spent a lot of last night doing mental type inference on some Python written in what I think of as a pretty obfuscated style (a friend's clone of GPM) <attila_lendvai>complexity has a cost that is *very* rarely accounted for in the software world <xentrac>and I was really wishing for a semantic model closer to ML's <xentrac>with pattern matching and type inference of sum types, rather than accessor functions for dotted pairs <attila_lendvai>reading mes, i wonder how maru compares to the scheme part of the mes core. maru's semantics is pretty close to scheme. <xentrac>it's an interesting question! when I wrote Ur-Scheme I encountered a lot of design decisions in Scheme that made it unnecessarily hard to get to a self-sustaining system <xentrac>I think Maru has simplified a lot of those decisions <attila_lendvai>without knowing anywhere near enough about mes... it would be an interesting project to try forking it and replacing the scheme part with something based on maru. <xentrac>being able to compile C with Maru would be awesome <attila_lendvai>i was wondering previously how much it would take to make maru scheme compatible... either by forking it, or my extending vanilla maru with a compatibility layer. <xentrac>scheme is usually pretty easy to implement in lisps *attila_lendvai is getting lost in a forest of interesting projects <gforce_d11977>ok, just show it to me / paste.bin or something, i will test <stikonas>just need to apply this patch for 1.13.4 <stikonas>it was already in the tree for some time <stikonas>gforce_d11977: that patch applies cleanly to 1.13.4 too, so just copy it into patches dir <gforce_d11977>ok, will do and report, give me time for first results till evening <stikonas>it patches out those lines that raise error <stikonas>I think that bug was not intermittent in 1.15.1, so I had to find a fix <stikonas>(because we were bootstrapping 1.15.3 with ./bootstrap script instead of running autoreconf) <stikonas>anyway, that should fix at least those frequent errors <stikonas>everything else is fairly infrequent even on your kernel <stikonas>4.9.4 will need C++ compiler which live-bootstrap does not have <stikonas>guile should be good to get first before we build C++ compiler since gcc has soft dependency on guile <stikonas>if so, this will also be fixed together with that more frequent error <stikonas>I'm removing automake 1.12 and automake 1.13 entirely ***pgreco_ is now known as pgreco
<OriansJ`>stikonas: so what you are saying is we should start creating bug reports for TCC for the features needed to compile newer versions of GCC <stikonas>OriansJ`: not really, in live bootstrap tcc 0.9.27 can build gcc 4.0.4, I think tcc from mob branch (which maybe will be 0.9.28 at some point) can build gcc 4.7.4 <stikonas>(not sure about any pre-gen stuff there etc...) 4.0.4 might still be much easier to build <stikonas>but anything later is not buildable with TCC no matter the patches <stikonas>anyway, tcc mob (future 0.9.28) will need either building with older TCC or improvements in initial libc <OriansJ`>stikonas: well we can always do another TCC self-host step; with the best libc we can build at that stage <stikonas[m]>Yes, but in any case GCC 4.7.4 is the last version written in C <OriansJ`>and we will probably have to backport new architectures into it and find someone to do long support on it <gforce_d11977>if this is good, i will start another masstest with 1000 runs, so i get better numbers 8-) <janneke>stikonas: looks like a bug, good catch <stikonas>basically, more than 255 command line arguments wrap