Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:
Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the document path
* if this relative path starts
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:
Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the
However, what I experienced is that the absolute path is used even if the
included files are in the same directory as the lyx file, which is my case
and I started lyx always in the directory where the lyx file lives.
Regards,
On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
Marcin
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Guanglei the lyx file, which is my case and I started lyx always in
Guanglei the directory where the lyx file
Thanks for all the reply. I do use qt lyx.
On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Hi all,
I'm not subscribed to lyx-dev and I just have already too many email lists.
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I
figured I'd add a bit of info in case it helps the developers.
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org supplied
rpms.
I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.
This is the end of gdb story:
(no debugging symbols found)...(no
Fernando Perez wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17855)]
0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
/usr/lib/qt-3.1/lib/libqt-mt.so.3
(gdb) Killed
lyx: SIGHUP signal caught
Bye.
[~] Mutex destroy failure: Device
Alfredo Braunstein wrote:
Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps.
Under Gnome it's even a bit worse: after killing gdb and reentering X, the
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to
resucitate the
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent, so both A and B
--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Matej Cepl [EMAIL PROTECTED], 2003-07-01 14:22 -0400:
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using
James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent,
Yes, Fernando. I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday. I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.
No one has offered up an answer, and others suggest everything works the right
[EMAIL PROTECTED] wrote:
way. Someone suggested that my build might be on top of incompatible
libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems.
Fernando Perez wrote:
Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
have no debugging info in them. Sorry, but I don't have time right now to
Ah yes, forgot about that.
Thanks anyway, Alfredo
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?
On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote:
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
`class
John Levon [EMAIL PROTECTED] writes:
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
way. Someone suggested that my build might be on top of incompatible
libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104:
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef
Alfredo Braunstein wrote:
I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I
updated my qt/kde from freshrpms.org to:
kdelibs-3.1.2-0.fdr.3.rh80
Hi Fernando
my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.
[EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 =
I mailed Trolltech about the discussion, and there reply is:
I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:
Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the document path
* if this relative path starts
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:
Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the
However, what I experienced is that the absolute path is used even if the
included files are in the same directory as the lyx file, which is my case
and I started lyx always in the directory where the lyx file lives.
Regards,
On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
Marcin
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Guanglei the lyx file, which is my case and I started lyx always in
Guanglei the directory where the lyx file
Thanks for all the reply. I do use qt lyx.
On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:
Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Hi all,
I'm not subscribed to lyx-dev and I just have already too many email lists.
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I
figured I'd add a bit of info in case it helps the developers.
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org supplied
rpms.
I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.
This is the end of gdb story:
(no debugging symbols found)...(no
Fernando Perez wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17855)]
0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
/usr/lib/qt-3.1/lib/libqt-mt.so.3
(gdb) Killed
lyx: SIGHUP signal caught
Bye.
[~] Mutex destroy failure: Device
Alfredo Braunstein wrote:
Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps.
Under Gnome it's even a bit worse: after killing gdb and reentering X, the
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to
resucitate the
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent, so both A and B
--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Matej Cepl [EMAIL PROTECTED], 2003-07-01 14:22 -0400:
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using
James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent,
Yes, Fernando. I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday. I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.
No one has offered up an answer, and others suggest everything works the right
[EMAIL PROTECTED] wrote:
way. Someone suggested that my build might be on top of incompatible
libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems.
Fernando Perez wrote:
Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
have no debugging info in them. Sorry, but I don't have time right now to
Ah yes, forgot about that.
Thanks anyway, Alfredo
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?
On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote:
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
`class
John Levon [EMAIL PROTECTED] writes:
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
way. Someone suggested that my build might be on top of incompatible
libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104:
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef
Alfredo Braunstein wrote:
I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I
updated my qt/kde from freshrpms.org to:
kdelibs-3.1.2-0.fdr.3.rh80
Hi Fernando
my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.
[EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 =
I mailed Trolltech about the discussion, and there reply is:
I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers
> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
> "Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:
Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the document path
* if this relative
Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:
Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.
The algorithm used currently is:
* compute the included file path relative to the
However, what I experienced is that the absolute path is used even if the
included files are in the same directory as the lyx file, which is my case
and I started lyx always in the directory where the lyx file lives.
Regards,
On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
> >
> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
Guanglei> However, what I experienced is that the absolute path is
Guanglei> used even if the included files are in the same directory as
Guanglei> the lyx file, which is my case and I started lyx always in
Guanglei> the directory where
Thanks for all the reply. I do use qt lyx.
On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
> > "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
>
> Guanglei> However, what I experienced is that the absolute path is
> Guanglei> used even if the included files are in the same
Hi all,
I'm not subscribed to lyx-dev and I just have already too many email lists.
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I
figured I'd add a bit of info in case it helps the developers.
Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org
On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2, using the Lyx.org supplied
> rpms.
I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.
This is the end of gdb story:
(no debugging symbols found)...(no
Fernando Perez wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17855)]
> 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
> /usr/lib/qt-3.1/lib/libqt-mt.so.3
> (gdb) Killed
>
> lyx: SIGHUP signal caught
> Bye.
> [~]> Mutex destroy
Alfredo Braunstein wrote:
Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps.
Under Gnome it's even a bit worse: after killing gdb and reentering X, the
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to
resucitate the
On Tue, 1 Jul 2003, Robin Turner wrote:
> or
>
> simulacra - see simulacrum
> simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent, so both A
--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Matej Cepl <[EMAIL PROTECTED]>, 2003-07-01 14:22 -0400:
> On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> > Platform: RedHat 8.0, KDE 3.1, Qt 3.1. Lyx 1.3.2,
James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:
or
simulacra - see simulacrum
simulacrum, 6, 8, 16
A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index. I would love to have an option in the index
generator that says A and B are equivalent,
Yes, Fernando. I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday. I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.
No one has offered up an answer, and others suggest everything works the right
[EMAIL PROTECTED] wrote:
> way. Someone suggested that my build might be on top of incompatible
> libraries and includes, but did not suggest how to investigate this.
It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems.
Fernando Perez wrote:
> Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
> have no debugging info in them. Sorry, but I don't have time right now to
Ah yes, forgot about that.
Thanks anyway, Alfredo
- Forwarded message from [EMAIL PROTECTED] -
From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?
On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein
On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
> > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > types for `typedef struct OpaqueControlRef * ControlRef'
> > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > `class
John Levon <[EMAIL PROTECTED]> writes:
> On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
>
> > > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > > types for `typedef struct OpaqueControlRef * ControlRef'
> > >
On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
>> way. Someone suggested that my build might be on top of incompatible
>> libraries and includes, but did not suggest how to investigate this.
>
> It seems that we have to discard this, since you (and others) get the same
> with the
/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104:
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef
Alfredo Braunstein wrote:
I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I
updated my qt/kde from freshrpms.org to:
kdelibs-3.1.2-0.fdr.3.rh80
Hi Fernando
my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.
[EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 =>
I mailed Trolltech about the discussion, and there reply is:
I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers
75 matches
Mail list logo
