Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| At the moment it seems that everyone, without exception, is frustrated by the
| current deadlock.

I'll try to explain why am am just not releasing 1.4.0 right away: I
continue to see small dribble of work that obviously some people deem
very important for a release. 

So perhaps going the active route is the approach.

Developer, if you have _anyting_ that you feel _must_ be included in
1.4.0, the time is to state so now, loud and clear.

-- 
Lgb

Re: Icon nastiness

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

 Angus == Angus Leeming [EMAIL PROTECTED]
 writes:
 
 Angus Is it just me, or does the LyX icon here look rubbish?
 Angus http://permalink.gmane.org/gmane.editors.lyx.devel/53215
 
 Angus Especially when it's compared to Martin's and Jean-Marc's
 Angus rather swizzy ones:
 Angus http://permalink.gmane.org/gmane.editors.lyx.devel/53214
 Angus http://permalink.gmane.org/gmane.editors.lyx.devel/53203
 
 I am not sure why I get two different INRIA icons...
 
 Angus We do have swankier icons; how do we get them used by the wider
 Angus world?
 
 I suspect they use the favicon from the web site.
 
 To get something better, submit a picon at
 http://members.cruzio.com/~jthomas/mailfaces/picons.html#piconcreate
 
 JMarc

I researched a bit more. It appears that the crappy icon is
http://cache.gmane.org/gmane/editors/lyx/devel/53303-favicon.png

I've also read the picons FAQ
http://www.cs.indiana.edu/picons/ftp/faq.html

We'd need to post an email:

To: [EMAIL PROTECTED]
Subject: lyx.org
Body: 48x48 XPM image, in line.

However, this image must use the AIcons collection colormap. Attached is
a ppm file containing this colormap (aicons.ppm).

I've converted John's image to a 48x48 png using the gimp (attached as
lyx48x48.png) but I don't know how to convert to a particular colormap
using the gimp.

I've converted this to ppm (lyx48x48.ppm) which loses the transparency data
but I reckon that's easy to add back.

However, using ppmquant to force this image to use the aicons.ppm colormap
doesn't produce very nice results.

ppmquant -floyd -mapfile aicons.ppm lyx48x48.ppm  lyx48x48_aicons.ppm
ppmquant -nofloyd -mapfile aicons.ppm lyx48x48.ppm  lyx48x48_aicons.ppm

So, I'm giving up. If some image manipulation guru could step in, that'd be
great.

Angus


aicons.ppm
Description: Portable pixmap


lyx48x48.png
Description: PNG image


lyx48x48.ppm
Description: Portable pixmap

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Angus Leeming]

Lars Gullik Bjønnes wrote:

 Angus Leeming [EMAIL PROTECTED] writes:
 
 | At the moment it seems that everyone, without exception, is frustrated
 | by the current deadlock.
 
 I'll try to explain why am am just not releasing 1.4.0 right away: I
 continue to see small dribble of work that obviously some people deem
 very important for a release.

Given that it's a dribble, why not branch for release now and open head for
real development again?

-- 
Angus

Re: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite)

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Abdelrazak Younes [EMAIL PROTECTED] writes:
|  Angus, I did removed the for_each methods but I let the inner class 
|  iterator and const_iterator because they could be useful in the future. 
|  Beside that they provide already operator+=. I am still open on that 
|  issue.
| 
| I am completely relaxed about this.
| 
| Lars, why don't you create a release candidate branch and allow Abdel to start
| committing stuff to head? Once you're happy that 1.4.0 is ready to be 
released,
| just create the tag on the branch as Boost does.

You are aware that branches can be used for playing and testing stuff?
(As well as letting other people try out your patches/changes in an
easy way.)

I am going to create branches/personal and tags/personal for exactly
this purpose.

-- 
Lgb

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Georg Baum]

Am Sonntag, 19. Februar 2006 13:30 schrieb Lars Gullik Bjønnes:

 I'll try to explain why am am just not releasing 1.4.0 right away: I
 continue to see small dribble of work that obviously some people deem
 very important for a release. 

I believe that this is a big misunderstanding: People do this and that 
because it is unclear when a release will happen and what should be 
contained. My impression is that 1.4.0 is mentally released and 
developers are developing for 1.4.1 (and later) really.

 So perhaps going the active route is the approach.

Yes.

 Developer, if you have _anyting_ that you feel _must_ be included in
 1.4.0, the time is to state so now, loud and clear.

John targetted some bugs to 1.4.0 recently. Of these, I would like to see 
the following in 1.4.0:

2251 (well understood and tested)
1161 (because this is a UI change that is best done in a major release)

Given the recent interest in lyx-users we should also think about 2238. 
The most important problem of this bug is that it can lead to dataloss, 
even without a single error message on the console. The patch I created 
is low risk, because it
a) restores what we have in 1.3,
b) works well for me, and 
c) the interface to LyX is restricted to the well known mechanism in 
math_factory.C and math_parser.C, so if it has still problems they will 
only occur for documents that contain \xymatrix. It is certainly better 
to risk some unknown problems with \xymatrix than knowing that LyX will 
throw away parts of \xymatrix for sure.

There are of course other problems, but IMHO they are not worth it to 
delay a release and/or not well enough understood (e.g. bug 2218)

Finally I think that we should state in the announcement that 1.4.0, 
although usable in general, still has some rough edges (e.g. speed, the 
spell checker problem 2218). And the change tracking should be advertised 
as experimental.


Georg

Re: Qt Runtime Dependency?

[Lars Gullik Bjønnes]

Daniel Watkins [EMAIL PROTECTED] writes:

| Hi list,
| Another query relating to my ebuild work. The creator of the last ebuild
| (for 1.4.0pre3) has set Qt up as a compile-time dependency only but has
| left a note saying he is unsure if this is accurate. Does LyX 1.4.0pre5
| (and we're assuming Qt is being used) need Qt to run or only to compile?

complile and link. So if you use dynamic linking you also need it to
run.

-- 
Lgb

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Georg Baum]

Am Sonntag, 19. Februar 2006 16:01 schrieb Lars Gullik Bjønnes:
 Georg Baum [EMAIL PROTECTED] writes:

 | 2251 (well understood and tested)
 
 But only cosmetic. I do not understand why it cannot wait.

Sure it is not so important, but I do not understand why it should wait. 
What do you expect to happen if we don't put it in 1.4.0? I believe it 
will then go in 1.4.1 exactly as it is now.

 Have anyone done any testing on 2243 at all?

I have it in my tree, it works for me, but I have an old dvipng (version 
1.5) that works also without the patch. At least this indicates that 
there are no regressions.

 | Given the recent interest in lyx-users we should also think about 
2238. 
 
 Have anyone tested this patch?

I have, but AFAIK nobody else.


Georg

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Martin Vermeer]

On Sun, Feb 19, 2006 at 04:01:14PM +0100, Lars Gullik Bjønnes wrote:
 Georg Baum [EMAIL PROTECTED] writes:
 
 |  Developer, if you have _anyting_ that you feel _must_ be included in
 |  1.4.0, the time is to state so now, loud and clear.
 | 
 | John targetted some bugs to 1.4.0 recently. Of these, I would like to see 
 | the following in 1.4.0:
 | 
 | 2251 (well understood and tested)
 
 But only cosmetic. I do not understand why it cannot wait.

Agreed.
 
...
 
 If you all are confident in the 2212 fix, it can go in.

I am confident, but it's near-useless without also multi-par change
tracking (which would make this a useable feature). Cosmetic, as
well. So... no, not now. 

- Martin



pgpkh6njOWsvS.pgp
Description: PGP signature

Re: Why not 1..40 right away?

[Michael Gerz]

Lars Gullik Bjønnes wrote:


Developer, if you have _anyting_ that you feel _must_ be included in
1.4.0, the time is to state so now, loud and clear.
 

Due to the fact that everybody has a different opinion on what must be 
included in 1.4.0, I would like to propose a different approach:


1. Let's go through the list of available patches
2. Ask people to test these patches (some of them have been tested already)
2. Let's decide which patches have been tested throughly and are 
trustworthy

3. Commit those patches without further discussion!
4. Let's see what we have achieved:
 4.1 Everybody happy? = release candiate 1.4.0
 4.2. Still some doubts? = goto 1

The important point is that we should NOT discuss on the IMPORTANCE of a 
patch. We are wasting energy this way. Let's discuss the patches themselves.


Is this a suitable way to cut the Gordian knot? I guess the discussion 
would be a lot less emotional.


Michael

Latest checkout fails to compile on Cygwin

[Kayvan A. Sylvan]

Here's what I am seeing. Any ideas?

make[4]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
make PCH_FLAGS= pch-file
make[5]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
g++ -DHAVE_CONFIG_H -I. -I../../../../../lyx/boost/libs/filesystem/src 
-I../../../../src   -DBOOST_USER_CONFIG=config.h -I../../../../../lyx/boost 
-I/usr/local/include  -Wextra -Wall-I/usr/X11R6/include -fno-exceptions -O2 
-mms-bitfields -x c++-header ../../../../../lyx/boost/libs/filesystem/src/pch.h 
-o ./pch.h.gch \
-MT ./pch.h.gch  -MD -MP -MF ././pch.h.gch.Tdep \
 mv ././pch.h.gch.Tdep ././pch.h.gch.dep \
|| rm ././pch.h.gch.Tdep
../../../../../lyx/boost/libs/filesystem/src/pch.h:20: internal compiler error: 
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
rm: cannot remove `././pch.h.gch.Tdep': No such file or directory
make[5]: *** [pch-file] Error 1
make[5]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
make[4]: *** [pch.h.gch] Error 2
make[4]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'

GCC version is 3.4.4

Edit Preferences File Formats mostly empty

[Daniel Watkins]

Hi list,
More ebuild stuff (though, having discovered the lack of an ebuild for the
most recent stable LyX version, I've switched from 1.4.0pre5 to 1.3.7).
When I first install LyX, Edit  Preferences  File Formats has no entries
under programs. I then used Edit  Reconfigure, which did fill in some of
the entries. However, there are still a lot missing, and I was just
wondering if that's my fault or if that's normal behaviour for LyX 1.3.7?

Thanks again for your time,
Dan

Re: Edit Preferences File Formats mostly empty

[Daniel Watkins]

I wrote:
 I then used Edit  Reconfigure...

Sorry to reply to my own message, but is there a way of just running a LyX
reconfigure from the command line (that'll exit immediate after the
reconfig)? I'd like to add it to the post-install section of the ebuild, to
get LyX operational faster.

Dan

Re: Edit Preferences File Formats mostly empty

[Georg Baum]

Am Sonntag, 19. Februar 2006 18:02 schrieb Daniel Watkins:
 Sorry to reply to my own message, but is there a way of just running a 
LyX
 reconfigure from the command line (that'll exit immediate after the
 reconfig)? I'd like to add it to the post-install section of the ebuild, 
to
 get LyX operational faster.

Yes. You can run the configure script without LyX, look at the %post macro 
in the rpm spec file development/lyx.spec.in.


Georg

Re: development/lyx.spec.in (Was Re: Edit Preferences File Formats mostly empty)

[Georg Baum]

Am Sonntag, 19. Februar 2006 18:32 schrieb Daniel Watkins:
 I've never really looked at RPM spec files before, so I am a little
 confused. I (think I) know %{name} refers to the package name (i.e. LyX)
 but can't figure out what directory %{_datadir} referring to. I'd
 appreciate it if someone could give me a shove in the right direction?

%{_datadir} is /usr/local/share in the default install. %{name} is lyx 
in the default install. If you use a version suffix -xxx, %{name} is 
lyx-xxx, and you must give the --with-version-suffix=-xxx argument to 
the configure script.


Georg

Re: About bugs targeted at 1.4.1

[Andre Poenitz]

On Sat, Feb 18, 2006 at 04:06:59PM +0100, Abdelrazak Younes wrote:
 I'm afraid this would need some changes to CutAndPaste.C because there 
 is a problem with the local c-like static variable theCuts. Apparently 
 the limited_stack class does not work well with my version of 
 ParagraphList: it does not keep the contents in memory outside 
 copySelectionHelper (but the sizes of ParagraphList and its paragraphs 
 are kept). I guess the reason why it worked with a vectorParagraph is 
 that std::vector keeps the data in a contiguous way. If I am right, 
 whatever strategy we choose for ParagraphList we will need to change th 
 way the Copy selection are stored.

I don't think anybody likes CutAndPaste.C too much/

 And the best solution is of course to create a class with a static member.
 I am sorry to say that CutAndPaste.C is a mess.

That's an understatement...

Andre'

Re: About bugs targeted at 1.4.1

[Andre Poenitz]

On Sat, Feb 18, 2006 at 06:16:56PM +0100, Abdelrazak Younes wrote:
 Abdelrazak Younes a écrit :
 Jean-Marc Lasgouttes a écrit :
 Andre == Andre Poenitz 
 [EMAIL PROTECTED] 
 writes:
 
 Is it to say that you will not allow the changes I've planned in my
 TODO list about ParagrahList in th 1.5svn timeframe for example?
 
 Andre I think you can be pretty confident that the ParagraphList will
 Andre go into 1.5.
 
 And _I_ would like to see it in 1.4 too, once it has proved correct.
 
 I'm afraid this would need some changes to CutAndPaste.C
 
 I take this back! I added a copy constructor to my it_vector and the 
 problem went away :-)

*shrug*

CutAndPaste.C is nevertheless a mess.

Andre'

Re: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite)

[Lars Gullik Bjønnes]

Michael Gerz [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
| 
| | Anyway, I attached again the last unchanged patch and the new
| | it_vector.h header.  Jean-Marc, if you could test this after 1.4.0,
| | I think it could be a good candidate for 1.4.1.
| 
| I must admit that I'd prefere it to be for 1.5 only. My guess is that
| the implementation suited for 1.4 will diverge quickly from what we
| will have in trunk.
| 
| Isn't this patch a prerequisite for correct bookmark handling? (I
| remember some problems with paragraph ids)

I do not think it is.

-- 
Lgb

Re: Latest checkout fails to compile on Cygwin

[Lars Gullik Bjønnes]

Kayvan A. Sylvan [EMAIL PROTECTED] writes:

| Here's what I am seeing. Any ideas?
| 
| make[4]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| make PCH_FLAGS= pch-file
| make[5]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| g++ -DHAVE_CONFIG_H -I. -I../../../../../lyx/boost/libs/filesystem/src 
-I../../../../src   -DBOOST_USER_CONFIG=config.h -I../../../../../lyx/boost 
-I/usr/local/include  -Wextra -Wall-I/usr/X11R6/include -fno-exceptions -O2 
-mms-bitfields -x c++-header ../../../../../lyx/boost/libs/filesystem/src/pch.h 
-o ./pch.h.gch \
| -MT ./pch.h.gch  -MD -MP -MF ././pch.h.gch.Tdep \
|  mv ././pch.h.gch.Tdep ././pch.h.gch.dep \
| || rm ././pch.h.gch.Tdep
| ../../../../../lyx/boost/libs/filesystem/src/pch.h:20: internal compiler 
error: Segmentation fault
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See URL:http://gcc.gnu.org/bugs.html for instructions.
| rm: cannot remove `././pch.h.gch.Tdep': No such file or directory
| make[5]: *** [pch-file] Error 1
| make[5]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| make[4]: *** [pch.h.gch] Error 2
| make[4]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| 
| GCC version is 3.4.4

And you have of course not changed _anything_ on your box?

No ideas, except don't do that then.

I am not willing to change anyting right now, but perhaps we should
run with pch as default off for pre-releases and releases in the
future? (safer)

-- 
Lgb

Re: Why not 1..40 right away?

[Lars Gullik Bjønnes]

Michael Gerz [EMAIL PROTECTED] writes:

| The important point is that we should NOT discuss on the IMPORTANCE of
| a patch. We are wasting energy this way. Let's discuss the patches
| themselves.

The patches themselves (if they are correct) are not important, it
_is_ what they fix and and the IMPORTANCE of the problem that matters.
 
| Is this a suitable way to cut the Gordian knot?

As you see we are comming from completely opposite ends, so I guess
not.

-- 
Lgb

Re: Why not 1..40 right away?

[Lars Gullik Bjønnes]

Michael Gerz [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
| 
| Developer, if you have _anyting_ that you feel _must_ be included in
| 1.4.0, the time is to state so now, loud and clear.
| 
| All the change tracking stuff should go in. It can't get worse.

Which part of the CT feature is not working?

Is it usable at all?
Does it kill your documents?
Reboot your box?

It can get a lot worse...

-- 
Lgb

Re: Why not 1..40 right away?

[Martin Vermeer]

On Sun, Feb 19, 2006 at 08:53:34PM +0100, Lars Gullik Bjønnes wrote:
 Michael Gerz [EMAIL PROTECTED] writes:
 
 | Lars Gullik Bjønnes wrote:
 | 
 | Developer, if you have _anyting_ that you feel _must_ be included in
 | 1.4.0, the time is to state so now, loud and clear.
 | 
 | All the change tracking stuff should go in. It can't get worse.
 
 Which part of the CT feature is not working?

Michael means the multi-paragraph part.
 
 Is it usable at all?

For some people apparently it is, which I find a bit surprising.

 Does it kill your documents?
 Reboot your box?
 
 It can get a lot worse...

Yes, a bad patch can break a lot more than just what it tries to fix.

Same for the fix to skip first change (2212 IIRC). On the surface it
is a cosmetic patch, but it makes some deep changes. So forget it at
this point. IMHO of course.

BTW what about creating a feature branch for CT directly under the
branches/ root? Makes playing around a little easier for people.

- Martin



pgpcunbf8B3Kc.pgp
Description: PGP signature

Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| At the moment it seems that everyone, without exception, is frustrated by the
| current deadlock.

I'll try to explain why am am just not releasing 1.4.0 right away: I
continue to see small dribble of work that obviously some people deem
very important for a release. 

So perhaps going the active route is the approach.

Developer, if you have _anyting_ that you feel _must_ be included in
1.4.0, the time is to state so now, loud and clear.

-- 
Lgb

Re: Icon nastiness

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
> 
> Angus> Is it just me, or does the LyX icon here look rubbish?
> Angus> http://permalink.gmane.org/gmane.editors.lyx.devel/53215
> 
> Angus> Especially when it's compared to Martin's and Jean-Marc's
> Angus> rather swizzy ones:
> Angus> http://permalink.gmane.org/gmane.editors.lyx.devel/53214
> Angus> http://permalink.gmane.org/gmane.editors.lyx.devel/53203
> 
> I am not sure why I get two different INRIA icons...
> 
> Angus> We do have swankier icons; how do we get them used by the wider
> Angus> world?
> 
> I suspect they use the favicon from the web site.
> 
> To get something better, submit a picon at
> http://members.cruzio.com/~jthomas/mailfaces/picons.html#piconcreate
> 
> JMarc

I researched a bit more. It appears that the crappy icon is
http://cache.gmane.org/gmane/editors/lyx/devel/53303-favicon.png

I've also read the picons FAQ
http://www.cs.indiana.edu/picons/ftp/faq.html

We'd need to post an email:

To: [EMAIL PROTECTED]
Subject: lyx.org
Body: 48x48 XPM image, in line.

However, this image must use the "AIcons collection" colormap. Attached is
a ppm file containing this colormap (aicons.ppm).

I've converted John's image to a 48x48 png using the gimp (attached as
lyx48x48.png) but I don't know how to convert to a particular colormap
using the gimp.

I've converted this to ppm (lyx48x48.ppm) which loses the transparency data
but I reckon that's easy to add back.

However, using ppmquant to force this image to use the aicons.ppm colormap
doesn't produce very nice results.

ppmquant -floyd -mapfile aicons.ppm lyx48x48.ppm > lyx48x48_aicons.ppm
ppmquant -nofloyd -mapfile aicons.ppm lyx48x48.ppm > lyx48x48_aicons.ppm

So, I'm giving up. If some image manipulation guru could step in, that'd be
great.

Angus


aicons.ppm
Description: Portable pixmap


lyx48x48.png
Description: PNG image


lyx48x48.ppm
Description: Portable pixmap

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | At the moment it seems that everyone, without exception, is frustrated
> | by the current deadlock.
> 
> I'll try to explain why am am just not releasing 1.4.0 right away: I
> continue to see small dribble of work that obviously some people deem
> very important for a release.

Given that it's a dribble, why not branch for release now and open head for
real development again?

-- 
Angus

Re: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite)

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > Angus, I did removed the "for_each" methods but I let the inner class 
| > iterator and const_iterator because they could be useful in the future. 
| > Beside that they provide already "operator+=". I am still open on that 
| > issue.
| 
| I am completely relaxed about this.
| 
| Lars, why don't you create a release candidate branch and allow Abdel to start
| committing stuff to head? Once you're happy that 1.4.0 is ready to be 
released,
| just create the tag on the branch as Boost does.

You are aware that branches can be used for playing and testing stuff?
(As well as letting other people try out your patches/changes in an
easy way.)

I am going to create branches/personal and tags/personal for exactly
this purpose.

-- 
Lgb

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Georg Baum]

Am Sonntag, 19. Februar 2006 13:30 schrieb Lars Gullik Bjønnes:

> I'll try to explain why am am just not releasing 1.4.0 right away: I
> continue to see small dribble of work that obviously some people deem
> very important for a release. 

I believe that this is a big misunderstanding: People do this and that 
because it is unclear when a release will happen and what should be 
contained. My impression is that 1.4.0 is "mentally released" and 
developers are developing for 1.4.1 (and later) really.

> So perhaps going the active route is the approach.

Yes.

> Developer, if you have _anyting_ that you feel _must_ be included in
> 1.4.0, the time is to state so now, loud and clear.

John targetted some bugs to 1.4.0 recently. Of these, I would like to see 
the following in 1.4.0:

2251 (well understood and tested)
1161 (because this is a UI change that is best done in a major release)

Given the recent interest in lyx-users we should also think about 2238. 
The most important problem of this bug is that it can lead to dataloss, 
even without a single error message on the console. The patch I created 
is low risk, because it
a) restores what we have in 1.3,
b) works well for me, and 
c) the interface to LyX is restricted to the well known mechanism in 
math_factory.C and math_parser.C, so if it has still problems they will 
only occur for documents that contain \xymatrix. It is certainly better 
to risk some unknown problems with \xymatrix than knowing that LyX will 
throw away parts of \xymatrix for sure.

There are of course other problems, but IMHO they are not worth it to 
delay a release and/or not well enough understood (e.g. bug 2218)

Finally I think that we should state in the announcement that 1.4.0, 
although usable in general, still has some rough edges (e.g. speed, the 
spell checker problem 2218). And the change tracking should be advertised 
as experimental.


Georg

Re: Qt Runtime Dependency?

[Lars Gullik Bjønnes]

Daniel Watkins <[EMAIL PROTECTED]> writes:

| Hi list,
| Another query relating to my ebuild work. The creator of the last ebuild
| (for 1.4.0pre3) has set Qt up as a compile-time dependency only but has
| left a note saying he is unsure if this is accurate. Does LyX 1.4.0pre5
| (and we're assuming Qt is being used) need Qt to run or only to compile?

complile and link. So if you use dynamic linking you also need it to
run.

-- 
Lgb

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Georg Baum]

Am Sonntag, 19. Februar 2006 16:01 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:

> | 2251 (well understood and tested)
> 
> But only cosmetic. I do not understand why it cannot wait.

Sure it is not so important, but I do not understand why it should wait. 
What do you expect to happen if we don't put it in 1.4.0? I believe it 
will then go in 1.4.1 exactly as it is now.

> Have anyone done any testing on 2243 at all?

I have it in my tree, it works for me, but I have an old dvipng (version 
1.5) that works also without the patch. At least this indicates that 
there are no regressions.

> | Given the recent interest in lyx-users we should also think about 
2238. 
> 
> Have anyone tested this patch?

I have, but AFAIK nobody else.


Georg

Re: Why not 1..40 right away? (was: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite))

[Martin Vermeer]

On Sun, Feb 19, 2006 at 04:01:14PM +0100, Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]> writes:
> 
> | > Developer, if you have _anyting_ that you feel _must_ be included in
> | > 1.4.0, the time is to state so now, loud and clear.
> | 
> | John targetted some bugs to 1.4.0 recently. Of these, I would like to see 
> | the following in 1.4.0:
> | 
> | 2251 (well understood and tested)
> 
> But only cosmetic. I do not understand why it cannot wait.

Agreed.
 
...
 
> If you all are confident in the 2212 fix, it can go in.

I am confident, but it's near-useless without also multi-par change
tracking (which would make this a useable feature). Cosmetic, as
well. So... no, not now. 

- Martin



pgpkh6njOWsvS.pgp
Description: PGP signature

Re: Why not 1..40 right away?

[Michael Gerz]

Lars Gullik Bjønnes wrote:


Developer, if you have _anyting_ that you feel _must_ be included in
1.4.0, the time is to state so now, loud and clear.
 

Due to the fact that everybody has a different opinion on what must be 
included in 1.4.0, I would like to propose a different approach:


1. Let's go through the list of available patches
2. Ask people to test these patches (some of them have been tested already)
2. Let's decide which patches have been tested throughly and are 
trustworthy

3. Commit those patches without further discussion!
4. Let's see what we have achieved:
 4.1 Everybody happy? => release candiate 1.4.0
 4.2. Still some doubts? => goto 1

The important point is that we should NOT discuss on the IMPORTANCE of a 
patch. We are wasting energy this way. Let's discuss the patches themselves.


Is this a suitable way to cut the Gordian knot? I guess the discussion 
would be a lot less emotional.


Michael

Latest checkout fails to compile on Cygwin

[Kayvan A. Sylvan]

Here's what I am seeing. Any ideas?

make[4]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
make PCH_FLAGS= pch-file
make[5]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
g++ -DHAVE_CONFIG_H -I. -I../../../../../lyx/boost/libs/filesystem/src 
-I../../../../src   -DBOOST_USER_CONFIG="" -I../../../../../lyx/boost 
-I/usr/local/include  -Wextra -Wall-I/usr/X11R6/include -fno-exceptions -O2 
-mms-bitfields -x c++-header ../../../../../lyx/boost/libs/filesystem/src/pch.h 
-o ./pch.h.gch \
-MT ./pch.h.gch  -MD -MP -MF "././pch.h.gch.Tdep" \
&& mv "././pch.h.gch.Tdep" "././pch.h.gch.dep" \
|| rm "././pch.h.gch.Tdep"
../../../../../lyx/boost/libs/filesystem/src/pch.h:20: internal compiler error: 
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
rm: cannot remove `././pch.h.gch.Tdep': No such file or directory
make[5]: *** [pch-file] Error 1
make[5]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
make[4]: *** [pch.h.gch] Error 2
make[4]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'

GCC version is 3.4.4

Edit > Preferences > File Formats mostly empty

[Daniel Watkins]

Hi list,
More ebuild stuff (though, having discovered the lack of an ebuild for the
most recent stable LyX version, I've switched from 1.4.0pre5 to 1.3.7).
When I first install LyX, Edit > Preferences > File Formats has no entries
under programs. I then used Edit > Reconfigure, which did fill in some of
the entries. However, there are still a lot missing, and I was just
wondering if that's my fault or if that's normal behaviour for LyX 1.3.7?

Thanks again for your time,
Dan

Re: Edit > Preferences > File Formats mostly empty

[Daniel Watkins]

I wrote:
> I then used Edit > Reconfigure...

Sorry to reply to my own message, but is there a way of just running a LyX
reconfigure from the command line (that'll exit immediate after the
reconfig)? I'd like to add it to the post-install section of the ebuild, to
get LyX operational faster.

Dan

Re: Edit > Preferences > File Formats mostly empty

[Georg Baum]

Am Sonntag, 19. Februar 2006 18:02 schrieb Daniel Watkins:
> Sorry to reply to my own message, but is there a way of just running a 
LyX
> reconfigure from the command line (that'll exit immediate after the
> reconfig)? I'd like to add it to the post-install section of the ebuild, 
to
> get LyX operational faster.

Yes. You can run the configure script without LyX, look at the %post macro 
in the rpm spec file development/lyx.spec.in.


Georg

Re: development/lyx.spec.in (Was Re: Edit > Preferences > File Formats mostly empty)

[Georg Baum]

Am Sonntag, 19. Februar 2006 18:32 schrieb Daniel Watkins:
> I've never really looked at RPM spec files before, so I am a little
> confused. I (think I) know %{name} refers to the package name (i.e. LyX)
> but can't figure out what directory %{_datadir} referring to. I'd
> appreciate it if someone could give me a shove in the right direction?

%{_datadir} is "/usr/local/share" in the default install. %{name} is "lyx" 
in the default install. If you use a version suffix "-xxx", %{name} is 
"lyx-xxx", and you must give the --with-version-suffix=-xxx argument to 
the configure script.


Georg

Re: About bugs targeted at 1.4.1

[Andre Poenitz]

On Sat, Feb 18, 2006 at 04:06:59PM +0100, Abdelrazak Younes wrote:
> I'm afraid this would need some changes to "CutAndPaste.C" because there 
> is a problem with the local c-like static variable theCuts. Apparently 
> the limited_stack class does not work well with my version of 
> ParagraphList: it does not keep the contents in memory outside 
> copySelectionHelper (but the sizes of ParagraphList and its paragraphs 
> are kept). I guess the reason why it worked with a vector is 
> that std::vector keeps the data in a contiguous way. If I am right, 
> whatever strategy we choose for ParagraphList we will need to change th 
> way the Copy selection are stored.

I don't think anybody likes CutAndPaste.C too much/

> And the best solution is of course to create a class with a static member.
> I am sorry to say that "CutAndPaste.C" is a mess.

That's an understatement...

Andre'

Re: About bugs targeted at 1.4.1

[Andre Poenitz]

On Sat, Feb 18, 2006 at 06:16:56PM +0100, Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
> >Jean-Marc Lasgouttes a écrit :
> >>>"Andre" == Andre Poenitz 
> >>><[EMAIL PROTECTED]> 
> >>>writes:
> >>
> Is it to say that you will not allow the changes I've planned in my
> TODO list about ParagrahList in th 1.5svn timeframe for example?
> >>
> >>Andre> I think you can be pretty confident that the ParagraphList will
> >>Andre> go into 1.5.
> >>
> >>And _I_ would like to see it in 1.4 too, once it has proved correct.
> >
> >I'm afraid this would need some changes to "CutAndPaste.C"
> 
> I take this back! I added a copy constructor to my it_vector and the 
> problem went away :-)

*shrug*

CutAndPaste.C is nevertheless a mess.

Andre'

Re: [PATCH] Speedup paragraph insertion/removal (a.k.a ParagraphList Rewrite)

[Lars Gullik Bjønnes]

Michael Gerz <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| >| Anyway, I attached again the last unchanged patch and the new
| >| "it_vector.h" header.  Jean-Marc, if you could test this after 1.4.0,
| >| I think it could be a good candidate for 1.4.1.
| >
| >I must admit that I'd prefere it to be for 1.5 only. My guess is that
| >the implementation suited for 1.4 will diverge quickly from what we
| >will have in trunk.
| >
| Isn't this patch a prerequisite for correct bookmark handling? (I
| remember some problems with paragraph ids)

I do not think it is.

-- 
Lgb

Re: Latest checkout fails to compile on Cygwin

[Lars Gullik Bjønnes]

"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:

| Here's what I am seeing. Any ideas?
| 
| make[4]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| make PCH_FLAGS= pch-file
| make[5]: Entering directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| g++ -DHAVE_CONFIG_H -I. -I../../../../../lyx/boost/libs/filesystem/src 
-I../../../../src   -DBOOST_USER_CONFIG="" -I../../../../../lyx/boost 
-I/usr/local/include  -Wextra -Wall-I/usr/X11R6/include -fno-exceptions -O2 
-mms-bitfields -x c++-header ../../../../../lyx/boost/libs/filesystem/src/pch.h 
-o ./pch.h.gch \
| -MT ./pch.h.gch  -MD -MP -MF "././pch.h.gch.Tdep" \
| && mv "././pch.h.gch.Tdep" "././pch.h.gch.dep" \
| || rm "././pch.h.gch.Tdep"
| ../../../../../lyx/boost/libs/filesystem/src/pch.h:20: internal compiler 
error: Segmentation fault
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See  for instructions.
| rm: cannot remove `././pch.h.gch.Tdep': No such file or directory
| make[5]: *** [pch-file] Error 1
| make[5]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| make[4]: *** [pch.h.gch] Error 2
| make[4]: Leaving directory 
`/home/kayvan/src/lyx/qtbuild/boost/libs/filesystem/src'
| 
| GCC version is 3.4.4

And you have of course not changed _anything_ on your box?

No ideas, except "don't do that then".

I am not willing to change anyting right now, but perhaps we should
run with pch as default off for pre-releases and releases in the
future? (safer)

-- 
Lgb

Re: Why not 1..40 right away?

[Lars Gullik Bjønnes]

Michael Gerz <[EMAIL PROTECTED]> writes:

| The important point is that we should NOT discuss on the IMPORTANCE of
| a patch. We are wasting energy this way. Let's discuss the patches
| themselves.

The patches themselves (if they are correct) are not important, it
_is_ what they fix and and the IMPORTANCE of the problem that matters.
 
| Is this a suitable way to cut the Gordian knot?

As you see we are comming from completely opposite ends, so I guess
not.

-- 
Lgb

Re: Why not 1..40 right away?

[Lars Gullik Bjønnes]

Michael Gerz <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| >Developer, if you have _anyting_ that you feel _must_ be included in
| >1.4.0, the time is to state so now, loud and clear.
| >
| All the change tracking stuff should go in. It can't get worse.

Which part of the CT feature is not working?

Is it usable at all?
Does it kill your documents?
Reboot your box?

It can get a lot worse...

-- 
Lgb

Re: Why not 1..40 right away?

[Martin Vermeer]

On Sun, Feb 19, 2006 at 08:53:34PM +0100, Lars Gullik Bjønnes wrote:
> Michael Gerz <[EMAIL PROTECTED]> writes:
> 
> | Lars Gullik Bjønnes wrote:
> | 
> | >Developer, if you have _anyting_ that you feel _must_ be included in
> | >1.4.0, the time is to state so now, loud and clear.
> | >
> | All the change tracking stuff should go in. It can't get worse.
> 
> Which part of the CT feature is not working?

Michael means the multi-paragraph part.
 
> Is it usable at all?

For some people apparently it is, which I find a bit surprising.

> Does it kill your documents?
> Reboot your box?
> 
> It can get a lot worse...

Yes, a bad patch can break a lot more than just what it tries to fix.

Same for the fix to "skip first change" (2212 IIRC). On the surface it
is a cosmetic patch, but it makes some deep changes. So forget it at
this point. IMHO of course.

BTW what about creating a feature branch for CT directly under the
branches/ root? Makes playing around a little easier for people.

- Martin



pgpcunbf8B3Kc.pgp
Description: PGP signature