IRC channel logs
2024-03-20.log
back to list of logs
<flatwhatson>what tools did you use for the FOSDEM slides? they looked slick! <dthompson>flatwhatson: org-reveal. it exported to html that uses reveal.js <dthompson>has been handy for hoot stuff since we can embed our demos into the talks <flatwhatson>i look forward to a future talk+demo where instead of switching to emacs for the demo, i just have a slide with an embedded hoot repl with pre-loaded libs <flatwhatson>bonus points for moving on with (next-slide) at the repl <dthompson>and we could take it one step further: the slideshow is a hoot program <dthompson>it wouldn't be too hard to implement the most important readline stuff like history <dthompson>I've done that for my WIP game engine's visual repl <flatwhatson>i wonder if it's worth going in the direction of wrapping up something full-featured like CodeMirror <dthompson>flatwhatson: re: codemirror... maybe! should be entirely possible with hoot. <dthompson>my personal preference is to avoid other js libs so I can completely avoid the js tool/npm nightmare <dthompson>but of course for practical reasons pulling in a js lib or two will be fairly common <nanomonkey>Hello kind folks, I'm wondering if anyone can help me figure out an error message that I'm getting with with Hoot? <nanomonkey>Unfortunately I'm compiling on another computer, so I'll transcribe what I can...the error message says "hoot/library-group.scm:396:27 unbound top-level #f iota" <nanomonkey>I believe that it's a problem with bringing in the iota from (srfi srfi-1) <dthompson>the answer is basically the same either way: hoot doesn't provide an 'iota' implementation in the standard environment. <dthompson>and you may be mixing up importing srfi-1 in native guile to importing it in your hoot program <nanomonkey>I compiled git main, but I may have ininvertently switched back to an earlier version of hoot <dthompson>okay, so on main you do have the ability to import modules now (still polishing that up for release) <dthompson>but you cannot just import the modules provided by guile <dthompson>are you compiling programs at the guile repl or via 'guild compile-wasm'? <nanomonkey>I'm using the guile-hoot-ffi-demo as a base, and playing around with adding canvas functionality...I was successful in adding the foreign functions, and writing to the canvas. Now I just wanted to draw out a mandelbrot set to spice things up, which is where I got in trouble with adding modules. <nanomonkey>So I'm using the makefile and manifest provided in that project <dthompson>nanomonkey: so that project doesn't use any module imports since it was written prior to hoot supporting modules. <dthompson>the tl;dr is: you can't use srfi-1. copy over an iota implementation into the program. <nanomonkey>Not a big deal, just wanted to figure out where the problem was coming from. <dthompson>whenever you see "unbound top-level" that means you've got an unbound variable <dthompson>hoot 0.4.0 is coming out next month and we're going to provide an example of using the module system <dthompson>which is currently *different* than guile's module system <dthompson>have fun experimenting with it! pardon the sharp edges ;) <nanomonkey>It's been years since I've used scheme though, mostly been in Clojure land...so I wasn't sure if the problem was with hoot or me doing something in an inappropriate manner. <dthompson>nanomonkey: this is a question we have to ask ourselves a lot while developing hoot ;) <nanomonkey>@cwebber I wanted to make a quick project to test out hoot, something slightly different from the examples you all gave, where I'd have to add new foreign functions...so I decided to write something using canvas. The only things I could think of were a maze game or a mandelbrot viewer. Not wanting to write a whole game engine, just yet, I went with the later. <cwebber>nanomonkey: please show us the mandelbrot viewer as soon as you have something!!!! <nanomonkey>I'll post a link to the code (tonight?) when I get a chance to fix the last little bit. <nanomonkey>I already got the canvas foreign functions to work... <nanomonkey>Hoot and goblins has been a wildly enjoyable distraction the last week...I originally overlooked it because I have some ptsd around Object Oriented programming. But I've been delving into Capabilities, and I have to say it fulfills a lot of my nagging searches for more fine grain control over system security (for lack of a better term). I work part time at a super cluster running Physics simmulations on gpu's, <nanomonkey>annoyed that there aren't good ways of keeping clusters from clobbering each other's resources once they have access to them. I also worked with Secure Scuttlebutt to do decentralized social networking and tooling, and felt like cryptographic security and append only logs got close, but still needed some refinement. Looking forward to some new ideas! <makx>I have to admit that I did not understand what cwebber was up to with these goblin shenanigans when I learned about them in 2018; but now that I learned about actors and the vat model of computation somewhat properly I had a few lightbulb moments. <makx>and jeez, the hoot stuff is nice, too <nanomonkey>Are there documents on how resources are restricted in a distributed manner for Goblins or OCap in general (if there is a general methodology). I can only imagine of accomplishing this through encryption, and only for read access, unless you rely on "trusted computing". Is this just done through the runtime environment, or is encryption still relied upon? If so, are there any means of revoking access? <Zarutian_iPad>in cryptography one is kostly considering confidentiality, authenticity, and integrity