IRC channel logs


back to list of logs

<zyd>should documentation bugs (guile manual) be sent to
<daviid>zyd: yes
<daviid>zyd: together with a patch, even better ..
<zyd>daviid: thanks
<old>I should make a release of guile-ev this weekend
<old>I also have a stable guile-configure. a pure scheme build system "compatible" with the gnu coding standard
<dsmith>old, Cool!
<flatwhatson>old: very interested in guile-configure :)
<Arsen>if I send a patch to, should I ping it periodically? is that the right ML even?
<flatwhatson>Arsen: yes that's the right list, but no you generally shouldn't ping/bump threads
<Arsen>sure, thanks
<mirai>how about having a guile-patches ML?
<mirai>patches in guile-devel seem prone to be forgotten in the sea of mails and it's harder to track which of them have been merged already
<rekado>there’s bug-guile, and since it’s backed by debbugs you can view the bugs in, e.g.
<mirai>rekado: I guess bug-guile could be “abused” to serve for patch-tracking but wouldn't it be better to have a similar arrangement like there is for guix?
<flatwhatson>guile-devel is pretty low traffic, i'm not sure having separate MLs would make much difference
<mirai>flatwhatson: just for the purpose of tracking their status?
<flatwhatson>oh right, yes having a tracker makes sense. maybe it could just look for [PATCH] on guile-devel?
<mirai>guile-devel isn't plugged into debbugs though
<Arsen>fwiw, I don't think I saw any mail on guile-devel since posting a patch
<Arsen>but I suggest setting up packwork and/or public-inbox
<Arsen>this works quite well for some components of the toolchain, less so for others, but b4 never fails to be useful anyway
<old>I agree with Arse
<Arsen>patchwork* didn't spot the typo
<old>flatwhatson: guile-configure is not ready for release, but it's usable. I use it in my projects
<old>I manully copy the modules under a .configure directory. That way, I can tweak stuff per project ver quickly
<old>Here's an example of a `configure' script. I use it in Libpatch my main project
<old>It's fairly complex because I do lots of thing in C and there's many options and configuration
<old>that configuration in turn can transform *.in file such as and, but it also export the configuration to C, Makefile and Guile module!
<old>So I end up in my case with a config.h that I include in my C compilation unit and a config.scm that I can use from the following project.scm which define what to build
<old>that project script is actually called from a Makefile so it's transparent to the `configure' `make' `make install' paradigm
<old>here's an example of a configuration result (what you see on the terminal when executing configure):
<old>Support out-of-tree build directory also
<flatwhatson>closer to cmake for guile than merely a ./configure :)
<old>yes. but it does support standard variable of configure
<old>No -DCMAKE_BUILD_TYPE=Debug. Good old CFLAGS='-O0 -g'
<old>anyway, I'm free of autotools now ^^
<flatwhatson>me too, by completely avoiding C and lazily relying on guix's guile-build-system and pretending other OS's don't exist
<old>That's another thing .. some distros have guile-3.0
<old>I've been careful to ony use 3.0.7 feature and no external depedency because apparently it's hard for distros to package guile library ..
<old>So it works at least on ubuntu/debian and Arch Linux from my testing
<old>But I would like to add thing for auto-packaging a subset of a project. e.g. copying importants source and a generating a Makefile into an archive
<old>the state of Guile outside of Guix is hostile unfortunatelly
<old>Arsen: Not trying to burry your proposal here. I think that the patch submission flow could improve
<singpolyma>Luckily you can run guix many places :)
<old>singpolyma: Sure! But not on a customer Box that has an enterprise distro
<flatwhatson>that's what guix package is for
<singpolyma>Why not?
<singpolyma>They probably run pip and cargo and npm on there. Why not guix too?
<old>Some customers are very conservative, e.g. using very old version of GCC and only rely on packages available on a service pack of the distros
<singpolyma>Well, sure, if they want stuff to be in the distro then they can't run your software no matter what language it's in I guess :)
<old>well they can build it
<old>If it's in C and use autotools
<old>not if the build system is a recent release of Guile
<flatwhatson>support for "make release" functionality sounds very nice, the other nice thing would be "make docs" taking care of standard texinfo stuff
<old>thus the foreign packaging scheme that could be made to generate a minimal Makefile for weird cases like this
<old>flatwhatson: The makefile actually a dispatcher here. See
<old>As you can see, I have a `make repl' so I have a Guile REPL where I simply do `(check)'
<old>but yes one could add a `make docs'. In my case, documentation is written in org-mode that is then export to man-pages via emacs
<Arsen>isn't make release just make dist, and make docs just, well, make {html,pdf,info}
<flatwhatson>sure, i mean the functionality not the name
<old>yes. Right now the functionallity are hand-tailored to me need for Libpatch :-)
<old>Since I don't use texinfo for that project well it lack support of it
<old>But since everything is based on GOOPS, it's trivial for someone to simply augment the set of possibility
<old>Just define a new class <buildable> class and implement the <build> method :-)
<flatwhatson>that's where having a repo for it would come in, use-cases can be expanded communally :)
<flatwhatson>also "make dist" functionality would solve the need for copying it into each project, i think?
<flatwhatson>so it can be external, but remain a "dev dependency" only, like autotools
<old>flatwhatson: That the goal! I'm making it more stable by the days of using it. Then I will need to move it to its own distro
<old>And yes that's the point of `make dist' I would only copy the C source files in my cases and genrate a minimal Makefile that do the `pkg-config' stuffs and all the rules
<old>so you end up with a `diet' version of the project that is ready to be compiled from any distro
<old>maybe a `make dist' that generate a autotools project could alse be made
<mwette>Arsen: maybe best to send patch to both and
<Arsen>I already sent mine, so I'm not sure I should resend, I can if you think I should
<mwette>then just send to; that way it stays on a list
<Arsen>okay, I can re-send later
<Arsen>but it is in the guile-devel archives already
<old>ehh I just realize that my patch was never sent
<old>Can't find it on the ML nor guile-bug
<old>oh well
<old>eeh not true. I did receive a ticket number but can't find it in debbugs of guile
<old>nvm found it
<old>71 days old D-:
<tohoyn>sneek: botsnack
<dsmith>sneek, botsnack
<mwette>sneek: botsnack
<daviid>fwiw, i do not think any distro/os is/are 'hostile' to guile, at the very contrary i would say ... but i do not want to engage a conversaton on this subject, i just feel a bit annoyed that some of us here constantly try to 'market' guix 'this way' (speaking badly about other distros/os) ... [guix (or any other 'subject' by the way) does not need that kind of 'marketing' anyway ...] -
<old>I mean I don't see any guile library on fedora
<old>that and it package it wrong by naming guile guile3.0.
<old>same for arch linux, I don't see lots of guile-package there
<mirai>guile package exists for fedora
<mirai>but its guile 2
<old>I meant third party package
<old>not Guile itself, but guile-cairo for example
<old>Ubuntu is way better on that side, it has a few libraries
<old>Arch linux is terrible, only Guile but no libraries
<mwette>ubuntu has lots of guile stuff because it's based on debian, which has lots of guile stuff because rlb takes care of us on debian
<mwette>redhat is bleeding-edge with guile 2.0.14
<singpolyma>Ubuntu and Debian also both have guix as apt install guix
<dsmith> apt-cache rdepends guile-3.0-libs | wc -l
<dsmith>(that's actually 18)
<dsmith>Debian Stable
<old>I think it was fedora whom disable Makefile Guile extension
<old>I vaguely remember that a distro has disabled the GNU Makefile extension for Guile because who use that few MB called Guile?
<Arsen>I mean, that'd not be that surprising. I can't even think of a use for such programming in a makefile
<old>It's just to show how naive some distros are toward Guile
<old>even though I agree that this particular extension in Makefile is probably never used anywhere
<Arsen>guile is generally criminally underused. i'm currently working on supporting it better in gentoo
<old>bless you for doing god's will