IRC channel logs

<apteryx>how would I generate a backtrace programatically upon encountering a fatal crash (I want to log it?)

<wingo>apteryx: see implementation of call-with-error-handling

<wingo>there is also the backtrace procedure

<wingo>starting to think we should merge fibers into guile :P

<wingo>also we should make a release

<apteryx>wingo: thanks!

<apteryx>wingo: thanks! a new release would be nice! I have a bunch of NEWS items to make it more featureful if needed ;-) (new SRFIs and some R7RS fixes)

<old>.

<apteryx>wingo: is the 'backtrace' documented somewhere, or where is it defined?

<apteryx>ah, SCM_DEFINE (scm_backtrace_with_highlights, "backtrace", 0, 1, 0, ... in backtrace.c ?

<mwette>apteryx: there is something in system/repl/error-handling.scm, search for print-frames

<cobra>dthompson: I see you're the maintainer of guile-sdl2. How does one create a surface with a background color?

<cobra>Specifically, I want to make the surface transparent

<dthompson>cobra: I think you want fill-rect

<dthompson>I don't use surfaces, myself. I use opengl.

<cobra>The surface automatically has a black background though, so trying to use fill-rect with a transparent color will just overlay it on top of the black

<cobra>I guess I will look into using opengl

<apteryx>can I get the continuation from an exception to pass it to make-stack?

<apteryx>I don't want to get the extra frames from my handler

<apteryx>maybe, (call/cc get-backtrace) within my handler?

<apteryx>with get-backtrace accepting a continuation object

<apteryx>that seems to work yes

<dthompson>cobra: have you tried it?

<apteryx>hm, not sure actually

<dthompson>you absolutely do not need to use opengl to have a clear background

<dthompson> https://wiki.libsdl.org/SDL2/SDL_FillRect

<dthompson>the docs say that there is no blending

<dthompson>it literally overwrites the color information with what you specify

<dthompson>no alpha blending applied

<apteryx>I'm getting "unknown file" instead of my program file name when using (backtrace): https://paste.debian.net/1301777/

<apteryx>any ideas?

<apteryx>here's the demo program used: https://paste.debian.net/

<apteryx>basically what I'd wish for is something like we have in Python: logging.exception("message"), with the current exception info (backtrace) added below the message.

<apteryx>(c.f.: https://docs.python.org/3/library/logging.html#logging.exception)

<cobra>dthompson: filling the surface with (fill-rect surf (make-rect 0 0 x y) color) where color is #xffffff7f and the surface format is 'rgba8888 results in this: https://0.vern.cc/dt.png

<cobra>the same after replacing make-rect with #nil

<cobra>am i doing something wrong?

<cobra>where the surface isn't, the window is completely transparent

<dthompson>cobra: #x7f is 127 which brings the full white down to a mid gray. looks correct to me.

<dthompson>are you expecting to see through the entire window?

<dthompson>that wouldn't be possible with what you're trying to do

<cobra>i see

<dthompson>I thought you just wanted transparent color data in the surface, which you have achieved

<dthompson>how are you blending when you blit the surface?

<dthompson>perhaps if you blit with no blending at all then you will get the look you're after

<dthompson>I haven't tried this

<cobra>I'm currently converting the surface to a texture with surface->texture, and using set-texture-blend-mode! setting it to none makes it not transparent at all

<dthompson>yeah sounds like it's either not possible to do what you want with sdl or you need to lookup what the proper technique is

<dthompson>all I can tell you is that your surface pixels are correct according to the code you've shown

<cobra>i see

<cobra>i'll look more into it

<apteryx>what's the smallest amount of resident memory guile daemon typically uses?

<apteryx>mine takes 12.9 MiB

<apteryx>random fact: the Guile 3.0.9 VM uses 1 MiB extra of resident compared to Python 3.10.7 (tested using a while loop on Guix)

<apteryx>shared memory is nice; having Shepherd run with on Guile in Guix System means other Guile processes reuse that same memory for their main VM

<apteryx>reading info '(guile) Smobs', there's this mention: "“applicable SMOBs” that's supposed to be discussed, but I don't see where?

<civodul>apteryx: an “applicable SMOB” can be applied like a regular procedure

<civodul>SMOBs are sorta deprecated though

<civodul>not formally deprecated, but “foreign objects” are the newer API for this

<dthompson>and you can define new applicable data types without using C at all

<apteryx>I was looking at the source of https://github.com/artyom-poptsov/guile-udev, which uses smobs

<apteryx>it's 3 years old

<apteryx>dthompson: interesting

<dthompson>for example: https://gitlab.com/spritely/guile-hoot/-/blob/main/module/hoot/reflect.scm?ref_type=heads#L252

<dthompson>we use applicable structs in hoot for running wasm scheme inside guile scheme somewhat transparently :)

<dthompson>a wasm scheme procedure that's plucked out of the wasm runtime can be called as if it were any old procedure

<apteryx>hm. I'll need to ponder over all of this some to get a clue :-)

<dthompson>there's just no nice high level api for it. gotta use the not-so-pleasant low level struct api

<apteryx>can we define keyword arguments procedure from C? The closest I know to do is SCM_DEFINE with optional args

<apteryx>define scheme procedures using keyword arguments*

<civodul>it’s possible, but not so nice

<apteryx>parsing the rest argument perhaps[/

<civodul>in general, people tend to prefer (system foreign) over the C interface

<apteryx>?

<civodul>there’s ‘scm_c_bind_keyword_arguments’

<civodul>via the rest arguments, yes

<civodul>(i think i’ve never used it :-))

<apteryx>good to know about scm_c_bind_keyword_arguments!

<apteryx>I think I'll stick to positional arguments and having two of them accept false values, for a very similar result

IRC channel logs

2023-12-21.log