<ane>not sure if guile uses bison but bison had an backwards incompatible change recently that breaks old gnulib <ane>if someone installs bison >=3.7 they won't be able to compile gnulib *wingo doing a very poor maintenance job these days <lloda>should make check work before make install? <lloda>sneek: later tell aleix i tried your guile-cairo patch and it makes make check fail before make-install <zzappie>logs search doesn't seem to be working *janneke does a lookahead-u8 and blocking read; and sees (guile 2.2.7): <janneke>GC Warning: Repeated allocation of very large block (appr. size 1073741824): <janneke> May lead to memory leak and poor performance <janneke>haven't looked into this yet; ring any bells? <lloda>i see that all the time janneke <janneke>lloda: thanks...guile eats through my memory very fast -- never seen that <lloda>normally i just shrug it off <lloda>i've needed to use GC_INITIAL_HEAP_SIZE=16G or something like that a few times for something to complete <janneke>yeah, well this is supposed to be a daemon, and within a minute it's on 5GiB and rising ;) <lloda>there have been leaks in the past, so i suppose that's always a possibility <lampilelo>is it possible to create a new lexical context inside a function, so that it doesn't know that function's arguments? but without creating a new top-level definition, like a let or something <dsmith-work>lampilelo: If you never refernce the outer function arguments, does it matter? <lloda>yeah if you want to make sure you don't use the context, better define the block outside the context <lloda>only thing that comes to mind is maybe using eval <lampilelo>dsmith-work: i'm asking a very specific question, my rationale is irrelevant <dsmith-work>So what I'm suggesting is if you never reference them, you can't reference them... <lampilelo>dsmith-work: i want to be able to use the same identifier inside of this new lexical context but without a function parameter coming in a way <lampilelo>i have everything i need between eval and unquoting <lloda>you can reuse identifiers simply with (let ((a ...)) (let ((a ...)) *inner-a-here*)) <lloda>i've never needed eval in ~20 years of using Guile tbh <lampilelo>i don't think i'll do it, but i wanted to know how <lampilelo>you hate eval, so what do you have to say about eval-string, huh? *chrislck sets mode +b *eval* <lampilelo>lloda: you use guile at work? as an extension language or plain guile? <lampilelo>i'm curious what do people use guile for in production <lloda>i use it as an extension language <lloda>but the shell isn't much removed from vanilla Guile <lloda>it just gives me a gl window and some other stuff <lloda>i've wanted to move all of the libraries that are compiled in the shell to external Guile modules for a while <lloda>but i never have time to do it <lloda>when i started using Guile there wasn't even an ffi, so it was in a way more natural to use Guile as an extension language <lloda>that has changed over the years <lampilelo>and i extended mocp with it, but only for one thing pretty much <lloda>i rarely need to go to C these days <roelj>Does anyone have any experience with Guile packages on CentOS 8? I can only find guile 2.0, and no guile-devel package.. <manumanumanu>roelj: doesn't redhat package everything in their packages? so guile-devel should be part of guile. <manumanumanu>I haven't used fedora since it was called fedora core something, so I might be off <roelj>Well, running ./configure for my program doesn't find the development libraries for Guile. <spk121>roelj: there is a guile-devel package for CentOS8, but, it is just version 2.0 <spk121>guile-devel-2.0.9-5.el7.x86_64.rpm <spk121>sorry, it is guile-devel-2.0.14-7.el8.x86_64.rpm <roelj>spk121: And how do I install it? "yum install guile-devel" doesn't seem to find it <roelj>Perhaps I should ask in #centos instead :) ***amiloradovsky1 is now known as amiloradovsky
<manumanumanu>ArneBab: so! The protocol is finished for goof-loop! Now we have finalizers for :for clauses, which means (:for ch (in-file "test.txt")) closes the file handle correctly. Everything should be properly propagated to subloops as well. Now I only have some minor cleanup, som tests and some docs to do :) <manumanumanu>ArneBab: ooh... I need to figure out some inlining behaviour as well. (in-file ...) produces a bit suboptimal code <spk121>roelj: I'd imagine centos is "dnf install", but, I'm not sure <roelj>spk121: Seemed to need to add "--enablerepo=PowerTools". :) Problem solved. <Rovanion>Hi, this may be the wrong channel but I'm trying to use Geiser for Emacs to do some REPL-driven development. I've got a form here in the Guix code base that I want to evaluate. I've compiled the whole file with C-c C-k and am trying to eval a form (parse-requires.txt "/path") with geiser-eval-last-sexp, but nothing happens. The REPL shows no output but if I press enter in it the number has been <roelj>Rovanion: The number indicates something went wrong. <Rovanion>Figured out that an exception was thrown and that I could get the backtrace by typing ,bt. But that was pure guesswork. <Formbi>I'm getting «Fatal error: glibc detected an invalid stdio handle» when trying to (import (srfi srfi-1))