Martin Vermeer wrote:
> On Thu, 2004-10-07 at 18:55, Angus Leeming wrote:
>> [EMAIL PROTECTED] wrote:
>> > Log message:
>> > Implement use of babel language in xindy.
>>
>> Incidentally, it would make sense to document use
>> of the $$lang parameter in lyxrc::getDescription
>> which is displayed
On Thu, 2004-10-07 at 18:55, Angus Leeming wrote:
> [EMAIL PROTECTED] wrote:
> > Log message:
> > Implement use of babel language in xindy.
>
> Incidentally, it would make sense to document use of the $$lang parameter
> in lyxrc::getDescription which is displayed in the xforms preferences
> dialog
[EMAIL PROTECTED] wrote:
> Log message:
> Implement use of babel language in xindy.
Incidentally, it would make sense to document use of the $$lang parameter
in lyxrc::getDescription which is displayed in the xforms preferences
dialog when your mouse goes over the 'index command' input widget...
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> So how can I solve the original compile problem of Edwin on
Alfredo> gcc 3.2? I'm totally lost here. Moreover, is there a way to
Alfredo> make g++ 2.95 to behave as strict as g++ 3.x?
Try to add ``#include '' as first thin
Alfredo Braunstein wrote:
> and we do need LString.h in format.h.
>
> Ok, it's between #if 0 #endif but...
>
> So how can I solve the original compile problem of Edwin on gcc 3.2? I'm
> totally lost here. Moreover, is there a way to make g++ 2.95 to behave as
> strict as g++ 3.x?
Of course, I'v
-BEGIN PGP SIGNED MESSAGE-
On Freitag, 28. Februar 2003 16:26, Edwin Leuven wrote:
> ../../lyx-devel/src/format.C:28: `cout' not declared
missing #include
> ../../lyx-devel/src/format.C:30: `io' not declared
Remove this line
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEG
Jean-Marc Lasgouttes wrote:
> Alfredo, please don't do this. should be included as the
> first header in all .C file, but never in .h files.
>
> JMarc
Finally, some words of wisdom. I though that this was the solution because
of LString.h:
#if 0
#ifndef _CONFIG_H
#error The header should alwa
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Kornel Benko wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> On Freitag, 28. Februar 2003 14:35, Alfredo Braunstein wrote:
>>> Try adding #include to the top of format.h.
>> Next error:
>>
Alfredo> How about this? I
still get
cc1plus: warning: changing search order for system directory "/usr/include"
cc1plus: warning: as it has already been specified as a non-system directory
and
../../lyx-devel/src/format.C:28: `cout' not declared
../../lyx-devel/src/format.C:30: `io' not declared
../../lyx-devel/src/f
Kornel Benko wrote:
> Still some there, but next directory ...
>
Of course, forgot about xforms. (should work with qt, though). I'll need
another age to compile. Sigh.
Alfredo
-BEGIN PGP SIGNED MESSAGE-
On Freitag, 28. Februar 2003 15:31, Alfredo Braunstein wrote:
> How about this? I hope I'v catched them all...
>
> Alfredo
>
> patch.diff
Still some there, but next directory ...
source='xformsImage.C' object='xformsImage.lo' libtool=yes \
depfile='.deps/xforms
Kornel Benko wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> On Freitag, 28. Februar 2003 14:35, Alfredo Braunstein wrote:
>> Try adding #include to the top of format.h.
>
> Next error:
>
How about this? I hope I'v catched them all...
Alfr
Kornel Benko wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> On Freitag, 28. Februar 2003 14:35, Alfredo Braunstein wrote:
>> Try adding #include to the top of format.h.
>
> Next error:
>
> g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/include
> -I/usr/X11R6/include -ftemplate-depth-50 -
-BEGIN PGP SIGNED MESSAGE-
On Freitag, 28. Februar 2003 14:35, Alfredo Braunstein wrote:
> Try adding #include to the top of format.h.
Next error:
g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/include -I/usr/X11R6/include
-ftemplate-depth-50 -fno-exceptions -W -Wall -Winline -c -
Try adding #include to the top of format.h.
Alfredo
Edwin Leuven wrote:
> compile fails for me:
>
> g++ -DHAVE_CONFIG_H -I. -I../../lyx-devel/src -I. -I../../lyx-devel/boost
> -I/usr/include -I/usr/X11R6/include -g -O -fno-exceptions -W -Wall
> -Winline -c -o graph.o `test -f '../../lyx-devel/src/graph.C' || echo
> '../../lyx-devel/src/'`../../l
compile fails for me:
g++ -DHAVE_CONFIG_H -I. -I../../lyx-devel/src -I. -I../../lyx-devel/boost
-I/usr/include -I/usr/X11R6/include -g -O -fno-exceptions -W -Wall -Winline
-c -o graph.o `test -f '../../lyx-devel/src/graph.C' || echo
'../../lyx-devel/src/'`../../lyx-devel/src/graph.C
cc1plus:
On Fri, Feb 28, 2003 at 09:45:15AM +0100, Alfredo Braunstein wrote:
> Sorry for the delay, the patch didn't applied cleanly anymore and had to
> backup some new changes to recreate it.
Applied.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they d
\
+ graph.h \
+ format.C \
+ format.h
lyx_main.o: lyx_main.C lyx_main.h config.h version.h \
lyxrc.h support/path.h support/filetools.h \
Index: MenuBackend.C
===
RCS
On Fri, Feb 28, 2003 at 08:40:09AM +0100, Alfredo Braunstein wrote:
> Do I have to wait until tuesday or there is another caritative soul that can
> apply it?
Send me the patch again.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, ei
Alfredo Braunstein wrote:
> Attached is the result.
>
> Thanks,
> Alfredo
Do I have to wait until tuesday or there is another caritative soul that can
apply it?
Thanks, Alfredo
Alfredo Braunstein wrote:
> Actually, this will force #including "format.h" in outside code which use
> the formats object, because the extern declaration of the global object
> formats is in it.
> I would leave this one as is for now, if it's ok with you. (I promess to
> do it soon)
>
I have al
ument processor.
* Licence details can be found in the file COPYING.
*
* \author Dekel Tsur
*
* Full author contact details are available in file CREDITS
*/
#include "format.h"
#include "LString.h"
#include
#include
class Graph {
public:
Graph() : numedges_(0) {};
///
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
> Why is the Converter c-tor inline? Do you need to #include "format.h" in
> converter.h? Can you not forward declare class Format?
>
> I would take papersize out of class Format, but still have its
> definition/declaration in format.[Ch].
>
>
Alfredo Braunstein wrote:
Why is the Converter c-tor inline? Do you need to #include "format.h" in
converter.h? Can you not forward declare class Format?
I would take papersize out of class Format, but still have its
definition/declaration in format.[Ch].
Looks good. Would you like it applied
The corrected version.
I've added converter.[Ch] here so you can look at it without applying the
patch, but they are already contained on patch.diff.
Alfredo
/**
* \file converter.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file CO
Angus Leeming wrote:
> //does this belong here??
> string const Formats::papersize(Buffer const * buffer) const
>
> It doesn't 'feel' right does it. Why not make it a stand-alone function?
It is accessed also from converter.C (it was before a member of Converters,
do
Andre Poenitz wrote:
> On Thu, Feb 27, 2003 at 11:35:16AM +0100, Alfredo Braunstein wrote:
>> > Why is it inline? Have you profiled this code? Take it out of line.
>>
>> Not my doing, but I will.
>
> You do not have to profile this part.
>
> Angus just meant "Unless you have verified that there
On Thu, Feb 27, 2003 at 11:35:16AM +0100, Alfredo Braunstein wrote:
> > Why is it inline? Have you profiled this code? Take it out of line.
>
> Not my doing, but I will.
You do not have to profile this part.
Angus just meant "Unless you have verified that there is a bottleneck
by profiling the c
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> So here it is. Please comment.
> Loks good. Here's some comments ;-)
> Angus
>
>
> * Copyright 2002 the LyX Team
>
> There is no such formal entity. Please use
Ok, I though I had to leave it because it was there on the original file.
> /
Alfredo Braunstein wrote:
> So here it is. Please comment.
Loks good. Here's some comments ;-)
Angus
* Copyright 2002 the LyX Team
There is no such formal entity. Please use
/**
* \file format.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file
es_++);
}
vector Graph::vertices_;
// -*- C++ -*-
/**
* \file graph.h
* Copyright 1995 Matthias Ettrich
* Copyright 2002 the LyX Team
* Read the file COPYING
*
* \author Dekel Tsur
*/
#ifndef CONVERSIONGRAPH_H
#define CONVERSIONGRAPH_H
#include "format.h"
#include
#in
Alfredo Braunstein wrote:
> I finally managed to work on converter.C.
>
> I've done the first split (converter.[Ch] -> converter.[Ch] + format.[Ch]
> +graph.[Ch]), with no change in interface nor in functionality.
>
> The graph work is done in the class Graph, who know
I finally managed to work on converter.C.
I've done the first split (converter.[Ch] -> converter.[Ch] + format.[Ch]
+graph.[Ch]), with no change in interface nor in functionality.
The graph work is done in the class Graph, who knows _almost_ nothing about
converters nor formats (w
>>>>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Also to me. I didn't understood what you were asking me, but
Alfredo> now I think I do. Alfredo
OK, to be clearer, I suspect that lines ~612-713 of converter.C should
be in the Converter class. But I may be wrong.
JMarc
Jean-Marc Lasgouttes wrote:
>>> Good idea. Also, while you are at it, I think that the central part
>>> of Converters::convert should be moved to a new Converter::convert
>>> (without the 's'). Doing such things would help make the code more
>>> understandable.
>>>
>>> JMarc
>
> Alfredo> Should
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Jean-Marc Lasgouttes wrote:
>> Good idea. Also, while you are at it, I think that the central part
>> of Converters::convert should be moved to a new Converter::convert
>> (without the 's'). Doing such things would help mak
Jean-Marc Lasgouttes wrote:
> Good idea. Also, while you are at it, I think that the central part of
> Converters::convert should be moved to a new Converter::convert
> (without the 's'). Doing such things would help make the code more
> understandable.
>
> JMarc
Should I rename
On Wed, Feb 26, 2003 at 11:28:17AM +0100, Alfredo Braunstein wrote:
> Is it ok to split it into 3 files?
I think so.
> What would be a good namig for them?
>
> file 1: Format+Formats
> file 2: Converter+Converters
> file 3: graph for Converters
format.[Ch], converter.[Ch], graph.[Ch]
[_I_ am
tually, what would be a good naming/file distribution?
In converter.C we have four classes:
class Format (a format item)
class Formats (the set of formats)
class Converter (a converter item)
class Converters (the set of converters)
I'm adding one more, the converter graph (if done properly,
>>>>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> If there are no a priori objections, I'd like to work a
Alfredo> little on converter.C to:
Alfredo> * clean a little the interface. Right there is ugly code like
Alfredo>
On Wed, Feb 26, 2003 at 09:45:06AM +0100, Alfredo Braunstein wrote:
> If you think it's ok, I would try to make the separation first without
> changing the existing code.
That's fine of course.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they d
On Wed, Feb 26, 2003 at 09:45:06AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > I think I have some code flying around that implement shortest path
> > searches. Interested?
>
> Absolutely, but:
>
> If you think it's ok, I would try to make the separation first without
> changin
Andre Poenitz wrote:
> I think I have some code flying around that implement shortest path
> searches. Interested?
Absolutely, but:
If you think it's ok, I would try to make the separation first without
changing the existing code. Once I have this working, we can think of
changing the graph code
On Wed, Feb 26, 2003 at 09:23:25AM +0100, Alfredo Braunstein wrote:
> * clean a little the implementation, separating the 'graph' part from the
> conversion part.
>
> * add weights (slowness and accurateness) to converters and find the least
> weighted path instead of the shortest, as suggested by
If there are no a priori objections, I'd like to work a little on
converter.C to:
* clean a little the interface. Right there is ugly code like this in
importer.C:
vector result =
converters.getReachableTo(loaders[0], true);
for (vector::const_iterat
Dekel,
Concerning the changes you did in Converter::setViewer() to quote
$$FName. I do not think these changes were needed. The best is
probably to use QuoteName() on the file name later, as in:
string command2 = subst(command, "$$FName",
QuoteName(OnlyF
47 matches
Mail list logo
