<dsmith>leoprikler: Yeah, I know there is a lot more you can do with syntax-case, but syntax-rules is so beautiful and elegant that I'm enamored with it and don't want to look at syntax-case. <dsmith>leoprikler: (m0 m0* ...) (mn mn* ...) ... seems to do want I want. <dsmith>Just need to add other patterns for catching errors. ***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<johnjay>rlb: irc is so disorienting sometimes <johnjay>i'm in emacs room and people talk about scheme. i'm in this room people talk about emacs <str1ngs>johnjay: Hello, in regards to the emacsy out of tree build issue. I'm aware of the root cause just not an easy fix right now. <johnjay>is that not something that autotools makes it easy to do? ***apteryx is now known as Guest65684
***apteryx_ is now known as apteryx
***sneek_ is now known as sneek
<str1ngs>johnjay: yes, but there was a request to add --without-examples to remove a large set of dependencies like kwebkitgtk. how every both guile and texinfo need source files in place from the examples . so to fix it I need to enable all the targets. which defeats --without-examples. <leoprikler>can't you make it so that the examples are only treated as text in the --without-examples case <str1ngs>there is some back history here. emacsy was originally written with noweb so there is some entanglement still. if the files are not source then the manual would break or not make sense. <str1ngs>though maybe if I treat them as text that will work. I think the only concern is texinfo not to worried about the guile snarfing. <str1ngs>I was adverse to adding --without-examples anyways because I was not confident there would'nt be side effects. I added up adding it because the user was MacOS user and I thought exposure and testing on Mac was a good thing... but never heard from the user againa. <leoprikler>so you're relying on the fact, that you can evaluate the code in the manual itself to generate some example blocks? <leoprikler>could you write your code in a way, that all those evaluations are #+CALL: and then if someone passes --without-examples [or --without-eval or however you want to call it], those get replaced by a warning saying "this doc was built without support for <...>, so there's nothing here" <leoprikler>or even do feature testing inside the manual using macros <simendsjo>I'm having some problems with Guile on a non-(Guix System) system. Manjaro (Arch based) has 2.2.6 available. Installing the git version fails. Installing Chickadee fails. Installing the different Guix versions (stable, git) fails. And looks like Guile doesn't really work on Windows. In my case, it means Guile is Guix System only atm, which is quite odd. <dsmith-work>simendsjo: Don't know much about Manjaro/Arch, but Guile does have dependencies, and the headers/libs for those must be installed for guile to build. (So typically some *-dev packages). <dsmith-work>When building from git, some auto* tooling needed beyond the packaged sources (the tarballs). <dsmith-work>simendsjo: FWIW, I have no problems installing Guile from source on Debian. <civodul>simendsjo: there are indeed packages for quite a few distros, and also "guix install guile" should work on top of any distro <civodul>but you're welcome to report Guix issues on #guix :-) <simendsjo>guile-git compiled now, but getting guix-git to compile was worse as every package still refers to guile2. I guess I should prioritize getting guix installed, and then use that to install guile and most other software I need. <simendsjo>.. but guile-ssh failed 11 tests so I cannot install Guix. I guess I'll try to build everything from source rather than using the Arch packages. Way more difficult than I was hoping it would be. <lampilelo>have fun resolving issues with the wrong libc and other libs loading <lampilelo>few days ago i gave up on guix on arch when it hung while updating and after i killed the process it turned out guix is in an unrecoverable state <lampilelo>i think it's better to just install guile from source <civodul>lampilelo: interesting, had you installed it from the Arch package or the binary tarball? <str1ngs>leoprikler: hello, I'm really not the author of emacsy. I just help maintain it. So I need to go digging regards to the manual. I don't think out of source builds are overly important I'd like to work on guile 3 support for emacsy first. <civodul>lampilelo: if you have time, we'd welcome details on what went wrong at bug-guix@gnu.org <str1ngs>simendsjo: hello, check the test log files. example. tests/server.log that might not be the exact name/location but you get the idea. <simendsjo>These doesn't give any more information. `# of expected passes 4\n FAIL server-client.scm (exit status: 1)` <str1ngs>simendsjo: which guile version are you using? <str1ngs>hmmm weird they don't use 2.2.7 is this a AUR package or something? <simendsjo>No, this is the official one in Manjaro. It might lag a bit behind Arch. <str1ngs>simendsjo: what is the source field for guile-ssh <str1ngs>simendsjo: can you try changing that to 0.13.0 ? <str1ngs>or using git instead might be easier. <simendsjo>str1ngs: Tried using 0.13 instead, but it fails in the same way <str1ngs>simendsjo: are you trying to build guile-ssh to use guix btw? just curious <str1ngs>simendsjo: also can you paste the PKGBUILD somewhere? <simendsjo>str1ngs: yes. But look at the gist I posted earlier. Some of the tests shows a backtrace, but not all. <str1ngs>simendsjo: thank you sorry, missed the gist <str1ngs>simendsjo: and I mistoke guile-ssh for guile-git apologies <str1ngs>I have guile-git on my mind right now. ***daviid is now known as Guest54789
<simendsjo>I found the problem with guile-ssh. I had installed guile-git too, and it defaulted to using that instead of guile 2.2.6. So the problem is probably related to the master branch of guile. Of course, now guile-json fails a test, but hopefully one step closer.. <str1ngs>simendsjo: I built guile-ssh manually on my pinebook pro with manjarho and checks are passing. <str1ngs>simendsjo: I'm not sure how guile-git would effect this was that a typo *dsmith-work keeps thinking guile-git is guile built from git instead of a release tarball.. <simendsjo>Sorry, guile-git-lib, not guile-git. As you say, guile-git is guile from git <str1ngs>simendsjo: ah so maybe an issue with guile-lib is that what the package is called in Arch? <str1ngs>simendsjo: hmm I don't see guile-lib as a depend of guile-ssh. main thing you have it sorted out? <str1ngs>dsmith-work: you are right its a common Arch naming for package built from git. <str1ngs>I got confused thinking guile-git the library forgot it could be guile built from git. <civodul>i figured string/bytevector output ports are buffered, which is ridiculouse <civodul>but if you make them unbuffered, you allocate less but wall-clock time increases <simendsjo>.. installed guile-git-lib by turning off the tests -- figured the tests were the problem, not the library.. Now stuck on guix-git requiring Guile-Zlib, which isn't packaged in Arch. The guix package fails on guile-json3 as the tests fails. Turned off the tests for guile-json3, crossing fingers, and back at trying guix (not guix-git). <simendsjo>So far it looks good and is compiling, but this is not a frictionless experience <simendsjo>Close, but no cigar. `mmap(PROT_NONE) failed` and segfault. I get the impression people don't use guix (or much guile?) on Arch/Manjaro. <str1ngs>simendsjo: hello, I don't know if how many people use guix. but generally it's easier to use guix-install.sh. though that technically locally bootstrapped. it is bootstrapped and gives you all the guix depends you need. which you will get later anyways. <str1ngs>guix-install.sh is not locally bootstrapped I meant <str1ngs>simendsjo: when using git with makepkg is it possible to pin the git hash?