Re: What are the main problems in CVS now?

[John Levon]

On Fri, Feb 11, 2005 at 10:18:25PM +0100, Andre Poenitz wrote:

> > What I am most concerned about is: Will there be any fundamental code
> > changes right after the release of LyX 1.4?
> 
> I would guess people will have a shot at XML file format which will
> probably change (and hopefully simplify) most of the export and import
> code.

I'd really want to work on the character style stuff.

john

Re: [patch] prevent crash in BufferParams::readGraphicsDriver()

[John Levon]

On Sat, Feb 12, 2005 at 05:23:58PM +0100, Georg Baum wrote:

> The last item of tex_graphics is "", not "last_item".

Fine, thanks.

john

Re: Some bugs

[John Levon]

On Fri, Feb 11, 2005 at 01:11:24AM +, John Levon wrote:

 Since I can't access bugzilla. I only tried for about 10 minutes so please

I filed all these now.

john

The cursor change

[John Levon]

It's easy to get droppings, load the user guiode and hold down the left
button to select stuff, then move about, eventually you'll see white
cursor droppings on the blue background

Andreas, please look at this again

john

Re: The cursor change / Bug 1790

[John Levon]

On Fri, Feb 11, 2005 at 07:49:50PM +, Andreas Vox wrote:

  In fact, just try selecting stuff with the mouse. The cursor is way
  ahead. I'll fix the comment to indicate the real reason.
 
 It's still perfect in Aqua. Cursor follows mouse, no droppings.
 Obviously platform dependent. Let's just hope it doesn't depend

Wow, that sucks :(

john

Re: Some bugs

[John Levon]

On Fri, Feb 11, 2005 at 01:11:24AM +, John Levon wrote:

> Since I can't access bugzilla. I only tried for about 10 minutes so please

I filed all these now.

john

The cursor change

[John Levon]

It's easy to get droppings, load the user guiode and hold down the left
button to select stuff, then move about, eventually you'll see white
cursor droppings on the blue background

Andreas, please look at this again

john

Re: The cursor change / Bug 1790

[John Levon]

On Fri, Feb 11, 2005 at 07:49:50PM +, Andreas Vox wrote:

> > In fact, just try selecting stuff with the mouse. The cursor is way
> > ahead. I'll fix the comment to indicate the real reason.
> 
> It's still perfect in Aqua. Cursor follows mouse, no droppings.
> Obviously platform dependent. Let's just hope it doesn't depend

Wow, that sucks :(

john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 03:51:56PM +0100, Lars Gullik Bj?nnes wrote:

 We have some 250 open bugs, but no idea if they exist in 1.3.x or in
 HEAD. We need to be able to mark the bugs so that we know what to work
 on.

If there's not marked with 'fixedintrunk', then they're probably still
there...

john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 04:24:07PM +0100, Jean-Marc Lasgouttes wrote:

 A possibility is to search for bugs reported against 1.4.0cvs.

I used to try mark regressions with 'regression'.

Whilst I don't have time to re-learn all the internals of LyX, I can
certainly try to do some triage...

Suffice to say there are LOTS of significant problems.

john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 06:12:06PM +0100, Georg Baum wrote:

 I think we should resolve these bugs to avoid mistakes like this. Either 
 as WONTFIX (because they won't be fixed in 1.3, I'd prefer that) or as 
 FIXED.

I don't think we should mark fixed bugs as WONTFIX, that's just too
unclear.

But I don't know of a decent way to search for 1.4-fixed bugs that are
still in 1.3.x otherwise...

john

Bugzilla help!

[John Levon]

I can't do anything with Bugzilla because of this:

00:44:05.548897 lambent.51199  aussie.lyx.org.http: P 1449:2567(1118) ack 1 
win 46 nop,nop,timestamp 3916868232 926092508 (DF)
00:44:05.684180 knoll.linpro.no  lambent: icmp: aussie.lyx.org unreachable - 
need to frag (mtu 1496)
00:44:05.684335 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916868368 926092508 (DF)
00:44:05.965938 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916868650 926092508 (DF)
00:44:06.529858 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916869214 926092508 (DF)
00:44:07.657677 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916870342 926092508 (DF)
00:44:09.913352 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916872598 926092508 (DF)
00:44:14.424638 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916877110 926092508 (DF)
00:44:23.447274 lambent.51199  aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46 nop,nop,timestamp 3916886134 926092508 (DF)

The first bit looks like normal MTU discovery, but then I don't hear anything 
back again! Anybody else?
Very occassionally bugzilla responds OK, but most of the time it's unusable.

I don't have these problems on any other site (including lyx ones), nor any 
other  bugzilla.

Lars, any ideas?

john

Re: Bug 1790: crashes due to pseudo-multithreading

[John Levon]

On Fri, Feb 11, 2005 at 12:56:26AM +0100, Andreas Vox wrote:

 I think the culprit is the call to sync_events() in
 LyXView::showCursor(). The comment says that it is needed for hiding
 the cursor correctly, but I commented this line out and I couldn't see
 any difference, except that there were no crashes any more. John?

The core has changed so much that that comment might well be irrelevant.

Please check overlapping windows with your WM, and flickling back and
forward with a blinking LyX cursor, using Page up/down etc.

I did a *lot* of work to fix cursor drawing, so it would be a shame if
it broke again.

john

Some bugs

[John Levon]

Since I can't access bugzilla. I only tried for about 10 minutes so please
don't think this is exhaustive. On the whole, the current CVS isn't too bad. A
couple of bad assertions, but after a few of these are fixed, I think we can
let Michael S loose. Massive improvement on last time... what have you lot been
doing? :)

1. crash by new doc, insert comment, then repeatedly click on the
   button to open and close the inset, until you get:

Assertion triggered in void LyXText::dispatch(LCursor, FuncRequest) by 
failing check cur.text() == this in file text3.C:361

2. the cursor is placed outside inset's red boundaries, this looks
   very confusing. I think  we need to add a buffer to inset's dimensions

3. Button insets are still not centred. I think someone closed this bug. It 
needs re-opening.

4. control-X on selected text in a table cell cuts the whole cell instead of 
just the selection

5. Any text cut from a table cell is gone forever

6. I have to click exactly in the middle of an empty table to cell in order to 
place
   the cursor there.

7. selection progression in table cells is broken. After selecting all text in 
a cell,
   another 'Right' should select the cell itself, and only then the next cell 
to the right.
   There's no way to select a table cell with the keyboard right now.

8. (usability issue) - minipage is just way too hard to find. We might consider 
a submenu
   for 'Box' that has Minipage, Parbox, Framed Box etc.

9. A new ERT inset has a width of zero, this is near impossible to use.

10. Pasting a paragraph about 50 times (lots of control-Vs) gives:

Assertion triggered in Point::Point(int, int) by failing check y  -3000 in 
file coordcache.h:27

   During this, the scrollbar is completely wrong.

11. Creating a new figure float, the 'Figure #:' of the caption is only seen on 
pressing return

12. Lars's on-screen translated  things like 'Part' etc. are broken. I get 
'Teil' in the DVI and
not on screen.

13. Undo is missing out lots of edits. Try entering 1,2,3,4 in a table (one on 
each row of the table)
then try to undo them. Generally broken in fact.

14. The footnote in the User Guide (first one) is inheriting the font from its 
containing paragraph. Not good ...

15. Right Address is (predictably enough) broken

john

Re: [patch] Bug 1119: race condition in Dialogs::show()

[John Levon]

On Fri, Feb 11, 2005 at 01:55:34AM +0100, Andreas Vox wrote:

 The attached patch just ignores subsequent calls to show if the old one 
 isn't finished yet.

I think this is pretty much the right thing to do. In the general sense
we can be half-initialised during show, so if we enter the event loop
for whatever reason we can be screwed. Note that we do this in Qt via
the -processEvents() in QDialogView.h (and we need to do this to ensure
updating the dialog doesn't screw up our button controller)

So, I'm OK with this patch, at least.

regards
john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 03:51:56PM +0100, Lars Gullik Bj?nnes wrote:

> We have some 250 open bugs, but no idea if they exist in 1.3.x or in
> HEAD. We need to be able to mark the bugs so that we know what to work
> on.

If there's not marked with 'fixedintrunk', then they're probably still
there...

john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 04:24:07PM +0100, Jean-Marc Lasgouttes wrote:

> A possibility is to search for bugs reported against 1.4.0cvs.

I used to try mark regressions with 'regression'.

Whilst I don't have time to re-learn all the internals of LyX, I can
certainly try to do some triage...

Suffice to say there are LOTS of significant problems.

john

Re: What are the main problems in CVS now?

[John Levon]

On Thu, Feb 10, 2005 at 06:12:06PM +0100, Georg Baum wrote:

> I think we should resolve these bugs to avoid mistakes like this. Either 
> as WONTFIX (because they won't be fixed in 1.3, I'd prefer that) or as 
> FIXED.

I don't think we should mark fixed bugs as WONTFIX, that's just too
unclear.

But I don't know of a decent way to search for 1.4-fixed bugs that are
still in 1.3.x otherwise...

john

Bugzilla help!

[John Levon]

I can't do anything with Bugzilla because of this:

00:44:05.548897 lambent.51199 > aussie.lyx.org.http: P 1449:2567(1118) ack 1 
win 46  (DF)
00:44:05.684180 knoll.linpro.no > lambent: icmp: aussie.lyx.org unreachable - 
need to frag (mtu 1496)
00:44:05.684335 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:05.965938 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:06.529858 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:07.657677 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:09.913352 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:14.424638 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)
00:44:23.447274 lambent.51199 > aussie.lyx.org.http: . 1:1445(1444) ack 1 win 
46  (DF)

The first bit looks like normal MTU discovery, but then I don't hear anything 
back again! Anybody else?
Very occassionally bugzilla responds OK, but most of the time it's unusable.

I don't have these problems on any other site (including lyx ones), nor any 
other  bugzilla.

Lars, any ideas?

john

Re: Bug 1790: crashes due to pseudo-multithreading

[John Levon]

On Fri, Feb 11, 2005 at 12:56:26AM +0100, Andreas Vox wrote:

> I think the culprit is the call to sync_events() in
> LyXView::showCursor(). The comment says that it is needed for hiding
> the cursor correctly, but I commented this line out and I couldn't see
> any difference, except that there were no crashes any more. John?

The core has changed so much that that comment might well be irrelevant.

Please check overlapping windows with your WM, and flickling back and
forward with a blinking LyX cursor, using Page up/down etc.

I did a *lot* of work to fix cursor drawing, so it would be a shame if
it broke again.

john

Some bugs

[John Levon]

Since I can't access bugzilla. I only tried for about 10 minutes so please
don't think this is exhaustive. On the whole, the current CVS isn't too bad. A
couple of bad assertions, but after a few of these are fixed, I think we can
let Michael S loose. Massive improvement on last time... what have you lot been
doing? :)

1. crash by new doc, insert comment, then repeatedly click on the
   button to open and close the inset, until you get:

Assertion triggered in void LyXText::dispatch(LCursor&, FuncRequest&) by 
failing check "cur.text() == this" in file text3.C:361

2. the cursor is placed outside inset's red boundaries, this looks
   very confusing. I think  we need to add a buffer to inset's dimensions

3. Button insets are still not centred. I think someone closed this bug. It 
needs re-opening.

4. control-X on selected text in a table cell cuts the whole cell instead of 
just the selection

5. Any text cut from a table cell is gone forever

6. I have to click exactly in the middle of an empty table to cell in order to 
place
   the cursor there.

7. selection progression in table cells is broken. After selecting all text in 
a cell,
   another 'Right' should select the cell itself, and only then the next cell 
to the right.
   There's no way to select a table cell with the keyboard right now.

8. (usability issue) - minipage is just way too hard to find. We might consider 
a submenu
   for 'Box' that has "Minipage", "Parbox", "Framed Box" etc.

9. A new ERT inset has a width of zero, this is near impossible to use.

10. Pasting a paragraph about 50 times (lots of control-Vs) gives:

Assertion triggered in Point::Point(int, int) by failing check "y > -3000" in 
file coordcache.h:27

   During this, the scrollbar is completely wrong.

11. Creating a new figure float, the 'Figure #:' of the caption is only seen on 
pressing return

12. Lars's on-screen translated  things like 'Part' etc. are broken. I get 
'Teil' in the DVI and
not on screen.

13. Undo is missing out lots of edits. Try entering 1,2,3,4 in a table (one on 
each row of the table)
then try to undo them. Generally broken in fact.

14. The footnote in the User Guide (first one) is inheriting the font from its 
containing paragraph. Not good ...

15. Right Address is (predictably enough) broken

john

Re: [patch] Bug 1119: race condition in Dialogs::show()

[John Levon]

On Fri, Feb 11, 2005 at 01:55:34AM +0100, Andreas Vox wrote:

> The attached patch just ignores subsequent calls to show if the old one 
> isn't finished yet.

I think this is pretty much the right thing to do. In the general sense
we can be half-initialised during show, so if we enter the event loop
for whatever reason we can be screwed. Note that we do this in Qt via
the ->processEvents() in QDialogView.h (and we need to do this to ensure
updating the dialog doesn't screw up our button controller)

So, I'm OK with this patch, at least.

regards
john

Re: Bugs in LyX 1.3.5

[John Levon]

On Mon, Feb 07, 2005 at 09:24:11PM -1000, John Burgess wrote:

 In the process, I've come across some bugs.

John, it's most helpful to us if you file these bugs in
http://bugzilla.lyx.org/ (one bug per report please!)

thanks,
john

Re: Bugs in LyX 1.3.5

[John Levon]

On Mon, Feb 07, 2005 at 09:24:11PM -1000, John Burgess wrote:

> In the process, I've come across some bugs.

John, it's most helpful to us if you file these bugs in
http://bugzilla.lyx.org/ (one bug per report please!)

thanks,
john

Re: Bug 1119: is LyX multithreaded after all?

[John Levon]

On Tue, Feb 08, 2005 at 01:41:55AM +0100, Andreas Vox wrote:

 Why do I think LyX is multithreaded? Well, not strictly, but the method
 sync_events() can cause similar effects. What I haven't figured out yet 

One of the perils of event-based programming is that you suddenly find
yourself dealing with race conditions :)

 is the exact sequence which could cause this crash, but the following
 micro-patch repairs this bug for me.

I wouldn't be really happy with this patch without knowing exactly what
the problem is...

john

Re: Bug 1119: is LyX multithreaded after all?

[John Levon]

On Tue, Feb 08, 2005 at 01:41:55AM +0100, Andreas Vox wrote:

> Why do I think LyX is multithreaded? Well, not strictly, but the method
> sync_events() can cause similar effects. What I haven't figured out yet 

One of the perils of event-based programming is that you suddenly find
yourself dealing with race conditions :)

> is the exact sequence which could cause this crash, but the following
> micro-patch repairs this bug for me.

I wouldn't be really happy with this patch without knowing exactly what
the problem is...

john

Sun Studio...

[John Levon]

For fun, I thought I'd try to compile lyx 1.3.5 with the version of Sun
Studio we use internally. I almost immediately got:

/bin/bash ../../../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I.
-I../../../../src -I../../../../boost-g -c -o cregex.lo `test -f
'cregex.cpp' || echo './'`cregex.cpp
CC -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -g -c
cregex.cpp
../../../../boost/boost/regex/detail/regex_match.hpp, line 218: Error:
Could not find a match for std::distancestd::ForwardIterator,
std::Distance(const char*, const char*).
../../../../boost/boost/regex/detail/regex_match.hpp, line 243:
Where: While instantiating boost::re_detail::_priv_match_dataconst
char*, boost::detail::allocatorchar::estimate_max_state_count(const
char*, const char*, unsigned, std::random_access_iterator_tag*).
../../../../boost/boost/regex/detail/regex_match.hpp, line 243:
Where: Instantiated from non-template code.

But I'm too lazy to make head or tail of this. Lars?

I'm doing a make -k and will report any others I see.

regards,
john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 06:15:02PM +, John Levon wrote:

 I'm doing a make -k and will report any others I see.

BTW, we now require GNU Make. We should document this in INSTALL.

formulabase.h, line 146: Warning: InsetFormulaBase::display hides the virtual 
function Inset::display(bool).
../../boost/boost/detail/iterator.hpp, line 333: Warning (Anachronism): Type 
names qualified by template parameters require typename.
../../boost/boost/detail/iterator.hpp, line 362: Where: While 
specializing boost::detail::iterator_traitsboost::detail::Iterator.
../../boost/boost/detail/iterator.hpp, line 362: Where: Specialized in 
non-template code.
../../boost/boost/detail/iterator.hpp, line 333: Warning (Anachronism): Type 
names qualified by template parameters require typename.
../../boost/boost/detail/iterator.hpp, line 362: Where: While 
specializing boost::detail::iterator_traitsboost::detail::Iterator.
../../boost/boost/detail/iterator.hpp, line 362: Where: Specialized in 
non-template code.
math_nestinset.h, line 114: Warning: MathNestInset::metrics hides the virtual 
function MathInset::metrics(MathMetricsInfo) const.
math_charinset.h, line 49: Warning: MathCharInset::match hides the virtual 
function MathInset::match(const MathAtom) const.
ref_inset.h, line 51: Warning: RefInset::getType hides the virtual function 
MathInset::getType() const.

math_nestinset.h, line 114: Warning: MathNestInset::metrics hides the virtual 
function MathInset::metrics(MathMetricsInfo) const.
math_arrayinset.C, line 48: Error: Could not find a match for 
std::vectorstd::string::vector(std::istream_iteratorstd::string, char, 
std::char_traitschar, int, std::istream_iteratorstd::string, char, 
std::char_traitschar, int).
1 Error(s) and 1 Warning(s) detected.


../../src/support/lyxalgo.h, line 79: Error: iterator_traits is not a member 
of std.
../../src/support/lyxalgo.h, line 79: Error: A declaration does not specify a 
tag or an identifier.
../../src/support/lyxalgo.h, line 79: Error: Templates can only declare 
classes or functions.
../../src/support/lyxalgo.h, line 86: Error: A declaration was expected 
instead of while.
../../src/support/lyxalgo.h, line 86: Error: ) expected instead of !=.
../../src/support/lyxalgo.h, line 108: Error: A declaration was expected 
instead of }.
math_mathmlstream.C, line 80: Error: count is not a member of lyx.


insetbib.h, line 121: Warning: InsetBibtex::display hides the virtual 
function Inset::display(bool).

And more...

john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 06:34:25PM +, Angus Leeming wrote:

 If that is the case, then that has changed recently. I've been able to
 build the XForms frontend quite happily with DEC make.

$ /usr/ccs/bin/make
make: Fatal error in reader: Makefile, line 625: Badly formed macro assignment
$ lineof -c 1 625 Makefile

# Hack so that the targets that use tar will also work with automake 1.4
AMTAR ?= $(TAR)


Been there for more than 2 years.

 The Qt frontend requires the use of some gnu-isms though.

OK, then *that* needs docs :)

regards,
john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 07:09:00PM +, Angus Leeming wrote:

 Or some input from the eejit wot wrote the gnuism on how to make his
 constuct portable ? :)

Ahem :)

john

Sun Studio...

[John Levon]

For fun, I thought I'd try to compile lyx 1.3.5 with the version of Sun
Studio we use internally. I almost immediately got:

/bin/bash ../../../../libtool --mode=compile CC -DHAVE_CONFIG_H -I. -I.
-I../../../../src -I../../../../boost-g -c -o cregex.lo `test -f
'cregex.cpp' || echo './'`cregex.cpp
CC -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -g -c
cregex.cpp
"../../../../boost/boost/regex/detail/regex_match.hpp", line 218: Error:
Could not find a match for std::distance(const char*, const char*).
"../../../../boost/boost/regex/detail/regex_match.hpp", line 243:
Where: While instantiating "boost::re_detail::_priv_match_data>::estimate_max_state_count(const
char*, const char*, unsigned, std::random_access_iterator_tag*)".
"../../../../boost/boost/regex/detail/regex_match.hpp", line 243:
Where: Instantiated from non-template code.

But I'm too lazy to make head or tail of this. Lars?

I'm doing a make -k and will report any others I see.

regards,
john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 06:15:02PM +, John Levon wrote:

> I'm doing a make -k and will report any others I see.

BTW, we now require GNU Make. We should document this in INSTALL.

"formulabase.h", line 146: Warning: InsetFormulaBase::display hides the virtual 
function Inset::display(bool).
"../../boost/boost/detail/iterator.hpp", line 333: Warning (Anachronism): Type 
names qualified by template parameters require "typename".
"../../boost/boost/detail/iterator.hpp", line 362: Where: While 
specializing "boost::detail::iterator_traits".
"../../boost/boost/detail/iterator.hpp", line 362: Where: Specialized in 
non-template code.
"../../boost/boost/detail/iterator.hpp", line 333: Warning (Anachronism): Type 
names qualified by template parameters require "typename".
"../../boost/boost/detail/iterator.hpp", line 362: Where: While 
specializing "boost::detail::iterator_traits".
"../../boost/boost/detail/iterator.hpp", line 362: Where: Specialized in 
non-template code.
"math_nestinset.h", line 114: Warning: MathNestInset::metrics hides the virtual 
function MathInset::metrics(MathMetricsInfo&) const.
"math_charinset.h", line 49: Warning: MathCharInset::match hides the virtual 
function MathInset::match(const MathAtom&) const.
"ref_inset.h", line 51: Warning: RefInset::getType hides the virtual function 
MathInset::getType() const.

"math_nestinset.h", line 114: Warning: MathNestInset::metrics hides the virtual 
function MathInset::metrics(MathMetricsInfo&) const.
"math_arrayinset.C", line 48: Error: Could not find a match for 
std::vector::vector(std::istream_iterator<std::string, char, 
std::char_traits, int>, std::istream_iterator<std::string, char, 
std::char_traits, int>).
1 Error(s) and 1 Warning(s) detected.


"../../src/support/lyxalgo.h", line 79: Error: iterator_traits is not a member 
of std.
"../../src/support/lyxalgo.h", line 79: Error: A declaration does not specify a 
tag or an identifier.
"../../src/support/lyxalgo.h", line 79: Error: Templates can only declare 
classes or functions.
"../../src/support/lyxalgo.h", line 86: Error: A declaration was expected 
instead of "while".
"../../src/support/lyxalgo.h", line 86: Error: ")" expected instead of "!=".
"../../src/support/lyxalgo.h", line 108: Error: A declaration was expected 
instead of "}".
"math_mathmlstream.C", line 80: Error: count is not a member of lyx.


"insetbib.h", line 121: Warning: InsetBibtex::display hides the virtual 
function Inset::display(bool).

And more...

john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 06:34:25PM +, Angus Leeming wrote:

> If that is the case, then that has changed recently. I've been able to
> build the XForms frontend quite happily with DEC make.

$ /usr/ccs/bin/make
make: Fatal error in reader: Makefile, line 625: Badly formed macro assignment
$ lineof -c 1 625 Makefile

# Hack so that the targets that use tar will also work with automake 1.4
AMTAR ?= $(TAR)


Been there for more than 2 years.

> The Qt frontend requires the use of some gnu-isms though.

OK, then *that* needs docs :)

regards,
john

Re: Sun Studio...

[John Levon]

On Wed, Feb 02, 2005 at 07:09:00PM +, Angus Leeming wrote:

> Or some input from the eejit wot wrote the gnuism on how to make his
> constuct portable ? :)

Ahem :)

john

Re: MSVC patch

[John Levon]

On Mon, Jan 31, 2005 at 02:23:54PM +0100, Lars Gullik Bj?nnes wrote:

 This version of is_readonly is racy. So for win32 we should try 

All versions of is_readonly() are racy, it's implicit in the API.

regards
john

Re: MSVC patch

[John Levon]

On Tue, Feb 01, 2005 at 11:46:17PM +0100, Lars Gullik Bj?nnes wrote:

 We shouldn't have to call readonly a lot anyway. The only place where
 I think it is needed is for informing the user that the loaded file
 is read only. For writing, we should just try to write.. and fail if
 we cannot do so.

Yep. Really we're informing them this file was at least one read only
at some point, so it might be why, but I agree it's not worthwhile to
use a race-free interface.

john

Re: MSVC patch

[John Levon]

On Mon, Jan 31, 2005 at 02:23:54PM +0100, Lars Gullik Bj?nnes wrote:

> This version of is_readonly is racy. So for win32 we should try 

All versions of is_readonly() are racy, it's implicit in the API.

regards
john

Re: MSVC patch

[John Levon]

On Tue, Feb 01, 2005 at 11:46:17PM +0100, Lars Gullik Bj?nnes wrote:

> We shouldn't have to call readonly a lot anyway. The only place where
> I think it is "needed" is for informing the user that the loaded file
> is read only. For writing, we should just try to write.. and fail if
> we cannot do so.

Yep. Really we're informing them "this file was at least one read only
at some point, so it might be why", but I agree it's not worthwhile to
use a race-free interface.

john

Branch vs. Box

[John Levon]

It seems to me that Box is going to be used more often than Branch
is. Shouldn't Box acquire the menu shortcut?

regards,
john

Re: [Patch] Kill FileInfo

[John Levon]

On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:

 This patch kills all uses and replace it with calls to
 boost.filesystem (+ a couple of new functions).

 int IsFileWriteable(string const  path)
 {
-   FileInfo fi(path);
-
-   if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
-   return 1;
-   if (fi.readable()) // read-only
-   return 0;
-   return -1; // everything else.
+   int ret = -1;
+   if (fs::is_readable(path))
+   ++ret;
+   if (fs::is_writable(path))
+   ++ret;
+   return ret;

Hmm, this doesn't look equivalent?

john

Branch vs. Box

[John Levon]

It seems to me that "Box" is going to be used more often than "Branch"
is. Shouldn't "Box" acquire the menu shortcut?

regards,
john

Re: [Patch] Kill FileInfo

[John Levon]

On Sun, Jan 30, 2005 at 10:48:56PM +0100, Lars Gullik Bj?nnes wrote:

> This patch kills all uses and replace it with calls to
> boost.filesystem (+ a couple of new functions).

 int IsFileWriteable(string const & path)
 {
-   FileInfo fi(path);
-
-   if (fi.access(FileInfo::wperm|FileInfo::rperm)) // read-write
-   return 1;
-   if (fi.readable()) // read-only
-   return 0;
-   return -1; // everything else.
+   int ret = -1;
+   if (fs::is_readable(path))
+   ++ret;
+   if (fs::is_writable(path))
+   ++ret;
+   return ret;

Hmm, this doesn't look equivalent?

john

Re: scripting support via lyxserver

[John Levon]

On Fri, Jan 28, 2005 at 09:01:04AM +, Angus Leeming wrote:

  Super-glad to see Asger back into the fold. He can be a less hated me!!
 He's just got a thicker skin ;-) How the hell are you anyway?

Fine, insanity at work has mitigated into mere eccentricity. I might
even build a recent lyx soon...

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 12:31:44PM +0100, Lars Gullik Bj?nnes wrote:

 int a[4];
 a+3 == a[3] == 3+a

Hah, you missed the really fun one: 3[a]

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 01:24:50PM +0100, Lars Gullik Bj?nnes wrote:

 (I have some code here that I work on now that uses it...)

My commiserations. (Though I have seen real-life code that uses Duff's
device...)

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 01:27:29PM +, Angus Leeming wrote:

 Was it needed, or was it an example of a call to the 'false god of
 efficiency'?

The latter as far as I could tell... and no, it's staying anonymous :)

john

Re: scripting support via lyxserver

[John Levon]

On Fri, Jan 28, 2005 at 09:01:04AM +, Angus Leeming wrote:

> > Super-glad to see Asger back into the fold. He can be a less hated me!!
> He's just got a thicker skin ;-) How the hell are you anyway?

Fine, insanity at work has mitigated into mere eccentricity. I might
even build a recent lyx soon...

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 12:31:44PM +0100, Lars Gullik Bj?nnes wrote:

> int a[4];
> a+3 == a[3] == 3+a

Hah, you missed the really fun one: 3[a]

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 01:24:50PM +0100, Lars Gullik Bj?nnes wrote:

> (I have some code here that I work on now that uses it...)

My commiserations. (Though I have seen real-life code that uses Duff's
device...)

john

Re: [Patch] Refactoring PreviewLoader

[John Levon]

On Fri, Jan 28, 2005 at 01:27:29PM +, Angus Leeming wrote:

> Was it needed, or was it an example of a call to the 'false god of
> efficiency'?

The latter as far as I could tell... and no, it's staying anonymous :)

john

Re: Questioning Why I Bother.

[John Levon]

On Fri, Jan 28, 2005 at 02:21:01AM +0100, Lars Gullik Bj?nnes wrote:

 Besides I am the only one allowed to be personally attacked in this
 forum.

Oh come on, you must consider Andre here. (For which I'm a bit sorry...)

john

Re: Let's All Attack John...

[John Levon]

On Fri, Jan 28, 2005 at 01:52:45AM +, Andreas Vox wrote:

 John, after what you told us about your situation I can understand you
 don't want any aggro from this list. But I don't see that *all* attack you,

Anyway, Mr. Weiss needs to know I've long since taken his title of
Least Popular John.

john

Re: scripting support via lyxserver

[John Levon]

On Thu, Jan 27, 2005 at 07:03:11PM +, Jose' Matos wrote:

   PS: In another movement (no pun John ;-) to help python scripting for lyx 

Is this a test on whether I'm still listening? :)

Super-glad to see Asger back into the fold. He can be a less hated me!!

john

Re: Questioning Why I Bother.

[John Levon]

On Fri, Jan 28, 2005 at 02:21:01AM +0100, Lars Gullik Bj?nnes wrote:

> Besides I am the only one allowed to be personally attacked in this
> forum.

Oh come on, you must consider Andre here. (For which I'm a bit sorry...)

john

Re: Let's All Attack John...

[John Levon]

On Fri, Jan 28, 2005 at 01:52:45AM +, Andreas Vox wrote:

> John, after what you told us about your situation I can understand you
> don't want any aggro from this list. But I don't see that *all* attack you,

Anyway, Mr. Weiss needs to know I've long since taken his title of
"Least Popular John".

john

Re: scripting support via lyxserver

[John Levon]

On Thu, Jan 27, 2005 at 07:03:11PM +, Jose' Matos wrote:

>   PS: In another movement (no pun John ;-) to help python scripting for lyx 

Is this a test on whether I'm still listening? :)

Super-glad to see Asger back into the fold. He can be a less hated me!!

john

Re: PayPal account opened for donations

[John Levon]

On Wed, Jan 12, 2005 at 06:53:35PM +0100, Lars Gullik Bj?nnes wrote:

 | Some information on what it'll get spent on would be good (you were
 | probably planning to do this anyway, but ...)
 
 Have you looked at the page?

I didn't notice it was committed at the time I sent the email.

 http://www.lyx.org/donations.php
 
 Please tell if it is something in particular that needs to change.

Seems fine to me

regards,
john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 11:06:29AM +0100, Lars Gullik Bj?nnes wrote:

 We should just change to use utf-8 all over.
 
 (and change the .php3 - .php)

Actually if you mention that, then we should drop extensions like that
altogether. http://lyx.org/donations; is cool, /donations.php
isn't...

john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 04:03:54PM +0100, Lars Gullik Bj?nnes wrote:

 | Actually if you mention that, then we should drop extensions like that
 | altogether. http://lyx.org/donations; is cool, /donations.php
 | isn't...
 
 Ok, please tell how to do this without having to insert aliases in the
 webserver conf.

No idea (helpful, huh?). mod_rewrite ?

I just did it by having a directory with 'index.php3' inside it for
every page

regards
john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 04:29:58PM +0100, Lars Gullik Bj?nnes wrote:

 Not possible to have more than one file in each dir...

Well, it just means you have a directory instead of a file...

 Can possibly be done by haveing a fram the encloses the whole page...

You don't mean a FRAMESET do you? Lord no :)

regards
john

Re: PayPal account opened for donations

[John Levon]

On Wed, Jan 12, 2005 at 06:53:35PM +0100, Lars Gullik Bj?nnes wrote:

> | Some information on what it'll get spent on would be good (you were
> | probably planning to do this anyway, but ...)
> 
> Have you looked at the page?

I didn't notice it was committed at the time I sent the email.

> http://www.lyx.org/donations.php
> 
> Please tell if it is something in particular that needs to change.

Seems fine to me

regards,
john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 11:06:29AM +0100, Lars Gullik Bj?nnes wrote:

> We should just change to use utf-8 all over.
> 
> (and change the .php3 -> .php)

Actually if you mention that, then we should drop extensions like that
altogether. "http://lyx.org/donations; is cool, "/donations.php"
isn't...

john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 04:03:54PM +0100, Lars Gullik Bj?nnes wrote:

> | Actually if you mention that, then we should drop extensions like that
> | altogether. "http://lyx.org/donations; is cool, "/donations.php"
> | isn't...
> 
> Ok, please tell how to do this without having to insert aliases in the
> webserver conf.

No idea (helpful, huh?). mod_rewrite ?

I just did it by having a directory with 'index.php3' inside it for
every page

regards
john

Re: PayPal account opened for donations

[John Levon]

On Thu, Jan 13, 2005 at 04:29:58PM +0100, Lars Gullik Bj?nnes wrote:

> Not possible to have more than one file in each dir...

Well, it just means you have a directory instead of a file...

> Can possibly be done by haveing a fram the encloses the whole page...

You don't mean a  do you? Lord no :)

regards
john

Re: PayPal account opened for donations

[John Levon]

On Wed, Jan 12, 2005 at 06:06:04PM +0100, Lars Gullik Bj?nnes wrote:

 I have just opened a PayPal account for the purpose of donations to
 the LyX Project.
 
 The address is: [EMAIL PROTECTED]
 
 I will put this information on the web, and also send a short note
 similar to this to the users list.

Some information on what it'll get spent on would be good (you were
probably planning to do this anyway, but ...)

regards
john

Re: PayPal account opened for donations

[John Levon]

On Wed, Jan 12, 2005 at 06:06:04PM +0100, Lars Gullik Bj?nnes wrote:

> I have just opened a PayPal account for the purpose of donations to
> the LyX Project.
> 
> The address is: [EMAIL PROTECTED]
> 
> I will put this information on the web, and also send a short note
> similar to this to the users list.

Some information on what it'll get spent on would be good (you were
probably planning to do this anyway, but ...)

regards
john

Re: [rework docs] reasons, plans, questions

[John Levon]

On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe St?hr wrote:

   The UserGuide will also have a short section about needed programs 
 and install issues for the platforms Linux/Unix, Mac and Win.

IMO, whilst such docs would be great, the User Guide is the wrong place
for it. I'd prefer such stuff to be on the website / wiki, plus a plain
ASCII file in the tarball

regards
john

Re: [rework docs] reasons, plans, questions

[John Levon]

On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe St?hr wrote:

>   The UserGuide will also have a short section about needed programs 
> and install issues for the platforms Linux/Unix, Mac and Win.

IMO, whilst such docs would be great, the User Guide is the wrong place
for it. I'd prefer such stuff to be on the website / wiki, plus a plain
ASCII file in the tarball

regards
john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Sat, Dec 04, 2004 at 03:42:45AM +0100, Alfredo Braunstein wrote:

 4) Your timing is admirable

What did I do...

john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Sat, Dec 04, 2004 at 01:21:34PM +0100, Lars Gullik Bj?nnes wrote:

 Well... this exact same thing has been discussed several times, you
 never piped up then...

Oh OK. I'll shut up then I suppose

john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Sat, Dec 04, 2004 at 03:42:45AM +0100, Alfredo Braunstein wrote:

> 4) Your timing is admirable

What did I do...

john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Sat, Dec 04, 2004 at 01:21:34PM +0100, Lars Gullik Bj?nnes wrote:

> Well... this exact same thing has been discussed several times, you
> never piped up then...

Oh OK. I'll shut up then I suppose

john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Fri, Dec 03, 2004 at 10:38:12PM +0100, Alfredo Braunstein wrote:

 Humm... right this is fault of the new coord scheme: now we don't know the
 full doc height so we cannot accurately compute the scrollbar height. I

BTW, why did you decide to go this route, when other word processors can
keep accurate scrollbars? I'm sure there's a good reason, I'd just like
to hear it

regards
john

Re: scrollbar problem (qt and xforms frontend)

[John Levon]

On Fri, Dec 03, 2004 at 10:38:12PM +0100, Alfredo Braunstein wrote:

> Humm... right this is fault of the new coord scheme: now we don't know the
> full doc height so we cannot accurately compute the scrollbar height. I

BTW, why did you decide to go this route, when other word processors can
keep accurate scrollbars? I'm sure there's a good reason, I'd just like
to hear it

regards
john

Re: Hyphenation mess :-(

[John Levon]

On Thu, Dec 02, 2004 at 12:02:20PM +0200, Martin Vermeer wrote:

 What about adding a panel Preferences-Language Settings-Hyphenation
 shortly explaining this?

Hmm, not a fan...

 It could even compile a short test file in the
 background extracting the phrase hyphenation patterns for ... loaded
 from the log. (or Reconfigure could do that.)

If we can test the case, then we can Edit-Reconfigure warn the user indeed.

john

Re: Hyphenation mess :-(

[John Levon]

On Thu, Dec 02, 2004 at 12:02:20PM +0200, Martin Vermeer wrote:

> What about adding a panel Preferences->Language Settings->Hyphenation
> shortly explaining this?

Hmm, not a fan...

> It could even compile a short test file in the
> background extracting the phrase "hyphenation patterns for ... loaded"
> from the log. (or Reconfigure could do that.)

If we can test the case, then we can Edit->Reconfigure warn the user indeed.

john

Re: Makefile.am typo?

[John Levon]

On Tue, Nov 30, 2004 at 08:59:28PM +, Angus Leeming wrote:

 Is '.' really a SUBDIR? It is defined as such only in these two
 Makefile.ams.

It's an ordering thing, it means make here before you descend.

john

Re: Makefile.am typo?

[John Levon]

On Tue, Nov 30, 2004 at 08:59:28PM +, Angus Leeming wrote:

> Is '.' really a SUBDIR? It is defined as such only in these two
> Makefile.ams.

It's an ordering thing, it means "make here before you descend".

john

Re: [patch] restore TABULAR::UNSET_ALL_LINES

[John Levon]

On Fri, Nov 26, 2004 at 08:50:10AM +0100, Juergen Spitzmueller wrote:

 BTW I'm gonna rename the set all borders button in the qt tabular dialog from 
 default to set, because it does not actually restore the default, but 
 sets all borders (which looks rather weird).

Sounds fine (although what would be really cool is fixing this dialog
for good ;)

john

Re: [patch] restore TABULAR::UNSET_ALL_LINES

[John Levon]

On Fri, Nov 26, 2004 at 08:50:10AM +0100, Juergen Spitzmueller wrote:

> BTW I'm gonna rename the set all borders button in the qt tabular dialog from 
> "default" to "set", because it does not actually restore the default, but 
> sets all borders (which looks rather weird).

Sounds fine (although what would be really cool is fixing this dialog
for good ;)

john

Re: [patch] restore TABULAR::UNSET_ALL_LINES

[John Levon]

On Thu, Nov 25, 2004 at 04:07:03PM +0100, Juergen Spitzmueller wrote:

 OK?
 Jürgen

Aha, you're the table maintainer now ? :)

Cool stuff...

regards
john

Re: [patch] restore TABULAR::UNSET_ALL_LINES

[John Levon]

On Thu, Nov 25, 2004 at 04:07:03PM +0100, Juergen Spitzmueller wrote:

> OK?
> Jürgen

Aha, you're the table maintainer now ? :)

Cool stuff...

regards
john

Re: LyX Status

[John Levon]

On Tue, Nov 09, 2004 at 10:08:50AM +0100, Juergen Spitzmueller wrote:

 What needs to be done beneath fixing the crashes is: getting the merge
 feature in a workable state again.

This is not a big deal, since it's new in 1.4, it can easily be backed
out.

regards
john

Re: LyX Status

[John Levon]

On Tue, Nov 09, 2004 at 10:08:50AM +0100, Juergen Spitzmueller wrote:

> What needs to be done beneath fixing the crashes is: getting the merge
> feature in a workable state again.

This is not a big deal, since it's new in 1.4, it can easily be backed
out.

regards
john

Re: booktabs

[John Levon]

I did try not to respond to this.

On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote:

 I'd rather officially lift the freeze for a short while and let
 everybody work on his pet project in this time. This also includes XML
 support as this is a thing of fairly high 'public interest' which also
 happens to be comparatively independent of the current core problems.

A decision was already made once that has screwed up LyX 1.4, please
don't do it again...

 The idea that in freeze time everybody starts fixing bugs might be nice
 in theory but seemingly does not work too well in reality. And this time
 is not the first time. 1.2 was no better.

We could have had 1.4 out of the door by now if we'd stopped soon after
Lars' STL-in-the-core changes.

 I'd really like to have a happy, busy lyx-devel list doing fancy things
 _including_ fixing a bug from time to time instead of a dead list with
 two kinds of corpses: Those that can't fix 'deep' bugs because they just
 started finding their ways around in LyX source, and those that
 theoretically could but feel defeated from several hundred open bugs and
 seemingly no support from anybody else.

You actively chose to rip the core code to shreds in the hope somebody
miight have time to rebuild it, and convinced Lars of it. I tried as
hard as I could to evangelise against this for precisely these reasons,
but lost the argument.

I don't want to annoy you any more, so I'll leave it here, but please
don't complain about situations you knowingly created.

regards,
john

Re: [patch] fix qt pref converters mess crash

[John Levon]

On Sun, Nov 07, 2004 at 09:32:50PM +0100, Andre Poenitz wrote:

   +   connect(convertersModule-converterToCO, SIGNAL(activated(const 
 QString)), this, SLOT(converter_changed()));
 
 LyXStyle would be  'QString const '.
 
 I know that early MOC had a problem with that, but as 3.3.3's moc
 definitely understands 'LyX style' I'd assume that 3.0.4's does as well.

Are you 100% positive of this? There have been several times when people
were under the impression this did/had worked, and I had to go back and
fix it all up again.

Regardless, we support older Qts, and they definitely were broken. (For
what it's worth, I wouldn't be concerned if we dropped support for such
Qt versions, but I don't think style quibbles is a good enough reason).

regards
john

Re: booktabs

[John Levon]

I did try not to respond to this.

On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote:

> I'd rather officially lift the freeze for a short while and let
> everybody work on his pet project in this time. This also includes XML
> support as this is a thing of fairly high 'public interest' which also
> happens to be comparatively independent of the current core problems.

A decision was already made once that has screwed up LyX 1.4, please
don't do it again...

> The idea that in freeze time everybody starts fixing bugs might be nice
> in theory but seemingly does not work too well in reality. And this time
> is not the first time. 1.2 was no better.

We could have had 1.4 out of the door by now if we'd stopped soon after
Lars' STL-in-the-core changes.

> I'd really like to have a happy, busy lyx-devel list doing fancy things
> _including_ fixing a bug from time to time instead of a dead list with
> two kinds of corpses: Those that can't fix 'deep' bugs because they just
> started finding their ways around in LyX source, and those that
> theoretically could but feel defeated from several hundred open bugs and
> seemingly no support from anybody else.

You actively chose to rip the core code to shreds in the hope somebody
miight have time to rebuild it, and convinced Lars of it. I tried as
hard as I could to evangelise against this for precisely these reasons,
but lost the argument.

I don't want to annoy you any more, so I'll leave it here, but please
don't complain about situations you knowingly created.

regards,
john

Re: [patch] fix qt pref converters mess & crash

[John Levon]

On Sun, Nov 07, 2004 at 09:32:50PM +0100, Andre Poenitz wrote:

>   +   connect(convertersModule->converterToCO, SIGNAL(activated(const 
> QString&)), this, SLOT(converter_changed()));
> 
> LyXStyle would be  'QString const &'.
> 
> I know that early MOC had a problem with that, but as 3.3.3's moc
> definitely understands 'LyX style' I'd assume that 3.0.4's does as well.

Are you 100% positive of this? There have been several times when people
were under the impression this did/had worked, and I had to go back and
fix it all up again.

Regardless, we support older Qts, and they definitely were broken. (For
what it's worth, I wouldn't be concerned if we dropped support for such
Qt versions, but I don't think style quibbles is a good enough reason).

regards
john

Re: [patch] fix installation of lib/scripts/* and lib/lyx2lyx/lyx2lyx

[John Levon]

On Mon, Nov 01, 2004 at 03:32:46PM +0100, Lars Gullik Bj?nnes wrote:

 IMHO (and this is going to be controversial) the whole version-suffix
 should be removed and if you want two Lyxen in parallell. you just
 configure with different --prefix.
 

So when are you going to fix the config file handling to be completely
lyx version independent?

regards
john

Re: [patch] fix installation of lib/scripts/* and lib/lyx2lyx/lyx2lyx

[John Levon]

On Mon, Nov 01, 2004 at 03:32:46PM +0100, Lars Gullik Bj?nnes wrote:

> IMHO (and this is going to be controversial) the whole version-suffix
> should be removed and if you want two Lyxen in parallell. you just
> configure with different --prefix.
> 

So when are you going to fix the config file handling to be completely
lyx version independent?

regards
john

Re: Route to 1.4.0

[John Levon]

On Thu, Oct 28, 2004 at 12:31:57PM +0200, Alfredo Braunstein wrote:

 Alfredo, phd for almost a day ;-)

Congratulations! Now, get to work!

john

Re: Route to 1.4.0

[John Levon]

On Thu, Oct 28, 2004 at 02:00:41PM +0200, Alfredo Braunstein wrote:

 btw, when exactly are you planning to stop playing around? (double-;-))

Oh, sometime in the next epoch...

john

Re: Route to 1.4.0

[John Levon]

On Thu, Oct 28, 2004 at 12:31:57PM +0200, Alfredo Braunstein wrote:

> Alfredo, phd for almost a day ;-)

Congratulations! Now, get to work!

john

Re: Route to 1.4.0

[John Levon]

On Thu, Oct 28, 2004 at 02:00:41PM +0200, Alfredo Braunstein wrote:

> btw, when exactly are you planning to stop playing around? (double-;-))

Oh, sometime in the next epoch...

john

Re: Route to 1.4.0

[John Levon]

On Tue, Oct 26, 2004 at 09:03:23AM +0300, Martin Vermeer wrote:

 To add my spicing to this soup, shouldn't we first take inventory of
 what bugs we actually have, and how critical they are? There is all
 kinds of stuff on bugzilla, and I suspect some of them must be
 absolutely fixed while others can be plastered over safely like Andre
 suggests... but could somebody make a clear compilation on this?

Anything with target milestone == 1.4.0 needs fixing. So people are
welcome to go triage bugs and set that as appropriate.

regards
john

Re: Route to 1.4.0

[John Levon]

On Tue, Oct 26, 2004 at 09:03:23AM +0300, Martin Vermeer wrote:

> To add my spicing to this soup, shouldn't we first take inventory of
> what bugs we actually have, and how critical they are? There is all
> kinds of stuff on bugzilla, and I suspect some of them must be
> absolutely fixed while others can be plastered over safely like Andre
> suggests... but could "somebody" make a clear compilation on this?

Anything with target milestone == 1.4.0 needs fixing. So people are
welcome to go triage bugs and set that as appropriate.

regards
john

Re: Route to 1.4.0

[John Levon]

On Sun, Oct 24, 2004 at 12:03:59PM +0200, Andre Poenitz wrote:

   That's why I propose changing some/most/all asserts to something less
   brutish, i.e. an exception carrying the same information as the assert
   that will be caught in the main loop (i.e. the outermost dispatch or
   even in the frontends).
  
  This seems an excellent route towards dataloss*.
 
 Not true. You can catch all of these exceptions in the main loop and pop
 up a flashing red sign something went wrong but I refuse to chrash
 right now. Things like this can be made obvious.

Sure, but how's that going to encourage users to use 1.4.0cvs?

john

Re: Bug 1687: request for help. :-)

[John Levon]

On Mon, Oct 25, 2004 at 12:06:33PM +0100, Jos? Ab?lio Oliveira Matos wrote:

http://bugzilla.lyx.org/attachment.cgi?id=597action=view

What I find strange is the frame #5:
 
 #5  0x00456f50 in Buffer::makeDocBookFile (this=0xb38fc0, [EMAIL PROTECTED],
 nice=true, only_body=false) at buffer.C:2945

Is the Buffer (this) valid?

john

Re: Bug 1687: request for help. :-)

[John Levon]

On Mon, Oct 25, 2004 at 01:28:15PM +0100, Jos? Ab?lio Oliveira Matos wrote:

  Is the Buffer (this) valid?
 
   You are right. The buffer changed between these two calls, even weird.
 
   It shouldn't, right?

It shouldn't ;)

john

Re: Route to 1.4.0

[John Levon]

On Mon, Oct 25, 2004 at 05:33:17PM +0200, Andre Poenitz wrote:

  Sure, but how's that going to encourage users to use 1.4.0cvs?
 
 If the result is still usable, it's usable.

The only people we're going to get using a program that brings up a
everything's screwed message every 10 minutes are people willing to
test lyx. And we already have those people...

 Right now we crash e.g. when we can place the cursor correctly after an
 'undo'. Of course it will be annoying to have the cursor jump to pos 0
 in the current par after an exceptionally tricky 'undo', but people have
 been living with that since day one for e.g. mathed (cursor always left
 mathed on undo()).
 
 So this is 'more usable' than a plain crash.

I'm also worried that people (i.e. the developers) will eventually get
used to these sort of regressions and not bother fixing them before
release.

 Of course, fixing the real problem is nicer and should be prefered in
 the long run, but I'd rather have a usable LyX in finite time than an
 unusable in infinite time.

(mouth firmly clamped shut)

regards,
john