Re: The LyX licence
Dear members of the LyX-team, I hereby grant permission to licence everything I have contributed to LyX under the Gnu General Public Licence, version 2 or later. Regards, Rob Lahaye.
Re: View->Postscript error: use --swap instead of -swap
Rob Lahaye wrote: > > My LyX, by default, uses for Postscript viewing "gv -swap" > (as in Tools->Preferences->Conversion->Formats, Postscript) > > However, eversince I upgraded to gv version 3.6.1, the -swap does > not work anymore, and consequently, Postscript viewing with LyX is > not working (not working with out-of-the box configuration, that is). > > I have to modify -swap to --swap in the preferences settings. > Then it's OK again. > > Has nobody else with up-to-date gv, trouble with this? > > I wonder, whether LyX-CVS by default, should choose to support latest > gv version. People with older gv, can then modify the preferences, or > upgrade to newer gv. > By the time the next LyX is released, it may not work with common version > of gv of that time, maybe. This could be a possible patch for fixing this for gv: Index: lib/configure.m4 === RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v retrieving revision 1.91 diff -u -r1.91 configure.m4 --- lib/configure.m42005/01/20 15:02:15 1.91 +++ lib/configure.m42005/01/24 17:44:33 @@ -295,7 +295,8 @@ # Search something to preview postscript SEARCH_PROG([for a Postscript previewer],GHOSTVIEW,gsview32 gv ghostview kghostview) case $GHOSTVIEW in - gv|ghostview) PS_VIEWER="$GHOSTVIEW -swap" ;; + gv) PS_VIEWER="$GHOSTVIEW --swap" ;; + ghostview) PS_VIEWER="$GHOSTVIEW -swap" ;; *) PS_VIEWER="$GHOSTVIEW";; esac EPS_VIEWER=$GHOSTVIEW
Re: FreeBSD/gcc-3.4.2: gmake ends with linking error
Jean-Marc Lasgouttes wrote: > Rob> It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC. > > Rob> Does that make sense? > > So the stdlibc++ debug feature is broken with your compiler version, I > guess. You should ask the freebsd people for more info. When we know > exactly what happens, we can maybe blacklist some freebsd/gcc combo in > the code that enables debug. > > What is your gcc version? It's 3.4.2. This version ships with FreeBSD 5.3 (latest release). This version of gcc may be the default compiler on FreeBSD for quite some time to come, I guess. I'll see if I can manage to ring a few bells on the FreeBSD mailinglist about this issue. Rob.
View->Postscript error: use --swap instead of -swap
Hi, My LyX, by default, uses for Postscript viewing "gv -swap" (as in Tools->Preferences->Conversion->Formats, Postscript) However, eversince I upgraded to gv version 3.6.1, the -swap does not work anymore, and consequently, Postscript viewing with LyX is not working (not working with out-of-the box configuration, that is). I have to modify -swap to --swap in the preferences settings. Then it's OK again. Has nobody else with up-to-date gv, trouble with this? I wonder, whether LyX-CVS by default, should choose to support latest gv version. People with older gv, can then modify the preferences, or upgrade to newer gv. By the time the next LyX is released, it may not work with common version of gv of that time, maybe. Rob.
Re: FreeBSD/gcc-3.4.2: gmake ends with linking error
Jean-Marc Lasgouttes wrote: >>>>>> Rob Lahaye writes: > > Rob> Yep, that solves the problem; not that I know what I'm doing > Rob> though. But LyX compiles like a charm! > > Rob> Can you explain a little? Is this a bug, or a misbehaving feature > Rob> of FreeBSD, or perhaps LyX or gcc? > > I think this is a bug of gcc on freebsd. These things turn on some > recent (gcc 3.3 or 3.4) debug features of the C++ standard library. > > It seems that at least one of these is broken. If you have time, you > could try to turn them off one by one and see which one is the > culprit. It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC. > Rob> Even more important: how can I tell the configure script to never > Rob> set these #def directives again in the future? > > use --disable-stdlib-debug and/or --disable-concept-checks. Using --disable-stdlib-debug is enough to solve the problem. Does that make sense? Rob.
New Userdir: [Create directory] and [Exit LyX] buttons mixed up?
Hi, I start LyX-cvs like this: $ src/lyx -userdir /tmp/LyX Because /tmp/LyX does not exist, a dialog appears with You have specified a non-existent user LyX directory, /tmp/LyX. It is needed to keep your own configuration. [Create directory][Exit LyX] I then click on [Create directory], but LyX seems to just exit without any message. The directory is not created. HOWEVER, if I click on [Exit LyX], then LyX creates the directory and continues. Apparently the function of the two buttons are mixed up here. Rob.
Re: FreeBSD/gcc-3.4.2: gmake ends with linking error
Jean-Marc Lasgouttes wrote: >>>>>>"Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes: > > > Rob> I can compile LyX almost; something goes wrong at the very end. > Rob> At the end of gmake, when the final executable is being linked, I > Rob> get zillions of following lines: > > Rob> $ gmake [...] > Rob> BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19): > Rob> In function `__gnu_norm::list > >>>::_M_insert(__gnu_norm::_List_iterator, Branch const&)': > > > Do you have one of these things defined in config.h? > > /* libstdc++ concept checking */ > #undef _GLIBCPP_CONCEPT_CHECKS > > /* libstdc++ concept checking */ > #undef _GLIBCXX_CONCEPT_CHECKS > > /* libstdc++ debug mode */ > #undef _GLIBCXX_DEBUG > > /* libstdc++ pedantic debug mode */ > #undef _GLIBCXX_DEBUG_PEDANTIC > > Could you test what happens when turning them off? Yep, that solves the problem; not that I know what I'm doing though. But LyX compiles like a charm! Can you explain a little? Is this a bug, or a misbehaving feature of FreeBSD, or perhaps LyX or gcc? Even more important: how can I tell the configure script to never set these #def directives again in the future? Thanks! Rob.
FreeBSD/gcc-3.4.2: gmake ends with linking error
Hi, First: thanks for solving the sh vs. bash issue, which is now working on my FreeBSD system. I can compile LyX almost; something goes wrong at the very end. At the end of gmake, when the final executable is being linked, I get zillions of following lines: $ gmake [...] BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19): In function `__gnu_norm::list >::_M_insert(__gnu_norm::_List_iterator, Branch const&)': /usr/include/c++/3.4/bits/locale_facets.tcc:2443: undefined reference to `__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)' BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE8_M_eraseENS_14_List_iteratorIS1_EE+0xd): In function `__gnu_norm::list >::_M_erase(__gnu_norm::_List_iterator)': /usr/include/c++/3.4/debug/list:122: undefined reference to `__gnu_norm::_List_node_base::unhook()' [...cut...] /usr/include/c++/3.4/bits/stl_algobase.h:155: undefined reference to `__gnu_norm::_List_node_base::transfer(__gnu_norm::_List_node_base*, __gnu_norm::_List_node_base*)' ../boost/libs/signals/src/.libs/libboost_signals.a(trackable.o)(.gnu.linkonce.t._ZN10__gnu_norm4listIN5boost7signals10connectionESaIS3_EE9_M_insertENS_14_List_iteratorIS3_EERKS3_+0x28): In function `__gnu_norm::list >::_M_insert(__gnu_norm::_List_iterator, boost::signals::connection const&)': /usr/include/c++/3.4/debug/formatter.h:359: undefined reference to `__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)' gmake[3]: *** [lyx-xforms] Error 1 All lines have something about "__gnu_norm". Any idea what this is about? I only have this with LyX, but if lyx-devel people tell me that this not a LyX issue, I may next contact the FreeBSD list for answers. Rob.
Re: boost/libs/filesystem/src: Syntax error: Bad substitution
Jose' Matos wrote: > On Tuesday 18 January 2005 12:12, Rob Lahaye wrote: > >>>not bash? >> >>Hmm, bash is the default shell in the linux community, isn't it? >>However, the FreeBSD base system has csh, sh and tcsh. > > We should make it work with sh, as it will then work in other posix > systems, if that is what you mean. :-) Yes, indeed, that is exactly what I mean. I believe 'sh' is garanteed to be included in any flavor of *nix, the free and commercial ones. Thank you for rephrasing it more correctly. Rob.
Re: boost/libs/filesystem/src: Syntax error: Bad substitution
Lars Gullik Bjønnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | On FreeBSD 5.3, with GCC-3.4.2:
>
> | [...]
> | gmake[4]: Entering directory
> | `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
> | TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src -Winvalid-pch
> | --include=./pch.h -DBOOST_USER_CONFIG="" -I../../../../boost
-Wextra
> | -Wall -I/usr/local/include -I/usr/X11R6/include -g -O -fno-exceptions |
sed
> | -e s,\",\',` ; \
> | PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
> | ${TMPCMD/$PATTERN} \
> | -x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF "./pch.h.gch.Tdep" \
> | && mv "./pch.h.gch.Tdep" "./pch.h.gch.dep" || rm "./pch.h.gch.Tdep"
> | Syntax error: Bad substitution
> | gmake[4]: *** [pch.h.gch] Error 2
>
>>
> | What's the "Syntax error: Bad substitution" here?
>
> not bash?
>
Hmm, bash is the default shell in the linux community, isn't it?
However, the FreeBSD base system has csh, sh and tcsh.
Of course, I can install bash as an additional package, but is it
wise to make these build scripts depend on a kind of 'linux-ism'?
Regards,
Rob.
boost/libs/filesystem/src: Syntax error: Bad substitution
On FreeBSD 5.3, with GCC-3.4.2:
[...]
gmake[4]: Entering directory
`/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src -Winvalid-pch
--include=./pch.h -DBOOST_USER_CONFIG="" -I../../../../boost -Wextra
-Wall -I/usr/local/include -I/usr/X11R6/include -g -O -fno-exceptions | sed
-e s,\",\',` ; \
PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
${TMPCMD/$PATTERN} \
-x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF "./pch.h.gch.Tdep" \
&& mv "./pch.h.gch.Tdep" "./pch.h.gch.dep" || rm "./pch.h.gch.Tdep"
Syntax error: Bad substitution
gmake[4]: *** [pch.h.gch] Error 2
What's the "Syntax error: Bad substitution" here?
Rob.
Re: FreeBSD compilation problems with boost stuff
Lars Gullik Bjønnes wrote: > Rob <[EMAIL PROTECTED]> writes: > > | Hi, > > | There are few clashes with LyX's boost stuff on the FreeBSD system. > | I use compiler gcc 3.4.2. > > | 1. Following patch is needed to have cstdint.hpp compile without > |error message (I have tried to investigate where exactly uintmax_t > |is already defined on my system, but to no avail; I've already > |reported this some time ago). > > Can you report it to the boost list as well? > (your fix might be our breakage) > > | 2. After above patch, I now get following problems: > > | /usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost > | -I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch > | --include=./pch.h > | -g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF > | .deps/tostr.TPlo -o tostr.o > | In file included from tostr.C:14: > | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a > | member of `std' > > Hmm we define BOOST_NO_WSTRING in config.h so there should be no > way for you to get the "wstring" stuff at all. What gives? > Ok I see... there is a template3 specialization in lexical_cast that > is not protected by DISABLE_WIDE_CHAR_SUPPORT. > > I'll send a msg to the boost list about this one. Meanwhile I have communicated this to the boost list and got following two answers: - 1) Could be related to the following g++ problem. Scheduled to be fixed in gcc 3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005 2) FreeBSD's wchar_t support is limited, so GCC does not enable any wide-char support in the C++ stdlib All uses of wstring/char_t/wstream etc. are be guarded by BOOST_NO_WSTRING so they aren't compiled on platforms without wchar support in the stdlib. BOOST_NO_WSTRING will get set automatically because the stdlib does not define _GLIBCXX_USE_WCHAR_T on FreeBSD. However, Boost 1.31 was released before GCC 3.4.1, which changed the stdlib macros from _GLIBCPP_blahblah to _GLIBCXX_blahblah and so Boost's config fails to configure correctly for this compiler. You could try taking the boost/config/stdlib/libstdcppv3.hpp header from CVS, but note that there are additional problems with GCC 3.4.x and Boost due to GCC 3.4 unconditionally defining _REENTRANT. See GCC PR 11953 for details. (I've written a summary of this issue, but it's sitting on my hard drive at home somewhere. I need to send it to this list...) In short, you must define either BOOST_DISABLE_THREADS or compile with -pthreads to avoid linker errors from the pthread_xxx functions. - Does that give a clue to you LyX/Boost gurus? Or will it be for FreeBSD just a matter of waiting for 3.5 to be released? Unfortunately, the soon upcoming release branch 5.X of FreeBSD ships with GCC 3.4.2. So the problem may persist for quite some time. Rob.
Re: Mailinglist issue: gmane archive does not hide email addresses
Andre Poenitz wrote: On Thu, Jun 03, 2004 at 07:37:00PM +0900, Rob Lahaye wrote: I'm suprised nobody is upset about this!?! Using a provider with a good spam filter helps a lot. Bleh! This is about preventing spam, not how to filter it PS: I wish I could use my anti-spam email address for this, but lyx doesn't allow me. My 'anti-spam' email address bounces back, since it's fake; ... This is considered rude behaviour in some parts of the net... Rude? When communicating with a public mailing list? The mailinglist should be the medium of communication, not the personal email addresses. And in this context I'd rather be a little rude and prevent spamming, than also being polite to spammers Ah, well, I made my point. If noone else cares, then let it be. Cheers, Rob.
Re: boost/cstdint.hpp:121: error
Angus Leeming wrote:
Sigh.
I'd like you to post a minimal, failing program of the form
#define uintmax_t unsigned long long
#include
int main() { return 0; }
where the #define is taken from your config.h file.
Right, you've got it already. So here we go again:
$ cat test.C
#define uintmax_t unsigned long long
#include
int main () { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -fno-exceptions \
-W -Wall -c -o test.lo test.C
In file included from test.C:2:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
Is this enough, or am I supposed to provide more info?
Please bear with me; I'm still not so sure what I'm doingdon't know
anything about what is happening in the boost stuff, and why this all
of a sudden clashes with the config.h file.
Rob.
Re: boost/cstdint.hpp:121: error
Angus Leeming wrote:
Rob Lahaye wrote:
Hmmm, don't think I get it. I thought, there's a line in
src/config.h that's causing trouble. Started deleting lines in
src/config.h, but then ended up deleting all lines in that file and
still getting the same error
So where am I supposed to look for this?
Actually, your suggestion to put another #define in the trial.C
file, is totally uncomprehesible for me :(. Don't see at all what it
means.
is included from within if you pass
-DBOOST_USER_CONFIG="" to the compiler.
So, rather than pass this macro to the compiler I was telling you
to compile this 'normally'. Ie without the macro.
#include
#include
int main() { return 0; }
If you can do that without triggering the error, then I'm baffled.
If you can't, then it makes sense to try and isolate the actual
#define that is causing the error.
Surprise surprise. I have these lines in src/config.h:
/* Define to unsigned long or unsigned long long if and
don't define. */
#define uintmax_t unsigned long long
which obviously causes the trouble. Apparently, this clashes with what
I have in /usr/include/machine/ansi.h:
typedef unsigned long long __uint64_t;
Or another typedef elsewhere? Does this bring us any closer?
Rob.
Re: Mailinglist issue: gmane archive does not hide email addresses
[EMAIL PROTECTED] wrote: On Thu, Jun 03, 2004 at 05:46:16PM +0900, Rob Lahaye wrote: All these archives are publicly available, which means someone can collect the emails from there for third parties spam-junk stuff, if the sender's email address is not hidden; mail-archive and theaimsgroup do this nicely! theaimsgroup is the worst, if you want my opinion. Within hours of posting to a list there, the address I use gets spammed. Tried it many times. But here is, I believe, where the trouble with gmane.org starts: all emails are 'as-is' on this archive, nothing is hidden! Which means, it's an excellent source for spam/junk distibutors to add all lyx-devel contributors to their list of email addresses. There are many developers who read this list as news; they need gmane. So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup hiding strategy, is made totally redundant by forwarding everything automatically also to the gmane.org. Actually, by forcing the use of a legitimate email address by the subscription mechanism, we are also forced to have our legitimate email address published on the public gmane archive. This is a very bad construction! Can you back up your claim about gmane not hiding the aaddresses? Have you read http://gmane.org/tmda.php No I haven't. I find it rather complicated though. What do you think of this excerpt: While the X-Archive header makes all addresses in your message be encrypted, if somebody on the mailing list responds to your message, it's still likely that your real email address will be included in the follow-up. It's probably more useful to switch encryption on for the entire list. Encription of entire list!?! Sounds like that would solve the exposure of email addresses for everyone, especially new subscribers; old subscribers are already exposed until now :(. Sorry, I'm not an email expert; don't know about setting X-archive fields etc. I'm only worried about the increasing amount of spam arriving at my inbox (yes, yes, I use a spam filter.). Rob. By the way: are you "[EMAIL PROTECTED]"? It's just there on gmane archive!
Re: boost/cstdint.hpp:121: error
Angus Leeming wrote:
Rob Lahaye wrote:
Once again: removing -DBOOST_USER_CONFIG="" from the
compile line above, solves the problem.
Does that bring us any closer?
Sure. Something in is messing up the (quite small)
You should try and isolate the #define that is screwing things up.
As a preliminary guess, looking at the you posted, try
#define uintmax_t unsigned long long
#include
int main () { return 0; }
Compile with a normal
$ gcc -I/boost -o trial trial.C
Anyway, I'm sure that you get the point and can find the offender
from here.
Hmmm, don't think I get it. I thought, there's a line in src/config.h
that's causing trouble. Started deleting lines in src/config.h, but
then ended up deleting all lines in that file and still getting
the same error
So where am I supposed to look for this?
Actually, your suggestion to put another #define in the trial.C file,
is totally uncomprehesible for me :(. Don't see at all what it means.
Rob.
Re: boost/cstdint.hpp:121: error
Angus Leeming wrote:
Rob Lahaye wrote:
So what now happens if you reduce your test case to the more minimal
#include
int main { return 0; }
where you compile with your 'lyx-style' command line invocation of g++?
$ cat test.C
#include
int main () { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" \
-fno-exceptions -W -Wall -c -o test.lo test.C
In file included from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
Once again: removing -DBOOST_USER_CONFIG="" from the compile
line above, solves the problem.
Does that bring us any closer?
Rob.
Re: boost/cstdint.hpp:121: error
Angus Leeming:
So what happens if you #include *all* the system
headers of cpp_regex_traits.cpp
$ cat test.C
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main() { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost -I/usr/local/include \
-I/usr/X11R6/include -DBOOST_USER_CONFIG="" -fno-exceptions -W -Wall \
-c -o test.lo test.C
In file included from boost/boost/regex/config.hpp:54,
from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
--
$ grep "^#" src/config.h
#ifndef _CONFIG_H
#define _CONFIG_H
#define AIKSAURUS_H_LOCATION
#define DEVEL_VERSION 1
#define ENABLE_ASSERTIONS 1
#define ENABLE_NLS 1
#define HAVE_ALLOCA 1
#define HAVE_ASPELL_H 1
#define HAVE_ASPRINTF 1
#define HAVE_DCGETTEXT 1
#define HAVE_DECL_FEOF_UNLOCKED 1
#define HAVE_DECL_FGETS_UNLOCKED 0
#define HAVE_DECL_GETC_UNLOCKED 1
#define HAVE_DECL_ISTREAMBUF_ITERATOR 1
#define HAVE_DECL_MKSTEMP 1
#define HAVE_DECL_SNPRINTF 1
#define HAVE_DECL_VSNPRINTF 1
#define HAVE_DECL__SNPRINTF 0
#define HAVE_DECL__SNWPRINTF 0
#define HAVE_DIRENT_H 1
#define HAVE_DLFCN_H 1
#define HAVE_GETCWD 1
#define HAVE_GETEGID 1
#define HAVE_GETEUID 1
#define HAVE_GETGID 1
#define HAVE_GETPAGESIZE 1
#define HAVE_GETTEXT 1
#define HAVE_GETUID 1
#define HAVE_ICONV 1
#define HAVE_INTTYPES_H 1
#define HAVE_IOS 1
#define HAVE_ISTREAM 1
#define HAVE_KPSEWHICH 1
#define HAVE_LANGINFO_CODESET 1
#define HAVE_LC_MESSAGES 1
#define HAVE_LIBC 1
#define HAVE_LIBM 1
#define HAVE_LIMITS 1
#define HAVE_LIMITS_H 1
#define HAVE_LOCALE 1
#define HAVE_LOCALE_H 1
#define HAVE_LONG_DOUBLE 1
#define HAVE_LONG_LONG 1
#define HAVE_MALLOC_H 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMORY_H 1
#define HAVE_MEMSET 1
#define HAVE_MKFIFO 1
#define HAVE_MKSTEMP 1
#define HAVE_MKTEMP 1
#define HAVE_MMAP 1
#define HAVE_MUNMAP 1
#define HAVE_NL_TYPES_H 1
#define HAVE_OSTREAM 1
#define HAVE_POSIX_PRINTF 1
#define HAVE_PUTENV 1
#define HAVE_SETENV 1
#define HAVE_SETLOCALE 1
#define HAVE_SNPRINTF 1
#define HAVE_SSTREAM 1
#define HAVE_STDDEF_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STD_COUNT 1
#define HAVE_STRCASECMP 1
#define HAVE_STRCHR 1
#define HAVE_STRDUP 1
#define HAVE_STRERROR 1
#define HAVE_STRINGS_H 1
#define HAVE_STRING_H 1
#define HAVE_STRTOUL 1
#define HAVE_SYS_PARAM_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_TSEARCH 1
#define HAVE_UNISTD_H 1
#define HAVE_UNSIGNED_LONG_LONG 1
#define HAVE_VSNPRINTF 1
#define HAVE_WCHAR_T 1
#define HAVE_WCSLEN 1
#define HAVE_WINT_T 1
#define HAVE_X11_FLIMAGE_H 1
#define HAVE_ZLIB_H 1
#define ICONV_CONST const
#define INTDIV0_RAISES_SIGFPE 1
#define MODERN_STL_STREAMS 1
#define PACKAGE "lyx"
#define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
#define PACKAGE_NAME "lyx"
#define PACKAGE_STRING "lyx 1.4.0cvs"
#define PACKAGE_TARNAME "lyx"
#define PACKAGE_VERSION "1.4.0cvs"
#define RETSIGTYPE void
#define SELECT_TYPE_ARG1 int
#define SELECT_TYPE_ARG234 (fd_set *)
#define SELECT_TYPE_ARG5 (struct timeval *)
#define SIZE_MAX 4294967295U
#define STDC_HEADERS 1
#define TIME_WITH_SYS_TIME 1
#define USE_ASPELL 1
#define USE_COMRESSION 1
#define USE_JPEG_IMAGE_LOADER 1
#define VERSION "1.4.0cvs"
#define WITH_WARNINGS 1
#ifndef _ALL_SOURCE
#endif
#define uintmax_t unsigned long long
#ifndef HAVE_STRCHR
# define strchr(a,b)index(a,b)
#endif
#ifndef HAVE_MEMMOVE
# define memmove(a,b,c) bcopy(b,a,c)
#endif
#ifndef HAVE_STRERROR
#if defined(__cplusplus)
#endif
#endif
#ifdef BROKEN_HEADERS
#include "broken_headers.h"
#endif
#ifdef HAVE_MKSTEMP
#ifndef HAVE_DECL_MKSTEMP
#if defined(__cplusplus)
#endif
#endif
#endif
#ifdef __EMX__
#include "support/os2_defines.h"
#endif
#if defined(HAVE_OSTREAM) && defined(HAVE_LOCALE) && defined(HAVE_SSTREAM)
#define USE_BOOST_FORMAT 1
#else
#define USE_BOOST_FORMAT 0
#endif
#define BOOST_USER_CONFIG
#if defined(ENABLE_ASSERTIONS)
#define BOOST_ENABLE_ASSERT_HANDLER 1
#else
#define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_DISABLE_THREADS 1
#define BOOST_NO_WREGEX 1
#define BOOST_NO_WSTRING 1
#endif
Re: boost/cstdint.hpp:121: error
Angus Leeming
Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Again, no problem. What else can I do?
I feel a bit lost now...
Rob, I take it that this fails to compile:
OK, got something here.
I copied (more or less) the compile line as it appears in the gmake
process. And then I found that the following fails:
$ cat test.C
#include
int main() { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" \
-fno-exceptions -W -Wall -c -o test.lo test.C
In file included from boost/boost/regex/config.hpp:54,
from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
-
*HOWEVER*:
when I remove -DBOOST_USER_CONFIG="" from this line,
it compiles without error!!!
Does that ring a bell?
Do you need to know what I have in src/config.h ?
Rob.
Re: boost/cstdint.hpp:121: error
Angus Leeming:
Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Again, no problem. What else can I do?
I feel a bit lost now...
Rob, I take it that this fails to compile:
Nah, also no problem:
$ cat test.C ; g++33 -Iboost -o test.o test.C
#include
int main() { return 0; }
$
And still, LyX gets stuck in boost on my FreeBSD PC.
Problem is, that I can't make head nor tail from the complex coding
in that boost stuff. I can't even make much out of the error message
(well, Lars helped me out here, but it's still foggy stuff for me).
Any other suggestions.?
Ah well, if nobody else suffers from this, as of yet!?!
Regards,
Rob.
Re: Mailinglist issue: gmane archive does not hide email addresses
Lars Gullik Bjønnes: Rob Lahaye <[EMAIL PROTECTED]> writes: | Hi, | [EMAIL PROTECTED] mailing list needs subscription (or alternatively | a once-only permission granted for sending emails, without the full | subscription). Once that is done, all emails to the list are also archived | at | 1) www.mail-archive.com/[EMAIL PROTECTED] | 2) marc.theaimsgroup.com/?l=lyx-devel | 3) gmane.org |(are there more?) | All these archives are publicly available, which means someone can collect | the emails from there for third parties spam-junk stuff, if the sender's | email address is not hidden; mail-archive and theaimsgroup do this nicely! | But here is, I believe, where the trouble with gmane.org starts: all emails | are 'as-is' on this archive, nothing is hidden! Which means, it's an | excellent source for spam/junk distibutors to add all lyx-devel contributors | to their list of email addresses. | So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup | hiding strategy, is made totally redundant by forwarding everything automatically | also to the gmane.org. | Actually, by forcing the use of a legitimate email address by the subscription | mechanism, we are also forced to have our legitimate email address published on the | public gmane archive. This is a very bad construction! | Any opinions? IMHO as it should be. That is: you want people to use a legitimate email address (with the subscription mechanism), and then silently put the full email address on a public archive. Not very nice at all! Especially, many people may think that the subscription protects against abuse by others (it usually does), but the very same people may not even be aware of the fact that lyx makes their email address available to everyone on gmane.org!!! If I was a malicious spam distributor, I would grap a nice collection of legitimate email addresses from gmane; the lyx list in particular is useful, because there all are legitimate email addresses I'm suprised nobody is upset about this!?! Regards, Rob. PS: I wish I could use my anti-spam email address for this, but lyx doesn't allow me. My 'anti-spam' email address bounces back, since it's fake; so all communication should then go via the mailing list and not to me personally. For example, you can find me on the FreeBSD mailing lists (also archived on gmane.org), but only with my anti-spam email address!
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes:
So it is some combination of headers that cause this.
Please try this:
$ cat test.C ; g++ -W -Wall -Iboost -c -o test.o test.C
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
int main() {return 0; }
$
Again, no problem. What else can I do?
Rob.
Mailinglist issue: gmane archive does not hide email addresses
Hi, [EMAIL PROTECTED] mailing list needs subscription (or alternatively a once-only permission granted for sending emails, without the full subscription). Once that is done, all emails to the list are also archived at 1) www.mail-archive.com/[EMAIL PROTECTED] 2) marc.theaimsgroup.com/?l=lyx-devel 3) gmane.org (are there more?) All these archives are publicly available, which means someone can collect the emails from there for third parties spam-junk stuff, if the sender's email address is not hidden; mail-archive and theaimsgroup do this nicely! But here is, I believe, where the trouble with gmane.org starts: all emails are 'as-is' on this archive, nothing is hidden! Which means, it's an excellent source for spam/junk distibutors to add all lyx-devel contributors to their list of email addresses. So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup hiding strategy, is made totally redundant by forwarding everything automatically also to the gmane.org. Actually, by forcing the use of a legitimate email address by the subscription mechanism, we are also forced to have our legitimate email address published on the public gmane archive. This is a very bad construction! Any opinions? Regards, Rob.
Re: boost/cstdint.hpp:121: error
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Does that ring a bell?
Unfortunately not.
We should perhaps try to find a reduced testcase that also fails.
---
#include
int main() {
}
---
Is that enouthg to trigger it?
put the file in a lyx topdir and compile with g++ -W -Wall -Iboost -c
-o test.o test.C
| $ cd
| $ cat test.C
| #include
| int main() { return 0; }
| $ g++33 -W -Wall -Iboost -c -o test.o test.C
| $
| Apparently, no problem!
| I hope that gives a hint, does it?
Yes it might... can you give me the origianl failure report again.
(sorry for making you do the leg work...)
No, not at all. I'm glad you're giving me clear directions, since I have
no idea how to proceed. So, here you go:
source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I.
-I../../../../src -I../../../../boost -I/opt/include -I/usr/local/include -I/usr/X11R6/include
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
/usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/opt/include
-I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
type `long'
Just to clearify, is this on a 32bit or 64bit platform?
CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2612.57-MHz 686-class CPU)
That's 32 bit, right?
Rob.
Re: boost/cstdint.hpp:121: error
| Does that ring a bell?
Unfortunately not.
We should perhaps try to find a reduced testcase that also fails.
---
#include
int main()
{
}
---
Is that enouthg to trigger it?
put the file in a lyx topdir and compile with g++ -W -Wall -Iboost -c
-o test.o test.C
$ cd
$ cat test.C
#include
int main() { return 0; }
$ g++33 -W -Wall -Iboost -c -o test.o test.C
$
Apparently, no problem!
I hope that gives a hint, does it?
Rob.
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | I have these results: | 1) Everything compiles like a charm, when I comment out in | boost/boost/cstdint.hpp this line | // typedef uint64_t uintmax_t; | 2) When I keep the offending typedef line in boost/boost/cstdint.hpp | and comment out in /usr/include/inttypes.h this line: | //typedef __uint64_t uint64_t; | I get another (obvious?) error during the compilation: | [...snip...] | depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ | /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp | /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o | In file included from ../../../../boost/boost/regex/config.hpp:54, | from cpp_regex_traits.cpp:22: | ../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not | declared So commenting out the line in inttypes.h is not the solution. | What else can I do, to clarify this problem? Is __uint64_t a typedef? Or a macro? All I can find, is this in /usr/include/machine/ansi.h: #ifdef __GNUC__ typedef int __attribute__((__mode__(__DI__)))__int64_t; typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t; #else /* LONGLONG */ typedef long long__int64_t; /* LONGLONG */ typedef unsigned long long __uint64_t; #endif There are many other typedefs here (without the #ifdef construct), for example: typedef __signed char __int8_t; typedef unsigned char __uint8_t; typedef short __int16_t; typedef unsigned short __uint16_t; typedef int __int32_t; typedef unsigned int __uint32_t; typedef int __intptr_t; typedef unsigned int__uintptr_t; Does that ring a bell? Rob.
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
Ok, it must be FreeBSD that is the "problem"
Is uintmax_t a macro? Or uint32_t?
Has on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined as in
| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef __uint32_t uint32_t;
| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main()
{}
Where does __uint32_t come from?
All this is going a bit beyond my level of understanding the compilation process.
I have these results:
1) Everything compiles like a charm, when I comment out in
boost/boost/cstdint.hpp this line
// typedef uint64_t uintmax_t;
2) When I keep the offending typedef line in boost/boost/cstdint.hpp
and comment out in /usr/include/inttypes.h this line:
//typedef __uint64_t uint64_t;
I get another (obvious?) error during the compilation:
[...snip...]
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I.
-I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
/usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost
-I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not declared
../../../../boost/boost/cstdint.hpp:117: error: syntax error before `;' token
../../../../boost/boost/cstdint.hpp:118: error: syntax error before `;' token
../../../../boost/boost/cstdint.hpp:121: error: syntax error before `unsigned'
gmake[4]: *** [cpp_regex_traits.lo] Error 1
[.and many more error lines, related to above error]
What else can I do, to clarify this problem?
Regards,
Rob.
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | autogen.sh: | Using autoconf (GNU Autoconf) 2.53 | gmake: | [...snip...] | gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' | source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ | depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ | depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ | /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp | /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o | In file included from ../../../../boost/boost/regex/config.hpp:54, | from cpp_regex_traits.cpp:22: | ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in | type `long' | gmake[4]: *** [cpp_regex_traits.lo] Error 1 | - | FreeBSD 4.10-STABLE i386 | GCC 3.3.4 20040505 (prerelease) [FreeBSD] Ok, it must be FreeBSD that is the "problem" Is uintmax_t a macro? Or uint32_t? Has on FreeBSD changed recently? (upgraded libc perhaps?) What is uintmax_t/uint32_t typdeffed/defined as in This is what I get: $ grep -n uintmax_t /usr/include/inttypes.h $ grep -n uint32_t /usr/include/inttypes.h /usr/include/inttypes.h:18:typedef __uint32_t uint32_t; Is that causing the trouble? Rob.
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: John Levon <[EMAIL PROTECTED]> writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. | I need this, to successfully compile CVS: | Index: boost/boost/cstdint.hpp | === | RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v | retrieving revision 1.5 | diff -u -r1.5 cstdint.hpp | --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 | +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 | @@ -118,7 +118,7 @@ | typedef uint64_t uint_fast64_t; | typedef int64_t intmax_t; | - typedef uint64_t uintmax_t; | +// typedef uint64_t uintmax_t; | # else | Any ideas why this obstructs the compilation? | Compiler: gcc 3.3.4 20040505 (prerelease) I doubt that this has anything to do with the compiler. I do not see the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease. What is the full error message you get? And what kind of system are you compiling on? autogen.sh: Using autoconf (GNU Autoconf) 2.53 gmake: [...snip...] gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src' source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \ depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \ depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \ /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/X11R6/include "-DBOOST_USER_CONFIG=" -g -O -fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o In file included from ../../../../boost/boost/regex/config.hpp:54, from cpp_regex_traits.cpp:22: ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long' gmake[4]: *** [cpp_regex_traits.lo] Error 1 - FreeBSD 4.10-STABLE i386 GCC 3.3.4 20040505 (prerelease) [FreeBSD] Rob.
Re: boost/cstdint.hpp:121: error
Lars Gullik Bjønnes wrote: John Levon <[EMAIL PROTECTED]> writes: | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote: My make of up-to-date LyX-CVS ends with: | Me too (well, something similar) gcc 3.5.0cvs I don't get either. I need this, to successfully compile CVS: Index: boost/boost/cstdint.hpp === RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v retrieving revision 1.5 diff -u -r1.5 cstdint.hpp --- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5 +++ boost/boost/cstdint.hpp 2004/06/02 08:24:38 @@ -118,7 +118,7 @@ typedef uint64_t uint_fast64_t; typedef int64_t intmax_t; - typedef uint64_t uintmax_t; +// typedef uint64_t uintmax_t; # else Any ideas why this obstructs the compilation? Compiler: gcc 3.3.4 20040505 (prerelease) Regards, Rob.
boost/cstdint.hpp:121: error
My make of up-to-date LyX-CVS ends with: In file included from ../../../../boost/boost/regex/config.hpp:54, from cpp_regex_traits.cpp:22: ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long' gmake[4]: *** [cpp_regex_traits.lo] Error 1 This is on FreeBSD (4.10), using Gcc 3.3.4 (20040505). Rob.
Lyx About: license 1995 - 2001 / shouldn't that be 2004?
Sorry, just a rediculous detail. "Help->About LyX...", License tab. Doesn't the LyX Team still have the license/copyrights? Shouldn't that be 2004 then? Cheers, Rob.
./autogen.sh + ./configure problems with 2.57
Hi, ./autogen.sh and ./configure get stuck: --- $ ./autogen.sh Using autoconf (GNU Autoconf) 2.57 Locating GNU m4... /usr/local/bin/gm4 Generate acinclude.m4... done. Building macros... . lib/reLyX done. Building config header template... . autoheader: error: AC_CONFIG_HEADERS not found in configure.ac done. Building Makefile templates... . lib/reLyX done. Building configure... . lib/reLyX done. Building lib/configure ... done. run "./configure ; make" $./configure --prefix=/opt --with-extra-prefix=/usr/local ./configure: line 1309: syntax error near unexpected token `src/config.h' ./configure: line 1309: `AM_CONFIG_HEADER(src/config.h)' $ --- Any idea why this is going wrong? Rob.
Re: pthread problems
Martti Kuparinen wrote: Hi! I'm maintaining lyx on NetBSD. I'm updating our packages to 1.3.4 and while the lyx-xforms package works okay lyx-qt gives me this upon shutdown: LyX: Done! lyx: Error detected by libpthread: Destroying locked mutex. Detected by file "/home/netbsd/src/lib/libpthread/pthread_mutex.c", line 135, function "pthread_mutex_destroy". See pthread(3) for information. Abort trap (core dumped) How should I debug this further? I'll rebuild lyx and submit backtraces from gdb... I remember similar things happened here when I compiled with Qt. I believe it was caused by the Qt libs which were compiled with threads by default from the ports. However, threads are not needed for LyX and thus LyX/Qt developers will say: "get/create Qt libs without threads". At least that how I remember this discussion ended. Keep in mind that I myself am not at all a threads expert! Rob.
Re: Boost, threading and FreeBSD problem
Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | I cannot see any obvious macros to turn on/off, but I'll experiment a | bit. Ok, can you try this patch please. Bingo! Works fine here. Thanks. Rob.
Re: Boost, threading and FreeBSD problem
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | Hi, | There's a problem with threading since recent boost updates in CVS, | at least for my FreeBSD PC. | My make ends with: | [...] | /usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o Floating.o counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o lyxlex_pimpl.o boost.o context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o math.o table.o text.o -L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a ../../boost/libs/regex/src/.libs/libboostregex.a -lz | ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function `boost::re_detail::re_init_threads()': | /home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88: undefined reference to `pthread_mutex_init' | ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function `boost::re_detail::re_free_threads()': | /home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93: undefined reference to `pthread_mutex_destroy' | collect2: ld returned 1 exit status | gmake[4]: *** [tex2lyx] Error 1 | On my FreeBSD PC, there should be something like this set before compilation: | setenv CXXFLAGS -D_THREAD_SAFE | setenv CFLAGS -D_THREAD_SAFE | setenv LDFLAGS -pthread | I suppose this should be added somethere in the autoconf script. I think the correct solution is to set the BOOST provided macro to just turn threading support off. I'll have a look. Lars, at the moment this is the show-stopper on FreeBSD. Am I the only FreeBSD user trying to compile CVS on my PC? Cheers, Rob.
Boost, threading and FreeBSD problem
Hi, There's a problem with threading since recent boost updates in CVS, at least for my FreeBSD PC. My make ends with: [...] /usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o Floating.o counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o lyxlex_pimpl.o boost.o context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o math.o table.o text.o -L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a ../../boost/libs/regex/src/.libs/libboostregex.a -lz ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function `boost::re_detail::re_init_threads()': /home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88: undefined reference to `pthread_mutex_init' ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function `boost::re_detail::re_free_threads()': /home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93: undefined reference to `pthread_mutex_destroy' collect2: ld returned 1 exit status gmake[4]: *** [tex2lyx] Error 1 On my FreeBSD PC, there should be something like this set before compilation: setenv CXXFLAGS -D_THREAD_SAFE setenv CFLAGS -D_THREAD_SAFE setenv LDFLAGS -pthread I suppose this should be added somethere in the autoconf script. Regards, Rob.
Re: FormDocument.C: FD_document_language has no member combox_language
Angus Leeming wrote: Rob Lahaye wrote: Compiling CVS, ends with: [...] FormDocument.C: In member function `virtual void FormDocument::build()': FormDocument.C:270: error: 'struct FD_document_language' has no member named 'combox_language' FormDocument.C:285: error: 'struct FD_document_language' has no I don't have 1.4.x here at work. However, these variables are created by manipulating the output from 'fdesign -convert' using some sed Thanks Angus; I moved my own patched "form_document.fd" out of the way and updated it from CVS. Then all went OK; well, other problems occurred which I'll report next email. Cheers, Rob.
FormDocument.C: FD_document_language has no member combox_language
Hi, Compiling CVS, ends with: [...] FormDocument.C: In member function `virtual void FormDocument::build()': FormDocument.C:270: error: 'struct FD_document_language' has no member named 'combox_language' FormDocument.C:285: error: 'struct FD_document_language' has no member named 'combox_language' FormDocument.C:288: error: 'struct FD_document_language' has no member named 'combox_language' FormDocument.C: In member function `bool FormDocument::language_apply(BufferParams&)': FormDocument.C:975: error: 'struct FD_document_language' has no member named 'combox_language' FormDocument.C: In member function `void FormDocument::language_update(const BufferParams&)': FormDocument.C:1147: error: 'struct FD_document_language' has no member named 'combox_language' gmake[6]: *** [FormDocument.lo] Error 1 I'm using xforms-1.0; is there a conflict here? Rob.
CVS File->New crash; math related
Hi, Maybe Andre knows already; if not: SISSEGV crash occurs after: Start LyX File->New Insert Math File->Close [and Discard Safe] File->New /Bang/ Cheers, Rob.
Crash with mathed
Hi, Current CVS with xforms crashes as follows: Start LyX File->New Insert Math lyx: SIGSEGV signal caught (Sorry can't make a backtrace at this stage). Regards, Rob.
Remove stray "if" in src/frontends/xforms/Makefile.am
Angus,
Apologies for the person-to-person email, but my emails to the devel list
seem to end up in /dev/null :(.
Another patch is needed to src/frontends/xforms/Makefile.am in CVS, to
remove a stray 'if':
Index: src/frontends/xforms/Makefile.am
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/Makefile.am,v
retrieving revision 1.111
diff -u -r1.111 Makefile.am
--- src/frontends/xforms/Makefile.am2003/11/30 17:11:50 1.111
+++ src/frontends/xforms/Makefile.am2003/12/01 07:24:42
@@ -194,7 +194,7 @@
@:
stamp-xpm: lyx_xpm.h-tmp
- if cmp -s $< lyx_xpm.h || {\
+ cmp -s $< lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp $< lyx_xpm.h ;\
}
Cheers,
Rob.
CVS can't compile in xforms directory !?!
Hi,
CVS compilation gets stuck at:
[...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms'
cmp -s lyx_forms.h-tmp lyx_forms.h || {\
rm -f lyx_forms.h ;\
cp lyx_forms.h-tmp lyx_forms.h ;\
}
echo timestamp > stamp-forms
if cmp -s lyx_xpm.h-tmp lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp lyx_xpm.h-tmp lyx_xpm.h ;\
}
/usr/local/bin/bash: -c: line 2: syntax error: unexpected end of file
gmake[4]: *** [stamp-xpm] Error 2
Syntac error? Could it be that you should use "(...)" instead of "{...}" here
for grouping commands?
This is up-to-date LyX-CVS on FreeBSD box.
Rob.
Re: "fdesign -convert form_external.fd}" failed. Please investigate.
Rob Lahaye wrote: > > > This is the end of the 'make' for current LyX/CVS: > Ah, hold on for a moment; this is possibly due to my own changes to form_external.fd! Forgot about that. I'll investigate myself first. Sorry for the noise. Rob.
"fdesign -convert form_external.fd}" failed. Please investigate.
This is the end of the 'make' for current LyX/CVS: [...snip...] /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I./.. -I../../../../src -I.. -I/opt/include -I/usr/local/include -I/usr/X11R6/include -g -O -fno-exceptions -W -Wall -MT form_ert.lo -MD -MP -MF .deps/form_ert.Tpo -c form_ert.C echo timestamp > form_ert.lo /bin/sh ./fdfix.sh form_external.fd In TypeValue [fd_objects.c 634] type is unknown In FindClassStruct [fd_objects.c 124] Can't find class 0 unknown class 0 Segmentation fault (core dumped) "fdesign -convert form_external.fd}" failed. Please investigate. make[6]: *** [form_external.C] Error 1 Is this a bug in LyX or a problem with Xforms? Maybe this form_external.fd has been created with a too new/old version of fdesign? I'm using xforms version 1.0.2, but I don't think that fdesign differs from the latest official release, or has it? I have then upgraded to latest Xforms/CVS, but still got exactly the same error. Rob.
gmane news server subscriber problems with non-members
Mate, The gmane news server should monitor all messages delivered to the lyx list. The following appears to be a small, but annoying bug in the communication between gmane news server and lyx lists (well, I only verified it with the lyx-devel list): As a non-member of the list, the very first email needs to be verified and confirmed. But after reconfimation, the email will not be forwarded to the gname news server. However, after this action has put me on a whitelist, all consecutive messages from me to the list, will appear on the gname news server. So, it's only the very first one that won't be on gmane. I suppose the reconfirmation exchange to have me on the whitelist, "forgets" the "on-hold" email to also forward to gmane, or something like that. This is really a problem for peole (like me), who do a single test email first, realize it is not working (the test email doesn't appear on gmane) and then give up on it. Not realizing a next email actually would work as expected! Is this easy to fix? Regards, Rob.
Re: Subscribe to devel-mailing-list without receiving emails. Possible?
Rob Lahaye wrote: > Jean-Marc Lasgouttes wrote: > >>It seems to me that, if you are not a subscriber and send a message, >>all you have to do is send a confirmation to some daemon and then you >>will be 'whitelisted' and allowed to post. >> >>Did you try that? >> >>Rob> However, I discovered that my emails do not arrive on the list, >>Rob> unless I am subscribed, which will also deliver all list messages >>Rob> to me by regular email. >> >>And you do not receive a message? > > > So I have now unsubscribed from the lyx-devel mailing list. > This is what happens, when I send a message as non-member: > 1) I receive a message to reconfirm; so I reconfirm that. > 2) I then receive a message that my original message is permitted for lyx-devel. > 3) I do never see my message appear on the lyx-devel gname news server. Ah, false alarm, but there's apparently a little bug in the mailer system. The very first email as non-member (which needs reconfirmation) will not be forwarded to the gname news server. However, after this action has put me on a whitelist, all consecutive messages from me to the list, will appear on the gname news server. So, it's only the very first one that won't be on gmane. I suppose the reconfirmation exchange to have me on the whitelist, "forgets" the "on-hold" email to also forward to gmane, or something like that. Cheers, Rob.
Re: Subscribe to devel-mailing-list without receiving emails. Possible?
Jean-Marc Lasgouttes wrote: > > It seems to me that, if you are not a subscriber and send a message, > all you have to do is send a confirmation to some daemon and then you > will be 'whitelisted' and allowed to post. > > Did you try that? > > Rob> However, I discovered that my emails do not arrive on the list, > Rob> unless I am subscribed, which will also deliver all list messages > Rob> to me by regular email. > > And you do not receive a message? So I have now unsubscribed from the lyx-devel mailing list. This is what happens, when I send a message as non-member: 1) I receive a message to reconfirm; so I reconfirm that. 2) I then receive a message that my original message is permitted for lyx-devel. 3) I do never see my message appear on the lyx-devel gname news server. So, even for this very message, I have no idea whether and when it actually makes it to the list, despite all the confirmation exchange. I therefor send this email also to you personally. Cheers, Rob.
Re: Subscribe to devel-mailing-list without receiving emails. Possible?
Angus Leeming wrote: > Rob Lahaye wrote: > >>Here is what I got, after subscribing, which doesn't tell me >>any webpage for making changes: > > > My apologies then. > > What happens when you send a mail to > [EMAIL PROTECTED] for a help message? Not useful either. If you recommend me to visit certain webpage for this, why not you tell me the webpage directly :) ? However, I think such service doesn't exist for the lyx mailing lists! If so, why not? Rob.
Re: Subscribe to devel-mailing-list without receiving emails. Possible?
Rob Lahaye wrote: Is there a way that allows me to send emails to the devel-list, but that will not send all lyx-devel emails to my subscription address? Jean-Marc Lasgouttes wrote: > It seems to me that, if you are not a subscriber and send a message, > all you have to do is send a confirmation to some daemon and then you > will be 'whitelisted' and allowed to post. > > Did you try that? Oh, maybe I tried once and considered the "confirmation" rather as a rejection. Angus Leeming wrote: Subscribe to the service and the mails that you receive telling you what step to take to confirm the subscription etc will also tell you where to find the web page that provides access to your mail delivery preferences. Go there and select the "do not receive mail" check box. Here is what I got, after subscribing, which doesn't tell me any webpage for making changes: --- Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. Acknowledgment: I have added the address [EMAIL PROTECTED] to the lyx-devel mailing list. Welcome to [EMAIL PROTECTED] Please save this message so that you know the address you are subscribed under, in case you later want to unsubscribe or change your subscription address. --- Administrative commands for the lyx-devel list --- I can handle administrative requests automatically. Please DO NOT SEND THEM TO THE LIST ADDRESS! If you do, I will not see them and other subscribers will be annoyed. Instead, send your message to the correct command address: To subscribe to the list, send a message to: <[EMAIL PROTECTED]> To remove your address from the list, send a message to: <[EMAIL PROTECTED]> Similar addresses exist for the digest list: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To get messages 123 through 145 (a maximum of 100 per request), mail: <[EMAIL PROTECTED]> To get an index with subject and author for messages 123-456 , mail: <[EMAIL PROTECTED]> They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To get an index with subject and author for the last 100-200 messages (this also tells you the latest message number), mail: <[EMAIL PROTECTED]> To receive all messages with the same subject as message 12345, send an empty message to: <[EMAIL PROTECTED]> The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example "[EMAIL PROTECTED]", just add a hyphen and your address (with '=' instead of '@') after the command word: <[EMAIL PROTECTED]> To stop subscription for this address, mail: <[EMAIL PROTECTED]> In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at [EMAIL PROTECTED] Please be patient, my owner is a lot slower than I am --- Enclosed is a copy of the request I received.
Subscribe to devel-mailing-list without receiving emails. Possible?
Hi, I follow the LyX-devel discussion on the gmane news server at the time that it suits me. So I do not want to receive instantly any new email to lyx-devel list. However, I discovered that my emails do not arrive on the list, unless I am subscribed, which will also deliver all list messages to me by regular email. Is there a way that allows me to send emails to the devel-list, but that will not send all lyx-devel emails to my subscription address? (Note that I'm neither interested in subscribing to digest service, since I follow the gname news server for that!). Thanks, Rob.
Re: LyX and European software patents?
Lars Gullik Bjønnes wrote: Rob Lahaye <[EMAIL PROTECTED]> writes: | http://www.gimp.org/ has taken a firm stand against this EU proposal. | How about LyX? I do not know really. But how is the new legislation different from what is already in effect in the USA? Free Software trives there? Found on the FreeBSD mailing list about this in the US: Ryck wrote: > > I've heard that SCO Group has an issue with Linux and is planning to sue > everyone who uses Linux because of the claim that it is using their code. > Does Free BSD have anything to worry about regarding SCO Group and would > Free BSD users be harmless from SCO Group's litigation threats? Scary...matter of time until LyX users are sued ?!?! Cheers, Rob.
gtk: lyx_gui.C::lyx_gui::hexname(EnumLColor): 'lcolor' undeclared
Something like following patch is needed to compile gtk frontend: Index: src/frontends/gtk/lyx_gui.C === RCS file: /cvs/lyx/lyx-devel/src/frontends/gtk/lyx_gui.C,v retrieving revision 1.6 diff -u -r1.6 lyx_gui.C --- src/frontends/gtk/lyx_gui.C 2003/09/15 15:20:17 1.6 +++ src/frontends/gtk/lyx_gui.C 2003/09/17 11:29:02 @@ -22,7 +22,7 @@ #include "debug.h" #include "gettext.h" - +#include "LColor.h" #include "lyx_main.h" #include "lyxrc.h" #include "lyxfont.h" Rob.
gtk & EnumLColor error
Compiling current CVS: [...] In file included from GScreen.C:14: GScreen.h: In member function `virtual WorkArea& GScreen::workarea() const': GScreen.h:42: error: could not convert `this->GScreen::owner_' to `WorkArea&' In file included from GScreen.C:16: GWorkArea.h: In member function `Gdk::Color* ColorCache::getColor(EnumLColor)': GWorkArea.h:32: error: `clr' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `struct EnumLColor' /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h: At global scope: /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h: In instantiation of `std::pair': GWorkArea.h:34: instantiated from here /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h:73: error: ` std::pair<_T1, _T2>::first' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `const struct EnumLColor' GWorkArea.h: In member function `XftColor* ColorCache::getXftColor(EnumLColor) ': GWorkArea.h:37: error: `clr' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `struct EnumLColor' /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h: At global scope: /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h: In instantiation of `std::pair': GWorkArea.h:39: instantiated from here /usr/local/lib/gcc-lib/i386-portbld-freebsd4.8/3.3.1/include/c++/bits/stl_pair.h:73: error: ` std::pair<_T1, _T2>::first' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `const struct EnumLColor' GWorkArea.h: In member function `void ColorCache::cacheColor(EnumLColor, Gdk::Color*)': GWorkArea.h:42: error: `clr' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `struct EnumLColor' GWorkArea.h: In member function `void ColorCache::cacheXftColor(EnumLColor, XftColor*)': GWorkArea.h:46: error: `clr' has incomplete type ../../../src/frontends/Painter.h:20: error: forward declaration of `struct EnumLColor' gmake[5]: *** [GScreen.lo] Error 1
cvsignore
$ cvs update ? install-sh ? missing ? src/lyx-gtk Can someone fix this in the corresponding .cvsignore files? R.
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > > As you see, not different at all... except that use of > lyx::support::abort will not change if ::abort is put in the std > namespace. (or anywhere else...) The patch below makes CVS compile on my FreeBSD system. OK? R. Index: src/boost.C === RCS file: /cvs/lyx/lyx-devel/src/boost.C,v retrieving revision 1.4 diff -u -r1.4 boost.C --- src/boost.C 2003/09/09 17:25:17 1.4 +++ src/boost.C 2003/09/10 12:51:59 @@ -12,6 +12,7 @@ #include "lyx_main.h" #include "debug.h" +#include "support/lyxlib.h" #include @@ -51,7 +52,7 @@ lyxerr << "Assertion triggered in " << function << " by \"" << expr << " in file " << file << ":" << line << endl; emergencyCleanup(); - assert(false); + lyx::support::abort(); }
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: > > | Unless you tell me in more detail what your abort-preference > | actually implies. > > the "problem" with using assert is that it depends on defines: NDEBUG > in particular. > > And what we really want anyway is a plain abort at this point. > > So to just abort is just a way to bypass the outer shell of assert. OK, fine with me. But why "lyx::support::abort"? How does that differ from: #include [...] abort(); For me testing it, should I do something like: #include [...] lyx::support::abort(); Rob.
Re: [Patch] Re: CVS error in GToolbar.C: view_->buffer()->params.getLyXTextClass()
Angus Leeming wrote:
> Rob Lahaye wrote:
>
>>No I don't, because I have no idea what I'm doing.
>>Well, if you insist:
>>
>>ChangeLog:
>>Add a "()" inbetween "params" and ".getLyXTextClass()".
>>
>>Sorry, but that's all I can say; "why and how this has become an error
>>and such-and-such is the fix" should better go in the ChangeLog.
>>Who knows this?
>
>
> Thanks, Rob. It's hard keeping the code free from errors when I can't compile
> it ;-)
Angus,
You applied the patch, didn't you?
You've change only one line, but you forgot two more instances:
Index: src/frontends/gtk/GToolbar.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/gtk/GToolbar.C,v
retrieving revision 1.5
diff -u -r1.5 GToolbar.C
--- src/frontends/gtk/GToolbar.C 2003/09/10 10:09:41 1.5
+++ src/frontends/gtk/GToolbar.C 2003/09/10 12:13:11
@@ -224,7 +224,7 @@
void GToolbar::setLayout(string const & layout)
{
LyXTextClass const & tc =
-view_->buffer()->params.getLyXTextClass();
+view_->buffer()->params().getLyXTextClass();
internal_ = true;
combo_.get_entry()->set_text(tc[layout]->name());
internal_ = false;
@@ -234,7 +234,7 @@
void GToolbar::updateLayoutList()
{
LyXTextClass const & tc =
-view_->buffer()->params.getLyXTextClass();
+view_->buffer()->params().getLyXTextClass();
LyXTextClass::const_iterator end = tc.end();
std::vector strings;
for (LyXTextClass::const_iterator cit = tc.begin();
Rob.
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: >>>>>Rob Lahaye <[EMAIL PROTECTED]> writes: >>>>> >>>>> >>>>>| Should instead a "#include " be added at the top of this file? >>>>> >>>>>Either that or we should use lyx::support::abort instead. >>>>>(I'll probably prefere that.) >>>> >>>| Either way. >>>| As it is now, CVS doesn't compile :(. >>> >>>... on your system. >> > | Have I missed something? > | Is LyX developped for one particular system, or a particular > | subset of systems only? > > No. > > but your statement "CVS doesn't compile", is not true in general, It > is only true on your system and systems like that. (And I have no idea > what kind of system that is.) FreeBSD, using gcc 3.3.1. > I'll certainly help getting things to work for you. (Just forget the > trivial case with the assert.) But the onus will be on you to check > that a certain "fix" resolves the problem. > > In this specific case an include of would (should) work. > Please test it. Ah, sorry, I have caused unnecessary confusion then. I tried the inclusion first and found it solved the problem. I then send the email to the list and suggested the change. However, you preferred "lyx::support::abort", which I do not understand. So it's my working fix against your preference; and yes, "working" applies to my system :). It's then better you choose how to fix it and apply the fix, I think. Unless you tell me in more detail what your abort-preference actually implies. R.
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bj?nnes wrote: > >>>Rob Lahaye <[EMAIL PROTECTED]> writes: >>> >>> >>>| Should instead a "#include " be added at the top of this file? >>> >>>Either that or we should use lyx::support::abort instead. >>>(I'll probably prefere that.) >> > | Either way. > | As it is now, CVS doesn't compile :(. > > ... on your system. Have I missed something? Is LyX developped for one particular system, or a particular subset of systems only? R.
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: > > > | Should instead a "#include " be added at the top of this file? > > Either that or we should use lyx::support::abort instead. > (I'll probably prefere that.) Either way. As it is now, CVS doesn't compile :(. R.
Re: [Patch] Re: CVS error in GToolbar.C: view_->buffer()->params.getLyXTextClass()
Alfredo Braunstein wrote: > Rob Lahaye wrote: > > >>Yes that helps. >>Path below does the trick. Someone willing to apply > > > If you add a ChangeLog entry I can apply it. No I don't, because I have no idea what I'm doing. Well, if you insist: ChangeLog: Add a "()" inbetween "params" and ".getLyXTextClass()". Sorry, but that's all I can say; "why and how this has become an error and such-and-such is the fix" should better go in the ChangeLog. Who knows this? Cheers, Rob.
[Patch] Re: CVS error in GToolbar.C: view_->buffer()->params.getLyXTextClass()
Martin Vermeer wrote:
>
> Probably. Try if replacing params by params() helps.
Yes that helps.
Path below does the trick. Someone willing to apply
Cheers,
Rob.
Index: src/frontends/gtk/GToolbar.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/gtk/GToolbar.C,v
retrieving revision 1.4
diff -u -r1.4 GToolbar.C
--- src/frontends/gtk/GToolbar.C2003/09/09 18:27:22 1.4
+++ src/frontends/gtk/GToolbar.C2003/09/10 08:48:44
@@ -160,7 +160,7 @@
if (layoutGuiName.empty())
return;
LyXTextClass const & tc =
- view_->buffer()->params.getLyXTextClass();
+ view_->buffer()->params().getLyXTextClass();
LyXTextClass::const_iterator end = tc.end();
for (LyXTextClass::const_iterator cit = tc.begin();
@@ -224,7 +224,7 @@
void GToolbar::setLayout(string const & layout)
{
LyXTextClass const & tc =
- view_->buffer()->params.getLyXTextClass();
+ view_->buffer()->params().getLyXTextClass();
internal_ = true;
combo_.get_entry()->set_text(tc[layout]->name());
internal_ = false;
@@ -234,7 +234,7 @@
void GToolbar::updateLayoutList()
{
LyXTextClass const & tc =
- view_->buffer()->params.getLyXTextClass();
+ view_->buffer()->params().getLyXTextClass();
LyXTextClass::const_iterator end = tc.end();
std::vector strings;
for (LyXTextClass::const_iterator cit = tc.begin();
Re: [patch] CVS: assert() error in src/boost.C
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: > > | Index: src/boost.C > | === > | RCS file: /cvs/lyx/lyx-devel/src/boost.C,v > | retrieving revision 1.4 > | diff -u -r1.4 boost.C > | --- src/boost.C 2003/09/09 17:25:17 1.4 > | +++ src/boost.C 2003/09/10 05:06:32 > | @@ -51,7 +51,7 @@ > | lyxerr << "Assertion triggered in " << function << " by \"" << > | expr << " in file " << file << ":" << line << endl; > | emergencyCleanup(); > | - assert(false); > | + BOOST_ASSERT(false); > | } > > This will create a citcular... > > Why is it needed? Aha, so my solution is indeed wrong then. I got the following error message (using gcc 3.3.1): boost.C: In function `void boost::assertion_failed(const char*, const char*, const char*, long int)': boost.C:54: error: `assert' undeclared (first use this function) boost.C:54: error: (Each undeclared identifier is reported only once for each function it appears in.) gmake[3]: *** [boost.o] Error 1 Should instead a "#include " be added at the top of this file? Rob.
CVS error in GToolbar.C: view_->buffer()->params.getLyXTextClass()
GToolbar.C: In member function `void GToolbar::onLayoutSelected()': GToolbar.C:163: error: request for member `getLyXTextClass' in ` this->GToolbar::view_->LyXView::buffer() const()->params', which is of non-aggregate type `' GToolbar.C: In member function `virtual void GToolbar::setLayout(const std::string&)': GToolbar.C:227: error: request for member `getLyXTextClass' in ` this->GToolbar::view_->LyXView::buffer() const()->params', which is of non-aggregate type `' GToolbar.C: In member function `virtual void GToolbar::updateLayoutList()': GToolbar.C:237: error: request for member `getLyXTextClass' in ` this->GToolbar::view_->LyXView::buffer() const()->params', which is of non-aggregate type `' Angus? Is this a result of includes minimalisation? Rob.
[patch] CVS: assert() error in src/boost.C
Index: src/boost.C
===
RCS file: /cvs/lyx/lyx-devel/src/boost.C,v
retrieving revision 1.4
diff -u -r1.4 boost.C
--- src/boost.C 2003/09/09 17:25:17 1.4
+++ src/boost.C 2003/09/10 05:06:32
@@ -51,7 +51,7 @@
lyxerr << "Assertion triggered in " << function << " by \"" <<
expr << " in file " << file << ":" << line << endl;
emergencyCleanup();
- assert(false);
+ BOOST_ASSERT(false);
}
A few lines before, there is:
void emergencyCleanup()
{
static bool didCleanup;
if (didCleanup)
return;
didCleanup = true;
LyX::emergencyCleanup();
}
Wouldn't "static bool didCleanup (false)" be better?
It worries me seeing a test of an uninitialized variable.
Rob.
Re: Removing redundant #includes
Martin Vermeer wrote: > On Sat, Sep 06, 2003 at 09:00:55AM +0900, Rob Lahaye spake thusly: > >>Martin Vermeer wrote: >>>be surprised if the minority platform people (Rob?) will release some >>>profanities. >> >>I am not actively using LyX CVS now. CVS is too unstable for my current work. >>But I keep my CVS tree up-to-date and compile it every now and then. >>I'll report when things break. Is that the kind of profanity you want? > > > Yes please ;-) A comment to the Qt guys related to this: LyX/Qt on FreeBSD does NOT compile out-of-the box. It does that only with a little tweaking of the configure script, which I have reported R.
Re: Removing redundant #includes
Martin Vermeer wrote: > > OK... but this kind of thing should be done by someone with an old and > finicky compiler. You're still in for some qt flak BTW and I wouldn't > be surprised if the minority platform people (Rob?) will release some > profanities. I am not actively using LyX CVS now. CVS is too unstable for my current work. But I keep my CVS tree up-to-date and compile it every now and then. I'll report when things break. Is that the kind of profanity you want? R.
lyx-gtk crash
Hi, LyX/gtk compiles fine here on my FreeBSD box. It looks really good! But it's rather slow. When I start lyx-gtk and then select Help->About LyX... I get a crash: (lyx-gtk:518): libglade-WARNING **: could not find glade file '' Abort (core dumped) The real problem comes when I run lyx-gtk through the debugger gdb, because even gdb itself (version 4.18) crashes :(. Has anyone successfully used gdb on lyx-gtk? The following happens with gdb: $ gdb src/lyx-gtk [...] This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader. (gdb) run Starting program: /home/lahaye/SOFTWARE/lyx-devel/src/lyx-gtk -userdir /tmp/LyX (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...Error while reading shared library symbols: Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Error while reading shared library symbols: Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader. Segmentation fault (core dumped) $ Any ideas? Rob.
LyX and European software patents?
http://www.gimp.org/ has taken a firm stand against this EU proposal. How about LyX? R.
[Patch] Xforms FormShowFile.C
In Xforms version: Tools->Tex Information Double click on e.g. hebtech.cls, will pop up the Show File dialog with "LyX: LyX: hebtech.cls" in the title. This patch removes the redundant "LyX: ". Please apply. Regards, Rob. Index: src/frontends/xforms/FormShowFile.C === RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormShowFile.C,v retrieving revision 1.14 diff -u -r1.14 FormShowFile.C --- src/frontends/xforms/FormShowFile.C 2003/05/22 15:42:50 1.14 +++ src/frontends/xforms/FormShowFile.C 2003/08/23 04:39:25 @@ -32,7 +32,7 @@ // courier medium fl_set_browser_fontstyle(dialog_->browser,FL_FIXED_STYLE); - string const title = "LyX: " + controller().getFileName(); + string const title = controller().getFileName(); setTitle(title); string const contents = controller().getFileContents();
LyX + Qt + FreeBSD: the configure solution
Hi, Being apparently among a minority that tries to compile LyX CVS on a FreeBSD OS, I used to encounter severe difficulties with the Qt build. Reason was that Qt on FreeBSD, by default, comes with threaded libs; and (Free)BSD has a somewhat different way to deal with the threading stuff, which is not in the current configure script: $ man gcc [...] FreeBSD SPECIFIC OPTIONS -pthread Link a user-threaded process against libc_r instead of libc. Ob- jects linked into user-threaded processes should be compiled with -D_THREAD_SAFE. [...] So, on FreeBSD I need the "-pthread" during the ld process for the Qt library libqt-mt (but I don't need the -D_THREAD_SAFE, because LyX is not threaded, or is it?). To let everything go smooth on FreeBSD, I need to set "setenv LDFLAGS -pthread" before running the configure script. Is it possible to include this somehow in the configure script automagically? A test like if ( OS == FreeBSD AND Qt-frontend-needed ) then LDFLAGS = "$LDFLAGS -pthread" In case of compiling both frontends in one make, the Xforms-frontend should not be linked with this -pthread! Any ideas how to do this? --- There's one remaining problem: when I exit LyX/Qt normally, I get a console message "Mutex destroy failure: Device busy" and a SIGSEGV. The backtrace says: Mutex destroy failure: Device busy Program received signal SIGSEGV, Segmentation fault. 0x28ef3aac in .cerror () from /usr/lib/libc.so.4 (gdb) bt #0 0x28ef3aac in .cerror () from /usr/lib/libc.so.4 #1 0x28f6b92b in _exit () from /usr/lib/libc_r.so.4 #2 0x28ef39ab in exit () from /usr/lib/libc.so.4 #3 0x83f8192 in lyx_gui::exit () at lyx_gui.C:188 #4 0x8180380 in QuitLyX () at lyx_cb.C:184 #5 0x81a7c69 in LyXFunc::dispatch (this=0x87d5780, [EMAIL PROTECTED], verbose=true) at lyxfunc.C:1142 #6 0x81a4ab7 in LyXFunc::dispatch (this=0x87d5780, ac=10, verbose=true) at lyxfunc.C:797 #7 0x842ad0c in QtView::activated (this=0xbfbff550, id=10) at QtView.C:146 But I don't think this is LyX related, is it? I will also communicate this with the FreeBSD mailing list. Regards, Rob. PS: This is how I compile successfully on FreeBSD right now: $ setenv LDFLAGS -pthread $ ./configure --prefix=/opt --with-extra-prefix=/opt:/usr/local --with-frontend="xforms qt" [...] Configuration Host type: i386-unknown-freebsd4.8 Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (2.95.4) C++ Compiler flags: -g -O -Wno-non-template-friend -ftemplate-depth-30 -W -Wall Linker flags: -pthread -L/opt/lib -L/usr/local/lib XForms Frontend: libXpm version: 4.11 libforms version: 1.0.2 Qt Frontend: Qt version: 3.1.2 LyX binary dir: /opt/bin LyX files dir: /opt/share/lyx $ gmake [...]
LyX + Qt + FreeBSD: the configure solution
Hi, Being apparently among a minority that tries to compile LyX CVS on a FreeBSD OS, I used to encounter severe difficulties with the Qt build. Reason was that Qt on FreeBSD, by default, comes with threaded libs; and (Free)BSD has a somewhat different way to deal with the threading stuff, which is not in the current configure script: $ man gcc [...] FreeBSD SPECIFIC OPTIONS -pthread Link a user-threaded process against libc_r instead of libc. Ob- jects linked into user-threaded processes should be compiled with -D_THREAD_SAFE. [...] So, on FreeBSD I need the "-pthread" during the ld process for the Qt library libqt-mt (but I don't need the -D_THREAD_SAFE, because LyX is not threaded, or is it?). To let everything go smooth on FreeBSD, I need to set "setenv LDFLAGS -pthread" before running the configure script. Is it possible to include this somehow in the configure script automagically? A test like if ( OS == FreeBSD AND Qt-frontend-needed ) then LDFLAGS = "$LDFLAGS -pthread" In case of compiling both frontends in one make, the Xforms-frontend should not be linked with this -pthread! Any ideas how to do this? --- There's one remaining problem: when I exit LyX/Qt normally, I get a console message "Mutex destroy failure: Device busy" and a SIGSEGV. The backtrace says: Mutex destroy failure: Device busy Program received signal SIGSEGV, Segmentation fault. 0x28ef3aac in .cerror () from /usr/lib/libc.so.4 (gdb) bt #0 0x28ef3aac in .cerror () from /usr/lib/libc.so.4 #1 0x28f6b92b in _exit () from /usr/lib/libc_r.so.4 #2 0x28ef39ab in exit () from /usr/lib/libc.so.4 #3 0x83f8192 in lyx_gui::exit () at lyx_gui.C:188 #4 0x8180380 in QuitLyX () at lyx_cb.C:184 #5 0x81a7c69 in LyXFunc::dispatch (this=0x87d5780, [EMAIL PROTECTED], verbose=true) at lyxfunc.C:1142 #6 0x81a4ab7 in LyXFunc::dispatch (this=0x87d5780, ac=10, verbose=true) at lyxfunc.C:797 #7 0x842ad0c in QtView::activated (this=0xbfbff550, id=10) at QtView.C:146 But I don't think this is LyX related, is it? I will also communicate this with the FreeBSD mailing list. Regards, Rob. PS: This is how I compile successfully on FreeBSD right now: $ setenv LDFLAGS -pthread $ ./configure --prefix=/opt --with-extra-prefix=/opt:/usr/local --with-frontend="xforms qt" [...] Configuration Host type: i386-unknown-freebsd4.8 Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (2.95.4) C++ Compiler flags: -g -O -Wno-non-template-friend -ftemplate-depth-30 -W -Wall Linker flags: -pthread -L/opt/lib -L/usr/local/lib XForms Frontend: libXpm version: 4.11 libforms version: 1.0.2 Qt Frontend: Qt version: 3.1.2 LyX binary dir: /opt/bin LyX files dir: /opt/share/lyx $ gmake [...]
Re: Freshmeat article "GUI Toolkits for the X Window System"
Christian Ridderstr?m wrote: > > Saw a link to this article about different GUI toolkits, maybe someone on > this list is interested in that > > http://freshmeat.net/articles/view/928 Interesting remarks for the XForms folks: FLTK (Fast, Light Tool Kit): FLTK is the C++ successor to the XForms library (which is written in plain C), so I won't cover the latter here. XForms is not Free Software and is free of charge only for non-commercial use. FLTK's strength lies, as its name suggests, in its size and speed. [...snip...] ?? Rob
Re: Invisible font
Garst R. Reese wrote: > > It be more useful if you would tell me what to try with fdesign and > I'll tell you what works. F.ex. using 25.5 or 26 to cover the rounding > errors. 1. cd into your LyX tree 2. Then do "fdesign src/frontends/xforms/forms/form_document.fd &" 3. In the "Control" dialog, find in the "Forms" section the entry "form_document_paper"; click on that one. 4. In the "Form Design" dialog, you see now the paper tab of the LyX document dialog. Click on the field that gives you the font trouble, f.ex. the Bottom input field. When you click on it, it will be surrounded by red lines. 5. Now, in the "Control" dialog on its right, click on "F1 attribs". The "Attributes" dialog pops up. 6. In the "Misc." section of the "Attributes" dialog, you see "Resize [RESIZE_ALL]". You can modify this to "[RESIZE_X]". 7. Click "Accept" in the "Attributes" dialog. In the "Control" dialog, choose "File->Save". Then "File->Exit". Done...recompile...and check. Does it solve the font problem? Rob.
Re: Weird xforms menu problem
John Levon wrote: > Using xforms 1.0.0, when I move to a different submenu, the old submenu > is still shown until a repaint happens .. I also have seen that. It is there for a long time already! Rob.
Re: Invisible font
Garst R. Reese wrote: > Rob Lahaye wrote: > >> 1. Do you have these invisible fonts in all input fields? >>(Dimensions: Width & Height as well as ALL the Margins >>input fields: Top/Bottom/Inner/Outerand how about >>the Headheight/Headsep/Footskip inputs?) > > No. For me it is just Bottom and Headheight Alright. So a rounding error. Now, what happens if you stretch the dialog to larger width and/or height, so that also the troublesome input fields stretch up? Will that remove the invisibility of the fonts? >>I have changed the depth and dpi, to no avail!?! The font in >>the Xforms dialogs remains exactly the same. >>Any ideas? > > I use color depth 16, 74dpi 800x600 zoom 150 > xforms-1.0.2 I have started another X session with "X :1 -query localhost -depth 16 -dpi 74". I did not try to run a 800x600 screen; mine is 1280x1024. I still don't see it. Cheers, Rob.
Re: Invisible font
Jean-Marc Lasgouttes wrote: "David" == David L Johnson <[EMAIL PROTECTED]> writes: > >> >> David> invisible. I can type, and the changes show up on the filename >> David> when I save, for example. Same thing in, say, the Layout -> >> David> Document -> Margins. I can set the margins, but I cannot see >> David> what I type. >> >> Rob, do you think it is possible to improve the situation a bit? Do >> the fields mentioned by David have an unusual height? Hmmm, I have never experienced this myself, even with the Xforms version of about a year ago. I tested the tighter sizes of the input fields and also had no complaints from the list...until now. Since I still do not have this problem, I am at a loss here. Let me try to get things a bit organized and focus on the Document-Layout Paper tab: 1. Do you have these invisible fonts in all input fields? (Dimensions: Width & Height as well as ALL the Margins input fields: Top/Bottom/Inner/Outerand how about the Headheight/Headsep/Footskip inputs?) All the input fields have the same height (25 pix), but differ in width. I wonder if it is related to that, when not all suffer from this 'font invisibility'. 2. What settings could I change on my PC to generate the same problems? I have an LCD flat screen 1280x1024 resolution, with color depth 24 and 90 dpi. I have changed the depth and dpi, to no avail!?! The font in the Xforms dialogs remains exactly the same. Any ideas? Cheers, Rob.
Re: [bug] reference dialog
Garst R. Reese wrote: > Rob Lahaye wrote: > > >>Is this a bug in Xforms perhaps? What Xforms version do you have? >>I myself use CVS/Xforms. >> > > Get real Rob! > It's fine to test a CVS version of a required pkg to check new > features/bugs, but designing with it is begging for problems. I think you misunderstood my remark here. Andre saw a problem with the Reference dialog, which I did not see. That's a bit surprising, so the reason might be the use of different Xforms versions, rather than a coding bug in the controller. Andre uses 0.89; I use CVS. Indeed, both should not be used for 1.4 CVS design.but I like to be able to resize the tabbed-dialogs! Rob.
Re: [bug] reference dialog
Andre Poenitz wrote: > On Wed, Jul 09, 2003 at 08:00:11PM +0900, Rob Lahaye wrote: > >>Andre Poenitz wrote: >> >>>xforms: >>> >>> >>>1. If I open the reference dialog on an existing reference and modify >>>the 'Reference' field manually, the Ok and Apply buttons stay disabled. >> >>I don't see that. Whenever I change something in the dialog, the >>OK/Apply buttons get activated! > > > Not here. Click on Reference inset, start typing. This goes straight in > the 'Reference' field and does not activate the Buttons. Hmmm, I open the dialog; indeed, when I start typing immediately it goes straight into the Reference field. At the first char, the buttons get immediately activated! Is this a bug in Xforms perhaps? What Xforms version do you have? I myself use CVS/Xforms. > >>>2. I am not sure whether I mentioned it lately: The box listing possible >>>targets is >>> >>> _T_O_O_ _S_H_O_R_T_. >>> >>>Scrolling through a few hundred items in chunks of seven is a mess. >> >>Then guys with only 10 or so are stuck with an massive dialog. > > > I don't care for the 'guys with only 10', I care for me. How sweet! As an opensource key developper of LyX, I would expect you to care for things beyond. > The dialog is currently about 0.6 the size of the main LyX window. > Assuming that nobody in their right minds would make the LyX window much > larger then his screen, increasing the dialog be a factor of 1.5 should > not be a problem. That's not the proper patch to the real problem: how do we eliminate the blocking of reducing the initial size of an Xforms dialog?!?! Rob.
Re: [bug] reference dialog
Andre Poenitz wrote: > xforms: > > > 1. If I open the reference dialog on an existing reference and modify > the 'Reference' field manually, the Ok and Apply buttons stay disabled. I don't see that. Whenever I change something in the dialog, the OK/Apply buttons get activated! > 2. I am not sure whether I mentioned it lately: The box listing possible > targets is > >_T_O_O_ _S_H_O_R_T_. > > Scrolling through a few hundred items in chunks of seven is a mess. Then guys with only 10 or so are stuck with an massive dialog. Once again, the problem (and solution) here is that we cannot reduce the size of an Xforms dialog below its initialized size. This means for this dialog: when 7 items are visible, you can stretch it up to what ever size and reduce it back to 7 visible items. With fifty items visible by default, there's no way to reduce the dialog's size to 7 visible items. I once tried to tackle the problem and wanted to find out why reducing the initial size is not possible. Angus gave me a few hints, but I got lost. So, is there anyone who knows how to remove this initial size limitation for LyX/Xforms dialogs? Why is this minimal size there in the first place? Will too small dialogs cause crashes, or what? Cheers, Rob.
Re: gtk patch against 1.4.0cvs on July 1st.
Huang Ying wrote: >>The "mm" extension doesn't seem to have a port on FreeBSD either. >>What is actually the difference between gtk+ and gtkmm ? >> > > gtk+ is a toolkit with C api, and gtkmm is a language binding of gtk+ > that provide the C++ api of gtk+. I remember there is gtkmm 2.0 port in > FreeBSD 4.8, no package, you must compile it from port. The name of port > probably is gtk--2.0, because gtkmm has ever used gtk-- as there name. > Ah, thanks. Indeed there is actually the FreeBSD port "gtk--2". So that must solve the config problem for FreeBSD, I hope. Allow me, though, to be confused why gtk 'minus minus' is the extension for C 'plus plus' !?! A kind of gtk humor? Cheers, Rob.
Re: gtk patch against 1.4.0cvs on July 1st.
Huang Ying wrote:
> diff -u -r -N lyx-1.4.0cvs/configure.ac lyx-1.4.0cvs_gtk/configure.ac
> --- lyx-1.4.0cvs/configure.ac 2003-07-01 17:51:21.0 +0800
> +++ lyx-1.4.0cvs_gtk/configure.ac 2003-07-07 19:15:25.0 +0800
> @@ -182,6 +184,15 @@
> dnl FRONTEND_INCLUDES="-I\${srcdir}/gnome -I\${srcdir}/xforms
> ${GNOME_FRONTEND_CFLAGS} "
> dnl FRONTEND_LIBS="@XPM_LIB@ @XFORMS_LIB@ ${GNOME_FRONTEND_LIBS}"
> dnl ;;
> + gtk)
> + FRONTEND="xforms gtk"
> + FRONTEND_GUILIB="frontends/gtk/libgtk.la"
> + FRONTEND_INCLUDES="-I\${srcdir}/gtk -I\${srcdir}/xforms ${GTK_FRONTEND_CFLAGS}"
> + GTKMM_VERSION=`pkg-config --modversion gtkmm-2.0`
> + LIBGLADEMM_VERSION=`pkg-config --modversion libglademm-2.0`
> + FRONTEND_INFO="libgtkmm version: ${GTKMM_VERSION}\n\
> +libglademm version: ${LIBGLADEMM_VERSION}\n"
> + ;;
The pkg-config commands are most probably not going to work with FreeBSD:
$ pkg-config --modversion gtkmm-2.0
No package 'gtkmm-2.0' found
$ pkg-config --modversion libglademm-2.0
No package 'libglademm-2.0' found
However, instead, this works on FreeBSD:
$ pkg-config --modversion gtk+-2.0
2.2.2
$ pkg-config --modversion libglade-2.0
2.0.1
The "mm" extension doesn't seem to have a port on FreeBSD either.
What is actually the difference between gtk+ and gtkmm ?
Regards,
Rob.
Re: gtk patch against 1.4.0cvs on July 1st.
Huang Ying wrote: >>Any special reason why you put the files in gtk instead of gnome? > > I use the gtkmm and libglademm to implement the frontend, but not > anything about gnome. Because the gnome develop platform is so big > and not as portable as gtk, So I base my work on gtk not gnome. This is a very good approach. I always wondered, whether the LyX/Gnome UI would force me to pull all the massive GNOME rubbish, in orde to use the gtk-port of LyX. Separating gtk-UI from gnome is the best way to go. Similar to not needing KDE for the LyX/Qt UI! The gtk-2 release is already out, though not that widely used. However, an official release with gtk-UI for LyX may take a while; would it be a better idea to base the GUI on gtk-2? Regards, Rob.
Re: xforms input field display bug (Re: [PATCH] Branch/Note, finally:-))
Andre Poenitz wrote: > On Mon, Jul 07, 2003 at 08:37:59AM +0900, Rob Lahaye wrote: > >>Yes, I do remember vague a problem like this, when I was reducing >>the height of all widgets from 30 to 20; 20 was too small, so it >>became 25. The latter seemed to work for all of us. > > > Aerm... did I mention the preamble dialog is _far_ too small? This is not about the size of the whole dialog, but about the width/height of the indivual input fields. Those were 30 pix, which made them look uggly and too bulky. It's now 25 pix. But to your preamble problem: I still don't understand why you have such problems with simply stretching up the preamble dialog in the direction you need (longer lines and/or more lines). Your lines may be 40 chars wide, some elses 80, another one has over 50 lines. For me personally, the preamble dialog is even far too large :). Why is resizing this dialog not good enough for you? Within one LyX session, Xforms remembers the size of the dialog so you only need to resize once. Remember: our Xforms dialogs can resize it to bigger size, but not to smaller size! Cheers, Rob.
Re: xforms input field display bug (Re: [PATCH] Branch/Note, finally:-))
Martin Vermeer wrote: > > You should start up fdesign for, e.g., form_document.fd. Then select > an input box. Then top left corner and width/height are displayed on > the bottom line in the main dialog. You can reduce the height by > dragging a red corner. In the document dialogs, the heights are all 25 > pixels; try reducing it. > > Save, then recompile. Aaah, I see. Yes, I do remember vague a problem like this, when I was reducing the height of all widgets from 30 to 20; 20 was too small, so it became 25. The latter seemed to work for all of us. (I haven't done all dialogs yet, some are still at 30 pix style). So the 25 pix. as it is now, is a sort of workable minimum for all the different fonts people use. Expect problems when you reduce this height. Why these problems, as you discovered, are there, I don't know. But that is more an issue for the xforms list; I think, don't you? Rob.
Re: xforms input field display bug (Re: [PATCH] Branch/Note, finally:-))
Martin Vermeer wrote: > On Fri, Jul 04, 2003 at 09:42:52AM +0900, Rob Lahaye spake thusly: > > Reduce the height of one of your input boxes, until you see the input > text disappear. I still have no idea. How do I reduce the height of an input box? Do you mean "reduce the size of the dialog, such that the height of the input box reduces"? My Document dialog as is, cannot be made smaller, only larger. Should be same for you! What I did: I entered some numbers in the field, and played with the size of the dialoglarger, smaller again etc. All that did not show any unusual behavior. Rob.
Re: [Patch] Re: Preamble dialog
John Levon wrote: > On Thu, Jul 03, 2003 at 03:04:09PM +0200, Andre Poenitz wrote: > >>>Rob Lahaye wrote: >>>If allright, then please apply the patch. >> >>Is fine with me. >> >>Others? > > Yes, fine. Then can someone apply the patch? Thanks. Rob.
Re: xforms input field display bug (Re: [PATCH] Branch/Note, finally :-))
Garst R. Reese wrote: > "Garst R. Reese" wrote: > >>Martin Vermeer wrote: >> >>>BTW, in the current (unpatched) document dialog, some string entry >>>fields don't display their content when you enter it. E.g. in the >>>paper tab the bottom margin field. >>> >>>The reason appears to be that if the field is not high enough for the >>>font to be displayed, it doesn't :-( This behaviour is also reported >>>on the Internet. >>> >>>Does anybody else see this? >> >>Yes! > > Rob, could you take a look at this? > It only affects Bottom and Headheight. Everybody does no have the > problem. I would, if I only understood what this is about. Everything seems to be fine here, so I don't know what to fix. BTW: Martin, what means "(unpatched) document dialog" ? Is that another, older version of the document dialog than I am using? If so, then what to fix, if we talk about two different dialog versions here ?!?! Rob.
[Patch] Re: Preamble dialog
Andre Poenitz wrote: > How can I close the preamble without using the mouse? > > There are neither shortcuts to 'ok' nor to 'cancel'... As for Xforms: Close/Cancel: Escape-key. Apply: Alt-A OK: is indeed missing; how about Alt-O, as does the attached patch? (OK used to be the Enter-key, but that can't be here!) If allright, then please apply the patch. Rob. Index: src/frontends/xforms/ChangeLog === RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/ChangeLog,v retrieving revision 1.777 diff -u -r1.777 ChangeLog --- src/frontends/xforms/ChangeLog 2003/06/30 23:56:11 1.777 +++ src/frontends/xforms/ChangeLog 2003/07/03 12:51:16 @@ -1,3 +1,7 @@ +2003-07-03 Rob Lahaye <[EMAIL PROTECTED]> + + * forms/form_preamble.fd: add Alt-O shortcut to OK button + 2003-07-01 Lars Gullik Bjønnes <[EMAIL PROTECTED]> * introcude namespace lyx::support Index: src/frontends/xforms/forms/form_preamble.fd === RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/forms/form_preamble.fd,v retrieving revision 1.6 diff -u -r1.6 form_preamble.fd --- src/frontends/xforms/forms/form_preamble.fd 2002/10/26 02:19:03 1.6 +++ src/frontends/xforms/forms/form_preamble.fd 2003/07/03 12:51:17 @@ -41,7 +41,7 @@ style: FL_NORMAL_STYLE size: FL_NORMAL_SIZE lcol: FL_BLACK -label: OK +label: OK|#O shortcut: resize: FL_RESIZE_NONE gravity: FL_SouthEast FL_SouthEast
Re: text_funcs.C:80: no match for `_List_iterator & != _List_iterator'
Lars Gullik Bj?nnes wrote: > Rob Lahaye <[EMAIL PROTECTED]> writes: > > | Gcc 2.95 on FreeBSD 4.8 > > Have I said it before? 2.95 is not exactly a good c++ compiler... Yes, you have...almost each time I have such complaints ;) > And IMHO FreeBSD is doing its community a disservice not switching to > a more modern compiler. The stable release is 4.x (4.8 at the moment). Release 5.x will come with gcc 3.2, but is not yet for production use. So, the FreeBSD-stable users are stuck with the more conservative 4.x release until sometime next year, when 5.x will be tagged 'stable'. > That said... we are certainly able to work around this compilers > deficiencies. But I hope Andre can handle that. That would be great! Rob.
text_funcs.C:80: no match for `_List_iterator & != _List_iterator'
The latest CVS doesn't compile: $ gmake [...] g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/opt/include -I/usr/local/include -I/usr/X11R6/include -g -O -Wno-non-template-friend -ftemplate-depth-30 -W -Wall -c -o text_funcs.o `test -f text_funcs.C || echo './'`text_funcs.C text_funcs.C: In function `void cursorLeftOneWord(LyXCursor &, const ParagraphList &)': text_funcs.C:80: no match for `_List_iterator & != _List_iterator' /usr/include/g++/stl_list.h:70: candidates are: bool _List_iterator::operator !=(const _List_iterator &) const lyxfont.h:431: bool operator !=(const LyXFont::FontBits &, const LyXFont::FontBits &) lyxfont.h:446: bool operator !=(const LyXFont &, const LyXFont &) changes.h:40: bool operator !=(const Change &, const Change &) changes.h:119: bool operator !=(const Changes::Range &, const Changes::Range &) lyxcursor.h:130: bool operator !=(const LyXCursor &, const LyXCursor &) text_funcs.C: In function `void cursorRightOneWord(LyXCursor &, const ParagraphList &)': text_funcs.C:102: no match for `_List_iterator != _List_iterator' /usr/include/g++/stl_list.h:70: candidates are: bool _List_iterator::operator !=(const _List_iterator &) const lyxfont.h:431: bool operator !=(const LyXFont::FontBits &, const LyXFont::FontBits &) lyxfont.h:446: bool operator !=(const LyXFont &, const LyXFont &) changes.h:40: bool operator !=(const Change &, const Change &) changes.h:119: bool operator !=(const Changes::Range &, const Changes::Range &) lyxcursor.h:130: bool operator !=(const LyXCursor &, const LyXCursor &) gmake[3]: *** [text_funcs.o] Error 1 Gcc 2.95 on FreeBSD 4.8 Rob.
Re: Paste Recent - wrong
Andre Poenitz wrote: > > Why not just let Lars commit what he wants and John change it later if he > wants etc. There won't be consensus anyway. And some more users on the devel front may comment, since it is then more visible what this discussion is actually all about ;). R.
Re: lyx --export (or File->Export) problem
Kayvan A. Sylvan wrote: > With latest CVS, it looks like File->Export->Postscript does not > copy the resulting file from the temporary directory to the > current directory. > > This is also the case with "lyx --export ps", which means that > the generated file (in the quite transient temporary directory) > is immediately deleted after it is created. > > Can someone please verify? No; everything as usual here. But, eh, File->Export is one of the more dangerous operations in LyX. If the export file already exists, it is simply overwritten, without asking permission to overwrite. This is an extremely bad set-up, to my opinion. Why is it still like that? Rob.
Re: xforms madness ...
Garst R. Reese wrote: > "Garst R. Reese" wrote: > >>John Levon wrote: >> >>>I'm seeing andre's prefs dialog problems. It's completely knackered. >>> >> >>"knackered" is too kind. >> >>Garst > > Checking, I find a lyx version on my box dated May 23 that exhibits > these problems. > May 7 is OK. Rob? Yes, possibly me. Problem is, I don't see this "knackered" things with my Xforms. I'm using Xforms CVS, is that why? Although my polishing patch was quite cute and a lot of work, how about reversing it (below is my orifinal patch; can you reverse it and test). R. RCS file: /home/lyx/cvs/lyx-devel/src/frontends/xforms/forms/form_preferences.fd,v retrieving revision 1.59 retrieving revision 1.60 diff -u -r1.59 -r1.60 --- lyx-devel/src/frontends/xforms/forms/form_preferences.fd2003/04/09 21:34:50 1.59 +++ lyx-devel/src/frontends/xforms/forms/form_preferences.fd2003/05/19 21:32:36 1.60 @@ -9,19 +9,19 @@ === FORM === Name: form_preferences -Width: 470 -Height: 500 +Width: 450 +Height: 445 Number of Objects: 8 class: FL_BOX -type: UP_BOX -box: 0 0 470 500 -boxtype: FL_UP_BOX +type: FLAT_BOX +box: 0 0 450 445 +boxtype: FL_FLAT_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER style: FL_NORMAL_STYLE -size: FL_DEFAULT_SIZE +size: FL_NORMAL_SIZE lcol: FL_BLACK label: shortcut: @@ -34,7 +34,7 @@ class: FL_TABFOLDER type: TOP_TABFOLDER -box: 5 10 455 375 +box: 5 5 440 325 boxtype: FL_FLAT_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_TOP_LEFT @@ -52,7 +52,7 @@ class: FL_BUTTON type: NORMAL_BUTTON -box: 5 390 100 30 +box: 5 335 90 25 boxtype: FL_UP_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -70,7 +70,7 @@ class: FL_BUTTON type: RETURN_BUTTON -box: 170 390 90 30 +box: 170 335 90 25 boxtype: FL_UP_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -88,7 +88,7 @@ class: FL_BUTTON type: NORMAL_BUTTON -box: 270 390 90 30 +box: 265 335 90 25 boxtype: FL_UP_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -106,7 +106,7 @@ class: FL_BUTTON type: NORMAL_BUTTON -box: 370 390 90 30 +box: 360 335 85 25 boxtype: FL_UP_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -124,7 +124,7 @@ class: FL_FRAME type: ENGRAVED_FRAME -box: 0 425 470 1 +box: 0 365 450 1 boxtype: FL_NO_BOX colors: FL_BLACK FL_COL1 alignment: FL_ALIGN_CENTER @@ -142,7 +142,7 @@ class: FL_TEXT type: NORMAL_TEXT -box: 5 430 460 70 +box: 5 375 440 65 boxtype: FL_FLAT_BOX colors: FL_COL1 FL_MCOL alignment: FL_ALIGN_LEFT|FL_ALIGN_INSIDE @@ -159,14 +159,14 @@ === FORM === Name: form_preferences_inner_tab -Width: 455 -Height: 375 +Width: 440 +Height: 325 Number of Objects: 2 class: FL_BOX type: FLAT_BOX -box: 0 0 455 375 +box: 0 0 440 325 boxtype: FL_FLAT_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -184,7 +184,7 @@ class: FL_TABFOLDER type: TOP_TABFOLDER -box: 0 0 455 375 +box: 0 0 440 325 boxtype: FL_FLAT_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_TOP_LEFT @@ -201,14 +201,14 @@ === FORM === Name: form_preferences_screen_fonts -Width: 455 -Height: 375 +Width: 440 +Height: 325 Number of Objects: 21 class: FL_BOX type: FLAT_BOX -box: 0 0 455 375 +box: 0 0 440 325 boxtype: FL_FLAT_BOX colors: FL_COL1 FL_COL1 alignment: FL_ALIGN_CENTER @@ -226,12 +226,30 @@ class: FL_LABELFRAME type: ENGRAVED_FRAME -box: 10 180 285 145 +box: 295 10 140 310 boxtype: FL_NO_BOX colors: FL_BLACK FL_COL1 alignment: FL_ALIGN_TOP_LEFT style: FL_NORMAL_STYLE -size: FL_DEFAULT_SIZE +size: FL_NORMAL_SIZE +lcol: FL_BLACK +label: Size +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: +callback: +argument: + + +class: FL_LABELFRAME +type: ENGRAVED_FRAME +box: 5 180 285 140 +boxtype: FL_NO_BOX +colors: FL_BLACK FL_COL1 +alignment: FL_ALIGN_TOP_LEFT +style: FL_NORMAL_STYLE +size: FL_NORMAL_SIZE lcol: FL_BLACK label: Scale & Resolution shortcut: @@ -244,12 +262,12 @@ class: FL_LABELFRAME type: ENGRAVED_FRAME -box: 10 15 285 155 +box: 5 10 285 160 boxtype: FL_NO_BOX colors: FL_BLACK FL_COL1 alignment: FL_ALIGN_TOP_LEFT style: FL_NORMAL_STYLE -size: FL_DEFAULT_SIZE +size: FL_NORMAL_SIZE lcol: FL_BLACK label: Fonts used shortcut: @@ -262,7 +280,7 @@ class: FL_INPUT type: NORMAL_INPUT -box: 145 25 140 30 +box: 145 25 140 25 boxtype: FL_DOWN_BOX colors: FL_COL1 FL_MCOL alignment: FL_ALIGN_LEFT @@ -280,7 +298,7 @@ class: FL_INPUT type: NORMAL_INPUT -box: 145 60 140 30 +box: 145 60 140 25 boxtype: FL_DOWN_BOX colors: FL_COL1 FL_MCOL alignment: FL_ALIGN_LEFT @@ -298,7 +316,7 @@
Re: dialog sizes
Andre Poenitz wrote: >> On Tue, Jun 17, 2003 at 04:32:45PM +0900, Rob Lahaye wrote: >> > >>>>Andre uses xforms 0.89 and I'm using xforms-CVS. >>>> >>>>Is this size clash only in the preferences dialog? > >> >> >> Yes, it it is there in all parts. Everything seems to be a bit too short. >> Tabular, math panel, File->Open are fine. For some dialogs, stretching the problem should solve the problem. For those dialogs, would "a bit too short" be acceptible with this somewhat old version of xforms? R.
Re: dialog sizes
Andre Poenitz wrote: > On Tue, Jun 17, 2003 at 04:50:31AM +0900, Rob Lahaye wrote: > >>I would like to know why you see these problems with your preferences >>dialog, whereas I do not have that. Is it the window manager; old version >>of Xforms; or what? > > > How can I know. This is xforms 0.89 and fvwm2 2.4.8. Does someone understand why there is this difference in size for Andre's and my preferences dialog (both attached)? Andre uses xforms 0.89 and I'm using xforms-CVS. Is this size clash only in the preferences dialog? (I can't check, since I do not have this size clash!). R. <><>
Re: dialog sizes
Rob Lahaye wrote: Andre Poenitz wrote: Now we have dialogs not even big enough to contain all buttons? I think I was the last person who modified the Xforms preferences layout. I'm willing to fix your problem, but I can't compile CVS at the moment due to a (your?) cast problem to iterators.C. Jean-Marc fixed this. Alright. I'm compiling now. If the cast problem is fixed, then I'll come with a fix for the preferences dialog. I would like to know why you see these problems with your preferences dialog, whereas I do not have that. Is it the window manager; old version of Xforms; or what? Rob. <>
Re: dialog sizes
Andre Poenitz wrote: > On Tue, Jun 17, 2003 at 03:35:47AM +0900, Rob Lahaye wrote: > >>Andre Poenitz wrote: >> >>>Now we have dialogs not even big enough to contain all buttons? >> >>I think I was the last person who modified the Xforms preferences layout. >>I'm willing to fix your problem, but I can't compile CVS at the moment >>due to a (your?) cast problem to iterators.C. > > > Jean-Marc fixed this. Alright. I'm compiling now. If the cast problem is fixed, then I'll come with a fix for the preferences dialog. R.
