<OriansJ>xentrac: thank you for the tests, only 2 currently don't pass <OriansJ>now mes-m2 looks just like guile when you do: (let ((a 0)) (while (< a 128) (begin (write (integer->char a)) (set! a (+ a 1)) (display #\newline)))) <OriansJ>only test039 [tailcall.scm] and test047 [or.scm] didn't pass <OriansJ>now the tailcall.scm; I kind of expected (since mes-m2 isn't tail-call yet) but the or.scm feels like a language lawyer sort of question. Should and/or short-circuit evaluate? <OriansJ>because the term circuit isn't even in the r7rs standard; let alone anything which would indicate that or/and should short circuit evaluate <OriansJ>But perhaps I am just missing something obvious again <dddddd>AFAIU 'or' is defined in terms of 'if' (7.3) and 'if' doesn't evaluate the alternate part (4.1.5) if test is false. ***Server sets mode: +cnt
<markjenkinsznc>But I can still do more formatting: whitespace aligning the operands in hex and adjusting the column widths on a per function basis (almost widest common denominator right now) , perhaps even going so far to have a few rare long lines violate column boundaries as is seen in some hex2/.s to tighten things up further <markjenkinsznc>And before PR / merge I can do a rebase squash commit if you'd like <markjenkinsznc>All for now. Next up, integrating my M0 test scripts into stage0 makefile, writing a good featured knight disssembler in python3, doing knighpies 0.4.1 with M0-macro-compact used by test suite for 16/32/64 bit testing ***pgreco_ is now known as pgreco
<OriansJ`>markjenkinsznc: I'll begin reviewing your autogenerated M0-macro-compact.hex2 for after I finish fixing continue in M2-Planet. <OriansJ`>I am considering a rule going forward for generated files in stage0 is must be manually reviewed by n number of developers before acceptance (n being (LOC/250)^(LOC/250) [limit 10bytes per line (so higher penalties for high level languages)]) to apply heavy pressure against generated files <markjenkinsznc>No rush on the review and audit OriansJ. I am interested in learning if you'd like me to white align the operands in hex and tighten the columns on a per function basis, formatting changes I think will make other people's audits easier <dddddd>OriansJ`, did you see my response to the "short-circuit" question? <markjenkinsznc>What I did with sed and awk while auditing is similar to getting my editor to assist with the audit with find replace <OriansJ`>dddddd: yes thank you; I just need to fix mes-m2's behavior in regards to or/and statements <dddddd>my pleasure, OriansJ`. Just checking it didn't get lost. <OriansJ`>markjenkinsznc: well at a rough pass, the formating looks good <OriansJ`>with the seperation between opcodes, registers, immediates and pointers <markjenkinsznc>possible improvement #1, white space align the hex operands , especially after the instruction because instructions different size <markjenkinsznc>possible improvement #2, reduce column widths on functions where they don't need to be as wide <OriansJ`>#2 would make it look more compact but as you can see in my hand written code, that can result in a handful of lines (where there are long label names) which have the comment just a single char after the end of the assembly but not lined up with the rest <markjenkinsznc>it's not an idea I got from elsewhere in stage1/mescc-tools-seed, but I thought it could add to readability <OriansJ`>markjenkinsznc: well a prototype might allow comment from people so say if it is a real improvement <markjenkinsznc>with #2 I can calibrate width per function to not have any lines go too far <markjenkinsznc>I actually think the rare line going too far is actually okay, as having the vast majority in a function line up is good enough <markjenkinsznc>but we can do perfect alignment on a per function basis instead of a per file basis <OriansJ`>(it is a couple lines down you see the extension past the standard padding) <OriansJ`>which allows the rest of the lines to be more compact <markjenkinsznc>but I can do either way, either tighten columns per function as far as possible without lines like 667, or tighten a lot more and have some 667 like <dddddd>Are you talking about some kind of prettifier? For...? <OriansJ`>I'd prefer if it was consistent for all functions while minimizing the global number of lines like 667 to a handful <OriansJ`>dddddd: because things that hard to read need all the help they can get <dddddd>So, to respect the input comments... I guess. First idea in my mind is just respect the indentation of the original (if that makes sense, as in the output is smaller than the input). <OriansJ`>Code shouldn't just be for executing but rather code is first for humans to read/understand and only secondly for computers to run <dddddd>you don't need to tell me that :P <dddddd>But I don't see how that's related to what I said. <dddddd>Another question is the complexity of getting that pretty output from low-level implementations, but maybe you're not planning to port it. <OriansJ`>automated formatting is for enforcing code style; as generally automated formatters are not needed if people can consistently do the right thing <OriansJ`>dddddd: well the cosmetic changes in stage0 are just something that markjenkinsznc wants to work on. I am fine with that contribution <OriansJ`>hence why mescc-tools+M2-Planet are the only level where cross-platform consistent results are expected. <dddddd>Let me try to explain again, with an example... because I think I did't make myself clear enough. My understanding is that the goal is to get, say... <dddddd>00 02 03 03 03 ; here be dragons <dddddd>THE_DRAGON_INSTRUCTION ; here be dragons