Hi,
I have had lyx 1.3.3 using the libqt3 toolkit dump core a couple of
times while I am messing with displayed equations. I am operating on
debian linux on an i686 laptop from ibm. I am saving a core dump if
anybody wants it.
Dave Raymond
I will update our boost extract to 1.31 later today.
Unless I get failure reports due to the patch I sent that is...
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Why do I get
>
| make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
| Making all in filesystem
| /bin/sh: line 1: cd: filesystem: No such file or directory
>
| even after 'autogen' and 'config.status --recheck'? (src != build)
Do you have t
Why do I get
make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
Making all in filesystem
/bin/sh: line 1: cd: filesystem: No such file or directory
even after 'autogen' and 'config.status --recheck'? (src != build)
Andre'
--
Those who desire to give up Freedom in order to gain Se
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
| | Keep your hat on.
>
| As suspected someone got scared...
>
| Anyhow this is just a heads up and a patch will all the boost changes.
| So if you want the (sudden) transition to boost 1.31 to go s
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Keep your hat on.
>
| Two points.
| 1. It hasn't even been released yet.
That is why "commit" has not been run yet.
| 2. I'm a bit sad that you had to include the python module. Bloat for
| the sake of it IMO.
Yes. I'll
Lars Gullik Bjønnes wrote:
> Keep your hat on.
Two points.
1. It hasn't even been released yet.
2. I'm a bit sad that you had to include the python module. Bloat for
the sake of it IMO.
--
Angus
Keep your hat on.
--
Lgb
On Wed, Feb 04, 2004 at 12:42:51PM +0100, Andre Poenitz spake thusly:
> On Wed, Feb 04, 2004 at 01:38:04PM +0200, Martin Vermeer wrote:
> > --- cursor.h3 Feb 2004 16:44:56 - 1.29
> > +++ cursor.h4 Feb 2004 11:24:41 -
> > @@ -33,6 +33,18 @@ class PainterInfo;
> > cla
On Wed, Feb 04, 2004 at 12:40:50PM +0100, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> I want to guarantee that temppath() is valid (this check is
> Georg> currently done in some places where it is used, but in other
> Georg> places it is assumed
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I want to guarantee that temppath() is valid (this check is
Georg> currently done in some places where it is used, but in other
Georg> places it is assumed that it is valid). However, I am not sure
Georg> wether the above works. Has an
On Wed, Feb 04, 2004 at 01:38:04PM +0200, Martin Vermeer wrote:
> --- cursor.h 3 Feb 2004 16:44:56 - 1.29
> +++ cursor.h 4 Feb 2004 11:24:41 -
> @@ -33,6 +33,18 @@ class PainterInfo;
> class MathUnknownInset;
> class MathGridInset;
>
> +
> +namespace turd {
> +
> +template
> +b
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Feb 04, 2004 at 09:01:58AM +0100, Lars Gullik Bjønnes spake thusly:
|
>>
>> >> BOOST_ASSERT(ptr_cmp(cur.inset(), this));
>> >>
>> >> template
>> >> bool ptr_cmp(A const * a, B const * b)
>> >> {
>> >> return a == b;
>> >> }
>> >
>>
On Wed, Feb 04, 2004 at 09:01:58AM +0100, Lars Gullik Bjønnes spake thusly:
>
> >> BOOST_ASSERT(ptr_cmp(cur.inset(), this));
> >>
> >> template
> >> bool ptr_cmp(A const * a, B const * b)
> >> {
> >> return a == b;
> >> }
> >
> | Ribbon, meet turd.
The good news is: the turd works. Sh
Andre Poenitz wrote:
> Solutions can be simple...
Please don't "solve" all of LyX using this method... ;-)
Alfredo
Solutions can be simple...
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
? .insetfootlike.h.swp
? 1.diff
Index: insetfootlike.C
===
this skips the middle part in LyXText-BufferView-LyXText::insertInset
and incidently fixes the recent crash when creating nested insets.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or b
On Wed, Feb 04, 2004 at 11:53:04AM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> This always returns 'true', so we can have 'void' instead and
> Andre> remove some never executed code...
>
> How come insetAllowed does not enter into the
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> This always returns 'true', so we can have 'void' instead and
Andre> remove some never executed code...
How come insetAllowed does not enter into the picture? At which place
do we decide that an inset is allowed or not?
Actually,
On Wed, Feb 04, 2004 at 11:09:56AM +0100, Lars Gullik Bj?nnes wrote:
> | Hmm, I know a few computer scientists who might disagree with you there
> | :)
>
> Are you thinking of functional languages (like ML) where all variables
> are immutable?
Course. And the funky thing they have to get round
On Wed, Feb 04, 2004 at 11:09:56AM +0100, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | On Wed, Feb 04, 2004 at 08:46:58AM +0100, Alfredo Braunstein wrote:
> >
> >> > BTW a general question: if the number of 'const' keywords in the code
> >> > increases, does that tend
On Wed, Feb 04, 2004 at 12:17:48PM +0200, Martin Vermeer wrote:
> > > - virtual void notifyCursorLeaves(idx_type) {}
> > > + virtual void notifyCursorLeaves(idx_type) const {}
> >
> > NO! The whole idea of these functions is to modify the insets logically.
> > They mustn't be const.
>
> But why d
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Feb 04, 2004 at 08:46:58AM +0100, Alfredo Braunstein wrote:
>
>> > BTW a general question: if the number of 'const' keywords in the code
>> > increases, does that tend to make the code better?
>>
>> A code with all its variables const is pretty use
On Wed, Feb 04, 2004 at 09:50:12AM +0100, Andre Poenitz spake thusly:
...
> > Index: cursor_slice.C
> > ===
> > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor_slice.C,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 curs
On Wed, Feb 04, 2004 at 09:47:31AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > This always returns 'true', so we can have 'void' instead and remove
> > some never executed code...
>
> Hold on! These lfuns can be called from outside can't they? So it's
> possible for a user to try and i
Andre Poenitz wrote:
> On Tue, Feb 03, 2004 at 10:34:16PM +0100, Lars Gullik Bjønnes wrote:
>> All this is just so super ugly that I cannot fathom why all other
>> compilers than 2.95 has to suffer by this.
>
> Well, you could as well decide that 2.95 is off the 'supported' list
> now. [I persona
On Wed, Feb 04, 2004 at 08:46:58AM +0100, Alfredo Braunstein wrote:
> > BTW a general question: if the number of 'const' keywords in the code
> > increases, does that tend to make the code better?
>
> A code with all its variables const is pretty useless generally :-P
Hmm, I know a few computer
On Wed, Feb 04, 2004 at 09:47:31AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > This always returns 'true', so we can have 'void' instead and remove
> > some never executed code...
>
> Hold on! These lfuns can be called from outside can't they? So it's
> possible for a user to try and i
Andre Poenitz wrote:
> This always returns 'true', so we can have 'void' instead and remove
> some never executed code...
Hold on! These lfuns can be called from outside can't they? So it's
possible for a user to try and insert an inset in a layout that
doesn't allow it. Isn't this the reason fo
On Wed, Feb 04, 2004 at 10:21:00AM +0100, Alfredo Braunstein wrote:
> >> Otherwise, we should ascertain that we have coordinates before (i.e. an
> >> update has been called) before calling LyXText::edit(x,y)... ugly.
> >
> > Or put some 'sensible' value there, i.e. LCursor::getPos() or similae
>
This always returns 'true', so we can have 'void' instead and remove
some never executed code...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: BufferView.C
Andre Poenitz wrote:
> Put it in and add a "#warning look here".
Done.
>> The fact is that it's kind of dumb to try to acess the insettext's
>> coordinates when it hasn't been drawn before: the user surely didn't
>> intended that when clicking (the inset wasn't visible). It seems cleaner
>> to
On Wed, Feb 04, 2004 at 09:50:43AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> The following patch should fix the crash. The culprit is that
> >> insetcollapsable::edit(x,y) should not call insettext::edit(cur,x,y) when
> >> opening (the inset was not visible before) but insette
Andre Poenitz wrote:
>> The following patch should fix the crash. The culprit is that
>> insetcollapsable::edit(x,y) should not call insettext::edit(cur,x,y) when
>> opening (the inset was not visible before) but insettext::edit(cur,
>> true).
>
> Hm.. is that a proper fix?
You tell me.
The fac
On Wed, Feb 04, 2004 at 09:50:36AM +0200, Martin Vermeer wrote:
> BTW a general question: if the number of 'const' keywords in the code
> increases, does that tend to make the code better?
Usually, yes.
Of course not, if the 'const' is const_cast'ed away afterwards.
> Index: cursor_slice.C
> ===
On Tue, Feb 03, 2004 at 10:34:16PM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Feb 03, 2004 at 04:12:13PM +0100, Andre Poenitz spake thusly:
> >>
> >> On Tue, Feb 03, 2004 at 05:14:58PM +0200, Martin Vermeer wrote:
> >> > It sure does help... prett
On Tue, Feb 03, 2004 at 09:11:51PM +0100, Alfredo Braunstein wrote:
> Kayvan A. Sylvan wrote:
>
> > The math mode seems to work again (no superscript crash) --- I have
> > not tested extensively.
> >
> > I noticed the following:
> >
> > 1) selection does not seem to be giving visual feedback (i.
On Tue, Feb 03, 2004 at 10:43:28AM -0800, Kayvan A. Sylvan wrote:
> The math mode seems to work again (no superscript crash) --- I have
> not tested extensively.
>
> I noticed the following:
>
> 1) selection does not seem to be giving visual feedback (i.e. I can position
>the cursor and then
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> And are you sure that the correct fix wouldn't be to make both insets
>> const? (that is after all the safer transition)
>
| That sounds better... like the attached? It compiles, but I wonder...
No... this was a bit over the top.
--
Lgb
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Feb 03, 2004 at 10:34:16PM +0100, Lars Gullik Bjønnes spake thusly:
>
| ...
>
>> All this is just so super ugly that I cannot fathom why all other
>> compilers than 2.95 has to suffer by this.
>
| Agreed...
|
>> IMHO const_cast is the wrong fi
Martin Vermeer wrote:
> BTW a general question: if the number of 'const' keywords in the code
> increases, does that tend to make the code better?
A code with all its variables const is pretty useless generally :-P
Alfredo
On Tue, Feb 03, 2004 at 10:34:16PM +0100, Lars Gullik Bjønnes spake thusly:
...
> All this is just so super ugly that I cannot fathom why all other
> compilers than 2.95 has to suffer by this.
Agreed...
> IMHO const_cast is the wrong fix. even a ptr_cmp function would have
> been better...
No
42 matches
Mail list logo
