<OriansJ>siraben: I'll get to that Pull request as soon as I can ***wowaname is now known as opal
<siraben>pder: Ok. I'd be happy to change the Haskell side of things, so let me know. <OriansJ>pder: well it would be rather trivial to max the max string size a global variable and then provide a user option to extend it as big as we would want. <OriansJ>siraben: it is going to be a bit; dealing with a drive corruption issues <OriansJ>which makes no sense badblocks finds nothing wrong the smart self-test finds nothing wrong and the memtest finds nothing wrong; CPU burn-in test finds nothing wrong. <OriansJ>correction ^max the max string^make the max string^ <OriansJ>The only reason we capped it at 4096bytes was it seemed unlikely for anything human written to have to exceed that size. <OriansJ>it is also the max size for tokens too eg 4K+ long variable names are also invalid. <OriansJ>and honestly I believe tweaking vm.c will eliminate the need for rts.c entirely and the compilation steps as well but that is currently on hold until I can finish the reviews for yt and get mescc-tools-seed done. <pder>OriansJ: I made some progress yesterday on blynn-compiler and finding a few minor issues in vm.c. I can now go from lonely to patty with a command like the following: <pder>./bin/vm -f patty.hs --rts_c lonely_prog.txt <pder>where lonely_prog.txt is a comma separated text file of the prog[] array <pder>However, something is still broken with the M2-Planet build of vm vs gcc <pder>I pushed a branch named lonely that has my work, but it is not ready to merge <pder>Unfortunately, no, but I am interested in learning ***ChanServ sets mode: +o rekado
***stikonas_ is now known as stikonas
<slavanap>Hello, is there manuals for bootstrapping Gentoo? <pder>I found the issue with compiling patty from the raw lonely prog. There appears to be a difference between M2-Planet and gcc when doing signed / unsigned comparisons. <pder>in run() when we compare if num(1) <= num(2), gcc reports true if num(1) is -1 and M2-Planet reports false which changes the behavior and caused the M2-Planet version to hang <pder>siraben: I am wondering if you can help decipher how the parameter for rts_reduce() is calculated. Line 934 of lonely.hs <pder>sorry, M2-Planet thinks -1 < 255 and gcc thinks -1 > 255. This is assuming all variables are unsigned. <xentrac>oh right, the Usual Arithmetic Conversions, the secret nightmare at the heart of C <OriansJ>So we might need to add signed and unsigned comparisions to M2-Planet <OriansJ>shouldn't be too hard to do; we already did a similiar transistion with arithmetic operators <OriansJ>fossy: should have made a bug test and we would have addressed it <pder>Does that mean the cc_x86 and other code would need to be updated as well? <OriansJ>pder: no as M2-Planet avoids depending on sign behavior entirely <OriansJ>Only M2-Planet needs to be updated to fix it <OriansJ>if you'll notice cc_x86 just has general_recursion and not arithmetic recursion and it is why M2-Planet needs to be built before we can build hex2_linker.c <OriansJ>hex2_linker.c actually needs the unsigned behavior and M1 needs the signed behavior <fossy>OriansJ: I didnt think much of it <OriansJ>So I made M2-Planet support both and avoided the cases in M2-Planet where it might impact generated behavior. <fossy>I was just like huh, -1 isnt doing that, lets make it 99999 <fossy>Because I was debugging using m2-planet <fossy>didnt test with gcc, so I didnt notice the discrepancy <OriansJ>fossy: 0xFFFFFFFF > i is more obvious if you ask me but maybe that is just me spending too much time in the hex <pder>Oriansj: its not quite ready to merge, but my lonely branch has the fixes to build patty. <OriansJ>and thank you for taking the lead on those steps <pder>Thanks, I did a lot of dumping data and comparing gcc output to M2-Planet and finally drilled into the cause