<stikonas>how do I build mes? When I run ./configure, I get platform not supported: x86_64-unknown-mes <OriansJ>stikonas: one can build mes-m2 if you would like <stikonas>yeah, I can try, but I did not find any build scripts yet <stikonas>I guess it's not yet ready for M2-Planet <janneke>OriansJ: just to give you a heads-up <janneke>i have pushed a wip-merge-struct branch to my mes-m2 gitlab <janneke>in which i have removed the new major change in boot behaviour <janneke>i have tagged that with `start-merge-struct' <janneke>i also pushed a rewritten master, in which the new boot behaviour change floats on top of this new branch point <janneke>i would like to see if with reasonable effort this can be nicely merged back into Mes <janneke>a macro-free, m2-planet ready, struct cell based mes is a major feature that i would like to release at some point <janneke>possibly that's too much work, i'll just have a go at it <OriansJ>although #include <assert.h> might be a problem for M2-Planet <OriansJ>So I'll probably have to create an approximate alternate (something like void require(int bool, char* error); which will display the error message and exit(EXIT_FAILURE) if false <OriansJ>or maybe require(int bool, char* error, struct scm* cell); thus one could inspect the cell that isn't conforming <OriansJ>well I'll play with that and release something <janneke>OriansJ: hah, trying to resurrect the M2-Planet build, i just arrived at an assert () <OriansJ>janneke: I'm going to rewrite all of those today <janneke>OriansJ: great, I'll refocus on the -> Mes integration <OriansJ>feel free to change up anything to make that easier for you <janneke>going to push what i have to my master, but that needs some work still <OriansJ>and I'll be picking off the M2-Planet compatibility issues <OriansJ>mes_builtins.c also has the FUNCTION0/1/2/3 problem <OriansJ>as M2-Planet supports FUNCTION and it is more powerful than GCC's function pointers <OriansJ>but GCC can't handle a universal function pointer type <OriansJ>So; I'll have to simplify it out when we get proper tests for the primitives in <OriansJ>and char* getenv(char*) doesn't appear either; I guess I have a replacement for that in kaem <OriansJ>yep: char* env_lookup(char* token, char** envp) <OriansJ>and with only a few minor tweaks the first of the Mes.c source files is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes.c <janneke>OriansJ: what settings do you use for `indent'? i made my changes on the GNU branch and moving them proves much harder than i hoped; i think i'll just retype them <OriansJ>janneke: tab (it is instantly visable if you use whitespace-mode) <janneke>OriansJ: sure, no i mean the program <OriansJ>oh, I use astyle when importing code <janneke>indent -linux moves the { and * in the wrong spots; possibly -kr -tab or -orig <OriansJ>janneke: and this should make you excited: M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_eval.c <janneke>OriansJ: changes are up on my `wip-merge-struct' branch, please just rewrite as convenient <janneke>i started by removing any libc stuff from src/*.c; before doing a real merge with mes <OriansJ>janneke: I'll try to get that in once I finish mes_gc.c's M2-Planet makeover <janneke>now the libc solution starts making more sense; parts come from M2-Planet, parts are M2-Planet specific and come with Mes/Mes-m2, parts are shared between mes and tcc and so on <OriansJ>well if we are careful the only M2-Planet specific parts are // CONSTANT lines; which work on all C compilers without issues <OriansJ>and janneke checkout M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_gc.c <janneke>OriansJ: yes, but being careful can be hard, think #if __arm__ ... <janneke>we have those in ntoab.c, so i chose to keep a m2-planet specific implementation... <janneke>OriansJ: i don't think i can manage keeping your `Starting major change in behavior...Adding arith tests' floating on top of the M2-Planet rewrite :-( *janneke sees what can be done <OriansJ>janneke: I am going to rewrite your read_boot to work with M2-Planet <OriansJ>I however don't think the makefile is ready for the M2-Planet build yet (don't worry I will be adding it later) <janneke>okay...fwiw i re-floated the major change again on top of both our m2-planet work <OriansJ>janneke: you know you can do mes-m2 --boot $file to work around the setting of the environment variables and the read_boot bit right? <janneke>OriansJ: yes; i tried to get mes/module/mes/boot-00.scm to boot that way but it looked like primitive-load was broken <janneke>OriansJ: i think the toplevel boot rewrite makes *a lot* of sense <OriansJ>that is because I broke primitive-load trying to get it to behave like a proper repl (I commented out the read bit in eval_apply()) <janneke>however, before that rewrite i have a chance of running all regular mes and mescc tests from mes-0.20 <OriansJ>simply uncomment /* X = read_input_file_env(); */ <OriansJ>then instead of implicit reading of the bootfile: ./bin/mes-m2 -f test/boot-01.scm -f test/test100/boot.test; sort of thing <OriansJ>but I was trying to eliminate everything but the C source when trying to understand mes-m2's behavior <janneke>OriansJ: hmm, yes, that's where i started, then i resurrected mes_symbols () and mes_builtins () to populate the environment, ... etc -- then i decided to hold this rewrite off for a bit :-) <OriansJ>remember get the primitives right (with guile compatible tests) and I'll get the build working with M2-Planet <janneke>OriansJ: yes, we will go this path, making the mes.c command-line parser compatible with guile instead of this boot-* thing <janneke>i was just hoping to get an intermediate release out <janneke>the fork is about a year old, and it only gets more painful if i wait longer <janneke>until now, mes has seen only minor changes, most work has gone into mescc and mes lib c; so we should be OK <janneke>i see libc-related work coming in mes-m2 now, so i want to prevent creating a headache <OriansJ>how does this sound: we make a branch in mes-m2 called MesCC and it'll be eternally in the state that works with MesCC at all times <OriansJ>we can cherry-pick and pull only the changes that don't break MesCC <OriansJ>then when mes-m2 is fully done, we can do a squashing merge <OriansJ>we will lose some history but it makes the transistion and maintance easier <OriansJ>and mes_hash.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_hash.c <OriansJ>and mes_lib.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_lib.c <OriansJ>and mes_math.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_math.c <OriansJ>and mes_module.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_module.c <OriansJ>now comes the ugly bit; dealing with mes-m2's string writes <OriansJ>and mes_printer.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_printer.c <OriansJ>looks like I need to add support for \a in M2-Planet <OriansJ>trivial to do and this patch is looking trivial <OriansJ>and patches for M2-Planet supporting \a and \b are now up <OriansJ>hmmm how the heck is isspace working in mes-m2? <janneke>OriansJ: looking at my wip-m2 branch in Mes, i don't think i ported isspace yet <OriansJ>no worries in_set solves that easily <janneke>that means mes libc only provides isspace for gcc/mescc <OriansJ>and mes_reader.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f functions/fdputc.c -f functions/file_print.c -f mes_reader.c <OriansJ>that only leaves mes_struct.c, mes_vector.c, mes_strings.c and mes_posix.c <OriansJ>but I'm going to take a break for a bit and when I come back, I'll knock those out <OriansJ>janneke: I think list_to_cstring ends up more problems than good; so I am going to reengineer it's usage to be simpler ***ChanServ sets mode: +o rekado
<OriansJ>and mes_strings.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_strings.c <OriansJ>and mes_struct.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_struct.c <OriansJ>and mes_vector.c is now M2-Planet compatible <OriansJ>M2-Planet --architecture amd64 -f mes.h -f mes_constants.h -f ../M2-Planet/test/common_amd64/functions/exit.c -f ../M2-Planet/test/common_amd64/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f mes_vector.c