Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes:
>
> I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
> (I guess some C++ afficionados know what this is about, I don't)
>
> __
template
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
// require iterator_traits typedef's
typedef typename std::iterator_traits<_Tp>::difference_type _D; //<<
// __function_requires< _SignedIntegerConcept<_D> >();
typedef typename std::iterator_traits<_Tp>::reference _R;//<<
...
> So the errormessage seems justified and we only have to find
> out which red-dripping includefile defined _D and _R ...
Ok, I found it. It's in /usr/include/ctype.h under the heading
/* backward compatibility */ -- hahaha, what about forward
compability?
Lars, Jean_Marc, what would be the best solution:
1 - change include order (if possible)
2 - undef _D and _R after ctype.h was included
3 - make a patch for Boost
4 - make a patch for Apples ctype.h
Well, I guess 1) might not work and 4) will take to long to
wait for. Let me know if I should test a solution.
/Andreas
Re: Configure problems for lyx-140 on Mac
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes:
>
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | Lars, we need some help from you I guess. The error says:
>
> g++ on darwin is botched?
>
> Turn off concept checking for darwin?
>
> | So the problem is with the new concept check support.
>
> or darwin...
I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
(I guess some C++ afficionados know what this is about, I don't)
__
template
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
// require iterator_traits typedef's
typedef typename std::iterator_traits<_Tp>::difference_type _D;
//<<
// __function_requires< _SignedIntegerConcept<_D> >();
typedef typename std::iterator_traits<_Tp>::reference _R;
//<<
typedef typename std::iterator_traits<_Tp>::pointer _Pt;
typedef typename std::iterator_traits<_Tp>::iterator_category _Cat;
__function_requires< _ConvertibleConcept<
typename std::iterator_traits<_Tp>::iterator_category,
std::input_iterator_tag> >();
++__i;// require preincrement operator
__i++;// require postincrement operator
}
_Tp __i;
};
__
After preprocessing (gcc -E) this looks like this:
__
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
typedef typename std::iterator_traits<_Tp>::difference_type 0x0400L;
//<<<
typedef typename std::iterator_traits<_Tp>::reference 0x0004L; //<<<
typedef typename std::iterator_traits<_Tp>::pointer _Pt;
typedef typename std::iterator_traits<_Tp>::iterator_category _Cat;
__function_requires< _ConvertibleConcept<
typename std::iterator_traits<_Tp>::iterator_category,
std::input_iterator_tag> >();
++__i;
__i++;
}
_Tp __i;
};
__
So the errormessage seems justified and we only have to find
out which red-dripping includefile defined _D and _R ...
(Did I mention recently that I prefer Java over C++ ?)
Cheers
/Andreas
Re: "HOME" on Windows?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Of course, it does require the existence of a .NET development
Angus> environment. I remember downloading one for free from
Angus> Microsoft. Nothing to do with any compiler. I wonder where I
Angus> installed it ;-)
I guess the good-old C version should not be too complicated to guess.
I have a cobol version if you are interested:
http://www.screenio.com/gui_screenio/gs_htmlhelp_subweb/advanced/windows-apis_getfolderpath.htm
Angus> I didn't look at the code, but I did read the comment in
Angus> src/lyxrc.C
Angus> case RC_DOCUMENTPATH: str = _("The default path for
Angus> your documents. An empty value selects the directory LyX was
Angus> started from."); break;
I think this means the CWD of the process that started LyX, not the
binpath.
JMarc
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
Jean-Marc Lasgouttes wrote: > Angus> Ur. I know that this will sound ridiculous in the light of > Angus> all these recent changes to the 13x tree, but I really don't > Angus> want to mess with 13x. I'm pretty sure that none of the changes > Angus> made so far alter *nix behaviour at all. I'd suspect that the > Angus> danger of that happening inadvertently will increase if we > Angus> start to rearrange existing code rather than speicalise it > Angus> in-place using #ifdef blocks. > > I agree with you. So as long as only 1.3.x is concerned, the patch is > probably OK. I thought you intended to do this to HEAD too. Actually, I'll shove it in as-is to both. That way we'll have a history of how this all came about. > Angus> Incidentally, why isn't this inside some #ifdef MAC_OS block? > Angus> For both 13x and for 14x? > > Angus> // Path of binary/../Resources/ > Angus> searchpath += NormalizePath(AddPath(binpath, "../Resources/") + > Angus> OnlyFilename(binname)) + ';'; > > Because the code is a hack? Because I do not want to have #ifdef in > such a place and the risk of guessing wrongly is ridiculously near to > 0? > > Anyway any attempt to torture a unix-centric code like this one to > work in an OSX or win32 setting leads to horrible hacks... I guess that that is the nature of porting. The hacks go in and then they get refactored into a more elegant encapsulation once the developers have worked out what the hell they need. Do we need an os_mac.C? -- Angus
Re: "HOME" on Windows?
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
>
> Angus> Thank you. Looks like this means Environment.SpecialFolder
> Angus> folder;
>
> This is as long as you program in C#, of course :)
Don't think so. From Jürgen's page:
[C++]
[Serializable]
__value public enum Environment.SpecialFolder
Of course, it does require the existence of a .NET development
environment. I remember downloading one for free from Microsoft. Nothing
to do with any compiler. I wonder where I installed it ;-)
> Angus> // $PREFIX/share/lyx on *nix
> Angus> folder = Environment.SpecialFolder::CommonApplicationData;
> Angus> system_lyxdir = Environment.GetFolderPath(folder) / "lyx";
>
> Yes, or maybe "LyX"
Good.
> Angus> // $HOME/.lyx on *nix folder =
> Angus> Environment.SpecialFolder::ApplicationData;
> Angus> user_lyxdir = Environment.GetFolderPath(folder) / ".lyx";
>
> Why not "LyX" instead of ".lyx"? There is no reason of using this on
> non-unix systems.
Good again.
> Angus> // Defaults to os::binpath() on *nix.
>
> I guess you mean os::homepath().
>
> Angus> folder = Environment.SpecialFolder.Personal;
> Angus> document_path = Environment.GetFolderPath(folder);
I didn't look at the code, but I did read the comment in src/lyxrc.C
case RC_DOCUMENTPATH:
str = _("The default path for your documents. An empty
value selects the directory LyX was started from.");
break;
--
Angus
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Ur. I know that this will sound ridiculous in the light of Angus> all these recent changes to the 13x tree, but I really don't Angus> want to mess with 13x. I'm pretty sure that none of the changes Angus> made so far alter *nix behaviour at all. I'd suspect that the Angus> danger of that happening inadvertently will increase if we Angus> start to rearrange existing code rather than speicalise it Angus> in-place using #ifdef blocks. I agree with you. So as long as only 1.3.x is concerned, the patch is probably OK. I thought you intended to do this to HEAD too. Angus> Incidentally, why isn't this inside some #ifdef MAC_OS block? Angus> For both 13x and for 14x? Angus> // Path of binary/../Resources/ Angus> searchpath += NormalizePath(AddPath(binpath, "../Resources/") + Angus> OnlyFilename(binname)) + ';'; Because the code is a hack? Because I do not want to have #ifdef in such a place and the risk of guessing wrongly is ridiculously near to 0? Anyway any attempt to torture a unix-centric code like this one to work in an OSX or win32 setting leads to horrible hacks... JMarc
Re: "HOME" on Windows?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Thank you. Looks like this means Environment.SpecialFolder Angus> folder; This is as long as you program in C#, of course :) Angus> // $PREFIX/share/lyx on *nix Angus> folder = Environment.SpecialFolder::CommonApplicationData; Angus> system_lyxdir = Environment.GetFolderPath(folder) / "lyx"; Yes, or maybe "LyX" Angus> // $HOME/.lyx on *nix folder = Angus> Environment.SpecialFolder::ApplicationData; Angus> user_lyxdir = Environment.GetFolderPath(folder) / ".lyx"; Why not "LyX" instead of ".lyx"? There is no reason of using this on non-unix systems. Angus> // Defaults to os::binpath() on *nix. I guess you mean os::homepath(). Angus> folder = Environment.SpecialFolder.Personal; Angus> document_path = Environment.GetFolderPath(folder); JMarc
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
Jean-Marc Lasgouttes wrote: > Concerning the removal of .exe, I think it should be done in os_win32. > Actually, removing the .exe in binname_ in os::init() will probably be > enough. I think in the long term, the code that follows symlinks and > looks for .../share/lyx should be moved to os_unix.C. On OSX and Win32 we > ave better way to find the system_lyxdir. > > Angus> Are you happy if I apply this to the 13x tree? > > Yes, unless it is possible to do that in os:: as explained above. Ur. I know that this will sound ridiculous in the light of all these recent changes to the 13x tree, but I really don't want to mess with 13x. I'm pretty sure that none of the changes made so far alter *nix behaviour at all. I'd suspect that the danger of that happening inadvertently will increase if we start to rearrange existing code rather than speicalise it in-place using #ifdef blocks. Ahhh well. Maybe you're right. I see that the patch is wrong anyway in that the '.exe' should also be stripped from fullbinname. Incidentally, why isn't this inside some #ifdef MAC_OS block? For both 13x and for 14x? // Path of binary/../Resources/ searchpath += NormalizePath(AddPath(binpath, "../Resources/") + OnlyFilename(binname)) + ';'; -- Angus
Re: "HOME" on Windows?
Juergen Spitzmueller wrote: >Environment.GetFolderPath(Environment.SpecialFolder.Personal); >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemenvironmentspecialfolderclasstopic.asp > > Jürgen Thank you. Looks like this means Environment.SpecialFolder folder; // $PREFIX/share/lyx on *nix folder = Environment.SpecialFolder::CommonApplicationData; system_lyxdir = Environment.GetFolderPath(folder) / "lyx"; // $HOME/.lyx on *nix folder = Environment.SpecialFolder::ApplicationData; user_lyxdir = Environment.GetFolderPath(folder) / ".lyx"; // Defaults to os::binpath() on *nix. folder = Environment.SpecialFolder.Personal; document_path = Environment.GetFolderPath(folder); -- Angus
Re: Running the lib/configure script on Windows
Ruurd wrotes: - @ echo off rem Configure script for Win32 rem calls msys sh.exe rem written by Ruurd Reitsma echo %0 SET PATH=%~p0..\..\bin;%PATH% echo %PATH% %~p0..\..\bin\sh.exe --login %0 --- This doesn't work when LyX and LaTeX are in different drives. The correct one is - @ echo off rem Configure script for Win32 rem calls msys sh.exe rem written by Ruurd Reitsma echo %0 SET PATH=%~dp0..\..\bin;%PATH% echo %PATH% %~dp0..\..\bin\sh.exe --login %0 --- see http://wiki.lyx.org/pmwiki.php/LyX/WindowsSetup regards Uwe
Re: Configure problems for lyx-140 on Mac
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | Lars, we need some help from you I guess. The error says: Lars> g++ on darwin is botched? Lars> Turn off concept checking for darwin? Maybe. How should that be done? | So the problem is with the new concept check support. Lars> or darwin... Sure, this was not supposed to be a vivious atack against concept checking. JMarc
Re: Running the lib/configure script on Windows
Ruurd Reitsma wrote:
>> Of course, there is a third solution, to rewrite lib/configure as a
>> python script. That would enable us to ditch the OS/2 (legacy and
>> unmaintained) lib/configure.cmd and would move us a step closer to
>> requiring only one scripting language, python, to actually run LyX,
>> rather than the current sh, python, perl combo.
>>
>> However, I don't want to consider this as a solution for either 13x or
>> 14x.
>>
> The current solution/hack in my ´distro´ is a configure.bat, and sh.exe
> stolen from msys.
Hm. Given that you require sh.exe anyway and given also that the OS/2
lib/configure.cmd is way out of date, I think I'll go with the hard-coded
equivalent of `::system("sh \"$system_lyxdir/configure\"");`. I'll scrap
lib/configure.cmd at the same time.
At least it's then explicit that we depend on the presence of sh, not just
here but in the graphics loader too.
Incidentally, when you come to release future distros, the python minidist
that you ship is not up to the task of running the instant preview script
lib/scripts/lyxpreview2ppm.py (1.3.x tree)
http://wiki.lyx.org/pmwiki.php/LyX/InstantPreview
People using instant preview on Windows will require the full python
distribution and will benefit from having the PyWin extension modules also.
--
Angus
Re: Configure problems for lyx-140 on Mac
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes: > | Lars, we need some help from you I guess. The error says: g++ on darwin is botched? Turn off concept checking for darwin? | So the problem is with the new concept check support. or darwin... -- Lgb
Re: "HOME" on Windows?
Jean-Marc Lasgouttes wrote: > PS: incidentally, I have a patch waiting for your comments on the > xforms mailing list. Then I really must fire up the box at home when I get back tonight. -- Angus
Re: Running the lib/configure script on Windows
"Angus Leeming" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Of course, there is a third solution, to rewrite lib/configure as a python > script. That would enable us to ditch the OS/2 (legacy and unmaintained) > lib/configure.cmd and would move us a step closer to requiring only one > scripting language, python, to actually run LyX, rather than the current > sh, python, perl combo. > > However, I don't want to consider this as a solution for either 13x or > 14x. > The current solution/hack in my ´distro´ is a configure.bat, and sh.exe stolen from msys. Ruurd @echo off rem Configure script for Win32 rem calls msys sh.exe rem written by Ruurd Reitsma echo %0 SET PATH=%~p0..\..\bin;%PATH% echo %PATH% %~p0..\..\bin\sh.exe --login %0
Re: "HOME" on Windows?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> However, os::homepath() is used in lots of places, eg to Angus> initialise the above when all else fails. What you're saying is Angus> that 'document_path' on Windows should be initialised to Angus> '$USERPROFILE/My documents' rather than to '$USERPROFILE' on Angus> Windows boxes. Assuming that that 'My documents' directory Angus> exists of course. Yes, I think it should. And I think that all uses of os::homepath should be audited. I am not sure that there is a real os-independent notion of `home'. Angus> I'll try and have a go. Thanks. Angus> Incidentally, I see that you're commenting on these Angus> hypothetical questions, but not on the concrete 'Are you happy Angus> to see this patch committed to the 13x tree' that I ask in Angus> [PATCH 13x, 14x] starting LyX successfully under Windows. I did answer. I am sorry if I seem to answer in a random order... JMarc PS: incidentally, I have a patch waiting for your comments on the xforms mailing list.
Re: LyX + MinGW + MinSYS + GPLed QT/Win32 --- success!
--- Andre Poenitz <[EMAIL PROTECTED]> wrote: > On Tue, Dec 14, 2004 at 12:48:40PM +0100, Jean-Marc Lasgouttes wrote: > > Ruurd> It´s already included in mingw, not in MSVC. > > > > Ahh, OK. I guess it would be a good idea to incorporate patches for > > mingw first, and then msvc. Is that doable? > > Haws anybody ever compiled LyX wuth msvc? Ruurd? How did do get past > ./configure? Created a .vcproj? > > Andre' > Using the MSVC wrapper...(I thought that was clear already???) Ruurd __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
Re: "HOME" on Windows?
Angus Leeming wrote: > However, os::homepath() is used in lots of places, eg to initialise the > above when all else fails. What you're saying is that 'document_path' on > Windows should be initialised to '$USERPROFILE/My documents' rather than > to '$USERPROFILE' on Windows boxes. Assuming that that 'My documents' > directory exists of course. Environment.GetFolderPath(Environment.SpecialFolder.Personal); http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemenvironmentspecialfolderclasstopic.asp Jürgen
Re: Configure problems for lyx-140 on Mac
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes: Lars, we need some help from you I guess. The error says: configure:4923: checking istream usability configure:4936: g++ -c -g -Os -fno-exceptions -W -Wall conftest.cc >&5 In file included from /usr/include/gcc/darwin/3.3/c++/bits/concept_check.h:60, from /usr/include/gcc/darwin/3.3/c++/bits/stl_iterator_base_fun cs.h:68, from /usr/include/gcc/darwin/3.3/c++/bits/stl_algobase.h:74, from /usr/include/gcc/darwin/3.3/c++/memory:54, from /usr/include/gcc/darwin/3.3/c++/string:48, from /usr/include/gcc/darwin/3.3/c++/bits/locale_classes.h:47, from /usr/include/gcc/darwin/3.3/c++/bits/ios_base.h:47, from /usr/include/gcc/darwin/3.3/c++/ios:49, from /usr/include/gcc/darwin/3.3/c++/istream:44, from configure:4987: /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_InputIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:415: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:417: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_ForwardIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:450: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_RandomAccessIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:502: error: parse error before `;' token So the problem is with the new concept check support. JMarc
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> You'll see from the screenshot that there's a placement problem Angus> with the 'menu separator' character, but otherwise all looks Angus> Ok. Ruurd signaled a similar problem which seems to be with all lines drawns with the painter... Could it be that the y axis is in the wrong sense? Angus> The patch replaces all uses of 'slashify_path' with Angus> 'internal_path' and adds the all-important - string tmp = Angus> argv[0]; + string tmp = internal_path(argv[0]); to the Windows Angus> version of os::init. Very good. Concerning the removal of .exe, I think it should be done in os_win32. Actually, removing the .exe in binname_ in os::init() will probably be enough. I think in the long term, the code that follows symlinks and looks for .../share/lyx should be moved to os_unix.C. On OSX and Win32 we ave better way to find the system_lyxdir. Angus> Are you happy if I apply this to the 13x tree? Yes, unless it is possible to do that in os:: as explained above. JMarc
Re: "HOME" on Windows?
Jean-Marc Lasgouttes wrote:
> Angus> On *nix we specify "HOME" with homepath_ = GetEnvPath("HOME");
>
> Angus> On Windows, where $HOME doesn't exist, we currently use:
> Angus> homepath_ = GetEnvPath("HOMEDRIVE") + GetEnvPath("HOMEPATH");
>
> Angus> Trouble is, this doesn't seem very robust. The lyx_init.txt
> Angus> output that I posted earlier this morning indicates that
>
> Angus> HOMEDRIVE=C: HOMEPATH=\ LOGNAME=Angus USERNAME=Angus
> Angus> USERPROFILE=C:\Documents and Settings\Angus
>
> Angus> The question is, where would an intelligent default location
> Angus> for the user .lyx dir be? I'd suggest that it should be
> Angus> C:\Documents and Settings\Angus\.lyx
>
> Angus> That would suggest code: homepath_ = GetEnvPath("USERPROFILE");
>
> I think HOME is used for two unrelated things:
>
> 1/ the user_lyxdir. For windows, this should be something like
> $USERPROFILE/LyX, I think (LyX/Mac already has special code to set
> user_lyxdir, that should probably be generalized and cleaned up).
>
> 2/ the documents home. In windows this should be the 'My Documents'
> folder.
>
> So it is not as simple as replacing HOME with something else.
Hmmm. Isn't the encapsulation already there? In lyx 14x we have
support/path_defines.[Ch]:
std::string const & system_lyxdir();
std::string const & user_lyxdir();
lyxrc.[Ch]:
// The default path for your documents.
// An empty value selects the directory LyX was started from.
std::string document_path;
In 13x, the same variables are present although they are found in diferent
locations.
However, os::homepath() is used in lots of places, eg to initialise the
above when all else fails. What you're saying is that 'document_path' on
Windows should be initialised to '$USERPROFILE/My documents' rather than
to '$USERPROFILE' on Windows boxes. Assuming that that 'My documents'
directory exists of course.
I'll try and have a go.
Incidentally, I see that you're commenting on these hypothetical
questions, but not on the concrete 'Are you happy to see this patch
committed to the 13x tree' that I ask in
[PATCH 13x, 14x] starting LyX successfully under Windows.
--
Angus
Scientific lyxlength?
Dear LyX developers, today I managed to configure and compile latest 1.3.x lyx from CVS. While testing the resulting binary I detected a minor but serious problem: the lyxlength numbers will be emitted to tex in scientific format when for example pt is the unit. So 140pt will be send to LaTeX as 1.4e+02pt and this breaks the LaTeX-compile step. I don't know how to fix this correctly but I'll attach my own solution... Regards, Stephan Index: lyxlength.C === RCS file: /cvs/lyx/lyx-devel/src/lyxlength.C,v retrieving revision 1.26.2.3 diff -u -p -r1.26.2.3 lyxlength.C --- lyxlength.C 2004/12/07 10:48:37 1.26.2.3 +++ lyxlength.C 2004/12/20 14:21:49 @@ -78,7 +78,7 @@ string const LyXLength::asLatexString() buffer << setprecision(2) << val_/100.0 << "\\textheight"; break; default: - buffer << setprecision(2) << val_ << unit_name[unit_]; + buffer << setprecision(2) << setiosflags (std::ios_base::fixed) << val_ << unit_name[unit_]; break; } return STRCONV(buffer.str());
Re: Running the lib/configure script on Windows
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> 2. Start the script as ::system("sh $systemdir/configure");
2 seems to be a good solution.
JMarc
Re: Running the lib/configure script on Windows
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Of course, there is a third solution, to rewrite lib/configure Angus> as a python script. That would enable us to ditch the OS/2 Angus> (legacy and unmaintained) lib/configure.cmd and would move us a Angus> step closer to requiring only one scripting language, python, Angus> to actually run LyX, rather than the current sh, python, perl Angus> combo. This is probably a good idea in the long term. Note also that for the viewers, we should have support for using the viewers defined in the environment. But I am not sure how to do it. JMarc
Re: Running the lib/configure script on Windows
Angus Leeming wrote:
> LyX sometimes tries to run the systemdir configure script as
> ::system("$systemdir/configure");
> See LyX::queryUserLyXDir() (lyx_main.C) and Reconfigure() (lyx_cb.C).
>
> Unfortunately, this doesn't work on Windows. Windows ascertains the type
> of the file simply from its extension, not from the first line
> #! /bin/sh
> magic that works under *nix. Thus, Windows screws up, interpretting the
> configure script as a batch file. See the output of `lyx -dbg init` that
> is stored in the lyx_init.txt file that I posted with the mail entitled:
> [PATCH 13x, 14x] starting LyX successfully under Windows.
>
> Two solutions present themselves.
> 1. Rename lib/configure as lib/configure.sh
> 2. Start the script as
> ::system("sh $systemdir/configure");
>
> I suspect that weird autotool gremlins will jump up and bite me
> if I try (1). I'll try out (2) this evening.
Of course, there is a third solution, to rewrite lib/configure as a python
script. That would enable us to ditch the OS/2 (legacy and unmaintained)
lib/configure.cmd and would move us a step closer to requiring only one
scripting language, python, to actually run LyX, rather than the current
sh, python, perl combo.
However, I don't want to consider this as a solution for either 13x or
14x.
--
Angus
Re: [patch] float -> string #1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> We shouldn't use floats internally. We do need them for diaplay. Lars> Sure LyXLength is a possibility, but if we onle sture the string Lars> so that we can output it later there is perhaps no need? InsetTable stores the width of cells and does use this information to draw itself. At the time when I changed this value from string to LyXLength, it was because the profiler told me to do so... So the poor behaviour of boost::lexical_cast does not seem to be a good reason for reverting this. LyXLength seems to be better in terms of encapsulation, anyway. JMarc
Re: "HOME" on Windows?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On *nix we specify "HOME" with homepath_ = GetEnvPath("HOME");
Angus> On Windows, where $HOME doesn't exist, we currently use:
Angus> homepath_ = GetEnvPath("HOMEDRIVE") + GetEnvPath("HOMEPATH");
Angus> Trouble is, this doesn't seem very robust. The lyx_init.txt
Angus> output that I posted earlier this morning indicates that
Angus> HOMEDRIVE=C: HOMEPATH=\ LOGNAME=Angus USERNAME=Angus
Angus> USERPROFILE=C:\Documents and Settings\Angus
Angus> The question is, where would an intelligent default location
Angus> for the user .lyx dir be? I'd suggest that it should be
Angus> C:\Documents and Settings\Angus\.lyx
Angus> That would suggest code: homepath_ = GetEnvPath("USERPROFILE");
I think HOME is used for two unrelated things:
1/ the user_lyxdir. For windows, this should be something like
$USERPROFILE/LyX, I think (LyX/Mac already has special code to set
user_lyxdir, that should probably be generalized and cleaned up).
2/ the documents home. In windows this should be the 'My Documents'
folder.
So it is not as simple as replacing HOME with something else.
JMarc
Re: "HOME" on Windows?
Lars Gullik Bjønnes wrote:
> | That would suggest code:
> | homepath_ = GetEnvPath("USERPROFILE");
>>
> | Thoughts?
>
> I agree. Should we cater for older windows?
How old is 'older'?
Presumably, the code would become:
homepath_ = GetEnvPath("USERPROFILE");
if (homepath_.empty()) {
// Insert nastiness here.
}
The trouble is that I have no idea what nastiness to insert. Is it
sufficient to use Ruurd's HOMEDRIVE + HOMEPATH combo?
--
Angus
Re: [patch] float -> string #1
Jean-Marc Lasgouttes wrote: > Hmm, I'd rather store LyXLength internally. Not being able to convert > correctly is a poor excuse for storing a string that take time to > parse. > > What about making LyXLength using a float instead of a double? > Wouldn't that be really good enough? I guess the problem remains then (the problem here is that boost::lexical_cast transforms doubles and floats to a string with 9 digits behind the separator; as I wrote in a previous post, there is a workaround from the boost list which lets you set the precision to another fixed value, say: 2; we could do this but I guess Lars has more general reasons for his plans). Jürgen
Re: [patch] float -> string #1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> I think this is the way to go. Store strings internally, only | Lars> use floats (or double preffered) when doing calculations and | Lars> stuff. > | Hmm, I'd rather store LyXLength internally. Not being able to convert | correctly is a poor excuse for storing a string that take time to | parse. > | What about making LyXLength using a float instead of a double? | Wouldn't that be really good enough? We shouldn't use floats internally. Sure LyXLength is a possibility, but if we onle sture the string so that we can output it later there is perhaps no need? -- Lgb
Re: "HOME" on Windows?
Angus Leeming <[EMAIL PROTECTED]> writes:
| On *nix we specify "HOME" with
| homepath_ = GetEnvPath("HOME");
>
| On Windows, where $HOME doesn't exist, we currently use:
| homepath_ = GetEnvPath("HOMEDRIVE") + GetEnvPath("HOMEPATH");
>
| Trouble is, this doesn't seem very robust. The lyx_init.txt output that I
| posted earlier this morning indicates that
>
| HOMEDRIVE=C:
| HOMEPATH=\
| LOGNAME=Angus
| USERNAME=Angus
| USERPROFILE=C:\Documents and Settings\Angus
>
| The question is, where would an intelligent default location for the user
| .lyx dir be? I'd suggest that it should be
| C:\Documents and Settings\Angus\.lyx
>
| That would suggest code:
| homepath_ = GetEnvPath("USERPROFILE");
>
| Thoughts?
I agree. Should we cater for older windows?
--
Lgb
Re: [patch] float -> string #1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think this is the way to go. Store strings internally, only Lars> use floats (or double preffered) when doing calculations and Lars> stuff. Hmm, I'd rather store LyXLength internally. Not being able to convert correctly is a poor excuse for storing a string that take time to parse. What about making LyXLength using a float instead of a double? Wouldn't that be really good enough? JMarc
Re: [patch] float -> string #1
Lars Gullik Bjønnes wrote: > | Comments? > > I think this is the way to go. Store strings internally, only use > floats (or double preffered) when doing calculations and stuff. Fine. Can I commit this one and proceed with the other occurences of floats/doubles? (I'd like to do this step by step, posting small patches to the list). Jürgen
"HOME" on Windows?
On *nix we specify "HOME" with
homepath_ = GetEnvPath("HOME");
On Windows, where $HOME doesn't exist, we currently use:
homepath_ = GetEnvPath("HOMEDRIVE") + GetEnvPath("HOMEPATH");
Trouble is, this doesn't seem very robust. The lyx_init.txt output that I
posted earlier this morning indicates that
HOMEDRIVE=C:
HOMEPATH=\
LOGNAME=Angus
USERNAME=Angus
USERPROFILE=C:\Documents and Settings\Angus
The question is, where would an intelligent default location for the user
.lyx dir be? I'd suggest that it should be
C:\Documents and Settings\Angus\.lyx
That would suggest code:
homepath_ = GetEnvPath("USERPROFILE");
Thoughts?
--
Angus
Re: [patch] float -> string #1
Juergen Spitzmueller <[EMAIL PROTECTED]> writes: | Juergen Spitzmueller wrote: >> > Do we have to use floats for this, or can we just use a string all the >> > time? >> >> I think it will be possible to switch to string in all these cases. >> However, I'd like to proceed in small steps. The attached patch uses >> strings instead of floats for graphics. We have to convert them back to >> double for some calculations, but at least the problem with the decimal >> values is gone. >> >> If you think this is the way to go, I'll proceed with the other float >> occurrences. > | Comments? I think this is the way to go. Store strings internally, only use floats (or double preffered) when doing calculations and stuff. -- Lgb
Running the lib/configure script on Windows
LyX sometimes tries to run the systemdir configure script as
::system("$systemdir/configure");
See LyX::queryUserLyXDir() (lyx_main.C) and Reconfigure() (lyx_cb.C).
Unfortunately, this doesn't work on Windows. Windows ascertains the type
of the file simply from its extension, not from the first line
#! /bin/sh
magic that works under *nix. Thus, Windows screws up, interpretting the
configure script as a batch file. See the output of `lyx -dbg init` that
is stored in the lyx_init.txt file that I posted with the mail entitled:
[PATCH 13x, 14x] starting LyX successfully under Windows.
Two solutions present themselves.
1. Rename lib/configure as lib/configure.sh
2. Start the script as
::system("sh $systemdir/configure");
I suspect that weird autotool gremlins will jump up and bite me
if I try (1). I'll try out (2) this evening.
--
Angus
Re: [patch] forceDefaultParagraphs
Angus Leeming wrote: > Alfredo Braunstein wrote: > >> This patch gets rid of Paragraph::forceDefaultParagraphs (the second user >> of Paragraph::inInset) >> >> The replacement is to call InsetBase::forceDefaultParagraph when the >> inset is available, add to add an aditional flag to OutputParams to be >> passed down in latex() methods, when the inset is not available. > >> Comments? > > What happens when you have a tabular inside a tabular: > > @@ -1963,6 +1963,7 @@ int LyXTabular::TeXRow(ostream & os, row > + OutputParams tmpparams = runparams; > ... > + tmpparams.forceDefaultParagraphs = getPWidth(cell).zero(); > + ret += inset->latex(buf, os, tmpparams); > > shouldn't you have > if (!tmpparams.forceDefaultParagraphs) > tmpparams.forceDefaultParagraphs = getPWidth(cell).zero(); > > ? > I don't think so. forceDefaultParagraphs is about forcing a default layout to paragraphs inside table cells with no width set (probably a latex restriction): I don't think that this should apply recursively. 1.3.x seems to behave like in the patch. (otoh, the difference is = vs |= so it's no big deal) Alfredo
Re: [patch] forceDefaultParagraphs
Alfredo Braunstein wrote: > This patch gets rid of Paragraph::forceDefaultParagraphs (the second user > of Paragraph::inInset) > > The replacement is to call InsetBase::forceDefaultParagraph when the > inset is available, add to add an aditional flag to OutputParams to be > passed down in latex() methods, when the inset is not available. > Comments? What happens when you have a tabular inside a tabular: @@ -1963,6 +1963,7 @@ int LyXTabular::TeXRow(ostream & os, row + OutputParams tmpparams = runparams; ... + tmpparams.forceDefaultParagraphs = getPWidth(cell).zero(); + ret += inset->latex(buf, os, tmpparams); shouldn't you have if (!tmpparams.forceDefaultParagraphs) tmpparams.forceDefaultParagraphs = getPWidth(cell).zero(); ? -- Angus
Re: LFUN_MATH_MODE
Alfredo Braunstein wrote: > Note that Andre did the opposite change recently, maybe he had some reason > to do it. ;-) (cvs says: "fix Â#1736"). But I have no idea. > > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ui/stdmenus.ui.diff?r1 >=1.35&r2=1.36 I see. There is also a check for the argument "on" in math_nestinset.C. I guess Andrà forgot to check for that argument in other places (text3.C et al.). JÃrgen
Re: LFUN_MATH_MODE
Juergen Spitzmueller wrote: > Inserting an inline formula via the menu currently inserts a formula with > the content "on". This is because the menu calls "math-mode on" instead of > "math-mode" (like in 1.3). Is this a typo? > > (The attached patch fixes it) > > JÃrgen Note that Andre did the opposite change recently, maybe he had some reason to do it. ;-) (cvs says: "fix #1736"). But I have no idea. http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ui/stdmenus.ui.diff?r1=1.35&r2=1.36 Alfredo
LFUN_MATH_MODE
Inserting an inline formula via the menu currently inserts a formula with the content "on". This is because the menu calls "math-mode on" instead of "math-mode" (like in 1.3). Is this a typo? (The attached patch fixes it) Jürgen Index: stdmenus.ui === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ui/stdmenus.ui,v retrieving revision 1.36 diff -u -r1.36 stdmenus.ui --- stdmenus.ui 7 Nov 2004 09:39:34 - 1.36 +++ stdmenus.ui 20 Dec 2004 10:58:57 - @@ -275,14 +275,14 @@ End Menu "insert_math" - Item "Inline Formula|I" "math-mode on" + Item "Inline Formula|I" "math-mode" Item "Display Formula|D" "math-display" - Item "Eqnarray Environment|E" "command-sequence math-mode on; math-mutate eqnarray;" - Item "AMS align Environment|a" "command-sequence math-mode on; math-mutate align;" - Item "AMS alignat Environment|t" "command-sequence math-mode on; math-mutate alignat;" - Item "AMS flalign Environment|f" "command-sequence math-mode on; math-mutate flalign;" - Item "AMS gather Environment|g" "command-sequence math-mode on; math-mutate gather;" - Item "AMS multline Environment|m" "command-sequence math-mode on; math-mutate multline;" + Item "Eqnarray Environment|E" "command-sequence math-mode; math-mutate eqnarray;" + Item "AMS align Environment|a" "command-sequence math-mode; math-mutate align;" + Item "AMS alignat Environment|t" "command-sequence math-mode; math-mutate alignat;" + Item "AMS flalign Environment|f" "command-sequence math-mode; math-mutate flalign;" + Item "AMS gather Environment|g" "command-sequence math-mode; math-mutate gather;" + Item "AMS multline Environment|m" "command-sequence math-mode; math-mutate multline;" Separator Item "Array Environment|y" "math-matrix 2 2" Item "Cases Environment|C" "math-insert \cases"
Re: change tracking
Juergen Spitzmueller wrote: > Alfredo Braunstein wrote: >> Nice work fixing this. > > All thanks go to Andrà and you. Actually, the new cursor scheme is really > quite instructive, once you get used to it. > > BTW, how far are we now from a beta release? IMO HEAD is quite usable now, > apart from the inInset crashes. Also, bugzilla does not have any real > critical bugs now. Shouldn't we try to fix the inInset crashes and release I think that there are no critical bugs in Bugzilla because people isn't using it (because it was/is indeed unusable), so: > a beta to get some user feedback? Absolutely. I was trying to fix the inInset problem in the right way: by getting rid of it ;-) There's a patch pending for review and there's still a 1/3 of the work still missing. But this is sort of academical... it may be trivial to find where are we missing the initialization and add it (I think I know where it is in fact); like so we would get rid of the crashes. I think I'll try to do it if it's indeed trivial. I'm sort of out of time momentaneously, but I have in my virtual TODO list: - inInset crashes (easy) - scrollbar problem pointed out by Georg (easy) - gtk scrolling is foobared (easy I hope -- some infinite loop caused by scrollbar feedback) - do something about DEPM: either try to fix it, or convince lyx-devel to remove it in favour of something like horizontal cursor (both are tricky in their own way ;-). Regards, Alfredo
Re: [patch] float -> string #1 (was: Re: [patch] validators for the rest)
Juergen Spitzmueller wrote: > > Do we have to use floats for this, or can we just use a string all the > > time? > > I think it will be possible to switch to string in all these cases. > However, I'd like to proceed in small steps. The attached patch uses > strings instead of floats for graphics. We have to convert them back to > double for some calculations, but at least the problem with the decimal > values is gone. > > If you think this is the way to go, I'll proceed with the other float > occurrences. Comments? Jürgen
Re: change tracking
Alfredo Braunstein wrote: > Nice work fixing this. All thanks go to Andrà and you. Actually, the new cursor scheme is really quite instructive, once you get used to it. BTW, how far are we now from a beta release? IMO HEAD is quite usable now, apart from the inInset crashes. Also, bugzilla does not have any real critical bugs now. Shouldn't we try to fix the inInset crashes and release a beta to get some user feedback? JÃrgen
Re: lyx-devel lib/: ChangeLog Makefile.am
On Fri, 2004-12-17 at 19:13, [EMAIL PROTECTED] wrote: > CVSROOT: /usr/local/lyx/cvsroot > Module name: lyx-devel > Repository: lyx-devel/lib/ > Changes by: [EMAIL PROTECTED] 04/12/17 17:13:27 > > Modified files: > lyx-devel/lib/: ChangeLog Makefile.am > > Log message: > fix Makefile.am after Martin's latest change > > Patches: > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ChangeLog?r1=1.657&r2=1.658 > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/Makefile.am?r1=1.67&r2=1.68 > > Complete Diff: > /usr/bin/cvs -f diff -kk -u -r 1.657 -r 1.658 lib/ChangeLog > /usr/bin/cvs -f diff -kk -u -r 1.67 -r 1.68 lib/Makefile.am > > ___ > Cvslog mailing list > [EMAIL PROTECTED] > http://baywatch.lyx.org/mailman/listinfo/cvslog Ah, thanks JÃrgen. - Martin signature.asc Description: This is a digitally signed message part
Re: change tracking
Juergen Spitzmueller wrote: > Alfredo Braunstein wrote: >> I'd do the following (manual diff): >> >> for (; cur; cur.forwardChar()) >> - Â Â Â Â Â Â Â if (cur.inTexted() && !cur.paragraph().empty() && >> + Â Â Â Â Â Â Â if (cur.inTexted() && cur.pos() != >> cur.paragraph().size() >> && cur.paragraph().lookupChange(cur.pos()) >> != Change::UNCHANGED) >> return true; > > Many thanks, Alfredo. This works. I gonna commit this (I take it that the > cur.pos() != cur.paragraph()size() check makes !cur.paragraph.empty() > redundant?). Exactly, because cur.paragraph().empty() is equivalent to cur.paragraph().size() == 0, and 0 <= cur.pos() <= cur.paragraph().size() always hold (in Texted that is). Nice work fixing this. Regards, Alfredo
Re: change tracking
Alfredo Braunstein wrote: > I'd do the following (manual diff): > > for (; cur; cur.forwardChar()) > - if (cur.inTexted() && !cur.paragraph().empty() && > + if (cur.inTexted() && cur.pos() != cur.paragraph().size() > && cur.paragraph().lookupChange(cur.pos()) > != Change::UNCHANGED) > return true; Many thanks, Alfredo. This works. I gonna commit this (I take it that the cur.pos() != cur.paragraph()size() check makes !cur.paragraph.empty() redundant?). Regards, Jürgen
