IRC channel logs

<old>Any idea why die-line-prog always return #f?

<old>((@ (system vm dwarf) die-line-prog) ((@@ (system vm debug) find-program-die) ((@ (system vm program) program-code) (@ (ice-9 ftw) ftw))))

<old>it seems like Guile objects are compiled with any stmt-list attributes to dwarf DIE

<old>s/with any/whitout any

<mfiano>I'm trying to install my first guile package with a fresh guix install, and i get a backtrace. I'm not sure if someone here could be able to help me find the cause, or if I should take this to #guix. I'm too new to both to know what I can do here.

<drakonis>do ask

<drakonis>you've invoked guix pull, yes?

<mfiano>yes

<mfiano>This is the error/log I have when running `guix install -L . guile-proba` as per the instructions here: https://luis-felipe.gitlab.io/guile-proba/ : https://gist.github.com/mfiano/40d1e560b630067e7e1b0d83068d0cfe

<mfiano>By the looks of it, something is not bound when trying to run the unit tests. I find that a bit comical, considering this package is supposed to make unit testing easier :D

<drakonis>heh well, it released yesterday

<mfiano>Oh!

<mfiano>I just did a google search

<drakonis> https://luis-felipe.gitlab.io/guile-proba/manual/Usage.html

<mfiano>What about that?

<drakonis>ah, it wouldnt solve anything

<mfiano>Know if that author comes around this IRC channel?

<drakonis>good question

<drakonis>see if there arent any tags in the repository

<drakonis>maybe some commit after 0.2.0 broke installation

<mfiano>Ok, yeah, prob not a bad idea to start there first.

<drakonis>any success?

<drakonis>progress, even.

<mfiano>Yes. I have to log out because my guix wasn't set up fully. brb

<mfiano>Well yes and no.

<mfiano>Yes it installed, but just typing `proba` to invoke the binary gives me a guile backtrace at runtime.

<mfiano>And, I'm not quite sure what it is trying to tell me, or this is the author's fault.

<drakonis>progress... at last...

<drakonis>well

<drakonis>what kind of backtrace is it now?

<mfiano> https://img.mfiano.net/xmMPio.png

<drakonis>oh, hmm.

<drakonis>seems to be that proba's modules arent in guile's load path?

<drakonis>see the last line

<mfiano>Yeah I don't know why. I'm just trying to get guile set up still, so I could have very well messed something up.

<mfiano>Are you able to use this (at commit tagged 0.2)?

<mfiano>If not, I'll move onto other things and wait for it to mature a bit :)

<drakonis>i'll give it a quick shot

<mfiano>HEAD detached at 58502f3

<drakonis>alright

<drakonis>maybe wait a bit for this one?

<drakonis>i think someone here might be able to help you out with it

<mfiano>Sure np, thanks.

<drakonis>this is standalone guix, yeah?

<mfiano>I don't know what that means. I think?

<drakonis>guix system or standalone install

<drakonis>no system management only package manager

<mfiano>I just ran the https://guix-install.sh script they provide

<drakonis>alright, so its a standalone install

<mfiano>Yeah, running on Arch here.

<drakonis>hmm, well, same here, for now at least

<drakonis>might hop over to the distro soon

<drakonis>might want to ask on #guix then

<mfiano>Ok cool, thanks.

<drakonis>the problem is most certainly related to the library not installing to the right places

<mfiano>Gotcha. And it's things like these that I always run into when getting set up in a new language. 1) It doesn't help that I am a bug magnet everywhere I go. 2) I don't know what is a bug or what is my own doing.

<drakonis>ha, it happened to me so its probably something we're either both doing wrong or the package developer did wrong

<mfiano>Oh ok, well if it happened to you too, then I'll remove it and keep on learning.

<drakonis>perhaps for the best

<drakonis> https://codeberg.org/luis-felipe/guile-proba/commit/030070ccfb31db75b68394a6a50a44496df87a1f

<drakonis>alas

<drakonis>it was something that the developer did wrong

<mfiano>Ah, I don't know the declarative language of guix yet, so I'll take your word for it.

<drakonis>ha, i wouldnt take my own word on this

<mfiano>:)

<drakonis>i bet it'll be fixed soon

<flatwhatson>yeah this package doesn't look like it's set up for being a guix package

<mfiano>Yeah it was just something dthompson mentioned he wanted to try when we were talking about running tests. No big deal. I can do it easy enough with a shell script

<drakonis>but for now, keep moving forward

<drakonis>srfi-64 is still there if you want to write tests

<drakonis>once proba is fixed, you'll be able to run them just fine!

<mfiano>Yes, I'm using that. I was looking into ways to run them easily from the cli. dthompson uses this beast of an autoconf/automake collection of files to handle all that

<mfiano>I wanted to avoid that

<drakonis>oic

<drakonis>fair enough

<flatwhatson>you can just run srfi-64 tests, it works, guile provides a default runner

<flatwhatson>it's not *pretty*, but does the job!

<mfiano>a default runner eh? I must have missed this.

<flatwhatson>yeah just use (srfi srfi-64), write your tests using test-group, test-assert, etc. then eval-buffer

<flatwhatson>or run with guile path/to/tests.scm

<flatwhatson>there are other runners around but i haven't looked closely

<mfiano>Ah ok. Is there a way to exit with a non zero exit code to hook up to CI or other shell scripts and what not?

<mfiano>(When tests fail)

<mfiano>Ah nevermind. dthompson's code answered that

<drakonis>oh yes... r7rs-large

<drakonis> https://codeberg.org/scheme/r7rs

<drakonis>its finally happening

<mfiano>Well John released a video not very long ago. It sounds like quite a lot of work is needed still.

<mfiano>Have you seen it?

<drakonis>i have not

<drakonis>found the video

<drakonis> https://www.youtube.com/playlist?list=PLyrlk8Xaylp5d8nboeHcddtF8VdF5Zqp0

<drakonis> https://www.youtube.com/watch?v=sRn9UxCEo0Q and for the video itself

<mfiano>Yep, that's the one.

<drakonis>what i meant its that it is finally taking shape

<mfiano>I talk to him in query once in a while. I offered to help out when I am more familiar

<mfiano>I think this was yesterday, and he seemed excited

<drakonis>ah, that's great to hear!

<mfiano>We need at least 100 more me's (experienced lispers/serious programmers [not just a passing academic]) to migrate to scheme and lend their help :)

<drakonis>heh

<drakonis>yes.

<drakonis>really wish lispers would take a look at scheme

<mfiano>but he is organizing the committee well, and it _is_ taking shape.

<drakonis>indeed.

<mfiano>People actually have roles to do now and tickets are rolling in and iterative work has begun on really building it.

<drakonis>i'm looking forward to the outcome of r7rs-large

<mfiano>It might start to get a little confusing reading Guile's manual soon. It doesn't make any distinction between them yet.

<drakonis>it'd be very funny if it actually ended larger than ansi cl

<drakonis>would also be great

<mfiano>Yes

<drakonis>because it'd finally shut up all the lispers that talk about scheme being too small to be useful

<drakonis>the biggest challenge is making sure that there's a couple implementations of r7rs-large

<mfiano>Eh, I never heard that. At least it's not something a CL user would normally think of when they think of Scheme.

<mfiano>A CL user would say that there is no point. CL can do everything Scheme can do and more. (But leave out the fact that it is bulky, hard to sandbox, can't really be embedded into any language, etc)

<ArneBab>drakonis: when doing the advent of code this year, I found only use-cases that are really harder than they should be: https://www.draketo.de/software/advent-of-wisp-code-2021 — reading line-based files (I improvised map-over-lines/port) and splitting strings by substrings. (I built string-split-substring).

<mfiano>But I gave up a long time caring about what people think of this language or that. To me they are all just tools I can use when I need a particular one.

<a12l>Isn't `string=?` defined in https://git.sv.gnu.org/git/guile.g? I don't get any hits when I run `rg -F "define string=?"` inside the dir.

<drakonis>mfiano: a fair point

<mfiano>But, I do foresee big things happening for Scheme soon, and even Guile specifically, so it's good to get on board early :)

<drakonis>aye.

<drakonis>same here, its good to be back

<daviid>a12l: it's in ./libguile/strorder.c

<drakonis>ArneBab: most of aoc is processing files, so it doesnt seem too unexpected

<drakonis>but a good point

<drakonis>time to take a short break

<drakonis>looking forward to fosdem though

<mfiano>flatwhatson: When I run `guile tests/foo.scm`, it also outputs a log file to the directory i run it from. Is there a way to turn this feature off?

<mfiano>Maybe this is explained in the SRFI. I'll read that now.

<old>a12l: string=? is define in libguile/strorder.c:52

<old>It's in C

<flatwhatson>mfiano: i think you'll need to read guile's srfi-64 implementation to answer that

<flatwhatson>you can install your own runner, and might be able to customize guile's built-in one to do what you want

<GNUtoo>Hi, I've looked at the copy-file function here:

<GNUtoo> https://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/filesys.c;hb=f3ea8f7fa1d84a559c7bf834fe5b675abe0ae7b8#l1257

<GNUtoo>(1) Would it be desirable to add a try with ioctl_ficlone first, in order to make a very fast deduplicated copy when BTRFS or XFS are used?

<GNUtoo>(2) I assume that beside getting it right and respecting what is in the HACKING file, I'd also somehow would need to detect that feature with autoconf to also support building with older Linux kernel headers (and also don't build that part on other OS like GNU/Hurd)?

<whereiseveryone>mfiano: here's a custom srfi-64 runner fo guile: https://git.systemreboot.net/run64/

<GNUtoo>For (2) #include <linux/fs.h> and #if defined(FICLONE) could probably be used somehow, at least for OSes using Linux.

<mfiano>flatwhatson, whereiseveryone: thank you.

<mfiano>run64 works well enough for me. My unit tests are easily runnable now, and look prettier than the default runner :)

<mfiano>You know I'm serious when I start making sure I can write and run unit tests good :)

<mfiano>Thank the Scheme gods for srfi-64 though. CL's testing framework situation is an absolute disaster.

<old>mfiano: You can use a modified version that I use: https://git.sr.ht/~old/guile-parallel/tree/master/item/scripts/test-driver

<old>I took it from guile-hall and add some stuff to it

<old>I call the test driver with this script: https://git.sr.ht/~old/guile-parallel/tree/master/item/scripts/run-tests

<mfiano>Thanks, I'll have a look!

<mfiano>Somebody really needs to say something about srht's scheme syntax highlighting attempts...

<old>It's really not their fault here. The script as a shell shebang

<old>s/as/has

<mfiano>Ah I see

<old>look at this one instead: https://git.sr.ht/~old/guile-parallel/tree/master/item/parallel/vector.scm

<old>it's okay I guess :p

<mfiano>Yeah

<mfiano>Does anyone know of a high level overview, like some blog article or something, explaining how to use guix to manage a guile project?

<mfiano>I'm looking at dthompson's repositories, and he uses a guix.scm file that imports a bunch of guix modules, that is pretty opaque to me.

<mfiano>It seems like a very useful thing though. Maybe I should just read the guix manual first.

<whereiseveryone>mfiano: just look at all of arun's guile libraries. They all use guix really well: https://git.systemreboot.net/

<whereiseveryone>mfiano: guix has a guile-build-system that makes thing very easy to package also

<whereiseveryone>but you can use a Makefile approach and gnu-build-system with guile also if that's your cup of tea

<whereiseveryone>mfiano notice how arun uses guix locally to build the project in the repo: https://git.systemreboot.net/kolam/tree/guix.scm#n34

<mfiano>I see it used by a lot of people, not just arun. That still doesn't tell me how to use the guix language or what anything is doing. I also know nothing about how the author uses guix, like for dev environments. I'm looking around for a simple guile coder (not guile user via guix user) walkthrough.

<whereiseveryone>see the guix cookbook

<whereiseveryone>that might be a good intro to guix

<whereiseveryone>a TLDR

<mfiano>"not guile user via guix user"

<whereiseveryone>there's also #guix channel on Libera

<whereiseveryone>not sure what you mean tbh

<mfiano>I still know nothing about how each author has guix set up for their development environment. I can at least see old's use somewhat with his script to launch a pure guix shell...but all these other guix scripts are too opaque because I don't know how they are being used by the author.

<whereiseveryone>do you know about guix shell already?

<whereiseveryone>`guix shell`

<whereiseveryone> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html

<mfiano>I know about the concept. I have used the nix equivalent about 6 years ago.

<whereiseveryone>that's the usual entry point to doing development

<whereiseveryone>it models nix shell

<whereiseveryone>ya

<mfiano>The problem is not learning guix though. You are missing me.

<whereiseveryone>you're trying to understand dev workflows with guix?

<whereiseveryone>or something else?

<mfiano>That is too general.

<whereiseveryone>k, can you describe the specific you're trying to achieve

<whereiseveryone>in more detail

<flatwhatson>the dev's individual setup shouldn't matter, at least in theory

<mfiano>I am trying to understand dev workflows for developing my Guile scheme software. How to instruct guix to pull in the dependencies I need, and all that. I do not want to know about all the inner workings of guix. I want to know how Guile _developers_ are using it at the most basic level, without having to read the huge guix manuals and try to piece together the 1% of that I need.

<flatwhatson>mfiano: have you used direnv or envrc? i find that simplest

<mfiano>flatwhatson: Yes, I currently use direnv with a .envrc for setting my GUILE_LOAD_PATH and GUILE_HISTORY

<flatwhatson>right, you can also use eval $(guix shell ... --search-paths) in there to add guix deps

<flatwhatson>guix shell supports a guix.scm or manifest.scm, or you can specify packages on the command there directly

<flatwhatson>see https://gitlab.com/flatwhatson/guile-gemini/-/blob/main/.envrc

<lilyp>mfiano: there's a presentation called on using guix.scm files for building your projects

<mfiano>Ah so you are saying to use the global guix environment for every project?

<lilyp>I forgot the exact name though

<lilyp>I think it was "Use a guix.scm" or something along those lines

<whereiseveryone>mfiano: you can use individual profiles if you like

<mfiano>lilyp: Thanks. I'll look for it.

<flatwhatson>mfiano: that's up to you, though it can be more annoying to add eg. coreutils to every project :)

<whereiseveryone>flatwhatson: but that's only needed if you use --pure?

<whereiseveryone>atleast in my experience

<mfiano>My understanding is that shells are hierarchical layers, and a pure one starts blank

<flatwhatson>correct

<flatwhatson>re: using a global env, not really, i use .envrc with guix shell to create project-specfici environments

<whereiseveryone>mfiano: one footgun you should be aware of is that you need to include the interpreter in your shell if you don't already have it in the base environment

<flatwhatson>and envrc-mode with emacs so that it understands and respects them

<whereiseveryone>for example if you create a shell with sbcl-alexandria and sbcl-jzon you also need sbcl

<mfiano>flatwhatson: Could you share an example .envrc and .guix.scm file and how you use them together?

<whereiseveryone>there was some discussion at one point about not requiring that but people decided on the former

<mfiano>I am very familiar with direnv so this might click for me

<whereiseveryone>iirc the direnv approach will just do what you'd do anyway "by hand" but maybe that will show the steps also. Could be useful though if you want to set environment variables that are long in your guix shell

<mfiano>I should have known... https://dthompson.us/guix-for-development.html

<mfiano>dthompson has a monopoly over useful guile information

<flatwhatson>mfiano: here's my guix.scm: https://gitlab.com/flatwhatson/guile-gemini/-/blob/main/guix.scm

<flatwhatson>and my .envrc: https://gitlab.com/flatwhatson/guile-gemini/-/blob/main/.envrc

<mfiano>Thanks!

<flatwhatson>so the guix.scm is specifying how to build my package, and the envrc is using that to build an env

<lilyp>exactly

<mfiano>So now I just have to learn what all those guix imports are and how the declarative language works.

<flatwhatson>there's a lot going on, if you try to learn it depth-first you'll probably have a bad time (ymmv)

<flatwhatson>the guix repo is the best source of examples of guix how to define packages :)

<mfiano>Well, I have time. It seems like it would be beneficial anyway.

<mfiano>I'm in no rush to start coding. My first stop was making sure I could run unit tests. Now it's to make sure I can build and easily deploy/reproduce my projects to all my machines (and anyone else that wants to use them)

<flatwhatson>yes it's pretty awesome!

<mfiano>You people are all very helpful. I am such a newb, thanks :)

<whereiseveryone>mfiano: I just read dthompson's blog post. Didn't know about that one but that's pretty much the workflow I've used before except for the direnv part which I only did for some time. I might go back to direnv soon.

<whereiseveryone>I've used direnv without guix for development but sometimes guix can make direnv slow because of all the stuff it downloads beware ymmv

<whereiseveryone>after that first time though it should be fast going forward because of this: https://guix.gnu.org/blog/2021/from-guix-environment-to-guix-shell/

<whereiseveryone>see the section "Caching environments" that ludo wrote

<mfiano>Was Guix forked from Nix?

<mfiano>I'm seeing some NIX_* environment variables in the manual :)

<GNUtoo>Guix uses some parts of nix, for instance nix build daemon if I recall well

<GNUtoo>But the rest on top is completely different

<mfiano>Ah

<whereiseveryone>mfiano: Yes, it uses an old version of the nix daemon. Some parts of the nix daemon were ported to guile by ludo. See guix/derivations.scm, for example

<mfiano>I just ran into a snag, trying to get one of flatwhatson's bindings working.

<whereiseveryone>derivations.scm used to be functionality in C++ that was in the nix-daemon at the time of forking

<mfiano> https://gitlab.com/flatwhatson/guile-gemini/-/blob/main/guix.scm#L16

<mfiano>For me, I get an error when doing `guix shell`, because (current-filename) always returns #f

<mfiano>(dirname #f) errors when compiling. I don't understand what is different about his guile setup.

<whereiseveryone>does it work in the guile-gemini repo but not in your personal repo?

<mfiano>I didn't try his. I've been trying to get my own empty project able to be `guix shell`'d.

<mfiano>For a few hours, haha.

<whereiseveryone>maybe try his to see if it works on your system and then work from there to see what's missing in your repo? dunno ;()

<mfiano>This looks like a bug in guix from my output

<mfiano> https://img.mfiano.net/ulptBm.png

<flatwhatson>mfiano: i think my snippet only works correctly if you have made a commit ':)

<mfiano>Yeah I got it to work, however, there is something I don't like

<mfiano>Because you are only evaluating the research of the env vars returned by --search-paths, it isn't the same as if you invoked `guix shell` interactively...it doesn't set $GUIX_ENVIRONMENT, so my prompt doesn't change. Slightly annoying, but other than that works.

<mfiano>evaluating the result*

<mfiano>and attempting to call `guix shell -Df guix.scm` in .envrc results in me fork bombing myself :)

<mfiano>apparently invoking the shell switches the directory with causes an infinite loop

<mfiano>I just want $GUIX_ENVIRONMENT to be set properly when eval'ing with --search-paths. I'm not quite sure how yet

<flatwhatson>hmm? the eval $(guix shell ...) works perfectly fine here, not sure how you're getting bombed

<mfiano>_that_ does

<mfiano>but not what I want

<flatwhatson>you could try: eval $(guix shell -Df guix.scm -- env)

<flatwhatson>that will grab the whole env instead of just the paths set by guix

<mfiano>I get a bunch of command not founds when I do that

<flatwhatson>hmm. what do you need GUIX_ENVIRONMENT for? you're kind of not *really* in a guix shell using this .envrc integration hack

<flatwhatson>you could set GUIX_ENVIRONMENT in your .envrc yourself if that's useful for some other tool

<flatwhatson>but maybe that's something for guix or direnv upstream to improve integration

<flatwhatson>i've never noticed a lack of that particular var

<mfiano>Ah, the guix install script modifies .bashrc to show that you're in a guix shell if $GUIX_ENVIRONMENT is set, which is only set when invoking guix shell, not just evaluating its variables

<mfiano>I know I'm not really in the shell...and that was the confusion. I wanted to know :)

<mfiano>I guess I'm not used to my environment being changed without some idicator. Maybe I can get used to this.

<flatwhatson>there's DIRENV_DIR or DIRENV_FILE, or you can export something from your .envrc, looks like $0 there is the path to the .envrc file being evaluated

<mfiano>Ok I'm set there. Now I have another problem

<mfiano>I activate (ice-9 readline) in my ~/.guile, and that works great if I don't eval the guix --search-paths. But if I do, guile can't find (ice-9 readline)

<mfiano>Oh hmm. It works if I use my system installed guile...but the guile at the front of my path was in /gnu/store

<mfiano>This is getting a little confusing. Think I need to call it for the day.

<flatwhatson>yeah that's confusing! perhaps your system & guix paths are getting mixed

<flatwhatson>that's where a --pure environment might help, or just "unset GUILE_LOAD_PATH GUILE_LOAD_COMPILED_PATH" before "eval $(guix shell ..."

<mfiano>I just fixed it

<mfiano>I needed to add (arguments '(#:source-directory "src"))

<mfiano>Like yours :)

<mfiano>I must say, some of the guix errors could be a little more obvious

<a12l>daviid: Thanks!

<flatwhatson>yes, there's improvements to be made debugging both guix and guile

<a12l>old: Thanks!

<flatwhatson>it's an active area of interest, jgart[m] is gathering support for a guile debugging working group for 2023 :)

<mfiano>Thank you for the help today everyone. Learned a ton, and almost up to where I want to be.

<mfiano>Very nice

<mfiano>flatwhatson: Thanks for showing me your code. I think I can learn a lot from your 'grump'

<flatwhatson>mfiano: heh, it's just a dumping ground of half-finished ideas but glad it's useful :)

<mfiano>That's exactly what I'm looking for. Scheme code in the making :)

<cow_2001>okay. i've reached a real mind bender (for my puny little mind, at least)

<cow_2001>wait, i should ask on #scheme instead

<mfiano>Morning. And wow, g-golf looks very nice, daviid.

<mfiano>I'll have to look into that sometime. I never did any GNOME or GTK+ UI before, but I often wondered if it would be worth it try figuring out how to embed a native GL window in, to have another UI decoupled from the main renderer.

<daviid>mfiano: the gtk4-demo has a couple of OpenGL based examples

<mfiano>Oh, thanks. I'll look into that.

<daviid>mfiano: 'GtkGLArea is a widget that allows custom drawing using OpenGL calls.'

<mfiano>Cool. I often waste weeks or months writing an adhoc UI system using low level graphics routines...

<daviid>mfiano: https://imgur.com/a/oBvls8B

<daviid>a screenshot of the gtk4-demo 'OpenGL' tab

<mfiano>I'll definitely have to explore this when I get that far.

<mfiano>Is there a scheme function that can clear the REPL, or a flag that will elide the startup banner text?

<daviid>mfiano: ofc someone still has to update guile-opengl so the experience would be 'smooth' - and in your perspective of a game, chickadee is a (much) better choce, i think

<mfiano>daviid: That is what really saddens me, that guile-opengl only supports the 20+ year GL 2.x API. I fear I am going to have to do a lot of wrapping 4.x stuff as I go.

<mfiano>4.3 is like 10 years old even. That's what I usually target, because SSBO's are wonderful

<dthompson>I use gl 3 with guile-opengl.

<mfiano>Oh? the manual says 2.x only.

<dthompson>there's some functions I've had to add wrappers for

<mfiano>Aha. We should pool our resources (when I get that far) :)

<dthompson> https://git.dthompson.us/chickadee.git/tree/chickadee/graphics/gl.scm

<old>mfiano: Auto-generating OpenGL4 bindings should not be that hard

<old>It has been done with XCB I think

<mfiano>I see. I'll think about a guile-opengl4 extension library sometime :)

<old>Would having a vulkan binding more useful since it's the new opengl?

<mfiano>I was also looking into libepoxy

<mfiano>Which seems like it'd make things easy

<dthompson>guile-opengl should just be updated to wrap the missing stuff

<dthompson>it was made using some sort of automation

<mfiano>old: I don't think Vulkan is worthwhile for single-person/small team developers that want to get work done.

<mfiano>That's my opinion though

<old>I haven't use it yet, but too much low level?

<dthompson>any time I break gl 2 support by accident I hear about it, so switching to vulkan is not something I'm personally interested in right now.

<mfiano>Well it's something like 10kloc of C just to display a triangle. You get to write your own allocators and everything :)

<old>ah neat. This is great for a high performance engine

<dthompson>yeah it's great for big companies or whatever

<old>if you have the time

<old>dthompson: Would it be possible to have opengl2 and opengl4 in guile-opengl at the same time?

<dthompson>yeah

<mfiano>Right. Not very practical for less demanding applications. I still can't even put a dent in my 7 year old GPU...usually run out of VRAM or CPU compute before that

<old>Maybe selecting the variant at runtime

<dthompson>it doesn't really work like that. you ask the system "please maybe I have an opengl context with these properties?" and it will hand you back something that matches to the best of its ability.

<mfiano>That is one thing I hope to fix for guile, is making OpenGL 4 bindings and very nice high level lispy wrappers like CL has.

<dthompson>I've been using guile-opengl for many years and aside from missing some newer API functions I don't think it's missing anything.

<mfiano>If I don't have SSBO's, I'm missing everything :)

<dthompson>yes, those are nice, and you can use them.

<mfiano>4.3 core or sometime before that with the relevant extensions

<dthompson>I haven't yet expanded my personal collection of gl wrappers to contain that api

<dthompson>but if you look at my link you'll see that it's easy to do

<mfiano>I agree it is. It's just the shear amount of them, and writing the lispy wrappers that cl-opengl has.

<mfiano>gamedev is easy. it's just a million tiny things :)

<dthompson>guile-opengl provides the lispy wrappers. all the gl functions become scheme procedures.

<dthompson>guile-opengl really just lacks someone maintaining it. maybe I should do it, I dunno.

<old>aren't you already the maintainer?

<mfiano>Well, I will surely help at some point. I'm starting with basic stuff :)

<dthompson>old: no

<mfiano>dthompson: I do have a request for you, should you ever find the time before I do

<dthompson>chickadee provides high-level abstractions on top of guile-opengl's low-level bindings so you can have data types for textures, buffers, shaders, etc.

<dthompson>and that includes deleting the gpu resource when guile gc's the scheme object for a particular object id

<mfiano>dthompson: For your guile-sdl2, can you add support for the FRect struct API? All the rect functions are duplicated as frect functions I think now (as of like a year or two ago), to allow for sub-pixel floating-point alignment. I have recently been using that in CL to avoid using GL directly for simple stuff. That is likely going to be one of the first things I do if you don't get to it :)

<dthompson>sounds like a good first project for you :) I probably won't get to that one before you do.

<mfiano>Sounds good :)

<dthompson>I think you'll find guile-sdl2 to be reasonably well organized

<dthompson>should be easy to add the necessary wrappers

<mfiano>I did look at it and I was impressed.

<mfiano>Everyone says to look at your code for quality standard. They aren't lying.

<dthompson>I didn't know anyone said that lol

<mfiano>The other day a few people here recommended me to look at your code for how it should be done :)

<mfiano>I don't recall who

<dthompson>rects are one of the weirder parts of guile-sdl2 because they aren't objects that sdl2 allocates for you

<dthompson>now that I think about it

<mfiano>I don't know. I think my cl-sdl2 just calls the explicit constructor/deconstructor function they expose, and has a with-* macro for called SDL_FreeRect() automatically if you don't need to keep a reference past the lexical extent.

<dthompson>looks like we don't have any of the rect functions wrapped at all! just some of the functions that accept regular rects as arguments.

<mfiano>s/called/calling/

<mfiano>Oh wow

<daviid>dthompson: i did, twice in the last few months, i stand by my recomendation :) - last was te 28th - http://logs.guix.gnu.org/guile/2022-12-28.log

<dthompson>sdl2 doesn't have a free rect function as far as I know

<dthompson>hehe thanks daviid

<dthompson>I personally don't use the rect api because it's so simple that it's better to implement them in scheme

<dthompson>like SDL_PointInRect could be wrapped, and I'd accept such a wrapper, but it's not that useful.

<mfiano>Ah yeah, you're right.

<dthompson>but if there's any other functions that accept an frect then we'd a frect scheme data type to handle it

<dthompson>we'd need*

<mfiano>Well, I'm primarily interested in FRect's, because the FRenderer API is awesome for 2D subpixel layer placement and parallax stuff

<dthompson>SDL_RenderDrawRectF and friends will need to be wrapped

<mfiano>Yeah those are the ones I'm talking about...sorry, it's been a few months since I used the API.

<mfiano>I'll gladly wrap them at some point

<daviid>dthompson: welcome! i am also very happy for your new job, and secretly hope you convince the institute to let you rewrite the enine using goops and te mop ...

<mfiano>Oh I must have missed the announcement, but congrats on the new job :)

<daviid>mfiano: https://spritely.institute/news/growing-a-networked-garden-with-spritely-goblins.html

<mfiano>Oh! I read the news last time that cwebber hired someone else...I missed this one.

<mfiano>last year*

<mfiano>dthompson: Congratulations!!!

<dthompson>thank you!!

<dthompson>hope to have lots more cool stuff to share soon once I'm fully onboarded and making some serious contributions to the codebase.

<mfiano>I finally got some test projects working with guix environments and unit tests work...so next, I guess I have to figure out how to actually make my guile libraries guix-installable correctly for others to use. The Guix documentation says that significant guile projects should have a GNU make setup and switch the build system to gnu. That is something I don't feel comfortable with at all...I know

<mfiano>next to nothing about the GNU toolchain from a developer perspective, only user, and m4 macros make my head spin.

<mfiano>So wondering where to go from here...

<dthompson>you really don't need much.

<dthompson>it's mostly some boilerplate.

<dthompson>but the result is something that is easy for other people to build and easy for you to build and generate release tarballs, etc.

<mfiano>Yeah but I'm not surew what boilerplate is required to get my stuff guix-installable. Sort of in a chicken/egg problem here without some guidance, since I don't know anything about `make`.

<mfiano>Your boilerplate looks much different than other peoples, and likewise for them to others.

<mfiano>So it's sort of hard to make head or tails out of :)

<dthompson>I cribbed my stuff from guix back when their autotools config wasn't super complicated.

<dthompson>you really need 2 things: configure.ac and Makefile.am

<mfiano>Ok. In the past I have only written a simple straight 'Makefile'.

<mfiano>And this was a while ago, so we can pretend I forgot everything, because I likely did.

<mfiano>I have some research to do. No prob. Not in a huge rush.

<lilyp>you really only need to copy the rule for .scm → .go

<lilyp>speaking of which, we should probably get a guile module into meson

<dthompson>mfiano: if you have a basic project with a couple of guile modules that you want to be able to install I can help you get a minimalish autotools setup.

<dadinn>I've been trying to understand syntax-case macros. I've looked at the documentation at https://www.gnu.org/software/guile/manual/html_node/Syntax-Case.html

<mfiano>dthompson: That would be fantastic

<mfiano>But I mean, I just have a single module with a single define, and some mock unit tests in another module

<mfiano>Nothing really worth showing.

<dthompson>that's enough.

<dthompson>it doesn't need to be anything useful

<mfiano>Ok give me a couple. Gotta step afk and then I will push it somewhere.

<dadinn>I am trying out the aif example with with-syntax, which is defined as: https://termbin.com/ipnz

<dthompson>I'm working so I won't be able to help right away but I will be able to at some point

<mfiano>Something just came up anyway, and I won't be back for a while. No rush. Thanks!

<dthompson>np!

<daviid>mfiano: if you are serious about your project, you should 1st and above all, get it autotool chained, then guix can 'take and shake it' like it's a joke anyway ... i also can help with that, if you upload ona free s/w servicfe, savannah, sourcehut, notabug ... but not if github (give up on github) nor gitlab ... (i don't have and don't want to have an account with those, not even gitlab ...)

<daviid>mfiano: there are numerous way to start , basically copy the chickadee tree struct and autotool files - meanwhile, here is an intro https://erikedrosa.com/2017/10/29/guile-projects-with-autotools.html

<cwebber>we are definitely excited to have dthompson on board in spritely land

<cwebber>and btw

<cwebber>#spritely is a channel on here

<cwebber>for those who would like to follow along

<dthompson>join us!

<dthompson>(or I *will* take it personally)

<dthompson>(I'm just joking)

<cwebber>you don't wanna make dthompson cry

<cwebber>it's a lot of work to clean up, gotta use a mop

<dthompson>don't make cwebber have to break out the mop

<daviid>sneek: seen dsmith

<sneek>dsmith was in #guile 9 days ago, saying: goodbot.

<daviid>cwebber: i joined, i see no sneek, is the channel logged?

<cwebber>daviid: it's not logged yet

<cwebber>it should be!

<daviid>when it is, you might wana resue the beautifull rekado's code to web show the logs ...

<daviid>*reuse

<cwebber>daviid: where's that code? :)

<daviid>let me find

<lilyp>the one that puts ACTION for /me?

<daviid>haha

<cwebber>tsyesika has it on her plate to solve our logging situation ;)

<cwebber>which might just be getting us on https://libera.irclog.whitequark.org/

<cwebber>but we need an irc bot in a sense

<daviid>cwebber: here https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/goggles.scm

<daviid>cwebber: then we could ask dsmith to add our bot there as well ... when he's back

<cwebber>thanks daviid! I will ask tsyesika to investigate when she returns from holiday ;)

<daviid>np!

<mfiano>daviid: I'm right with you there on github/gitlab (and now gitea). I decided earlier this year new repos won't be on their. probably something simple like cgit and you can add my remote :)

<mfiano>there*

<mfiano>cwebber: Don't worry, dthompson will be MOPing up your mess with GOOPS sooner or later

<dthompson>I feel like there's a not-quite-satisfied niche for a git hosting tool for self hosters that just handles repo access, viewing, and bug tracking.

<dthompson>cgit has worked just fine for me as a viewer. gitolite is fine for access. I don't know of a good issue tracker that doesn't involve managing database servers.

<mfiano>give it a year and there will be a blockchain for that or something (sigh)

<daviid>savannah/debbugs still have my prefs

<dthompson>neither of those are easy to host for yourself. mailing list based tracking is good for bigger projects with the necessary infrastructure.

<mfiano>I do agree there should be a self-hosted or distributed (or both) service for issue tracking very much so. But at the same time, I long for the simpler times of email and patches.

<dthompson>people email me patches now, but there's no public record and nothing tracking open/closed issues

<mfiano>Yeah, that's the reason why I think thre is a hole to be filled.

<mfiano>i don't want to open myself up and run some php script with sql, redis, 5 services running and whatnot, just to track that stuff. I think it would make for a good guile project, but the web annoys me too much to spend that much time working on that.

<daviid>dthompson: you could create ml on savannah nongnu, no? sh offers ml as well - i perso don't have the free time to self host, nor the money, hence savannah is perfect for me - and i am against web driven workflow, so cgit for the code, ml for discussion design, patches ... and debbugs ... are quite perfect

<cwebber>dthompson: "how hard could it be"

<daviid>although they seem a bit 'old-fashioned', there are a 'back to the future' thing afaic :) - those web sites gets my fan on the cealing before they even displayed the first line, just to put an avatar and totally useless colors, totally useless indentation, more then often inadequate ... no thanks :)

<mfiano>Newbie style question, if anyone can chime in :) Should I have a main (project) module with (project src) and (project test) modules, or should I have (project) and (test) or something?

<daviid>anyway, back to hack

<dthompson>daviid: I like hosting my small projects on my own server. I'm happy to move them if they outgrow it, but it would take longer for them to outgrow it if I had a simple issue tracker.

<dthompson>cwebber: "it's one issue tracker, Michael. what could it cost, $10?"

<cwebber>haha

<dthompson>(forgive me if this is not a universally known Arrested Development reference)

<rekado>we could add #spritely to the list of logged channels if you don’t want to host this yourself.

<mfiano>Additionally, is it generally good practice to have 1 module per file in Guile? I see that a lot anyway.

<rekado>and lilyp is welcome to turn ACTION into /me.

<dthompson>mfiano: yes, and in practice you need to do it that way because that's how load path lookup works.

<mfiano>dthompson: To my first or second question?

<dthompson>mfiano: the question about one module per file

<mfiano>Ok thanks.

<dthompson>rekado: thank you for the offer. cwebber what do you think? is it important for us to host our own irc logs?

<daviid>dthompson: i understand, you also have the knowedge and practice to selfhost, i don't (i could but i'd have to learn and practice you can't buy at a shop ... :)

<mfiano>Would I want to namespace my test module to be a list of two items, with the car being my project name? I'm not sure if this will cause namespace clobbering just having it called test. Currently my %load-path has $PWD and $PWD/src added to it, and I run tests with something like `guile test/tests.scm` and it works with just (define-module (test) ...)

<dthompson>daviid: I have learned to be *very* picky about what I self-host over the years. anything I've ever tried to maintain that involves mysql/postgresql/etc. inevitably breaks in a way that I can't be bothered to fix.

<rekado>dthompson: good thing the goggles thing just uses files then :)

<dthompson>mfiano: since your test modules wouldn't be part of the library that someone would install you're free to use whichever names you'd like

<cwebber>rekado: works for us

<rekado>coolio

<cwebber>#spritely and #ocapn both actually

<rekado>ok

<cwebber>yay

<cwebber>thx!!!

<mfiano>dthompson: I see. and by library you mean r6rs, what define-module accomplishes, and what `library` expands into on guile?

<dthompson>mfiano: by library I mean the collection of modules that you'd distribute in a release of your project

<mfiano>Ah ok, so Ill worry about that after autoconf/automake

<mfiano>Sorry for all the dumb questions and thanks for the help everyone. I really am a complete idiot when I'm outside of CL, but I'm really trying here.

<dthompson>no worries at all. every time I try to do CL I feel like a helpless baby.

<mfiano>Oh I have one question that didn't get answered this morning

<mfiano>Is there a scheme function I can call to clear the REPL, or a guile switch to start it up without the verbose banner text?

<mfiano>Not a deal breaker. Just went looking and didn't see anything of the sort so I am kind of curious.

<dthompson>not that I know of

<mfiano>Fair enough.

<mfiano>Ok, last question before I go finish my chores :) Am I correct that guile programs, even though it JIT compiles and compiles ELF .go files, needs the guile executable available?

<dthompson>mfiano: correct. native compilation and single-executable distribution are not yet implemented.

<dthompson>will be nice to get one or both of those!

<mfiano>I see. I'm not complaining. Guile is nice to work with and fast enough for me. guix should help make it more installable anyway

<dthompson>I have some special code I use for generating binary bundles to distribute game jam stuff.

<mfiano>I actually lost interest in gamedev a couple years ago, so dont think I will be needing anything like that. I just write little graphics thingies :)

<dthompson>the tool itself could be more generally useful. it helps you bundle up the guile executable, libguile, any C shared libraries that are used via the FFI, and all the guile modules your program needs.

<mfiano>Sounds like a nice blog article in the making :)

<dthompson>it's a gross hack that is pretty useful :)

<mfiano>Everytime I search for how to do something in guile, your blog pops up

<dthompson>oh really? that's cool

<dthompson>I don't track my site traffic or anything

<mfiano>Yeah, I was struggling with guix yesterday. Your blog article helped with that.

<dthompson>i'm glad!

<mfiano>I actually had to rip out pieces of your package recipe and pieces of flatwhatson's to get mine to work.

<mfiano>Mostly due to the fact that I'm using the guile build system and not GNU

<mfiano>For...reasons that will hopefully be solved soon :)

<dthompson>ah, makes sense. I haven't used that build system. :)

<old>talking about build system, I think I'm done with refactoring a little helper that I've made in order to avoid autoconf

<old>a configure script can look like this: https://git.sr.ht/~old/guile-parallel/tree/master/item/configure

IRC channel logs

2022-12-29.log