IRC channel logs
2020-03-02.log
back to list of logs
<xentrac>so it's failing to recognize it as a comment? <OriansJ>It is treating the contents of the string the same way guile's REPL is <OriansJ>(display ";hi\n") has the same output in mes-m2 as guile does <xentrac>right, I didn't mean parsing "\";hi\\n\"", but rather parsing ";hi\n" <xentrac>which doesn't show in the transcript <xentrac>(read) returns #<eof> because a comment like ";hi\n" doesn't count as an S-expression <OriansJ>xentrac: mes-m2 just drops ;hi\n on the floor and the interpreter doesn't even see it <xentrac>that's good, that's the behavior that test is attempting to verify <xentrac>also it's verifying that the dropping on the floor ends at the end of the line and doesn't continue to the ) <fossy>OriansJ: I am very aware of that <fossy>I am developing gcc seed to use gash right now :p so thats very obbious <OriansJ>(string->list ";hi\n(;hi\n)") matches in mes-m2 and guile <OriansJ>fossy: sorry if I misunderstood you in regards to your goals in kaem <fossy>that is certinaly the end goal <fossy>to make it bootstrap make and bash <OriansJ>I guess I am guite behind on my sleep <fossy>for the time being? I just want to help make a working bootstrap <OriansJ>fossy: as do we all; some more rigorously than others <OriansJ>fossy: no personal technical preferences in regards to solution? <OriansJ>For example janneke and the guix community want scheme to be the "magic" solution to the bootstrapping problem <OriansJ>hence my last 14months of effort; 9 trying to get mes.c buildable via M2-Planet and the last 5 on extending slow_lisp to be good enough <fossy>Yes, I have a preference that the bootstrap is cross platform and that it is easily extensible to any linux distro <OriansJ>fossy: good we agree on that point to a degree (wish it to extend to all possible host operating systems) <fossy>I also feel that everything pre tinycc in the current bootstrap map is good <fossy>I would like tinycc to be removed also eventually <OriansJ>although I still want to improve the steps below mes-m2 to be able to work on even more possible architecture targets <OriansJ>like z80, 6502 and 6809 processors; along with knight in 16bit mode <OriansJ>but I also have a desire to just finish the rope bridge of bootstrapping before reworking the lower level pieces <OriansJ>but at the same time debugging an interpreter sucks and is no fun at all <OriansJ>So progress on mes-m2 just feels like work and I just can't do it after a 14hour day at work. <OriansJ>Work on the lower levels feels like play and I squeeze those bits in <OriansJ>I am honestly grateful for all the help I can get because I just feel the weight of how much work I have to carry up this mountain. <OriansJ>From 2018-06-17 I have been working on mes-m2; I didn't get it buildable via GCC until 2019-07-16; Then I hammered on it until 2019-11-14 to get it buildable via M2-Planet. So I guess I have only been working on the slow_lisp version of mes-m2 since then. God, why does it feel longer than 3.5months of work? <OriansJ>so correction fossy 13 months to get mes.c buildiable via GCC and 4 more months trying to get it buildable via M2-Planet. Then the last 3.5 months extending slow_lisp to be good enough <OriansJ>Good night; need so much rest. Very long day tomorrow <pder>fossy: I tested the latest mescc-tools and found a segfault in kaem when trying to build mescc-tools-seed <pder>I did some debugging and it appears the problem is in collect_token when you set token to the previous token in the list. <pder>The problem is token->next is still set to a valid address so it causes other functions to walk off the end of the list. <pder>This one line patch appears to fix the problem as far as I can tell: <fossy>I noticed that oriansjs patch introduced a number of segfaults <fossy>I am doing some more code cleanup to kaem that should be up by the end of the week <fossy>OriansJ: would you mind applying that patch to mescc tools until I finish the new repo