Can't compile

Can't compile

[Xavier Maillard]

Hi,

I am trying to byte-compile nero.el[1] but it just fails with
this error:

In nero-restore-match:
nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
    22.1); use `string-to-number' instead.
nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
make: *** [nero.elc] Error 1

The first warning is easy to fix (and I fixed it) but what about
the second error ?

nero-follow-numbers is a (defined) function used in a macro.

Here is the defun:

(defun nero-follow-numbers (lis handler)
  "Used by `nero-defjump' to add a nested list of actions.
Each action corresponds to following a given numbered link in LIS.
The last link in the list is followed using HANDLER."
  (let (ret)
    (nero-recursively-add-number-actions (reverse lis) handler ret)))

And the macro:

(defmacro nero-defjump (name baseurl 
                             &optional handler run-after-load 
                             &rest numbers)
  "Create a jump to be used with nero.
Nero jumps are like bookmarks or \"webjumps\", but they can
do a bit more.  The most basic nero jump is essentially just
a bookmark.

The reason you might want more is that sometimes urls change, you
know a consistent way to find them, starting from some
\"landmark\".  You don't want to redefine your bookmark every
time the url changes, but you don't want to physically go through
the process of browsing to the final url either.  What to do?
This macro takes the approach of having nero do the browsing for
you.

NAME is how you might refer to this jump in prose.  BASEURL
is the URL to start from. NUMBERS, if present, indicate the
numbered links to follow, in order.

A function called \"nero-jump-to-\" NAME (suitably marked up)
will be created when this macro runs.

HANDLER can be used to specify alternative instructions on how to
load the final page accessed by the jump.  For one example,
see `nero-oddmuse-recent-changes-handler'."
  (declare (indent defun))
  `(add-to-list 
    'nero-jumps
    (cons ,name 
          (defun ,(intern
                   (concat "nero-jump-to-"
                           (downcase
                            (replace-regexp-in-string
                             " " "-" name))))
            (&optional insert)
            (interactive "P")
            (if insert
                (insert ,baseurl)
              (nero-browse-url 
               ,baseurl
               nil
               ;; this is last,
               ;; use the handler 
               (unless 
                   ,(car numbers)
                 ,handler)
               nil 
               ;; the action we take once the page has loaded
               ;; (typically involves following numbered links)
               ,(nero-follow-numbers numbers handler)
               ;; the first page is not the last page; be ephemeral
               (when ,(car numbers) t)
               ;; maybe revise, otherwise, add.
               (when ,(equal (nero-current-url) baseurl) t)))))))

I can not find a way to "silent" the byte-compiler. Can you help
?

Thank you

Footnotes: 
[1]  http://www.ma.utexas.edu/~jcorneli/a/elisp/nero.el

Re: Can't compile

[Peter Dyballa]

Am 24.02.2007 um 11:28 schrieb Xavier Maillard:

> nero.el:2119:1:Error: Symbol's function definition is void: nero- 
> follow-numbers

I think there is one argument too much in the "Musical Letters" ...

--
Mit friedvollen Grüßen

   Pete

With Capitalism man exploits man. With communism it's the exact  
opposite.

Re: Can't compile

[Xavier Maillard]

Hi,

Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> Am 24.02.2007 um 11:28 schrieb Xavier Maillard:
> 
> > nero.el:2119:1:Error: Symbol's function definition is void: nero- 
> > follow-numbers
> 
> I think there is one argument too much in the "Musical Letters" ...

Yep but it is not the error reported when byte-compiling. I fixed
the "Musical Letters" entry but it still reports a void function
definition.

Xavier

Re: Can't compile

[Peter Dyballa]

Am 25.02.2007 um 09:08 schrieb Xavier Maillard:

> Peter Dyballa wrote:
>
>> Am 24.02.2007 um 11:28 schrieb Xavier Maillard:
>>
>>> nero.el:2119:1:Error: Symbol's function definition is void: nero-
>>> follow-numbers
>>
>> I think there is one argument too much in the "Musical Letters" ...
>
> Yep but it is not the error reported when byte-compiling. I fixed
> the "Musical Letters" entry but it still reports a void function
> definition.
>

The error must be in nero-defjump then, but I don't understand enough  
of Emacs Lisp to be able to find it. Could be the way the function is  
used is inappropriate ...

--
Greetings

   Pete

The human animal differs from the lesser primates in his passion for  
lists of "Ten Best".
                                      -- H. Allen Smith

Re: Can't compile

[Xavier Maillard]

Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> The error must be in nero-defjump then, but I don't understand enough
> of Emacs Lisp to be able to find it. Could be the way the function is
> used is inappropriate ...

Sure it has to be with the way it is called. I emailed Joe to ask
him but as of today, I did not receive any answer from him.

Xavier

Re: Can't compile

[Joost Kremers]

Xavier Maillard wrote:
> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> make: *** [nero.elc] Error 1
[...]
> nero-follow-numbers is a (defined) function used in a macro.

i had the same problem recently with XEmacs (a defun used in a macro
defined in the same file). i solved it by wrapping the defun in an
eval-and-compile. so you could try:

(eval-and-compile
  (defun nero-follow-numbers (lis handler)
    "Used by `nero-defjump' to add a nested list of actions.
  Each action corresponds to following a given numbered link in LIS.
  The last link in the list is followed using HANDLER."
    (let (ret)
      (nero-recursively-add-number-actions (reverse lis) handler ret))))

no idea if this is the proper way to handle it, but it worked.

the same code compiled without problems on GNU/Emacs 22.0.91.1 (without the
eval-and-compile, i mean). i'm not really sure what the story is there...


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Can't compile

[Xavier Maillard]

Joost Kremers <joostkremers@yahoo.com> wrote:

> Xavier Maillard wrote:
> > nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> > make: *** [nero.elc] Error 1
> [...]
> > nero-follow-numbers is a (defined) function used in a macro.
> 
> i had the same problem recently with XEmacs (a defun used in a macro
> defined in the same file). i solved it by wrapping the defun in an
> eval-and-compile. so you could try:

[SNIP]

> the same code compiled without problems on GNU/Emacs 22.0.91.1 (without the
> eval-and-compile, i mean). i'm not really sure what the story is there...

Weird since it did not compiler with emacs22 and emacs21 (21.2 to
21.4). I tried with emacs22.0.51 and it failed miserably.

I am pretty lost here. Could it be a bug into Emacs itself ?

Xavier

Re: Can't compile

[Joost Kremers]

Xavier Maillard wrote:
> Weird since it did not compiler with emacs22 and emacs21 (21.2 to
> 21.4). I tried with emacs22.0.51 and it failed miserably.

did the eval-and-compile work?

> I am pretty lost here. Could it be a bug into Emacs itself ?

it's not a bug in emacs, it's a think-o on my part... the code compiled
fine in my running instance of Emacs, because while developing that code,
and had manually compiled/eval'ed the relevant defun. then when i
byte-compiled the entire file, the defun was known, and Emacs did not
complain.

i just quit Emacs completely and reloaded the relevant file, got rid of the
eval-and-compile and byte-compiled the file. now, Emacs complains in the
same way as XEmacs did before.


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Can't compile

[Xavier Maillard]

Joost Kremers <joostkremers@yahoo.com> wrote:

> Xavier Maillard wrote:
> > Weird since it did not compiler with emacs22 and emacs21 (21.2 to
> > 21.4). I tried with emacs22.0.51 and it failed miserably.
> 
> did the eval-and-compile work?

Yes and no. Yes it worked after having added several eval-when
forms but no, I am really not satisfied by this solution.

I would like to know why it solely happens with this defmacro :)
 
> > I am pretty lost here. Could it be a bug into Emacs itself ?
> 
> it's not a bug in emacs, it's a think-o on my part... the code compiled
> fine in my running instance of Emacs, because while developing that code,
> and had manually compiled/eval'ed the relevant defun. then when i
> byte-compiled the entire file, the defun was known, and Emacs did not
> complain.
> 
> i just quit Emacs completely and reloaded the relevant file, got rid of the
> eval-and-compile and byte-compiled the file. now, Emacs complains in the
> same way as XEmacs did before.

I am using a Makefile to byte-compile and thus I am using -q -Q
as my command line switches.

Xavier

Re: Can't compile

[Robert Thorpe]

On Feb 24, 10:28 am, Xavier Maillard <z...@gnu.org> wrote:
> Hi,
>
> I am trying to byte-compile nero.el[1] but it just fails with
> this error:
>
> In nero-restore-match:
> nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
>     22.1); use `string-to-number' instead.
> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> make: *** [nero.elc] Error 1
>
> The first warning is easy to fix (and I fixed it) but what about
> the second error ?

I don't know anything about this code, but what is shown here is a
rather common lisp error.

The function nero-follow-numbers is used in a macro.  This macro is
used in the file/compilation block nero.elc.
The bytecompiler works on a per file basis.  It compiles each of the
defuns to bytecodes completing it's actions once the file is
finished.  Macros though must be expanded when the code is being read,
at this stage the defuns in the file have not yet been finalised.

This works fine for the normal evalutator because it finalises and
installs a function at the end of the defun form.

This is why "eval-and-compile" is needed.

Re: Can't compile

[Xavier Maillard]

Robert Thorpe <rthorpe@realworldtech.com> wrote:

> This is why "eval-and-compile" is needed.

This is a neat explanation Robert. Thank you very much.

Problem with this code is that even with a "eval-and-compile"
there are several other places where I have to add this clause or
the "eval-when-compile" form. That's why it is sucky ;)

Xavier

Re: Can't compile

[Robert Thorpe]

On Feb 26, 6:31 pm, Xavier Maillard <z...@gnu.org> wrote:
> Robert Thorpe <rtho...@realworldtech.com> wrote:
> > This is why "eval-and-compile" is needed.
>
> This is a neat explanation Robert. Thank you very much.

I hope it's correct.

> Problem with this code is that even with a "eval-and-compile"
> there are several other places where I have to add this clause or
> the "eval-when-compile" form. That's why it is sucky ;)

Yes.  Have a look at how some other modes deal with it, often you can
get away with only a few mentions of eval-when-compile or eval-and-
compile. One way to do it is to put all the functions used in macros
into a separate file and then load that file inside eval-when-compile.

Re: Can't compile

[Xavier Maillard]

Robert Thorpe <rthorpe@realworldtech.com> wrote:

> > Problem with this code is that even with a "eval-and-compile"
> > there are several other places where I have to add this clause or
> > the "eval-when-compile" form. That's why it is sucky ;)
> 
> Yes.  Have a look at how some other modes deal with it, often you can
> get away with only a few mentions of eval-when-compile or eval-and-
> compile. One way to do it is to put all the functions used in macros
> into a separate file and then load that file inside eval-when-compile.

That's an idea but this is not my code :) I can only make changes
onto my local copy. I hope Joe will see this discussion or even
better, answer to my application to maintain this code ;)

Once again, thank you.

Xavier

Re: Can't compile

[Kevin Rodgers]

Robert Thorpe wrote:
> On Feb 24, 10:28 am, Xavier Maillard <z...@gnu.org> wrote:
>> Hi,
>>
>> I am trying to byte-compile nero.el[1] but it just fails with
>> this error:
>>
>> In nero-restore-match:
>> nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
>>     22.1); use `string-to-number' instead.
>> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
>> make: *** [nero.elc] Error 1
>>
>> The first warning is easy to fix (and I fixed it) but what about
>> the second error ?
> 
> I don't know anything about this code, but what is shown here is a
> rather common lisp error.
> 
> The function nero-follow-numbers is used in a macro.  This macro is
> used in the file/compilation block nero.elc.
> The bytecompiler works on a per file basis.  It compiles each of the
> defuns to bytecodes completing it's actions once the file is
> finished.  Macros though must be expanded when the code is being read,
> at this stage the defuns in the file have not yet been finalised.
> 
> This works fine for the normal evalutator because it finalises and
> installs a function at the end of the defun form.
> 
> This is why "eval-and-compile" is needed.

A cleaner design would be for the macro to return a form that contains a
call to the function, rather calling the function during macro expansion
to generate the returned form.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Can't compile

[Robert Thorpe]

On Feb 28, 3:16 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> Robert Thorpe wrote:
<snip>
> > I don't know anything about this code, but what is shown here is a
> > rather common lisp error.
>
> > The function nero-follow-numbers is used in a macro.  This macro is
> > used in the file/compilation block nero.elc.
> > The bytecompiler works on a per file basis.  It compiles each of the
> > defuns to bytecodes completing it's actions once the file is
> > finished.  Macros though must be expanded when the code is being read,
> > at this stage the defuns in the file have not yet been finalised.
>
> > This works fine for the normal evalutator because it finalises and
> > installs a function at the end of the defun form.
>
> > This is why "eval-and-compile" is needed.
>
> A cleaner design would be for the macro to return a form that contains a
> call to the function, rather calling the function during macro expansion
> to generate the returned form.

Yes, but that depends on what the function does, if it does a
significant amount of computation then running it only at
macroexpansion time will make the program faster.

Re: Can't compile

[Xavier Maillard]

Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

> > This is why "eval-and-compile" is needed.
> 
> A cleaner design would be for the macro to return a form that contains a
> call to the function, rather calling the function during macro expansion
> to generate the returned form.

Do you mean a funcall call ?

Xavier