Re: LaTeX in-table computations.
On Sun, Nov 11, 2007 at 01:16:46AM +0100, Tommaso Cucinotta wrote:
> Hi all,
>
> I wish it were possible to make simple computations within
> table cells, like summing up all the rows or columns and computing
> totals. I found the \FP LaTeX package that allows to perform
> computations. Do you know if it is possible, in LaTeX, to generically
> refer to the contents of other cells in a table through some appropriate
> macro where you provide cell coordinates ?
>
> Thankx, bye,
>
> T.
I actually had a working implementation of simple spreadsheet
functionality in LyX tables (but on the LyX level, not LaTeX
level), where the tabular dialogue presented the current row
and column sums. It wasn't considered acceptable though ("if
you want to use a spreadsheet, use a real one").
I disagreed and disagree with this. Good luck.
- Martin
Re: Scrollfix patch
On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote: > Hi all, > > please, find attached an improved version of the scrollfix patch. > > Summary of the further changes: > -) most optimizations for updating a single par are back > -) actually, it is possible to specify a par range with Update::SinglePar >-- actually, should be renamed as Update::Paragraphs; >-- actually, Update::Force should be renamed as Update::Screen ? > -) class UpdateScope encapsulates the scope of an update (updateFlags >plus parameters, e.g. the par range to be updated if SinglePar is used) > -) the boxes example now works correctly, except it is somewhat slow >because with SinglePar I'm updating and redrawing the outer Par, >not the inner one, so with such a great box (or even table, etc...), >it gets slow -- here I should add a further parameter to UpdateScope >specifying the Text where the update starts from; > -) probably it adheres slightly more to the coding rules; > -) updated to trunk revision 21533; > -) needs testing to check if there are any further crashes; > > As it is somewhat growing, I wouldn't like to keep working on it for too > much time further, as the operation of merging with trunk may become > cumbersome. Now it seems to me sufficiently stable. > > T. I think this is the time to check it in -- with the trivial renames you propose. We're not close to a trunk release so any bugs will get ironed out in a timely manner. - Martin
Re: LaTeX in-table computations.
Darren Freeman ha scritto: just in the generated output, you would be suggesting a basic embedded spreadsheet within LyX.. Exactly. I was of course thinking of a way to latexify the connections among numbers, rather than simply calculating them in LyX. So that, after export LaTeX -> reimport, the spreadsheet would still work. And, needless to say, I felt so stupid when, while writing my last paper, I was so afraid of having not only to update a few numbers within a couple of tables, but also to update some totals around (both in the table, and in the text). I confess I missed the spreadsheet embedding feature of other editors. given the state of tables in LyX, I'm just happy that they seem to work a lot of the time :) Try to add a column to the end of a table and see the double cell border. Or delete the last column and get no border. Hilarious. Yeah, I use to fix those borders manually (it is displayed double because it is both e.g. at the bottom of a cell and at the top of the cell immediately below -- guess you know). Don't even know if it reflected in the preview(s). T.
Re: LaTeX in-table computations.
On Sun, 2007-11-11 at 01:16 +0100, Tommaso Cucinotta wrote: > I wish it were possible to make simple computations within > table cells, like summing up all the rows or columns and computing If you wanted to see the results of the computation in LyX, rather than just in the generated output, you would be suggesting a basic embedded spreadsheet within LyX.. given the state of tables in LyX, I'm just happy that they seem to work a lot of the time :) Try to add a column to the end of a table and see the double cell border. Or delete the last column and get no border. Hilarious. Have fun, Darren
LaTeX in-table computations.
Hi all, I wish it were possible to make simple computations within table cells, like summing up all the rows or columns and computing totals. I found the \FP LaTeX package that allows to perform computations. Do you know if it is possible, in LaTeX, to generically refer to the contents of other cells in a table through some appropriate macro where you provide cell coordinates ? Thankx, bye, T.
Re: trunk compile problem
> > yes, that works.
>
> Whoahey.
>
> Now you could do me a favour: Could you run that file through the preprocessor
> only (i.e. g++ -E instead of g++ -c) and figure out who pulls in X.h (or
> Xlib.h)?
are you talking about all occurences of X/lib/.h ?
i'm bit confused what all the numbers mean, eg # 1 "/usr/include/X11/Xatom.h" 1
3 4
> > now remains
> > ../../../src/DispatchResult.h: In constructor
> > 'lyx::DispatchResult::DispatchResult()':
> > ../../../src/DispatchResult.h:24: error: expected unqualified-id before
> > numeric constant
>
> Probably something similar. Try
>
> #undef None
yes, you are right.
/me -> bed now; good night :)
pavel
http://195.113.31.123/~sanda/junk/dump.c
$ g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
-DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends
-I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I../../../boost -Wextra -Wall -O -MT liblyxqt4.lo -MD
-MP -MF .deps/liblyxqt4.Tpo -c liblyxqt4.cpp -E | grep -A5 -B15 -E
'/X.h|Xlib'
# 48 "GuiApplication.cpp" 2
# 1 "/usr/include/qt4/QtCore/QSocketNotifier" 1
# 49 "GuiApplication.cpp" 2
# 1 "/usr/include/qt4/QtCore/QTextCodec" 1
# 50 "GuiApplication.cpp" 2
# 1 "/usr/include/qt4/QtCore/QTimer" 1
# 51 "GuiApplication.cpp" 2
# 1 "/usr/include/qt4/QtCore/QTranslator" 1
# 52 "GuiApplication.cpp" 2
# 1 "/usr/include/qt4/QtGui/QWidget" 1
# 53 "GuiApplication.cpp" 2
# 1 "/usr/include/X11/Xatom.h" 1 3 4
# 56 "GuiApplication.cpp" 2
# 1 "/usr/include/X11/Xlib.h" 1 3 4
# 60 "/usr/include/X11/Xlib.h" 3 4
# 1 "/usr/include/X11/X.h" 1 3 4
# 71 "/usr/include/X11/X.h" 3 4
typedef unsigned long XID;
typedef unsigned long Mask;
typedef unsigned long Atom;
typedef unsigned long VisualID;
typedef unsigned long Time;
# 101 "/usr/include/X11/X.h" 3 4
typedef XID Window;
typedef XID Drawable;
typedef XID Font;
typedef XID Pixmap;
typedef XID Cursor;
typedef XID Colormap;
typedef XID GContext;
typedef XID KeySym;
typedef unsigned char KeyCode;
# 61 "/usr/include/X11/Xlib.h" 2 3 4
# 1 "/usr/include/X11/Xfuncproto.h" 1 3 4
# 64 "/usr/include/X11/Xlib.h" 2 3 4
# 1 "/usr/include/X11/Xosdefs.h" 1 3 4
# 65 "/usr/include/X11/Xlib.h" 2 3 4
# 75 "/usr/include/X11/Xlib.h" 3 4
# 1 "/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/stddef.h" 1 3 4
# 76 "/usr/include/X11/Xlib.h" 2 3 4
# 93 "/usr/include/X11/Xlib.h" 3 4
extern int
_Xmblen(
char *str,
int len
);
typedef char *XPointer;
# 180 "/usr/include/X11/Xlib.h" 3 4
typedef struct _XExtData {
int number;
struct _XExtData *next;
int (*free_private)(
struct _XExtData *extension
--
} XKeyboardState;
typedef struct {
Time time;
short x, y;
} XTimeCoord;
typedef struct {
int max_keypermod;
KeyCode *modifiermap;
} XModifierKeymap;
# 519 "/usr/include/X11/Xlib.h" 3 4
typedef struct _XDisplay Display;
struct _XPrivate;
struct _XrmHashBucketRec;
--
typedef struct _XOC *XOC, *XFontSet;
typedef struct {
char *chars;
int nchars;
int delta;
XFontSet font_set;
} XmbTextItem;
typedef struct {
wchar_t *chars;
int nchars;
int delta;
XFontSet font_set;
} XwcTextItem;
# 1124 "/usr/include/X11/Xlib.h" 3 4
typedef struct {
int charset_count;
char **charset_list;
} XOMCharSetList;
--
XPointer
);
typedef void (*XIDProc)(
Display*,
XPointer,
XPointer
);
typedef unsigned long XIMStyle;
typedef struct {
unsigned short count_styles;
XIMStyle *supported_styles;
} XIMStyles;
# 1236 "/usr/include/X11/Xlib.h" 3 4
typedef void *XVaNestedList;
typedef struct {
XPointer client_data;
XIMProc callback;
} XIMCallback;
typedef struct {
XPointer client_data;
XICProc callback;
} XICCallback;
typedef unsigned long XIMFeedback;
# 1260 "/usr/include/X11/Xlib.h" 3 4
typedef struct _XIMText {
unsigned short length;
XIMFeedback *feedback;
int encoding_is_wchar;
union {
--
typedef struct _XIMPreeditStateNotifyCallbackStruct {
XIMPreeditState state;
} XIMPreeditStateNotifyCallbackStruct;
typedef unsigned long XIMResetState;
typedef unsigned long XIMStringConversionFeedback;
# 1294 "/usr/include/X11/Xlib.h" 3 4
typedef struct _XIMStringConversionText {
unsigned short length;
XIMStringConversionFeedback *feedback;
int encoding_is_wchar;
union {
Re: trunk compile problem
On Sat, Nov 10, 2007 at 11:16:15PM +0100, Pavel Sanda wrote: > > Hm... shot into the dark: > > > > What happens if you add > > > > #undef CursorShape > > yes, that works. Whoahey. Now you could do me a favour: Could you run that file through the preprocessor only (i.e. g++ -E instead of g++ -c) and figure out who pulls in X.h (or Xlib.h)? > now remains > ../../../src/DispatchResult.h: In constructor > 'lyx::DispatchResult::DispatchResult()': > ../../../src/DispatchResult.h:24: error: expected unqualified-id before > numeric constant Probably something similar. Try #undef None Andre'
Re: trunk compile problem
> Hm... shot into the dark: > > What happens if you add > > #undef CursorShape yes, that works. > around line 14 in GuiDocument.h (i.e. before the #include "ui_*.h" lines) now remains ../../../src/DispatchResult.h: In constructor 'lyx::DispatchResult::DispatchResult()': ../../../src/DispatchResult.h:24: error: expected unqualified-id before numeric constant pavel
Re: trunk compile problem
On Sat, Nov 10, 2007 at 10:43:47PM +0100, Pavel Sanda wrote:
> > If you're seeing that problem, your trunk must be out of date:
> >
> > [EMAIL PROTECTED] src]$ srcgrep lfun_name_
>
> sorry, i didnt recognized that the error message is slightly different.
>
> make[6]: Entering directory `/home/installer/lyx/trunkaa/src/frontends/qt4'
> /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
> -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL
> -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images
> -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore
> -I/usr/include/qt4/QtGui -I../../../boost -Wextra -Wall -g -O -MT
> liblyxqt4.lo -MD -MP -MF .deps/liblyxqt4.Tpo -c -o liblyxqt4.lo liblyxqt4.cpp
> g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
> -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends
> -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore
> -I/usr/include/qt4/QtGui -I../../../boost -Wextra -Wall -g -O -MT
> liblyxqt4.lo -MD -MP -MF .deps/liblyxqt4.Tpo -c liblyxqt4.cpp -o liblyxqt4.o
> ui_TextLayoutUi.h: In member function 'void
> Ui_TextLayoutUi::setupUi(QWidget*)':
> ui_TextLayoutUi.h:152: error: expected primary-expression before '(' token
> ui_TextLayoutUi.h:152: error: expected type-specifier
> ui_TextLayoutUi.h:152: error: expected `>'
> ui_TextLayoutUi.h:152: error: expected `('
> ui_TextLayoutUi.h:152: error: expected unqualified-id before numeric constant
> ui_TextLayoutUi.h:152: error: expected `)' before numeric constant
Hm... shot into the dark:
What happens if you add
#undef CursorShape
around line 14 in GuiDocument.h (i.e. before the #include "ui_*.h" lines)
Andre'
Re: trunk compile problem
> If you're seeing that problem, your trunk must be out of date:
>
> [EMAIL PROTECTED] src]$ srcgrep lfun_name_
sorry, i didnt recognized that the error message is slightly different.
make[6]: Entering directory `/home/installer/lyx/trunkaa/src/frontends/qt4'
/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL
-DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images
-DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I../../../boost -Wextra -Wall -g -O -MT
liblyxqt4.lo -MD -MP -MF .deps/liblyxqt4.Tpo -c -o liblyxqt4.lo liblyxqt4.cpp
g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
-DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends
-I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I../../../boost -Wextra -Wall -g -O -MT liblyxqt4.lo
-MD -MP -MF .deps/liblyxqt4.Tpo -c liblyxqt4.cpp -o liblyxqt4.o
ui_TextLayoutUi.h: In member function 'void Ui_TextLayoutUi::setupUi(QWidget*)':
ui_TextLayoutUi.h:152: error: expected primary-expression before '(' token
ui_TextLayoutUi.h:152: error: expected type-specifier
ui_TextLayoutUi.h:152: error: expected `>'
ui_TextLayoutUi.h:152: error: expected `('
ui_TextLayoutUi.h:152: error: expected unqualified-id before numeric constant
ui_TextLayoutUi.h:152: error: expected `)' before numeric constant
../../../src/DispatchResult.h: In constructor
'lyx::DispatchResult::DispatchResult()':
../../../src/DispatchResult.h:24: error: expected unqualified-id before numeric
constant
GuiKeySymbol.cpp: At global scope:
GuiKeySymbol.cpp:44: warning: 'char lyx::encode(const std::string&, const
QString&)' defined but not used
make[6]: *** [liblyxqt4.lo] Error 1
pavel
Re: trunk compile failiure
Andre Poenitz schrieb: I think #undef min #undef max after #include is still prefered. OK, I commited this version. regards Uwe
Re: trunk compile failiure
Uwe Stöhr wrote: Andre Poenitz schrieb: Windows? Try #undef max after the last #include in that file. This doesn't help, but I found now the problem: You added in r21492 this code to FileName.cpp: #if defined (BOOST_WINDOWS) # define WIN32_LEAN_AND_MEAN # include #endif But this redefines the max command: The Standard Library defines the two template functions std::min() and std::max() in the header. In general, you should use these template functions for calculating the min and max values of a pair. Unfortunately, Visual C++ does not define these function templates. This is because the names min and max clash with the traditional min and max macros defined in . As a workaround, Visual C++ defines two alternative templates with identical functionality called _cpp_min() and _cpp_max(). You can use them instead of std::min() and std::max().To disable the generation of the min and max macros in Visual C++, #define NOMINMAX before #including . (from http://www.devx.com/tips/Tip/14540) When I change it to: #if defined (BOOST_WINDOWS) # define WIN32_LEAN_AND_MEAN # define NOMINMAX # include #endif I can compile it. OK to commit this? No, scons should be corrected to pass -DNOMINMAX instead. I think Scons already does that for src/ so it should be easy to do the same for src/support/. Abdel.
Re: trunk compile failiure
On Sat, Nov 10, 2007 at 08:53:29PM +0100, Uwe Stöhr wrote: > Andre Poenitz schrieb: > >> Windows? >> Try #undef max after the last #include in that file. > > This doesn't help, but I found now the problem: > > You added in r21492 this code to FileName.cpp: > > #if defined (BOOST_WINDOWS) > # define WIN32_LEAN_AND_MEAN > # include > #endif This was moved in from somewhere else. > But this redefines the max command: > > The Standard Library defines the two template functions std::min() and > std::max() in the header. In general, you should use these > template functions for calculating the min and max values of a pair. > Unfortunately, Visual C++ does not define these function templates. This is > because the names min and max clash with the traditional min and max macros > defined in . As a workaround, Visual C++ defines two alternative > templates with identical functionality called _cpp_min() and _cpp_max(). > You can use them instead of std::min() and std::max().To disable the > generation of the min and max macros in Visual C++, #define NOMINMAX before > #including . > (from http://www.devx.com/tips/Tip/14540) > When I change it to: > > #if defined (BOOST_WINDOWS) > # define WIN32_LEAN_AND_MEAN > # define NOMINMAX > # include > #endif > > I can compile it. OK to commit this? I think #undef min #undef max after #include is still prefered. Andre'
Re: Branches feature addition
Andre Poenitz wrote: On Sat, Nov 10, 2007 at 03:18:06PM +0200, Martin Vermeer wrote: How hard would that be to fix? Very hard. That's why we don't have real text-in-math since 1.3 when it became possible in theory. It will be easier when we have a structured file format (i.e. XML), but somehow XML seemingly got stuck... Andre' But didn't we have some parts of it working? What happened to that? Why would we not just commit what we have? Tabular is already XML based and I hear no complaints about that. We'd probably need to merge Lars' branch into trunk and 'make it stable'. Big work in branches simply does not work, at least not for LyX. However, I don't know whether this would be a good idea right now. Having a quick 1.6 out of the door and doing XML later might make more sense. A LOT more sense! Merging the XML branch is simply too late, I vote against. Abdel.
Re: trunk compile failiure
Andre Poenitz schrieb: Windows? Try #undef max after the last #include in that file. This doesn't help, but I found now the problem: You added in r21492 this code to FileName.cpp: #if defined (BOOST_WINDOWS) # define WIN32_LEAN_AND_MEAN # include #endif But this redefines the max command: The Standard Library defines the two template functions std::min() and std::max() in the header. In general, you should use these template functions for calculating the min and max values of a pair. Unfortunately, Visual C++ does not define these function templates. This is because the names min and max clash with the traditional min and max macros defined in . As a workaround, Visual C++ defines two alternative templates with identical functionality called _cpp_min() and _cpp_max(). You can use them instead of std::min() and std::max().To disable the generation of the min and max macros in Visual C++, #define NOMINMAX before #including . (from http://www.devx.com/tips/Tip/14540) When I change it to: #if defined (BOOST_WINDOWS) # define WIN32_LEAN_AND_MEAN # define NOMINMAX # include #endif I can compile it. OK to commit this? thanks and regards Uwe
Re: update links on wiki
On Sat, Nov 10, 2007 at 04:51:14PM +0100, Jürgen Spitzmüller wrote: > [EMAIL PROTECTED] wrote: > > At least it is lame by design :-) > > Which means the design is lame. Wasn't the intention to have a weak 'protection' only to save us from spam bots? Andre'
Re: CVS/SVN logs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Michael Gerz wrote: >> Pavel's commits do not appear in the cvs log mailing list. > > He's not subscribed yet (only Lars can accept the subscription). Moreover, Pavel, you should try to subscribe your new [EMAIL PROTECTED] address not the other one. JMarc
Re: Branches feature addition
On Sat, Nov 10, 2007 at 03:18:06PM +0200, Martin Vermeer wrote: > > > How hard would that be to fix? > > > > Very hard. That's why we don't have real text-in-math since 1.3 when it > > became possible in theory. It will be easier when we have a structured > > file format (i.e. XML), but somehow XML seemingly got stuck... > > > > Andre' > > But didn't we have some parts of it working? What happened to > that? Why would we not just commit what we have? Tabular is > already XML based and I hear no complaints about that. We'd probably need to merge Lars' branch into trunk and 'make it stable'. Big work in branches simply does not work, at least not for LyX. However, I don't know whether this would be a good idea right now. Having a quick 1.6 out of the door and doing XML later might make more sense. Andre'
Re: Branches feature addition
Martin Vermeer <[EMAIL PROTECTED]> writes:
> It _appears_ doable, even in the PC way where LyX, not
> LaTeX, handles the conditional outputting: one can, in math,
> have a LaTeX output differing from the LyX serialization
> ("write") routine -- e.g., have an arg enclosed in [] instead
> of the standard {} --, but then, as Georg pointed out, you also
> have to add special code in the math parser to translate the
> LaTeX in the LyX math insets back to this standard form.
I am not sure I understand what you mean. My idea was to have
InsetMathBranch::latex output nothing when the branch is disabled, and
its contents when it is enabled. InsetMathBranch::write would always
write \lyxbranchfoo{...contents...}.
JMarc
Re: 1.6svn module URL in use, but doesn't show up in charstyle menu :-(
Richard Heck <[EMAIL PROTECTED]> writes: > Martin Vermeer wrote: >> Eh, shouldn't URL rather be in stdinsets? If it's a standard >> feature... >> > That'd be fine with me. Should the URL module then be removed > altogether? If so, then I guess the lyx2lyx would need to be changed, > as well. Yes, it should be kept standard. JMarc
Re: [Cvslog] r21542 - /lyx-devel/trunk/src/LyXFunc.cpp
[EMAIL PROTECTED] schrieb: Author: spitz Date: Sat Nov 10 12:22:19 2007 New Revision: 21542 URL: http://www.lyx.org/trac/changeset/21542 Log: * src/LyXFunc.cpp (actOnUpdatedPrefs): - add missing case LyXRC::RC_DEFFILE (and shut up compiler) so there was still another case missing. cas this warning be enabled for msvc? bernhard
LyXAction and updates ?
Hello,
I'd like to know what is the purpose of these two LyXAction values:
LyXAction {
NoUpdate = 8, //< Does not
(usually) require update
SingleParUpdate = 16 //< Usually
only requires this par updated
};
and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.
Thanks,
T.
Re: [Cvslog] r21513 - in /lyx-devel/trunk/src/support: docstream.cpp d...
On Sat, Nov 10, 2007 at 07:01:57PM +0100, Enrico Forestieri wrote:
> + static size_t
> + length(char_type const * s)
> + {
> + char_type const * p = s;
> + while (*p)
> + +p;
Gotcha... should be ++p, of course.
> + return (p - s);
> + }
--
Enrico
Re: [Cvslog] r21513 - in /lyx-devel/trunk/src/support: docstream.cpp d...
On Sat, Nov 10, 2007 at 01:08:41PM +0100, Andre Poenitz wrote: > On Fri, Nov 09, 2007 at 12:22:25AM +0100, Enrico Forestieri wrote: > > > Hm... the easy way out would probably be an #include or such > > > guarded by #ifdef SOMETHING_CYGWIN_SPECIFIC. > > > > > > But there should be something cheaper. > > > > > > Is USE_WCHAR_T defined for you? > > > What type is lyx::char_type typedef'ed to? > > > For what types do you have char_traits<> specialized? > > > > BTW I get the same exact error on Linux after editing src/config.h > > and putting #undef USE_WCHAR_T just after the point where it gets defined. > > So this is a hint that it would not work with any compiler with > !defined(USE_WCHAR_T)? But isn't that with MSVC, too? Apparently, MSVC is better than gcc here... -- Enrico
Re: [Cvslog] r21513 - in /lyx-devel/trunk/src/support: docstream.cpp d...
On Sat, Nov 10, 2007 at 12:49:44PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 11:58:19PM +0100, Enrico Forestieri wrote:
> > > Hm... the easy way out would probably be an #include or such
> > > guarded by #ifdef SOMETHING_CYGWIN_SPECIFIC.
> >
> > I don't think this is cygwin specific, though.
>
> Possibly. But as long as we don't have
But we also have *BSD and Macs where USE_WCHAR_T is not defined.
> > > But there should be something cheaper.
> > >
> > > Is USE_WCHAR_T defined for you?
> >
> > No.
>
> But there's a wchar_t type, but that's presumably only 16 bits, so we
> don't use it, right?
Right.
> > > For what types do you have char_traits<> specialized?
> >
> > gcc has only specializations for char and wchar_t.
>
> I guess that's the common pattern and they are the only ones that are
> required.
No, the standard doesn't require any specialization. It is gcc that
is only specializing for char and wchar_t. For example, MSVC has
no problems with any type, seemingly.
> > The only way out that I see is a full blown specialization for
> > lyx::char_type, something like:
> >
> > template<>
> > struct char_traits
> > {
> >... put here what is needed...
> > };
>
> That would be a solution, but it's already a bit more of 'handcoding'
> than I'd consider sensible. I mean, have a few typedefs instead of
> #include is ok, duplicating ~200 lines rather not...
The attached strfwd-2.diff fails at link time, but strfwd-3.diff works.
However, note that I would have to still include the wchar.h (for wint_t
and mbstate_t) and string.h C headers. Then, there still would be a
problem with the streamoff type. The standard says that it is
implementation dependent and I should include the ios header to get its
definition. Moreover, even if we limit the specialization to gcc, there
surely would be a problem with 64 bit machines. The moral is that gcc
sucks with respect to MSVC, at least in this area.
In the end I verified that simply omitting the forward declaration
for lyx::char_type char traits, it works. I admit that I don't know
why it does, though. Probably this means that it is not needed, after
all.
> Is your wchar_t really 16 bit?
Yes, and cannot be easily changed. However, I have hacked the STLport
library such that I can have a 32 bit wchar_t on Cygwin with all needed
specializations. Of course, I would still be lacking proper support for
ancillary wide char functions, as STLport relies on those provided by
the system. Nothing that could not be solved, but I already invested a
good deal of effort in implementing the missing facets for the current
solution and I am not willing to start it over again.
--
Enrico
Index: src/support/strfwd.h
===
--- src/support/strfwd.h(revision 21530)
+++ src/support/strfwd.h(working copy)
@@ -23,6 +23,7 @@ namespace lyx { typedef wchar_t char_typ
#else
+#include
#include
namespace lyx { typedef boost::uint32_t char_type; }
@@ -37,6 +38,34 @@ template struct char_trai
template<> struct char_traits;
#ifdef USE_WCHAR_T
template<> struct char_traits;
+#else
+typedef long long streamoff;
+template class fpos;
+typedef fpos streampos;
+template<> struct char_traits {
+ typedef lyx::char_type char_type;
+ typedef wint_t int_type;
+ typedef streamoff off_type;
+ typedef streampos pos_type;
+ typedef mbstate_t state_type;
+
+ static void assign(char_type & c1, char_type const & c2);
+ static bool eq(char_type const & c1, char_type const & c2);
+ static bool lt(char_type const & c1, char_type const & c2);
+ static int
+ compare(char_type const * s1, char_type const * s2, size_t n);
+ static size_t length(char_type const * s);
+ static char_type const *
+ find(char_type const * s, size_t n, char_type const & a);
+ static char_type * move(char_type * s1, char_type const * s2, size_t n);
+ static char_type * copy(char_type * s1, char_type const * s2, size_t n);
+ static char_type * assign(char_type* s, size_t n, char_type a);
+ static int_type eof();
+ static int_type not_eof(int_type const & c);
+ static char_type to_char_type(int_type const & c);
+ static int_type to_int_type(char_type const & c);
+ static bool eq_int_type(int_type const & c1, int_type const & c2);
+};
#endif
template class basic_string;
Index: src/support/strfwd.h
===
--- src/support/strfwd.h(revision 21530)
+++ src/support/strfwd.h(working copy)
@@ -23,6 +23,8 @@ namespace lyx { typedef wchar_t char_typ
#else
+#include
+#include
#include
namespace lyx { typedef boost::uint32_t char_type; }
@@ -37,6 +39,89 @@ template struct char_trai
template<> struct char_traits;
#ifdef USE_WCHAR_T
template<> struct char_traits;
+#else
Re: trunk compile problem
Pavel Sanda wrote:
ui_TextLayoutUi.h: In member function 'void
Ui_TextLayoutUi::setupUi(QWidget*)':
ui_TextLayoutUi.h:154: error: expected primary-expression before '('
token
ui_TextLayoutUi.h:154: error: expected type-specifier
ui_TextLayoutUi.h:154: error: expected `>'
ui_TextLayoutUi.h:154: error: expected `('
ui_TextLayoutUi.h:154: error: expected unqualified-id before numeric
constant
ui_TextLayoutUi.h:154: error: expected `)' before numeric constant
../../../src/DispatchResult.h: In constructor
'lyx::DispatchResult::DispatchResult()':
../../../src/DispatchResult.h:24: error: expected unqualified-id before
numeric constant
GuiRef.cpp: At global scope:
GuiRef.cpp:46: error: redefinition of 'const std::string
lyx::frontend::lfun_name_'
GuiInclude.cpp:63: error: 'const std::string lyx::frontend::lfun_name_'
previously declared here
GuiKeySymbol.cpp:44: warning: 'char lyx::encode(const std::string&, const
QString&)' defined but not used
make[6]: *** [liblyxqt4.lo] Error 1
make[6]: Leaving directory
`/home/installer/lyx/trunk_disable/src/frontends/qt4'
make[5]: *** [all] Error 2
Broken by 21149.
Richard, we have a restriction of which you might not ave heard yet:
static functions/objects need to have different names, even if they
are in different .cpp files, otherwise the 'chunked build' will fail.
Sorry! I've fixed it.
hmm i still see the same error. maybe its caused by some different problem ?
If you're seeing that problem, your trunk must be out of date:
[EMAIL PROTECTED] src]$ srcgrep lfun_name_
frontends/qt4/GuiCitation.cpp:589:
InsetCommandMailer::string2params(lfun_name_, data, params_);
frontends/qt4/GuiDialog.h:169: //FIXME It should be possible to
eliminate lfun_name_
frontends/qt4/GuiDialog.h:173: std::string const lfun_name_;
frontends/qt4/GuiDialog.cpp:273: : GuiDialog(lv, name),
params_(insetCode(name)), lfun_name_(name)
frontends/qt4/GuiDialog.cpp:282:
InsetCommandMailer::string2params(lfun_name_, data, params_);
frontends/qt4/GuiDialog.cpp:289: if (lfun_name_.empty())
frontends/qt4/GuiDialog.cpp:293:
InsetCommandMailer::params2string(lfun_name_, params_);
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: update links on wiki
[EMAIL PROTECTED] wrote: > At least it is lame by design :-) Which means the design is lame. Jürgen
Re: update links on wiki
On Thu, 8 Nov 2007, Edwin Leuven wrote: Juergen Spitzmueller wrote: Edwin Leuven wrote: > i had the impression a password was needed It is. But it's not really secret (I found it within 5 minutes on the Internet). how lame... At least it is lame by design :-) /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Sorter struct
> can i change it back to the class ?
see attachment. if there won't be objections, i'll put it in later.
> pavel
diff --git a/src/frontends/qt4/qt_helpers.cpp b/src/frontends/qt4/qt_helpers.cpp
index 0cc436f..0209a5b 100644
--- a/src/frontends/qt4/qt_helpers.cpp
+++ b/src/frontends/qt4/qt_helpers.cpp
@@ -41,6 +41,7 @@
#include
#include
+#include
using std::string;
using std::vector;
@@ -162,11 +163,34 @@ QString const qt_(string const & str)
namespace {
-struct Sorter
+class Sorter
{
+public:
+#if !defined(USE_WCHAR_T) && defined(__GNUC__)
bool operator()(LanguagePair const & lhs, LanguagePair const & rhs)
const {
return lhs.first < rhs.first;
}
+#else
+ Sorter() : loc_ok(true)
+ {
+ try {
+ loc_ = std::locale("");
+ } catch (...) {
+ loc_ok = false;
+ }
+ };
+
+ bool operator()(LanguagePair const & lhs,
+ LanguagePair const & rhs) const {
+ if (loc_ok)
+ return loc_(lhs.first, rhs.first);
+ else
+ return lhs.first < rhs.first;
+ }
+private:
+ std::locale loc_;
+ bool loc_ok;
+#endif
};
Re: CVS/SVN logs
Michael Gerz wrote: > Pavel's commits do not appear in the cvs log mailing list. He's not subscribed yet (only Lars can accept the subscription). Jürgen
CVS/SVN logs
Hi, Pavel's commits do not appear in the cvs log mailing list. Michael
[patch] bug 4345: Correction of shortcut behaviour in "Print" dialog
http://bugzilla.lyx.org/show_bug.cgi?id=4345 The patch (against branch) is straightforward. However, since last time the ui file was saved in 4.3 format even though I used the designer of Qt4.1, could someone with Qt4.2 please test if this builds there? Thanks, Jürgen P.S., Michael: the German print dialog has a duplicated accelerator: "_D_urchsuchen" and "_D_atei:" Index: src/frontends/qt4/ui/PrintUi.ui === --- src/frontends/qt4/ui/PrintUi.ui (Revision 21543) +++ src/frontends/qt4/ui/PrintUi.ui (Arbeitskopie) @@ -147,9 +147,9 @@ - + - Copies + Copie&s @@ -345,5 +345,70 @@ closePB - + + + printerRB + clicked() + printerED + setFocus() + + + 60 + 56 + + + 254 + 56 + + + + + fileRB + clicked() + fileED + setFocus() + + + 60 + 91 + + + 213 + 91 + + + + + rangeRB + clicked() + fromED + setFocus() + + + 55 + 206 + + + 108 + 206 + + + + + copiesGB + clicked() + copiesSB + setFocus() + + + 214 + 373 + + + 52 + 384 + + + +
Re: Branches feature addition
On Sat, Nov 10, 2007 at 01:11:34PM +0100, Andre Poenitz wrote: > On Fri, Nov 09, 2007 at 07:20:11AM +0200, Martin Vermeer wrote: > > On Thu, Nov 08, 2007 at 09:11:26PM +0100, Andre Poenitz wrote: > > > On Thu, Nov 08, 2007 at 08:47:29PM +0200, Martin Vermeer wrote: > > > > On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote: > > > > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > > > > > > > > > n times for every string you want to 'branchify', i.e., n times for > > > > > > every > > > > > > case in a 'cases' statement, n times the number of branchifyable > > > > > > strings > > > > > > in an XFig graphic, etc., where n is the number of branches. > > > > > > Remember > > > > > > this is ERT-like. It's not LyX inserting these command names. > > > > > > > > > > I math, it should be a MathBranch inset. > > > > > > > > Hmmm, that's an interesting idea. How would that work in practice? > > > > > > > > Wouldn't it be better to strive for allowing true text insets embedded > > > > in math? (Surely not simple.) > > > > > > The problem is reading from an external file (*.lyx). The rest more or > > > less works. > > > > How hard would that be to fix? > > Very hard. That's why we don't have real text-in-math since 1.3 when it > became possible in theory. It will be easier when we have a structured > file format (i.e. XML), but somehow XML seemingly got stuck... > > Andre' But didn't we have some parts of it working? What happened to that? Why would we not just commit what we have? Tabular is already XML based and I hear no complaints about that. - Martin
Re: [Cvslog] r21525 - /lyx-devel/trunk/src/frontends/qt4/GuiFloat.cpp
On Thu, Nov 08, 2007 at 11:05:48PM -, [EMAIL PROTECTED] wrote: > Author: uwestoehr > Date: Fri Nov 9 00:05:48 2007 > New Revision: 21525 > > URL: http://www.lyx.org/trac/changeset/21525 > Log: > GuiFloat.cpp: fix the regression that float placement dialog has no title Thanks. Andre'
Re: trunk compile failiure
On Sat, Nov 10, 2007 at 02:10:22AM +0100, Uwe Stöhr wrote:
> Since yesterday I get this error:
>
> FileName.cpp
> D:\LyXSVN\lyx-devel\src\support\FileName.cpp(629) : error C2589: '(':
> Invalid token at the right side of '::'
> D:\LyXSVN\lyx-devel\src\support\FileName.cpp(629) : error C2059: Syntax
> error: '::'
>
> I fixed this yesterday:
> http://www.lyx.org/trac/changeset/21523
> but Abdel reverted it:
> http://www.lyx.org/trac/changeset/21529
>
> So what is wrong?
Windows?
Try #undef max after the last #include in that file.
Andre'
Re: Branches feature addition
On Fri, Nov 09, 2007 at 07:20:11AM +0200, Martin Vermeer wrote: > On Thu, Nov 08, 2007 at 09:11:26PM +0100, Andre Poenitz wrote: > > On Thu, Nov 08, 2007 at 08:47:29PM +0200, Martin Vermeer wrote: > > > On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote: > > > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > > > > > > > n times for every string you want to 'branchify', i.e., n times for > > > > > every > > > > > case in a 'cases' statement, n times the number of branchifyable > > > > > strings > > > > > in an XFig graphic, etc., where n is the number of branches. Remember > > > > > this is ERT-like. It's not LyX inserting these command names. > > > > > > > > I math, it should be a MathBranch inset. > > > > > > Hmmm, that's an interesting idea. How would that work in practice? > > > > > > Wouldn't it be better to strive for allowing true text insets embedded > > > in math? (Surely not simple.) > > > > The problem is reading from an external file (*.lyx). The rest more or > > less works. > > How hard would that be to fix? Very hard. That's why we don't have real text-in-math since 1.3 when it became possible in theory. It will be easier when we have a structured file format (i.e. XML), but somehow XML seemingly got stuck... Andre'
Re: [Cvslog] r21513 - in /lyx-devel/trunk/src/support: docstream.cpp d...
On Fri, Nov 09, 2007 at 12:22:25AM +0100, Enrico Forestieri wrote: > > Hm... the easy way out would probably be an #include or such > > guarded by #ifdef SOMETHING_CYGWIN_SPECIFIC. > > > > But there should be something cheaper. > > > > Is USE_WCHAR_T defined for you? > > What type is lyx::char_type typedef'ed to? > > For what types do you have char_traits<> specialized? > > BTW I get the same exact error on Linux after editing src/config.h > and putting #undef USE_WCHAR_T just after the point where it gets defined. So this is a hint that it would not work with any compiler with !defined(USE_WCHAR_T)? But isn't that with MSVC, too? Andre'
Re: [Cvslog] r21513 - in /lyx-devel/trunk/src/support: docstream.cpp d...
On Thu, Nov 08, 2007 at 11:58:19PM +0100, Enrico Forestieri wrote:
> > Hm... the easy way out would probably be an #include or such
> > guarded by #ifdef SOMETHING_CYGWIN_SPECIFIC.
>
> I don't think this is cygwin specific, though.
Possibly. But as long as we don't have
> > But there should be something cheaper.
> >
> > Is USE_WCHAR_T defined for you?
>
> No.
But there's a wchar_t type, but that's presumably only 16 bits, so we
don't use it, right?
> > What type is lyx::char_type typedef'ed to?
>
> Seems to be unsigned long.
Ok, that's from boost::stdint..
> > For what types do you have char_traits<> specialized?
>
> gcc has only specializations for char and wchar_t.
I guess that's the common pattern and they are the only ones that are
required.
> The only way out that I see is a full blown specialization for
> lyx::char_type, something like:
>
> template<>
> struct char_traits
> {
>... put here what is needed...
> };
That would be a solution, but it's already a bit more of 'handcoding'
than I'd consider sensible. I mean, have a few typedefs instead of
#include is ok, duplicating ~200 lines rather not...
Is your wchar_t really 16 bit?
Andre'
Sorter struct
hi, i would like to rescue patch http://bugzilla.lyx.org/attachment.cgi?id=2063&action=view for bug 2738. meanwhile the class Sorter changed into struct in http://www.lyx.org/trac/changeset/20225 . what was the reason for this change ? can i change it back to the class ? pavel
Re: trunk compile failiure
Uwe Stöhr wrote:
Since yesterday I get this error:
FileName.cpp
D:\LyXSVN\lyx-devel\src\support\FileName.cpp(629) : error C2589: '(':
Invalid token at the right side of '::'
D:\LyXSVN\lyx-devel\src\support\FileName.cpp(629) : error C2059: Syntax
error: '::'
I fixed this yesterday:
http://www.lyx.org/trac/changeset/21523
but Abdel reverted it:
http://www.lyx.org/trac/changeset/21529
So what is wrong?
Try to put this line at the top of FileName.cpp:
#undef max
If this fixes it then scons is broken on your platform.
Abdel.
