unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* Geiser and Guix - how to avoid long compilation steps?
@ 2020-05-25 23:02 Jonathan Frederickson
  2020-05-26  0:05 ` divoplade
  2020-05-26  7:45 ` Pierre Neidhardt
  0 siblings, 2 replies; 7+ messages in thread
From: Jonathan Frederickson @ 2020-05-25 23:02 UTC (permalink / raw)
  To: help-guix

I've been using Geiser to hack on Guix lately, which is absolutely 
wonderful to use when it works. The trouble is, after I upgrade my 
system's Guix, Guile attempts to compile large portions of Guix when I 
attempt to switch to the module I'm working on in Geiser, e.g.:

M-x run-guile
,m (gnu services games)

This despite the fact that I'm working on a copy of Guix that I've 
already compiled with 'make' and that has the compiled copy alongside 
the source. The compilation step takes a *long* time on my hardware, 
which is fairly painful when I want to hack on Guix.

I do have my Guix checkout in geiser-guile-load-path in my emacs config 
as per https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html:

(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/sources/guix"))

My guess is that Guile is picking up my system's version of Guix before 
my local copy. I understand that I could start a version of Emacs in a 
pure ad-hoc environment (and Guile doesn't appear to start recompiling 
Guix when I do so), but the typical Emacs workflow is to have a 
long-running Emacs session and use that for everything; that's what I'm 
used to, and I'd like to continue to do so if possible.

Does anyone else experience this? What's the best way to use Geiser to 
hack on Guix when running Guix System?




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-25 23:02 Geiser and Guix - how to avoid long compilation steps? Jonathan Frederickson
@ 2020-05-26  0:05 ` divoplade
  2020-05-26  2:32   ` Jonathan Frederickson
  2020-05-26  7:45 ` Pierre Neidhardt
  1 sibling, 1 reply; 7+ messages in thread
From: divoplade @ 2020-05-26  0:05 UTC (permalink / raw)
  To: Jonathan Frederickson, help-guix

Hello,

I think that guix does not support guile 3 yet, so you should have
guile 2 bytecode for the guix modules. If geiser starts guile 3, then
guile 3 will recompile everything because the bytecode format changed
(and it could even compile native code).

Maybe it could work if you used guile 2.2 with geiser.

divoplade

Le lundi 25 mai 2020 à 19:02 -0400, Jonathan Frederickson a écrit :
> I've been using Geiser to hack on Guix lately, which is absolutely 
> wonderful to use when it works. The trouble is, after I upgrade my 
> system's Guix, Guile attempts to compile large portions of Guix when
> I 
> attempt to switch to the module I'm working on in Geiser, e.g.:
> 
> M-x run-guile
> ,m (gnu services games)
> 
> This despite the fact that I'm working on a copy of Guix that I've 
> already compiled with 'make' and that has the compiled copy
> alongside 
> the source. The compilation step takes a *long* time on my hardware, 
> which is fairly painful when I want to hack on Guix.
> 
> I do have my Guix checkout in geiser-guile-load-path in my emacs
> config 
> as per 
> https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html:
> 
> (with-eval-after-load 'geiser-guile
>   (add-to-list 'geiser-guile-load-path "~/sources/guix"))
> 
> My guess is that Guile is picking up my system's version of Guix
> before 
> my local copy. I understand that I could start a version of Emacs in
> a 
> pure ad-hoc environment (and Guile doesn't appear to start
> recompiling 
> Guix when I do so), but the typical Emacs workflow is to have a 
> long-running Emacs session and use that for everything; that's what
> I'm 
> used to, and I'd like to continue to do so if possible.
> 
> Does anyone else experience this? What's the best way to use Geiser
> to 
> hack on Guix when running Guix System?
> 
> 
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-26  0:05 ` divoplade
@ 2020-05-26  2:32   ` Jonathan Frederickson
  2020-05-26  6:18     ` divoplade
  0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Frederickson @ 2020-05-26  2:32 UTC (permalink / raw)
  To: divoplade; +Cc: help-guix

Ah! Thanks for the hint about the version of Guile.

Turns out it was actually the other way around; I had built Guix with 
Guile 3 but still had Guile 2.2 in my profile. This explains why an 
ad-hoc environment with Guile worked just fine, but Guile in my normal 
profile did not. (Looks like Guix gained support for Guile 3 prior to 
version 1.1.0: https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/)

On Tue, May 26, 2020 at 2:05 am, divoplade <d@divoplade.fr> wrote:
> Hello,
> 
> I think that guix does not support guile 3 yet, so you should have
> guile 2 bytecode for the guix modules. If geiser starts guile 3, then
> guile 3 will recompile everything because the bytecode format changed
> (and it could even compile native code).
> 
> Maybe it could work if you used guile 2.2 with geiser.
> 
> divoplade
> 
> Le lundi 25 mai 2020 à 19:02 -0400, Jonathan Frederickson a écrit :
>>  I've been using Geiser to hack on Guix lately, which is absolutely
>>  wonderful to use when it works. The trouble is, after I upgrade my
>>  system's Guix, Guile attempts to compile large portions of Guix when
>>  I
>>  attempt to switch to the module I'm working on in Geiser, e.g.:
>> 
>>  M-x run-guile
>>  ,m (gnu services games)
>> 
>>  This despite the fact that I'm working on a copy of Guix that I've
>>  already compiled with 'make' and that has the compiled copy
>>  alongside
>>  the source. The compilation step takes a *long* time on my hardware,
>>  which is fairly painful when I want to hack on Guix.
>> 
>>  I do have my Guix checkout in geiser-guile-load-path in my emacs
>>  config
>>  as per
>>  https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html:
>> 
>>  (with-eval-after-load 'geiser-guile
>>    (add-to-list 'geiser-guile-load-path "~/sources/guix"))
>> 
>>  My guess is that Guile is picking up my system's version of Guix
>>  before
>>  my local copy. I understand that I could start a version of Emacs in
>>  a
>>  pure ad-hoc environment (and Guile doesn't appear to start
>>  recompiling
>>  Guix when I do so), but the typical Emacs workflow is to have a
>>  long-running Emacs session and use that for everything; that's what
>>  I'm
>>  used to, and I'd like to continue to do so if possible.
>> 
>>  Does anyone else experience this? What's the best way to use Geiser
>>  to
>>  hack on Guix when running Guix System?
>> 
>> 
>> 
> 




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-26  2:32   ` Jonathan Frederickson
@ 2020-05-26  6:18     ` divoplade
  0 siblings, 0 replies; 7+ messages in thread
From: divoplade @ 2020-05-26  6:18 UTC (permalink / raw)
  To: Jonathan Frederickson; +Cc: help-guix

Hello,

Le lundi 25 mai 2020 à 22:32 -0400, Jonathan Frederickson a écrit :
> Ah! Thanks for the hint about the version of Guile.
> 
> Turns out it was actually the other way around; I had built Guix
> with 
> Guile 3 but still had Guile 2.2 in my profile. This explains why an 
> ad-hoc environment with Guile worked just fine, but Guile in my
> normal 
> profile did not. (Looks like Guix gained support for Guile 3 prior
> to 
> version 1.1.0: 
> https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/)

I am glad this helped even if I was 100% wrong!

> 
> On Tue, May 26, 2020 at 2:05 am, divoplade <d@divoplade.fr> wrote:
> > Hello,
> > 
> > I think that guix does not support guile 3 yet, so you should have
> > guile 2 bytecode for the guix modules. If geiser starts guile 3,
> > then
> > guile 3 will recompile everything because the bytecode format
> > changed
> > (and it could even compile native code).
> > 
> > Maybe it could work if you used guile 2.2 with geiser.
> > 
> > divoplade
> > 
> > Le lundi 25 mai 2020 à 19:02 -0400, Jonathan Frederickson a écrit :
> > >  I've been using Geiser to hack on Guix lately, which is
> > > absolutely
> > >  wonderful to use when it works. The trouble is, after I upgrade
> > > my
> > >  system's Guix, Guile attempts to compile large portions of Guix
> > > when
> > >  I
> > >  attempt to switch to the module I'm working on in Geiser, e.g.:
> > > 
> > >  M-x run-guile
> > >  ,m (gnu services games)
> > > 
> > >  This despite the fact that I'm working on a copy of Guix that
> > > I've
> > >  already compiled with 'make' and that has the compiled copy
> > >  alongside
> > >  the source. The compilation step takes a *long* time on my
> > > hardware,
> > >  which is fairly painful when I want to hack on Guix.
> > > 
> > >  I do have my Guix checkout in geiser-guile-load-path in my emacs
> > >  config
> > >  as per
> > >  https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html:
> > > 
> > >  (with-eval-after-load 'geiser-guile
> > >    (add-to-list 'geiser-guile-load-path "~/sources/guix"))
> > > 
> > >  My guess is that Guile is picking up my system's version of Guix
> > >  before
> > >  my local copy. I understand that I could start a version of
> > > Emacs in
> > >  a
> > >  pure ad-hoc environment (and Guile doesn't appear to start
> > >  recompiling
> > >  Guix when I do so), but the typical Emacs workflow is to have a
> > >  long-running Emacs session and use that for everything; that's
> > > what
> > >  I'm
> > >  used to, and I'd like to continue to do so if possible.
> > > 
> > >  Does anyone else experience this? What's the best way to use
> > > Geiser
> > >  to
> > >  hack on Guix when running Guix System?
> > > 
> > > 
> > > 
> 
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-25 23:02 Geiser and Guix - how to avoid long compilation steps? Jonathan Frederickson
  2020-05-26  0:05 ` divoplade
@ 2020-05-26  7:45 ` Pierre Neidhardt
  2020-05-26 21:19   ` Ludovic Courtès
  1 sibling, 1 reply; 7+ messages in thread
From: Pierre Neidhardt @ 2020-05-26  7:45 UTC (permalink / raw)
  To: Jonathan Frederickson, help-guix

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

Jonathan Frederickson <jonathan@terracrypt.net> writes:

> This despite the fact that I'm working on a copy of Guix that I've 
> already compiled with 'make' and that has the compiled copy alongside 
> the source.

This has been a source of headaches for me too.  I like to run Geiser
to hack my Guix checkout.  But if I forget to compile a (big) scheme
file, geiser will grind to a halt when switching to a module that
depends on the uncompiled file.

Something weird: If I repeat the module switch, Geiser still takes ages
to do it, as if it didn't persist the .go files (normally in
~/.cache/guile/ccache?)

In my understanding, the solution here is to run `guix environment
guix -- make` all the time.

Maybe I'll add an override for geiser-mode-switch-to-repl-and-enter that
compiles Guix automatically.

Any other tip?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-26  7:45 ` Pierre Neidhardt
@ 2020-05-26 21:19   ` Ludovic Courtès
  2020-05-27  9:37     ` Pierre Neidhardt
  0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2020-05-26 21:19 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: help-guix

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> This has been a source of headaches for me too.  I like to run Geiser
> to hack my Guix checkout.  But if I forget to compile a (big) scheme
> file, geiser will grind to a halt when switching to a module that
> depends on the uncompiled file.
>
> Something weird: If I repeat the module switch, Geiser still takes ages
> to do it, as if it didn't persist the .go files (normally in
> ~/.cache/guile/ccache?)
>
> In my understanding, the solution here is to run `guix environment
> guix -- make` all the time.
>
> Maybe I'll add an override for geiser-mode-switch-to-repl-and-enter that
> compiles Guix automatically.
>
> Any other tip?

I run “make” before starting the REPL to avoid the problem you mention
(bah!), but from there on I can happily hack on my stuff.

A little-known feature of Emacs-Guix is C-c . u (guix-devel-use-module),
which allows you to load a module without compiling it with C-c C-k.
It’s fast and non-intrusive, unlike C-c C-k.

Ludo’.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Geiser and Guix - how to avoid long compilation steps?
  2020-05-26 21:19   ` Ludovic Courtès
@ 2020-05-27  9:37     ` Pierre Neidhardt
  0 siblings, 0 replies; 7+ messages in thread
From: Pierre Neidhardt @ 2020-05-27  9:37 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: help-guix

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> A little-known feature of Emacs-Guix is C-c . u (guix-devel-use-module),
> which allows you to load a module without compiling it with C-c C-k.
> It’s fast and non-intrusive, unlike C-c C-k.

Thanks for the tip.
Although recently I've found Emacs-Guix increasingly unusable with many
features reporting errors
(e.g. package completion).

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-05-27  9:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-25 23:02 Geiser and Guix - how to avoid long compilation steps? Jonathan Frederickson
2020-05-26  0:05 ` divoplade
2020-05-26  2:32   ` Jonathan Frederickson
2020-05-26  6:18     ` divoplade
2020-05-26  7:45 ` Pierre Neidhardt
2020-05-26 21:19   ` Ludovic Courtès
2020-05-27  9:37     ` Pierre Neidhardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).