all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: Stefan Huchler <stefan.huchler@mail.de>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Strange eval behaviour
Date: Fri, 18 Nov 2016 03:38:25 +0100	[thread overview]
Message-ID: <878tshjyvy.fsf@web.de> (raw)
In-Reply-To: <878tsl1p7b.fsf@mail.de> (Stefan Huchler's message of "Tue, 15 Nov 2016 02:55:52 +0100")

Stefan Huchler <stefan.huchler@mail.de> writes:

> Normaly it should through a error if it cant find a macro/function
> that is not availible right?

In case of a macro, it depends on whether the macro is defined when
compiling.  So you don't get a warning necessarily.  To avoid missing
dependencies, it's helpful to compile from a separate emacs instance
(emacs -Q).

> that was the code I did not have
> (require 'let-alist)

That was one problem, at least.

> in the file?

> Again thanks so far so I can release that code soon, but again I would
> like to understand what the problem was.

AFAIR, you had a strange handling of variables in your code: some
functions had used free variables that were declared nowhere.  Compiling
is a good way to reveal such problems.

> Do I have to have a byte-compiled .elc file if I use the "function"
> macro

No.

> oh wait its the function* which is a alias to the cl-function macro in
> cl-macs
>
> so I need the cl library imported too.

Yes.  It is now more or less consent now that the cl library should not
be loaded at run-time.  Please use cl-lib and the according cl- prefixed
functions instead.

> But well thats more relevant for packaging I think, I think the main
> problem was that there just was no .elc file?

No, Stefan suggested to compile so that you get warnings that help you
find the problems in your code.  Compiling is not required to run code.
Compiled code is just running faster, and the compiler produces
excellent warnings.


Michael.



  reply	other threads:[~2016-11-18  2:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-13 21:28 Strange eval behaviour Stefan Huchler
2016-11-14 15:04 ` Stefan Monnier
2016-11-15  1:55   ` Stefan Huchler
2016-11-18  2:38     ` Michael Heerdegen [this message]
2016-11-18 16:51       ` Stefan Huchler
2016-11-18 23:19         ` Michael Heerdegen
2016-11-22 23:57           ` Stefan Huchler
2016-11-23  9:19             ` Michael Heerdegen
2016-11-23 14:20               ` Stefan Huchler
2016-11-18 17:00       ` Stefan Huchler
2016-11-18 23:35         ` Michael Heerdegen
2016-11-22 14:43           ` Stefan Huchler
2016-11-27  4:25           ` Stefan Huchler
2016-11-27  4:29           ` Stefan Huchler

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

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

  git send-email \
    --in-reply-to=878tshjyvy.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=help-gnu-emacs@gnu.org \
    --cc=stefan.huchler@mail.de \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.