Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Dr Eberhard W Lisse]

2.3.6.2 works on my 12.3.1 (x86 and arm)

I use hombrew's python but the stub will also work because homebrew
will ask for the Command Line Tools anyway :-)-O

el

On 2022-04-19 11:46 , Stephan Witt wrote:
[...]
> LyX is trying to use python3 while looking for python.  This one
> (/usr/bin/python3) is present for a long time and a stub to ask for
> install of it.  The real python3 is part of the developer tools and
> can be download from Apple freely.  Of course other alternatives are
> available.  The „official“ one from python.org or the python from
> homebrew or macports.
>
> What the best choice for the user is depends on its background, IMO.
[...]
> Currently I have Monterey 12.1 with MacTeX and LyX 2.3.6.2 up and
> running.  Next step is the update to 12.3.1 …
>
> Stephan

--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Stephan Witt]

Am 19.04.2022 um 11:12 schrieb Pavel Sanda via lyx-users 
:
> 
> On Tue, Apr 19, 2022 at 08:10:30AM +0200, Stephan Witt wrote:
 Now you have to install Python yourself. You may download it from 
 python.org (https://www.python.org/downloads/macos/). Alternatively you 
 may run python in a terminal window and choose to install it from Apple. I 
 recommend the first option.
>>> 
>>> Not sure if I understand it correctly - any up to date mac system won't run 
>>> lyx 2.3.6.2 (or rather its pythonic parts) anymore?
>>> If this is the case we should add some info directly to 
>>> https://www.lyx.org/Download ?
>> 
>> Yes, that would be appropriate. 
> 
> We should probably do that, I don't understand the details to write it on my 
> own though.

The only hard fact is the removal of /usr/bin/python (and all the libraries and 
eggs). So there is no out-of-the-box python anymore.

LyX is trying to use python3 while looking for python. This one 
(/usr/bin/python3) is present for a long time and a stub to ask for install of 
it. The real python3 is part of the developer tools and can be download from 
Apple freely. Of course other alternatives are available. The „official“ one 
from python.org or the python from homebrew or macports.

What the best choice for the user is depends on its background, IMO.

>> At the time macOS 12 (Monterey) came out I verified the presence of python. 
>> It was there and had version 2.7.18. While the installation of macOS update 
>> to 12.3 the python installation will be removed.
>> 
>> Apple provides python3 but it is not preinstalled anymore. There is only a 
>> stub executable asking for download and installation of it:
>> 
>> On reconfigure LyX checks for a usable python and triggers the popup window 
>> with the opportunity to install python3. If the user responds with 
>> ???Install??? and the download and install succeeds LyX has to be restarted 
>> and is usable after reconfigure.
>> 
>> I didn???t try yet how it goes if an existing LyX installation looses the 
>> python executable. I want to try that next. But all these experiments are 
>> time consuming as I have to do them in virtual machines.
> 
> I have mac with 12.1 on my desk, which I avoid touching. It has some older 
> version of LyX with both python 2 & 3 installed as I just checked.
> Is there something I can do for you?

Thank you, but I think the time consuming option with virtual machines is the 
better one.

Currently I have Monterey 12.1 with MacTeX and LyX 2.3.6.2 up and running. Next 
step is the update to 12.3.1 …

Stephan
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Pavel Sanda via lyx-users]

On Tue, Apr 19, 2022 at 08:10:30AM +0200, Stephan Witt wrote:
> >> Now you have to install Python yourself. You may download it from 
> >> python.org (https://www.python.org/downloads/macos/). Alternatively you 
> >> may run python in a terminal window and choose to install it from Apple. I 
> >> recommend the first option.
> > 
> > Not sure if I understand it correctly - any up to date mac system won't run 
> > lyx 2.3.6.2 (or rather its pythonic parts) anymore?
> > If this is the case we should add some info directly to 
> > https://www.lyx.org/Download ?
> 
> Yes, that would be appropriate. 

We should probably do that, I don't understand the details to write it on my 
own though.

> At the time macOS 12 (Monterey) came out I verified the presence of python. 
> It was there and had version 2.7.18. While the installation of macOS update 
> to 12.3 the python installation will be removed.
> 
> Apple provides python3 but it is not preinstalled anymore. There is only a 
> stub executable asking for download and installation of it:
> 
> On reconfigure LyX checks for a usable python and triggers the popup window 
> with the opportunity to install python3. If the user responds with 
> ???Install??? and the download and install succeeds LyX has to be restarted 
> and is usable after reconfigure.
> 
> I didn???t try yet how it goes if an existing LyX installation looses the 
> python executable. I want to try that next. But all these experiments are 
> time consuming as I have to do them in virtual machines.

I have mac with 12.1 on my desk, which I avoid touching. It has some older 
version of LyX with both python 2 & 3 installed as I just checked.
Is there something I can do for you?

Pavel
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Pavel Sanda via lyx-users]

On Sun, Apr 17, 2022 at 10:21:42AM +0200, Stephan Witt wrote:
> Apple finally removed Python 2 in macOS 12.3 - sorry for LyX not being 
> prepared. At the time LyX 2.3.6.2 was built it was announced already but not 
> sure when it happens.
> 
> Now you have to install Python yourself. You may download it from python.org 
> (https://www.python.org/downloads/macos/). Alternatively you may run python 
> in a terminal window and choose to install it from Apple. I recommend the 
> first option.

Not sure if I understand it correctly - any up to date mac system won't run lyx 
2.3.6.2 (or rather its pythonic parts) anymore?
If this is the case we should add some info directly to 
https://www.lyx.org/Download ?

Pavel
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Dr Eberhard Lisse]

On the Mac I STRONGLY recommend using homebrew's python as it will
be updated any time you do a 'brew update'.

el


On 2022-04-17 10:21 , Stephan Witt wrote:

Am 16.04.2022 um 01:52 schrieb gelfand :


Just upgraded (from Mohave!) and when attempt to open any LyX 2.2 and earlier 
get lyx2lyx script failed to convert. Also when attempt to reconfigure get 
system reconfiguration failed.

Did see the warning message when first launching LyX that in future OS versions 
the application will no longer run and should be updated.

Running LyX 2.3.6.2 on Intel Mac with OS 12.3.1


Apple finally removed Python 2 in macOS 12.3 - sorry for LyX not being 
prepared. At the time LyX 2.3.6.2 was built it was announced already but not 
sure when it happens.

Now you have to install Python yourself. You may download it from python.org 
(https://www.python.org/downloads/macos/). Alternatively you may run python in 
a terminal window and choose to install it from Apple. I recommend the first 
option.

BR, Stephan



--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[Stephan Witt]

Am 16.04.2022 um 01:52 schrieb gelfand :
> 
> Just upgraded (from Mohave!) and when attempt to open any LyX 2.2 and earlier 
> get lyx2lyx script failed to convert. Also when attempt to reconfigure get 
> system reconfiguration failed.
> 
> Did see the warning message when first launching LyX that in future OS 
> versions the application will no longer run and should be updated.
> 
> Running LyX 2.3.6.2 on Intel Mac with OS 12.3.1

Apple finally removed Python 2 in macOS 12.3 - sorry for LyX not being 
prepared. At the time LyX 2.3.6.2 was built it was announced already but not 
sure when it happens.

Now you have to install Python yourself. You may download it from python.org 
(https://www.python.org/downloads/macos/). Alternatively you may run python in 
a terminal window and choose to install it from Apple. I recommend the first 
option.

BR, Stephan
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

MacOS 12.3.1 (Monterey) lyx2lyx script fails to convert

[gelfand]

Just upgraded (from Mohave!) and when attempt to open any LyX 2.2 and earlier 
get lyx2lyx script failed to convert. Also when attempt to reconfigure get 
system reconfiguration failed.

Did see the warning message when first launching LyX that in future OS versions 
the application will no longer run and should be updated.

Running LyX 2.3.6.2 on Intel Mac with OS 12.3.1
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: lyx2lyx script

[Jürgen Spitzmüller]

2015-04-23 14:19 GMT+02:00 Wolfgang Engelmann:

>
> By using trac? --->
>

You could download the file one by one via trac (I dno't think you can
download the folder at once). A better solution is to access the git
repository:
http://www.lyx.org/HowToUseGIT

Jürgen

Re: lyx2lyx script

[Wolfgang Engelmann]

Am 23.04.2015 um 10:01 schrieb Jürgen Spitzmüller:

2015-04-22 18:24 GMT+02:00 Wolfgang Engelmann:


I have copied the lyx2lyx in a file. Is it correct to add .py to it?


No, you need to download the whole lyx2lyx folder.

By using trac? --->

 * first install of the latest stable version Trac 0.12.1, with i18n
   support:

   easy_install Babel==0.9.5 Genshi==0.6
   easy_install Trac

   /It's very important to run the two easy_install commands
   separately, otherwise the message catalogs won't be generated./

 * upgrade to the latest stable version of Trac:

   easy_install -U Trac

 * upgrade to the latest trunk development version (0.13dev):

   easy_install -U Trac==dev





And how do I use it to convert a file
x.lyx from a too new version to a 2.0x version file?


python -tt /lyx2lyx/lyx2lyx -t 474 inputfile.lyx > outputfile.lyx

Jürgen



Wolfgang

Re: lyx2lyx script

[Wolfgang Engelmann]

Am 22.04.2015 um 18:10 schrieb Jürgen Spitzmüller:

2015-04-22 17:54 GMT+02:00 Wolfgang Engelmann:


  Where can I find the latest lyx2lyx script?


http://www.lyx.org/trac/browser/lyxgit/lib/lyx2lyx

Jürgen



Wolfgang


Thanks, Jürgen,

I have copied the lyx2lyx in a file. Is it correct to add .py to it?
And how do I use it to convert a file
x.lyx from a too new version to a 2.0x version file?

Wolfgang

Re: lyx2lyx script

[Jürgen Spitzmüller]

2015-04-22 17:54 GMT+02:00 Wolfgang Engelmann:

>  Where can I find the latest lyx2lyx script?
>

http://www.lyx.org/trac/browser/lyxgit/lib/lyx2lyx

Jürgen


> Wolfgang
>

lyx2lyx script

[Wolfgang Engelmann]

Where can I find the latest lyx2lyx script?
Wolfgang//

Re: Lyx2lyx script failure trying to open year old file

[Jürgen Spitzmüller]

2014-11-10 14:40 GMT+01:00 Graham Smith:

> Hello Jurgen,
>
> Sorry for the delay in replying, I missed your response.
>
> It won't compile because of R code chunks which have been altered.
>
> What was originally:
>
>
> [image: Inline images 1]
>
> has been changed to:
>
> [image: Inline images 2]
>
> all the way through the document
>

I think this is what it is supposed to be now (i.e., correct). But I am not
sure (I do not use chunks). Doesn't the LaTeX output look identical?

I started to edit it back, but in the end just had to use last years
> pdf/beamer for my class.
>
> Indeed this has become a major problem as only a few of my lectures from
> last year will compile this year (not all have r code chunks in them).
>
> I assume its some something to do with beamer as a typical error relates
> to  paragraph ending before  beamer@inlineframetile was complete.
>

Could you send such a document for inspection?


>
> Unfortunately, I have been in too much of a panic to prepare something fro
> lectures that I haven't spend the time trying to sort it out. But I seem to
> have separators between slides that i can't remember being there before.
>

This is correct. In the new interface, frames have to be separated that way.

I just don't have the time to look at it properly right now.
>

If you find time again, please prepare an example document, so we can check
what is wrong.

Jürgen


>
> Cheers,
>
> Graham
>
>
>
>
>
> On 3 November 2014 12:11, Jürgen Spitzmüller  wrote:
>
>> Graham Smith wrote:
>> > Hello Jurgen,
>> >
>> > Many thanks for this, I can now read it, but unfortunately it won't
>> compile
>>
>> If you post the errors to lyx-users, we might be able to help.
>>
>> Jürgen
>>
>
>

Re: Lyx2lyx script failure trying to open year old file

[Jürgen Spitzmüller]

Graham Smith wrote:
> I am trying to open a file in 2.1.2,  which is about a year old (last
> opened 30th October 2013, as I update it annually), but not sure which
> version of Lyx it was last edited in.
> 
> I am getting an error that the file was created in an older version of lyx
> and the lyx2lyx script failed to recover it.
> 
> It is one of two documents created at the same time, and the second
> document opens fine.
> 
> This one however, gives this error message in Mavericks and Ubuntu 14.04.
> The debug message just says the same as the error message.
> 
> 
> I have attached the file, However it links to many  external graphics, so
> won't open as it is, but I am hoping that looking at the preamble etc might
> give a clue.
> 
> I wonder if someone could have a look and suggest a solution.

This is bug 9298:
http://www.lyx.org/trac/ticket/9298

The bug has been fixed in the development branch and should get fixed for the 
next stable release as well.

Meanwhile, find attached a successfully converted (2.1.x) file.

Jürgen

> Many thanks,
> 
> Graham



2013-10-29 R_GettingStarted Oct 2013.lyx
Description: application/lyx

Re: lyx2lyx script failed to convert the file

[Richard Heck]

On 06/23/2014 03:35 PM, Ross Reyes wrote:


On 6/23/2014 2:24 PM, ashutosh vishwa bandhu wrote:
I want to open a lyx file using lyx version 2.0.5 on Ubuntu 11.04. 
This file was created using lyx version 2.1.0-1 on Ubuntu 14.04. When 
I try to open the file I get and error message saying that the file 
is from a new version of Lyx and the lyx2lyx script failed to convert 
it.


Is it possible to open the file using the older version of lyx?


I just change the \lyxformat specifier using a text editor and it 
usually will work.   just open your .lyx file and make the change to 
see if it will open.


This is not a good idea. In an emergency, I suppose it's worth trying, 
but there is a reason the format number changes. With Lyx 2.1.x files, 
for example, if you use any of what used to be called "Short Title" 
insets, you will get errors.


Richard

Re: lyx2lyx script failed to convert the file

[Ross Reyes]

On 6/23/2014 2:24 PM, ashutosh vishwa bandhu wrote:
I want to open a lyx file using lyx version 2.0.5 on Ubuntu 11.04. 
This file was created using lyx version 2.1.0-1 on Ubuntu 14.04. When 
I try to open the file I get and error message saying that the file is 
from a new version of Lyx and the lyx2lyx script failed to convert it.


Is it possible to open the file using the older version of lyx?
I just change the \lyxformat specifier using a text editor and it 
usually will work.   just open your .lyx file and make the change to see 
if it will open.

Re: lyx2lyx script failed to convert the file

[ashutosh vishwa bandhu]

On Tue, Jun 24, 2014 at 12:48 AM, Scott Kostyshak  wrote:

> On Mon, Jun 23, 2014 at 2:24 PM, ashutosh vishwa bandhu
>  wrote:
> > I want to open a lyx file using lyx version 2.0.5 on Ubuntu 11.04. This
> file
> > was created using lyx version 2.1.0-1 on Ubuntu 14.04. When I try to open
> > the file I get and error message saying that the file is from a new
> version
> > of Lyx and the lyx2lyx script failed to convert it.
> >
> > Is it possible to open the file using the older version of lyx?
>
> Only if you use 2.0.8 (the last release in the minor series can open
> the next major format). You can alternatively copy the lyx2lyx scripts
> from 2.0.8 or 2.1.x and use those.
>
> Best,
>
> Scott
>


Thanks. Copying the lyx2lyx scripts worked!!

Regards,

Ashutosh

Re: lyx2lyx script failed to convert the file

[Scott Kostyshak]

On Mon, Jun 23, 2014 at 2:24 PM, ashutosh vishwa bandhu
 wrote:
> I want to open a lyx file using lyx version 2.0.5 on Ubuntu 11.04. This file
> was created using lyx version 2.1.0-1 on Ubuntu 14.04. When I try to open
> the file I get and error message saying that the file is from a new version
> of Lyx and the lyx2lyx script failed to convert it.
>
> Is it possible to open the file using the older version of lyx?

Only if you use 2.0.8 (the last release in the minor series can open
the next major format). You can alternatively copy the lyx2lyx scripts
from 2.0.8 or 2.1.x and use those.

Best,

Scott

lyx2lyx script failed to convert the file

[ashutosh vishwa bandhu]

I want to open a lyx file using lyx version 2.0.5 on Ubuntu 11.04. This
file was created using lyx version 2.1.0-1 on Ubuntu 14.04. When I try to
open the file I get and error message saying that the file is from a new
version of Lyx and the lyx2lyx script failed to convert it.

Is it possible to open the file using the older version of lyx?

Thanks,

Ashutosh

Re: Re: ERROR: file is from a newer version of LyX and the lyx2lyx script failed to convert it.

[Stefan Janse van Rensburg]

On 04/22/2011 06:15 AM, Stefan Janse van Rensburg wrote:


As for the errors, the main thing was that I was experiencing several 
spontaneous crashes which I had not experienced with RC3. Nothing 
that resulted in data loss, though.



Any hint at all when these were happening?
OK, re-upgraded to RC3 and crashes seem to happen when I delete certain 
tables within a branch. I get the message: "Lyx has caught an exception, 
it will attempt to save all unsaved documents and exit. Exception: 
basic_string::_S_create". Richard, I can e-mail you the offending file.
The other issue (the main one that made me downgrade), I have a 
document which previously rendered as PDF (using latex2pdf) which now 
suddenly complains that latex cannot determine image size (no 
bounding box). Unfortunately, this problem has persisted after 
downgrading, so I might have been wrong in assuming that it was the 
upgrade that caused the error.


This is usually because LaTeX cannot find the image. Are you sure it 
is still there? (Silly question, perhaps, but I had this very problem 
recently.)
Images are still there, but will try replacing relative paths with 
absolute paths. Note that I have no problems when rendering as PS and 
then converting to PDF.


Richard

Re: ERROR: file is from a newer version of LyX and the lyx2lyx script failed to convert it.

[Richard Heck]

On 04/22/2011 06:15 AM, Stefan Janse van Rensburg wrote:


As for the errors, the main thing was that I was experiencing several 
spontaneous crashes which I had not experienced with RC3. Nothing that 
resulted in data loss, though.



Any hint at all when these were happening?

The other issue (the main one that made me downgrade), I have a 
document which previously rendered as PDF (using latex2pdf) which now 
suddenly complains that latex cannot determine image size (no bounding 
box). Unfortunately, this problem has persisted after downgrading, so 
I might have been wrong in assuming that it was the upgrade that 
caused the error.


This is usually because LaTeX cannot find the image. Are you sure it is 
still there? (Silly question, perhaps, but I had this very problem 
recently.)


Richard

Re: ERROR: file is from a newer version of LyX and the lyx2lyx script failed to convert it.

[Stefan Janse van Rensburg]

On 22-4-2011 11:27, Stefan Janse van Rensburg wrote:

>  Dear List,
>  
>  I'm using Fedora 14 (32 bit version), LyX 2.0.0-0.11.beta3.fc14. Upgrading to LyX 2.0.0-0.21.rc3.fc14, I encountered several problems which forced me to downgrade back to LyX 2.0.0-0.11.beta3.fc14.

Which problems did you encounter ? We might need to fix these.

If there are really problems introduced after beta3 that make rc3 unusable, 
this is really serious.

>  
>  I now, however, have the problem that I cannot open any of my previous documents as LyX complains that "...file is from a newer version of LyX and the lyx2lyx script failed to convert it."
>  
>  I have my most important files exported as Lyx 1.6 files, so I can work on them, but I was wondering if there is an easy way for me to convert all my Lyx 2 RC3 files to a format that Lyx 2 Beta 3 will read, without me having to install Lyx 2 RC 3 again.

You can download the lyx2lyx script:
http://www.lyx.org/trac/export/38473/lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.py
and install it in the lib/lyx2lyx directory.

Vincent



Thank you Vincent, will try and copy the script.

As for the errors, the main thing was that I was experiencing several 
spontaneous crashes which I had not experienced with RC3. Nothing that 
resulted in data loss, though. The other issue (the main one that made 
me downgrade), I have a document which previously rendered as PDF (using 
latex2pdf) which now suddenly complains that latex cannot determine 
image size (no bounding box). Unfortunately, this problem has persisted 
after downgrading, so I might have been wrong in assuming that it was 
the upgrade that caused the error.


For now, I am using ps2pdf to render the document, but all image size 
are out of whack. E.g. Doubling the size of an image has no effect in 
the rendered document. Image fles are all SVGs, but I have tried 
replcing them with PNG, EPS and PDF, to no avail.


Kind regards,

Stefan

Re: ERROR: file is from a newer version of LyX and the lyx2lyx script failed to convert it.

[Vincent van Ravesteijn]

On 22-4-2011 11:27, Stefan Janse van Rensburg wrote:
> Dear List,
> 
> I'm using Fedora 14 (32 bit version), LyX 2.0.0-0.11.beta3.fc14. Upgrading to 
> LyX 2.0.0-0.21.rc3.fc14, I encountered several problems which forced me to 
> downgrade back to LyX 2.0.0-0.11.beta3.fc14.

Which problems did you encounter ? We might need to fix these.

If there are really problems introduced after beta3 that make rc3 unusable, 
this is really serious.

> 
> I now, however, have the problem that I cannot open any of my previous 
> documents as LyX complains that "...file is from a newer version of LyX and 
> the lyx2lyx script failed to convert it."
> 
> I have my most important files exported as Lyx 1.6 files, so I can work on 
> them, but I was wondering if there is an easy way for me to convert all my 
> Lyx 2 RC3 files to a format that Lyx 2 Beta 3 will read, without me having to 
> install Lyx 2 RC 3 again.

You can download the lyx2lyx script:
http://www.lyx.org/trac/export/38473/lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.py
and install it in the lib/lyx2lyx directory.

Vincent

ERROR: file is from a newer version of LyX and the lyx2lyx script failed to convert it.

[Stefan Janse van Rensburg]

Dear List,

I'm using Fedora 14 (32 bit version), LyX 2.0.0-0.11.beta3.fc14. 
Upgrading to LyX 2.0.0-0.21.rc3.fc14, I encountered several problems 
which forced me to downgrade back to LyX 2.0.0-0.11.beta3.fc14.


I now, however, have the problem that I cannot open any of my previous 
documents as LyX complains that "...file is from a newer version of LyX 
and the lyx2lyx script failed to convert it."


I have my most important files exported as Lyx 1.6 files, so I can work 
on them, but I was wondering if there is an easy way for me to convert 
all my Lyx 2 RC3 files to a format that Lyx 2 Beta 3 will read, without 
me having to install Lyx 2 RC 3 again.


Kind regards,

Stefan

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Pavel Sanda]

Guenter Milde wrote:
> Maybe someone with right permission could change the topic to 
> "LyX should have an option of where to export".

or somebody with the right permissions could give long standing
contributors bigger rights in bugzilla.

pavel

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Guenter Milde]

On 2009-03-11, Richard Heck wrote:
> M-L wrote:
>> On Mon, 09 Mar 2009 17:34:24 -0400
>> rgheck  wrote:
>>> M-L wrote:
 rgheck  wrote:

> As Jurgen said, export to 1.5.x should work on Windows, too. But
> you have to find the right file: FILENAME.lyx15.

>> But maybe not many are so stupid and would look for the new version file
>> by default, rather than assume the original is now altered?

The same effect can be achieved by a "destination file choosing"
dialogue (with the default file name and path pre-selected).
The added bonus is that you are able to modify the target
destination/name.

> If someone wants to file an enhancement request over at bugzilla about 
> this, and then cc me (rgh...@comcast.net),
> I'll see if I can get to it for 1.6.3. (We're frozen for 1.6.2, which
> should be out in a few days.)

I added the request for "where to export" also as choice from GUI 
to Bug # 4501 
"lyx -e  should have an option of where to export".

Maybe someone with right permission could change the topic to 
"LyX should have an option of where to export".

Günter

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Richard Heck]

M-L wrote:

On Mon, 09 Mar 2009 17:34:24 -0400
rgheck  wrote:

  

M-L wrote:


On Mon, 09 Mar 2009 07:58:49 -0400
rgheck  wrote:
  
  

As Jurgen said, export to 1.5.x should work on Windows, too. But
you have to find the right file: FILENAME.lyx15.




Thank you for that. I will have to look for the right file in
windows. It seems that was the problem and I didn't know a new file
was generated, just thought the original was converted. I sent the
wrong file and therefore LyX produced the error message on my Linux
box.

  
  

Perhaps it'd be worth our issuing a message after the conversion,
saying what file has been exported.

rh



Or maybe for dummies like me - that: the "new version" file has
been created?

But maybe not many are so stupid and would look for the new version file
by default, rather than assume the original is now altered?

  
If someone wants to file an enhancement request over at bugzilla about 
this, and then cc me (rgh...@comcast.net), I'll see if I can get to it 
for 1.6.3. (We're frozen for 1.6.2, which should be out in a few days.)


rh

Re:[SOLVED] lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Joe(theWordy)Philbrook]

It would appear that on Mar 10, Joe(theWordy)Philbrook did say:

> The biggest problem should be that I have about a half dozen .lyx files
> that I open all at once via a script when I work on the story.  But
> since that script finishes by backing up my .lyxfiles to a usbstick from
> which I can import the latest changes to my laptop, then I suppose
> that the version of the script on the linux with the lyx ver 1.6.1
> could also" mv ${filename}.lyx ${filename}-v161.lyx, then invoke
> lyx2lyx to save the lyx 1.5.6 version as ${filename}.lyx... That way
> my script will always open the 1.5.6 compatabe copy. 

Actually the script that opens those files with lyx calls another
which does the backup... For me the solution was to establish the
version of lyx2lyx from lyx 1.6.1 as a command line tool. then to
modify the back-up script so that it now contains:

#!/bin/bash
# tarLyxSTUFF use tar & gzip to backup the lyxSTUFF dir...
# special version for saba4... extra code to convert .lyx files that
# were written by lyx 1.6.1 from "lyxformat 345" to "lyxformat 276"
# which the more prevalent lyx 1.5.6 can process. via the lyx2lyx
# script from lyx 1.6.1. (See ~/bin2nd/lyx2lyx for details)
cd ~/com/lyxSTUFF
fixlist=`grep -l "lyxformat 345" *.lyx`
for InName in $fixlist
do
OutName=`echo $InName|sed 's/\(.lyx\)/.v_1_6_1-lyx/'`
echo "Preserving original $InName  as  $OutName"
cp $InName $OutName
echo "Processing $InName via lyx2lyx"
lyx2lyx -t 276 -o $InName $OutName
done
# end of 'extra' code for saba4
cd ~/com/uplo
echo "
the old current LyXstuff files in uplo were"
ls -l LyXstuff*
mv LyXstuff.tgz LyXstuffWAS.tgz
cd ~/com/lyxSTUFF
tar -czf ~/com/uplo/LyXstuff.tgz .
cd ~/com/uplo
echo "
the new current LyXstuff files in uplo are"
ls -l LyXstuff*


I went with .v_1_6_1-lyx rather than -v161.lyx because I don't want
the next run to redundantly process the .v_1_6_1-lyx files...

FYI ~/com is the mount point for a personal data partition mounted
   there for my primary login regardless of which linux distro I boot...
And ~/com/uplo is regularly backed up to my laptop. especially prior to
my taking it somewhere I can't get at my desktop...

-- 
|   ---   ___
|   <0>   <->  Joe (theWordy) Philbrook
|   ^   J(tWdy)P
|~\___/~ <>

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Joe(theWordy)Philbrook]

,
It would appear that on Mar 9, Guenter Milde did say:

> On 2009-03-09, Joe(theWordy)Philbrook wrote:
> 
> > One of my computers is running lyx 1.6.1 on which I
> > recently wrote a couple of documents. Then I had occasion
> > to modify one of the .lyx files on a different linux box. 
> > But the available version of lyx was only 1.5.6 and when I
> > tried to open the document I was informed that it had been
> > created by a different version of lyx. And that the
> > lyx2lyx script had failed. 
 
> LyX 1.5.6 pre-dates 1.6.1 and hence the conversion script does not know
> how to handle the new format.

Yeah, that makes sense. Conversely then I expect when ver 1.6.1 opens a
document from ver 1.5.6, it recognizes the old format and converts it
so silently that I didn't know it had even run this lyx2lyx thingy.
 
> > Is there a way to tell lyx 1.6.1 to save in an older lyx format?
> 
> Yes. File>Export>Lyx and then choose the desired version.

Good. Then at least if I KNOW I'll need to access the durned thing
ahead of time... 

> > OR is there a conversion script that can convert a 
> > (lyx version 0.6.1).lyx  file into something lyx 1.5.6 can open???

> Yes, the lyx2lyx script of 1.6.x and 1.5.7 can do this.
> 
> You can 
> 
> * upgrade to 1.5.7 (save but maybe not possible)
> * replace the lyx2lyx dir with the version from 1.6.x or 1.5.7.
>   (on your own risk, backup the original),
> * place the lyx2lyx package in usr/local/, say and call "by hand".  

I don't think the one from 1.5.7 can handle it else I wouldn't have
had the error that got me to start this thread. But if the one from
1.6.1 can be called by hand, AND doesn't depend on specific libraries
that are only installed on the Linux that has lyx 1.6.1, then It
might be smart to at least put a copy of it in my ~/bin on the other
linux installations... Then If I happen to forget to export after
editing with the one instance of lyx ver 1.6.1 I'll still be able to
access the document when I'm using a different linux box.  

  (For assorted reasons I multi-boot several versions of
   linux. On Both my desktop AND my laptop. I never really
   know ahead of time which one I'll be using when I find
   the time to work on a book I'm trying to write.) 

The biggest problem should be that I have about a half dozen .lyx files
that I open all at once via a script when I work on the story.  But
since that script finishes by backing up my .lyxfiles to a usbstick from
which I can import the latest changes to my laptop, then I suppose
that the version of the script on the linux with the lyx ver 1.6.1
could also" mv ${filename}.lyx ${filename}-v161.lyx, then invoke
lyx2lyx to save the lyx 1.5.6 version as ${filename}.lyx... That way
my script will always open the 1.5.6 compatabe copy. 


NOTE: I just did a little testing and this can be made to work. But
it's not quite as simple as you described...

I found the lyx2lyx script and copied it's whole directory to a data
partiion. But when I ran:

cd ~/lyxstuff
/mnt/lyx2lyx/lyx2lyx -t 276 -o ${filename}.lyx ${filename}-v16.lyx

It coplained that /mnt/unicodesymbols wasn't there and output a zero
length ${filename}.lix file. But when I inserted all the non directory
files from /usr/share/lyx it worked.


-- 
|   ---   ___
|   <0>   <->  Joe (theWordy) Philbrook
|   ^   J(tWdy)P
|~\___/~ <>

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Guenter Milde]

On 2009-03-09, Uwe Stöhr wrote:
> Guenter Milde schrieb:

>> As FILENAME.lyx15 will not be recognised as a LyX file by most file managers
>> and is easily overseen by a user, I propose to open a destination-chooser
>> (save-file dialogue) with export. 

> I propose to export to "name-lyx15.lyx" instead to "name.lyx15"

This would be an improvement. But still I would like to be able to set the
destination path and filename from LyX.

Example 1: 

* Export name.lyx (1.6 format) to the usb-stick at
  /media/usbdisk/name.lyx (1.5 format).
* take the usb-stick home and edit name.lyx with my old LyX 1.5,
* open it without any renaming etc,
* save back to the usb-stick (still 1.5 format of course),
* open with LyX 1.6,
...

Example 2: 

* At Feierabend, Export name.lyx to 1.5 format but overwriting the
  original.
* Use some syncing software to move all modified files to the usb-stick.
* -- as in Example 1.

Example 3:

* Export name.lyx to HTML with TTH, save it as name-tth.html
* Export name.lyx to HTML with LaTeX2HTML, save it as name-l2h.html
* Export name.lyx to HTML with L4H, save it as name-l4h.html
* Compare the results and decide which to publish on the web (or import
  with Word or ...).

Günter

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[M-L]

On Mon, 09 Mar 2009 17:34:24 -0400
rgheck  wrote:

> M-L wrote:
> > On Mon, 09 Mar 2009 07:58:49 -0400
> > rgheck  wrote:
> >   
> >> As Jurgen said, export to 1.5.x should work on Windows, too. But
> >> you have to find the right file: FILENAME.lyx15.
> >>
> >> 
> > Thank you for that. I will have to look for the right file in
> > windows. It seems that was the problem and I didn't know a new file
> > was generated, just thought the original was converted. I sent the
> > wrong file and therefore LyX produced the error message on my Linux
> > box.
> >
> >   
> Perhaps it'd be worth our issuing a message after the conversion,
> saying what file has been exported.
> 
> rh

Or maybe for dummies like me - that: the "new version" file has
been created?

But maybe not many are so stupid and would look for the new version file
by default, rather than assume the original is now altered?

Thanks again.
Charlie
-- 
Registered Linux User:- 329524
***
Mountains should be climbed with as little effort as possible and
without desire. The reality of your own nature should determine the
speed. If you become restless, speed up. If you become winded, slow
down. You climb the mountain in an equilibrium between restlessness and
exhaustion. Then, when you're no longer thinking ahead, each footstep
isn't just a means to an end but a unique event in
itself. ..Robert Pirsig

***
Debian, just the best way to create magic
___

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[rgheck]

Uwe Stöhr wrote:

Guenter Milde schrieb:

As FILENAME.lyx15 will not be recognised as a LyX file by most file 
managers
and is easily overseen by a user, I propose to open a 
destination-chooser
(save-file dialogue) with export. 


I propose to export to "name-lyx15.lyx" instead to "name.lyx15"

Yes, that's been discussed many times and probably ought to be done now. 
But I think it'd still be worth at least telling the user what file has 
been exported. This is supposed to be done in the status bar, but it 
seems instantly to get over-written with the "buffer-export pdf" type 
message.


rh

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Uwe Stöhr]

Guenter Milde schrieb:


As FILENAME.lyx15 will not be recognised as a LyX file by most file managers
and is easily overseen by a user, I propose to open a destination-chooser
(save-file dialogue) with export. 


I propose to export to "name-lyx15.lyx" instead to "name.lyx15"

regards Uwe

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Guenter Milde]

On 2009-03-09, M-L wrote:
> On Mon, 09 Mar 2009 07:58:49 -0400
> rgheck  wrote:

>> As Jurgen said, export to 1.5.x should work on Windows, too. But you 
>> have to find the right file: FILENAME.lyx15.

> Thank you for that. I will have to look for the right file in windows.
> It seems that was the problem and I didn't know a new file was
> generated, just thought the original was converted. I sent the wrong
> file and therefore LyX produced the error message on my Linux box.

As FILENAME.lyx15 will not be recognised as a LyX file by most file managers
and is easily overseen by a user, I propose to open a destination-chooser
(save-file dialogue) with export. 

(This would also solve the: "Why do I have to remove/rename a html file
(with a separate tool) if I want to compare the output of different html
export tools?" annoyance.)

Günter

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[rgheck]

M-L wrote:

On Mon, 09 Mar 2009 07:58:49 -0400
rgheck  wrote:
  
As Jurgen said, export to 1.5.x should work on Windows, too. But you 
have to find the right file: FILENAME.lyx15.




Thank you for that. I will have to look for the right file in windows.
It seems that was the problem and I didn't know a new file was
generated, just thought the original was converted. I sent the wrong
file and therefore LyX produced the error message on my Linux box.

  
Perhaps it'd be worth our issuing a message after the conversion, saying 
what file has been exported.


rh

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[M-L]

On Mon, 09 Mar 2009 07:58:49 -0400
rgheck  wrote:

> Jürgen Spitzmüller wrote:
> > The method proposed by Siegfried works if (and only if) you do not
> > use a new feature of LyX 1.6 and if you do not use a feature whose
> > semantics was changed (which is the case for many features).
> >
> >   
> Let me just clarify what Jurgen means by this by giving an example.
> In LyX 1.5, a BibTeX inset would be written in the LyX file this way:
> 
> \begin_inset LatexCommand bibtex
> bibfiles "heck"
> options "plain"
> 
> \end_inset
> 
> In 1.6, it's like this:
> 
> \begin_inset CommandInset bibtex
> LatexCommand bibtex
> bibfiles "heck"
> options "plain"
> 
> \end_inset
> 
> There's a similar difference with citations and other "command"
> insets. Changing the format might work with these, if the parser
> happens to skip over the "CommandInset bibtex" bit that it doesn't
> recognize. But if that did work, it'd be by pure luck, and there are
> similar cases that won't work.
> 
> As Jurgen said, export to 1.5.x should work on Windows, too. But you 
> have to find the right file: FILENAME.lyx15.
> 
> Richard

Thank you for that. I will have to look for the right file in windows.
It seems that was the problem and I didn't know a new file was
generated, just thought the original was converted. I sent the wrong
file and therefore LyX produced the error message on my Linux box.

Thanks again to all for the explanations,
Charlie
-- 
Registered Linux User:- 329524
***
The nail that sticks up will be hammered down. --Japanese
proverb

***
Debian, just the best way to create magic
___

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[rgheck]

Jürgen Spitzmüller wrote:
The method proposed by Siegfried works if (and only if) you do not use a 
new feature of LyX 1.6 and if you do not use a feature whose semantics was 
changed (which is the case for many features).


  
Let me just clarify what Jurgen means by this by giving an example. In 
LyX 1.5, a BibTeX inset would be written in the LyX file this way:


\begin_inset LatexCommand bibtex
bibfiles "heck"
options "plain"

\end_inset

In 1.6, it's like this:

\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles "heck"
options "plain"

\end_inset

There's a similar difference with citations and other "command" insets. 
Changing the format might work with these, if the parser happens to skip 
over the "CommandInset bibtex" bit that it doesn't recognize. But if 
that did work, it'd be by pure luck, and there are similar cases that 
won't work.


As Jurgen said, export to 1.5.x should work on Windows, too. But you 
have to find the right file: FILENAME.lyx15.


Richard

RE: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Vincent van Ravesteijn - TNW]

>I created some files on LyX 1.6.1 in windows XP and then went to:
>
>[...]
>
>Then emailed them as an attachment and later picked it up on
>my Linux Debian Lenny machine and tried to open it with LyX
>1.5.5

I've heard this before. I think this was raised as a possible cause for
bug http://bugzilla.lyx.org/show_bug.cgi?id=5822. (I mean the different
OS'es and lyx2lyx).

Vincent

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Jürgen Spitzmüller]

M-L wrote:
> I created some files on LyX 1.6.1 in windows XP and then went to:
>
> File - then to Export - then to LyX 1.5.x
>
> With each of them.
>
> Then emailed them as an attachment and later picked it up on my Linux
> Debian Lenny machine and tried to open it with LyX 1.5.5
>
> It wouldn't open but gave me the wrong version error message.

Maybe you picked the wrong file? Note that Export does not overwrite the 
original document, but creates a new one with the suffix *.lyx15 (this is to 
preserve the native new features of 1.6, which will end up in ERT if you re-
open the 1.5 file).

You can check this by the format number. The exported file (to 1.5.x) has
\lyxformat 276

while the 1.6.x file has
\lyxformat 345

To open the *.lyx15 file, you might need to change the suffix back to *.lyx 
(some versions know this suffix, though).

> So I can't tell you what went wrong, it didn't and wouldn't show
> anything but the error message, and when that was clicked off, just an
> empty LyX screen with LYX on it?
>
> So sorry, I can't give you some more details about what fails,
> because I don't know. The error message was nothing more than that. I
> just know it doesn't work for me.

A minimal example file would help as well.

> But I have done as stated above and changed the lines and that does
> work.
>
> I know - it doesn't help - it just works and the documents I have done
> this with, I am still working on and they are fine. It would appear
> that one way [the right way?] works for you and another works for me and
> some other people?

No. The method proposed by Siegfried works if (and only if) you do not use a 
new feature of LyX 1.6 and if you do not use a feature whose semantics was 
changed (which is the case for many features).

So if it works for you, it is pure luck.

Jürgen

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[M-L]

On Mon, 9 Mar 2009 11:21:45 +0100
Jürgen Spitzmüller  wrote:

> M-L wrote:
> > I recall that I once had to change many documents from LyX 1.6.1 and
> > deleted the first 6 or so lines at the top of the documents and
> > replaced them with 6 or so lines of the older version. I didn't
> > realise it was this simple. Anything that works is a nice
> > workaround.
> 
> Note that the possibility to corrupt your documents that way is high,
> and you might not even notice that in the first place. If you would
> give us some more details about _what_ fails, we might have a chance
> to fix the problem. Without further information, there's probably not
> much we can do.
> 
> Jürgen

I created some files on LyX 1.6.1 in windows XP and then went to:

File - then to Export - then to LyX 1.5.x 

With each of them.

Then emailed them as an attachment and later picked it up on my Linux
Debian Lenny machine and tried to open it with LyX 1.5.5

It wouldn't open but gave me the wrong version error message.

So I can't tell you what went wrong, it didn't and wouldn't show
anything but the error message, and when that was clicked off, just an
empty LyX screen with LYX on it?

So sorry, I can't give you some more details about _what_ fails,
because I don't know. The error message was nothing more than that. I
just know it doesn't work for me.

But I have done as stated above and changed the lines and that does
work.

I know - it doesn't help - it just works and the documents I have done
this with, I am still working on and they are fine. It would appear
that one way [the right way?] works for you and another works for me and
some other people?

Thank you,

Charlie

-- 
Registered Linux User:- 329524
***
The law will never make men free, it is men that have to make the law
free. .Henry David Thoreau

***
Debian, just the best way to create magic
___

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Jürgen Spitzmüller]

M-L wrote:
> I recall that I once had to change many documents from LyX 1.6.1 and
> deleted the first 6 or so lines at the top of the documents and replaced
> them with 6 or so lines of the older version. I didn't realise it was this
> simple. Anything that works is a nice workaround.

Note that the possibility to corrupt your documents that way is high, and you 
might not even notice that in the first place. If you would give us some more 
details about _what_ fails, we might have a chance to fix the problem. Without 
further information, there's probably not much we can do.

Jürgen

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[M-L]

On Mon, 9 Mar 2009, Siegfried Meunier-Guttin-Cluzel engaged keyboard and 
shared this with us all:
>--} Since I often have this problem, I've found a workaround ( not a nice
>--} one, but it works when the formats aren't too different).
>--} I simply change the number of the LyX format.
>--} Open your file with a text editor and see the second line e. g.
>--} \lyxformat 276
>--} Change this number to match the number used on the old file format and
>--} it can work.
>--} Of couse make backups, since it can be dangerous.
>--}
>--} Hope it helps.
>--} Siegfried.

Thank you.

I recall that I once had to change many documents from LyX 1.6.1 and deleted 
the first 6 or so lines at the top of the documents and replaced them with 6 
or so lines of the older version. I didn't realise it was this simple. 
Anything that works is a nice workaround.

So thank you.

Charlie

-- 
Registered Linux User:- 329524
***
I scarcely remember counting upon any Happiness—I look not for it if it be not 
in the present hour—nothing startles me beyond the Moment. The setting sun 
will always set me to rights—or if a Sparrow come before my Window I take 
part in its existence and pick about the Gravel. ---JOHN KEATS

***
Debian, just the best way to create magic
___

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Siegfried Meunier-Guttin-Cluzel]

Since I often have this problem, I've found a workaround ( not a nice 
one, but it works when the formats aren't too different).

I simply change the number of the LyX format.
Open your file with a text editor and see the second line e. g.
\lyxformat 276
Change this number to match the number used on the old file format and 
it can work.

Of couse make backups, since it can be dangerous.

Hope it helps.
Siegfried.

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Jürgen Spitzmüller]

M-L wrote:
> I've tried that but it doesn't work, or it doesn't work from LyX 1.6.1
> windows converting to LyX 1.5.x to be read by LyX 1.5.5 debian Lenny.

What exactly doesn't work?

Jürgen

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[M-L]

On Mon, 9 Mar 2009 08:35:40 +0100
Jürgen Spitzmüller  wrote:

> Joe(theWordy)Philbrook wrote:
> > Is there a way to tell lyx 1.6.1 to save in an older lyx format?
> 
> File>Export>LyX 1.5.x
> 
> Jürgen

I've tried that but it doesn't work, or it doesn't work from LyX 1.6.1
windows converting to LyX 1.5.x to be read by LyX 1.5.5 debian Lenny.

No joy there at all.

Charlie
-- 
Registered Linux User:- 329524
***
Be true to your work, your word, and your
friend. ...Henry David Thoreau

***
Debian, just the best way to create magic
___

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Jürgen Spitzmüller]

Joe(theWordy)Philbrook wrote:
> Is there a way to tell lyx 1.6.1 to save in an older lyx format?

File>Export>LyX 1.5.x

Jürgen

Re: lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Guenter Milde]

On 2009-03-09, Joe(theWordy)Philbrook wrote:

> One of my computers is running lyx 1.6.1 on which I recently wrote a
> couple of documents. Then I had occasion to modify one of the .lyx files 
> on a different linux box.  But the available version of lyx was only
> 1.5.6 and when I tried to open the document I was informed that it had
> been created by a different version of lyx. And that the lyx2lyx script
> had failed. 

> I'm reasonably certain I hadn't used any new advanced features from
> ver 1.6.1 that ver 1.5.6 doesn't have. 
...
> So I was a bit surprised that version 1.5.6 couldn't open the resulting
> document.

LyX 1.5.6 pre-dates 1.6.1 and hence the conversion script does not know how
to handle the new format.

> Is there a way to tell lyx 1.6.1 to save in an older lyx format?

Yes. File>Export>Lyx and then choose the desired version.

> OR is there a conversion script that can convert a (lyx version 1.6.1).lyx  
> file into something lyx 1.5.6 can open???

Yes, the lyx2lyx script of 1.6.x and 1.5.7 can do this.

You can 

* upgrade to 1.5.7 (save but maybe not possible)
* replace the lyx2lyx dir with the version from 1.6.x or 1.5.7.
  (on your own risk, backup the original),
* place the lyx2lyx package in usr/local/, say and call "by hand".  

Günter

lyx2lyx script failed... lyx 1.6.1 >>lyx 1.5.6

[Joe(theWordy)Philbrook]

Hello. I happen to like lyx. for lots of things. But I need to be able
to access my documents via more than one computer. Not all of which
are easy to upgrade to newer software versions.

One of my computers is running lyx 1.6.1 on which I recently wrote a
couple of documents. Then I had occasion to modify one of the .lyx files 
on a different linux box.  But the available version of lyx was only
1.5.6 and when I tried to open the document I was informed that it had
been created by a different version of lyx. And that the lyx2lyx script
had failed. 

I'm reasonably certain I hadn't used any new advanced features from
ver 1.6.1 that ver 1.5.6 doesn't have. I started with a short document
that was created on ver 1.5.6 (or earlier)... Which I had opened with
ver 1.6.1 deleted a line. Added text to about 5 existing lines which i
modified the color of. Then inserted a few paragraphs of text. And did
a "Save As" new name. So I was a bit surprised that version 1.5.6
couldn't open the resulting document.

Is there a way to tell lyx 1.6.1 to save in an older lyx format?

OR is there a conversion script that can convert a (lyx version 1.6.1).lyx  
file into something lyx 1.5.6 can open???


-- 
|  ~^~   ~^~
|  Joe (theWordy) Philbrook
|  ^  J(tWdy)P
|\___/ <>

Re: LyX 1.5.7 and lyx2lyx-Script

[mrg]

The LyX terminal output:
D:\Programme\LyX 1.5.7\bin>lyx
Menu warning: menu entries "Spalte anfügen|S" and "Swap Rows|S" share the
same
shortcut.
Traceback (most recent call last):
  File "D:/Programme/LyX 1.5.7/Resources/./lyx2lyx/lyx2lyx", line 83, in

main()
  File "D:/Programme/LyX 1.5.7/Resources/./lyx2lyx/lyx2lyx", line 77, in
main
doc.convert()
  File "D:\Programme\LyX 1.5.7\Resources\lyx2lyx\LyX.py", line 482, in
convert
steps = getattr(__import__("lyx_" + step), mode)
  File "D:\Programme\LyX 1.5.7\Resources\lyx2lyx\lyx_1_5.py", line 23, in

import unicodedata
ImportError: DLL load failed: Diese Anwendung konnte nicht gestartet werden,
wei
l die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten
Sie
die Anwendung neu installieren.
Error: Das Konvertierungsskript ist fehlgeschlagen

D:/Programme/MiKTeX
2.7/tex/latex/beamer/solutions/conference-talks/conference-o
rnate-20min.en.lyx stammt von einer anderen LyX-Version, aber das
lyx2lyx-Skript
 konnte das Dokument nicht konvertieren.
-- 
View this message in context: 
http://n2.nabble.com/LyX-1.5.7-and-lyx2lyx-Script-tp1612843p1618928.html
Sent from the LyX - Users mailing list archive at Nabble.com.

Re: LyX 1.5.7 and lyx2lyx-Script

[Jürgen Spitzmüller]

mrg wrote:
> I have changed to the new LyX-157-3-27-AltInstaller-Small but the
> lyx2lyx-Script-Error still exists.

Did you try to start LyX from a terminal and check its output?

Jürgen

Re: LyX 1.5.7 and lyx2lyx-Script

[mrg]

I have changed to the new LyX-157-3-27-AltInstaller-Small but the
lyx2lyx-Script-Error still exists.
-- 
View this message in context: 
http://n2.nabble.com/LyX-1.5.7-and-lyx2lyx-Script-tp1612843p1618572.html
Sent from the LyX - Users mailing list archive at Nabble.com.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Thu, Dec 04, 2008 at 06:20:40PM -0500, Michael Wojcik wrote:
> This has gone on far too long, and I'm not really interested in
> arguing the point.

When I am not really interested in arguing a point anymore, I just
stop doing it. I don't consider that a bad habit.

> [...]
> So, for the record:   
> 16-bit Windows applications continued to run unchanged under Windows 3.0.

Except for the ones that did not get enough main memory anymore thanks
to the fatter system. Those simply would refuse to work...

> [Win 1.0 - 3.0]
> >  So, at best, that's a
> > period of 4.5 years of "API stability". That's close to a joke,
> > especially when taking into account that < 3.11 was not usable for any
> > reasonable practical purpose...
> 
> Tell that to the hundreds of customers we sold development tools for
> Windows 2.0.

First, this leaves a few more developers whom you did _not_ sell your
development tools. Second, selling someone a brush and a few buckets of
paint does not necessarily mean that the house he's living in is in good
shape. Etc. Anyway. That's subjective.
 
> > [...] X11R3: End of 88, X11R4: End of 89.
> 
> And clients continued to work. And they still work, under X11R5. New
> releases came out and API compatibility was maintained.

And still a lot of user code broke. Wasn't it even Motif++ that
barely survived the jump from R3 to R4? [And where is it nowadays?]

> Which was my point.

And my point was that maintaining compatibility is possible, if the
feature set is pretty much frozen and all new development is done
in some kind of add-on.

And even then it's not _easily_ possible.

Remember the time when suddenly no Turbo Pascal program could start
on new machines because the time calibration loop was executed too
quickly causing a division by zero? Luckily people could use hex
editors back then ;-}
 
> > Pretty much around 1990 supposedly the last person died that used plain X.
> 
> What's "plain X"? Everyone always ran windows managers on top of X11.
> That's part of the architecture.

"Plain X" as in "Xlib", possibly with Xt. In contrast to, say, Athena,
Motif, Gtk or whatever toolkit of the day - with way shorter life cycles
than the "basic library".

> > [...]
> > Spring (?) 2001 - January 2002.
> 
> I don't know what those dates are supposed to refer to. BSD 4.3 was
> released in 1986. BSD 4.4 in 1994.

I already admitted that I indeed mixed up the BSD factions here. So
you are right. _Something_ was factual incorrect.

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

This has gone on far too long, and I'm not really interested in
arguing the point. But some of your response is simply factually
incorrect. So, for the record:

Andre Poenitz wrote:
> On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote:
>> Andre Poenitz wrote:
>>> On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote:
 I've worked on many projects that maintained backward compatibility
 with new releases of the API, and seen a great many more.
>>> Just for my curiosity: Which projects, which scope? 
>> - Early versions of Windows. The Windows 1.x to Windows 2.0 and
>> Windows/286 transition maintained compatibility in the Windows API;
>> Windows 1.x applications ran unchanged in the 2.0 family.
> 
> Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0
> completely broke the API 2 1/2 years later.

16-bit Windows applications continued to run unchanged under Windows 3.0.

>  So, at best, that's a
> period of 4.5 years of "API stability". That's close to a joke,
> especially when taking into account that < 3.11 was not usable for any
> reasonable practical purpose...

Tell that to the hundreds of customers we sold development tools for
Windows 2.0.

>> - X11R3. The X11 API was layered correctly: as long as the server
>> follows the protocol spec, it doesn't matter what it does under the
>> covers. I added support for new hardware to the ddx layer; wrote new
>> window managers with completely different look-and-feel from the
>> standard ones; added extensions to X11 itself. None of that interfered
>> with existing clients one bit.
> 
> X11R3: End of 88, X11R4: End of 89.

And clients continued to work. And they still work, under X11R5. New
releases came out and API compatibility was maintained. Which was my
point.

> Pretty much around 1990 supposedly the last person died that used plain X.

What's "plain X"? Everyone always ran windows managers on top of X11.
That's part of the architecture.

>> - The 4.3 BSD kernel. Extended multihead support in the console driver
>> and wrote some drivers for new hardware. Enhanced the shared memory
>> kernel option. Nothing that didn't want to use the new features needed
>> to be recompiled.
> 
> Spring (?) 2001 - January 2002.

I don't know what those dates are supposed to refer to. BSD 4.3 was
released in 1986. BSD 4.4 in 1994.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: LyX 1.5.7 and lyx2lyx-Script

[Jürgen Spitzmüller]

mrg wrote:

> After I changed to the new LyX 1.5.7 (LyX-157-3-26-AltInstaller-Small.exe)
> I receive a lyx2lyx-Script-Error if I open the MiKTeX 2.7 beamer examples
> like beamerexample-lyx.lyx, conference-ornate-20min.en.lyx ...

There's an updated version (LyX-157-3-27-AltInstaller-Small.exe) on the Server 
which should fix this issue.

Jürgen

LyX 1.5.7 and lyx2lyx-Script

[mrg]

After I changed to the new LyX 1.5.7 (LyX-157-3-26-AltInstaller-Small.exe) I
receive a lyx2lyx-Script-Error if I open the MiKTeX 2.7 beamer examples like
beamerexample-lyx.lyx, conference-ornate-20min.en.lyx ...
-- 
View this message in context: 
http://n2.nabble.com/LyX-1.5.7-and-lyx2lyx-Script-tp1612843p1612843.html
Sent from the LyX - Users mailing list archive at Nabble.com.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Jeremy C. Reed]

> > - The 4.3 BSD kernel. Extended multihead support in the console driver
> > and wrote some drivers for new hardware. Enhanced the shared memory
> > kernel option. Nothing that didn't want to use the new features needed
> > to be recompiled.
> 
> Spring (?) 2001 - January 2002.

Sorry to jump into your thread. But the dates are many years off. 4.3BSD 
kernel was released by CSRG in 1986.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Abdelrazak Younes]

On 23/11/2008 16:26, Michael Wojcik wrote:

In older versions of the Microsoft toolchain, you could just drop the
MSVC DLLs into the same directory as your executable. That's no longer
allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now
they have to be installed into the SxS tree.


FYI, unless I'm misunderstanding you, that's not really true, many open 
source (or not) programs distribute the C and C++ runtime along the 
executable and the manifest file. We do that for LyX for example. So the 
old method still stands.


Abdel.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote:
> Andre Poenitz wrote:
> > On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote:
> >> Andre Poenitz wrote:
> >>> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote:
> >> I've worked on many projects that maintained backward compatibility
> >> with new releases of the API, and seen a great many more.
> > 
> > Just for my curiosity: Which projects, which scope? 
> 
> Hmm. Off the top of my head, in roughly chronological order:
> 
> - Various IBM internal-only projects, such as the E editor.
>
> - Early versions of Windows. The Windows 1.x to Windows 2.0 and
> Windows/286 transition maintained compatibility in the Windows API;
> Windows 1.x applications ran unchanged in the 2.0 family.

Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0
completely broke the API 2 1/2 years later.  So, at best, that's a
period of 4.5 years of "API stability". That's close to a joke,
especially when taking into account that < 3.11 was not usable for any
reasonable practical purpose...

> - X11R3. The X11 API was layered correctly: as long as the server
> follows the protocol spec, it doesn't matter what it does under the
> covers. I added support for new hardware to the ddx layer; wrote new
> window managers with completely different look-and-feel from the
> standard ones; added extensions to X11 itself. None of that interfered
> with existing clients one bit.

X11R3: End of 88, X11R4: End of 89.

In any case, this is a nice example for something that is "finished" at
some point of time. Nobody changed 7 bit ASCII for a while for that
matter. If a feature set is closed at some point of time it is easy to
"outsource" the problems to "extensions" and "toolkits".

Pretty much around 1990 supposedly the last person died that used plain X.
[No, that was not me *cough*]  SCNR ;-)

> - The 4.3 BSD kernel. Extended multihead support in the console driver
> and wrote some drivers for new hardware. Enhanced the shared memory
> kernel option. Nothing that didn't want to use the new features needed
> to be recompiled.

Spring (?) 2001 - January 2002.

I can't/won't comment on the others.

> Maintaining backward compatibility simply is not that hard.

We are _not_ talking about _two_ years here. I can maintain compatibility
over two years by simply ignoring advancements in the outside world for
that long and release "incompatible version x+1" after that.

> > I am still pretty convinced that "compatibility" and "progress" are
> > fairly incompatible notions when it comes to the development of _usable_
> > libraries.
> 
> And I'll say that my experience as a professional software developer
> for 20 years, and as a hobbyist for a number of years prior to that,
> shows me otherwise.

Fine. My experience so far shows that one has a choice between
stagnation and breaking compatibility. And making that choice is 
neither obvious nor easy.

> > you try to provide everything and the kitchen sink, and end up with
> > design and implementation decisions that need to be re-evaluated from
> > time to time in the presence of new environments. Java and Python, or
> > anything including a "GUI" comes to mind.
> 
> I'll offer X11 as a counterexample.

X11 has certainly its merits and is time proven. Still it puts a lot of
burden on the application developer, or, at the very least, on the
toolkit developer. Lots of the initial design decisions that do not
scale well into the 21st century are only bearable because of the
"outsourcing" mentioned above. Plain X11 does _not_ come with kitchen
sinks.
 
> >> And in this case, we're talking C and C++ runtimes, which should
> >> conform to the ISO standard anyway.
> > 
> > Ah... should they conform to the Standard or should they be compatible to
> > older versions?
> 
> To the standard.

That rules out fixing bugs, and it also breaks compatibility. I do not
say that's a bad choice - in fact that's what I'd do in most cases - but
it is incompatible with your statement that maintaining compatibility is
possible _and easy_.

> > What is supposed to happen if an existing version does
> > _not_ conform to the Standard?
> 
> Since the standards attempt to codify existing practice, that rarely
> happens.

Hear, hear.

How come ISO 14882 codifies "export" for templates when not a single 
compiler was able to handle that in 1998 (and for a few years after
that)?

Apart from that the point is not how often it happens but that it
happens at all. You just admit that it happens.

> The only case that comes to mind of an incompatible change in
> the C standard, between C90 (ISO 9899-1990) and C99, is the choice of
> return code semantics for snprintf when it was added to the standard.
> There were two implementations with different semantics; the committee
> chose the sensible one. The only significant broken implementations by
> that point were HP's and Microsoft's, and Microsoft's doesn't really
> count because 1) the can

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Sun, Nov 23, 2008 at 10:26:30AM -0500, Michael Wojcik wrote:
> Jean-Marc Lasgouttes wrote:
> >> Completely infeasible on Windows. The loss of shared text would make
> >> the working set of the typical application mix grossly exceed even the
> >> absurd amounts of RAM available in typical machines today. The disk
> >> space problem would be even worse.
> > 
> > I meant just for application which feel that they have to distribute
> > their own version-of-the-day
> > of whatever.dll. There is no reason to do it everywhere of course.
> 
> Still not feasible, unfortunately, because that includes everything
> linked with any of the Microsoft C/C++ runtime DLLs.

*cough*

We were _not_ talking about statically linking _everything_. We were
talking about things like Qt which are not a typical part of a Windows
system.

> This is the central problem: if you build an application that uses
> anything in the MS C/C++ library (Microsoft combines the C and C++
> standard libraries into a single DLL), which means pretty much
> anything built with a Microsoft C or C++ compiler, or with the
> Microsoft Platform SDK, you'll link against some specific version of
> one or more of the MSVC DLLs. You don't have much choice about which
> version you get - it depends on what version of the compiler or SDK
> you have installed, and what updates have been applied to it.
> [...] [...] [...]

You are fighting windmills.

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Andre Poenitz wrote:
> On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote:
>> Jean-Marc Lasgouttes wrote:
>>> What's wrong with static linking? At least it goes away when the
>>> application goes away.
>> Completely infeasible on Windows. ...
>> Many people have done
>> back-of-the-envelope calculations to demonstrate this; I think I did
>> some myself, in a post to alt.folklore.computers some time back.
> 
> Some time back I was disputing the sheer possibility to catch a virus
> using email. Still ... "environments" ... came up that made _not catching
> one_ an art...  So "things done a while back" do not count in IT.

That's one of the silliest generalizations I've seen in some time.
People who ignore the history of IT are doomed to repeat it. Usually
poorly.

In this specific case, the situation has only gotten worse.

However, I have no particular interest in demonstrating it. If you
think static linking is feasible on Windows, go ahead and build LyX
that way.

> Mac OS X pretty much shows that _not_ sharing shared libraries on an
> application level is a feasible approach to DLL hell. 

I wouldn't take anything Apple does as a model. I've used too many
Apple products. And avoiding shared code in applications is a solution
to "DLL hell" (which is a system administration problem, not an
application architecture one) in the same way that walking is a
solution to airplane safety.

>> It's a lousy idea in any case, as anyone who remembers compiling all
>> of BSD 4.2 to switch from local-files resolution to DNS remembers.
>> Dynamic linking lets you fix the bug or add the feature in one place.
> 
> So why go from  libstdc++.so.5  to  libstdc++.so.6  at all, if 
> incompatible changes can be, as you seem to say, avoided?

Because there are many changes that *are* compatible?

I'm not a libstdc++ maintainer, so I don't know offhand what the
differences in those two releases are; and I'm not going to trawl
through the release notes to find out. But it's very rare that a bug
fix, or even a new feature, needs to alter an existing API, so there's
no reason for it to introduce incompatibility. (Maintaining undefined
behavior isn't a compatibility issue. Applications that rely on
undefined behavior are broken.)

>> Dynamic linking is a good thing. It's worked very well on a number of
>> OSes.
> 
> Examples?

Most mainframe OSes - all of the MVS and VM family, for example. Also
IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix
variants, such as SVR4 and AIX. I believe dynamic linking in VMS
wasn't bad, though I only ever looked at it briefly. Worked pretty
well on OS/2.

For that matter, it often works well on Windows, when DLL management
is done properly.

>> It would work on Windows if Microsoft could figure out 1) how to
>> version properly, and 2) how to maintain backward compatibility. And
>> it's not like those are unsolved problems.
> 
> I am happy to have learned now that these problems are solved.

They were solved decades ago.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Andre Poenitz wrote:
> On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote:
>> Andre Poenitz wrote:
>>> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote:
>> I've worked on many projects that maintained backward compatibility
>> with new releases of the API, and seen a great many more.
> 
> Just for my curiosity: Which projects, which scope? 

Hmm. Off the top of my head, in roughly chronological order:

- Various IBM internal-only projects, such as the E editor.

- Early versions of Windows. The Windows 1.x to Windows 2.0 and
Windows/286 transition maintained compatibility in the Windows API;
Windows 1.x applications ran unchanged in the 2.0 family.

- X11R3. The X11 API was layered correctly: as long as the server
follows the protocol spec, it doesn't matter what it does under the
covers. I added support for new hardware to the ddx layer; wrote new
window managers with completely different look-and-feel from the
standard ones; added extensions to X11 itself. None of that interfered
with existing clients one bit.

- The 4.3 BSD kernel. Extended multihead support in the console driver
and wrote some drivers for new hardware. Enhanced the shared memory
kernel option. Nothing that didn't want to use the new features needed
to be recompiled.

- A number of Micro Focus commercial products and components thereof:
AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying
customers to build in-house and ISV commercial applications. Changing
them and breaking existing mission-critical applications isn't good
for business. But we release updates a few times a year for most of them.

Take AAI, for example. AAI 1.0 came out in 1988, and had major new
releases for the next 10 years. Typical AAI purchases were in the $10K
to $300K range, with yearly maintenance fees. The 1998 release had a
feature set probably five times as large as in the 1988 release and
ran on a dozen more platforms (from 16-bit Windows to big iron). We
still shipped, as one of the demos, the original 1988 demo source -
unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI
clients and servers interoperated with the 1998 ones, with no user
intervention (just a bit of automatic protocol negotiation).

Maintaining backward compatibility simply is not that hard.

> I am still pretty convinced that "compatibility" and "progress" are
> fairly incompatible notions when it comes to the development of _usable_
> libraries.

And I'll say that my experience as a professional software developer
for 20 years, and as a hobbyist for a number of years prior to that,
shows me otherwise.

> you try to provide everything and the kitchen sink, and end up with
> design and implementation decisions that need to be re-evaluated from
> time to time in the presence of new environments. Java and Python, or
> anything including a "GUI" comes to mind.

I'll offer X11 as a counterexample.

>> And in this case, we're talking C and C++ runtimes, which should
>> conform to the ISO standard anyway.
> 
> Ah... should they conform to the Standard or should they be compatible to
> older versions?

To the standard.

> What is supposed to happen if an existing version does
> _not_ conform to the Standard?

Since the standards attempt to codify existing practice, that rarely
happens. The only case that comes to mind of an incompatible change in
the C standard, between C90 (ISO 9899-1990) and C99, is the choice of
return code semantics for snprintf when it was added to the standard.
There were two implementations with different semantics; the committee
chose the sensible one. The only significant broken implementations by
that point were HP's and Microsoft's, and Microsoft's doesn't really
count because 1) the canonical name of the function in the Microsoft
libraries was _sprintf, an identifier reserved to the implementation,
and 2) Microsoft wasn't inclined to follow the standard anyway.

> Also: What am I supposed to do in case there is no obvious standard to
> adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done
> well before 1998...) around that's uncompilable with todays compilers.
> Who is to blame here? Should g++ have sticked to 2.95's view of the
> world?

That's not a dynamic-runtime issue, which is what we were discussing.
It's another problem entirely - the overly large and loose definition
of the C++ language.

>>> In particular that would mean not only source and binary but also
>>> behavioural compatibility including keeping buggy behaviour.
>> No it doesn't. Undefined behavior is undefined; an application that
>> relies on it is broken.
> 
> What is an application supposed to do when it lives in an environment
> where only buggy libraries are available? 

Suck it up? Might as well ask what a car is supposed to do in an
environment with no roads. That's not a design failure in the car, nor
a mistake on the part of the car's engineers; and neither does it mean
that cars are a bad idea.

>> And for the rare applic

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Jean-Marc Lasgouttes wrote:
>> Completely infeasible on Windows. The loss of shared text would make
>> the working set of the typical application mix grossly exceed even the
>> absurd amounts of RAM available in typical machines today. The disk
>> space problem would be even worse.
> 
> I meant just for application which feel that they have to distribute
> their own version-of-the-day
> of whatever.dll. There is no reason to do it everywhere of course.

Still not feasible, unfortunately, because that includes everything
linked with any of the Microsoft C/C++ runtime DLLs.

This is the central problem: if you build an application that uses
anything in the MS C/C++ library (Microsoft combines the C and C++
standard libraries into a single DLL), which means pretty much
anything built with a Microsoft C or C++ compiler, or with the
Microsoft Platform SDK, you'll link against some specific version of
one or more of the MSVC DLLs. You don't have much choice about which
version you get - it depends on what version of the compiler or SDK
you have installed, and what updates have been applied to it.

For someone else to run that binary, they need that exact same version
of the MSVC DLLs.

In older versions of the Microsoft toolchain, you could just drop the
MSVC DLLs into the same directory as your executable. That's no longer
allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now
they have to be installed into the SxS tree.

Microsoft's solution is for every application linked against any MSVC
DLL to include the redistributable DLL package for that specific MSVC
version as part of their installer package.

So it's not the application developers who want you to install a dozen
versions of the MSVC runtime. They don't know what versions you
already have installed. There's no way to coordinate versions among
unrelated applications. People build and distribute binaries, and they
carry with them MSVC version requirements.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: lyx2lyx script broken (1.6.0 on Vista)

[Richard heck]

Andre Poenitz wrote:

PPS: I cut a few smileys from the mail to avoid the embarassing ranking
in the 1.7 smiley-per-mail statistics.

  

Best to start now, eh?

rh

Re: lyx2lyx script broken (1.6.0 on Vista)

[Pavel Sanda]

> On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote:
> > > PPS: I cut a few smileys from the mail to avoid the embarassing ranking
> > > in the 1.7 smiley-per-mail statistics.
> > 
> > feel free to uncover yourself, users list is not evaluated...
> 
> Nobody expected the Spanish Inquisition...

of course the next ranking wont be based on emoticons but on the ratio between
vowels and consonants.

pavel

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote:
> > PPS: I cut a few smileys from the mail to avoid the embarassing ranking
> > in the 1.7 smiley-per-mail statistics.
> 
> feel free to uncover yourself, users list is not evaluated...

Nobody expected the Spanish Inquisition...

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Pavel Sanda]

> PPS: I cut a few smileys from the mail to avoid the embarassing ranking
> in the 1.7 smiley-per-mail statistics.

feel free to uncover yourself, users list is not evaluated...
pavel

Re: lyx2lyx script broken (1.6.0 on Vista)

[Jean-Marc Lasgouttes]

Completely infeasible on Windows. The loss of shared text would make
the working set of the typical application mix grossly exceed even the
absurd amounts of RAM available in typical machines today. The disk
space problem would be even worse.


I meant just for application which feel that they have to distribute  
their own version-of-the-day

of whatever.dll. There is no reason to do it everywhere of course.

JMarc

Re: lyx2lyx script broken (1.6.0 on Vista)

[Jean-Marc Lasgouttes]

PPS: I cut a few smileys from the mail to avoid the embarassing  
ranking

in the 1.7 smiley-per-mail statistics.


Chicken! Does not even dare to be rude anymore.

JMarc

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote:
> Jean-Marc Lasgouttes wrote:
> > 
> > What's wrong with static linking? At least it goes away when the
> > application goes away.
> 
> Completely infeasible on Windows. The loss of shared text would make
> the working set of the typical application mix grossly exceed even the
> absurd amounts of RAM available in typical machines today. The disk
> space problem would be even worse. Many people have done
> back-of-the-envelope calculations to demonstrate this; I think I did
> some myself, in a post to alt.folklore.computers some time back.

I only trust statistics I rigged  myself.

Some time back I was disputing the sheer possibility to catch a virus
using email. Still ... "environments" ... came up that made _not catching
one_ an art...  So "things done a while back" do not count in IT.

Mac OS X pretty much shows that _not_ sharing shared libraries on an
application level is a feasible approach to DLL hell. 

> It's a lousy idea in any case, as anyone who remembers compiling all
> of BSD 4.2 to switch from local-files resolution to DNS remembers.
> Dynamic linking lets you fix the bug or add the feature in one place.

So why go from  libstdc++.so.5  to  libstdc++.so.6  at all, if 
incompatible changes can be, as you seem to say, avoided?

> We can't have millions of Windows users downloading a refresh of the
> entire OS every time a bug is fixed in one of the prominent DLLs.
> 
> Dynamic linking is a good thing. It's worked very well on a number of
> OSes.

Examples?

> It would work on Windows if Microsoft could figure out 1) how to
> version properly, and 2) how to maintain backward compatibility. And
> it's not like those are unsolved problems.

I am happy to have learned now that these problems are solved.

Now the only thing I miss is a Star Gate taking me to that
parallel universe.

Andre'

PS: And don't get me wrong: I am painfully aware of what "insufficient"
hardware means nowadays, and to my best knowledge I am usually not
trying to defend any decision by MS...

PPS: I cut a few smileys from the mail to avoid the embarassing ranking
in the 1.7 smiley-per-mail statistics.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote:
> Andre Poenitz wrote:
> > On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote:
> >> I wonder if disk manufacturers are paying M$ to do this?  I've got about  
> >> 54MB of crap in %windir%\winsxs, with multiple versions of each set of  
> >> files.  Presumably there's no way for Windoze to know that something  
> >> depending on an older version can use the newer version, so old versions  
> >> never go away. 
> > 
> > In fact that's actually the most sensible behaviour since there are only
> > very few cases where a new version indeed can replace an older one
> > without any existing or imagined problem.
> 
> I respectfully disagree.

No need to show some special respect here. I believe I can stand ordinary
disagreement rather well.

> I've worked on many projects that maintained backward compatibility
> with new releases of the API, and seen a great many more.

Just for my curiosity: Which projects, which scope? 

I am still pretty convinced that "compatibility" and "progress" are
fairly incompatible notions when it comes to the development of _usable_
libraries.

Guaranteeing the behaviour of only a very limited set of property gives
you the opportunity of changing/improving implementations, but reduces
the utility of the library as such. That's the approach taken by e.g.
standardized languages like C++ 

   _or_

you try to provide everything and the kitchen sink, and end up with
design and implementation decisions that need to be re-evaluated from
time to time in the presence of new environments. Java and Python, or
anything including a "GUI" comes to mind.

> And in this case, we're talking C and C++ runtimes, which should
> conform to the ISO standard anyway.

Ah... should they conform to the Standard or should they be compatible to
older versions? What is supposed to happen if an existing version does 
_not_ conform to the Standard?

> There's no need for them to change every other week.

No. But if problems show up. Non-conformance is a problem for instance.

Also: What am I supposed to do in case there is no obvious standard to
adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done
well before 1998...) around that's uncompilable with todays compilers.
Who is to blame here? Should g++ have sticked to 2.95's view of the
world?

> > In particular that would mean not only source and binary but also
> > behavioural compatibility including keeping buggy behaviour.
> 
> No it doesn't. Undefined behavior is undefined; an application that
> relies on it is broken.

What is an application supposed to do when it lives in an environment
where only buggy libraries are available? 

> And for the rare application that does, there are other Windows
> mechanisms for tying it to the old version of the DLL.

I obviously dispute "rare", otherwise Wikipedia would not know about
"DLL hell", and I have to admit that I am not aware of a lot of "other
Windows mechanisms" that scale from, say, Win 3.11^H95 through Vista.
What exactly are you refering to?

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Jean-Marc Lasgouttes wrote:
> 
> What's wrong with static linking? At least it goes away when the
> application goes away.

Completely infeasible on Windows. The loss of shared text would make
the working set of the typical application mix grossly exceed even the
absurd amounts of RAM available in typical machines today. The disk
space problem would be even worse. Many people have done
back-of-the-envelope calculations to demonstrate this; I think I did
some myself, in a post to alt.folklore.computers some time back.

It's a lousy idea in any case, as anyone who remembers compiling all
of BSD 4.2 to switch from local-files resolution to DNS remembers.
Dynamic linking lets you fix the bug or add the feature in one place.
We can't have millions of Windows users downloading a refresh of the
entire OS every time a bug is fixed in one of the prominent DLLs.

Dynamic linking is a good thing. It's worked very well on a number of
OSes. It would work on Windows if Microsoft could figure out 1) how to
version properly, and 2) how to maintain backward compatibility. And
it's not like those are unsolved problems.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Andre Poenitz wrote:
> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote:
>> I wonder if disk manufacturers are paying M$ to do this?  I've got about  
>> 54MB of crap in %windir%\winsxs, with multiple versions of each set of  
>> files.  Presumably there's no way for Windoze to know that something  
>> depending on an older version can use the newer version, so old versions  
>> never go away. 
> 
> In fact that's actually the most sensible behaviour since there are only
> very few cases where a new version indeed can replace an older one
> without any existing or imagined problem.

I respectfully disagree. I've worked on many projects that maintained
backward compatibility with new releases of the API, and seen a great
many more.

And in this case, we're talking C and C++ runtimes, which should
conform to the ISO standard anyway. There's no need for them to change
every other week.

> In particular that would mean
> not only source and binary but also behavioural compatibility including
> keeping buggy behaviour.

No it doesn't. Undefined behavior is undefined; an application that
relies on it is broken. And for the rare application that does, there
are other Windows mechanisms for tying it to the old version of the DLL.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Mon, Nov 17, 2008 at 09:58:50PM +0100, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > In fact that's actually the most sensible behaviour since there are only
> > very few cases where a new version indeed can replace an older one
> > without any existing or imagined problem. 
> 
> What's wrong with static linking?

Not much. But it's not very different from per-application shared objects.
In the 'main application' in my previous job most we actually linked
most of the stuff statically - including Qt...

> At least it goes away when the application goes away.

That's a benefit.

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Jean-Marc Lasgouttes]

Andre Poenitz <[EMAIL PROTECTED]> writes:
> In fact that's actually the most sensible behaviour since there are only
> very few cases where a new version indeed can replace an older one
> without any existing or imagined problem. 

What's wrong with static linking? At least it goes away when the
application goes away.

JMarc

Re: lyx2lyx script broken (1.6.0 on Vista)

[Andre Poenitz]

On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote:
> I wonder if disk manufacturers are paying M$ to do this?  I've got about  
> 54MB of crap in %windir%\winsxs, with multiple versions of each set of  
> files.  Presumably there's no way for Windoze to know that something  
> depending on an older version can use the newer version, so old versions  
> never go away. 

In fact that's actually the most sensible behaviour since there are only
very few cases where a new version indeed can replace an older one
without any existing or imagined problem. In particular that would mean
not only source and binary but also behavioural compatibility including
keeping buggy behaviour. When you factor in that application also can
depend on runtime characteristics even optimizations might have to be
ruled out, so there's really not much left what could be done in a newer
version...

Andre'

Re: lyx2lyx script broken (1.6.0 on Vista)

[Paul A. Rubin]

Michael Wojcik wrote:

Uwe Stöhr wrote:

Dominik Waßenhoven schrieb:


On the Vista machine, I had no Python installed and the lyx2lyx script
failed. I now installed Microsoft's VC++ redistributable package, as
suggested by Paul Rubin, and now the lyx2lyx script works. So I think
there is a problem with the python.exe and/or python26.dll which are in
the bin directory of LyX 1.6.

But I also had no Python installed on this Vista machine, only installed
LyX using my installer and it worked. I also got feedback that it works
for others too.


It appears the bundled Python requires a particular release of
Microsoft's C runtime. There are approximately a zillion releases of
the MSVC runtime, all mutually incompatible.

For years, Microsoft handled this by changing the name of the MSVC
runtime DLLs with each release. More recently, when someone decided
it'd be good to have more incompatible runtime versions than would fit
in a single MSVC release cycle, they invented the "Side by Side"
versioning method, which has the advantages of being a black box,
completely different from previous Windows DLL versioning mechanisms,
and entirely mysterious, opaque, and frustrating for users.

Side-by-Side sticks various releases of the MSVC runtime in
directories under %windir%\winsxs.

Product installers are supposed to include the MSVC redistributable
package for the particular MSVC version they need, which will get
installed in Side-by-Side if it's not already present.

Probably, people who don't have problems with the minimal Python
included with Uwe's installer already have the necessary MSVC
redistributable on their machine from some other product installation.

The fix would be to include the appropriate MSVC redistributable in
Uwe's LyX installer. Note that it may have to be updated any time the
Python binaries are updated, since they might be linked with a
different MSVC version.

Sure makes SVR4 shared object versioning look good, doesn't it?



I wonder if disk manufacturers are paying M$ to do this?  I've got about 
54MB of crap in %windir%\winsxs, with multiple versions of each set of 
files.  Presumably there's no way for Windoze to know that something 
depending on an older version can use the newer version, so old versions 
never go away.  Kind of like that half gigabyte (and counting) of patch 
files that never gets deleted.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Michael Wojcik]

Uwe Stöhr wrote:
> Dominik Waßenhoven schrieb:
> 
>> On the Vista machine, I had no Python installed and the lyx2lyx script
>> failed. I now installed Microsoft's VC++ redistributable package, as
>> suggested by Paul Rubin, and now the lyx2lyx script works. So I think
>> there is a problem with the python.exe and/or python26.dll which are in
>> the bin directory of LyX 1.6.
> 
> But I also had no Python installed on this Vista machine, only installed
> LyX using my installer and it worked. I also got feedback that it works
> for others too.

It appears the bundled Python requires a particular release of
Microsoft's C runtime. There are approximately a zillion releases of
the MSVC runtime, all mutually incompatible.

For years, Microsoft handled this by changing the name of the MSVC
runtime DLLs with each release. More recently, when someone decided
it'd be good to have more incompatible runtime versions than would fit
in a single MSVC release cycle, they invented the "Side by Side"
versioning method, which has the advantages of being a black box,
completely different from previous Windows DLL versioning mechanisms,
and entirely mysterious, opaque, and frustrating for users.

Side-by-Side sticks various releases of the MSVC runtime in
directories under %windir%\winsxs.

Product installers are supposed to include the MSVC redistributable
package for the particular MSVC version they need, which will get
installed in Side-by-Side if it's not already present.

Probably, people who don't have problems with the minimal Python
included with Uwe's installer already have the necessary MSVC
redistributable on their machine from some other product installation.

The fix would be to include the appropriate MSVC redistributable in
Uwe's LyX installer. Note that it may have to be updated any time the
Python binaries are updated, since they might be linked with a
different MSVC version.

Sure makes SVR4 shared object versioning look good, doesn't it?

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Re: lyx2lyx script broken (1.6.0 on Vista)

[Uwe Stöhr]

Dominik Waßenhoven schrieb:


On the Vista machine, I had no Python installed and the lyx2lyx script
failed. I now installed Microsoft's VC++ redistributable package, as
suggested by Paul Rubin, and now the lyx2lyx script works. So I think
there is a problem with the python.exe and/or python26.dll which are in
the bin directory of LyX 1.6.


But I also had no Python installed on this Vista machine, only installed 
LyX using my installer and it worked. I also got feedback that it works 
for others too.


regards Uwe

Re: lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Uwe Stöhr wrote:

> Dominik Waßenhoven schrieb:

>> In the bin directory is a python26.dll file.

>> Oh -- I just saw that I have a full Python installed on the WinXP
>> machine (I didn't realize that, sorry...). It's Python 2.5.1

> This means that you have Python 2.5.1 installed but the installer didn't
> recognize it.

No,  I think I was not clear enough. The second sentenc you cited above
bear on my insallation on a WinXP system, where your installer worked
perfectly.

On the Vista machine, I had no Python installed and the lyx2lyx script
failed. I now installed Microsoft's VC++ redistributable package, as
suggested by Paul Rubin, and now the lyx2lyx script works. So I think
there is a problem with the python.exe and/or python26.dll which are in
the bin directory of LyX 1.6.

> I'm currently also on a Vista machine but cannot reproduce the problem.
> I installed here also Python 2.5.1 and then LyX using my installer. LyX
> correctly recognized Python 2.5.1 and therefore not installed Python 2.6.

As I said, the scenario was different for me, as I had /no/ Python
installed.

Thanks for your effort,
Dominik.-

Re: lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Paul A. Rubin wrote:

> Dominik Waßenhoven wrote:
>> Should I try to install Python on Vista and try to convert
>> from LyX 1.5 to 1.6 again?

> That would likely work.  Alternatively, you might install the M$ VC++
> redistributable package
> (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=de)
> and see if that does the trick.

Indeed, it does! Thanks a lot.

Regards,
Dominik.-

new LyX installer for Vista was: Re: lyx2lyx script broken (1.6.0 on Vista)

[Uwe Stöhr]

I wrote:

p.s. I'll provide a new installer version within the next 2 hours that 
fixes some Vista-specific bugs.


You can now download this version from:
https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=15417

That fixes the following bugs:
- fix a bug in the Romanian translation of the installer
- fix installation of Aspell dictionaries in Win Vista
- fix uninstallation of the file extensions ".lyx14" and the like

You would do me a big favour when you give it a try and report back if 
it works for you.


thanks and regards
Uwe

Re: lyx2lyx script broken (1.6.0 on Vista)

[Uwe Stöhr]

Dominik Waßenhoven schrieb:


In the bin directory is a python26.dll file.

Oh -- I just saw that I have a full Python installed on the WinXP
machine (I didn't realize that, sorry...). It's Python 2.5.1


This means that you have Python 2.5.1 installed but the installer didn't 
recognize it.
I'm currently also on a Vista machine but cannot reproduce the problem. 
I installed here also Python 2.5.1 and then LyX using my installer. LyX 
correctly recognized Python 2.5.1 and therefore not installed Python 2.6.


To solve your problems, I propose to uninstall Python 2.5.1, uninstall 
LyX, install Python 2.6 and afterwards LyX again.


regards Uwe

p.s. I'll provide a new installer version within the next 2 hours that 
fixes some Vista-specific bugs.

Re: lyx2lyx script broken (1.6.0 on Vista)

[Paul A. Rubin]

Dominik Waßenhoven wrote:

Paul A. Rubin wrote:


Also, you might check try converting a file manually on the Vista box,
using a DOS shell.  This would look something like



"C:\Program Files\LyX16\python\python.exe" "C:\Program
Files\LyX16\Resources\lyx2lyx\lyx2lyx" doc.lyx



where doc.lyx is the old document.  If it works, the converted file will
be written on screen.


This doesn't work either. I get the following error message:
,---.
¦ line 23, in  import unicodedata   ¦
¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden,   ¦
¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦
¦ finden Sie im Anwendungsereignisprotokoll.¦
`---´

In the bin directory is a python26.dll file.

Oh -- I just saw that I have a full Python installed on the WinXP
machine (I didn't realize that, sorry...). It's Python 2.5.1

Any ideas? Should I try to install Python on Vista and try to convert
from LyX 1.5 to 1.6 again?



That would likely work.  Alternatively, you might install the M$ VC++ 
redistributable package 
(http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=de) 
and see if that does the trick.  I googled the side-by-side 
configuration error message (rather unusual, which is fortunate from a 
search standpoint), and it appears to occur in other contexts, the 
common theme being that some piece of software is missing.


HTH,
Paul

Re: lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Paul A. Rubin wrote:

> Also, you might check try converting a file manually on the Vista box,
> using a DOS shell.  This would look something like

>> "C:\Program Files\LyX16\python\python.exe" "C:\Program
>> Files\LyX16\Resources\lyx2lyx\lyx2lyx" doc.lyx

> where doc.lyx is the old document.  If it works, the converted file will
> be written on screen.

This doesn't work either. I get the following error message:
,---.
¦ line 23, in  import unicodedata   ¦
¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden,   ¦
¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦
¦ finden Sie im Anwendungsereignisprotokoll.¦
`---´

In the bin directory is a python26.dll file.

Oh -- I just saw that I have a full Python installed on the WinXP
machine (I didn't realize that, sorry...). It's Python 2.5.1

Any ideas? Should I try to install Python on Vista and try to convert
from LyX 1.5 to 1.6 again?

TIA,
Dominik.-

Re: lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Paul A. Rubin wrote:

> Dominik Waßenhoven wrote:
>> Dominik »Ingrid« Waßenhoven wrote:

>>> I installed LyX 1.6.0 on WinXP without problems and can open lyx files
>>> of the 1.5.x series. But on Windows Vista, the same installation cannot
>>> read 1.5.x files.

>> I forgot: I used Uwe's AltInstaller.

> Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run.  Do
> you have the same installation of Python on both boxes (just the subset
> that Uwe bundles, or a full install on both)?

I have only the Python that Uwe bundles, on both machines. I used Uwe's
full installer.

> Also, you might check try converting a file manually on the Vista box,
> using a DOS shell.

I will try that, but I have no permanent access to the Vista machine...
I will report later if this works.

Thanks so far,
Dominik.-

[Fwd: Re: lyx2lyx script broken (1.6.0 on Vista)]

[Sergio Celani]

I have the same problem in Windows Vista with the Uwe's AltInstaller.

Sergio


Dominik Waßenhoven escribió:

Dominik »Ingrid« Waßenhoven wrote:

  

I installed LyX 1.6.0 on WinXP without problems and can open lyx files
of the 1.5.x series. But on Windows Vista, the same installation cannot
read 1.5.x files.



I forgot: I used Uwe's AltInstaller.

Regards,
Dominik.-
  

Re: lyx2lyx script broken (1.6.0 on Vista)

[Paul A. Rubin]

Dominik Waßenhoven wrote:

Dominik »Ingrid« Waßenhoven wrote:


I installed LyX 1.6.0 on WinXP without problems and can open lyx files
of the 1.5.x series. But on Windows Vista, the same installation cannot
read 1.5.x files.


I forgot: I used Uwe's AltInstaller.



Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run.  Do 
you have the same installation of Python on both boxes (just the subset 
that Uwe bundles, or a full install on both)?  Also, you might check try 
converting a file manually on the Vista box, using a DOS shell.  This 
would look something like


>"C:\Program Files\LyX16\python\python.exe" "C:\Program 
Files\LyX16\Resources\lyx2lyx\lyx2lyx" doc.lyx


where doc.lyx is the old document.  If it works, the converted file will 
be written on screen.  I'm wondering if perhaps there's a permission 
problem accessing Python?


/Paul

Re: lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Dominik »Ingrid« Waßenhoven wrote:

> I installed LyX 1.6.0 on WinXP without problems and can open lyx files
> of the 1.5.x series. But on Windows Vista, the same installation cannot
> read 1.5.x files.

I forgot: I used Uwe's AltInstaller.

Regards,
Dominik.-

lyx2lyx script broken (1.6.0 on Vista)

[Dominik Waßenhoven]

Hi all,

I installed LyX 1.6.0 on WinXP without problems and can open lyx files
of the 1.5.x series. But on Windows Vista, the same installation cannot
read 1.5.x files.

I attach a file example which could not be opened on Vista, but could on
WinXP:

8<->8
#LyX 1.5.7 created this file. For more info see http://www.lyx.org/
\lyxformat 276
\begin_document
\begin_header
\textclass scrreprt
\begin_preamble
\end_preamble
\options ngerman
\language ngerman
\inputencoding cp1252
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\use_esint 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language danish
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Standard
Test.
\end_layout

\end_body
\end_document
8<->8

Any suggestions?

TIA,
Dominik.-