lyxexport: batch export utility for LyX
Hi Jean-Marc and everyone, > Do you want lyxexport to be included in LyX? In this case, there will be > some > work needed to integrate it in the build process. I do not know how we > can do that (in particular where to install LyX-Client so that perl > finds it...). As I said before, the installation process for LyX::Client and LyX::Polite amounts to: perl Makefile.PL make install in the corresponding directories. I still didn't figure out the "magic" needed to put the correct perl path at the beginning ot the lyxexport program. I see that for reLyX it is done with autoconf stuff, but I don't know how to do that myself. Unfortunately (?) I am going on holiday for three weeks, so I will not be able to investigate the question further for the time being. If LyX 1.0.4 comes out before and no one had the time to integrate lyxexport in the LyX build, I will announce the program on the users list so that who's interested will be able to install it separately. Cheers, Stefano Stefano Ghirlanda, Zoologiska Institutionen, Stockholms Universitet Office: D554, Arrheniusv. 14, S-106 91 Stockholm, Sweden Phone: +46 8 164055, Fax: +46 8 167715, Email: [EMAIL PROTECTED] Support Free Science, look at: http://rerumnatura.zool.su.se
Re: lyxexport: batch export utility for LyX
> I still didn't figure out the "magic" needed to put the correct perl path > at the beginning ot the lyxexport program. I use eval "exec perl $0 $*" if 0; as the first two lines of a "portable" perl script (but I do not know, how portable it really is). The "magic": The script is fed into your standard interpreter (/bin/bash e.g.) that recognizes the first line as a command and fires up perl with a commandline consisting of the scriptname and any additional parameter. Than perl takes over, reads the first *statement* (lines 1 and 2) drops the eval-stuff since 'if 0' never succeeds and goes on with the rest of the script. Of course, it's not my own idea, rather taken from 'man perlrun'. And you need perl in your $PATH and your standard interpreter has to know what to do with eval and exec... Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: lyxexport: batch export utility for LyX
Hi Andre', > I use > > eval "exec perl $0 $*" > if 0; > > as the first two lines of a "portable" perl script (but I do not know, > how portable it really is). yes, I sort of remember seeing this somewhere but wasn't able to find it when I looked for it... This seems to be the standard way to do the job. I think the only advantage over a perl line #!perl would be a more helpful error message, am I wrong? Both eval ... and #!perl require that perl is in PATH to work... I'll do like this and release lyxexport 0.2.1 soon. It will be found at http://rerumnatura.zool.su.se/stefano/software if anyone wants to lift it in the LyX distribution. Thanks for your help, Stefano Stefano Ghirlanda, Zoologiska Institutionen, Stockholms Universitet Office: D554, Arrheniusv. 14, S-106 91 Stockholm, Sweden Phone: +46 8 164055, Fax: +46 8 167715, Email: [EMAIL PROTECTED] Support Free Science, look at: http://rerumnatura.zool.su.se
Re: lyxexport: batch export utility for LyX
> yes, I sort of remember seeing this somewhere but wasn't able to find it > when I looked for it... This seems to be the standard way to do the job. I > think the only advantage over a perl line #!perl would be a more helpful > error message, am I wrong? Both eval ... and #!perl require that perl is > in PATH to work... #!perl does not work at all, I think, even if perl is in $PATH. In this place an absolute path is required. Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: lyxexport: batch export utility for LyX
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: >> yes, I sort of remember seeing this somewhere but wasn't able to >> find it when I looked for it... This seems to be the standard way >> to do the job. I think the only advantage over a perl line #!perl >> would be a more helpful error message, am I wrong? Both eval >> ... and #!perl require that perl is in PATH to work... Andre'> #!perl does not work at all, I think, even if perl is in Andre'> $PATH. In this place an absolute path is required. To enter a bit in this discussion, let me say that the problem is not to find perl, but to know how perl >= 5.002 is named. At my site, 'perl' is perl 4.0036 to avoid breaking a lot of old scripts that people use. Therefore perl 5.002 is perl5. Thus, getting the right version of perl (which is important for reLyX, but maybe not for lyxexport...) has to be done separately, unless the test which is done by configure can be done at each startup (but this would take a lot of time...). JMarc
Re: lyxexport: batch export utility for LyX
> Andre'> #!perl does not work at all, I think, even if perl is in > Andre'> $PATH. In this place an absolute path is required. > > To enter a bit in this discussion, let me say that the problem is not > to find perl, but to know how perl >= 5.002 is named. How does autoconf handle that case? It doesn't look simple... Well, one could always check a list of possible name - but ouch!! > Thus, getting the right version of perl (which is important for reLyX, > but maybe not for lyxexport...) Maybe this could be checked easily? Okok, I'll have a look ;-) Andre' -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: lyxexport: batch export utility for LyX
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: >> Andre'> #!perl does not work at all, I think, even if perl is in >> Andre'> $PATH. In this place an absolute path is required. >> >> To enter a bit in this discussion, let me say that the problem is >> not to find perl, but to know how perl >= 5.002 is named. Andre'> How does autoconf handle that case? It doesn't look simple... Andre'> Well, one could always check a list of possible name - but Andre'> ouch!! That's what it does actually. It tries, in this order perl perl5 perl5.002 perl5.003 perl5.004 perl5.005 and executes 'require 5.002;exit' on each of them. I agree that this would be very time intensive if done at each run. Another fun idea would be that configure could find the right perl, and then do a ln -s /usr/local/bin/perl /usr/local/share/lyx/thegoodperl With this hack, the name thegoodperl in lyx lib directory would always point to a working perl. However, this is so complicated that I suspect it will not work... (and also OS/2 does not do symlinks). JMarc
Re: lyxexport: batch export utility for LyX
On Tue, Jun 29, 1999 at 04:50:32PM +0200, Jean-Marc Lasgouttes wrote: > > "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes: > > That's what it does actually. It tries, in this order > perl perl5 perl5.002 perl5.003 perl5.004 perl5.005 > and executes 'require 5.002;exit' on each of them. I agree that this > would be very time intensive if done at each run. I've probably asked you this before: why do you test for 5.002 *before* 5.005? Even if someone has 5.002 in their path in the unlikely case that a 5.002 script didn't work in 5.005, why don't we run the latest version? > Another fun idea would be that configure could find the right perl, > and then do a > ln -s /usr/local/bin/perl /usr/local/share/lyx/thegoodperl > > With this hack, the name thegoodperl in lyx lib directory would always > point to a working perl. However, this is so complicated that I > suspect it will not work... (and also OS/2 does not do symlinks). Why can't you do something like the relyx wrapper script? -Amir
~M?
So we're waiting breathlessly for reports from the ~M. It seems that at least JMarc has recovered from his hangover^H^H^H^H^H^H^H^H exhausting travels, so maybe he could tell us what happened. -Amir
Re: lyxexport: batch export utility for LyX
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> On Tue, Jun 29, 1999 at 04:50:32PM +0200, Jean-Marc Lasgouttes Amir> wrote: >> > "Andre'" == Andre' Poenitz >> <[EMAIL PROTECTED]> writes: >> >> That's what it does actually. It tries, in this order perl perl5 >> perl5.002 perl5.003 perl5.004 perl5.005 and executes 'require >> 5.002;exit' on each of them. I agree that this would be very time >> intensive if done at each run. Amir> I've probably asked you this before: why do you test for 5.002 Amir> *before* 5.005? Even if someone has 5.002 in their path in the Amir> unlikely case that a 5.002 script didn't work in 5.005, why Amir> don't we run the latest version? Because I'm stupid. I'll invert the order. >> Another fun idea would be that configure could find the right perl, >> and then do a ln -s /usr/local/bin/perl >> /usr/local/share/lyx/thegoodperl >> >> With this hack, the name thegoodperl in lyx lib directory would >> always point to a working perl. However, this is so complicated >> that I suspect it will not work... (and also OS/2 does not do >> symlinks). Amir> Why can't you do something like the relyx wrapper script? If we do that, it would be in the wrapper script too. I am just proposing weird ideas... Note that relyx needs a bit more info, for example the lyxdir location, which is not needed by lyxexport. JMarc
Re: ~M?
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> So we're waiting breathlessly for reports from the ~M. It seems Amir> that at least JMarc has recovered from his Amir> hangover^H^H^H^H^H^H^H^H exhausting travels, so maybe he could Amir> tell us what happened. I am not very good at writing long reports... And since Asger have written one which is awaiting for Lars' approbation, I do not want to spoil his show ;) JMarc
Re: lyxexport: batch export utility for LyX
On Tue, 29 Jun 1999 16:50:32 +0200 (MET DST), Jean-Marc Lasgouttes wrote: >Another fun idea would be that configure could find the right perl, >and then do a > ln -s /usr/local/bin/perl /usr/local/share/lyx/thegoodperl Why not always directly use the absolute pathname instead of using the link to it? > >With this hack, the name thegoodperl in lyx lib directory would always >point to a working perl. However, this is so complicated that I >suspect it will not work... (and also OS/2 does not do symlinks). Well, it depends: tvfs.ifs and ext2fs.ifs both support symlinks. And you can always simulate one with configuring a small script(X:/XFree86/lib/X11/lyx/thegoodperl.cmd): rem fake link to working perl X:/usr/local/bin/perl.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 [or whatever] rem end of script This would work for those more exotic Unices without symlinks, too. Greets, Arnd
Re: lyxexport: batch export utility for LyX
On Tue, Jun 29, 1999 at 05:06:28PM +0200, Jean-Marc Lasgouttes wrote: > > "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: > > Because I'm stupid. I'll invert the order. It's always more fun to make you say it rather than saying it myself. That way it still looks like I"m polite. > Amir> Why can't you do something like the relyx wrapper script? > > If we do that, it would be in the wrapper script too. I am just > proposing weird ideas... Note that relyx needs a bit more info, for > example the lyxdir location, which is not needed by lyxexport. OK, I'll admit, I have no idea what's going on & have been mostly ignoring the thread (even tho it's about perl!). I thought, though, that all you needed was the name of the real perl to put in the #! line. In that case, you could have a two-line wrapper script since, as you say, relyx needs more info that this would. Hm. Is there a way to get the perl make utilities to tell you where the real perl is? Or is the problem that you need to run the correct perl when you perl the Makefile? -Amir
table customization
I don't recall.
For a complex table is it possible to feed LyX the *whole* LaTeX
\begin{tablular} parameter file, with customized Array Package entries
for multiple columns?
It is much too difficult to keep things straight, maintain perspective
and make changes if I have to input each column's particulars using the
Extra options in right click->table.
--
-lsm
table bug
Regarding borders. When you designate certain cells of the first row of a table as Multicolumn, then try and delete the left vertical lines (and right?) of any particular box, LyX displays that the entire column's left vertical line has been removed. However, LyX generates the right LaTeX code, so that the box in the top row only has had it's left vertical line removed. -- -lsm
delete column bug
Delete row works properly. Delete row five, and you can hit Delete Row again and delete row six. Not so with Delete Column. After you delete column 8, hit Delete Column again and you delete column 1. -- -lsm
LyX 1.0.3 and a compiler trouble (Linux/Alpha)
I reported a while ago problems with lyx-1.0.3 on alpha and
subsequently proposed spec file modifications to avoid triggering
the problem. Here is more detailed account what is really going on
(and a code modification).
This is indeed a compiler bug. To see it on a simple example look
at the following code:
#include
#include
unsigned char buffer[sizeof(char *) + 2];
int
main ()
{
unsigned char *p;
int i;
p = (unsigned char *)&p; /* trivial initialization */
printf("original = %p\n", p);
#if defined(BUG)
memcpy (&buffer[1], &p, sizeof(p));
#else
{
unsigned char *target, *source;
target = &buffer[1];
source = (unsigned char *)&p;
for (i = 0; i < sizeof(char *) ; i++) {
*target++ = *source++;
}
}
#endif
for (i = sizeof(char *) + 2; i > 0 ; ) {
printf("%02x ", buffer[--i]);
}
printf("\n");
return(0);
}
If BUG is not defined then, whatever an optimization level this prints
original = 0x11b60
00 00 00 00 01 1f ff fb 60 00
If you add to your compilation flags -DBUG and **any** level of
optimization above -O0 then, with some versions of egcs on Alpha,
including egcs-1.1.2 release, you will see
original = 0x11b60
00 00 00 00 00 00 00 00 60 00
Short scan through a generated assembler seems to indicate that this
is a faulty expansion of an inline function memcpy (this inlining does
not happen with -O0 and you are safe). I am not entirely sure about
diagnosis, but it seems to be plausible. I am told that in egcs (gcc)
2.95, which is not released yet and only available in snapshots this
bug vanished. I did not try that yet myself.
Here is a patch which makes math_iter.C "safe" in the face
of a broken compiler.
--- lyx-1.0.3/src/math_iter.C~ Mon Nov 30 10:26:29 1998
+++ lyx-1.0.3/src/math_iter.C Mon Jun 28 22:45:12 1999
@@ -265,10 +265,21 @@
if (!MathIsInset(type))
type = LM_TC_INSET;
split(shift);
-array->bf[pos] = type;
-memcpy(&array->bf[pos+1], &p, sizeof(p));
+// array->bf[pos] = type;
+// memcpy(&array->bf[pos+1], &p, sizeof(p));
+// pos += SizeInset;
+// array->bf[pos-1] = type;
+{
+ unsigned char *pt = &array->bf[pos];
+ unsigned char *ps = (unsigned char *)&p;
+ size_t i;
+ *pt++ = type;
+ for(i = 0; i < sizeof(p); i++) {
+ *pt++ = *ps++;
+ }
+ *pt = type;
+}
pos += SizeInset;
-array->bf[pos-1] = type;
array->bf[array->last] = '\0';
fcode = -1;
}
After this change and recompilation (even with a higher level
of an optimization than -O2) LyX seems to be doing just fine
although I definitely did not test all its aspects.
Regards,
Michal
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: LyX 1.0.3 and a compiler trouble (Linux/Alpha)
On Wed, Jun 30, 1999 at 12:30:55AM -0600, Michal Jaegermann wrote: > > I reported a while ago problems with lyx-1.0.3 on alpha and > [...] > > Here is a patch which makes math_iter.C "safe" in the face > of a broken compiler. I vote that we don't put in this patch since compiling without optimization is a good enough workaround for now. I don't see much benefit in putting in platform-specific compiler bug workarounds if we end up complicating the code (even slightly). However, a note in the README for the alpha will be necessary to warn alpha users of this problems. -- Kayvan Aghaiepour Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | | Robin Gregory (2/28/92)
