Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis



As you can see the major differences are in the versions of
ghostscript and Python. Also Miktex has texmf installed under
it on Textonics while Primary gives texmf its own initial directory.
Python is in the Primary Windows PATH but is not included in the 
Textonics Windows PATH. Textonics also has gsview4.6 not 4.7.


So I removed Python24 from the Primary's PATH and uninstalled
Python24, replacing it with Python23. It failed with the usual error
messages. So I tried the other computer which does install 137pre5
by uninstalling Python23 and upgrading to Python24. It took a 
little longer to complete its install but it still installed OK.


So what I thought was the most likely candidate for causing the
problem, appears to be fairly innocent. It does seem though, that
this points to the problem being caused by different Windows XP
environments than the 1.3.7pre5 installer, although the 1.3.6
installer works with the same environment that the 1.3.7 fails with.



In summary I have one test machine in which LyX1.3.7_pre5 
installs OK, but it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths in
\path_prefix, but it is no longer necessary to run sh.exe configure
to finish the installation. 


I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; 
trying to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.

Regards,
Stephen 



Re: selection of font in footnote in koma-script

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
   \setkomafont{footnote}{\sffamily}

This works for me. Can you send a minimal example file?

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
  How I can get sections* and Navigate Menu.

I think it's not possible, but it would be definitely desirable. Cf.
http://bugzilla.lyx.org/show_bug.cgi?id=1982

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Jean-Marc Lasgouttes
Why do you want to have Section*?
For the numbering?

JMarc



Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 12:07 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis


In summary I have one test machine in which LyX1.3.7_pre5 installs OK, but 
it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths 
in

\path_prefix, but it is no longer necessary to run sh.exe configure
to finish the installation.
I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; trying 
to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.



Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Regards,
Stephen






Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Angus Leeming
Stephen Harris wrote:
 Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
 or C:\Python23 will work individually; but combinations like
 Msys and Python, Msys and texmf, or Python and texmf, will
 fail to run the configure script, requiring sh.exe configure.
 I have installed to C:\LyX

Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
COPYING
abi_util_fileassoc.nsh
download.nsh
io_download.ini
io_summary.ini
io_ui_language.ini
is_user_admin.nsh
lyx_configure.C
lyx_configure.dll
lyxfunc.nsh
lyx_32x32.ico
lyx_installer.nsi
lyx_utils.nsh
strtrim.nsh

lyx_languages\
danish.nsh
dutch.nsh
english.nsh
french.nsh
german.nsh
italian.nsh
spanish.nsh
swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line 
   !define PRODUCT_SOURCEDIR C:\Program Files\LyX

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
  * edit this line to point to your installed LyX files
  * install NSIS (http://nsis.sourceforge.net/Download)
  * copy lyx_configure.dll to
  C:\Program Files\NSIS\Plugins\lyx_configure.dll
  * build the package as
  C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
  * the sources of the script
  * C:\Program Files\LyX\Resources\lyx\configure
  * lyx_configure.C --- although this also will require you to
  rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
-- 
Angus



Re: I lost a very useful feature

2005-12-17 Thread Marcelo Acuÿfffff1a
Why do you want to have Section*?
For the numbering?

JMarc

For aesthetic and legibility. My book is on history and
  is plenty of dates, numbers, and is very long.
  I try to reduce hard impact in readers.
  Because my book have a cronological structural, numbers
  of section no add useful information for readers but
  impose a hard load for they.
  (Excuse me for my english. I don´t know if I explaned me. )
  Thanks.
  Marcelo




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: I lost a very useful feature (more)

2005-12-17 Thread Marcelo Acuÿfffff1a
Why do you want to have Section*?
For the numbering?

JMarc

For aesthetic and legibility. My book is on history and
is plenty of dates, numbers, and is very long.
I try to reduce hard impact in readers.
Because my book have a cronological structural, numbers
of section no add useful information for readers but
impose a hard load for they.
(Excuse me for my english. I don´t know if I explaned me. )
Thanks.
Marcelo

  And I lost running heads. 
  After changed section for section*, names of sections*
  no more appears in header.
  I am using scrpage2
  How I can get it?
  Thanks
  Marcelo
  



-
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
Abrí tu cuenta aquí




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Angus Leeming [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the


I've also found that Perl and ImageMagick can't be included in a combo.
No two of: Perl, Imagemagick, texmf, Msys, or Python can be paired
with each other in the Win PATH prior to installing LyX1.3.7_pre5.
However, Ghostscript and Ghostgum can be in the PATH before, so
for instance Msys/ghostscript/ghostgum works.

My original problem was not exactly like Paul's report. If I restarted LyX
it would never eventually rebuild? itself and work; it always displayed the
textclass.lst error message, sorry, gotta close. I had two computers, one
of which was badly off (textclass.lst error) and the other behaved more
like Paul's symptom, a delayed initial startup.

That is a troubleshooting problem, not a programming problem, but I
thought the solution to making them behave the same might point the
way to the programming area which would produce this behavior. I'm
good at solving troubleshooting problems which is why I volunteered
to be a tester. Anyway, you can see that I haven't reproduced the
problem. but uncovered an exacerbation of the problem and its cause.

I thought of pre-existing PATH entries which apply to Lyx/helper apps
because not everyone reported the problem and there seemed to be a
pattern of experienced users, thus more likely to have LyX apps in the
PATH, as reporting problems. Newer users would not of course have
LyX apps in their PATH, especially installing LyX for the first time.

I reported that on my older machine, which never exhibited the problem,
that Python, Msys could both be pre-existing PATH entries and Lyx137
would install OK. Except that under File--import, NoWeb and Latex
don't show up just Ascii line and paragraph imports. So sh configure
is needed to restore Noweb and Latex to the menu.


   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh

   lyx_languages\
   danish.nsh
   dutch.nsh
   english.nsh
   french.nsh
   german.nsh
   italian.nsh
   spanish.nsh
   swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR C:\Program Files\LyX

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
 * edit this line to point to your installed LyX files
 * install NSIS (http://nsis.sourceforge.net/Download)
 * copy lyx_configure.dll to
 C:\Program Files\NSIS\Plugins\lyx_configure.dll
 * build the package as
 C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
 * the sources of the script
 * C:\Program Files\LyX\Resources\lyx\configure
 * lyx_configure.C --- although this also will require you to
 rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
--
Angus



1.3.6 installed correctly on both machines. That means the problem could
be in the Windows environment, either software or hardware, and that the
1.3.7-pre5 installer is triggering an environmental/system conflict that the
1.3.6 did not produce. I've solved a very few number of problems in the
past by comparing an earlier working script with a later non-working script
and noticing differences (typos) in the syntax. Of course this would work
better if I understood the scripting or programming language. But I think
learning a programming language is outside the scope of responsibility
of a tester. Especially one you describe as horrible in the extreme; that
crosses the divide, IMO. I didn't realize when you posted the workaround
you meant that test reports should be discontinued. Perhaps Uwe 

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Angus Leeming [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh




The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR C:\Program Files\LyX


I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version (22,668)
which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION 1.3.6 and
!define INSTALLER_EXE lyx_setup_136.exe to

!define PRODUCT_VERSION 1.3.7  and
!define INSTALLER_EXE lyx_setup_137.exe

I guess something more subtle, if its even in this file.

Thanks;
Stephen 





Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org; Angus Leeming [EMAIL PROTECTED]
Sent: Saturday, December 17, 2005 6:29 PM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version 
(22,668)

which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION 1.3.6 and
!define INSTALLER_EXE lyx_setup_136.exe to

!define PRODUCT_VERSION 1.3.7  and
!define INSTALLER_EXE lyx_setup_137.exe

I guess something more subtle, if its even in this file.



I used examdiff (Win) to compare the two contents of lyx_installer.nsi

I noticed that the 1.3.6 installer has a push $0 and push $1
and pop $0 and a pop $1

The 1.3.7 installer has only push $0 and pop $0

I wondered if this could be related to the 1.3.7 \path-prefix
in configure showing duplicated strings. Well, as the peers
say, this isn't really my cup of tea, so I give up, over my head.

Moving on,
Stephen 





Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis



As you can see the major differences are in the versions of
ghostscript and Python. Also Miktex has texmf installed under
it on Textonics while Primary gives texmf its own initial directory.
Python is in the Primary Windows PATH but is not included in the 
Textonics Windows PATH. Textonics also has gsview4.6 not 4.7.


So I removed Python24 from the Primary's PATH and uninstalled
Python24, replacing it with Python23. It failed with the usual error
messages. So I tried the other computer which does install 137pre5
by uninstalling Python23 and upgrading to Python24. It took a 
little longer to complete its install but it still installed OK.


So what I thought was the most likely candidate for causing the
problem, appears to be fairly innocent. It does seem though, that
this points to the problem being caused by different Windows XP
environments than the 1.3.7pre5 installer, although the 1.3.6
installer works with the same environment that the 1.3.7 fails with.



In summary I have one test machine in which LyX1.3.7_pre5 
installs OK, but it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths in
\path_prefix, but it is no longer necessary to run sh.exe configure
to finish the installation. 


I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; 
trying to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.

Regards,
Stephen 



Re: selection of font in footnote in koma-script

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
   \setkomafont{footnote}{\sffamily}

This works for me. Can you send a minimal example file?

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
  How I can get sections* and Navigate Menu.

I think it's not possible, but it would be definitely desirable. Cf.
http://bugzilla.lyx.org/show_bug.cgi?id=1982

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Jean-Marc Lasgouttes
Why do you want to have Section*?
For the numbering?

JMarc



Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 12:07 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis


In summary I have one test machine in which LyX1.3.7_pre5 installs OK, but 
it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths 
in

\path_prefix, but it is no longer necessary to run sh.exe configure
to finish the installation.
I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; trying 
to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.



Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Regards,
Stephen






Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Angus Leeming
Stephen Harris wrote:
 Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
 or C:\Python23 will work individually; but combinations like
 Msys and Python, Msys and texmf, or Python and texmf, will
 fail to run the configure script, requiring sh.exe configure.
 I have installed to C:\LyX

Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
COPYING
abi_util_fileassoc.nsh
download.nsh
io_download.ini
io_summary.ini
io_ui_language.ini
is_user_admin.nsh
lyx_configure.C
lyx_configure.dll
lyxfunc.nsh
lyx_32x32.ico
lyx_installer.nsi
lyx_utils.nsh
strtrim.nsh

lyx_languages\
danish.nsh
dutch.nsh
english.nsh
french.nsh
german.nsh
italian.nsh
spanish.nsh
swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line 
   !define PRODUCT_SOURCEDIR C:\Program Files\LyX

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
  * edit this line to point to your installed LyX files
  * install NSIS (http://nsis.sourceforge.net/Download)
  * copy lyx_configure.dll to
  C:\Program Files\NSIS\Plugins\lyx_configure.dll
  * build the package as
  C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
  * the sources of the script
  * C:\Program Files\LyX\Resources\lyx\configure
  * lyx_configure.C --- although this also will require you to
  rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
-- 
Angus



Re: I lost a very useful feature

2005-12-17 Thread Marcelo Acuÿfffff1a
Why do you want to have Section*?
For the numbering?

JMarc

For aesthetic and legibility. My book is on history and
  is plenty of dates, numbers, and is very long.
  I try to reduce hard impact in readers.
  Because my book have a cronological structural, numbers
  of section no add useful information for readers but
  impose a hard load for they.
  (Excuse me for my english. I don´t know if I explaned me. )
  Thanks.
  Marcelo




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: I lost a very useful feature (more)

2005-12-17 Thread Marcelo Acuÿfffff1a
Why do you want to have Section*?
For the numbering?

JMarc

For aesthetic and legibility. My book is on history and
is plenty of dates, numbers, and is very long.
I try to reduce hard impact in readers.
Because my book have a cronological structural, numbers
of section no add useful information for readers but
impose a hard load for they.
(Excuse me for my english. I don´t know if I explaned me. )
Thanks.
Marcelo

  And I lost running heads. 
  After changed section for section*, names of sections*
  no more appears in header.
  I am using scrpage2
  How I can get it?
  Thanks
  Marcelo
  



-
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
Abrí tu cuenta aquí




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Angus Leeming [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the


I've also found that Perl and ImageMagick can't be included in a combo.
No two of: Perl, Imagemagick, texmf, Msys, or Python can be paired
with each other in the Win PATH prior to installing LyX1.3.7_pre5.
However, Ghostscript and Ghostgum can be in the PATH before, so
for instance Msys/ghostscript/ghostgum works.

My original problem was not exactly like Paul's report. If I restarted LyX
it would never eventually rebuild? itself and work; it always displayed the
textclass.lst error message, sorry, gotta close. I had two computers, one
of which was badly off (textclass.lst error) and the other behaved more
like Paul's symptom, a delayed initial startup.

That is a troubleshooting problem, not a programming problem, but I
thought the solution to making them behave the same might point the
way to the programming area which would produce this behavior. I'm
good at solving troubleshooting problems which is why I volunteered
to be a tester. Anyway, you can see that I haven't reproduced the
problem. but uncovered an exacerbation of the problem and its cause.

I thought of pre-existing PATH entries which apply to Lyx/helper apps
because not everyone reported the problem and there seemed to be a
pattern of experienced users, thus more likely to have LyX apps in the
PATH, as reporting problems. Newer users would not of course have
LyX apps in their PATH, especially installing LyX for the first time.

I reported that on my older machine, which never exhibited the problem,
that Python, Msys could both be pre-existing PATH entries and Lyx137
would install OK. Except that under File--import, NoWeb and Latex
don't show up just Ascii line and paragraph imports. So sh configure
is needed to restore Noweb and Latex to the menu.


   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh

   lyx_languages\
   danish.nsh
   dutch.nsh
   english.nsh
   french.nsh
   german.nsh
   italian.nsh
   spanish.nsh
   swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR C:\Program Files\LyX

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
 * edit this line to point to your installed LyX files
 * install NSIS (http://nsis.sourceforge.net/Download)
 * copy lyx_configure.dll to
 C:\Program Files\NSIS\Plugins\lyx_configure.dll
 * build the package as
 C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
 * the sources of the script
 * C:\Program Files\LyX\Resources\lyx\configure
 * lyx_configure.C --- although this also will require you to
 rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
--
Angus



1.3.6 installed correctly on both machines. That means the problem could
be in the Windows environment, either software or hardware, and that the
1.3.7-pre5 installer is triggering an environmental/system conflict that the
1.3.6 did not produce. I've solved a very few number of problems in the
past by comparing an earlier working script with a later non-working script
and noticing differences (typos) in the syntax. Of course this would work
better if I understood the scripting or programming language. But I think
learning a programming language is outside the scope of responsibility
of a tester. Especially one you describe as horrible in the extreme; that
crosses the divide, IMO. I didn't realize when you posted the workaround
you meant that test reports should be discontinued. Perhaps Uwe 

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Angus Leeming [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh




The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR C:\Program Files\LyX


I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version (22,668)
which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION 1.3.6 and
!define INSTALLER_EXE lyx_setup_136.exe to

!define PRODUCT_VERSION 1.3.7  and
!define INSTALLER_EXE lyx_setup_137.exe

I guess something more subtle, if its even in this file.

Thanks;
Stephen 





Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: Stephen Harris [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org; Angus Leeming [EMAIL PROTECTED]
Sent: Saturday, December 17, 2005 6:29 PM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version 
(22,668)

which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION 1.3.6 and
!define INSTALLER_EXE lyx_setup_136.exe to

!define PRODUCT_VERSION 1.3.7  and
!define INSTALLER_EXE lyx_setup_137.exe

I guess something more subtle, if its even in this file.



I used examdiff (Win) to compare the two contents of lyx_installer.nsi

I noticed that the 1.3.6 installer has a push $0 and push $1
and pop $0 and a pop $1

The 1.3.7 installer has only push $0 and pop $0

I wondered if this could be related to the 1.3.7 \path-prefix
in configure showing duplicated strings. Well, as the peers
say, this isn't really my cup of tea, so I give up, over my head.

Moving on,
Stephen 





Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: "Stephen Harris" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis



As you can see the major differences are in the versions of
ghostscript and Python. Also Miktex has texmf installed under
it on Textonics while Primary gives texmf its own initial directory.
Python is in the Primary Windows PATH but is not included in the 
Textonics Windows PATH. Textonics also has gsview4.6 not 4.7.


So I removed Python24 from the Primary's PATH and uninstalled
Python24, replacing it with Python23. It failed with the usual error
messages. So I tried the other computer which does install 137pre5
by uninstalling Python23 and upgrading to Python24. It took a 
little longer to complete its install but it still installed OK.


So what I thought was the most likely candidate for causing the
problem, appears to be fairly innocent. It does seem though, that
this points to the problem being caused by different Windows XP
environments than the 1.3.7pre5 installer, although the 1.3.6
installer works with the same environment that the 1.3.7 fails with.



In summary I have one test machine in which LyX1.3.7_pre5 
installs OK, but it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths in
\path_prefix, but it is no longer necessary to run "sh.exe configure"
to finish the installation. 


I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; 
trying to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.

Regards,
Stephen 



Re: selection of font in footnote in koma-script

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
>   \setkomafont{footnote}{\sffamily}

This works for me. Can you send a minimal example file?

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Juergen Spitzmueller
Marcelo Acuÿf1a wrote:
>  How I can get sections* and Navigate Menu.

I think it's not possible, but it would be definitely desirable. Cf.
http://bugzilla.lyx.org/show_bug.cgi?id=1982

Jürgen


Re: I lost a very useful feature

2005-12-17 Thread Jean-Marc Lasgouttes
Why do you want to have Section*?
For the numbering?

JMarc



Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: "Stephen Harris" <[EMAIL PROTECTED]>

To: 
Sent: Saturday, December 17, 2005 12:07 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




- Original Message - 
From: "Stephen Harris" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 9:09 PM
Subject: LyX 1.3.7pre5 some progress in diagnosis


In summary I have one test machine in which LyX1.3.7_pre5 installs OK, but 
it doesn't install on my newer machine and

they are fairly similar, both Win XP Pro.

I discovered that if I eliminate both C:\Pythonxx and C:\Msys\1.0\bin
from Windows PATH environment variable from my newer machine
that LyX1.3.7_pre5 will install OK. That is, the final portion of the
install lingers for quite awhile and there is still duplication of paths 
in

\path_prefix, but it is no longer necessary to run "sh.exe configure"
to finish the installation.
I added C:\Pythonxx and C:\Msys\1.0\bin to the Windows PATH
of my older test machine in an attempt to disable the installation; trying 
to isolate the problem to C:\Pythonxx and C:\Msys\1.0\bin.

(I had previously removed all LyX programs from the PATH).

But LyX1.3.7_pre5 still installed although it has the \path_prefix dupes.
The test machine has a slower cpu, about 1gig, or half of my newer one.



Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Regards,
Stephen






Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Angus Leeming
Stephen Harris wrote:
> Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
> or C:\Python23 will work individually; but combinations like
> Msys and Python, Msys and texmf, or Python and texmf, will
> fail to run the configure script, requiring sh.exe configure.
> I have installed to C:\LyX

Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
COPYING
abi_util_fileassoc.nsh
download.nsh
io_download.ini
io_summary.ini
io_ui_language.ini
is_user_admin.nsh
lyx_configure.C
lyx_configure.dll
lyxfunc.nsh
lyx_32x32.ico
lyx_installer.nsi
lyx_utils.nsh
strtrim.nsh

lyx_languages\
danish.nsh
dutch.nsh
english.nsh
french.nsh
german.nsh
italian.nsh
spanish.nsh
swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line 
   !define PRODUCT_SOURCEDIR "C:\Program Files\LyX"

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
  * edit this line to point to your installed LyX files
  * install NSIS (http://nsis.sourceforge.net/Download)
  * copy lyx_configure.dll to
  C:\Program Files\NSIS\Plugins\lyx_configure.dll
  * build the package as
  C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
  * the sources of the script
  * C:\Program Files\LyX\Resources\lyx\configure
  * lyx_configure.C --- although this also will require you to
  rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
-- 
Angus



Re: I lost a very useful feature

2005-12-17 Thread Marcelo Acuÿfffff1a
>>Why do you want to have Section*?
>>For the numbering?
>>
>>JMarc

For aesthetic and legibility. My book is on history and
  is plenty of dates, numbers, and is very long.
  I try to reduce hard impact in readers.
  Because my book have a cronological structural, numbers
  of section no add useful information for readers but
  impose a hard load for they.
  (Excuse me for my english. I don´t know if I explaned me. )
  Thanks.
  Marcelo




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: I lost a very useful feature (more)

2005-12-17 Thread Marcelo Acuÿfffff1a
>>Why do you want to have Section*?
>>For the numbering?
>>
>>JMarc

>For aesthetic and legibility. My book is on history and
>is plenty of dates, numbers, and is very long.
>I try to reduce hard impact in readers.
>Because my book have a cronological structural, numbers
>of section no add useful information for readers but
>impose a hard load for they.
>(Excuse me for my english. I don´t know if I explaned me. )
>Thanks.
>Marcelo

  And I lost running heads. 
  After changed section for section*, names of sections*
  no more appears in header.
  I am using scrpage2
  How I can get it?
  Thanks
  Marcelo
  



-
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
Abrí tu cuenta aquí




-
 1GB gratis, Antivirus y Antispam
 Correo Yahoo!, el mejor correo web del mundo
 Abrí tu cuenta aquí

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the


I've also found that Perl and ImageMagick can't be included in a combo.
No two of: Perl, Imagemagick, texmf, Msys, or Python can be paired
with each other in the Win PATH prior to installing LyX1.3.7_pre5.
However, Ghostscript and Ghostgum can be in the PATH before, so
for instance Msys/ghostscript/ghostgum works.

My original problem was not exactly like Paul's report. If I restarted LyX
it would never eventually rebuild? itself and work; it always displayed the
textclass.lst error message, sorry, gotta close. I had two computers, one
of which was badly off (textclass.lst error) and the other behaved more
like Paul's symptom, a delayed initial startup.

That is a troubleshooting problem, not a programming problem, but I
thought the solution to making them behave the same might point the
way to the programming area which would produce this behavior. I'm
good at solving troubleshooting problems which is why I volunteered
to be a tester. Anyway, you can see that I haven't reproduced the
problem. but uncovered an exacerbation of the problem and its cause.

I thought of pre-existing PATH entries which apply to Lyx/helper apps
because not everyone reported the problem and there seemed to be a
pattern of experienced users, thus more likely to have LyX apps in the
PATH, as reporting problems. Newer users would not of course have
LyX apps in their PATH, especially installing LyX for the first time.

I reported that on my older machine, which never exhibited the problem,
that Python, Msys could both be pre-existing PATH entries and Lyx137
would install OK. Except that under File-->import, NoWeb and Latex
don't show up just Ascii line and paragraph imports. So sh configure
is needed to restore Noweb and Latex to the menu.


   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh

   lyx_languages\
   danish.nsh
   dutch.nsh
   english.nsh
   french.nsh
   german.nsh
   italian.nsh
   spanish.nsh
   swedish.nsh

The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR "C:\Program Files\LyX"

If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
 * edit this line to point to your installed LyX files
 * install NSIS (http://nsis.sourceforge.net/Download)
 * copy lyx_configure.dll to
 C:\Program Files\NSIS\Plugins\lyx_configure.dll
 * build the package as
 C:\Program Files\NSIS\makensis lyx_installer.nsi

The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.

Personally, I'd start by adding lots of comments to
 * the sources of the script
 * C:\Program Files\LyX\Resources\lyx\configure
 * lyx_configure.C --- although this also will require you to
 rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.

Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
--
Angus



1.3.6 installed correctly on both machines. That means the problem could
be in the Windows environment, either software or hardware, and that the
1.3.7-pre5 installer is triggering an environmental/system conflict that the
1.3.6 did not produce. I've solved a very few number of problems in the
past by comparing an earlier working script with a later non-working script
and noticing differences (typos) in the syntax. Of course this would work
better if I understood the scripting or programming language. But I think
learning a programming language is outside the scope of responsibility
of a tester. Especially one you describe as horrible in the extreme; that
crosses the divide, IMO. I didn't realize when you posted the workaround
you meant that test reports should be discontinued. 

Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis



Stephen Harris wrote:

Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX


Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
   development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
   http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
   COPYING
   abi_util_fileassoc.nsh
   download.nsh
   io_download.ini
   io_summary.ini
   io_ui_language.ini
   is_user_admin.nsh
   lyx_configure.C
   lyx_configure.dll
   lyxfunc.nsh
   lyx_32x32.ico
   lyx_installer.nsi
   lyx_utils.nsh
   strtrim.nsh




The main logic of the script is in lyx_installer.nsi which contains a line
  !define PRODUCT_SOURCEDIR "C:\Program Files\LyX"


I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version (22,668)
which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION "1.3.6" and
!define INSTALLER_EXE "lyx_setup_136.exe" to

!define PRODUCT_VERSION "1.3.7"  and
!define INSTALLER_EXE "lyx_setup_137.exe"

I guess something more subtle, if its even in this file.

Thanks;
Stephen 





Re: LyX 1.3.7pre5 some more progress in diagnosis

2005-12-17 Thread Stephen Harris


- Original Message - 
From: "Stephen Harris" <[EMAIL PROTECTED]>

To: ; "Angus Leeming" <[EMAIL PROTECTED]>
Sent: Saturday, December 17, 2005 6:29 PM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis




I imagine you've already done this but I will examine the difference
between the 1.3.6 lyx_installer.nsi (22,421) and the 1.3.7 version 
(22,668)

which you supplied, for any glaring discrepancies. I notice you changed
the version and .exe numbers from

!define PRODUCT_VERSION "1.3.6" and
!define INSTALLER_EXE "lyx_setup_136.exe" to

!define PRODUCT_VERSION "1.3.7"  and
!define INSTALLER_EXE "lyx_setup_137.exe"

I guess something more subtle, if its even in this file.



I used examdiff (Win) to compare the two contents of lyx_installer.nsi

I noticed that the 1.3.6 installer has a push $0 and push $1
and pop $0 and a pop $1

The 1.3.7 installer has only push $0 and pop $0

I wondered if this could be related to the 1.3.7 \path-prefix
in configure showing duplicated strings. Well, as the peers
say, this isn't really my cup of tea, so I give up, over my head.

Moving on,
Stephen