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
sorted
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'
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 not exist.
But it
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 avoid an error if the
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
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
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 (remember the
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
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.)
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 probably
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 from
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 old design
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?
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 in the 1.4.x
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.
| templatetypename Factory, typename Data
| TransformCommand::ptr_type
|
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.]
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 means
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
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 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
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 here.
Of
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 to
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. Left with say
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 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
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-Branch
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 documentation.
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
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:
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. However, I
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
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, I think that I'll
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.
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_gridinset.C
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 ready to convert into
|
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
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 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
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 so, I get
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 way to
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 convert into InsetExternal
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 convert into InsetExternal
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
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
;)
It
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 machine will be
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,
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 machine will be
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?
--
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
Lars Gullik Bjønnes wrote:
But aren't you using the wrong any_cast here?
Shouldn't you use boost::any_castFactory*?
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
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
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 string directly.
(and remove configure and .h file cruft)
So just do that.
Andre'
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 sensitive to
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?
- Martin
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).
|
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 the
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 that 9?). And
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);
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
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
certainly use
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
+bool
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 behind
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/Dialogs.C:
there
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:
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)
+{
+ InsetBoxParams
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
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?
To the big
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
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
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
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
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,
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
>
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'
> "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
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
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
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
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
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
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.)
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
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
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
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?
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
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
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.]
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
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
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 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
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
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
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.
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 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
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.
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
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
1 - 100 of 144 matches
Mail list logo
