IRC channel logs
2025-01-05.log
back to list of logs
<dckc>sigh. back to: libstdc++.so.6: version `GLIBCXX_3.4.30' not found <dckc>the libc used by the FHS stuff is old :-/ <dckc>I suppose if I had reported that bug thru channels in Aug, it might have been fixed by now :) <drewjose>how would yall feel about an independent port of goblins to common lisp 😳 <dckc>re Oaken / mobile code: does guile provide complete encapsulation? <dckc>it seems to provide the sort of low-level unsafe facilities that work against that <dckc>I suppose confined code can be prevented from touching those tools? <dckc>a wish: a justin interpreter / evaluator (IOU pointer to justin, a subset of Jessie, a subset of JavaScript) <dthompson>unlike regular guile code, oaken code won't have any access to things like the POSIX interface without granting such access. <stdh>hoi spritely folks! i'm finally experimenting with goblins. i have a question about objects and persistence: what would be a clean way to implement objects with a reference to objects of the same type? <stdh>(i'm building a rubik's cube, and want the sides to have a reference to their neighbours) <stdh>perhaps i can use something like the proxy and swapper from swappable, but it's all rather new to me. <stdh>if not for persistence, i could solve it in a 'letrec' and wrapping the references in a lambda, but that only got me so far. <dthompson>hey stdh, you need a way to "tie the knot" since there's recursion in the references. one way would be to spawn all the sides and then send them a mesage informing who their neighbors are <dthompson>another option is to have the sides query some other actor that will return the current neighboring sides. <dthompson>in cirkoban, a grid-based game we made last year, I kept things simple and passed along a reference to the relevant info about the grid when making calls to the actors occuping a space on the grid. <dthompson>and there was also a way to query for the actors occupying a tile.