Re: Listings

2007-07-16 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
> But this is then a bug. LyX currently swallows all author informations
> without confirmation. This is in my opinion a dataloss!

I don't think so. The author information was introduced and currently is 
actually only there for change tracking purposes. Because of bug 3764, this 
privacy information leaked into documents without change tracking (without 
user confirmation).

> Furthermore it is a bug that I can set my identity in the preferences but
> still get an empty author field in the LyX files. Currently an author is
> only set when change tracking was used. 

That's how it's supposed to be.

> What I still miss is an option in 
> the preferences to set this in every case.

Right. But that would be a new feature. You can file an enhancement request on 
this.

The policy should be: newer publish privacy information when the user didn't 
explicitly agreed on this.

Jürgen


Re: [patch] Reversing numbers in arabic_arabi

2007-07-16 Thread José Matos
On Monday 16 July 2007 22:30:09 Uwe Stöhr wrote:
> > This is technically a format change, though I would again argue that we
> > should *not* create a lyx2lyx for it.
>
> I agree that this is not necessary as there is currently no user base that
> needs this.

  That is not a valid argument, we only use that if we are really desperate, 
are we there already? ;-)

> regards Uwe

-- 
José Abílio


Re: [patch] Reversing numbers in arabic_arabi

2007-07-16 Thread Uwe Stöhr

Dov Feldstern schrieb:

Attached find a patch which I believe is necessary for correctly 
displaying numbers in the output of arabic documents using Arabi 
(ArabTeX takes care of this internally).


Uwe, Mostafa --- could you please test this?


I cannot speak Arabic and therefore also doesn't know how the numbers should look. But as the 
comment above this routine states:

"// for Hebrew and Farsi (Arabi) do not."
Then I think this also applies for Arabic (Arabi). Mostafa?
So when Mostafa gives his OK, I think it is safe to apply.

This is technically a format change, though I would again argue that we 
should *not* create a lyx2lyx for it.


I agree that this is not necessary as there is currently no user base that 
needs this.

regards Uwe


Re: Listings

2007-07-16 Thread Uwe Stöhr

>> In principle yes. But please don't delete all authors.
>
> I didn't do this explicitly. This is the consequence of rev 19019.

But this is then a bug. LyX currently swallows all author informations without confirmation. This is 
in my opinion a dataloss!
Furthermore it is a bug that I can set my identity in the preferences but still get an empty author 
field in the LyX files. Currently an author is only set when change tracking was used. What I still 
miss is an option in the preferences to set this in every case.


>> The note should be
>> in a greyed-out note as the other ones in the document. I can also do this
>> later today and commit.
>
> Yes, please do that.

Done:
http://www.lyx.org/trac/changeset/19090

regards Uwe


Re: [PATCH] Re: Current svn: Crash with pdfsync

2007-07-16 Thread José Matos
On Monday 16 July 2007 18:46:55 Abdelrazak Younes wrote:
> OK, Jose shall I commit?

OK.

> Please note that I have two other patches pending...

I know, I am a slow thinker. :-)

-- 
José Abílio


[patch] Reversing numbers in arabic_arabi

2007-07-16 Thread Dov Feldstern

Hi!

Attached find a patch which I believe is necessary for correctly 
displaying numbers in the output of arabic documents using Arabi 
(ArabTeX takes care of this internally).


Uwe, Mostafa --- could you please test this? (I'm still having trouble 
with setting up Arabi correctly --- though what I am able to see 
convinces me that this patch is needed).


This is technically a format change, though I would again argue that we 
should *not* create a lyx2lyx for it. However, if this is not 
acceptable, a lyx2lyx patch should be relatively simple; and that only 
underlines the need for applying this before 1.5.0.


Dov
Index: lyx-devel/src/Font.cpp
===
--- lyx-devel.orig/src/Font.cpp 2007-07-16 22:06:14.0 +0300
+++ lyx-devel/src/Font.cpp  2007-07-16 22:13:55.0 +0300
@@ -802,7 +802,8 @@
// for Hebrew and Farsi (Arabi) do not.
if (number() == ON && prev.number() != ON
&& (language()->lang() == "hebrew"
-   || language()->lang() == "farsi")) {
+   || language()->lang() == "farsi" 
+   || language()->lang() == "arabic_arabi")) {
os << "{\\beginL ";
count += 9;
}
@@ -936,7 +937,8 @@
// for Hebrew and Farsi (Arabi) do not.
if (number() == ON && next.number() != ON
&& (language()->lang() == "hebrew"
-   || language()->lang() == "farsi")) {
+   || language()->lang() == "farsi"
+   || language()->lang() == "arabic_arabi")) {
os << "\\endL}";
count += 6;
}


LFUN Option Syntax

2007-07-16 Thread Richard Heck


A couple weeks ago, there was some talk about reworking the syntax of 
the arguments passed to LFUNs. At present, it is a bit of a mess. Here's 
a suggestion: Why not just have these in the standard GNU form, with 
short (or even long) options? There are plenty of libraries for parsing 
such options, and some of these presumably would handle quotes and such 
automatically. Since they would only need to be called where there are 
options to be passed, that shouldn't slow things down appreciably, I 
wouldn't think.


Thoughts?

Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: Development meeting fixed.

2007-07-16 Thread Martin Vermeer
On Mon, Jul 16, 2007 at 09:35:54PM +0300, Martin Vermeer wrote:
> On Mon, Jul 16, 2007 at 04:42:27PM +0200, Lars Gullik Bjønnes wrote:
> > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > 
> > | Lars Gullik Bjønnes wrote:
> > | > Are everything fixed, dates.
> > | > More attendents than one etc?
> > | > I am in the process of booking my trip, but am holding off slightly
> > | > to
> > | > get some feedback from the others going.
> > | 
> > | http://wiki.lyx.org/Devel/LyXMeeting2007
> > 
> > No hard info there. Wrt to booking etc.
> 
>  
> Lars,
> 
> great you are coming!
> 
> Others that have confirmed are Andre, Jean-Marc and Christian
> (thu 9 coming, tue 14 leaving) and Jose (fri 10 coming).
> More would be nice of course...

Actually if anyone has a bluetooth card in their laptop
(for communicating over a mobile phone), bring it along.
I have a "dongle" myself (but no laptop) and a bluetooth
3G phone (bring your own too if you can, but mine is
cheaper here). Just as a fallback, hope we won't need it...

- Martin
 




Re: LeftIndent Paragraph Setting??

2007-07-16 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard> In ParagraphParameters.cpp and elsewhere, there are
Richard> references to a leftindent property. At present, however, I
Richard> see no way to set this property. In particular, it isn't in
Richard> the Paragraph Settings dialog, and isn't in 1.4.4, either.
Richard> Anyone know the history of this?

Yes, this was an old feature that allowed to increase the left margin
of a document. It was one of these badly designed features that only
managed to creep in because one main developer (jug) needed it for his
own use. It seems that it got removed at some point (before 1.3?) and
nobody noticed :)

I guess it is another candidate for removal. I am not sure what to do
with old documents using this property.
  
This seems to be generated by lyx2lyx for 1.2-format files. Perhaps it 
is just as well to leave it.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



[patch] bug 1820 --- cleaned-up patch

2007-07-16 Thread Dov Feldstern

Hi!

Attached find a cleaned up version of the patch for 1820, based on the 
explanations I provided last night 
(http://permalink.gmane.org/gmane.editors.lyx.devel/89979).


I now feel quite confident that this patch is good. I tried it on all 
the sample files I have and that I created, I tried it on the sample 
files Enrico sent in on Friday, and I also tried it on most of the LyX 
files that I just happen to have lying around --- and it does the right 
thing for all of them. Still, I would be very happy to have other people 
test it and provide feedback.


There are one or two FIXMEs in the patch --- if anyone can help me with 
them, that would be great, I'll try to work on them myself, too. But The 
patch should be applied even in its current form.


There's still the issue of a lyx2lyx for this, as this *is* a format 
change. I'm not sure how to go about this, though. First of all, as I 
already explained, the patch only fixes things which were outputting 
*incorrectly* (i.e., the output did not match the GUI) and now it does. 
So do we really want to force the *wrong* display for old files? 
Secondly, some of the fixes here actually fix things which caused 
encoding errors previously --- obviously, we don't try to simulate 
those, too... In a word --- I need help from the lyx2lyx people for this 
part.


Dov
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revision 19080)
+++ src/output_latex.cpp(working copy)
@@ -259,14 +259,23 @@
OutputParams runparams = runparams_in;
runparams.moving_arg |= style->needprotect;
 
+   // This paragraph's language
Language const * const par_language = pit->getParLanguage(bparams);
+   // The document's language
Language const * const doc_language = bparams.language;
-   Language const * const prev_par_language =
-   (pit != paragraphs.begin())
-   ? boost::prior(pit)->getParLanguage(bparams)
-   : doc_language;
+   // The language that was in effect when the environemnt this paragraph 
is 
+   // inside of was opened
+   Language const * const outer_language = 
+   (runparams.local_font != 0) ?
+   runparams.local_font->language() : doc_language;
+   // The previous language that was in effect is either the language of
+   // the previous paragraph, if there is one, or else the outer language
+   // if there is no previous paragraph
+   Language const * const prev_language =
+   (pit != paragraphs.begin()) ?
+   boost::prior(pit)->getParLanguage(bparams) : 
outer_language;
 
-   if (par_language->babel() != prev_par_language->babel()
+   if (par_language->babel() != prev_language->babel()
// check if we already put language command in TeXEnvironment()
&& !(style->isEnvironment()
 && (pit == paragraphs.begin() ||
@@ -275,19 +284,47 @@
 || boost::prior(pit)->getDepth() < pit->getDepth(
{
if (!lyxrc.language_command_end.empty() &&
-   prev_par_language->babel() != doc_language->babel() &&
-   !prev_par_language->babel().empty())
+   prev_language->babel() != outer_language->babel() &&
+   !prev_language->babel().empty())
{
os << from_ascii(subst(lyxrc.language_command_end,
"$$lang",
-   prev_par_language->babel()))
+   prev_language->babel()))
   << '\n';
texrow.newline();
}
 
+   // We need to open a new language if we couldn't close the 
previous 
+   // one (because there's no language_command_end); and even if 
we closed
+   // the previous one, if the current language is different than 
the
+   // outer_language (which is currently in effect once the 
previous one
+   // is closed).
if ((lyxrc.language_command_end.empty() ||
-par_language->babel() != doc_language->babel()) &&
+par_language->babel() != outer_language->babel()) &&
!par_language->babel().empty()) {
+   // If we're inside an inset, and that inset is within 
an \L or \R
+   // (or equivalents), then within the inset, too, any 
opposite
+   // language paragraph should appear within an \L or \R 
(in addition
+   // to, outside of, the normal language switch commands).
+   if (lyxrc.rtl_support &&
+   // are we in an inset?
+   runparams.local_font != 0 &&
+   // is

Re: [patch] bug 3613 (includes format change)

2007-07-16 Thread Dov Feldstern

Hi!

I haven't gotten any responses to this. I think this patch 
(http://permalink.gmane.org/gmane.editors.lyx.devel/89975) should go in, 
I would be happy for people to test it. Can I commit?

Dov



Re: Development meeting fixed.

2007-07-16 Thread Martin Vermeer
On Mon, Jul 16, 2007 at 04:42:27PM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> 
> | Lars Gullik Bjønnes wrote:
> | > Are everything fixed, dates.
> | > More attendents than one etc?
> | > I am in the process of booking my trip, but am holding off slightly
> | > to
> | > get some feedback from the others going.
> | 
> | http://wiki.lyx.org/Devel/LyXMeeting2007
> 
> No hard info there. Wrt to booking etc.

 
Lars,

great you are coming!

Others that have confirmed are Andre, Jean-Marc and Christian
(thu 9 coming, tue 14 leaving) and Jose (fri 10 coming).
More would be nice of course...

- Martin


Re: Search LyX Text Functionality.

2007-07-16 Thread Abdelrazak Younes

Tommaso Cucinotta wrote:

Richard Heck ha scritto:
Yes, it doesn't actually commit anything: only svn ci will do that. 
svn add just registers the files with your local copy, so svn diff, 
etc, will see them.

In fact, done. Please, find the patched patch at bug 3998.

 http://bugzilla.lyx.org/show_bug.cgi?id=3998

Added missing files in diff (QSearchAdv.{cpp,h}, SearchAdvUi.ui). 
Cleaned up

commented code.


Looks terrific ;-)

Here's some comments on the code nevertheless:


Index: lib/bind/cua.bind
===
--- lib/bind/cua.bind   (revisione 19086)
+++ lib/bind/cua.bind   (copia locale)
@@ -62,6 +62,7 @@
 \bind "C-S-M""math-display"

 \bind "C-f"  "dialog-show findreplace"
+\bind "C-S-f""dialog-show findreplaceadv"


I'd prefer avancedfindreplace personally.


Index: src/BufferView.cpp
===
--- src/BufferView.cpp  (revisione 19086)

+   case LFUN_WORD_FINDADV:
+   findAdv(this, cmd);

AdvancedFind() IMHO.


+static docstring stringifyFromCursor(DocIterator & cur, MatchStringAdv 
const & match) {


The convention in LyX sourcecode is to put local functions in the 
anonymous namespace:


namespace {
docstring stringifyFromCursor(..)
...
}


Index: src/frontends/qt4/QSearchAdv.h

AdvancedSearch.h would be better, we try to move away for Qxxx naming.


+
+protected Q_SLOTS:
+   void findNextClicked();
+   void findPrevClicked();
+   void replaceClicked();
+   void replaceallClicked();
+   void closeClicked();

Instead of those, you could use automatic slots:
+   void on_findNextPB_clicked();

This saves the manual signal/slot connection.


+   ControlSearchAdv * ctrl_;
+   WorkArea * origWorkArea_;   // The work area in which to search
+   GuiWorkArea * searchWorkArea_;  // The work area defining what to search

This GuiWorkArea is a child of QSearchAdvDialog right?


Index: src/frontends/qt4/QSearchAdv.cpp
===
+   origWorkArea_ = theApp()->currentView()->currentWorkArea();
+	searchWorkArea_ = new GuiWorkArea(frameRect.width(), 
frameRect.height(), 10, *theApp()->currentView());


Good.

+   searchWorkArea_->setBufferView(&ctrl_->bufferView());
+   searchWorkArea_->connectBuffer(ctrl->buffer());

You will need to simplify this with my branch.

I'll try to look at the Controller code tommorrow.

Good stuff ;-)

Abdel.



Re: [PATCH] Re: Current svn: Crash with pdfsync

2007-07-16 Thread Bennett Helm

On Jul 16, 2007, at 1:46 PM, Abdelrazak Younes wrote:

One additional (minor) problem I've noticed: if you start with a  
saved file, and then use pdfsync to jump to a location in that  
file, it marks the file as changed. Shall I file this as a  
separate bug report?


Yes if it doesn't already exist.


Done:



Bennett


Re: [PATCH] Re: Current svn: Crash with pdfsync

2007-07-16 Thread Abdelrazak Younes

Bennett Helm wrote:

On Jul 16, 2007, at 1:11 PM, Abdelrazak Younes wrote:


Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746
Could you please verify that your cursor was not within an inset 
before using pdfsync? Could you also try to reproduce the crash when 
the cursor is in the _main_ text? If you cannot, then I might be able 
to cure this bug.


If you confirm then you might want to try the attached patch.


That seems to fix the problem. (I've tried in various types of insets 
without a problem.)


OK, Jose shall I commit? Please note that I have two other patches 
pending...




One additional (minor) problem I've noticed: if you start with a saved 
file, and then use pdfsync to jump to a location in that file, it marks 
the file as changed. Shall I file this as a separate bug report?


Yes if it doesn't already exist.

Abdel.



Re: Search LyX Text Functionality.

2007-07-16 Thread Tommaso Cucinotta

Richard Heck ha scritto:
Yes, it doesn't actually commit anything: only svn ci will do that. 
svn add just registers the files with your local copy, so svn diff, 
etc, will see them.

In fact, done. Please, find the patched patch at bug 3998.

 http://bugzilla.lyx.org/show_bug.cgi?id=3998

Added missing files in diff (QSearchAdv.{cpp,h}, SearchAdvUi.ui). Cleaned up
commented code.

Use: open a document, C-S-f, type what you want to search (also math
expressions) then hit Enter to repeatidly Find the next match, hit Esc to go
back to the document. C-S-f shows the dialog again with the last search (could
be improved to store and allow browsing of last searches).

T.



Re: [PATCH] Re: Current svn: Crash with pdfsync

2007-07-16 Thread Bennett Helm

On Jul 16, 2007, at 1:11 PM, Abdelrazak Younes wrote:


Abdelrazak Younes wrote:

Bennett Helm wrote:

On Jul 16, 2007, at 11:45 AM, Abdelrazak Younes wrote:


Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click  
in the .pdf file of an open LyX document. Recently I've been  
getting crashes. Here's the console output:
Assertion triggered in void lyx::Text::setCursorIntern 
(lyx::Cursor&, lyx::pit_type, lyx::pos_type, bool, bool) by  
failing check "this == cur.text()" in file Text2.cpp:746

Is there more info I should provide?


A backtrace :-)


How's this? --

Assertion triggered in void lyx::Text::setCursorIntern 
(lyx::Cursor&, lyx::pit_type, lyx::pos_type, bool, bool) by  
failing check "this == cur.text()" in file Text2.cpp:746
Could you please verify that your cursor was not within an inset  
before using pdfsync? Could you also try to reproduce the crash  
when the cursor is in the _main_ text? If you cannot, then I might  
be able to cure this bug.


If you confirm then you might want to try the attached patch.


That seems to fix the problem. (I've tried in various types of insets  
without a problem.)


One additional (minor) problem I've noticed: if you start with a  
saved file, and then use pdfsync to jump to a location in that file,  
it marks the file as changed. Shall I file this as a separate bug  
report?


Bennett



Re: Search LyX Text Functionality.

2007-07-16 Thread Richard Heck

Abdelrazak Younes wrote:

Richard Heck wrote:

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:
- First your patch is not complete in bugzilla, the added 
QSearch.{h,cpp} and QSearchAdv.{h,cpp} are missing. Please send a 
complete patch.
Hello, I used "svn diff src lib > lyx.patch", and I didn't notice it 
was not adding new files to
the patch. Any switch to svn that might do what I need, here ? Or 
just a standard way to

produce patches with svn (I used to use CVS for all past projects).

You need to add the files to the repository so svn will see them:
   svn add QSearch.{h,cpp} QSearchAdv.{h,cpp}
should do it.


I was about to say that too but the problem is that Tommaso does not 
have commit priviledge; will "svn add" work without that?
Yes, it doesn't actually commit anything: only svn ci will do that. svn 
add just registers the files with your local copy, so svn diff, etc, 
will see them.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: Current svn: Crash with pdfsync

2007-07-16 Thread Bennett Helm

On Jul 16, 2007, at 12:52 PM, Abdelrazak Younes wrote:


Bennett Helm wrote:

On Jul 16, 2007, at 11:45 AM, Abdelrazak Younes wrote:

Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click  
in the .pdf file of an open LyX document. Recently I've been  
getting crashes. Here's the console output:
Assertion triggered in void lyx::Text::setCursorIntern 
(lyx::Cursor&, lyx::pit_type, lyx::pos_type, bool, bool) by  
failing check "this == cur.text()" in file Text2.cpp:746

Is there more info I should provide?


A backtrace :-)

How's this? --
Assertion triggered in void lyx::Text::setCursorIntern 
(lyx::Cursor&, lyx::pit_type, lyx::pos_type, bool, bool) by  
failing check "this == cur.text()" in file Text2.cpp:746


Could you please verify that your cursor was not within an inset  
before using pdfsync? Could you also try to reproduce the crash  
when the cursor is in the _main_ text? If you cannot, then I might  
be able to cure this bug.


It was in an inset -- a Shaded Note inset. I haven't been able to  
trigger the crash without the cursor being in an inset.



Some more question below:


Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) bt
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x000ec0ad in lyx::support::abort () at abort.cpp:25
#4  0x000c7c74 in lyx::Text::setCursorIntern (this=0xf10737c,  
[EMAIL PROTECTED], par=708, pos=0, setfont=true, boundary=false) at  
Text2.cpp:746
#5  0x000c7d1a in lyx::Text::setCursor (this=0xf10737c,  
[EMAIL PROTECTED], par=708, pos=0, setfont=1, boundary=0) at  
Text2.cpp:714


Could you verify that paragraph number 708 exists? If it doesn't  
then we have a problem with TexRow::getIdFromRow(). I remember that  
Alfredo had a patch concerning this TexRow class but I cannot  
remember the bug number.


Yes, it exists: it contains only a Shaded Note, itself with several  
paragraphs.


#6  0x00025d1d in lyx::BufferView::setCursorFromRow  
(this=0xe9d1530, row=11812) at BufferView.cpp:1265


Ouch... row=11812! Is the document that big?


Yes. ;)

#7  0x0008615e in lyx::LyXFunc::dispatch (this=0xe91cd60,  
[EMAIL PROTECTED]) at LyXFunc.cpp:1261
#8  0x00096e06 in lyx::Server::callback (serv=0xe9bfda0,  
[EMAIL PROTECTED]) at Server.cpp:464
#9  0x000963e8 in lyx::LyXComm::read_ready (this=0xe9bfdd0) at  
Server.cpp:268
#10 0x007d5b7b in boost::_bi::bind_tlyx::LyXComm>, boost::_bi::list1  
>  >::operator() (this=0xe9fb0e0) at ../boost/boost/bind/ 
bind_template.hpp:20
#11 0x0077529b in boost::function0   
>::operator() (this=0xe9fb0dc) at ../boost/boost/function/ 
function_template.hpp:692
#12 0x00218ec2 in lyx::socket_callback::qt_metacall  
(this=0xe9fb0d0, _c=InvokeMetaMethod, _id=4, _a=0xbfffe9c8) at  
socket_callback.cpp:30


The information below seems bogus... I have difficulty to  
understand the backtrace at this point... Was the cursor inset an  
equation before the crash?


(Not an equation, but a note inset.)


#13 0x0023015a in QMetaObject::activate () at QLImage.cpp:173
#14 0x00609989 in QSocketNotifier::activated () at fileiter.cpp:214
#15 0x003c017c in QSocketNotifier::event () at cregex.cpp:428
#16 0x001c7d18 in QApplicationPrivate::notify_helper () at  
MathParser.cpp:1472

#17 0x001cbac9 in QApplication::notify () at MathParser.cpp:1472


Abdel.



Bennett


[PATCH] Re: Current svn: Crash with pdfsync

2007-07-16 Thread Abdelrazak Younes

Abdelrazak Younes wrote:

Bennett Helm wrote:

On Jul 16, 2007, at 11:45 AM, Abdelrazak Younes wrote:


Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click in 
the .pdf file of an open LyX document. Recently I've been getting 
crashes. Here's the console output:
Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746

Is there more info I should provide?


A backtrace :-)


How's this? --

Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746


Could you please verify that your cursor was not within an inset before 
using pdfsync? Could you also try to reproduce the crash when the cursor 
is in the _main_ text? If you cannot, then I might be able to cure this 
bug.


If you confirm then you might want to try the attached patch.

Abdel.

Index: BufferView.cpp
===
--- BufferView.cpp  (revision 19080)
+++ BufferView.cpp  (working copy)
@@ -1259,6 +1259,7 @@
 
buffer_->texrow().getIdFromRow(row, tmpid, tmppos);
 
+   cursor_.reset(buffer_->inset());
if (tmpid == -1)
buffer_->text().setCursor(cursor_, 0, 0);
else


Re: Search LyX Text Functionality.

2007-07-16 Thread Abdelrazak Younes

Richard Heck wrote:

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:
- First your patch is not complete in bugzilla, the added 
QSearch.{h,cpp} and QSearchAdv.{h,cpp} are missing. Please send a 
complete patch.
Hello, I used "svn diff src lib > lyx.patch", and I didn't notice it 
was not adding new files to
the patch. Any switch to svn that might do what I need, here ? Or just 
a standard way to

produce patches with svn (I used to use CVS for all past projects).

You need to add the files to the repository so svn will see them:
   svn add QSearch.{h,cpp} QSearchAdv.{h,cpp}
should do it.


I was about to say that too but the problem is that Tommaso does not 
have commit priviledge; will "svn add" work without that?


Abdel.



Re: Current svn: Crash with pdfsync

2007-07-16 Thread Abdelrazak Younes

Bennett Helm wrote:

On Jul 16, 2007, at 11:45 AM, Abdelrazak Younes wrote:


Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click in 
the .pdf file of an open LyX document. Recently I've been getting 
crashes. Here's the console output:
Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746

Is there more info I should provide?


A backtrace :-)


How's this? --

Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746


Could you please verify that your cursor was not within an inset before 
using pdfsync? Could you also try to reproduce the crash when the cursor 
is in the _main_ text? If you cannot, then I might be able to cure this bug.


Some more question below:


Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) bt
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x000ec0ad in lyx::support::abort () at abort.cpp:25
#4  0x000c7c74 in lyx::Text::setCursorIntern (this=0xf10737c, 
[EMAIL PROTECTED], par=708, pos=0, setfont=true, boundary=false) at 
Text2.cpp:746
#5  0x000c7d1a in lyx::Text::setCursor (this=0xf10737c, [EMAIL PROTECTED], 
par=708, pos=0, setfont=1, boundary=0) at Text2.cpp:714


Could you verify that paragraph number 708 exists? If it doesn't then we 
have a problem with TexRow::getIdFromRow(). I remember that Alfredo had 
a patch concerning this TexRow class but I cannot remember the bug number.



#6  0x00025d1d in lyx::BufferView::setCursorFromRow (this=0xe9d1530, 
row=11812) at BufferView.cpp:1265


Ouch... row=11812! Is the document that big?

#7  0x0008615e in lyx::LyXFunc::dispatch (this=0xe91cd60, 
[EMAIL PROTECTED]) at LyXFunc.cpp:1261
#8  0x00096e06 in lyx::Server::callback (serv=0xe9bfda0, 
[EMAIL PROTECTED]) at Server.cpp:464
#9  0x000963e8 in lyx::LyXComm::read_ready (this=0xe9bfdd0) at 
Server.cpp:268
#10 0x007d5b7b in boost::_bi::bind_tlyx::LyXComm>, boost::_bi::list1 > 
 >::operator() (this=0xe9fb0e0) at ../boost/boost/bind/bind_template.hpp:20
#11 0x0077529b in boost::function0 
 >::operator() (this=0xe9fb0dc) at 
../boost/boost/function/function_template.hpp:692
#12 0x00218ec2 in lyx::socket_callback::qt_metacall (this=0xe9fb0d0, 
_c=InvokeMetaMethod, _id=4, _a=0xbfffe9c8) at socket_callback.cpp:30


The information below seems bogus... I have difficulty to understand the 
backtrace at this point... Was the cursor inset an equation before the 
crash?



#13 0x0023015a in QMetaObject::activate () at QLImage.cpp:173
#14 0x00609989 in QSocketNotifier::activated () at fileiter.cpp:214
#15 0x003c017c in QSocketNotifier::event () at cregex.cpp:428
#16 0x001c7d18 in QApplicationPrivate::notify_helper () at 
MathParser.cpp:1472

#17 0x001cbac9 in QApplication::notify () at MathParser.cpp:1472


Abdel.



Re: Search LyX Text Functionality.

2007-07-16 Thread Richard Heck

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:
- First your patch is not complete in bugzilla, the added 
QSearch.{h,cpp} and QSearchAdv.{h,cpp} are missing. Please send a 
complete patch.
Hello, I used "svn diff src lib > lyx.patch", and I didn't notice it 
was not adding new files to
the patch. Any switch to svn that might do what I need, here ? Or just 
a standard way to

produce patches with svn (I used to use CVS for all past projects).

You need to add the files to the repository so svn will see them:
   svn add QSearch.{h,cpp} QSearchAdv.{h,cpp}
should do it.

Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: Search LyX Text Functionality.

2007-07-16 Thread Tommaso Cucinotta

Abdelrazak Younes ha scritto:
- First your patch is not complete in bugzilla, the added 
QSearch.{h,cpp} and QSearchAdv.{h,cpp} are missing. Please send a 
complete patch.
Hello, I used "svn diff src lib > lyx.patch", and I didn't notice it was 
not adding new files to
the patch. Any switch to svn that might do what I need, here ? Or just a 
standard way to

produce patches with svn (I used to use CVS for all past projects).
- Second, I have solved already the multi-workArea issue in my "mvc" 
branch. If you agree to rebase your work on it, I will help you 
refining the approach and I will commit it in my branch.

Of course I will. I'm going to download your branch.

My branch:

svn+ssh://svn.lyx.org/lyx/lyx-devel/branches/personal/younes/mvc

I intent to merge this branch to trunk as soon as trunk is opened and 
I have solved a few issues with the background banner and with child 
documents.

   T.


Re: Current svn: Crash with pdfsync

2007-07-16 Thread Bennett Helm

On Jul 16, 2007, at 11:45 AM, Abdelrazak Younes wrote:


Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click in  
the .pdf file of an open LyX document. Recently I've been getting  
crashes. Here's the console output:
Assertion triggered in void lyx::Text::setCursorIntern 
(lyx::Cursor&, lyx::pit_type, lyx::pos_type, bool, bool) by  
failing check "this == cur.text()" in file Text2.cpp:746

Is there more info I should provide?


A backtrace :-)


How's this? --

Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&,  
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this ==  
cur.text()" in file Text2.cpp:746


Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) bt
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x000ec0ad in lyx::support::abort () at abort.cpp:25
#4  0x000c7c74 in lyx::Text::setCursorIntern (this=0xf10737c,  
[EMAIL PROTECTED], par=708, pos=0, setfont=true, boundary=false) at  
Text2.cpp:746
#5  0x000c7d1a in lyx::Text::setCursor (this=0xf10737c,  
[EMAIL PROTECTED], par=708, pos=0, setfont=1, boundary=0) at Text2.cpp:714
#6  0x00025d1d in lyx::BufferView::setCursorFromRow (this=0xe9d1530,  
row=11812) at BufferView.cpp:1265
#7  0x0008615e in lyx::LyXFunc::dispatch (this=0xe91cd60,  
[EMAIL PROTECTED]) at LyXFunc.cpp:1261
#8  0x00096e06 in lyx::Server::callback (serv=0xe9bfda0,  
[EMAIL PROTECTED]) at Server.cpp:464
#9  0x000963e8 in lyx::LyXComm::read_ready (this=0xe9bfdd0) at  
Server.cpp:268
#10 0x007d5b7b in boost::_bi::bind_tlyx::LyXComm>, boost::_bi::list1 >  
>::operator() (this=0xe9fb0e0) at ../boost/boost/bind/ 
bind_template.hpp:20
#11 0x0077529b in boost::function0  
>::operator() (this=0xe9fb0dc) at ../boost/boost/function/ 
function_template.hpp:692
#12 0x00218ec2 in lyx::socket_callback::qt_metacall (this=0xe9fb0d0,  
_c=InvokeMetaMethod, _id=4, _a=0xbfffe9c8) at socket_callback.cpp:30

#13 0x0023015a in QMetaObject::activate () at QLImage.cpp:173
#14 0x00609989 in QSocketNotifier::activated () at fileiter.cpp:214
#15 0x003c017c in QSocketNotifier::event () at cregex.cpp:428
#16 0x001c7d18 in QApplicationPrivate::notify_helper () at  
MathParser.cpp:1472

#17 0x001cbac9 in QApplication::notify () at MathParser.cpp:1472
#18 0x00195484 in lyx::frontend::GuiApplication::notify  
(this=0xf017e00, receiver=0x1bfaffa0, event=0xbfffed34) at  
GuiApplication.cpp:238
#19 0x002150cf in QCoreApplication::notifyInternal () at  
QKeySymbol.cpp:105
#20 0x00397eaa in QEventDispatcherUNIX::activateSocketNotifiers () at  
cregex.cpp:428
#21 0x00398783 in QEventDispatcherUNIXPrivate::doSelect () at  
cregex.cpp:428
#22 0x002102bc in QApplicationPrivate::globalEventProcessor () at  
QKeySymbol.cpp:105

#23 0x92ddb537 in DispatchEventToHandlers ()
#24 0x92ddabdc in SendEventToEventTargetInternal ()
#25 0x92ddaaa1 in SendEventToEventTargetWithOptions ()
#26 0x92de2123 in ToolboxEventDispatcherHandler ()
#27 0x92ddb8ee in DispatchEventToHandlers ()
#28 0x92ddabdc in SendEventToEventTargetInternal ()
#29 0x92de1fbc in SendEventToEventTarget ()
#30 0x0020b518 in qt_mac_send_event () at QKeySymbol.cpp:105
#31 0x00396dce in QEventDispatcherMac::processEvents () at cregex.cpp: 
428

#32 0x003af344 in QEventLoop::processEvents () at cregex.cpp:428
#33 0x003af4c7 in QEventLoop::exec () at cregex.cpp:428
#34 0x00216bbd in QCoreApplication::exec () at QKeySymbol.cpp:105
#35 0x0007a8a9 in lyx::LyX::exec (this=0xb9f4, [EMAIL PROTECTED],  
argv=0xba80) at LyX.cpp:463

#36 0x3583 in main (argc=1, argv=0xba80) at main.cpp:48

Bennett



Re: [new patch] bug 1820

2007-07-16 Thread Dov Feldstern

José Matos wrote:

On Sunday 15 July 2007 10:47:46 Martin Vermeer wrote:

If the LaTeX output is different, I would say it is a format
change... the problem is then to produce a lyx2lyx entry
that would modify an old .lyx file upon conversion to the
new format so, that it nevertheless produces the old LaTeX
output... is this realistically doable?


  It needs to. :-)
  That is what we have been doing for this type of code cleanup for all other 
file formats that are not enhancements.


  And I agree with Martin, what you (Dov) are proposing is a file format 
change.



- Martin




Okay, I hope to clean the patch itself (for 1820) up tonight, once it is 
stable we'll have to see how to go about the lyx2lyx for it.


What about the reversed numbers in arabic_arabi --- is that also a 
format change? If so, it should also be fixed now, before 1.5.0. It 
should be really easy --- it's already being done for farsi, just need 
to do the same thing again for arabic_arabi.


Dov


Current svn: Crash with pdfsync

2007-07-16 Thread Bennett Helm
I'm using pdfsync via lyxpipe to have LyX jump to where I click in  
the .pdf file of an open LyX document. Recently I've been getting  
crashes. Here's the console output:


Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&,  
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this ==  
cur.text()" in file Text2.cpp:746


Is there more info I should provide?

Bennett


Re: Current svn: Crash with pdfsync

2007-07-16 Thread Abdelrazak Younes

Bennett Helm wrote:
I'm using pdfsync via lyxpipe to have LyX jump to where I click in the 
.pdf file of an open LyX document. Recently I've been getting crashes. 
Here's the console output:


Assertion triggered in void lyx::Text::setCursorIntern(lyx::Cursor&, 
lyx::pit_type, lyx::pos_type, bool, bool) by failing check "this == 
cur.text()" in file Text2.cpp:746


Is there more info I should provide?


A backtrace :-)

Abdel.



Re: Towards LyX 1.5.0

2007-07-16 Thread José Matos
On Monday 16 July 2007 01:01:34 Uwe Stöhr wrote:
> Hello LyXers,
>
> I think we should release LyX 1.5.0 this week, so if somebody can help with
> the lyx2lyx stuff please do so. (José, perhaps you can find an hour.)

  I have more time now. I have used more than one hour to look into the 
lyx2lyx problems. :-)

  And I agree that now is the right time. :-)

> Despite lyx2lyx I only got positive feedback for 1.5rc2, so I think it is
> time to release.

  I agree.

> best regards
> Uwe



-- 
José Abílio


Re: [new patch] bug 1820

2007-07-16 Thread José Matos
On Sunday 15 July 2007 10:47:46 Martin Vermeer wrote:
> If the LaTeX output is different, I would say it is a format
> change... the problem is then to produce a lyx2lyx entry
> that would modify an old .lyx file upon conversion to the
> new format so, that it nevertheless produces the old LaTeX
> output... is this realistically doable?

  It needs to. :-)
  That is what we have been doing for this type of code cleanup for all other 
file formats that are not enhancements.

  And I agree with Martin, what you (Dov) are proposing is a file format 
change.

> - Martin

-- 
José Abílio


Re: Travelling to Finland

2007-07-16 Thread Lars Gullik Bjønnes
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| I am planning to book by boatride now...
| 
| Departure:
| Stockholm-Åbo 2007/08/09 20:15
| At Åbo: 2007/08/10 08:00
| Return:
| Åbo-Stockholm 2007/08/13 21:15
| At Stockholm 2007/08/14 07:00
| 
| Will that work for you Martin?
| How different is my schedule from the others?

I decided to take a chance. The above is what I booked.

-- 
Lgb



Re: Development meeting fixed.

2007-07-16 Thread Lars Gullik Bjønnes
Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| > Are everything fixed, dates.
| > More attendents than one etc?
| > I am in the process of booking my trip, but am holding off slightly
| > to
| > get some feedback from the others going.
| 
| http://wiki.lyx.org/Devel/LyXMeeting2007

No hard info there. Wrt to booking etc.


-- 
Lgb



Re: Assertion when leaving LyX

2007-07-16 Thread Jean-Pierre Chrétien
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
[...]
> 
> We need the full context to help you. Please recompile
> in debug mode and 
> send us the full backtrace.

Here are the conditions:

env LD_OPTIONS=-R/usr/local/lib ./configure \
--with-version-suffix=-$VERS \
--with-frontend=qt4 --with-qt-dir=/usr/local/qt-4.2.1 \
--with-extra-lib=/usr/local/qt-4.2.1/lib --enable-debug \
--enable-stdlib-debug && make && make install

Debug (File-Close triggers the bug)

-> gdb /usr/local/bin/lyx-svn
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, 
and you are welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. 
Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run /tmp/test.lyx
Starting program: /usr/local/bin/lyx-svn /tmp/test.lyx
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
Assertion failed: __pos < size(), file
/usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6/../../../../\
include/c++/3.4.6/bits/basic_string.h,
line 643

Program received signal SIGABRT, Aborted.
0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1
(gdb) bt
#0  0xfdf592f0 in __sigprocmask () from /usr/lib/libthread.so.1
#1  0xfdf4e59c in _resetsig () from /usr/lib/libthread.so.1
#2  0xfdf4dd3c in _sigon () from /usr/lib/libthread.so.1
#3  0xfdf50d98 in _thrp_kill () from /usr/lib/libthread.so.1

That's all what I get :-(

TIA

-- 
Jean-Pierre






Re: Development meeting fixed.

2007-07-16 Thread Abdelrazak Younes

Lars Gullik Bjønnes wrote:

Are everything fixed, dates.
More attendents than one etc?

I am in the process of booking my trip, but am holding off slightly to
get some feedback from the others going.


http://wiki.lyx.org/Devel/LyXMeeting2007

Abdel.



Development meeting fixed.

2007-07-16 Thread Lars Gullik Bjønnes

Are everything fixed, dates.
More attendents than one etc?

I am in the process of booking my trip, but am holding off slightly to
get some feedback from the others going.

-- 
Lgb



Travelling to Finland

2007-07-16 Thread Lars Gullik Bjønnes

I am planning to book by boatride now...

Departure:
Stockholm-Åbo 2007/08/09 20:15
At Åbo: 2007/08/10 08:00
Return:
Åbo-Stockholm 2007/08/13 21:15
At Stockholm 2007/08/14 07:00

Will that work for you Martin?
How different is my schedule from the others?


-- 
Lgb


Re: Assertion when leaving LyX

2007-07-16 Thread Abdelrazak Younes

Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien <[EMAIL PROTECTED]> writes:



Solaris again, here is what I get when I leave LyX. Not much boring, but...

  ^^^
Perfectly boring, sorry: happens when I close a doc (an thus when I revert to
saved version), when I copy a formula, etc.

The context  in usr/local/lib/gcc/.../include/c++/3.4.6/bits/basic_string.h
is the following
  operator[](size_type __pos)
  {
_GLIBCXX_DEBUG_ASSERT(__pos < size());
_M_leak();
return _M_data()[__pos];
  }


We need the full context to help you. Please recompile in debug mode and 
send us the full backtrace.




Related to the tex2lyx segfault ?
http://article.gmane.org/gmane.editors.lyx.devel/89984


Probably not.



Re: Search LyX Text Functionality.

2007-07-16 Thread Abdelrazak Younes

Tommaso Cucinotta wrote:

Hi all,

please, consider the feature request I posted to bugzilla:
having an advanced search/replace functionality
allowing to find/replace segments of LyX Text, including
math.

Initial idea description and prototype implementation patch:

 http://bugzilla.lyx.org/show_bug.cgi?id=3982

Patch for full GUI-support (dockable search panel a'la Acrobat,
with its own GuiWorkArea):

 http://bugzilla.lyx.org/show_bug.cgi?id=3998

Core functionality in the patch is just basic, but I think that, at
least for the search part, it is not impossible to complete (with
reg exp search etc...). I'm available to complete the implementation,
if there is any chance for it to get into the mainstream branch.


Hello Tommaso,

Just to confirm that there is a good change to have it in trunk but I 
have two comments:
- First your patch is not complete in bugzilla, the added 
QSearch.{h,cpp} and QSearchAdv.{h,cpp} are missing. Please send a 
complete patch.
- Second, I have solved already the multi-workArea issue in my "mvc" 
branch. If you agree to rebase your work on it, I will help you refining 
the approach and I will commit it in my branch.


My branch:

svn+ssh://svn.lyx.org/lyx/lyx-devel/branches/personal/younes/mvc

I intent to merge this branch to trunk as soon as trunk is opened and I 
have solved a few issues with the background banner and with child 
documents.


Abdel.




Re: Assertion when leaving LyX

2007-07-16 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien <[EMAIL PROTECTED]> writes:

> 
> 
> Solaris again, here is what I get when I leave LyX. Not much boring, but...
  ^^^
Perfectly boring, sorry: happens when I close a doc (an thus when I revert to
saved version), when I copy a formula, etc.

The context  in usr/local/lib/gcc/.../include/c++/3.4.6/bits/basic_string.h
is the following
  operator[](size_type __pos)
  {
_GLIBCXX_DEBUG_ASSERT(__pos < size());
_M_leak();
return _M_data()[__pos];
  }

Related to the tex2lyx segfault ?
http://article.gmane.org/gmane.editors.lyx.devel/89984

-- 
Jean-Pierre




Search LyX Text Functionality.

2007-07-16 Thread Tommaso Cucinotta

Hi all,

please, consider the feature request I posted to bugzilla:
having an advanced search/replace functionality
allowing to find/replace segments of LyX Text, including
math.

Initial idea description and prototype implementation patch:

 http://bugzilla.lyx.org/show_bug.cgi?id=3982

Patch for full GUI-support (dockable search panel a'la Acrobat,
with its own GuiWorkArea):

 http://bugzilla.lyx.org/show_bug.cgi?id=3998

Core functionality in the patch is just basic, but I think that, at
least for the search part, it is not impossible to complete (with
reg exp search etc...). I'm available to complete the implementation,
if there is any chance for it to get into the mainstream branch.

Bye,

   T.


Re: Listings

2007-07-16 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
> In principle yes. But please don't delete all authors. 

I didn't do this explicitly. This is the consequence of rev 19019.

> The note should be 
> in a greyed-out note as the other ones in the document. I can also do this
> later today and commit.

Yes, please do that.

Jürgen


Re: Listings

2007-07-16 Thread Uwe Stöhr

Jürgen Spitzmüller schrieb:


Uwe, OK to xommit the attached?


In principle yes. But please don't delete all authors. The note should be in a greyed-out note as 
the other ones in the document. I can also do this later today and commit.


regards Uwe


tex2lyx segfaults on Solaris

2007-07-16 Thread Jean-Pierre Chrétien
Solaris again...

Create a simple file with lyx-svn (as of July 11), say tex2lyx.tex
Export as latex and reimport in lyx:

(gdb) ...
Starting program: /usr/local/bin/tex2lyx-svn tex2lyx.tex
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Program received signal SIGSEGV, Segmentation fault.
0xfed5776c in __gnu_debug::_Safe_iterator_base::_M_detach() ()
   from /usr/local/lib/libstdc++.so.6

gcc 3.4 again ?

-- 
Jean-Pierre