IRC channel logs
2023-06-19.log
back to list of logs
<rekado>a few days ago I was made to write some Python web code with fastapi. The experience was very smooth, mainly because I didn’t have to write as much boilerplate code. I think it would be a great help if the code in the webutils project were part of the Guile web server. <rekado>it also helped that launching the web server and watching files for changes was handled by a dedicated command line tool <flatwhatson>rekado: +1 for fleshing out guile's web module, i have some client-side multipart code which would also make sense there <flatwhatson>not sure how others feel about this but imo the ideal situation would be to also have a mainline json library. JSON/HTTP is ubiquitous and basic api client/server stuff should be available ootb. <flatwhatson>alternatively, maybe it's worth resuscitating webutils to make a "one stop shop" 3rd party library for this <daviid>ArneBab: wrt your license quiz, no idea - but with the rest of the idea, i think that those functionalities that are 'guix libification(able)' might/should be (1st) moved to guile-lib [ where the license is not a problem (afaict) ] so we can 'prepare', making sure everything is 'ok' ... it could well be that some(most) won't make it to guile 'proper' anyway, but in guile-lib would already greatly improve/augment guile's batteries ... <daviid>dig in the past :), i'd be happy to see where it gets its 'st value ... tx <ArneBab>rekado: do you think that would be something for web server, too? <wingo>abcdw: i like it and i use something like it in some project but i wonder if core is the right place for it, given that you might want exponential backoff, yielding, etc <wingo>daviid: initialized to 0 on line gobject.c:379 <abcdw>wingo: From my experience it is a very often use case for atomics, especially when you try to stick to FP and it feels missing in (ice-9 atomic). IMHO, it should be available out of the box. Let's make a thread and discuss it in the guile-devel? <wingo>abcdw: another argument :) the proc should take the old value, not the box. this is to avoid an additional atomic-box-ref inside the proc <wingo>in general i think atomics are good building blocks but you always have to wrap them in a library before exposing them to a user <wingo>ah i had just read the docs :) <wingo>which specify that proc is called on the box <cow_2001>i have a one file script. it has a main procedure which i call using #!/usr/bin/env -S guile -e main -s. there is also a define-module defining the file as a module. i've tried adding #:export (main) to it. it still cannot find main. <cow_2001>running it using ./clipboard-speaker.scm <cow_2001>when i remove the define-module, it works as expected <cow_2001>-e '(@ (clipboard-speaker) main)' works! <wingo>erryday be FAIL: net-db.test: getaddrinfo: no name <wingo>otoh i am grateful that threads.test hasn't hung for me in the last few years <wingo>used to do that all the time :P <cow_2001>okay, spawn is a thousand times better than open-pipe* <cow_2001>only weird thing is that it wants the name of the program twice, but i guess the second one is lenient? it's just what passes as the program's argv[0]. <Arsen>that depends on the program :) <ArneBab>cow_2001: you can simplify that to -e '(clipboard-speaker)' — the (@ ... main) is implicit then. <sarna>I still failed to install hall, though. I installed vmware and got guix working on a debian vm - yay! but it's so alien I think I'll skip :/ <morenonatural>I keep getting compilation error for short executables scrips and I dunno where to start looking <morenonatural>I do try to run a script using `env -S GUILE_LOAD_PATH=... guile-3.0 -e main -s ` <morenonatural>it "gets stuck" and will print that warning even when I empty the file and run it as `guile-3.0 something.scm` <RhodiumToad>do you have something dodgy in one of the ccache dirs that matches that filename? <rlb>Not sure what that suggests offhand, but suppose you could try deleting the cache on the off chance something's broken there (disk fileed up or...). i.e. likely rm -rf ~/.cache/guile/ccache <rlb>(unless you've changed your XDG_CACHE_DIR) <morenonatural>although I would like to understand why I'm getting a broken .go file... maybe not worth the effort? <rlb>(need better cosmic ray shielding...) <RhodiumToad>surprised it didn't get overwritten by a successful compile though <dsmith>If that ever happens again, you can take a look at the .go file with readelf. That might give more info on how it was broken. <dsmith>Or even tell you if it was an elf file at all. <dsmith>Also the `file` command might be maginally useful too.