<spk121>There is a new libtool maintainer. That's exciting. <ajarara>writing a test for a guix patch.. why is (eq? (package->specification "foo") (package (inherit (package->specification "foo")))) false? source info missing from the second? <daviid>ajarara: you might want to try #guix - there are guixers here, but ... <ajarara>ah, you're right, I was thinking about watering this down but guix uses a diff define-record-type syntax <ajarara>I'll sleep on it and figure it out tomorrow. I'll check logs if anyone knows off-hand, my guess is these innate fields. I'll see if there's a way to ignore them, or look into package/inherit a bit more <lloda>the pipe question comes up a lot. The manual needs a section on 'How do you x in Guile' <manumanumanu>Ahoy hoy! I have now moved to a 500mbit internet connection, meaning I can now IRC even MORE. I was beginning to saturate that old 100mbit connection. <dthompson>I figured out what was going wrong with geiser. <dthompson>though I am surprised no one else has run into it... is it just me? <dthompson>Zelphir: evaluation within a module file was not working. <dthompson>for example, let's say you were working in foo.scm, which has (define-module (foo)) in it. <dthompson>and the geiser REPL is using the default module, (guile-user) <dthompson>if you were to use geiser-eval-last-sexp on the expression (define bar "hello"), you would expect that this expression be evaluated in the context of the module (foo), since you are editing that file. <dthompson>however, with the latest version of geiser at least, that is not what happens <dthompson>the evaluation is performed in the context of the current module in the geiser repl bufferf <Zelphir>Ah hm. Not sure which of the 2 I would expect tbh. My limited understanding is, that any in Emacs command for running code in Geiser simply copies it over and runs it. But this might simply be a completely wrong understanding of how things work with Geiser. <dthompson>the expectation is that the code is evaluated in the context of the current module being edited <dthompson>and if you read the source code, that is the explicit intention <dthompson>however, it's not working due to a small bug that may only affect guile 3.0+ <dthompson>I just checked with 2.2.7 and the issue is not present there <Zelphir>I guess I have not noticed this before, because I am often copy-pasting like a noob, from buffer to Geiser and manually press enter to evaluate in Geiser. <dthompson>lampilelo: in guile 3.0, the code that geiser uses to find the current buffer's module produces a syntax object, not a list of symbols. <dthompson>so the fix is simply to run syntax->datum on it <lampilelo>so it's pretty much the same issue as the one i debugged some time ago, it changed in 3.0.6 <dthompson>seems that just calling syntax->datum on this is safe because if you pass it a list of symbols, it just returns that same value <lampilelo>this (let ...) form you altered is the one i put there <lampilelo>i'm sure there are more bugs stemming from this syntax/datum thing ***spk121_ is now known as spk121
<lampilelo>iirc in 3.0.6 wingo switched the reader to the one written in scheme and this one wraps everything with syntax <wingo>dthompson: didn't geiser fix this in git <dthompson>I just thought that I had some weird hodge podge broken setup for months <lampilelo>i guess i screw up, i should've cast all of these syntax args to datums <dthompson>because it was around the time that geiser split into many smaller projects <dthompson>and no one else seemed to be complaining about it <lampilelo>i use geiser but didn't know it worked like that because i'm kinda new to scheme so i haven't been using it for too long, so thanks for fixing that dthompson <taw10>How does Geiser figure out the current buffer's module? In particular, why does that part involve Guile rather than just parsing the contents of the buffer? <taw10>I ask because I suspect I have a similar problem with Conjure <dthompson>it figures that out in emacs and then passes it off to guile <dthompson>and during the handoff process, new versions of guile transform it into a syntax object <dthompson>lampilelo: thanks for fixing the other issue <lampilelo>i should've fixed it properely the first time around and you wouldn't have this problem <sneek>I've been running for 17 days <sneek>This system has been up 14 weeks, 1 day, 22 hours, 49 minutes <dthompson>geiser-guile 0.18 is out with my fix. jao works quickly. :) <dthompson>civodul: yes that's the exact problem that's fixed <dthompson>it prevented me from reasonably developing my recent game jam submission in my usual cool, live programming way. <dthompson>I was back to the stone age edit, compile, run loop <civodul>dthompson: yeah i've been working around it for too long... <civodul>C-c C-a was kinda okay, but really not great <dthompson>yeah I could not make that workflow work reasonably <daviid>dthompson: this is great, tx! - fwiw, i did ask sneek, backthen, to tell youi was also facing the exact same problem, when you asked here if others were also... i'll grab the fix right now! <taw10>dthompson: Thanks. Ok, it can't be the same problem in my case ***Ekho- is now known as Ekho
<manumanumanu>I just came in to whine about how the last update to geiser broke coding a module <lampilelo>emacs package updates are a double-edged sword, i regretted updating on more than one occasion, especially updating ivy and helm