<oriansj>guess I have to change how mes-m2 handles strings to get (string-index "\a\b\v\t\"'" #\") to match guile <oriansj>looks like the perfect time to include in_set into mes-m2 <Hagfish>those seem like reasonable sub-goals, yes <oriansj>fuck, did that actually just solve my EOF problem? <Hagfish>more and more projects are being built in the grey zone between "simple enough to be trustworthy" and "powerful enough to be useful" <oriansj>powerful enough to be useful is a personal feeling about a tool and simple enough to be trustworthy has alot of personal variances (see reading APL code) <oriansj>The most exciting part is ../mes-m2/bin/mes-m2 -e main -s M1.scm -f foo WORKS <oriansj>and I added proper leading whitespace handling for #; (janneke: I know, I know but I did it eventually) <oriansj>so now #; (....) does the *right* thing <oriansj>also Hagfish I just don't know how simple a node.js program is <oriansj>perhaps we are just starting to enter the start of the golden age of computer trust; where librehardware is becoming more and more available <fossy>still cant build a working TCC with MesCC <oriansj>a good sanity check is to compile tcc with gcc in a single command <oriansj>for some reason most software tends to be quite fiddly. <oriansj>which reminds me; I'm gonna need to schedule some time to fuzz mescc-tools and M2-Planet so that they are more fault tolerant <oriansj>Hagfish: for example of the powerful enough gradient: Give me a hex-monitor and I can bootstrap the world. Give the average java programmer an unconfigured eclipse studio and an empty project and they wouldn't be able to make fizz-buzz <Hagfish>that's an extremely hot take, but i can't dispute that :) <Hagfish>maybe technologies exist in a space with dimensions of power and usability <Hagfish>a tool which can empower some people could be a huge limitation to another person <Hagfish>i'd rather do sums in my head than with an abacus <Hagfish>i don't know if that's a good example <oriansj>Hagfish: or perhaps there is a level of compatibility between people and tools <oriansj>much like how one needs a certain amount of strength to use a sledge hammer <oriansj>or the realization that some minds are better suited for certain familities of languages than other people <oriansj>I know I am a far better C programmer now; than I ever was a scheme programmer <oriansj>It might have been the last 3 years of writing hex, assembly and dealing with representations <Hagfish>the whole field of human-machine interface design probably has a lot of advancements yet to be made <Hagfish>i guess it is starting to be more empirical now that software can measure how users interact with it (and that probably helps with the design of other things) <Hagfish>but i think a lot of products get redesigns that feel worse for at least a vocal minority of users <oriansj>or perhaps the reason there are so many programming languages is because the differences in how humans think about ordering problems <Hagfish>now you're framing it correctly, thank you <Hagfish>rather than trying to invent the "perfect" programming language for some idealised human brain, maybe what the world needs is some researchers to try to understand the variety of human brains based on preferences that are already apparent in the world <oriansj>and create clusters of programming languages suited to those brains? <oriansj>Hagfish: doesn't work too well with current economics <Hagfish>a lot of scientific research doesn't pay off in the short term, yeah <oriansj>essentially the ability to mix programming languages on solving a problem however does enable a business justification for supporting multiple languages <oriansj>kinda like how one could mix C + FORTRAN + COBOL + JAVA + Python into the exact same code base <Hagfish>everything will compile to webASM :) <oriansj>except assembly and who really needs that ;-p <oriansj>especially since webASM can't even consistently tell if two things are equal <Hagfish>so you're saying it supports quantum computing natively? ;) <oriansj>in scheme terms (= #t unspecified) => #f but (= unspecified #t) => #t <oriansj>just changing the order of the arguments in comparision changes if the mixing of 2 different types results in equality <oriansj>or more precisely a chrome only version of *Javascript (tm google)* <Hagfish>i think Mozilla is doing quite well at driving webASM in the right direction <oriansj>webASM incompatibilities between browsers is still a major thing <oriansj>especially in regards to performance and halting <Hagfish>at least there are competing implementations <oriansj>without a formal document saying these primitives *MUST* be implemented and developers limiting themseles to only those <oriansj>So instead of generic x86 binarires that run everywhere; we get --arch=native but now it breaks moving from a 2GHz i7 to a 3GHz i7 <oriansj>because you know, it isn't exactly the same.... <Hagfish>i haven't looked into implementation details, but i haven't heard it being that bad <oriansj>node.js is full of such bullshit stories <Hagfish>ah, node.js, i could probably believe that <oriansj>hell, they managed to fuck up appending a char to a string or returning #t or #f if a number was even <oriansj>they actually wrote it like this: is_odd.js:: return !is_even(a); is_even.js:: return !is_odd(a); <oriansj>like what the mickey mouse gangbang wacked out on coke bullshit is that? <oriansj>I swear, half the code is written by markov chain generators <oriansj>with a QA process of: fuckit, they already paid me, ship the shit already so that we can bill them to "fix it" <Hagfish>at least a markov chain generator could be said to have some sort of logic driving it <oriansj>Hagfish: like seriously, you need 18GB of shit to build freaking hello_world.js??? <oriansj>I just can't even with those javascript people. <oriansj>No thinking about systems engineering <oriansj>No planning for system administration of the program <Hagfish>yeah, the ecosystem does seem to be a dumpster fire, and the best practice seems to be "try only using the garbage that isn't on fire" <Hagfish>or transitively connected to fire, yeah <oriansj>there is nothing not on fire in that shitbox <oriansj>There is no dollar amount large enough to make me care about bootstrapping that shitscape <Hagfish>the half-life of an average javascript project is probably less than 2 years, so there might not be much that needs saving <oriansj>The JavaScript compilers have circular dependencies so deep, mathematics professors could use them as examples of 90+ dimensional Cline bottles <fossy>oriansj: I would be happy to do some fuzzing on m2 planet and mescc tools <oriansj>fossy: how goes the kaem enhancements? <fossy>I decided to do it the proper way <fossy>and so im trying to implement chdir() in M2-Planet functions <fossy>basically its not working and I cant tell why <oriansj>fossy: well you would just assume the C function and let me figure out how to implement it <oriansj>as it is just a syscall if I rmemeber correctly <fossy>oriansj: my concern with my improvements is inflating the size of kaem-optional-seed <oriansj>fossy: I'm going to replace kaem-optional-seed with one hand written in assembly and then hex0; so don't worry about that <fossy>oriansj: how then would the bootstrap be initiated? <fossy>other than making hex0-seed JIT compile hex0 <oriansj>but it would be helpful if you write a test for M2-Planet for the chdir primtive for when I am implementing it <oriansj>fossy: 2 binary seeds: kaem (written in hex0) and hex0 <oriansj>we will solve those bootstraps via hardware level work <oriansj>perfect isn't possible now but we are a hell of alot closer than where we were 3 years ago <oriansj>I figure I can get kaem down to 1KB for the seed if I strip out everything possible; then after kaem is built via M2-Planet, simply switch to that kaem to do the rest <oriansj>say make it just plain ./kaem with no support for options and it only runs kaem.run in the current directory <oriansj>that way fossy you can make the full kaem into a dream <oriansj>Lots of useful features, perhaps even powerful enough to be used to build make <oriansj>and as long as you preserve the buildable via M2-Planet, it will not cause any problems down the road when we solve the posix bootstrap problem <oriansj>even a minimal kaem will solve the shell problem of the bootstrap; as one can make a linux image with that kaem as the init and on power on, it can bootstrap everything and switch out the init to a proper one and reboot when done <oriansj>I probably should write up these details in the talk notes; so that those sort of questions in the future have a ready answer. <fossy>oriansj: however we will have to refractor the AMD64/x86 kaem.run to be able to run from / to allow it to be run by minimal kaem <oriansj>which I believe is what they currently leverage <fossy>but we need to make sure kaem.run can be in / to be able to run it from a simple POSIX kernel, do we not? <fossy>otherwise it has to cd first <oriansj>fossy: well that is a trivial check, as root on a system pushd / ; git clone messc-tools-seed ; build and see if we run into any issues <oriansj>but yes you are absolutely correct in that it does need to be tested fossy <oriansj>as we must always test before shipping promises to others <fossy>so in the end there will only be four seeds (excluding microcode) on x86/amd64? Bootloader kernel kaem hex0? <fossy>for the user that doesn't or cannot use special hardware? <oriansj>and we will have to provide a way to make those 4 seeds on standard hardware as well as on special hardware <oriansj>and the bootloader, definitely will be written in assembly (possibly hex0) to fit in the MBR (less than 512bytes) <oriansj>and the Kernel will probably be written in M2-Planet (possibly ported to assembly if someone wants to shrink the size down by a factor of 4-6) <fossy>What will the kernel be written in <oriansj>M2-Planet can run on bare metal (such as the special hardware) <fossy>now can we keep this under.. hm.. 100KB? <oriansj>fossy: depends on how much functionality we feel needs to be shoved into that posix <fossy>I honestly feel like we should only include enough functionality to make it run the kaem seed <oriansj>filesystem support, single thread only, subset of syscalls sort of deal <fossy>and boot on a wide range of machines <fossy>but only certain filesystems (maybe only one?) <oriansj>which will require drivers, which really adds to size <fossy>Knight wont have any of these problems though yay <oriansj>well, one could implement a variation of the stage0 steps in x86 but one will still depend upon bios calls <oriansj>well one could work around the bios entirely and directly interface with the hardware via internal drivers but that is alot bigger <oriansj>perhaps a gold star project for someone who comes late to the project and wants to do the "impossible" <oriansj>I mean, I literally laid out 90% of the core functionality required; one needs only figure out 5 syscall replacements to go from hex0 to cc_* <oriansj>after that, if we kept our minimal posix simple enough; it could be built via cc_* and then they can just leverage the rest of the steps <oriansj>read-from keyboard, write to screen, read from disk, write to disk and halt <oriansj>and floppy disks would be easier than USB flashdrives <oriansj>so keep everything under 1.44MB and we should be good <oriansj>as mescc-tools-seed for AMD64 generates 432KB of binaries, so 1MB for the kernel and various tools required for bootstrapping <oriansj>(with mes-m2: 169,147bytes (currently and growing) M2-Planet: 142,607bytes (currently and growing) M1: 36,044bytes (until we add support for RISC-V) hex2: 33,721bytes (until we add support for RISC-V) blood-elf: 11,590bytes (probably forever) get_machine: 6,630bytes (probably forever) and kaem: 20,785bytes (currently and growing) <oriansj>or if we limit ourselves to cc_amd64: 16,079bytes (probably forever), minimal hex2: 1,487bytes and M0:1,860bytes <oriansj>for a grand total of 19,426bytes and say 1-2KB for a minimal kaem <fossy>oriansj: im still confused how one would run kaem-optional-seed as init from a initramfs <fossy>as youd still need to chdir from /? <oriansj>fossy: the kernel is the program that starts init <oriansj>so on power-on the kernel loads the init program and executes it <oriansj>or pass a kernel flag on boot to use /AMD64/kaem <fossy>giving kaem a workout with fuzzing <fossy>got a few improvements to make it buildable with gcc <fossy>also two functions can be replaced with functions/string.c <fossy>dosent want to not segfault >:( ***ng0_ is now known as ng0
<dddddd>fossy, what do you have so far for chdir()? <oriansj>fossy: well kaem, mescc-tools and M2-Planet have always been buildable via gcc <oriansj>fossy: yeah janneke went through alot of pain just getting tcc himself. (it is a poorly written program; hence why we want MesCC to grow to be able to build GCC directly) ***janneke_ is now known as janneke
<oriansj>dddddd: I'll probably knock chdir in M2-Planet out today <oriansj>and access too probably in the same test <dddddd>yeah, I was looking at the syscall and it's simple enough. Just wanted to help fossy to understand their issue. <oriansj>of course, we always help each other here <oriansj>well I'm just gonna write chdir, fchdir and access off the cuff without testing (I'll let fossy make M2-Planet tests for them) <oriansj>I'll do the knight versions, after I implement those primtives in knight-vm <dddddd>I guess access can help/complement test22. <oriansj>or an arbitrary new test could be created that uses both <oriansj>ok, got those primitives into stage0's vm ***ng0_ is now known as n0
<oriansj>and first draft for knight-posix support is done (as chdir, fchdir and access are all meaningless in knight-native [bare-metal mode]) <oriansj>so fossy they are ready for you to test (and create a M2-Planet test for them); so that you'll be able to leverage them in kaem ***n0 is now known as ng0_
***ng0_ is now known as ng0
<oriansj>I think that is enough changes for a stage0 release <oriansj>ok a brand new stage0 release is now up <oriansj>speaking of which, dddddd when you are ready and AArch64 is merged in we can do a release of M2-Planet to along with it <dddddd>I'm using this weekend to improve the documentation you saw: reading logs about the endianess and ARM documentation. Then I think it's just a matter of split the patch a bit, in logical commits because even if it's not a huge patch it's not that small. Hopefuly end of the month (but no promises yet). <oriansj>also fossy when you get kaem to a happy place and update docs/kaem.1 accordingly, we can do a mescc-tools release as well <oriansj>now we just need to find an entry level scheme programmer; who is willing to complete a half finished program, to complete janneke's scheme only bootstrap of Guix <oriansj>just need to implement eval-immediates, preserve-other and print-hex. <dddddd>So many funny things I'd like to help with; so little time. I wish I could "work" full-time on these... <oriansj>so you might qualify dddddd for some funds <oriansj>which might help you afford to have more time for the work <oriansj>and a port to AArch64 for M2-Planet certain would be the sorts of deliverables they would want <oriansj>janneke: might even be able to help you with what you need to know dddddd <oriansj>My employer would be willing to sponsor me to dedicate 40hours per week (for 2 months) to mes-m2 if we found another party willing do a matching sponsorship with another developer. (I might be able to get them to stretch to 3 months if we could get a second party as well) <dddddd>NLnet sounds familiar (I think is was mentioned along the "horizon program" for another project I follow from the sideline). *dddddd looking the website <dddddd>I'm not good at burocracy, but the process there seems quite streamlined. The next deadline is in just a few days. <oriansj>dddddd: I just suck at bureaucracy but I work at the State of Michigan and discovered the power of nicely asking people for things. <dddddd>hehe, so bad at it that can't even spell it correctly xD <oriansj>dddddd: believe me, it took 4 years to migrate one department from IBM's ClearCase to git for a net $700K/year savings. God that was draining <oriansj>but yesterday I got my 5year award; having net saved the State of Michigan $60 Million (plus or minus $2M) <oriansj>Well actually that was considered a black mark against me; and why I am still a P11 after 5 years when I should have been promoted to a P12 after 3years <oriansj>or kinda like how I nearly got fired for formally proving that Windows 10 doesn't comply with HIPPA and thus the State was breaking Federal Law <oriansj>or when Oracle nearly sued us because we found and reported sooo many security vulnerabilities to them that they have a 10+year backlog of RCE/PE CVEs to deal with <oriansj>(We ended up having to pay them because of the trouble we caused by finding security issues in their product....) <oriansj>God, working in government is fucking weird <oriansj>hence why I really want to find a sponsor to support an alternate dev to work on mes-m2; so I could get 2 months paid away from that insanity <oriansj>hence, since I don't need the money and money is available; why not get that money to someone else who could use it to do more good <oriansj>heck, I'd even pay $50 for someone to go through the effort of getting another mes-m2 developer sponsored <oriansj>dddddd: heck, I'll even give that money to a developer who got themselves sponsored <oriansj>(requirements must be atleast 2months of 40hr/week paid) <dddddd>I can self-sponsor me for that time if that helps :P <dddddd>Taking a sabbathical (or just quit and see what happens next) and happily burn some savings. <oriansj>dddddd: I doubt the State of Michigan will consider that a matching sponsorship <dddddd>Anyway, it's not about money on my side; not for a couple of months. <oriansj>well, no rushing needed; let us focus on long term sustainability of the work <dongcarl>oriansj: Ah! Pretty good, I've got everything building for Linux, Windows, and OSX... Just waiting for some review from another build systems person :-) <dongcarl>guix time-machine really simplified things, so I'm glad that happened <dongcarl>Sure, I'm just not sure my talk lends itself to being in a repo that way... <dongcarl>It was made using non-free software... And most of the slides are quite meaningless without my narration <oriansj>dongcarl: it is more historical reference anyway <dongcarl>Haha one of these days I might transcribe the talk into a script <dongcarl>Yeah lemme think about what's the best format *dongcarl adding to todo list <fossy>oriansj: danke, thanks a lot <dddddd>Enough documenting the implementation for now. I uploaded an update as usual, oriansj. No hurry for the review, more is to come tomorrow. *dddddd takes a look at M1.scm <oriansj>fossy: I appreciate your help in making kaem better ^_^ <stikonas>at the moment mescc-tools-seed fails to build M2-Planet (./blood-elf-0 --64 -f hex2_linker.M1 -o hex2_linker-footer.M1): Subprocess error 139