IRC channel logs
2024-05-30.log
back to list of logs
<old>theruran: I read a post from cwebber, but I'm interested in more details and theory of this model <cwebber>I long have wanted to make a propagators visual programming language and here somebody did it! <old>cwebber: AH. I remember reading about this in Software Design For Flexibility <old>Merging of cell states nad propagatins stuffs <old>with this in repl: (define wat (wasm->wat (compile (call-with-input-file "test.scm" read)))) <old>However, I get: test.scm:4:2: definition in expression context, where definitions are not allowed, in form (define foo 42) <old>What am I getting wrong here? <dthompson>old: the problem there is you're trying to compile a module, not a program <old>So it is not possible to do modular program or libraries yet? <old>I don't fully understand. There is examples/project-template/hello/{document,element}.scm that seems to be module <dthompson>old: modules are imported into a larger program and it is the whole program that is compiled <old>ah okay. So I just need to compile the entrypoint then <dthompson>yes, a program that imports that module and does something with one of its exports <old>So in the template example, the program hello use two user defined module and just add a text node <old>no need for a main procedure as an entry point <old>the script itself is the entry point if I understand <old>Is it possible to have the name of procedures in the resulting .wat? I've tried #:emit-names #t while compiling without much success <old>maybe my functions were inline <old>yes. It would help me understand better what is the instructions generated for a given lambda <dthompson>#:emit-names will generate a name section that chrome is good at using when showing disassembled wasm <old>I'm still on the exploration path here <dthompson>however the compiler is generating many names <dthompson>so you'll see good names for things in our stdlib which is handwritten wat, but all the compiler generated wasm functions have names like f1234 <dthompson>the hoot wasm->wat disassembler doesn't currently incorporate the original names via the name section (when present) but I have a branch that is attempting to do this <old>it is possible to compile to .wat directly then and keep the name? <old>or that's just not how it works <dthompson>if you hand-write wat and assemble it via wat->wasm and emit names then you'll have the names <dthompson>but if you're talking from scheme then no because many things have names generated by the compiler and they do not currently reflect the names in the original scheme source <old>okay. but that defies my purpose of understanding the instructions used for a given lambda :/ <old>like all these $wtf. Is that just accidental? <old>ahh I see that with the ->wtf8 <dthompson>I've done my fair share of debugging these binaries, and currently the best way to match up a wasm function to scheme source code is to run 'guild compile-wasm' with the --dump-cps flag. the dumped cps info has source locations and you can use that to find the relevant wasm function based on the cps continuation id. <old>that would be nice indeed <old>compilation seems to work nice fine. But if I try to import something I get: unbound top-level #("test.scm" 0 0) import <dthompson>the 'import' form must be the first expression <old>I'm not sure if maybe my guile is misconfigured here <dthompson>if you're using 'compile' at the repl then the modules to be imported are passed as a separate keyword arg, not as part of the program <old>((@ (hoot compile) compile) (call-with-input-file "test.scm" read)) <old>with #:include-file ? <old>ah no #:imports okay <old>that's kind of limiting no? Having to conses the imports manually <old>anyway, good work I like it :-)