Hi Liliana,
On Tue, 25 Oct 2022 at 20:31, Liliana Marie Prikler
wrote:
>
> Warning (comp): /gnu/store/hjciw32mj05yz1m6r6nzwdi12waz81ni-emacs-next-
> 29.0.50-2.4aeb80c/share/emacs/29.0.50/lisp/emacs-lisp/cl-
> loaddefs.el.gz: Error: error Uncompression program `sh' not found
I have reported
Am Dienstag, dem 25.10.2022 um 19:23 +0300 schrieb Max Brieiev:
> Liliana Marie Prikler writes:
>
> > Ehm, yes... best to keep this open until I can bump to a version
> > that's
> > approved and solves the problem.
>
> Do the recent changes suppose to fix the issue?
>
> Today I did:
>
>
Liliana Marie Prikler writes:
> Ehm, yes... best to keep this open until I can bump to a version that's
> approved and solves the problem.
Do the recent changes suppose to fix the issue?
Today I did:
guix pull
sudo guix system reconfigure /etc/system-config.scm
guix package -u
Am Samstag, dem 15.10.2022 um 17:40 +0200 schrieb zimoun:
> Just to be sure, do you mean an emacs-next version which includes the
> upstream Lars’s patches? The ones that Eli and Andrea are calling to
> be reverted?
>
> --8<---cut here---start->8---
> Sorry as
Hi Liliana,
On Sat, 15 Oct 2022 at 16:40, Liliana Marie Prikler
wrote:
> Done. Since I just copypasta'd the wording, I made you the author.
Oh, thanks. (It was the news’ wording. :-))
> As for this bug: I've bumped emacs-next to a version that can inhibit
> almost all native-compilation
Am Samstag, dem 15.10.2022 um 12:11 +0200 schrieb zimoun:
> Hi Liliana,
>
> On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler
> wrote:
>
> > > Maybe it could be worth to have that in the manual too, no? For
> > > example, under ’Application setup, Emacs packages’ [1].
> > >
> > Would you
Hi Liliana,
On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler
wrote:
>> Maybe it could be worth to have that in the manual too, no? For
>> example, under ’Application setup, Emacs packages’ [1].
>>
> Would you prefer a paragraph, a note, or a footnote?
As you would prefer. Maybe a note
Am Freitag, dem 14.10.2022 um 18:07 +0200 schrieb zimoun:
> Hi Liliana,
>
> Maybe it could be worth to have that in the manual too, no? For
> example, under ’Application setup, Emacs packages’ [1].
Would you prefer a paragraph, a note, or a footnote?
Hi Liliana,
On mer., 12 oct. 2022 at 21:42, Liliana Marie Prikler
wrote:
> In Guix, this is more or less a user choice – we advertised the
> transformation by which you can opt-in to AOT compilation in a news
> entry. Also, enforcing ahead-of-time compilation does not fix the more
> pressing
I am new to Guix.
My issue is related to the native compilation too, however it manifests
itself differently.
The build of emacs-next goes well.
However, when I start Emacs it throws lots of errors, most of which are
like this:
Deleting /tmp/comp-lambda-RCGJQI.eln
comp--native-compile:
Liliana Marie Prikler writes:
> From personal experience, no. Even if you compile code ahead of time,
> there seem to be some leftovers that are deferred. guix-emacs.el is an
> oversight, but apart from that I also other leftovers (possibly from
> init.el?)
AFAIU, the compiler is invoked any
Am Donnerstag, dem 13.10.2022 um 12:31 +0300 schrieb Max Brieiev:
> > I think this reasoning really falls flat in presence of any non-
> > Emacs package manager. Like, obviously wanting to natively compile
> > packages managed by (dpkg, rpm, pacman, emerge, guix), but not
> > natively compiling a
Am Sonntag, dem 02.10.2022 um 10:25 +0200 schrieb Konrad Hinsen:
> As for Liliana's idea of disabling deferred compilation : shouldn't
> it be sufficient to have all Emacs Lisp packages in Guix AOT-
> compiled?
>From personal experience, no. Even if you compile code ahead of time,
there seem to
Hi,
On Sat, 01 Oct 2022 at 20:15, "Thompson, David"
wrote:
> I am leaning towards this being an upstream
> issue as it is also affecting Debian users [0]. Unfortunately, they
> do not seem to have found a solution. I haven't checked the Emacs bug
> tracker/mailing lists
Hi David and Liliana,
Thanks David for the added observations. This does indeed look like an
upstream bug, but it also seems to have a context dependence because the
Debian bug reports list some packages are affected that cause no problem
under Guix (e.g. git-timemachine).
As for Liliana's idea
Am Samstag, dem 01.10.2022 um 20:15 -0400 schrieb Thompson, David:
> Is disabling native compilation an option on the table?
I don't want to disable native compilation for everyone, but I'd very
much disable deferred compilation and replace it with Guix packages.
In other words, as long as your
Hello Konrad and Liliana,
On Mon, Sep 19, 2022 at 5:16 AM Konrad Hinsen
wrote:
>
> I did one more test: run native-compile by hand on each elisp file in
> the package ido-completing-read+. Works fine.
>
> The next question that I consider relevant: is this an upstream (Emacs)
> issue, or an
I did one more test: run native-compile by hand on each elisp file in
the package ido-completing-read+. Works fine.
The next question that I consider relevant: is this an upstream (Emacs)
issue, or an issue created by packaging in Guix? That's not easy to
answer.
A related question: what are
Liliana Marie Prikler writes:
>> I think you can prevent native-compilation entirely by setting no-
>> native-compile to t in your early-init.el (I'm playing with the idea
>> of doing this anyway, because I'm annoyed by the clutter that falls
>> through the cracks).
>
> Okay, it turns out that
Am Sonntag, dem 18.09.2022 um 01:19 +0200 schrieb Liliana Marie
Prikler:
> I think you can prevent native-compilation entirely by setting no-
> native-compile to t in your early-init.el (I'm playing with the idea
> of doing this anyway, because I'm annoyed by the clutter that falls
> through the
Am Samstag, dem 17.09.2022 um 17:45 +0200 schrieb Konrad Hinsen:
> Konrad Hinsen writes:
>
> > Here is a minimal containerized example that
> > creates a process avalanche:
> >
> > guix shell -C emacs emacs-ido-completing-read+ \
> > -- emacs --batch --eval="(print load-path)"
>
> I
Konrad Hinsen writes:
> Here is a minimal containerized example that
> creates a process avalanche:
>
> guix shell -C emacs emacs-ido-completing-read+ \
>-- emacs --batch --eval="(print load-path)"
I went through all my emacs packages. The only one that starts
the process avalanche
My understanding of site-start.el is that it actually loads all the
Emacs packages that are listed in my Guix profile. Which means that my
package list matters. Here is a minimal containerized example that
creates a process avalanche:
guix shell -C emacs emacs-ido-completing-read+ \
--
23 matches
Mail list logo
