IRC channel logs

<jfred>vv[m]1: If you're talking about what I think you are, it's just a way to spawn an actor with a reference to itself. Useful for things like loops, since you can send yourself a message that will trigger the next loop iteration

<jfred>Objects in e.g. Python always have a reference to themselves, but in Goblins they don't so you have to be explicit about it when you want that behavior

<flatwhatson>the self-reference is explicit in python too! it's just design so that the calling syntax always passes it in

<flatwhatson>i haven't looked closely, but it seems like T added this kind of syntax to scheme

<vv[m]1>I chatted with cwebber earlier and she pointed me to the (incredibly awesomely tested https://gitlab.com/spritely/goblins/-/blob/master/goblins/actor-lib/selfish-spawn.rkt) -- only in the racket impl for now but a simple enough pattern.

<ieugen[m]>hi, I just saw the announcement about guile and wasm and I am interested in keeping in touch / helping out if I can.

<ieugen[m]>I am not interested in the job opening since I lack the skills but would like to see the project succeed and offering to help out however I can

<ieugen[m]>I think I can help mostly with testing, maybe some documentation and some noise about the progress

<sneek>Welcome back Zarutian_iPad :)

<drakonis>who watched fosdem this year?

<dthompson>I watched whatever I could catch on Saturday

<ieugen[m]>I am watching what videos I can right now (not all published)

<dthompson>mainly watched the declarative and minimalistic language room since that's where all the guile/guix stuff was.

<dthompson>I'm eagerly awaiting the prescheme video to be uploaded.

<ieugen[m]>why so eager?

<dthompson>because it's really neat :)

<ieugen[m]>ok :) . can you elaborate?

<dthompson>prescheme is a statically typed subset of scheme that compiles to native code. so it can be used as a systems programming language.

<dthompson>it's part of scheme48 and was made in the 90s but flatwhatson is porting it to guile and seeing if we can build upon it.

<dthompson>it's interesting because we can use a familiar language to write low-level code and not have to use C or something.

<dthompson>what blew my mind when I first saw it was that the code looks pretty much like regular scheme, no type annotations to be found, yet it is statically typed due to type inference.

<ieugen[m]>it is interesting

<ieugen[m]>thanks

<ieugen[m]>I'm not looking to do systems programming (yet) but it's good to know

<dthompson>a future without C and with (pre)scheme, rather than rust or zig or whatever, is exciting to me.

<ieugen[m]>:)

<ieugen[m]>I think the virtual world is huge and there is a place for every programming language

<ieugen[m]>but I get your point

<dthompson>yes I agree! I should clarify that I'm scoping this to Scheme land.

<ieugen[m]>video is up https://fosdem.org/2023/schedule/event/prescheme/

<ieugen[m]>almost up

<dthompson>unfortunately it is broken

<flatwhatson>no, it's still broken. they're working on it :)

<ieugen[m]>I think they are being copied ? https://video.fosdem.org/2023/D.minimalistic/

<dthompson>but yeah what I mean is that it would be nice for those of us that like Scheme to use something very close to Scheme for low-level programming rather than having to use C or Rust or Zig, etc.

<ieugen[m]>size is 0

<dthompson>it *was* up, for a brief and wondeful period of time

<dthompson>and then it was gone by the time I tried to watch it

<ieugen[m]>it's a Rust+zig+C kabal to sabotage PreScheme :D

<dthompson>surely a conspiracy to keep schemers down

<flatwhatson>they acknowledged there's a problem affecting all remote/virtual talks, and it will be fixed "this week"

<dthompson>that would be nice!

<Zarutian_iPad>dthompson: prescheme compiles only to legacy x86 or is RISC-V supported

<jfred>I've been in the process of moving lately (in the new house now but still have loose ends to tie up at the old place) so didn't get to watch live this year. Looking forward to catching up though!

<dthompson>Zarutian_iPad: I think flatwhatson can answer this better than I could

<flatwhatson>Zarutian_iPad: it compiles to C, really using it as a portable assembly

<flatwhatson>compiling this: https://gitlab.com/flatwhatson/prescheme-demo/-/blob/main/vecfun.scm

<flatwhatson>to this: https://gitlab.com/flatwhatson/prescheme-demo/-/blob/main/vecfun.c

<dthompson>flatwhatson: would be cool to do direct native code generation in the (potentially far) future

<dthompson>something about a minimal language relying on the gcc mammoth doesn't sit right with me, spirtitually, but it's 100% the right move for practicality

<dthompson>spiritually*

<flatwhatson>well the original transformational compiler produced motorolla 68020 assembly

<dthompson>oh wow

<flatwhatson>also we don't know whether prescheme-generated C can be compiled with some more minimal C compiler, it's worth exploring

<dthompson>yeah that would be an interesting experiment.

<jfred>I'm curious, is it memory-safe? (I assume not completely but partially?)

<flatwhatson>nope!

<Zarutian_iPad>hmm could it target uFork?

<Zarutian_iPad> https://github.com/organix/uFork

<flatwhatson>it's not safe, but it might be possible to make it safe, or at least safer

<jfred>Oh very interesting, I hadn't heard about uFork before. Pure-actor hardware would sure be neat :P

<jfred>Along similar lines there's CHERI which has actually had (some) hardware built for it: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

<flatwhatson>the main thing is it has a well-designed compiler written in Scheme, with a design that has supported multiple languages over the years (Pascal, Basic, Pre-Scheme)

<flatwhatson>it's been repurposed as a just-in-time bytecode optimizer for scheme 48

<flatwhatson>and used to compile TTCN-3, a test specification language that runs in a concurrent actor-based vm

<flatwhatson>on embedded hardware no less

<jfred>Ooh, whoa

<flatwhatson>so the current effort is to dust it off and get more eyes on it, maybe we can hack it into some more interesting shapes

<jfred>Makes sense

<jfred>Looking forward to watching the talk when it gets posted again 😅

<flatwhatson>yeah hopefully they sort it out soon!

<ieugen[m]>I think the scheme -> wasm and run that or build native from that is another (good) option

<ieugen[m]>wasm is a low level representation

<ieugen[m]>and there is a lot of momentum in the industry for it

<jfred>Reading through the prescheme docs I'm realizing how spoiled I am working with high-level languages. No closures! 😆

<Zarutian_iPad>it is rather high level though for a low level representation

<jfred>Low-level programming is a different beast

<dthompson>prescheme -> wasm would be cool :)

<jfred>Does have me wondering if prescheme could be practical for microcontroller programming too though

<dthompson>like microscheme?

<jfred>Hadn't heard of that somehow but now I need to look into that too I think :P

<dthompson>the rabbit hole is deep

<dthompson>in my free time I'm working on a very minimal scheme -> glsl shader compiler. people will try to make scheme-like things run everywhere. ;)

<jfred>Imagine a bunch of Goblins actors running on ESP32s and chatting via CapTP over WiFi Direct ;)

<dthompson>over here in spritely land I'm trying to generate lamport causality diagrams for vat messages

<dthompson>jfred: :)

<jfred>Or BLE I suppose, not sure they can do WiFi Direct

<dthompson>I'm not well-versed on embedded/microcontroller stuff

<dthompson>dabbled with avr-gcc a bit but didn't make anything too serious

<jfred>I'm not as well-versed in it as I'd like to be beyond some toy LED projects and what little I learned on it in undergrad

<jfred>...oh my, I should have expected this but there's a WebAssembly runtime targeting embedded devices among other things: https://github.com/bytecodealliance/wasm-micro-runtime

<dthompson>neat!

<Zarutian_iPad>dthompson: like https://gist.github.com/zarutian/2f89fc40094702f08ed6 ?

<flatwhatson>ah, but wouldn't you rather write your wasm runtime in (pre)scheme than C? :)

<dthompson>Zarutian_iPad: those are more detailed! I'm generating diagrams similar to what's in the Causeway paper

<dthompson>like page 3 here https://www.hpl.hp.com/techreports/2009/HPL-2009-78.pdf

<dthompson>we want our system to retain message order information so we can use it for debugging and monitoring.

<flatwhatson>also "no closures" isn't exactly correct, see eg. here: https://gitlab.com/flatwhatson/prescheme-demo/-/blob/main/vecfun.scm#L52

<flatwhatson>out appears to be captured here, and it works fine (because it doesn't escape)

<flatwhatson>it's only closures which would require heap allocation that aren't supported

<dthompson>that's an interesting detail

<flatwhatson>it would be far less fun to program without this

<flatwhatson>anyhow i'm off to bed, nn!

<cwebber>flatwhatson: ah, well at least it's not just your talk :)

<jfred>Ahh I see. I don't think I have a good feel for which closures require heap allocation. (I'm definitely spoiled in high-level land 😆)

<cwebber>flatwhatson: does that mean "closures where `set!` is not used"?

<dthompson>vv[m]1: I read your "Hello, Goblins!" article and it is really great!!

<dthompson>I didn't know about the lockstep pattern either. very clever solution!

<dthompson>vv[m]1: you may want to add a slot to keep a reference to the mycapn actor in <rps-host> because it's possible that it may be gc'd eventually. I don't know for certain if it will, but keeping a reference in a slot will ensure it stays alive.

<jackhill>👋 goblins! I haven't been paying attention to this part of the 'net recently, but wanted to come say hellow and congratulate you on all the announcements!

<cwebber>hey jackhill :)

<cwebber>thanx :D

<dthompson>thanks jackhill!

<vv[m]1><dthompson> "vv: you may want to add a slot..." <- nice! thanks for the feedback. I am not quite sure what you mean by 'a slot " but I could do research to figure it out. I'm a lisp, scheme, guile newb

<vv[m]1>hopefully quotes don't look weird translated to irc...

<dthompson>vv[m]1: "slot" is a GOOPS term (borrowed from Common Lisp). it's like how you have the vat as part of your classes.

<dthompson>and the lobby

<Zarutian_iPad>slots is a much older term from Self and Squeak btw

<dthompson>in OOP terms, CLOS is the parent class of GOOPS ;)

<dthompson>but yes, noted.

<vv[m]1>I guess like... a member of the class? To use a different programming language's name?

<dthompson>vv[m]1: yeah, that's right.

<flatwhatson>cwebber: i think "closures which require heap allocation" is mainly when you store a closure for later use, like an async promise callback

<cwebber>flatwhatson: ah I see

<cwebber>you *could* do such a thing on the stack but another way to put that maybe

<cwebber>closures which can be eliminated as closure datastructures

<flatwhatson>yeah, or closures which can be inlined into the surrounding code. not sure on the most accurate way to describe it yet.

<flatwhatson>something like C++ lambda syntax is able to generate a struct to represent the closure on-the-fly, in theory similar capabilities could be added to prescheme

<dthompson>I've been meaning to think about closure stuff for my little side project, actually, so glad this has come up here. :)

<flatwhatson>the only description of what it's doing for closures in either of kelsey's papers is this:

<flatwhatson>> Downward closures could be allowed, as they are in Pascal, since doing so would not compromise the efficiency of compiled programs. This might require declarations on the part of the programmer to indicate when a closure could be passed downwards, instead of needing to be eliminated by beta reduction.

<flatwhatson>implying that "elimination by beta reduction" ie. inlining is the current approach

<dthompson>ah that makes sense

IRC channel logs

2023-02-07.log