GNU bug report logs - #33598
Optimizations for emacs-clang-format and emacs-clang-rename

Previous Next

Full log

Message #14 received at 33598 <at> debbugs.gnu.org (full text, mbox):

From: Tim Gesthuizen <tim.gesthuizen <at> yahoo.de>
To: Pierre Neidhardt <mail <at> ambrevar.xyz>, Ludovic Courtès
 <ludo <at> gnu.org>
Cc: 33598 <at> debbugs.gnu.org
Subject: Re: [bug#33598] Optimizations for emacs-clang-format and
 emacs-clang-rename
Date: Fri, 14 Dec 2018 11:06:21 +0100

[Message part 1 (text/plain, inline)]

Hi,

On 14.12.2018 10:23, Pierre Neidhardt wrote:
> In your implementation, you've essentially moved the 'configure phase to a
> snippet.  As I understand it, this does not change anything.  What is your
> reason for doing this?

1. Intention: Stripping the source with the snippet models more clearly
   that the building part is a function that maps the single elisp file
   to the final package.

> You are also deleting all non-required files.  Which saves some space in /tmp
> indeed, but this won't change anything to the store or the resulting
> substitutes, right?  I don't mind this change, I just want to be clear about
> what we are trying to achieve here :)

2. Efficiency: I am not quite sure about this - maybe I am just wrong:
   As far as I understand it at first guix builds a source derivation
   and then the actual package derivation. Even when the source
   derivation is not stored in the store it can be substituted. If this
   is the case we can save some bandwith / disk space / build time by
   moving the file stripping to the source snippet. On my machine the
   most time during the build process is spend unpacking the clang
   source.

> Last, the factorization into package-from-clang-elisp-file: this is a good idea,
> and I would make it even more generic.  Simply rename your function
> 
> 	package-elisp-from-package
> 
> (or something like that) and make "clang" a parameter.  Then we can use this
> function in other packages like emacs-agda2-mode.

I also thought about this but could not find another situation where
this was applicable.
In which module should such a function go?
What would definitely be nice is that such a function can encapsulate
the emacs stuff so that we do not need any other emacs related modules
imported in (gnu packages llvm) for example.

> Am I making sense?  What do you think?

Yes. Maybe we should add some reasoning to the commit message then?
Depends on whether we just want a description of the changes in a commit
message or also some reasoning if things might be unclear.
I think that package-elisp-from-package is a really good idea.
Without seeing the function definition it is really hard to figure out
why it needs the arguments it needs and what their purposes are.
Maybe we want to make the arguments keyword arguments if it becomes more
generic so its usage is more intuitive.
The first two patches are debatable though. If there is a particular
reason against them (unnecessary changing without benefits included) we
might want to not merge them.

Tim.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.