Re: Old web page: Change tracking by John Levon

[Angus Leeming]

Christian Ridderström wrote:

On Thu, 17 Jul 2008, Christian Ridderström wrote:

What's the status of the change tracking that's describe on the 
following page?


http://www.lyx.org/devel/changetracking.php

Should I port it to the new web site? To the wiki? Or just redirect 
the old page to 'Home'?


This is the last of the 'devel/'-pages to be ported, so I'd really like 
to deal with this page as well. :-)


The page is redundant; it can be removed/redirected to home. If you 
really care about historical noise shove it on the wiki.


It was written when John Levon took on some consultancy work to 
implement change tracking on top of the existing stable version of LyX 
(1.3?) If memory serves, that work was folded into LyX 1.4. Thereafter, 
John's original implementation was rewritten from scratch in order to 
fix a host of conceptual problems by Michael Gerz (né Schmitt). That 
work made it into LyX 1.5.


Angus

Re: Reminiscing II: Old web page by John Wess, TranlsationHints

[Angus Leeming]

Christian Ridderström wrote:

Nice to read:
http://www.lyx.org/TranslationHints

/Christian

PS. I'm not sure if we still should link to this page, and from which 
page we should link to it.


Ideal material for a wiki, no? It's a useful but personal account.

A.

Re: Old web page: Change tracking by John Levon

[Angus Leeming]

Christian Ridderström wrote:

On Thu, 17 Jul 2008, Christian Ridderström wrote:

What's the status of the change tracking that's describe on the 
following page?


http://www.lyx.org/devel/changetracking.php

Should I port it to the new web site? To the wiki? Or just redirect 
the old page to 'Home'?


This is the last of the 'devel/'-pages to be ported, so I'd really like 
to deal with this page as well. :-)


The page is redundant; it can be removed/redirected to home. If you 
really care about historical noise shove it on the wiki.


It was written when John Levon took on some consultancy work to 
implement change tracking on top of the existing stable version of LyX 
(1.3?) If memory serves, that work was folded into LyX 1.4. Thereafter, 
John's original implementation was rewritten from scratch in order to 
fix a host of conceptual problems by Michael Gerz (né Schmitt). That 
work made it into LyX 1.5.


Angus

Re: Reminiscing II: Old web page by John Wess, TranlsationHints

[Angus Leeming]

Christian Ridderström wrote:

Nice to read:
http://www.lyx.org/TranslationHints

/Christian

PS. I'm not sure if we still should link to this page, and from which 
page we should link to it.


Ideal material for a wiki, no? It's a useful but personal account.

A.

Re: New www.lyx.org is now live

[Angus Leeming]

[EMAIL PROTECTED] wrote:

A starting point of the announcment can be found here:
PS. Here's a copy of the text:


Here's a little re-working into English ;-)
Angus

The LyX community has for a long time felt that the old site needed a
major overhaul. The [[new LyX web site-http://www.lyx.org]]
has finally gone live with what we hope is a cleaner and more
useful design.

 Redesigning the web site

The design and implementation of the new site went quickly and
smoothly thanks to the contributions of several people. We especially
wish to thank Rex C. Eastbourne for getting it all going.
Rex is a new LyX developer who felt that re-designing the web site
would be a good way to start contributing. With help from his web
designer friend Andrei and from Joost Verbug, an old LyX hand,
they pushed things along at breakneck speed. So fast, in fact, that
Christian Ridderström, who implemented the backend could
barely keep up with the changes. Most of the details of these events can
be found in the users' and the developers' mailing lists.

Finally we also wish to acknowledge the many LyX users and developers
that contributed with opinions about the structure and design of the new
site.

-2008-04-xx mdash; The LyX contributors

Re: New www.lyx.org is now live

[Angus Leeming]

[EMAIL PROTECTED] wrote:

A starting point of the announcment can be found here:
PS. Here's a copy of the text:


Here's a little re-working into English ;-)
Angus

The LyX community has for a long time felt that the old site needed a
major overhaul. The [[new LyX web site-http://www.lyx.org]]
has finally gone live with what we hope is a cleaner and more
useful design.

 Redesigning the web site

The design and implementation of the new site went quickly and
smoothly thanks to the contributions of several people. We especially
wish to thank Rex C. Eastbourne for getting it all going.
Rex is a new LyX developer who felt that re-designing the web site
would be a good way to start contributing. With help from his web
designer friend Andrei and from Joost Verbug, an old LyX hand,
they pushed things along at breakneck speed. So fast, in fact, that
Christian Ridderström, who implemented the backend could
barely keep up with the changes. Most of the details of these events can
be found in the users' and the developers' mailing lists.

Finally we also wish to acknowledge the many LyX users and developers
that contributed with opinions about the structure and design of the new
site.

-2008-04-xx  The LyX contributors

Re: Do we want to keep a copy of the old www.lyx.org?

[Angus Leeming]

[EMAIL PROTECTED] wrote:
Do we want to keep a copy of the old www.lyx.org? Or maybe just a 
screenshot to remember how ugly it was?  (I didn't think about this 
before I modified 'index.php')


Would be nice, for nostalgia's sake.

One thing I keep remembering as I walk to work and then forget any time 
I get near a computer is this admonition from Tim Berners-Lee, Cool 
URIs don't change: http://www.w3.org/Provider/Style/URI.html


It would be nice if you could map the URIs for the old pages to the 
equivalent in the revamp...


Angus

Bad link on http://www.lyx.org/Translation

[Angus Leeming]

... The [translation page] on the main LyX home page ...

points at

http://www.lyx.org/about/i18n.php

... If you've got (or would like) any experience with coding for 
multi-lingual documents, contact the [Developers' mailing list].


points at

http://www.lyx.org/mailing.php

All that green comes as a shock to the system ;-)

-
http://www.lyx.org/HowToUseSVN

... gzip the patch, and send to the [LyX developers' mailing list].

points at

http://www.lyx.org/mailing.php

-
Dumb-ass question: is it possible to crawl the new wiki pages with a 
script to check for obvious errors such as these?


Angus

Re: Do we want to keep a copy of the old www.lyx.org?

[Angus Leeming]

[EMAIL PROTECTED] wrote:
Do we want to keep a copy of the old www.lyx.org? Or maybe just a 
screenshot to remember how ugly it was?  (I didn't think about this 
before I modified 'index.php')


Would be nice, for nostalgia's sake.

One thing I keep remembering as I walk to work and then forget any time 
I get near a computer is this admonition from Tim Berners-Lee, "Cool 
URIs don't change": http://www.w3.org/Provider/Style/URI.html


It would be nice if you could map the URIs for the old pages to the 
equivalent in the revamp...


Angus

Bad link on http://www.lyx.org/Translation

[Angus Leeming]

... The [translation page] on the main LyX home page ...

points at

http://www.lyx.org/about/i18n.php

... If you've got (or would like) any experience with coding for 
multi-lingual documents, contact the [Developers' mailing list].


points at

http://www.lyx.org/mailing.php

All that green comes as a shock to the system ;-)

-
http://www.lyx.org/HowToUseSVN

... gzip the patch, and send to the [LyX developers' mailing list].

points at

http://www.lyx.org/mailing.php

-
Dumb-ass question: is it possible to crawl the new wiki pages with a 
script to check for obvious errors such as these?


Angus

Re: The wiki now blocks 'href' as a word

[Angus Leeming]

[EMAIL PROTECTED] wrote:
Does anyone know a perl compatible regexp that matches 'href' but not 
'\href'?


Match all occurences of 'href' that are preceded by zero or more 
whitespace chars and followed by zero or more whitespace chars and an 
'=' char


[\n\t ]*href[\n\t ]*=

Angus

Re: The wiki now blocks 'href' as a word

[Angus Leeming]

[EMAIL PROTECTED] wrote:
Does anyone know a perl compatible regexp that matches 'href' but not 
'\href'?


Match all occurences of 'href' that are preceded by zero or more 
whitespace chars and followed by zero or more whitespace chars and an 
'=' char


[\n\t ]*href[\n\t ]*=

Angus

The new web site and that first image

[Angus Leeming]

The new site is looking fantastic! Way to go, guys! Way to go! (See, 
I've become American :-P)


I see that Rex has created a new graphic for the home page, so 
presumably you're still experimenting with such things. With that as my 
preamble, I'd like to share some comments I have about the image at 
http://www.lyx.org/test (OLDIMG) and that at 
http://www.lyx.org/test/HomeNewGraphic (NEWIMG):


1. (OLDIMG) The download button image with the LyX mascot is a very 
powerful piece of imagery. I would urge you to keep it.
2. (OLDIMG) The rest of that graphic (a view of the LyX window) isn't 
very exciting at all.
3. (NEWIMG) The background of the new image attempts to give people a 
flavour of the typesetting power of LaTeX.

4. (NEWIMG) The foreground of the new image is entirely lacking in punch.
5. (NEWIMG) The new image cries out for some anti-aliasing.

Can I suggest that you combine some of the ideas of the two images into 
something new. Some suggestions to consider:


1. I like the idea of showing off the power of LaTeX in a background 
splash. However, I think you need to be careful about exactly what you 
want to put into that image. Rex's new image gives me the feeling of a 
layout engine like Scribus rather than the logical, uncluttered feel of 
LyX in everyday use.


2. The background image should be separate from the download button. It 
would be doubly funky to use some CSS magic to get a clickable button 
that looks as striking as the existing one, but really I think that only 
the green button itself should be a link.


Conceptually something like the idea below. (No, I'm not proposing 
wholesale use of absolute positioning; just trying to get the visual 
idea across.)


Regards,
Angus

?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en

head
  titleExample/title
  style type='text/css'!--
.lyxsplash {
  background-image: url(lyxsplash.png);
  position: absolute;
  width: 300px;
  height: 150px;
}

.lyxmascot {
  position: absolute;
  bottom: 60px;
  right: 150px;
  width: 50px;
  height: 50px;
}

.downloadbutton{
  position: absolute;
  bottom: 10px;
  right: 50px;
  width: 100px;
  height: 50px;
}
--/style
/head

body

div class=lyxsplash
  div class=lyxmascot
img src=lyxmascot.png /
  /div
  div class=downloadbutton
a href=Downloadimg src=downloadbutton.png //a
  /div
div

/body
/html

inline: downloadbutton.pnginline: lyxmascot.pnginline: lyxsplash.png

The new web site and that first image

[Angus Leeming]

The new site is looking fantastic! Way to go, guys! Way to go! (See, 
I've become American :-P)


I see that Rex has created a new graphic for the home page, so 
presumably you're still experimenting with such things. With that as my 
preamble, I'd like to share some comments I have about the image at 
http://www.lyx.org/test (OLDIMG) and that at 
http://www.lyx.org/test/HomeNewGraphic (NEWIMG):


1. (OLDIMG) The download button image with the LyX mascot is a very 
powerful piece of imagery. I would urge you to keep it.
2. (OLDIMG) The rest of that graphic (a view of the LyX window) isn't 
very exciting at all.
3. (NEWIMG) The background of the new image attempts to give people a 
flavour of the typesetting power of LaTeX.

4. (NEWIMG) The foreground of the new image is entirely lacking in punch.
5. (NEWIMG) The new image cries out for some anti-aliasing.

Can I suggest that you combine some of the ideas of the two images into 
something new. Some suggestions to consider:


1. I like the idea of showing off the power of LaTeX in a background 
splash. However, I think you need to be careful about exactly what you 
want to put into that image. Rex's new image gives me the feeling of a 
layout engine like Scribus rather than the logical, uncluttered feel of 
LyX in everyday use.


2. The background image should be separate from the download button. It 
would be doubly funky to use some CSS magic to get a clickable button 
that looks as striking as the existing one, but really I think that only 
the green button itself should be a link.


Conceptually something like the idea below. (No, I'm not proposing 
wholesale use of absolute positioning; just trying to get the visual 
idea across.)


Regards,
Angus


http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;>
http://www.w3.org/1999/xhtml; xml:lang="en">


  Example
  





  

  
  

  





<><><>

Am I meant to be able to edit the new site without a password???

[Angus Leeming]

I get asked for a password if I click on the Edit link at the bottom of
http://www.lyx.org/test/Download?skin=pmwiki

However, I can just walk into
http://www.lyx.org/test/wiki/index.php/Web/HomePage?action=edit

I suspect you don't want that :-P

Angus

Am I meant to be able to edit the new site without a password???

[Angus Leeming]

I get asked for a password if I click on the Edit link at the bottom of
http://www.lyx.org/test/Download?skin=pmwiki

However, I can just walk into
http://www.lyx.org/test/wiki/index.php/Web/HomePage?action=edit

I suspect you don't want that :-P

Angus

Re: Small problem with BlanketPermission on the new site.

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

[EMAIL PROTECTED] writes:


On Mon, 7 Apr 2008, Angus Leeming wrote:


While I'm at it ;-)

Hi Angus,

Would it be to much to ask you to just fix it? 


I am not sure his employer would allow him to %-]


:-P

I see many other pages are afflicted by the -- and '...' nastiness. The 
sed script below seems to do the trick on http://www.lyx.org/test/WhatIsLyX.


The pages look much brighter now! What's with the funny slanty lines at 
the top though?


Regards,
Angus

# Replace all occurrences of -- with mdash;
# Ignore HTML comment delimiters !-- and --
[EMAIL PROTECTED]([^!]\)--\([^]\)@\1\mdash;[EMAIL PROTECTED]

# If the line does not start p class='vspace', break.
/p class='vspace'/!b

# Temporarily append a \n after all '...' pairs.
s@'[^']\{1,\}'@\
@g

# Replace all ... with ldquo;...rdquo;
s@\([^]\{1,\}\)@\ldquo;\1\rdquo;@g

# Replace all '...' with ldquo;...rdquo;
# The loop fixes up the rightmost '...' on each iteration
# until there's only the p class='vspace' on the first line left.
:loop
[EMAIL PROTECTED](\n.*\) '\([^']\{1,\}\)'@\1 \ldquo;\2\rdquo;@
tloop

# Remove all those \n placeholders.
[EMAIL PROTECTED]@@g

# The end.

Re: Small problem with BlanketPermission on the new site.

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

[EMAIL PROTECTED] writes:


On Mon, 7 Apr 2008, Angus Leeming wrote:


While I'm at it ;-)

Hi Angus,

Would it be to much to ask you to just fix it? 


I am not sure his employer would allow him to %-]


:-P

I see many other pages are afflicted by the -- and '...' nastiness. The 
sed script below seems to do the trick on http://www.lyx.org/test/WhatIsLyX.


The pages look much brighter now! What's with the funny slanty lines at 
the top though?


Regards,
Angus

# Replace all occurrences of -- with 
# Ignore HTML comment delimiters 
[EMAIL PROTECTED]([^!]\)--\([^>]\)@\1\[EMAIL PROTECTED]

# If the line does not start , break.
//!b

# Temporarily append a \n after all '...' pairs.
s@'[^']\{1,\}'@&\
@g

# Replace all "..." with ...
s@"\([^"]\{1,\}\)"@\\1\@g

# Replace all '...' with ...
# The loop fixes up the rightmost '...' on each iteration
# until there's only the  on the first line left.
:loop
[EMAIL PROTECTED](\n.*\) '\([^']\{1,\}\)'@\1 \\2\@
tloop

# Remove all those \n placeholders.
[EMAIL PROTECTED]@@g

# The end.

Small problem with BlanketPermission on the new site.

[Angus Leeming]

We had one curmudgeonly gentleman, John Weiss, who point blank refused 
to licence his contribution to LyX under the GPL version 2 or later. The 
old flavour of this page has him down as licencing his contributions 
under the artistic licence. The new page does not...


http://www.lyx.org/test/AboutLyX
has two links that need to be completed, Introduction to LyX and 
Press about LyX.


Is this the final skin? It's a bit grey for my taste...

Angus

Re: Small problem with BlanketPermission on the new site.

[Angus Leeming]

Angus Leeming wrote:
We had one curmudgeonly gentleman, John Weiss, who point blank refused 
to licence his contribution to LyX under the GPL version 2 or later. The 
old flavour of this page has him down as licencing his contributions 
under the artistic licence. The new page does not...


http://www.lyx.org/test/AboutLyX
has two links that need to be completed, Introduction to LyX and 
Press about LyX.


Is this the final skin? It's a bit grey for my taste...


While I'm at it ;-)

On the home page you have ... its printed output -- or richly 
cross-referenced PDF, just as readily produced -- looks like


Could you replace those -- with mdash;, please?

Ditto, 'finger painting' is probably better written using the HTML codes 
 ldquo; and rdquo;. Having said that, whilst it's not applicable 
there I'd prefer to see more use of qsome quoted text/q rather than 
this non-semantic markup. (LyX cares about WYSIWYM, right? ;-))


Finally, I see that you have this footer to these pages: Copyright 2008 
- The LyX team. I'll retire for the night noting that there is no such 
legal entity and, as such, the statement is meaningless...


Tinkering at the edges-ly yours,
Angus

Small problem with BlanketPermission on the new site.

[Angus Leeming]

We had one curmudgeonly gentleman, John Weiss, who point blank refused 
to licence his contribution to LyX under the GPL version 2 or later. The 
old flavour of this page has him down as licencing his contributions 
under the artistic licence. The new page does not...


http://www.lyx.org/test/AboutLyX
has two links that need to be completed, "Introduction to LyX" and 
"Press about LyX".


Is this the final skin? It's a bit grey for my taste...

Angus

Re: Small problem with BlanketPermission on the new site.

[Angus Leeming]

Angus Leeming wrote:
We had one curmudgeonly gentleman, John Weiss, who point blank refused 
to licence his contribution to LyX under the GPL version 2 or later. The 
old flavour of this page has him down as licencing his contributions 
under the artistic licence. The new page does not...


http://www.lyx.org/test/AboutLyX
has two links that need to be completed, "Introduction to LyX" and 
"Press about LyX".


Is this the final skin? It's a bit grey for my taste...


While I'm at it ;-)

On the home page you have "... its printed output -- or richly 
cross-referenced PDF, just as readily produced -- looks like"


Could you replace those "--" with , please?

Ditto, 'finger painting' is probably better written using the HTML codes 
  and . Having said that, whilst it's not applicable 
there I'd prefer to see more use of some quoted text rather than 
this non-semantic markup. (LyX cares about WYSIWYM, right? ;-))


Finally, I see that you have this footer to these pages: "Copyright 2008 
- The LyX team". I'll retire for the night noting that there is no such 
legal entity and, as such, the statement is meaningless...


Tinkering at the edges-ly yours,
Angus

Re: LyX site - left to do?

[Angus Leeming]

Angus Leeming wrote:

Pavel Sanda wrote:

I think we're ready to go live.


just few bits i've found during scanning the whole structure:

- what is lyx, features, get involved pages, donate contain unreadbale 
chars   (copyright sign Lars name,...)
- whats is lyx - credits links at the end will be b0rken once pages 
are official

- the picture in the begining of features is visually disturbing

- i experienced one annoyance, but it may be difficult to 
automatically solve
  it: for example go to About LyX section. you get some links to 
browse through
  but once you click on some, you lose the context of others. this was 
much
  more naturally solved in old pages, where the whole subsctructure 
uncollapses

  and stays uncollapsed until your were in that section.
  it becomes even worse once you get back, because we dont have 
different link colors

  for already visited pages - you get lost where you have (not) been.

  maybe Christian will know some wiki magic how to do?

- the proposed trick with (:title :) doesn't work

- if you dont see some reason to keep green sections in TODO i think 
it will be

  good to remove them for better overview.

- the 'Latest Changes' item is misguiding. but i'm not sure what will 
be better-

  'Trac' or  'Timeline / Browser'. another proposals?

pavel



What happened to all the old news in at
http://www.lyx.org/test/News?

The email addresses at I18n are obfuscated nicely. However, at least 
some of them appear to be wrong:


Translator: Szőke Sándor
Right Click; Copy shortcut;
Ctnl-V: mailto:[EMAIL PROTECTED]


I prefer the hyperlinked name of the translator in I18n to the Contact 
of the Credits page.


The BlanketPermission page doesn't have any obfuscation.

The PayPal link at Donate is still busted (invisible, actually) on IE. 
Oh, I see you've just removed it!


HTH,
Angus




Can you keep the footer information of the existing site? This stuff:

[W3C XHTML] [W3C CSS]
At least 8940277 hits on this page.
Webmaster: lyx-devel at lists dot lyx dot org
Page last updated on 2008-03-29 (year-month-day).

Angus

Re: LyX site - left to do?

[Angus Leeming]

Angus Leeming wrote:

Pavel Sanda wrote:

I think we're ready to go live.


just few bits i've found during scanning the whole structure:

- what is lyx, features, get involved pages, donate contain unreadbale 
chars   (copyright sign Lars name,...)
- whats is lyx - credits links at the end will be b0rken once pages 
are official

- the picture in the begining of features is visually disturbing

- i experienced one annoyance, but it may be difficult to 
automatically solve
  it: for example go to About LyX section. you get some links to 
browse through
  but once you click on some, you lose the context of others. this was 
much
  more naturally solved in old pages, where the whole subsctructure 
uncollapses

  and stays uncollapsed until your were in that section.
  it becomes even worse once you get back, because we dont have 
different link colors

  for already visited pages - you get lost where you have (not) been.

  maybe Christian will know some wiki magic how to do?

- the proposed trick with (:title :) doesn't work

- if you dont see some reason to keep green sections in TODO i think 
it will be

  good to remove them for better overview.

- the 'Latest Changes' item is misguiding. but i'm not sure what will 
be better-

  'Trac' or  'Timeline / Browser'. another proposals?

pavel



What happened to all the old news in at
http://www.lyx.org/test/News?

The email addresses at I18n are obfuscated nicely. However, at least 
some of them appear to be wrong:


Translator: Szőke Sándor
Right Click; Copy shortcut;
Ctnl-V: mailto:[EMAIL PROTECTED]


I prefer the hyperlinked name of the translator in I18n to the "Contact" 
of the Credits page.


The BlanketPermission page doesn't have any obfuscation.

The PayPal link at Donate is still busted (invisible, actually) on IE. 
Oh, I see you've just removed it!


HTH,
Angus




Can you keep the footer information of the existing site? This stuff:

[W3C XHTML] [W3C CSS]
At least 8940277 hits on this page.
Webmaster: lyx-devel at lists dot lyx dot org
Page last updated on 2008-03-29 (year-month-day).

Angus

Re: LyX site - left to do?

[Angus Leeming]

[EMAIL PROTECTED] wrote:
I've talked to Andrei, Rex etc and from a design point of view, we're 
ready to go live. So what else is missing before a release?


It's looking very nice, but I notice when playing with the different 
skins at http://www.lyx.org/test/Download that h1LyX Downloads/h1 
isn't visible at all in the default lyx skin. It is in all the other 
skins...


Of course, I'm not sure that's a bad thing, given that you also have 
div id='page-subtitle'download/div, but it seems strange to swallow 
h1 elements.


Incidentally, the w3c validator thinks your HTML is invalid...
http://validator.w3.org/

It likes the CSS better...
http://jigsaw.w3.org/css-validator/

Angus

Re: LyX site - left to do?

[Angus Leeming]

Pavel Sanda wrote:

I think we're ready to go live.


just few bits i've found during scanning the whole structure:

- what is lyx, features, get involved pages, donate contain unreadbale chars 
  (copyright sign Lars name,...)

- whats is lyx - credits links at the end will be b0rken once pages are official
- the picture in the begining of features is visually disturbing

- i experienced one annoyance, but it may be difficult to automatically solve
  it: for example go to About LyX section. you get some links to browse through
  but once you click on some, you lose the context of others. this was much
  more naturally solved in old pages, where the whole subsctructure uncollapses
  and stays uncollapsed until your were in that section.
  it becomes even worse once you get back, because we dont have different link 
colors
  for already visited pages - you get lost where you have (not) been.

  maybe Christian will know some wiki magic how to do?

- the proposed trick with (:title :) doesn't work

- if you dont see some reason to keep green sections in TODO i think it will be
  good to remove them for better overview.

- the 'Latest Changes' item is misguiding. but i'm not sure what will be better-
  'Trac' or  'Timeline / Browser'. another proposals?

pavel



What happened to all the old news in at
http://www.lyx.org/test/News?

The email addresses at I18n are obfuscated nicely. However, at least 
some of them appear to be wrong:


Translator: Szőke Sándor
Right Click; Copy shortcut;
Ctnl-V: mailto:[EMAIL PROTECTED]


I prefer the hyperlinked name of the translator in I18n to the Contact 
of the Credits page.


The BlanketPermission page doesn't have any obfuscation.

The PayPal link at Donate is still busted (invisible, actually) on IE. 
Oh, I see you've just removed it!


HTH,
Angus

Re: LyX site - left to do?

[Angus Leeming]

[EMAIL PROTECTED] wrote:
I've talked to Andrei, Rex etc and from a design point of view, we're 
ready to go live. So what else is missing before a release?


It's looking very nice, but I notice when playing with the different 
skins at http://www.lyx.org/test/Download that LyX Downloads 
isn't visible at all in the default lyx skin. It is in all the other 
skins...


Of course, I'm not sure that's a bad thing, given that you also have 
download, but it seems strange to swallow 
 elements.


Incidentally, the w3c validator thinks your HTML is invalid...
http://validator.w3.org/

It likes the CSS better...
http://jigsaw.w3.org/css-validator/

Angus

Re: LyX site - left to do?

[Angus Leeming]

Pavel Sanda wrote:

I think we're ready to go live.


just few bits i've found during scanning the whole structure:

- what is lyx, features, get involved pages, donate contain unreadbale chars 
  (copyright sign Lars name,...)

- whats is lyx - credits links at the end will be b0rken once pages are official
- the picture in the begining of features is visually disturbing

- i experienced one annoyance, but it may be difficult to automatically solve
  it: for example go to About LyX section. you get some links to browse through
  but once you click on some, you lose the context of others. this was much
  more naturally solved in old pages, where the whole subsctructure uncollapses
  and stays uncollapsed until your were in that section.
  it becomes even worse once you get back, because we dont have different link 
colors
  for already visited pages - you get lost where you have (not) been.

  maybe Christian will know some wiki magic how to do?

- the proposed trick with (:title :) doesn't work

- if you dont see some reason to keep green sections in TODO i think it will be
  good to remove them for better overview.

- the 'Latest Changes' item is misguiding. but i'm not sure what will be better-
  'Trac' or  'Timeline / Browser'. another proposals?

pavel



What happened to all the old news in at
http://www.lyx.org/test/News?

The email addresses at I18n are obfuscated nicely. However, at least 
some of them appear to be wrong:


Translator: Szőke Sándor
Right Click; Copy shortcut;
Ctnl-V: mailto:[EMAIL PROTECTED]


I prefer the hyperlinked name of the translator in I18n to the "Contact" 
of the Credits page.


The BlanketPermission page doesn't have any obfuscation.

The PayPal link at Donate is still busted (invisible, actually) on IE. 
Oh, I see you've just removed it!


HTH,
Angus

Re: lyx-devel Digest 16 Mar 2008 14:59:52 -0000 Issue 5651

[Angus Leeming]

Pavel Sanda wrote:

wasn't WYSIWYM as well). The second time, I fixed the errant line
breaks in Notepad++. I'm willing to fix it again to look the way you
want if you let me know specifically what should change (indentation,
spacing, line breaks, ?).


just look into the patch you sent and compare - lines with + lines.
indentation is gone. line width is gone. it should be easy to see the
structure (indent  spacing) and to read the paragraphs (intelligent
line break).


Go grab HTML Tidy (http://tidy.sourceforge.net/), originally developed 
by the W3C's Dave Raggett. You'll wonder how you ever survived without it.


Regards,
Angus

Re: lyx-devel Digest 16 Mar 2008 14:59:52 -0000 Issue 5651

[Angus Leeming]

Pavel Sanda wrote:

wasn't WYSIWYM as well). The second time, I fixed the errant line
breaks in Notepad++. I'm willing to fix it again to look the way you
want if you let me know specifically what should change (indentation,
spacing, line breaks, ?).


just look into the patch you sent and compare "-" lines with "+" lines.
indentation is gone. line width is gone. it should be easy to see the
structure (indent & spacing) and to read the paragraphs (intelligent
line break).


Go grab HTML Tidy (http://tidy.sourceforge.net/), originally developed 
by the W3C's Dave Raggett. You'll wonder how you ever survived without it.


Regards,
Angus

Re: [PATCH] Custom LayoutIterator

[Angus Leeming]

rgheck [EMAIL PROTECTED] writes:
 In r23505, I removed the ability to index into the LayoutList held in a 
 TextClass, because it seemed too implementation dependent, and just 
 ugly. I replaced it with an iterator. Unfortunately, the iterator was 
 kind of ugly too, because it wasn't returning pointers to Layouts but 
 rather pointers to LayoutPtrs, since a LayoutList is a 
 std::vectorboost::shared_ptrLayout .
 
 Actually: Why is that? Could we just change LayoutList to a 
 std::vectorLayout?
 
 Anyway, until we do that, it seems better to have a custom iterator here 
 that will allow us to iterate directly over the layouts. This patch is 
 supposed to do that. I've tested it a bit, and it seems to work fine. 
 But I've not written one of these before, so I'd appreciate any comments.

Writing a standards-conformant iterator is *hard*. There's a Boost library 
called (wait for it...) Iterator to make it easy to write an iterator that 
won't come back and bite you later. It's written by Dave Abrahams, so it's one 
of Boost's better, more robust libraries.

http://www.boost.org/libs/iterator/doc/index.html

Whilst it appears to be fashionable to bash Boost here, this is one of those 
libraries that's made it into tr1 and so will become just as standard as the 
rest of the standard library.

All this of course without reviewing your code. Take or leave the suggestion 
as you choose.

Angus

Re: [PATCH] Custom LayoutIterator

[Angus Leeming]

rgheck <[EMAIL PROTECTED]> writes:
> In r23505, I removed the ability to index into the LayoutList held in a 
> TextClass, because it seemed too implementation dependent, and just 
> ugly. I replaced it with an iterator. Unfortunately, the iterator was 
> kind of ugly too, because it wasn't returning pointers to Layouts but 
> rather pointers to LayoutPtrs, since a LayoutList is a 
> std::vector.
> 
> Actually: Why is that? Could we just change LayoutList to a 
> std::vector?
> 
> Anyway, until we do that, it seems better to have a custom iterator here 
> that will allow us to iterate directly over the layouts. This patch is 
> supposed to do that. I've tested it a bit, and it seems to work fine. 
> But I've not written one of these before, so I'd appreciate any comments.

Writing a standards-conformant iterator is *hard*. There's a Boost library 
called (wait for it...) Iterator to make it easy to write an iterator that 
won't come back and bite you later. It's written by Dave Abrahams, so it's one 
of Boost's better, more robust libraries.

http://www.boost.org/libs/iterator/doc/index.html

Whilst it appears to be fashionable to bash Boost here, this is one of those 
libraries that's made it into tr1 and so will become just as "standard" as the 
rest of the standard library.

All this of course without reviewing your code. Take or leave the suggestion 
as you choose.

Angus

Re: Warnings for Pavel

[Angus Leeming]

Dov Feldstern wrote:
So now the question is: do we need this function at all at this point? 
Since it seems to have been doing nothing for the past three years, can 
we just get rid of it? Does anyone know if what the code that's in there 
*should* have been doing is still needed?


You should never have to restart LyX for your preference change to 
take effect. That's just lame. So, keep the function but give your own 
changes precedence over worries about the function's functionality.


Angus (just my two cents, of course...)

Re: boost version

[Angus Leeming]

Stefan Schimanski wrote:

Hi!

I would like to use the multi_index classes from the boost library. 
Unfortunately this is not in the boost version we have in svn. Is it 
just old or do we have only a selection of boost modules?


Only those libraries that are actually used by LyX. While you're 
adding MultiIndex, you could probably also remove Spirit. Never got used.


Angus

No link to PayPal from the donations page viewed with IE

[Angus Leeming]

I notice that the LyX donations page, 
http://www.lyx.org/donations.php, is unable to display the PayPal 
image. As a result, the admonition to click the button below isn't 
going to bring in much hard cash :-P


Ah, interesting. All looks fine with Firefox 2.0, but things are 
broken with IE7. Microsoft-bashing aside, it's probably in your 
interests to make IE happy here ;-)


A quick google search reveals that this is a known problem. See 
http://www.webmasterworld.com/forum88/4894.htm for a discussion and 
some solutions.


Kind regards,
Angus

Re: Warnings for Pavel

[Angus Leeming]

Dov Feldstern wrote:
So now the question is: do we need this function at all at this point? 
Since it seems to have been doing nothing for the past three years, can 
we just get rid of it? Does anyone know if what the code that's in there 
*should* have been doing is still needed?


You should never have to restart LyX for your preference change to 
take effect. That's just lame. So, keep the function but give your own 
changes precedence over worries about the function's functionality.


Angus (just my two cents, of course...)

Re: boost version

[Angus Leeming]

Stefan Schimanski wrote:

Hi!

I would like to use the multi_index classes from the boost library. 
Unfortunately this is not in the boost version we have in svn. Is it 
just old or do we have only a selection of boost modules?


Only those libraries that are actually used by LyX. While you're 
adding MultiIndex, you could probably also remove Spirit. Never got used.


Angus

No link to PayPal from the donations page viewed with IE

[Angus Leeming]

I notice that the LyX donations page, 
http://www.lyx.org/donations.php, is unable to display the PayPal 
image. As a result, the admonition to "click the button below" isn't 
going to bring in much hard cash :-P


Ah, interesting. All looks fine with Firefox 2.0, but things are 
broken with IE7. Microsoft-bashing aside, it's probably in your 
interests to make IE happy here ;-)


A quick google search reveals that this is a known problem. See 
http://www.webmasterworld.com/forum88/4894.htm for a discussion and 
some solutions.


Kind regards,
Angus

Re: Warnings for Pavel

[Angus Leeming]

Pavel Sanda wrote:

Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because something 
is fishy about it. AFAICT, this function doesn't do anything... JMarc 
took a look and I think he also wasn't sure about it... So before just 
fixing the warnings, we ought to try and figure out what this function 
*should* be doing, and whether it's necessary at all. I'm pretty sure I 
went quite far back in history, and it hasn't been doing anything for 
ages...

but there is some code for certain cases, no?
Yes, but that code is never executed, which is even more disturbing. Notice 
that the just before the switch, tag is set to RC_LAST, which is the *last* 
case in the switch...


Looks like I was smoking something funny at the time ;-)

i see now. 
i would ask Angus http://www.lyx.org/trac/changeset/9485 , whats the purpose of that

code.


If memory serves, the idea was to enable LyX to handle updates to the 
preferences that traditionally required the user to restart LyX for 
the changed preference to take effect.


I've no idea why I initialized tag as I did. Maybe, LyX just blew up 
when the switch was executed?


1876LyXRC::LyXRCTags tag = LyXRC::RC_LAST;
1877switch (tag) {

Angus

Re: Warnings for Pavel

[Angus Leeming]

Pavel Sanda wrote:

Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because something 
is fishy about it. AFAICT, this function doesn't do anything... JMarc 
took a look and I think he also wasn't sure about it... So before just 
fixing the warnings, we ought to try and figure out what this function 
*should* be doing, and whether it's necessary at all. I'm pretty sure I 
went quite far back in history, and it hasn't been doing anything for 
ages...

but there is some code for certain cases, no?
Yes, but that code is never executed, which is even more disturbing. Notice 
that the just before the switch, tag is set to RC_LAST, which is the *last* 
case in the switch...


Looks like I was smoking something funny at the time ;-)

i see now. 
i would ask Angus http://www.lyx.org/trac/changeset/9485 , whats the purpose of that

code.


If memory serves, the idea was to enable LyX to handle updates to the 
preferences that traditionally required the user to restart LyX for 
the changed preference to take effect.


I've no idea why I initialized tag as I did. Maybe, LyX just blew up 
when the switch was executed?


1876LyXRC::LyXRCTags tag = LyXRC::RC_LAST;
1877switch (tag) {

Angus

Re: LyXRC descriptions / tooltips

[Angus Leeming]

Jürgen Spitzmüller [EMAIL PROTECTED] writes:

 
 Dov Feldstern wrote:
  I just noticed that LyXRC::getDescription (in which I made some changes
  for the visual cursor stuff) is #if-fed out because it's not used.
 
  1. So is there any point in my making changes in it?
  2. Should we just get rid of it?
  3. Can I add the description as a tooltip, instead?
 
 I think the descriptions there are rather What's this? than tooltips 
(i.e., 
 more verbose). Unfortunately, we do not have working whatsthis in our 
 frontend.

This file is a left-over from the XForms days. The other frontends never made 
use of it. I believe that it should now die.

Angus

Re: LyXRC descriptions / tooltips

[Angus Leeming]

Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:

> 
> Dov Feldstern wrote:
> > I just noticed that LyXRC::getDescription (in which I made some changes
> > for the visual cursor stuff) is #if-fed out because it's not used.
> >
> > 1. So is there any point in my making changes in it?
> > 2. Should we just get rid of it?
> > 3. Can I add the description as a tooltip, instead?
> 
> I think the descriptions there are rather "What's this?" than tooltips 
(i.e., 
> more verbose). Unfortunately, we do not have working whatsthis in our 
> frontend.

This file is a left-over from the XForms days. The other frontends never made 
use of it. I believe that it should now die.

Angus

Re: r22385 - in /lyx-devel/trunk/src: ModuleList.cpp ModuleLi...

[Angus Leeming]

[EMAIL PROTECTED] wrote:
 Author: rgheck
 Date: Sat Jan  5 17:49:49 2008
 New Revision: 22385

 URL: http://www.lyx.org/trac/changeset/22385
 Log:
 Implement isAvaiable in ModuleList.

Call be blind, but I cannot see where you set LyXModule::checked to 
True...


Incidentally, it's usually considered bad practice to expose member 
variables directly (packageList, description, etc). How can you 
prevent someone resetting their values after they've been initialized 
in the c-tor?


It's fun to see so much LyX activity.

Wishing you all a very fruitful 2008,
Angus

Re: r22374 - /lyx-devel/trunk/src/insets/InsetGraphicsParams.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: bpeng
Date: Sat Jan  5 05:43:13 2008
New Revision: 22374

URL: http://www.lyx.org/trac/changeset/22374
Log:
Embedding: does not write inzipName option in InsetGraphics because inzipName 
is now automatically determined


Isn't this a format change?

A.

Re: r22368 - in /lyx-devel/branches/BRANCH_1_5_X: src/fronten...

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: lasgouttes
Date: Fri Jan  4 18:04:07 2008
New Revision: 22368

URL: http://www.lyx.org/trac/changeset/22368
Log:
remove extra menu expansion which causes multiple warnings about shortcuts

-
-   Menu menu;
-   menubackend_.expand(menubackend_.getMenubar(), menu, 
owner_-buffer());


Why not add an isExpanded member to menubackend_, set to true by 
.expand ?


A.

Re: r22373 - /lyx-devel/trunk/src/support/minizip/zipunzip.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: bpeng
Date: Sat Jan  5 05:39:01 2008
New Revision: 22373

URL: http://www.lyx.org/trac/changeset/22373
Log:
zipunzip.cpp: Replace makedir etc with versions in support::FileName, fix a bug 
in extracting subdirectories

Modified:
lyx-devel/trunk/src/support/minizip/zipunzip.cpp

Modified: lyx-devel/trunk/src/support/minizip/zipunzip.cpp
URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/support/minizip/zipunzip.cpp?rev=22373
==
--- lyx-devel/trunk/src/support/minizip/zipunzip.cpp (original)
+++ lyx-devel/trunk/src/support/minizip/zipunzip.cpp Sat Jan  5 05:39:01 2008
@@ -55,6 +55,7 @@
 #include string
 #include vector
 #include utility
+#include support/FileName.h


If memory serves, local .h files should be included before system 
header files. That way, you discover hidden dependencies that might 
break compilation.



+   if ((*popt_extract_without_path)==0) {
+   printf(Create directory %s\n, filename_inzip);



+   fout=fopen(full_path, wb);


Urgs. This isn't C++. Why are you using C I/O here?

Angus

Re: r22385 - in /lyx-devel/trunk/src: ModuleList.cpp ModuleLi...

[Angus Leeming]

[EMAIL PROTECTED] wrote:
> Author: rgheck
> Date: Sat Jan  5 17:49:49 2008
> New Revision: 22385
>
> URL: http://www.lyx.org/trac/changeset/22385
> Log:
> Implement isAvaiable in ModuleList.

Call be blind, but I cannot see where you set LyXModule::checked to 
True...


Incidentally, it's usually considered bad practice to expose member 
variables directly (packageList, description, etc). How can you 
prevent someone resetting their values after they've been initialized 
in the c-tor?


It's fun to see so much LyX activity.

Wishing you all a very fruitful 2008,
Angus

Re: r22374 - /lyx-devel/trunk/src/insets/InsetGraphicsParams.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: bpeng
Date: Sat Jan  5 05:43:13 2008
New Revision: 22374

URL: http://www.lyx.org/trac/changeset/22374
Log:
Embedding: does not write inzipName option in InsetGraphics because inzipName 
is now automatically determined


Isn't this a format change?

A.

Re: r22368 - in /lyx-devel/branches/BRANCH_1_5_X: src/fronten...

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: lasgouttes
Date: Fri Jan  4 18:04:07 2008
New Revision: 22368

URL: http://www.lyx.org/trac/changeset/22368
Log:
remove extra menu expansion which causes multiple warnings about shortcuts

-
-   Menu menu;
-   menubackend_.expand(menubackend_.getMenubar(), menu, 
owner_->buffer());


Why not add an "isExpanded" member to menubackend_, set to true by 
.expand ?


A.

Re: r22373 - /lyx-devel/trunk/src/support/minizip/zipunzip.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

Author: bpeng
Date: Sat Jan  5 05:39:01 2008
New Revision: 22373

URL: http://www.lyx.org/trac/changeset/22373
Log:
zipunzip.cpp: Replace makedir etc with versions in support::FileName, fix a bug 
in extracting subdirectories

Modified:
lyx-devel/trunk/src/support/minizip/zipunzip.cpp

Modified: lyx-devel/trunk/src/support/minizip/zipunzip.cpp
URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/support/minizip/zipunzip.cpp?rev=22373
==
--- lyx-devel/trunk/src/support/minizip/zipunzip.cpp (original)
+++ lyx-devel/trunk/src/support/minizip/zipunzip.cpp Sat Jan  5 05:39:01 2008
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include "support/FileName.h"


If memory serves, "local" .h files should be included before system 
header files. That way, you discover hidden dependencies that might 
break compilation.



+   if ((*popt_extract_without_path)==0) {
+   printf("Create directory %s\n", filename_inzip);



+   fout=fopen(full_path, "wb");


Urgs. This isn't C++. Why are you using C I/O here?

Angus

Re: [Cvslog] r22081 - /lyx-devel/trunk/src/support/SystemcallPrivate.cpp

[Angus Leeming]

Enrico Forestieri wrote:
   configure_command_ = os::python() + ' ' +
   quoteName(configure_script.toFilesystemEncoding()) +
   with_version_suffix();
 
 You are right. A parser would be needed, and it is going to become
 cumbersome and error prone.

It just so happens that I wrote one using Boost.Spirit a couple of years
ago. Never got round to integrating it into LyX unfortunately. It's a
formally correct parser of a subset of sh. Certainly capable of handling
our command definition strings.

See
http://www.lyx.org/~leeming/libs/child/doc/html/parse_pseudo_command_line.html

The code's been languishing in the
boost/child
libs/child
subdirectories of http://www.lyx.org/~leeming

Feel free to grab it. If you're interested I can certainly walk you through
it all.

-- 
Angus

Re: [Cvslog] r22081 - /lyx-devel/trunk/src/support/SystemcallPrivate.cpp

[Angus Leeming]

Enrico Forestieri wrote:
>>   configure_command_ = os::python() + ' ' +
>>   quoteName(configure_script.toFilesystemEncoding()) +
>>   with_version_suffix();
> 
> You are right. A parser would be needed, and it is going to become
> cumbersome and error prone.

It just so happens that I wrote one using Boost.Spirit a couple of years
ago. Never got round to integrating it into LyX unfortunately. It's a
formally correct parser of a subset of sh. Certainly capable of handling
our command definition strings.

See
http://www.lyx.org/~leeming/libs/child/doc/html/parse_pseudo_command_line.html

The code's been languishing in the
boost/child
libs/child
subdirectories of http://www.lyx.org/~leeming

Feel free to grab it. If you're interested I can certainly walk you through
it all.

-- 
Angus

Re: System call problem?

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 I know you would eventually praise the good old xforms way of doing
 things :)

LOL. As the man what wrote that dialog, I seem to remember that we killed
it because it wasn't LyX's job to be a taskmgr-like GUI.

I believe John and Asger were particularly convincing in this regard.

-- 
Angus

Re: System call problem?

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> I know you would eventually praise the good old xforms way of doing
> things :)

LOL. As the man what wrote that dialog, I seem to remember that we killed
it because it wasn't LyX's job to be a taskmgr-like GUI.

I believe John and Asger were particularly "convincing" in this regard.

-- 
Angus

Re: [patch] tex2lyx support for the otherlanguage environment

[Angus Leeming]

Andre Poenitz [EMAIL PROTECTED] writes:
 [Btw, this is one of the cases were I do not see actual benefits over
 global variables. If we had several instances or needed complicated
 construction/destruction matters would be different...]

Several instances? Your confused me ol' china. Neither existing code nor 
proposed code change anything in that regard.

The benefits, in my opinion are primarily a documentation of intent. However, 
using an accessor would mean we could reduce use of those nasty null-
terminated arrays to simply initialize a vectorstring.

Merry Christmas to you all,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Andre Poenitz [EMAIL PROTECTED] writes:
 So maybe the macro is not the best idea after all.

Maybe I'll dig into the boost preprocessor library to write something like:

vectorstring opts = LYX_INITIALIZE_VECTOR(a, b, c);

Compile times would surely make you smile.

SCNR backly,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Andre Poenitz wrote:
 Given that the plain C++ version
 
 char const *d[] = { a, b, c };
 vectorstring v(d, d + sizeof(d) / sizeof(d[0]));
 
 is - taking the extra #include boost/whatever.hpp line into
 account - not even longer to type than any boost based solution
 I doubt the boost stuff would survive for long in tex2lyx...

The SCNR backly was meant to imply a gentle laugh at us both.

Angus

ps, Uwe, I didn't mean to  scare you off. I'll retreat under my stone
again.

Re: [patch] tex2lyx support for the otherlanguage environment

[Angus Leeming]

Andre Poenitz <[EMAIL PROTECTED]> writes:
> [Btw, this is one of the cases were I do not see actual benefits over
> global variables. If we had several instances or needed complicated
> construction/destruction matters would be different...]

Several instances? Your confused me ol' china. Neither existing code nor 
proposed code change anything in that regard.

The benefits, in my opinion are primarily a documentation of intent. However, 
using an accessor would mean we could reduce use of those nasty null-
terminated arrays to simply initialize a vector.

Merry Christmas to you all,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Andre Poenitz <[EMAIL PROTECTED]> writes:
> So maybe the macro is not the best idea after all.

Maybe I'll dig into the boost preprocessor library to write something like:

vector opts = LYX_INITIALIZE_VECTOR("a", "b", "c");

Compile times would surely make you smile.

SCNR backly,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Andre Poenitz wrote:
> Given that the plain C++ version
> 
> char const *d[] = { "a", "b", "c" };
> vector v(d, d + sizeof(d) / sizeof(d[0]));
> 
> is - taking the extra #include  line into
> account - not even longer to type than any boost based solution
> I doubt the boost stuff would survive for long in tex2lyx...

The "SCNR backly" was meant to imply a gentle laugh at us both.

Angus

ps, Uwe, I didn't mean to  scare you off. I'll retreat under my stone
again.

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr [EMAIL PROTECTED] writes:
 In general a document has usually not more than 10 options, so
 10 times reforming a vector should be done in less than one millisecond.

I understand. But if nobody tells you of a better way then you'll never grow.

Anyway, thanks for persevering with me. It's been a long time since I wrote 
any C++ and the code I posted was full of C# syntax. At least this time I've 
got the thing to compile ;-)

In your original code, data is actually an array of c-strings, rather than a 
vectorstring. Personally, I'd prefer to use vectorstring, but I'll leave 
it to you to either adapt tex2lyx or the code below :-P

Kindest regards,
Angus

#include algorithm
#include string
#include vector

using std::find;
using std::string;
using std::vector;

namespace lyx {

class element_matches
{
vectorstring const  data_;

public:
element_matches(vectorstring const  data) : data_(data) {}

bool operator()(string const  opt_element) const
{
vectorstring::const_iterator it = std::find(
data_.begin(), data_.end(), opt_element);
return it != data_.end();
}
};


void delete_opt(vectorstring  opts, vectorstring const  to_discard)
{
if (opts.empty() || to_discard.empty())
return;

vectorstring::iterator new_end = std::remove_if(
opts.begin(), opts.end(), element_matches(to_discard));
opts.erase(new_end, opts.end());
}

} // namespace lyx

Re: [patch] tex2lyx support for the otherlanguage environment

[Angus Leeming]

Enrico Forestieri [EMAIL PROTECTED] writes:

 
 On Sun, Dec 09, 2007 at 06:59:36PM +0100, Uwe Stöhr wrote:
 
  What's the problem?
  This code part is from Jürgen as proposal, because Angus and Abdel 
requested a solution without the 
  declaration of the extern global variable as I did in the first version of 
the patch.
  When you have a cleaer solution, please post it. Better to learn now then 
to make the same mistake 
  the next times.
  
  p.s. When you are a real C++ master, then please act like this! Look for 
example at
  http://www.mail-archive.com/lyx-devel-UqbJ+GOpo4+hPH1hqNUYSQ at 
public.gmane.org/msg133041.html
  to see how this is done gentlemen like.
 
 Uwe, the problem is that you happily bash others with harsh manners,
 so you should not be surprised when you are paid with the same money.
 Please, don't give me lessons about gentlemanliness when there are
 posts in the archives demonstrating what a gentleman you are.
 
 That said, I am not a C++ master and don't feel to give lessons to
 anyone. Anyway, the following code appears amusing even to me:
 
 +// the document's main language
 +string document_language;
 +
 +string getDocumentLanguage()
 +{
 + return document_language;
 +}
 +
 +
 +void setDocumentLanguage(string const  lang)
 +{
 + document_language = lang;
 +}
 +
 
 See, you still have a global variable but nonetheless you introduce
 two accessor functions to set and get its value, when it can still
 be freely referenced from everywhere.
 
 So, please forgive me for having been in such a mood that didn't let me
 refrain from returning some harshness.

The thing with politeness is, someone has to start.

Uwe, your setter and getter *are* redundant as things stand, but I have a 
couple of other comments about them too:

1. They could both be called DocumentLanguage. No need to prepend with set 
and get.
2. More importantly, getDocumentLanguage should return a const  to the 
variable.

I agree with Abdel that this binary is very C-ish in structure. It would be a 
reasonable cleanup (IMO) to introduce a Tex2Lyx singleton class and access all 
global state through that.

Something like:

class Tex2Lyx
{
// Singleton pattern
// Make the default ctor private. Will be invoked from the
// singleton accessor.
Tex2Lyx() {}

// Make the copy ctor and assignment operator private.
// Don't actually implement them.
Tex2Lyx(Tex2Lyx const );
Tex2Lyx operator=(Tex2Lyx const );

static boost::scoped_ptrTex2Lyx instance_;

// Data members go here...
string documentLanguage_;

public:
// I see that LyX.h defines ref and cref static functions
// to return reference and const reference views on the global
// instance_. It's probably best to do the same here...
static Tex2Lyx  Instance()
{
if (Tex2Lyx::instance_.get() == 0)
{
instance_.reset(new Tex2Lyx());
}

return *instance_;
}

string const  DocumentLanguage() { return documentLanguage_; }
};

Your preamble.cpp code would then become:

string const  documentLanguage = Tex2Lyx::Instance().DocumentLanguage();

Regards,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr [EMAIL PROTECTED] writes:
 This compiles except that I don't know how to declare the vector correctly.
 Currently all lists are given as:
 char const * const known_fontsizes[] = { 10pt, 11pt, 12pt, 0};

G. I really dislike arrays that use a null pointer to indicate the end.

 When I want to create a vector, would this be something like this?:

// Note that the null pointer has gone...
char const * const known_fontsizes_array[] = { 10pt, 11pt, 12pt };
std::size const known_fontsizes_size = 
sizeof(known_fontsizes_array) / sizeof(known_fontsizes_array[0]);
vectorstring const known_fontsizes(
known_fontsizes_array,
known_fontsizes_array + known_fontsizes_size);

Personally, I think you should use the arrays to initialize the vectors and 
then never, ever go near the arrays again. They're just an invitation for 
coding errors.

You might define a preprocessor macro to perform the drudgery for you. Perhaps 
something like:

#define LYX_BUILD_VECTOR(LYX_CARRAY, LYX_VECTOR) \
{ \
if (LYX_CARRAY != 0  LYX_CARRAY[0] != 0) \
{ \
std::size_t const size = sizeof(LYX_CARRAY) / sizeof(LYX_CARRAY
[0]); \
LYX_VECTOR = std::vectorstring(LYX_CARRAY, LYX_CARRAY + 
size); \
} \
}

char const * const known_fontsizes_array[] = { 10pt, 11pt, 12pt };
vectorstring known_fontsizes;
LYX_BUILD_VECTOR(known_fontsizes_array, known_fontsizes);

Dunno off the top of my head how to make a macro to initialize the vector 
though...

Regards,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr <[EMAIL PROTECTED]> writes:
> In general a document has usually not more than 10 options, so
> 10 times reforming a vector should be done in less than one millisecond.

I understand. But if nobody tells you of "a better way" then you'll never grow.

Anyway, thanks for persevering with me. It's been a long time since I wrote 
any C++ and the code I posted was full of C# syntax. At least this time I've 
got the thing to compile ;-)

In your original code, "data" is actually an array of c-strings, rather than a 
vector. Personally, I'd prefer to use vector, but I'll leave 
it to you to either adapt tex2lyx or the code below :-P

Kindest regards,
Angus

#include 
#include 
#include 

using std::find;
using std::string;
using std::vector;

namespace lyx {

class element_matches
{
vector const & data_;

public:
element_matches(vector const & data) : data_(data) {}

bool operator()(string const & opt_element) const
{
vector::const_iterator it = std::find(
data_.begin(), data_.end(), opt_element);
return it != data_.end();
}
};


void delete_opt(vector & opts, vector const & to_discard)
{
if (opts.empty() || to_discard.empty())
return;

vector::iterator new_end = std::remove_if(
opts.begin(), opts.end(), element_matches(to_discard));
opts.erase(new_end, opts.end());
}

} // namespace lyx

Re: [patch] tex2lyx support for the otherlanguage environment

[Angus Leeming]

Enrico Forestieri <[EMAIL PROTECTED]> writes:

> 
> On Sun, Dec 09, 2007 at 06:59:36PM +0100, Uwe Stöhr wrote:
> 
> > What's the problem?
> > This code part is from Jürgen as proposal, because Angus and Abdel 
requested a solution without the 
> > declaration of the extern global variable as I did in the first version of 
the patch.
> > When you have a cleaer solution, please post it. Better to learn now then 
to make the same mistake 
> > the next times.
> > 
> > p.s. When you are a real C++ master, then please act like this! Look for 
example at
> > http://www.mail-archive.com/lyx-devel-UqbJ+GOpo4+hPH1hqNUYSQ  
public.gmane.org/msg133041.html
> > to see how this is done gentlemen like.
> 
> Uwe, the problem is that you happily bash others with harsh manners,
> so you should not be surprised when you are paid with the same money.
> Please, don't give me lessons about gentlemanliness when there are
> posts in the archives demonstrating what a gentleman you are.
> 
> That said, I am not a C++ master and don't feel to give lessons to
> anyone. Anyway, the following code appears amusing even to me:
> 
> +// the document's main language
> +string document_language;
> +
> +string getDocumentLanguage()
> +{
> + return document_language;
> +}
> +
> +
> +void setDocumentLanguage(string const & lang)
> +{
> + document_language = lang;
> +}
> +
> 
> See, you still have a global variable but nonetheless you introduce
> two accessor functions to set and get its value, when it can still
> be freely referenced from everywhere.
> 
> So, please forgive me for having been in such a mood that didn't let me
> refrain from returning some harshness.

The thing with politeness is, someone has to start.

Uwe, your setter and getter *are* redundant as things stand, but I have a 
couple of other comments about them too:

1. They could both be called DocumentLanguage. No need to prepend with "set" 
and "get".
2. More importantly, getDocumentLanguage should return a "const &" to the 
variable.

I agree with Abdel that this binary is very C-ish in structure. It would be a 
reasonable cleanup (IMO) to introduce a Tex2Lyx singleton class and access all 
global state through that.

Something like:

class Tex2Lyx
{
// Singleton pattern
// Make the default ctor private. Will be invoked from the
// singleton accessor.
Tex2Lyx() {}

// Make the copy ctor and assignment operator private.
// Don't actually implement them.
Tex2Lyx(Tex2Lyx const &);
Tex2Lyx operator=(Tex2Lyx const &);

static boost::scoped_ptr instance_;

// Data members go here...
string documentLanguage_;

public:
// I see that LyX.h defines "ref" and "cref" static functions
// to return reference and const reference views on the global
// instance_. It's probably best to do the same here...
static Tex2Lyx & Instance()
{
if (Tex2Lyx::instance_.get() == 0)
{
instance_.reset(new Tex2Lyx());
}

return *instance_;
}

string const & DocumentLanguage() { return documentLanguage_; }
};

Your preamble.cpp code would then become:

string const & documentLanguage = Tex2Lyx::Instance().DocumentLanguage();

Regards,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr <[EMAIL PROTECTED]> writes:
> This compiles except that I don't know how to declare the vector correctly.
> Currently all lists are given as:
> char const * const known_fontsizes[] = { "10pt", "11pt", "12pt", 0};

G. I really dislike arrays that use a null pointer to indicate the end.

> When I want to create a vector, would this be something like this?:

// Note that the null pointer has gone...
char const * const known_fontsizes_array[] = { "10pt", "11pt", "12pt" };
std::size const known_fontsizes_size = 
sizeof(known_fontsizes_array) / sizeof(known_fontsizes_array[0]);
vector const known_fontsizes(
known_fontsizes_array,
known_fontsizes_array + known_fontsizes_size);

Personally, I think you should use the arrays to initialize the vectors and 
then never, ever go near the arrays again. They're just an invitation for 
coding errors.

You might define a preprocessor macro to perform the drudgery for you. Perhaps 
something like:

#define LYX_BUILD_VECTOR(LYX_CARRAY, LYX_VECTOR) \
{ \
if (LYX_CARRAY != 0 && LYX_CARRAY[0] != 0) \
{ \
std::size_t const size = sizeof(LYX_CARRAY) / sizeof(LYX_CARRAY
[0]); \
LYX_VECTOR = std::vector(LYX_CARRAY, LYX_CARRAY + 
size); \
} \
}

char const * const known_fontsizes_array[] = { "10pt", "11pt", "12pt" };
vector known_fontsizes;
LYX_BUILD_VECTOR(known_fontsizes_array, known_fontsizes);

Dunno off the top of my head how to make a macro to initialize the vector 
though...

Regards,
Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr wrote:
I'm still a bloody C++ beginner and lost when looking into your code. 


No need to be lost. Let's see if I can explain.

The best thing would be to provide a patch tho make the void 
handle_opt work without the need to have a delete_void called 
afterwards.


It's best to keep the two separate. Removing elements from a vector 
within a loop invalidates the loop iterators.


Anyway, the explanation...

I was commenting on your delete_opt function, because its inefficient 
and because the STL provides tools to achieve your aim in a less 
expensive manner.


What's inefficient about your existing code?

+   for (; *what; ++what) {
+   it = find(opts.begin(), opts.end(), *what);
+   if (it != opts.end())
+   opts.erase(it);
+   }

This loops over all strings in the what array of strings. It looks for 
each string *what in the opts vectorstring and, if it finds it, 
it removes it. That's expensive, because you're regenerating the 
opts vector completely with each call to opts.erase.


The STL provides a means to achieve the same using std::remove and 
std::erase.


std::remove will move all iterators matching your predicate to the end 
of the collection. It's possible to do that multiple times, resetting 
the new_end iterator to mark (1 past) the end of that part of the 
collection you're interested in. Then use std::erase to actually 
resize the collection only once.


std::remove comes in two flavours, one that takes a variable that can 
be compared directly to an element of opts, and another, called 
std::remove_if, that takes a functor as its predicate. What's a 
functor? Just a fancy name to say a class variable that overrides 
operator(). It's a very powerful STL concept.


Let's look at your example again, but let's use a vectorstring to 
hold the things we want to discard. Just to make the code easier to 
understand.


void delete_opt(
vectorstring  opts,
vectorstring const  to_discard)
{
if (opts.empty() || to_discard.empty())
return;

// Use a functor, element_matches, to decide which elements
// of opts to move to the end. This functor has a constructor
// that takes the collection of strings we want to
// remove from opts.
vectorstring::iterator new_end = std::remove_if(
opts.begin(), opts.end(), element_matches(to_discard));
// Only one resize is needed...
std::erase(new_end, opts.end());
}

All that remains is the definition of the functor. As I said above, 
it's a class with a constructor that takes the collection of strings 
we want to remove:


struct element_matches {
private const vectorstring const  data_;

element_matches(vectorstring const  data) : data_(data) {}
};

However, to make it a *functor* that can be used by std::remove_if, we 
need to give it an operator() overload that takes an element of opts 
as its single parameter and returns a bool meaning remove, so:


struct element_matches {
private vectorstring const  data_;

element_matches(vectorstring const  data) : data_(data) {}

bool operator()(string const  opt_element) const
{
vectorstring::const_iterator it = data_.begin();
vectorstring::const_iterator const data_end = data.end();
for (; it != data_end; ++it)
{
if (opt_element == *it)
return true;
}
return false;
}
};

So, I end up with the same number of comparisons as you do, but with 
only one resize of the opts vector.


Makes sense now?

Regards,
Angus

ps. As one final piece of trickery, you'll notice that the body of 
operator() above is no more than the body of std::find. So, it could 
be written:


bool operator()(string const  opt_element) const
{
vectorstring iterator it = std::find(
data_.begin(), data.end(), opt_element);
return it != data.end();
}

Hope this helps ;-)
A.

Re: r21994 - /lyx-devel/trunk/src/tex2lyx/preamble.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

 // special columntypes
 extern std::mapchar, int special_columns;
@@ -218,8 +220,17 @@
h_font_sans = name;
if (!opts.empty()) {
scale = opts;
-   pos = scale.find(.);
-   h_font_sf_scale = scale.erase(0, pos + 1);
+   // the option is in the form scaled=0.9
+   // therefore cut of before the =
+   pos = scale.find(=);
+			if (pos != string::npos) { 
+scale.erase(0, pos + 1);

+   if (isStrDbl(scale)) {
+   // LyX needs the scale as integer, 
therfore multiply by 100
+   scale = convertstring(100 * 
convertdouble(scale));
+   h_font_sf_scale = scale;
+   }
+   }
}
}
// typewriter fonts
@@ -227,8 +238,17 @@
h_font_typewriter = name;
if (!opts.empty()) {
scale = opts;
-   pos = scale.find(.);
-   h_font_tt_scale = scale.erase(0, pos + 1);
+   // the option is in the form scaled=0.9
+   // therefore cut of before the =
+   pos = scale.find(=);
+			if (pos != string::npos) { 
+scale.erase(0, pos + 1);

+   if (isStrDbl(scale)) {
+   // LyX needs the scale as integer, 
therfore multiply by 100
+   scale = convertstring(100 * 
convertdouble(scale));
+   h_font_tt_scale = scale;
+   }
+   }
}
}


Couldn't you put this code in a function and call it from both places?

h_font_sf_scale = extract_scale_as_percentage(scale);
h_font_tt_scale = extract_scale_as_percentage(scale);

// Given a string scaled=0.9, return 0.9 * 100
string const extract_scale_as_percentage(string const  scale)
{
string::size_type pos = scale.find('=');
if (pos != string::npos)
{
   string value = scale.substr(pos);
   if (isStrDbl(value))
   return convertstring(100 * convertdouble(value));
}

// The input data didn't match our expectations.
// return it unaltered.
return scale;
}

Angus

Re: [patch] fix bug 75

[Angus Leeming]

Uwe Stöhr wrote:

take this attached correct patch.
regards Uwe


Shouldn't global variables be declared in tex2lyx.h and defined in 
tex2lyx.cpp?


Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr wrote:
I'm still a bloody C++ beginner and lost when looking into your code. 


No need to be lost. Let's see if I can explain.

The best thing would be to provide a patch tho make the void 
"handle_opt" work without the need to have a "delete_void" called 
afterwards.


It's best to keep the two separate. Removing elements from a vector 
within a loop invalidates the loop iterators.


Anyway, the explanation...

I was commenting on your delete_opt function, because its inefficient 
and because the STL provides tools to achieve your aim in a less 
expensive manner.


What's inefficient about your existing code?

+   for (; *what; ++what) {
+   it = find(opts.begin(), opts.end(), *what);
+   if (it != opts.end())
+   opts.erase(it);
+   }

This loops over all strings in the what array of strings. It looks for 
each string "*what" in the "opts" vector and, if it finds it, 
it removes it. That's expensive, because you're regenerating the 
"opts" vector completely with each call to opts.erase.


The STL provides a means to achieve the same using std::remove and 
std::erase.


std::remove will move all iterators matching your predicate to the end 
of the collection. It's possible to do that multiple times, resetting 
the "new_end" iterator to mark (1 past) the end of that part of the 
collection you're interested in. Then use std::erase to actually 
resize the collection only once.


std::remove comes in two flavours, one that takes a variable that can 
be compared directly to an element of opts, and another, called 
std::remove_if, that takes a functor as its predicate. What's a 
functor? Just a fancy name to say a class variable that overrides 
operator(). It's a very powerful STL concept.


Let's look at your example again, but let's use a vector to 
hold the things we want to discard. Just to make the code easier to 
understand.


void delete_opt(
vector & opts,
vector const & to_discard)
{
if (opts.empty() || to_discard.empty())
return;

// Use a functor, element_matches, to decide which elements
// of opts to move to the end. This functor has a constructor
// that takes the collection of strings we want to
// remove from opts.
vector::iterator new_end = std::remove_if(
opts.begin(), opts.end(), element_matches(to_discard));
// Only one resize is needed...
std::erase(new_end, opts.end());
}

All that remains is the definition of the functor. As I said above, 
it's a class with a constructor that takes the collection of strings 
we want to remove:


struct element_matches {
private const vector const & data_;

element_matches(vector const & data) : data_(data) {}
};

However, to make it a *functor* that can be used by std::remove_if, we 
need to give it an operator() overload that takes an element of "opts" 
as its single parameter and returns a bool meaning "remove", so:


struct element_matches {
private vector const & data_;

element_matches(vector const & data) : data_(data) {}

bool operator()(string const & opt_element) const
{
vector::const_iterator it = data_.begin();
vector::const_iterator const data_end = data.end();
for (; it != data_end; ++it)
{
if (opt_element == *it)
return true;
}
return false;
}
};

So, I end up with the same number of comparisons as you do, but with 
only one resize of the opts vector.


Makes sense now?

Regards,
Angus

ps. As one final piece of trickery, you'll notice that the body of 
operator() above is no more than the body of std::find. So, it could 
be written:


bool operator()(string const & opt_element) const
{
vector iterator it = std::find(
data_.begin(), data.end(), opt_element);
return it != data.end();
}

Hope this helps ;-)
A.

Re: r21994 - /lyx-devel/trunk/src/tex2lyx/preamble.cpp

[Angus Leeming]

[EMAIL PROTECTED] wrote:

 // special columntypes
 extern std::map special_columns;
@@ -218,8 +220,17 @@
h_font_sans = name;
if (!opts.empty()) {
scale = opts;
-   pos = scale.find(".");
-   h_font_sf_scale = scale.erase(0, pos + 1);
+   // the option is in the form "scaled=0.9"
+   // therefore cut of before the "="
+   pos = scale.find("=");
+			if (pos != string::npos) { 
+scale.erase(0, pos + 1);

+   if (isStrDbl(scale)) {
+   // LyX needs the scale as integer, 
therfore multiply by 100
+   scale = convert(100 * 
convert(scale));
+   h_font_sf_scale = scale;
+   }
+   }
}
}
// typewriter fonts
@@ -227,8 +238,17 @@
h_font_typewriter = name;
if (!opts.empty()) {
scale = opts;
-   pos = scale.find(".");
-   h_font_tt_scale = scale.erase(0, pos + 1);
+   // the option is in the form "scaled=0.9"
+   // therefore cut of before the "="
+   pos = scale.find("=");
+			if (pos != string::npos) { 
+scale.erase(0, pos + 1);

+   if (isStrDbl(scale)) {
+   // LyX needs the scale as integer, 
therfore multiply by 100
+   scale = convert(100 * 
convert(scale));
+   h_font_tt_scale = scale;
+   }
+   }
}
}


Couldn't you put this code in a function and call it from both places?

h_font_sf_scale = extract_scale_as_percentage(scale);
h_font_tt_scale = extract_scale_as_percentage(scale);

// Given a string "scaled=0.9", return 0.9 * 100
string const extract_scale_as_percentage(string const & scale)
{
string::size_type pos = scale.find('=');
if (pos != string::npos)
{
   string value = scale.substr(pos);
   if (isStrDbl(value))
   return convert(100 * convert(value));
}

// The input data didn't match our expectations.
// return it unaltered.
return scale;
}

Angus

Re: [patch] fix bug 75

[Angus Leeming]

Uwe Stöhr wrote:

take this attached correct patch.
regards Uwe


Shouldn't global variables be declared in tex2lyx.h and defined in 
tex2lyx.cpp?


Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr [EMAIL PROTECTED] writes:
+void delete_opt(vectorstring  opts, char const * const * what)
+{
+   if (opts.empty())
+   return;
+
+   // remove found options from the list
+   // do this after handle_opt to avoid potential memory leaks and to be 
able
+   // to find in every case the last language option
+   vectorstring::iterator it;
+   for (; *what; ++what) {
+   it = find(opts.begin(), opts.end(), *what);
+   if (it != opts.end())
+   opts.erase(it);
+   }
+}

Can't you use std::remove multiple times and then perform only one erase? 
Should be much more efficient, no?

See http://www.sgi.com/tech/stl/remove.html (it doesn't actually remove 
anything, just moves those iterators matching the predicate to the end...)

typedef vectorstring::iterator iterator;
iterator opts_end = opts.end();
iterator const opts_begin = opts.begin();
for (; *what; ++what)
{
 opts_end = std::remove(opts_begin, opts_end, *what);
 if (opts_end == opts_begin)
 break;
}

std::erase(opts_end, opts.end();

Better still, use a predicate that itself loops over the what. Why are you 
using a c-string anyway? It's been a long time (and I get lost with pointers 
to pointers), but I think that the code below, or something like it should do 
the trick. Minimal re-working of your opts vector...

struct ContainsCharInCString
{
private char const * const * cstring;

ContainsCharInCString(char const * const * data) : this.cstring(data) {}

bool operator(char input)
{
for (char const * const * ptr = cstring; *ptr; ++ptr)
{
if (input == *ptr)
return true;
}
return false;
}
}

iterator new_end = std::remove_if(
opts.begin(), opts.end(), ContainsCharInCString(what));
std::erase(new_end, opts.end();

Angus

Re: [patch] full babel support for tex2lyx

[Angus Leeming]

Uwe Stöhr <[EMAIL PROTECTED]> writes:
+void delete_opt(vector & opts, char const * const * what)
+{
+   if (opts.empty())
+   return;
+
+   // remove found options from the list
+   // do this after handle_opt to avoid potential memory leaks and to be 
able
+   // to find in every case the last language option
+   vector::iterator it;
+   for (; *what; ++what) {
+   it = find(opts.begin(), opts.end(), *what);
+   if (it != opts.end())
+   opts.erase(it);
+   }
+}

Can't you use std::remove multiple times and then perform only one erase? 
Should be much more efficient, no?

See http://www.sgi.com/tech/stl/remove.html (it doesn't actually remove 
anything, just moves those iterators matching the predicate to the end...)

typedef vector::iterator iterator;
iterator opts_end = opts.end();
iterator const opts_begin = opts.begin();
for (; *what; ++what)
{
 opts_end = std::remove(opts_begin, opts_end, *what);
 if (opts_end == opts_begin)
 break;
}

std::erase(opts_end, opts.end();

Better still, use a predicate that itself loops over the what. Why are you 
using a c-string anyway? It's been a long time (and I get lost with pointers 
to pointers), but I think that the code below, or something like it should do 
the trick. Minimal re-working of your opts vector...

struct ContainsCharInCString
{
private char const * const * cstring;

ContainsCharInCString(char const * const * data) : this.cstring(data) {}

bool operator(char input)
{
for (char const * const * ptr = cstring; *ptr; ++ptr)
{
if (input == *ptr)
return true;
}
return false;
}
}

iterator new_end = std::remove_if(
opts.begin(), opts.end(), ContainsCharInCString(what));
std::erase(new_end, opts.end();

Angus

Re: new tex2lyx version

[Angus Leeming]

Juergen Spitzmueller [EMAIL PROTECTED] writes:

 
 Uwe Stöhr wrote:
 
  Yes, things that are already in the latest fileformat won't be touched in
  lyx2lyx as far as I tested. So except of probably only a few cases where
  lyx2lyx changes the file to a wrong format, we can support LyX's 1.6's
  features and the old ones are converted by lyx2lyx.
 
 So tex2lyx produces an invalid LyX file now. This is not a way we should go,
 IMO.

Adding a word of warning from the reLyX trenches: reLyX produced these psuedo-
lyx files that were actually a mismatch of formats and then relied on lyx2lyx 
to clean up after it. It was an unmaintainable, unmitigated disaster. I'd hate 
to see tex2lyx go the same way.

Butting out again,
Angus

Re: new tex2lyx version

[Angus Leeming]

Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

> 
> Uwe Stöhr wrote:
> 
> > Yes, things that are already in the latest fileformat won't be touched in
> > lyx2lyx as far as I tested. So except of probably only a few cases where
> > lyx2lyx changes the file to a wrong format, we can support LyX's 1.6's
> > features and the old ones are converted by lyx2lyx.
> 
> So tex2lyx produces an invalid LyX file now. This is not a way we should go,
> IMO.

Adding a word of warning from the reLyX trenches: reLyX produced these "psuedo-
lyx" files that were actually a mismatch of formats and then relied on lyx2lyx 
to clean up after it. It was an unmaintainable, unmitigated disaster. I'd hate 
to see tex2lyx go the same way.

Butting out again,
Angus

Re: index-bug in 1.6.0svn with data loss

[Angus Leeming]

Martin Vermeer [EMAIL PROTECTED] writes:
 -# Put here the conversions needed from LaTeX string
 -# to LyXText:
 +# Put here the conversions needed from LaTeX string to LyXText:
 +# Umlauted characters:
 +fullcontent = fullcontent.replace(r'\\\a', u'ä').replace(r'\\\o', 
u'ö').replace(r'\\\u', u'ü')
 +# Same German style:
 +fullcontent = fullcontent.replace(r'a', u'ä').replace(r'o', 
u'ö').replace(r'u', u'ü')

This doesn't look very robust. What about Noël/No\el?. Can't you make use of 
a tool that's dedicated to this type of conversion, like recode?

http://www.delorie.com/gnu/docs/recode/recode_13.html

Angus

Re: index-bug in 1.6.0svn with data loss

[Angus Leeming]

Martin Vermeer <[EMAIL PROTECTED]> writes:
> -# Put here the conversions needed from LaTeX string
> -# to LyXText:
> +# Put here the conversions needed from LaTeX string to LyXText:
> +# Umlauted characters:
> +fullcontent = fullcontent.replace(r'\\\"a', u'ä').replace(r'\\\"o', 
u'ö').replace(r'\\\"u', u'ü')
> +# Same German style:
> +fullcontent = fullcontent.replace(r'"a', u'ä').replace(r'"o', 
u'ö').replace(r'"u', u'ü')

This doesn't look very robust. What about Noël/No\"el?. Can't you make use of 
a tool that's dedicated to this type of conversion, like recode?

http://www.delorie.com/gnu/docs/recode/recode_13.html

Angus

Re: [PATCH] remove properly [[context]] strings from translated messages

[Angus Leeming]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

 This is fixed by the patch below, where I have also replaced
 the regex based code by something simpler. This is not (only) to make
 Andre happy, but also to make it work on wide strings.

I thought Boost.Regex supported wide strings. I believe that the typedef is 
boost::wregex...

Just FYI,
Angus

Re: [PATCH] remove properly [[context]] strings from translated messages

[Angus Leeming]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

> This is fixed by the patch below, where I have also replaced
> the regex based code by something simpler. This is not (only) to make
> Andre happy, but also to make it work on wide strings.

I thought Boost.Regex supported wide strings. I believe that the typedef is 
boost::wregex...

Just FYI,
Angus

Re: freefont, LFUN_FONT_FREE_APPLY and LFUN_FONT_FREE_UPDATE...

[Angus Leeming]

Andre Poenitz [EMAIL PROTECTED] writes:
 I think we should think about how a binary kernel interface would look
 like. The serialization could exist on top of that as a thin wrapper.

LOL! I've obviously a long memory. I remember a certain André Pönitz telling 
me that binary serialization based on the XLT library was total overkill.

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg09034.html

Angus

Re: freefont, LFUN_FONT_FREE_APPLY and LFUN_FONT_FREE_UPDATE...

[Angus Leeming]

Andre Poenitz <[EMAIL PROTECTED]> writes:
> I think we should think about how a binary kernel interface would look
> like. The serialization could exist on top of that as a thin wrapper.

LOL! I've obviously a long memory. I remember a certain André Pönitz telling 
me that binary serialization based on the XLT library was total overkill.

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg09034.html

Angus

Valgrind reports memory leaks

[Angus Leeming]

On a Linux box:
valgrind --leak-check=full src/lyx
Open up the Users' Guide using the menu HelpUsers' Guide
Wait some time...
Close LyX with FileExit

That produces the rather disturbing report. This is with a bang-up-to-date
check out.

-- 
Angus

valgrind_report.txt.gz
Description: GNU Zip compressed data

Valgrind reports memory leaks

[Angus Leeming]

On a Linux box:
valgrind --leak-check=full src/lyx
Open up the Users' Guide using the menu "Help>Users' Guide"
Wait some time...
Close LyX with "File>Exit"

That produces the rather disturbing report. This is with a bang-up-to-date
check out.

-- 
Angus

valgrind_report.txt.gz
Description: GNU Zip compressed data

Re: Is There a Better Way To Do This?

[Angus Leeming]

Richard Heck [EMAIL PROTECTED] writes:

 
 
 This is very boring:
 
 CommandInfo const * InsetCommandParams::findInfo(
 InsetCode code, std::string const  cmdName)
 {
 switch (code) {
 case BIBITEM_CODE:
 return InsetBibitem::findInfo(cmdName);
 case BIBTEX_CODE:
 return InsetBibtex::findInfo(cmdName);
 case CITE_CODE:
 return InsetCitation::findInfo(cmdName);   
 case FLOAT_LIST_CODE:
 return InsetFloatList::findInfo(cmdName);
 case HFILL_CODE:
 return InsetHFill::findInfo(cmdName);


What you're really implementing here is the Factory Pattern. One way to 
implement a factory, as you're doing here, is using a giant switch. Another 
way to do it is to register the content of the case statement in some map.

Something like (I probably get the function pointer syntax wrong):

class InsetCommandParams {
typedef CommandInfo const * (FindInfoFn *)(std::string);
static std::mapInsetCode, FindInfoFn *) findInfoFactory;
public:
static void RegisterFindInfo(InsetCode code, FindInfoFn * func)
{
findInfoFactory[code] = func;
}
};


class InsetBibitem {
static bool firstTime = true;
public:
InsetBibitem()
{
   if (firstTime)
   {
   firstTime = false;
   InsetCommandParams.RegisterFindInfo(BIBITEM_CODE, 
InsetBibitem::findInfo);
   }
}
};

Then your InsetCommandParams::findInfo just calls into the map:

CommandInfo const * InsetCommandParams::findInfo(
InsetCode code, std::string const  cmdName)
{
return findInfoFactory[code](cmdName);
}

This is one place where c#'s reflection tool is a real win.

Angus

Re: Is There a Better Way To Do This?

[Angus Leeming]

Richard Heck <[EMAIL PROTECTED]> writes:

> 
> 
> This is very boring:
> 
> CommandInfo const * InsetCommandParams::findInfo(
> InsetCode code, std::string const & cmdName)
> {
> switch (code) {
> case BIBITEM_CODE:
> return InsetBibitem::findInfo(cmdName);
> case BIBTEX_CODE:
> return InsetBibtex::findInfo(cmdName);
> case CITE_CODE:
> return InsetCitation::findInfo(cmdName);   
> case FLOAT_LIST_CODE:
> return InsetFloatList::findInfo(cmdName);
> case HFILL_CODE:
> return InsetHFill::findInfo(cmdName);


What you're really implementing here is the Factory Pattern. One way to 
implement a factory, as you're doing here, is using a giant switch. Another 
way to do it is to register the content of the case statement in some map.

Something like (I probably get the function pointer syntax wrong):

class InsetCommandParams {
typedef CommandInfo const * (FindInfoFn *)(std::string);
static std::map

Re: [PATCH] InsetInclude -- InsetCommand

[Angus Leeming]

Richard Heck wrote:

 
 The attached patch finishes this bit of work, left over from the
 InsetCommand conversion. Comments welcome before I commit.
 
 Richard

This sort of change gives me a nice, warm, fuzzy feeling. It's obvious
you've done something right when you can remove so much code :-)

Minor comments:

It would be nice to see the death of those to_utf8(...) calls.

Shouldn't the enum and the type(InsetCommandParams const ) function live
in an anonymous namespace?

There's some whitespace horkage in/around the enum definition.

-- 
Angus

Re: [PATCH] InsetInclude --> InsetCommand

[Angus Leeming]

Richard Heck wrote:

> 
> The attached patch finishes this bit of work, left over from the
> InsetCommand conversion. Comments welcome before I commit.
> 
> Richard

This sort of change gives me a nice, warm, fuzzy feeling. It's obvious
you've done something right when you can remove so much code :-)

Minor comments:

It would be nice to see the death of those to_utf8(...) calls.

Shouldn't the enum and the type(InsetCommandParams const &) function live
in an anonymous namespace?

There's some whitespace horkage in/around the enum definition.

-- 
Angus

Re: FontList-related (?) crash in trunk

[Angus Leeming]

Abdelrazak Younes wrote:
 PS: Sorry Angus but you deserved it ;-)
 PPS: I'm talking about Rugby...

Me too. So did you.

Re: FontList-related (?) crash in trunk

[Angus Leeming]

Abdelrazak Younes wrote:
> PS: Sorry Angus but you deserved it ;-)
> PPS: I'm talking about Rugby...

Me too. So did you.

Re: r21033 - in /lyx-devel/trunk/src: Buffer.cpp CutAndPaste....

[Angus Leeming]

Abdelrazak Younes wrote:
 Well it was just modeled after Inset::clone but you're right, it's
 strange. Maybe I should just rename it to cloneInset() instead or
 implement a copy ctor...

The copy constructor sounds sane. This thing isn't polymorphic at all.

-- 
Angus

Re: r21033 - in /lyx-devel/trunk/src: Buffer.cpp CutAndPaste....

[Angus Leeming]

Abdelrazak Younes wrote:
 Well it was just modeled after Inset::clone but you're right, it's
> strange. Maybe I should just rename it to cloneInset() instead or
> implement a copy ctor...

The copy constructor sounds sane. This thing isn't polymorphic at all.

-- 
Angus

Re: InsetCommandParams Question

[Angus Leeming]

Richard Heck wrote:
 The obvious way to handle this is to have something like this:
 enum Optional { OPT, REQ };
 struct ParamInfo {
std::string paramName;
Optional opt;
docstring value;
 }
 class ParamList {
setValue(std::string name, docstring value);
getValue(std::string name);
isOptional(std::string name);
addParam(ParamInfo);
 private:
std::listParamInfo plist;
 }
 And then every InsetCommand would have an associated ParamList in its
 InsetCommandParams.
 
 So the question is: Are the added memory requirements here
 objectionable? If so, is there some natural way to continue with the
 static const treatment, even assuming the acceptable parameters could
 vary, and even be set at runtime? It's because I don't see how to do the
 latter that this plan seems the only workable one.

It looks like a sane plan and doesn't look especially expensive to me. You
might even take this one step further to:

 enum Optional { OPT, REQ };
 struct PropertyDefinition {
 std::string paramName;
 Optional opt;
 // Some helper functions defining what might be meant
 // by valid values.
 };

 struct Property {
  PropertyDefinition propDef;
  docstring value;
 };

Doing that, you would have essentially define a schema that you could go on
to use to validate your input data.

Presumably well known insets would have hard-coded ParamLists and custom
Flex insets would define them in the equivalent of a .layout file.
(Whatever this thing is called for these clever beasties.)

-- 
Angus

Re: r21033 - in /lyx-devel/trunk/src: Buffer.cpp CutAndPaste....

[Angus Leeming]

[EMAIL PROTECTED] wrote:

 Author: younes
 Date: Thu Oct 18 17:29:51 2007
 New Revision: 21033
 
 URL: http://www.lyx.org/trac/changeset/21033
 Log:
 Reduce header dependencies in Paragraph.h
 - Move Changes.h out of Paragraph.h
 - pimpl the inset list.

==
 --- lyx-devel/trunk/src/InsetList.cpp (original) +++
 lyx-devel/trunk/src/InsetList.cpp Thu Oct 18 17:29:51 2007 @@ -138,4
 +138,12 @@
  }
  
  
 +void InsetList::clone()
 +{
 + List::iterator it = list_.begin();
 + List::iterator end = list_.end();
 + for (; it != end; ++it)
 + it-inset = it-inset-clone();
 +}
 +
  } // namespace lyx

==
 --- lyx-devel/trunk/src/Paragraph.cpp (original) +++
 lyx-devel/trunk/src/Paragraph.cpp Thu Oct 18 17:29:51 2007 @@ -21,10
 @@ -277,6 +282,8 @@
  inset_owner = p.inset_owner;
  fontlist = p.fontlist;
  id_ = paragraph_id++;
 + insetlist_ = p.insetlist_;
 + insetlist_.clone();
  }

This is a very strange clone. Why aren't you writing it:

   class InsetList {
   static InsetList clone(InsetList  rhs)
   {
   InsetList lhs = rhs;
   List::iterator it = lhs.begin();
   List::iterator const end = lhs.end();
   for (; it != end; ++it)
   {
   // Indeed, I think Inset::clone should be similar.
   it-inset = it-inset-clone();
   }
   return lhs;
   }
   };

 ?

Angus

Re: r21048 - in /lyx-devel/trunk/src: BufferView.cpp Converte...

[Angus Leeming]

[EMAIL PROTECTED] wrote:

 Author: poenitz
 Date: Fri Oct 19 01:03:51 2007
 New Revision: 21048
 
 URL: http://www.lyx.org/trac/changeset/21048
 Log:
 isome more FileName shuffling
http://www.lyx.org/trac/file/lyx-devel/trunk/src/support/FileName.cpp?rev=21048

==
 --- lyx-devel/trunk/src/support/FileName.cpp (original) +++
 lyx-devel/trunk/src/support/FileName.cpp Fri Oct 19 01:03:51 2007 @@
 -16,6 +16,9 @@
  #include support/os.h
  #include support/qstring_helpers.h
  
 +#include debug.h
 +#include lyxlib.h
 +
  #include QFile
  #include QFileInfo
  
 @@ -67,14 +70,14 @@
  }
  
  
 -string const FileName::toFilesystemEncoding() const
 +string FileName::toFilesystemEncoding() const
  {
  QByteArray const encoded = QFile::encodeName(toqstr(name_));
  return string(encoded.begin(), encoded.end());
  }
  
  
 -FileName const FileName::fromFilesystemEncoding(string const  name)
 +FileName FileName::fromFilesystemEncoding(string const  name)
  {
  QByteArray const encoded(name.c_str(), name.length());
  return FileName(fromqstr(QFile::decodeName(encoded)));
 @@ -104,6 +107,40 @@
  {
  QFileInfo const fi(toqstr(name_));
  return fi.isReadable();
 +}
 +
 +
 +bool FileName::isFileReadable() const
 +{
 + QFileInfo const fi(toqstr(name_));
 + return fi.isFile()  fi.isReadable();
 +}
 +
 +
 +bool FileName::isWritable() const
 +{
 + QFileInfo const fi(toqstr(name_));
 + return fi.isReadable();
 +}
 +
 +
 +bool FileName::isDirWritable() const
 +{
 + LYXERR(Debug::FILES)  isDirWriteable:   *this  std::endl;
 +
 + FileName const tmpfl(tempName(*this, lyxwritetest));
 +
 + if (tmpfl.empty())
 + return false;
 +
 + unlink(tmpfl);
 + return true;
 +}
 +
 +
 +FileName FileName::tempName(FileName const  dir, std::string const 
 mask) +{
 + return support::tempName(dir, mask);
  }

This makes the source much more readable; obviously the right thing to do.
However, I think it also makes sense to make that QFileInfo a member
variable of FileName, no? You seem to be creating an awful lot of
temporary objects for no real reason.

Angus

Re: InsetCommandParams Question

[Angus Leeming]

Richard Heck wrote:
> The obvious way to handle this is to have something like this:
> enum Optional { OPT, REQ };
> struct ParamInfo {
>std::string paramName;
>Optional opt;
>docstring value;
> }
> class ParamList {
>setValue(std::string name, docstring value);
>getValue(std::string name);
>isOptional(std::string name);
>addParam(ParamInfo);
> private:
>std::list plist;
> }
> And then every InsetCommand would have an associated ParamList in its
> InsetCommandParams.
> 
> So the question is: Are the added memory requirements here
> objectionable? If so, is there some natural way to continue with the
> static const treatment, even assuming the acceptable parameters could
> vary, and even be set at runtime? It's because I don't see how to do the
> latter that this plan seems the only workable one.

It looks like a sane plan and doesn't look especially expensive to me. You
might even take this one step further to:

 enum Optional { OPT, REQ };
 struct PropertyDefinition {
 std::string paramName;
 Optional opt;
 // Some helper functions defining what might be meant
 // by "valid" values.
 };

 struct Property {
  PropertyDefinition propDef;
  docstring value;
 };

Doing that, you would have essentially define a schema that you could go on
to use to validate your input data.

Presumably "well known" insets would have hard-coded ParamLists and custom
Flex insets would define them in the equivalent of a .layout file.
(Whatever this thing is called for these clever beasties.)

-- 
Angus

Re: r21033 - in /lyx-devel/trunk/src: Buffer.cpp CutAndPaste....

[Angus Leeming]

[EMAIL PROTECTED] wrote:

> Author: younes
> Date: Thu Oct 18 17:29:51 2007
> New Revision: 21033
> 
> URL: http://www.lyx.org/trac/changeset/21033
> Log:
> Reduce header dependencies in Paragraph.h
> - Move Changes.h out of Paragraph.h
> - pimpl the inset list.

==
> --- lyx-devel/trunk/src/InsetList.cpp (original) +++
> lyx-devel/trunk/src/InsetList.cpp Thu Oct 18 17:29:51 2007 @@ -138,4
> +138,12 @@
>  }
>  
>  
> +void InsetList::clone()
> +{
> + List::iterator it = list_.begin();
> + List::iterator end = list_.end();
> + for (; it != end; ++it)
> + it->inset = it->inset->clone();
> +}
> +
>  } // namespace lyx

==
> --- lyx-devel/trunk/src/Paragraph.cpp (original) +++
> lyx-devel/trunk/src/Paragraph.cpp Thu Oct 18 17:29:51 2007 @@ -21,10
> @@ -277,6 +282,8 @@
>  inset_owner = p.inset_owner;
>  fontlist = p.fontlist;
>  id_ = paragraph_id++;
> + insetlist_ = p.insetlist_;
> + insetlist_.clone();
>  }

This is a very strange "clone". Why aren't you writing it:

   class InsetList {
   static InsetList clone(InsetList & rhs)
   {
   InsetList lhs = rhs;
   List::iterator it = lhs.begin();
   List::iterator const end = lhs.end();
   for (; it != end; ++it)
   {
   // Indeed, I think Inset::clone should be similar.
   it->inset = it->inset->clone();
   }
   return lhs;
   }
   };

 ?

Angus

Re: r21048 - in /lyx-devel/trunk/src: BufferView.cpp Converte...

[Angus Leeming]

[EMAIL PROTECTED] wrote:

> Author: poenitz
> Date: Fri Oct 19 01:03:51 2007
> New Revision: 21048
> 
> URL: http://www.lyx.org/trac/changeset/21048
> Log:
> isome more FileName shuffling
http://www.lyx.org/trac/file/lyx-devel/trunk/src/support/FileName.cpp?rev=21048
>
==
> --- lyx-devel/trunk/src/support/FileName.cpp (original) +++
> lyx-devel/trunk/src/support/FileName.cpp Fri Oct 19 01:03:51 2007 @@
> -16,6 +16,9 @@
>  #include "support/os.h"
>  #include "support/qstring_helpers.h"
>  
> +#include "debug.h"
> +#include "lyxlib.h"
> +
>  #include 
>  #include 
>  
> @@ -67,14 +70,14 @@
>  }
>  
>  
> -string const FileName::toFilesystemEncoding() const
> +string FileName::toFilesystemEncoding() const
>  {
>  QByteArray const encoded = QFile::encodeName(toqstr(name_));
>  return string(encoded.begin(), encoded.end());
>  }
>  
>  
> -FileName const FileName::fromFilesystemEncoding(string const & name)
> +FileName FileName::fromFilesystemEncoding(string const & name)
>  {
>  QByteArray const encoded(name.c_str(), name.length());
>  return FileName(fromqstr(QFile::decodeName(encoded)));
> @@ -104,6 +107,40 @@
>  {
>  QFileInfo const fi(toqstr(name_));
>  return fi.isReadable();
> +}
> +
> +
> +bool FileName::isFileReadable() const
> +{
> + QFileInfo const fi(toqstr(name_));
> + return fi.isFile() && fi.isReadable();
> +}
> +
> +
> +bool FileName::isWritable() const
> +{
> + QFileInfo const fi(toqstr(name_));
> + return fi.isReadable();
> +}
> +
> +
> +bool FileName::isDirWritable() const
> +{
> + LYXERR(Debug::FILES) << "isDirWriteable: " << *this << std::endl;
> +
> + FileName const tmpfl(tempName(*this, "lyxwritetest"));
> +
> + if (tmpfl.empty())
> + return false;
> +
> + unlink(tmpfl);
> + return true;
> +}
> +
> +
> +FileName FileName::tempName(FileName const & dir, std::string const &
> mask) +{
> + return support::tempName(dir, mask);
>  }

This makes the source much more readable; obviously the right thing to do.
However, I think it also makes sense to make that QFileInfo a member
variable of FileName, no? You seem to be creating an awful lot of
temporary objects for no real reason.

Angus

Re: Boost and exceptions

[Angus Leeming]

Andre Poenitz [EMAIL PROTECTED] writes:
 [Apart from that I do neither trust boost::fs nor our own use of file
 names when it comes to unusual enviroments. Chinese Windows comes
 to mind for instance. One of the less funny features that show up
 there is that the argv/argc that's passed to main() is already damaged,
 so anything seriously relying on that is inherently broken.]
 
  Also I see in src/boost.cpp:
#ifndef BOOST_NO_EXCEPTIONS
void throw_exception(std::exception const  e)
{
lyxerr  Exception caught:\n
 e.what()  endl;
BOOST_ASSERT(false);
}
#endif
  
  How come this code is not used? The output does not match what the
  original reported wrote.
 
 I don't have a clue.

LyX's use of Boost.FileSystem is a failed experiment IMO.
1. Boost.FileSystem really *doesn't* handle the case where the client is not 
using exceptions. It's essentially hard-coded to abort if BOOST_NO_EXCEPTIONS 
is true.
2. The fact that fs.exists throws is totally fubar-ed.

You really should replace all use of fs.exists with something sane.

Having said that, the API *has* been mandated by the Standards Committees and 
is now part of tr1, no? So you can expect vendors (gcc, msvc) to start rolling 
their own implementations in the near-ish future.

Angus

Angus

Re: Boost and exceptions

[Angus Leeming]

Andre Poenitz <[EMAIL PROTECTED]> writes:
> [Apart from that I do neither trust boost::fs nor our own use of file
> names when it comes to "unusual" enviroments. Chinese Windows comes
> to mind for instance. One of the less funny features that show up
> there is that the argv/argc that's passed to main() is already damaged,
> so anything seriously relying on that is inherently broken.]
> 
> > Also I see in src/boost.cpp:
> >   #ifndef BOOST_NO_EXCEPTIONS
> >   void throw_exception(std::exception const & e)
> >   {
> >   lyxerr << "Exception caught:\n"
> >   << e.what() << endl;
> >   BOOST_ASSERT(false);
> >   }
> >   #endif
> > 
> > How come this code is not used? The output does not match what the
> > original reported wrote.
> 
> I don't have a clue.

LyX's use of Boost.FileSystem is a failed experiment IMO.
1. Boost.FileSystem really *doesn't* handle the case where the client is not 
using exceptions. It's essentially hard-coded to abort if BOOST_NO_EXCEPTIONS 
is true.
2. The fact that fs.exists throws is totally fubar-ed.

You really should replace all use of fs.exists with something sane.

Having said that, the API *has* been mandated by the Standards Committees and 
is now part of tr1, no? So you can expect vendors (gcc, msvc) to start rolling 
their own implementations in the near-ish future.

Angus

Angus