Compilation problem

Compilation problem

[Alan Schmitt]

Hello,

I cannot compile the current version of org-mode (from git): something
fails during testing:

make test-dirty
install -m 755 -d /var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T//tmp-orgtest
TMPDIR=/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T//tmp-orgtest /Applications/Emacs.app/Contents/MacOS/Emacs -batch -Q  --eval '(add-to-list '"'"'load-path "./lisp")' --eval '(add-to-list '"'"'load-path "./testing")'  -l org-install.el -l testing/org-test.el --eval '(require '"'"'ob-awk)' --eval '(require '"'"'ob-C)' --eval '(require '"'"'ob-fortran)' --eval '(require '"'"'ob-maxima)' --eval '(require '"'"'ob-lilypond)' --eval '(require '"'"'ob-octave)' --eval '(require '"'"'ob-python)' --eval '(require '"'"'ob-sh)'  --eval '(setq org-confirm-babel-evaluate nil)' -f org-test-run-batch-tests
Symbol's function definition is void: org-export-define-backend
make[1]: *** [test-dirty] Error 255

Here is my local.mk

EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
prefix=/Users/schmitta/.emacs.d/vendor
SUDO =
ORG_ADD_CONTRIB=org-checklist org-export org-e-*
up2::

Is this a (known) bug?

Alan

Re: Compilation problem

[Achim Gratz]

Alan Schmitt writes:
> EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs

As with the problems John Hendy has: is that the actual Emacs binary or
a wrapper script?  If it is a script, it seems that it doesn't correctly
feed all the options to Emacs.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Compilation problem

[Nick Dokos]

Alan Schmitt <alan.schmitt@polytechnique.org> wrote:

> Hello,
> 
> I cannot compile the current version of org-mode (from git): something
> fails during testing:
> 
> make test-dirty
> install -m 755 -d /var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T//tmp-orgtest
> TMPDIR=/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T//tmp-orgtest /Applications/Emacs.app/Contents/MacOS/Emacs -batch -Q  --eval '(add-to-list '"'"'load-path "./lisp")' --eval '(add-to-list '"'"'load-path "./testing")'  -l org-install.el -l testing/org-test.el --eval '(require '"'"'ob-awk)' --eval '(require '"'"'ob-C)' --eval '(require '"'"'ob-fortran)' --eval '(require '"'"'ob-maxima)' --eval '(require '"'"'ob-lilypond)' --eval '(require '"'"'ob-octave)' --eval '(require '"'"'ob-python)' --eval '(require '"'"'ob-sh)'  --eval '(setq org-confirm-babel-evaluate nil)' -f org-test-run-batch-tests
> Symbol's function definition is void: org-export-define-backend
> make[1]: *** [test-dirty] Error 255
> 
> Here is my local.mk
> 
> EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
> prefix=/Users/schmitta/.emacs.d/vendor
> SUDO =
> ORG_ADD_CONTRIB=org-checklist org-export org-e-*
> up2::
> 
> Is this a (known) bug?
> 

I can reproduce this. AFAIK, it's new - I stripped down the command line above and kept
getting the error until the -l org-install.el, so it's clearly something in org-install.el.
I modified the function org-make-org-install in org-fixup.el to add

(eval-when-compile (require 'org-export))

at the top of org-install.el and that did make the error go away, but Achim has the
last word on whether that's a good solution or not (probably needs to be conditional
on ORG_ADD_CONTRIB).

Even with that, ``make test'' failed later on with

,----
| ...
| OVERVIEW
| OVERVIEW
| Symbol's function definition is void: org-id-update-id-locations
| make: *** [test] Error 255
`----

I haven't chased that one down.

Nick

Re: Compilation problem

[John Hendy]

On Mon, Sep 10, 2012 at 2:45 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> Alan Schmitt writes:
>> EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
>
> As with the problems John Hendy has: is that the actual Emacs binary or
> a wrapper script?  If it is a script, it seems that it doesn't correctly
> feed all the options to Emacs.

Just as a followup... mine appears to be the actual binary. Inspecting
C:\path\to\emacs-23.3\bin, I have:
- emacs.exe (8,753 kb)
- emacsclientw.exe (115 kb)
- runemacs.exe (82 kb)

So, I think emacs.exe, which is what I call, is the actual binary.

Per the EmacsWiki, the above appears to be the binary as well. There
are several references to
""/Applications/Emacs.app/Contents/MacOS/Emacs"
- http://emacswiki.org/emacs/EmacsApp


John

>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Samples for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
>
>

Re: Compilation problem

[Achim Gratz]

Nick Dokos writes:
> I can reproduce this. AFAIK, it's new - I stripped down the command
> line above and kept getting the error until the -l org-install.el, so
> it's clearly something in org-install.el.  I modified the function
> org-make-org-install in org-fixup.el to add

That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
don't work that way, so could this please be reverted?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Compilation problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nick Dokos writes:
>> I can reproduce this. AFAIK, it's new - I stripped down the command
>> line above and kept getting the error until the -l org-install.el, so
>> it's clearly something in org-install.el.  I modified the function
>> org-make-org-install in org-fixup.el to add
>
> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
> don't work that way, so could this please be reverted?

Done.

-- 
 Bastien

Re: Compilation problem

[Achim Gratz]

Bastien writes:
> Achim Gratz <Stromeko@nexgo.de> writes:
>> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
>> don't work that way, so could this please be reverted?
>
> Done.

Thank you.

By way of explanation: autoload knows about a handful of "special"
constructs.  If you put an autoload cookie on any other sexp, it will be
copied verbatim into the autoload file.  This comes in handy sometimes,
but the sexp may not make any sense in that context…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Compilation problem

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
>>> don't work that way, so could this please be reverted?
>>
>> Done.
>
> Thank you.
>
> By way of explanation: autoload knows about a handful of "special"
> constructs.  If you put an autoload cookie on any other sexp, it will be
> copied verbatim into the autoload file.  This comes in handy sometimes,
> but the sexp may not make any sense in that context…

Yes.  On top of that, I think these functions do not need to be
autoloaded anyway.  

-- 
 Bastien

Re: Compilation problem

[Nick Dokos]

Achim Gratz <Stromeko@nexgo.de> wrote:

> Bastien writes:
> > Achim Gratz <Stromeko@nexgo.de> writes:
> >> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
> >> don't work that way, so could this please be reverted?
> >
> > Done.
> 
> Thank you.
> 
> By way of explanation: autoload knows about a handful of "special"
> constructs.  If you put an autoload cookie on any other sexp, it will be
> copied verbatim into the autoload file.  This comes in handy sometimes,
> but the sexp may not make any sense in that context…
> 

No errors in ``make test'' after this:

,----
| Ran 206 tests, 206 results as expected (2012-09-10 16:22:59-0400)
| 6 expected failures
`----

There are warnings in compilation:

,----
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org-e-groff.el...
| 
| In org-e-groff-table-cell:
| org-e-groff.el:1880:36:Warning: reference to free variable `orgtbl-exp-regexp'
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org-e-groff.elc
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org-e-latex.el...
| 
| In org-e-latex-export-block:
| org-e-latex.el:1209:56:Warning: `"LATEX"' is a malformed function
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org-e-latex.elc
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org-e-man.el...
| 
| In org-e-man-table-cell:
| org-e-man.el:1134:36:Warning: reference to free variable `orgtbl-exp-regexp'
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org-e-man.elc
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org-e-texinfo.el...
| 
| In org-e-texinfo-table-column-widths:
| org-e-texinfo.el:1542:35:Warning: function `remove-if' from cl package called
|     at runtime
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org-e-texinfo.elc
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org-md.el...
| 
| In org-md-link:
| org-md.el:312:22:Warning: reference to free variable `path'
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org-md.elc
| ...
| Compiling /home/nick/src/emacs/org/org-mode/lisp/org.el...
| 
| In org-create-formula-image-with-dvipng:
| org.el:17621:21:Warning: reference to free variable
|     `org-export-latex-listings'
| 
| In end of data:
| org.el:22595:1:Warning: the function `org-clock-sum-current-item' is not known
|     to be defined.
| Wrote /home/nick/src/emacs/org/org-mode/lisp/org.elc
`----

Nick

Re: Compilation problem

[Jambunathan K]

Bastien <bzg@altern.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Bastien writes:
>>> Achim Gratz <Stromeko@nexgo.de> writes:
>>>> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
>>>> don't work that way, so could this please be reverted?
>>>
>>> Done.
>>
>> Thank you.
>>
>> By way of explanation: autoload knows about a handful of "special"
>> constructs.  If you put an autoload cookie on any other sexp, it will be
>> copied verbatim into the autoload file.  This comes in handy sometimes,
>> but the sexp may not make any sense in that context…
>
> Yes.  On top of that, I think these functions do not need to be
> autoloaded anyway.  

Please ask for clarification and politely indicate that a change may
have to be reverted.  It will be promptly followed up.  Please don't
reach a conclusion.

Let me see!  

Can someone explain to me the reason why I might have added those in
first place?  Instead of the commit being wrong, is it possible that
changes were incomplete.  Do you have a solution for what that autoload
was trying to solve.

I am OK with the revert, btw.

There is a popular saying in Tamil which goes like "One who has sown the
seeds, will water the plants."  I have been watering the plants, you
know, whether I like it or not.

ps: I am not interested in a discussion.  
-- 

Re: Compilation problem

[Alan Schmitt]

Achim Gratz <Stromeko@nexgo.de> writes:

> Alan Schmitt writes:
>> EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
>
> As with the problems John Hendy has: is that the actual Emacs binary or
> a wrapper script?  If it is a script, it seems that it doesn't correctly
> feed all the options to Emacs.

It's 14MB in size so I hope it's not a script ...

Alan

Re: Compilation problem

[Alan Schmitt]

Bastien <bzg@altern.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Nick Dokos writes:
>>> I can reproduce this. AFAIK, it's new - I stripped down the command
>>> line above and kept getting the error until the -l org-install.el, so
>>> it's clearly something in org-install.el.  I modified the function
>>> org-make-org-install in org-fixup.el to add
>>
>> That would be commit 830a0781a6 by Jambunathan, then.  Autoloads really
>> don't work that way, so could this please be reverted?
>
> Done.

Thanks, it now compiles (and get stuck as usual on the line

   passed   90/192  test-ob-sh/dont-insert-spaces-on-expanded-bodies

), which was the previous behavior.

Alan

Re: Compilation problem

[Bastien]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Please ask for clarification and politely indicate that a change may
> have to be reverted.  

Sorry that I reverted this one too hastily and without warning.

> Instead of the commit being wrong, is it possible that
> changes were incomplete.  

I understand.

What would be helpful would be some comment in the commit telling 
that the change is part of a bigger change that is not yet committed.

But I think we should try to avoid this: the whole point of using git 
is to commit changes only if they are complete.  A "change" can be a
commit or a set of commits, but let's try to push changes only when
they are complete.

I know this is not always easy, and I'm not lecturing here, I'm just
sharing directions I try to follow myself.

Thanks,

-- 
 Bastien

Re: Compilation problem

[Carsten Dominik]

On 18.9.2012, at 15:22, Bastien wrote:

> Hi Jambunathan,
> 
> Jambunathan K <kjambunathan@gmail.com> writes:
> 
>> Please ask for clarification and politely indicate that a change may
>> have to be reverted.  
> 
> Sorry that I reverted this one too hastily and without warning.
> 
>> Instead of the commit being wrong, is it possible that
>> changes were incomplete.  
> 
> I understand.
> 
> What would be helpful would be some comment in the commit telling 
> that the change is part of a bigger change that is not yet committed.
> 
> But I think we should try to avoid this: the whole point of using git 
> is to commit changes only if they are complete.

Hi Bastien,

I think this should be to *merge* (and push) only complete changes.  At least this is what I think - git allows you to commit often while making changes.

Actually, I think you agree, your next paragraph says as much.

- Carsten


>  A "change" can be a
> commit or a set of commits, but let's try to push changes only when
> they are complete.
> 
> I know this is not always easy, and I'm not lecturing here, I'm just
> sharing directions I try to follow myself.
> 
> Thanks,
> 
> -- 
> Bastien
> 

Re: Compilation problem

[Bastien]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> I think this should be to *merge* (and push) only complete changes.  At
> least this is what I think - git allows you to commit often while making
> changes.
>
> Actually, I think you agree, your next paragraph says as much.

Yes, I fully agree!

-- 
 Bastien

Re: Compilation problem

[Bastien]

Hi Alan,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> I cannot compile the current version of org-mode (from git): something
> fails during testing:

did you find a workaround?

-- 
 Bastien

Re: Compilation problem

[Alan Schmitt]

Bastien <bzg@altern.org> writes:

> Hi Alan,
>
> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> I cannot compile the current version of org-mode (from git): something
>> fails during testing:
>
> did you find a workaround?

There was a revert of a commit that fixed it, and I got back to the
usual state of getting stuck on some test. (I tried finding which test
is getting stuck, but I don't know how. I just know the last test to
pass is test-ob-sh/dont-insert-spaces-on-expanded-bodies. Digging a bit
more the stuck process is running "zsh -i". Killing it crashes the Emacs
test process with a stack full of "mark_object" and "mark_vectorlike",
as reported by the OS X crash reporter.)

Alan

Re: Compilation problem

[Achim Gratz]

Alan Schmitt writes:
> There was a revert of a commit that fixed it, and I got back to the
> usual state of getting stuck on some test. (I tried finding which test
> is getting stuck, but I don't know how. I just know the last test to
> pass is test-ob-sh/dont-insert-spaces-on-expanded-bodies. Digging a bit
> more the stuck process is running "zsh -i".

Then it certainly is the sh session test and Emacs doesn't know how to
interpret the prompt it gets from zsh and waits indefinately for the
shell to start or zsh tries to do session management, which doesn't work
in emacs' emulated terminal.  This test is a bit fragile, I've seen it
do strange things on windows as well.  If you have that on your system,
use posh as a shell for the invocation of emacs from the makefile, in
local.mk:

EMACS = SHELL=posh /path/to/emacs

Make sure the shell prompt you get ends with "$" and maybe some
whitespace, then emacs should know the shell is active.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Compilation problem

[Alan Schmitt]

Achim Gratz <Stromeko@nexgo.de> writes:

> Alan Schmitt writes:
>> There was a revert of a commit that fixed it, and I got back to the
>> usual state of getting stuck on some test. (I tried finding which test
>> is getting stuck, but I don't know how. I just know the last test to
>> pass is test-ob-sh/dont-insert-spaces-on-expanded-bodies. Digging a bit
>> more the stuck process is running "zsh -i".
>
> Then it certainly is the sh session test and Emacs doesn't know how to
> interpret the prompt it gets from zsh and waits indefinately for the
> shell to start or zsh tries to do session management, which doesn't work
> in emacs' emulated terminal.  This test is a bit fragile, I've seen it
> do strange things on windows as well.  If you have that on your system,
> use posh as a shell for the invocation of emacs from the makefile, in
> local.mk:
>
> EMACS = SHELL=posh /path/to/emacs
>
> Make sure the shell prompt you get ends with "$" and maybe some
> whitespace, then emacs should know the shell is active.

I don't have posh, but putting

EMACS = SHELL=sh /path/to/emacs

in my local.mk worked. Thanks for the hint.

Alan