unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Suhail <suhail@bayesians.ca>
Cc: cox.katherine.e+guix@gmail.com, 67260@debbugs.gnu.org, andrew@trop.in
Subject: [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.
Date: Sat, 27 Jan 2024 17:50:02 +0100	[thread overview]
Message-ID: <070e018eb1d848cf296791672ffa6499995ffef3.camel@gmail.com> (raw)
In-Reply-To: <65b522ef.050a0220.6e48b.a677SMTPIN_ADDED_BROKEN@mx.google.com>

Am Samstag, dem 27.01.2024 um 15:36 +0000 schrieb Suhail:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> […]
> For emacs-htmlize, I believe the issue may stem from the fact that
> some .eln files are available from entries in native-comp-eln-load-
> path only via symlinks and the .eln loader may not be able to load
> symlinks.  
Would you care to debug this a bit more and report your findings?

> Packages such as ox-html are available from two locations in the
> native-comp-eln-load-path.  In one location they are symlinked, but
> (presumably because org is a builtin package) it is also available
> from another location in the native-comp-eln-load-path and in the
> latter location it's not symlinked in.  I believe this difference is
> why for some packages natively-compiled versions are loaded (e.g.
> org, ox-html, etc) whereas for others it's not the case.
Well, as pointed out in the deleted code, dlopen has a "one shared
library per file name" limitation.  I don't think we're hit by that
thanks to unique hashes in the store directory, but I might be wrong
about that.  Maybe we have to do java-style FQDNs instead.

> In addition, I believe there's another issue.  Some packages' names
> are getting  truncated.  For instance, instead of uniquify.eln, I
> observe niquify.eln.  In this case, the .eln isn't symlinked
> (presumably because it's a builtin), but due to the name being messed
> up (perhaps too aggressive a truncation of hashes?) the natively
> compiled version is not available:
I am not truncating any hashes, I'm not even computing them in the
first place.  The functions I'm modifying are publicly callable, namely
comp-el-to-eln-rel-filename for the relative file names, and
comp-el-to-eln-filename for the absolute ones.

There could be an off-by-one error hidden in the stripping of the
BOGUS_DIRS, however.  Let's investigate that.

> > uniquify-item-p is a byte-compiled Lisp function in `uniquify.el'.
> 
> The manifest file that was used is below.
> 
> #+begin_src scheme
>   (use-modules (guix transformations)
>                (gnu packages))
> 
>   (define transform1
>     (options->transformation
>      '((with-input . "emacs-minimal=emacs")
>        (without-tests . "emacs-clojure-mode"))))
> 
>   (packages->manifest
>     (list (transform1 (specification->package "bash"))
>           (transform1 (specification->package "coreutils"))
>           (transform1 (specification->package "git"))
>           (transform1 (specification->package "make"))
>           (transform1 (specification->package "emacs"))
>           (transform1 (specification->package "emacs-org"))
>           (transform1
>             (specification->package "emacs-org-contrib"))
>           (transform1
>             (specification->package "emacs-citeproc-el"))
>           (transform1
>             (specification->package "emacs-engrave-faces"))
>           (transform1
>             (specification->package "emacs-haskell-mode"))
>           (transform1
>             (specification->package "emacs-htmlize"))
>           (transform1
>             (specification->package "emacs-markdown-mode"))
>           (transform1
>             (specification->package
>               "emacs-org-pandoc-import"))
>           (transform1 (specification->package "pandoc"))
>           ))
> #+end_src
Note, that you can map transform1, saving some typing overhead, and
since you are transforming all of your packages you could compose that
with specification->package.

Cheers




       reply	other threads:[~2024-01-27 16:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <65b522ef.050a0220.6e48b.a677SMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-27 16:50 ` Liliana Marie Prikler [this message]
     [not found] <65b67e33.df0a0220.72d31.84b1SMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-28 16:50 ` [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH Liliana Marie Prikler
     [not found] <65b59c2b.5d0a0220.2cacf.b39dSMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-28  9:51 ` Liliana Marie Prikler
     [not found] <65b55c1c.050a0220.a79c1.cfa9SMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-27 20:11 ` Liliana Marie Prikler
     [not found] <65b53a59.df0a0220.d6f27.b59bSMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-27 17:54 ` Liliana Marie Prikler
     [not found] <65b4362c.050a0220.0774.bd29SMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-27  7:00 ` Liliana Marie Prikler
     [not found] <65b36b7a.5d0a0220.f1ff5.fe0cSMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-26 16:10 ` Liliana Marie Prikler
     [not found] <65b2f485.050a0220.f377c.aa8fSMTPIN_ADDED_BROKEN@mx.google.com>
2024-01-26  5:29 ` Liliana Marie Prikler
2023-11-18 13:42 [bug#67260] [PATCH emacs-team 0/2] Think ahead when compiling Liliana Marie Prikler
2024-01-22 20:21 ` [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH Liliana Marie Prikler
2024-01-25 23:53 ` Suhail via Guix-patches via
2024-01-26  7:49 ` Suhail via Guix-patches via
2024-01-26  8:20 ` Suhail via Guix-patches via
2024-01-26 22:45 ` Suhail via Guix-patches via
2024-01-27 15:36 ` Suhail via Guix-patches via
2024-01-27 16:24 ` Suhail via Guix-patches via
2024-01-27 17:15 ` Suhail via Guix-patches via
2024-01-27 19:39 ` Suhail via Guix-patches via
2024-01-28  0:13 ` Suhail via Guix-patches via
2024-01-28  0:18 ` Suhail via Guix-patches via
2024-01-28 16:17 ` Suhail via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=070e018eb1d848cf296791672ffa6499995ffef3.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=67260@debbugs.gnu.org \
    --cc=andrew@trop.in \
    --cc=cox.katherine.e+guix@gmail.com \
    --cc=suhail@bayesians.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).