IRC channel logs
2023-12-12.log
back to list of logs
<cwebber>Kind of related is getting debugging support so an exception in the browser can show corresponding source lines <cwebber>I think your suggestion is a bit different. It's interesting, I think it's something to consider when bundling up all the things necessary to distribute a Hoot program <cwebber>Which simplifying the tooling around that is on the agenda but this is an interesting direction. Funny enough the thing that might be best at making this possible is, dare I say it, autotools <cwebber>I suppose I should move those comments to the issue but I am out and about! <isaneran>ACTION is now finally writing the code for the steps outlined in the incremental compiler paper <dthompson>isaneran: "an incremental approach to compiler construction"? love that paper. I've gone through about half of it. <isaneran>I figured I will learn more by not relying too much on the full tutorial <isaneran>full tutorial does not actually seem to be fully finished either way <dthompson>even just going through the first few iterations is very worth the time <isaneran>If I don't get anything else from the paper, it is good that it reminded me that it is smart to piggy back on C for printing program results to center my focus on what I am actually trying to learn <isaneran>s/C/things I already know that I can outsource the functionality to/ <isaneran>my other attempts at making a compiler have been a bit inhibited by not doing stuff like that, because I feel like oh now I have to write the code to print the number from assembly with linux system call and stuff like that if I don't have libc <isaneran>but I am also getting other things from the paper of course <isaneran>like starting out with making the test suite and making sure I have something that can compile the input and run the output at each incremental addition to the input language <isaneran>dthompson: I am aiming to get to the end of it but we'll see about that I guess, might branch off and try to make a real compiler half-way through :p <dthompson>I tried to use only basic scheme for the implementation, but by step 13 the code desperately needs rewriting to use pattern matching and stuff <isaneran>dthompson: well, your commit history is certainly cleaner than mine :P <isaneran>I see you couldn't resist making it 64 bit though haha <isaneran>oh, do you run into crap by just emitting it as is? <isaneran>I thought %eax etc worked as is just that they only refer to one half of the %rax <isaneran>(which is what I was outputting for my other attempt at scheme compiler) <isaneran>but yeah re pattern matching, I also feel some push to just write it with standard r5rs or r7rs but it is just so much nicer to work with pattern matching <cwebber>I have read it front to back several times <cwebber>But I never implemented it admittedly <isaneran>was wrecking myself over and over by being over-ambitious with how much I wanna get done in a sitting and since I was kind of sporadic with when I sat down to hack I ended up losing a lot of brain context which increased friction to get back to hacking and created some kind of vicious cycle, where I started losing confidence in my ability to learn this <isaneran>but this paper gives a very managable roadmap and helps break things down into good chunks <isaneran>(I'm very bad at breaking things down into chunks like this, which is a shame, cuz my brain probably needs it to stand a chance at not becoming overwhelmed) <dthompson>isaneran: my memory is fuzzy but I was emitting x86_64 asm. I don't know the ins and outs of all this register stuff. I remember having issues that were fixed by switching to the 64 bit registers. I don't think I immediately had issues with %eax, it was something else. <dthompson>I started with simple scheme because I was trying to make my commit history tell the story of incrementally building this compiler <dthompson>and, judging from your comments, seems to work kinda well <dthompson>if I go back to this, I will first do a big clean-up where everything gets converted to use pattern matching <isaneran>yeah I'll try to make my commit history follow a similar shape <isaneran>although I might have more commits between step commits :P <isaneran>dthompson: the other compiler you started working on, is it hoot or do you have yet another top secret compiler project? <dthompson>it's not top secret but it's very not working <dthompson>secret codename Seagull: a Scheme-like shader language that compiles to whatever GPU backend you need (initially GLSL) <isaneran>we really just have the same project ideas all across the board <dthompson>varjo kind of organically grew into what it is... the code is hard to follow. <dthompson>there are some tricky details that are hard to solve without getting "more serious" about the compiler design <dthompson>namely... moving from a tree-based expression tree to continuation passing style <isaneran>what would cps help with for a shader language? <dthompson>simplify the data structure used for compiler passes <dthompson>I was struggling with correctly determining the type signatures for all user defined functions <dthompson>because the tree structure doesn't tell you who calls what, the cps graph does <dthompson>I don't know if I can clearly summarize the problem, but it was staring me in the face once I was in the weeds <isaneran>right, I think I can kind of picture it vaguely though <dthompson>this is too simplistic, but when it comes time to emit code for (lambda (x y) (+ x y)), the emitted code depends on what type of arguments the function is called with in the program. if some callers pass 2 ints, and others pass 2 floats, then 2 separate functions with different signatures are emitted. <dthompson>shader languages being statically typed and all <dthompson>still a complete noob but learned a lot in this past year <isaneran>well, good to know someone who is not so far ahead of me that they don't know the struggles but also far enough ahead that maybe I can get some advice on avoiding some bumps :P <isaneran>but I've also noticed a huge crater between how much I can learn after a boring day's work compared to when I have lots of free time <isaneran>like during summer 2020 (covid time) I spent like an evening or two writing a compiler and vm for a low level lisp and made much more progress than I do on the average evening I decide to try to push myself to do a little compiler hacking <dthompson>yeah it's hard. I struggle with the same thing. <jfred>I'm the same way. When I dive into something over the holidays or on a long weekend I'm way more productive than if I try to work up the motivation after a long day of work <jfred>my progress on side projects happens in fits and starts, when I can actually get into a flow state 😅 <dthompson>no progress for months... then suddenly a big step forward <jfred>I wish I had a way of getting into that more productive state more often haha <jfred>that would probably help but has other downsides 😆 <isaneran>ACTION wishes he could build a house out of parentheses <isaneran>cwebber: you said your house is haunted the other day, is it haunted by the spirit that lives in the machine? <jfred>sneek: later tell isaneran you can build a digital house out of parentheses ;) <jfred>(but - a scheme interpreter in z-code!) <cwebber>jfred: oh yeah! that one's pretty cool :) <cwebber>also dpk last night I read your letter to the r7rs list about becoming chair and I thought it was very thoughtful. <cwebber>particularly, I was unfamiliar with the plans for the different parts <cwebber>"environments" in particular is interesting <cwebber>re: environments, I think Guile has gone to great lengths to implement most of POSIX's APIs, and also recently WASI has been more or less approaching them afresh <cwebber>I suspect those would be two interesting places to start looking <cwebber>(there's a lot to think about in terms of ocap safety with that too since POSIX... isn't safe. but WASI is providing a containerizing + ocap approach to safety at least.) <dthompson>dpk: seems neat! the 'route' form reminds me of rails. the use of format strings is a little un-schemey to me but that's okay. the make-like structure and incremental build is cool. that's something I've been meaning to add to haunt but there hasn't been any external pressure to do it so I haven't. <cwebber>dpk: on that note we've said a few times on internal calls "we should probably have a call with dpk at some point" :) <dpk>cwebber: thanks! the shape of the Environments is still quite unclear. we’re not sure how much we want to mirror the POSIX APIs vs designing a high-level API which isn’t quite so closely tied to an operating system i (and a lot of other Schemers) find only barely tolerable <dthompson>personally I think sxml is a pretty nice format. has served me and others well for many years. <dpk>even if the practical reality is that POSIX is everywhere and can be emulated pretty well even in places where it isn’t, i do have the sense we’re on a verge of a revival of interest in OS development going in different directions <dpk>dthompson: i’m not sure about incremental builds. one of the things i want to use this for is a website with my photography portfolio, which is why i mention that might be useful for sites doing a lot of imagemagick-type stuff in their build <dpk>i imagine my ‘source’ repo containing maximum-size TIFFs or otherwise lossless files, and then generating appropriately-sized JPEGs/JXLs/AVIFs/whatever to actually serve on the web as part of the build <dpk>but probably i’m overthinking that too <dthompson>yeah you'd want to skip the build step if the hash of the file hasn't changed <dpk>cwebber: i’d be open to that <dthompson>I want to be careful not to greenspun's 10th rule but for guix (or make) when I get around to caching artifacts. <dthompson>I also want to incorporate hashes into the urls of images/etc. as an optional cache invalidation strategy. <cwebber>dpk: maybe look at WASI without too much focus on POSIX, consider it a step removed <cwebber>it's promising that WASI says "capability oriented" *explicitly* <dpk>Codeberg is down, post ponies <jfred>cwebber: Yeah that bit is exciting re: WASI :) <dpk>cwebber: heh, the stuff about providing openat instead of open is interesting … unfortunately we already have procedures in Scheme which depend on an implicit current directory (which R7RS small provides no way to detect or change, sigh) <dpk>where we abuse openat and friends to pretend like that current directory is part of the dynamic environment <dpk>but the problem is it makes basically all C FFI non-parallelizable, which is a bit of a non-starter <dpk>if someone could work out a way to provide all the R6RS and R7RS small file system procedures and still have a capability-based system, we could maybe consider moving in that direction