Thanks Garst... that script works great! I think I'm still going to
stick with cvs, I feel a little more secure knowing that this script can
(hopefully) get me out of trouble if I do run into major problems with
cvs and need to go back to 1.3...
nirmal
Garst R. Reese wrote:
See the attached, n
See the attached, not sure whether Andre or Angus contributed it, but it
what I used to solve your problem.
Garst
Nirmal Govind wrote:
>
> Hi.. so I need to port a couple of documents back to 1.3.3 from 1.4cvs..
> and looks like 1.3.3 can't read the 1.4cvs doc, not in any decent
> manner... is t
reason I need to go back to 1.3.3 is cos the table editing is broken now
in cvs - can't center the field, undo magically deletes all the entries
in the table etc..
Sorry, let me quickly retract some of what I said.. the centering does
work in the output, just not in the lyx window...
nirmal
Hi.. so I need to port a couple of documents back to 1.3.3 from 1.4cvs..
and looks like 1.3.3 can't read the 1.4cvs doc, not in any decent
manner... is there any way to restore my document so that I can start
editing it in 1.3.3 again? I converted to .tex and then imported it and
that did almos
Martin Vermeer wrote:
> Undoubtedly can be made to work... but it is 'politically' wise? If we
> go the way that Lars proposed and recommend people sticking to 2.95 to
> install and use stlport, than even the little extra hassle of
> writing/editing a configure_stlport script when a simple --use-st
Martin Vermeer wrote:
>> xforms/Dialogs.C is my code that happens to use a different string label
>> to ascertain which dialog to open.
>
> Yes, but where is it actually set?
Remember this?
string InsetBoxMailer::name_ = "box";
> And (I believe unrelatedly) where does my above "box" go to?
>
On Thu, Oct 02, 2003 at 03:19:49PM +, Angus Leeming spake thusly:
...
> > 2) Then, in the makefiles of src and src/tex2lyx I had to add to
> > LDFLAGS:
> > -lpthread -lstlport_gcc
> > (I didn't find a way to do that in configure)
>
> CXXFLAGS_STLPORT=...
> LDFLAGS_STLPORT=...
> ./configure C
On Thu, Oct 02, 2003 at 04:46:31PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
>
> >> Ain't this "Boxed"? (That's why using the enum is safer...)
> >>
> >> src/frontends/controllers/ControlBox.C
> >> +bool ControlBox::initialiseParams(string const & data)
> >> +{
> >> + Ins
Sorry to beat this horse, but I've gotten close on compiling lyx-1.3.3
with Apple's new gcc-3.3 and the Qt library, and wonder if anyone has a
suggestion for the remaining glitch. LyX compiles without protest with
CXXFLAGS=-Wno-long-double (i.e., no optimization), but the linker
reports:
ld:
Martin Vermeer wrote:
>> Ain't this "Boxed"? (That's why using the enum is safer...)
>>
>> src/frontends/controllers/ControlBox.C
>> +bool ControlBox::initialiseParams(string const & data)
>> +{
>> + InsetBoxParams params("box");
>
> I'm not sure if it's actually used. But look at xforms/D
Asger Kunuk Alstrup wrote:
> From what I see, you have managed to keep the changes to the external
> definition file pretty simple. I'd like to read your documentation,
> but I do not have LyX working. Can you export to ASCII and send it
> privately?
Attached. The document describes the ideas behi
On Thu, Oct 02, 2003 at 04:18:19PM +, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
> > Okay, here is then my latest. Anything left to do with this except
> > committing?
>
> Ain't this "Boxed"? (That's why using the enum is safer...)
>
> src/frontends/controllers/ControlBox.C
> +boo
Lars Gullik Bjønnes wrote:
> | +#include "support/std_ostream.h"
> | WriteStream & operator<<(WriteStream & ws, string const & s)
> | {
>
> What are the errors when std_ostream.h are left out?
> but this change is ok.
I suspect that things like this are very STL-implementation dependent. We
c
On Thu, Oct 02, 2003 at 03:19:49PM +, Angus Leeming spake thusly:
> > Except for a number of smaller patches to the source, see attached.
> > I assume you will want to tinker with this, packing some of them in
> > CXX_GLOBAL_CSTD conditionals etc. Please advise.
>
> The only thing that looks
Martin Vermeer wrote:
> Okay, here is then my latest. Anything left to do with this except
> committing?
Ain't this "Boxed"? (That's why using the enum is safer...)
src/frontends/controllers/ControlBox.C
+bool ControlBox::initialiseParams(string const & data)
+{
+ InsetBoxParams params("box
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> If not your own box: hassle the admins. They are now 2 years on
| Lars> the back burner. If your own machine: upgrade now.
>
| Well, their next target is upgrading to rh8 (is
On Thu, 2 Oct 2003, Angus Leeming wrote:
> I also attach a document discussing the changes to the external template
> language and how the transformations are implemented. The document does
> not discuss how InsetExternal connects data and output transformations
> together, partly because this is
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Thu, Oct 02, 2003 at 04:52:46PM +0200, Lars Gullik Bjønnes spake thusly:
|
>> IMVHO we should begin using exceptions and require 2.95 and 2.96 users
>> to use STLPort. (these must be my new peeves, since we finally got rid
>> of lyxstring).
>
| Alt
On Wed, Oct 01, 2003 at 04:01:26PM +, Angus Leeming spake thusly:
>
> >> You must be sick to the back teeth of my suggestions ;-)
> > Yes. That's why I'll leave a little for you ;-)
>
> Hmpfff!
>
> --
> Angus
Okay, here is then my latest. Anything left to do with this except
committing?
-
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> If not your own box: hassle the admins. They are now 2 years on
Lars> the back burner. If your own machine: upgrade now.
Well, their next target is upgrading to rh8 (is that 9?). And they are
a bit too overworked to be sensitiv
On Thu, Oct 02, 2003 at 04:52:46PM +0200, Lars Gullik Bjønnes wrote:
> Ad. lyxstring -> Andre are you still testing the private inheritance
I had no time so far.
> stuff? If not I'd like to begin using directly.
> (and remove configure and .h file cruft)
So just do that.
Andre'
Martin Vermeer <[EMAIL PROTECTED]> writes:
Ok, these seems simple enough, but why are they needed?
| Index: src/graph.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graph.C,v
| retrieving revision 1.10
| diff -u -p -r1.10 g
Lars Gullik Bjønnes wrote:
> But aren't you using the wrong any_cast here?
> Shouldn't you use boost::any_cast?
I would love to, but that would mean storing a pointer to a
boost::function.
> Hmm... there is something I do not understand here. any_cast with a
> refernece or a value type will thro
On Thu, Oct 02, 2003 at 04:52:46PM +0200, Lars Gullik Bjønnes spake thusly:
> IMVHO we should begin using exceptions and require 2.95 and 2.96 users
> to use STLPort. (these must be my new peeves, since we finally got rid
> of lyxstring).
Alternatively, compile gcc3 from a tarball into a private
On Thu, Oct 02, 2003 at 04:27:57PM +0200, Lars Gullik Bjønnes spake thusly:
> | Getting better still. It builds! And works after building... I opened
> | and moved around in a production file with it.
>
> Can you remind me: what system have you now been able to compile and
> run lyx on?
>
> --
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Thursday 02 October 2003 2:39 pm, Jean-Marc Lasgouttes wrote:
>> Lars> Can you remind me: what system have you now been able to compile
>> Lars> and run lyx on?
>>
>> FWIW I am now unable to compile 1.4.0cvs with gcc 2.96. I anticipate
>> that this ma
On Thursday 02 October 2003 2:39 pm, Jean-Marc Lasgouttes wrote:
> Lars> Can you remind me: what system have you now been able to compile
> Lars> and run lyx on?
>
> FWIW I am now unable to compile 1.4.0cvs with gcc 2.96. I anticipate
> that this machine will be upgraded to gcc 3.2 in a few months,
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Can you remind me: what system have you now been able to compile
| Lars> and run lyx on?
>
| FWIW I am now unable to compile 1.4.0cvs with gcc 2.96. I anticipate
| that this
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Can you remind me: what system have you now been able to compile
Lars> and run lyx on?
FWIW I am now unable to compile 1.4.0cvs with gcc 2.96. I anticipate
that this machine will be upgraded to gcc 3.2 in a few months, though
;
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Oct 01, 2003 at 10:04:33PM +, Angus Leeming spake thusly:
|
>> On Wednesday 01 October 2003 8:40 pm, Martin Vermeer wrote:
>> > On Wed, Oct 01, 2003 at 08:31:44PM +0300, Martin Vermeer spake thusly:
>> > > Hmmm, perhaps /home/mv/STLport-4.
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>
>> Angus Leeming wrote:
>>> Lars Gullik Bjønnes wrote:
note the member function boost::any:type
>>>
>>> Bingo! No need for exceptions after all.
>>> Many thanks, Lars.
>>
>> Next iteration. I think that this is ready to conv
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>
>> Angus Leeming wrote:
>>> Lars Gullik Bjønnes wrote:
note the member function boost::any:type
>>>
>>> Bingo! No need for exceptions after all.
>>> Many thanks, Lars.
>>
>> Next iteration. I think that this is ready to conv
Martin Vermeer wrote:
> Getting better still. It builds! And works after building... I opened
> and moved around in a production file with it.
Well done!!!
> This is needed:
> 2) Then, in the makefiles of src and src/tex2lyx I had to add to
> LDFLAGS:
> -lpthread -lstlport_gcc
> (I didn't find a
Angus Leeming wrote:
> Angus Leeming wrote:
>> Lars Gullik Bjønnes wrote:
>>> note the member function boost::any:type
>>
>> Bingo! No need for exceptions after all.
>> Many thanks, Lars.
>
> Next iteration. I think that this is ready to convert into InsetExternal
> code.
Hmmppfff! trying to do
On Wed, Oct 01, 2003 at 10:04:33PM +, Angus Leeming spake thusly:
> On Wednesday 01 October 2003 8:40 pm, Martin Vermeer wrote:
> > On Wed, Oct 01, 2003 at 08:31:44PM +0300, Martin Vermeer spake thusly:
> > > Hmmm, perhaps /home/mv/STLport-4.5.3/stlport/stl in addition to
> > > /home/mv/STLpo
Lars Gullik Bjønnes wrote:
> | Because the code using it does exactly the same as Inset::clone. Just
> | passes a pointer around safely.
>
> But you are not passing it... isn't it a static class variable?
The factory function is static, but the transformer itself is not. Each
transformer holds a
On Thursday, October 2, 2003, at 10:12 AM, Angus Leeming wrote:
That fixes that problem. But then the linker fails to find all of the
Qt functions and some others:
Can you compile and link the Qt test programs?
What happens if you compile -fnoinline-functions or whatever the
option is?
All of t
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Angus Leeming wrote:
Lars Gullik Bjxnnes wrote:
> note the member function boost::any:type
Bingo! No need for exceptions after all.
Many thanks, Lars.
>>>
>> | Next iteration. I think that this is
On Thursday 02 October 2003 12:47 pm, Ronald Florence wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > Looks like a gcc bug to me.
> >
> > What happens if you explicitly define an out-of-line empty destructor to
> > MathGridInset:
> > math_gridinset.h
> > ~MathGridInset();
> > math_gr
Ronald Florence wrote:
> This fixed that problem, but then the linker fails to find some
> functions, including all of the Qt functions. The exact same
> configuration worked with gcc-2.95.2, and the Qt library is linked
> with the same gcc-3.3 as lyx-1.3.3:
Your toolchain is broken. Tell Apple.
Lars Gullik Bjønnes wrote:
> | Angus Leeming wrote:
>>> Lars Gullik Bjxnnes wrote:
note the member function boost::any:type
>>>
>>> Bingo! No need for exceptions after all.
>>> Many thanks, Lars.
>>
> | Next iteration. I think that this is ready to convert into
> | InsetExternal code. However
Angus Leeming <[EMAIL PROTECTED]> writes:
> > ld: multiple definitions of symbol MathGridInset::~MathGridInset
> > [in-charge deleting]()
>
> Looks like a gcc bug to me.
>
> What happens if you explicitly define an out-of-line empty destructor to
> MathGridInset:
> math_gridinset.h
> ~M
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> Lars Gullik Bjxnnes wrote:
>>> note the member function boost::any:type
>>
>> Bingo! No need for exceptions after all.
>> Many thanks, Lars.
>
| Next iteration. I think that this is ready to convert into InsetExternal
| code. Ho
On Thu, Oct 02, 2003 at 01:56:47PM +0200, Andre Poenitz wrote:
> [Probably my doing. Would it possible to call trackChanges() in a big
> loop after the loading?]
Not without other changes I think, see the code that actually populates
the Changes structure on a buffer read.
john
--
Khendon's Law
Inst InsetText::read:
if (buf.params().tracking_changes)
paragraphs.begin()->trackChanges();
// delete the initial paragraph
paragraphs.clear();
This doesn't make much sense, does it?
[Probably my doing. Would it possible to call trackChanges() in a bi
Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
>> note the member function boost::any:type
>
> Bingo! No need for exceptions after all.
> Many thanks, Lars.
Next iteration. I think that this is ready to convert into InsetExternal
code. However, I think that I'll also use it in the documentati
On Thu, Oct 02, 2003 at 12:29:53PM +, Angus Leeming wrote:
> > 1. There are already enough open issues. For instance, the Qt frontend
> > lacks branch support. Tex2lyx still misses some features. And I guess
> > there are more gaps to flll.
>
> These are mising features, not bugs.
Insert->Br
On Thu, Oct 02, 2003 at 01:28:03PM +0200, Andre Poenitz wrote:
> That's distributed over a few more people. Including you...
I won't be around.
The bugs that consume real time are all difficult and will require
significant knowledge of the core. That means very few people, or some
people with qu
Michael Schmitt wrote:
> 1. There are already enough open issues. For instance, the Qt frontend
> lacks branch support. Tex2lyx still misses some features. And I guess
> there are more gaps to flll.
These are mising features, not bugs.
--
Angus
On Thu, Oct 02, 2003 at 12:19:21PM +0100, John Levon wrote:
> On Thu, Oct 02, 2003 at 11:36:42AM +0200, Andre Poenitz wrote:
>
> > Than there are 153 'normal' bugs. Quite a few of them are
> > reLyX/round-trip related. No biggo. Should be verified against tex2lyx
> > by someone...
> >
> > Ok. Lef
On Thu, Oct 02, 2003 at 11:36:42AM +0200, Andre Poenitz wrote:
> Than there are 153 'normal' bugs. Quite a few of them are
> reLyX/round-trip related. No biggo. Should be verified against tex2lyx
> by someone...
>
> Ok. Left with say ~4 people and ~12 weeks until Chrismas, this makes
> three bugs
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Attached is a simple sample showing how I could use boost::any to
> | implement the transformation stuff in InsetExternal.
>
> I do not agree with how you use operatesOn.
Thanks for the feedback. I'm feeling my way her
Andre Poenitz wrote:
The idea is ok, but I'd not be too strict about it. There are a few
people which probably can't help much with the real problems, and I
don't think we need to stop them working on non-intrusive improvements.
Well, I disagree for three reasons:
1. There are already enough op
Lars Gullik Bjønnes wrote:
> note the member function boost::any:type
Bingo! No need for exceptions after all.
Many thanks, Lars.
--
Angus
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 02, 2003 at 12:48:16PM +0200, Lars Gullik Bjønnes wrote:
>> If we all agree that we want to use exceptions, I am all for it.
>> But that is up to the rest of you.
>
| What's the drawback?
To use excepitions well is not easy, and it has to be
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a simple sample showing how I could use boost::any to implement
| the transformation stuff in InsetExternal.
>
| I think it results in very elegant code, but the killer is the try,catch
| block. The block is needed, so I guess that this mea
On Thu, Oct 02, 2003 at 12:48:16PM +0200, Lars Gullik Bjønnes wrote:
> If we all agree that we want to use exceptions, I am all for it.
> But that is up to the rest of you.
What's the drawback?
I.e. which of the currently supported compilers don't 'do' exceptions?
[I am fine with them btw.]
And
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a simple sample showing how I could use boost::any to implement
| the transformation stuff in InsetExternal.
I do not agree with how you use operatesOn.
| template
| TransformCommand::ptr_type
| getTransformer(Data const
On Thu, Oct 02, 2003 at 12:16:18PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Oct 02, 2003 at 11:29:08AM +0200, Lars Gullik Bjønnes wrote:
> >> Angus Leeming <[EMAIL PROTECTED]> writes:
> >>
> >> | The trouble as I see it is that the real problems
Attached is a simple sample showing how I could use boost::any to implement
the transformation stuff in InsetExternal.
I think it results in very elegant code, but the killer is the try,catch
block. The block is needed, so I guess that this means I cannot use the
appropach within lyx?
Shame...
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 02, 2003 at 11:29:08AM +0200, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | The trouble as I see it is that the real problems in the 1.4.x tree stem
>> | from the kernel being in a state of transition from
On Thu, Oct 02, 2003 at 11:29:08AM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | The trouble as I see it is that the real problems in the 1.4.x tree stem
> | from the kernel being in a state of transition from old design to new. My
> | reading of discussions
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> - We should stop implementing new stuff and start fixing and completing
>>the existing features (after Martin has committed his box inset, of
>>course)
>
| The idea is ok, but I'd not be too strict about it. There are a few
| people which prob
On Thu, Oct 02, 2003 at 10:39:09AM +0200, Michael Schmitt wrote:
> - We need some reward for people fixing bugs and polishing LyX 1.4.0
>(I was thinking about sending a small present each week to the person
>that has fixed the most bugs. Any proposals for such a present are
>welcome.)
Angus Leeming <[EMAIL PROTECTED]> writes:
| The trouble as I see it is that the real problems in the 1.4.x tree stem
| from the kernel being in a state of transition from old design to new. My
| reading of discussions from those who know is that fixing some (major)
| bugs _requires_ this transi
Lars Gullik Bjønnes wrote:
> Michael Schmitt <[EMAIL PROTECTED]> writes:
>
> | - WE NEED A REAL BOSS THAT TELLS US WHAT TO DO - AND WHEN!
> | (LARS, PLEASE SPEAK TO US)
>
> That has never helped in the past. I can not force people to work.
> And every time I try to force something (remembe
Michael Schmitt <[EMAIL PROTECTED]> writes:
| - WE NEED A REAL BOSS THAT TELLS US WHAT TO DO - AND WHEN!
| (LARS, PLEASE SPEAK TO US)
That has never helped in the past. I can not force people to work.
And every time I try to force something (remember the 1.3.xpre freeze
flame wars), I just
Hi,
it is not friday yet but tomorrow is public holiday in Germany and so I
have to start the flame war today:
Let's face the facts:
- LyX 1.4.X offers many new features
- Many user (including myself) would like to use them
- The kernel code has been improved significantly
but
- there are
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> test $num -ne 0 && which makepsres > /dev/null && { ... (cd
> Angus> xfonts ; rm -f PSres.upr ; makepsres -q) || true
> Angus> }
>
> Angus> Finally, what's with the '|| true'?
>
> The idea was to
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> test $num -ne 0 && which makepsres > /dev/null && { ... (cd
Angus> xfonts ; rm -f PSres.upr ; makepsres -q) || true
Angus> }
Angus> Finally, what's with the '|| true'?
The idea was to avoid an error if the program makepsres did no
On Wed, Oct 01, 2003 at 09:42:36PM -0400, Nirmal Govind wrote:
> but it's great to see it already implemented..
Yeah... the radiation in the Ore Mountains we visited has a positive
impact on clairvoyance.
Andre'
Ronald Florence wrote:
> Apple has a new developer toolkit with gcc-3.3 that seems to be able to
> compile lyx-1.3.x. No problems in the compile on MacOS-10.2.8, but I
> get the following link warnings and errors:
>
> ld: warning table of contents of library: mathed/.libs/libmathed.a not
> sorte
72 matches
Mail list logo
