IRC channel logs


back to list of logs

<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?
<spk121>lloda: yes
<lloda>ok that makes sense
<lloda>sneek: later tell aleix i tried your guile-cairo patch and it makes make check fail before make-install
<sneek>Got it.
<zzappie>logs search doesn't seem to be working
<zzappie>I get 'Resource not found:'
*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
<lloda>have for years now
<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>{appropriate time} Greetings, Guilers
<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...
<dsmith-work>And the compiler makes sure they are not there.
<lampilelo>lloda: right, it works, thanks
<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
<dsmith-work>Ahh. Ok.
<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>doesn't work with parameterize
<chrislck>eval is evil
<lampilelo>i don't think i'll do it, but i wanted to know how
<dsmith-work>It's spelled "eval", but it's pronounced "evil".
<lampilelo>you hate eval, so what do you have to say about eval-string, huh?
<lampilelo>(eval-string (read-line socket))
*chrislck sets mode +b *eval*
<lampilelo>cheap way to do RPC!
<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
<sneek>Just me
<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>i mostly use it for writing scripts
<lampilelo>and i extended mocp with it, but only for one thing pretty much
<lloda>i rarely need to go to C these days
<lloda>well C++ in my case
<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>or am I completely out?
<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>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
<manumanumanu>anyway. The daily chore is done.
<spk121>roelj: I'd imagine centos is "dnf install", but, I'm not sure
<dsmith-work>Happy Thankgiving to those in the US..
<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.
<roelj>Good guess!
<Formbi>I'm getting «Fatal error: glibc detected an invalid stdio handle» when trying to (import (srfi srfi-1))