Re: [O] Build fail with emacs 24.3.1
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: Aside from the issue of whether using macros here is needed or appropriate, I can't find anything wrong with the macros or their use so far. If that upholds, the test not working points to a rather substantial bug in either the test framework or Emacs 24.3. It's not too late to explore this. This has been whittled down to a small test case after reverting the changes locally and finally reported as Emacs bug #14422. Thanks for narrowing down the problem and reporting it as a bug. For the record: independantly of the problem, I think it's better to use defuns instead of macros in Org's code for this. Best, -- Bastien
Re: [O] Build fail with emacs 24.3.1
Bastien writes: Aside from the issue of whether using macros here is needed or appropriate, I can't find anything wrong with the macros or their use so far. If that upholds, the test not working points to a rather substantial bug in either the test framework or Emacs 24.3. It's not too late to explore this. This has been whittled down to a small test case after reverting the changes locally and finally reported as Emacs bug #14422. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Build fail with emacs 24.3.1
Hi Achim, Achim Gratz strom...@nexgo.de writes: Aside from the issue of whether using macros here is needed or appropriate, I can't find anything wrong with the macros or their use so far. If that upholds, the test not working points to a rather substantial bug in either the test framework or Emacs 24.3. It's not too late to explore this. I'm not sure if there's a way to circumvent eager macroexpansion to test how it gets involved. Some further testing seems to point to the let clause that produces the contents list: it never seems to be adding anything coming from the parent. Yeah... I've dugg quite far in many directions here, but I'm stuck. Anyway, `org-export-define-backend' and its friends are now defuns, since there is no good reason for them to be macros. Thanks, -- Bastien
Re: [O] Build fail with emacs 24.3.1
Bastien bzg at altern.org writes: One potential problem in the first test is the use of parent as the name of the symbol to pass to the macro... since this is the very same name than the macro second argument. At least this reminded me this section of Elisp manual: I've actually tested this by renaming the macro arguments and no symbol capturing seems to be involved via this path. The symbol is never used unquoted in the macro expansion anyway. So... instead of fixing the macro calls in the tests, I've been wondering why using a macro for `org-export-define-derived-backend' and `org-export-define-backend' would be better? I think that these are proper uses of macros since Nicolas is introducing special syntax for defining a backend. In any case before anything is changed we should know why this is happening at all. Regards, Achim.
Re: [O] Build fail with emacs 24.3.1
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien bzg at altern.org writes: One potential problem in the first test is the use of parent as the name of the symbol to pass to the macro... since this is the very same name than the macro second argument. At least this reminded me this section of Elisp manual: I've actually tested this by renaming the macro arguments and no symbol capturing seems to be involved via this path. The symbol is never used unquoted in the macro expansion anyway. So, I'm not alone. So... instead of fixing the macro calls in the tests, I've been wondering why using a macro for `org-export-define-derived-backend' and `org-export-define-backend' would be better? I think that these are proper uses of macros since Nicolas is introducing special syntax for defining a backend. Yes -- but what I'm arguing about is that the special syntax is not needed. Or more specifically, it is not needed to have (org-export-define-backend html ((bold . org-html-bold) instead of just (org-export-define-backend 'html '((bold . org-html-bold) In any case before anything is changed we should know why this is happening at all. If we agree the macros are not really needed we can make the change. We will always be free to find why the macros are causing problems later one. I know the move looks like I want to avoid the problems instead of fixing them, but it's not: it's about fixing the approach upstream instead of fighting with some obscure consequences of the unnecessary approach. Anyway, I'll wait Nicolas opinion on this for sure. -- Bastien
Re: [O] Build fail with emacs 24.3.1
Hi Achim, Bastien b...@altern.org writes: Yes -- but what I'm arguing about is that the special syntax is not needed. Or more specifically, it is not needed to have (org-export-define-backend html ((bold . org-html-bold) instead of just (org-export-define-backend 'html '((bold . org-html-bold) Some more thought on this. For `org-export-define-derived-backend', my assumption is that the macro mimicks the style of `define-derived-mode': (define-derived-mode CHILD PARENT NAME optional DOCSTRING rest BODY) `define-derived-mode' is a macro and both CHILD and PARENT are unquoted symbol names. It makes sense in this case to use this syntax because those symbol names are meant to be accessible to the user as symbols. When I see a (define-derived-mode CHILD...) sexp, I know I can check for the value of CHILD, once derived-defined. This is not the case for `org-export-define-derived-backend', where CHILD and PARENT are not symbols the user wants to check. There are symbols that only have a meaning in `org-export-registered-backends', which is what the users/devs really want to manipulate. So mimicking `define-derived-mode' is confusing here IMHO. Anyway, waiting for Nicolas feedback on this. -- Bastien
Re: [O] Build fail with emacs 24.3.1
Bastien writes: If we agree the macros are not really needed we can make the change. We will always be free to find why the macros are causing problems later one. I know the move looks like I want to avoid the problems instead of fixing them, but it's not: it's about fixing the approach upstream instead of fighting with some obscure consequences of the unnecessary approach. Aside from the issue of whether using macros here is needed or appropriate, I can't find anything wrong with the macros or their use so far. If that upholds, the test not working points to a rather substantial bug in either the test framework or Emacs 24.3. I'm not sure if there's a way to circumvent eager macroexpansion to test how it gets involved. Some further testing seems to point to the let clause that produces the contents list: it never seems to be adding anything coming from the parent. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Build fail with emacs 24.3.1
I just installed Emacs 24.3.1 on OSX 10.8.2 and tried to build the latest git version of orgmode. It fails. Is this due to the fact that I have a new emacs, or is it a more general problem. Here is the output from building: Ran 428 tests, 426 results as expected, 2 unexpected (2013-03-13 08:36:11+0100) 5 expected failures 2 unexpected results: FAILED test-org-export/define-derived-backend FAILED test-org-export/derived-backend-p make[1]: *** [test-dirty] Error 1 make: *** [up2] Error 2
Re: [O] Build fail with emacs 24.3.1
Hi Erich, Neuwirth Erich erich.neuwi...@univie.ac.at writes: I just installed Emacs 24.3.1 on OSX 10.8.2 and tried to build the latest git version of orgmode. It fails. Is this due to the fact that I have a new emacs, or is it a more general problem. It was a problem with Org. I just removed the tests, which pass fine when called interactively, but don't pass when run in batch mode. I've been digging quite a lot and I don't understand why they break in batch mode. If someone else wants to have a look into this: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c5490f Thanks, -- Bastien
Re: [O] Build fail with emacs 24.3.1
I just installed Emacs 24.3.1 on OSX 10.8.2 and tried to build the latest git version of orgmode. It fails. Is this due to the fact that I have a new emacs, or is it a more general problem. Here is the output from building: Ran 428 tests, 426 results as expected, 2 unexpected (2013-03-13 08:36:11+0100) 5 expected failures 2 unexpected results: FAILED test-org-export/define-derived-backend FAILED test-org-export/derived-backend-p make[1]: *** [test-dirty] Error 1 make: *** [up2] Error 2 I don't know OSX at all but mine failed for a couple of days with Ubuntu and it was because the build-deps have either changed or been updated. So I ran sudo apt-get build-dep emacs24 and got a few new files. HTH. Susan
Re: [O] Build fail with emacs 24.3.1
Am 13.03.2013 12:58, schrieb Bastien: Hi Erich, Neuwirth Erich erich.neuwi...@univie.ac.at writes: I just installed Emacs 24.3.1 on OSX 10.8.2 and tried to build the latest git version of orgmode. It fails. Is this due to the fact that I have a new emacs, or is it a more general problem. It was a problem with Org. I just removed the tests, which pass fine when called interactively, but don't pass when run in batch mode. I've been digging quite a lot and I don't understand why they break in batch mode. If someone else wants to have a look into this: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c5490f Thanks, Hi Bastien, beside of the tests --an experience made with python-mode.el tests also sometimes, which failed for very different reasons-- should not the build process be independent from tests? Best, Andreas
Re: [O] Build fail with emacs 24.3.1
Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: should not the build process be independent from tests? Yes, the default build process should be independant from the tests, and it is. ~$ make up2 runs the test, but it is not the default build process. -- Bastien
Re: [O] Build fail with emacs 24.3.1
Bastien writes: It was a problem with Org. I just removed the tests, which pass fine when called interactively, but don't pass when run in batch mode. Since they did pass just until Emacs 24.3 was released (and still pass with earlier versions) that should maybe give you some pause before you sweep this failure under the rug. I've been digging quite a lot and I don't understand why they break in batch mode. Because the macro expansion doesn't produce the expected result, more specifically, the translation alist for the parent backend fails to copy into the child backend. This likely indicates that eager macro expansion is involved (one of the new things in Emacs 24.3) and may be a hint that the macro definition itself might need attention. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
