IRC channel logs

<EWEW>really excited to see all the news coming out :)

<EWEW>I just might also have something in the works that might get some people excited about all the spritely work as well :)

<EWEW>that's just a rumor though

<flatwhatson>guile spritelymacs?

<EWEW>well let's just say. before i knew about spritely specifically. I was already working on a book on wasm and put together a nice little environment for myself for WAT

<EWEW>but after spritely, i got stuck down in guile source code land

<EWEW>and 100 tabs of papers

<EWEW>my little goal right now, i want to be able to read guile vm bytecode fluently, directly.

<flatwhatson>tree-il? or from hex, neo style? :)

<EWEW>hex

<flatwhatson>probably can't read *directly* until neuralink comes out :P

<flatwhatson>but this is a noble goal i guess, being able to diagnose at bytecode level can be handy sometimes

<EWEW>well you can start inventing adhoc mnemonics for repeated sequences. sort of reinventing the wheel of course.

<EWEW>but the basic idea is tooling to make reading hex directly not be an insurmountable task

<EWEW>while allowing it to be productive to make edits

<flatwhatson>tooling can help a lot though, think traditional annotated asm readouts

<EWEW>now you're getting to what i'm working on :)

<EWEW>also much better simulation tooling for feedback

<flatwhatson>i think wireshark is a good example of how this kind of tooling can work

<EWEW>and then people will look at my goblins based project(s) and be like wtf is all this inlined hex hahahaha

<flatwhatson>i wonder whether the current guile bytecode format will remain with the move to WAT

<EWEW>so my understanding, without being on the team obviously, but just from what i saw of the doc that wingo wrote and cwebber posted here a while back

<EWEW>i think at minimum it will be similar. the design of how guile would be implemented is sharing a lot of the same ideas

<flatwhatson>oh, i missed that! do you still have the link?

<EWEW>let me see if i can dig it up, one moment

<flatwhatson>with working on binary formats, i stumbled upon GNU poke recently: http://www.jemarch.net/poke

<EWEW>flatwhatson: https://gitlab.com/spritely/guile-hoot-updates/-/blob/main/design/ABI.md

<flatwhatson>thanks!

<EWEW>like right now guile is JIT with various backends for different architectures. only certain sections are actually ever compiled to "native"

<EWEW>the JITed sections are what would correspond to what's being described here afaik

<EWEW>except

<EWEW>it's everything lol

<EWEW>but if you dig into the current code for the guile vm

<EWEW>it's very similar to what's here

<flatwhatson>right, i guess it's a matter of both porting the vm to wasm and writing the bytecode->wasm jit

<flatwhatson>reading through the ABI.md and log.md, it's not clear that guile's bytecode format will remain as an intermediate representation

<flatwhatson>> So next up is creating a compiler to go from minimal Scheme snippets to wasm, through tailified CPS.

<flatwhatson>in the guile repo, we have CPS -> guile bytecode: https://git.savannah.gnu.org/cgit/guile.git/tree/module/language/cps/compile-bytecode.scm

<EWEW> https://wingolog.org/archives/2014/01/12/a-continuation-passing-style-intermediate-language-for-guile

<EWEW>yep

<flatwhatson>so hoot might emit wasm directly here instead of using the existing bytecode rep

<drakonis>ELS will be good and fun this year

<drakonis>its got a sussman keynote

IRC channel logs

2023-03-10.log