On Fri, Jan 07, 2005 at 04:35:38PM +0100, Jean-Marc Lasgouttes wrote:
> > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
>
> >> Your patch does not sound right. It says that under cygwin, all
> >> programs should use dos-style paths. If this is the case, a simple
> >> #ifdef __CYGWIN
Lars Gullik Bjønnes wrote:
> | To recap, on Windows we attempt to execute the lib/configure script as
> | system("start /min sh /configure");
>
> coudn't we just call
>
> system("start /min J:\MinSys\bin/sh lyxdir>/configure");
>
> ??
>
> Where "J:\MinSys\bin\sh
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
There is also the option of not altering the PATH at all and just call
teh binary with a full path.
>>>
>> | Sure, but that won't help me find sh.exe if LyX is installed at
>> | C:\Program Files\LyX\bin and sh.exe is
Lars Gullik Bjønnes wrote:
>>> There is also the option of not altering the PATH at all and just call
>>> teh binary with a full path.
>>
> | Sure, but that won't help me find sh.exe if LyX is installed at
> | C:\Program Files\LyX\bin and sh.exe is in J:\MinSys\bin
>>
> | I do think that a LyXRC va
Lars Gullik Bjønnes wrote:
> |char array[PATH_MAX + 1];
> |FSRefMakePath(&fsref, reinterpret_cast(array), PATH_MAX);
>
> So FSRefMakePath really should have another type.
It's hard to know how native API's are meant to be used when I've never,
ever coded for a Mac and haven't played with one for
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
Rather than hard-code these weird and wonderful additions to PATH, why
don't we define a new LyXRC variable "path_prefix" which will be
prepended to the existing PATH variable when LyX is initialised.
>>>
>> | Wh
Angus Leeming <[EMAIL PROTECTED]> writes:
>> | I think that it's safe to cast, but am I correct?
>> | std::string(reinterpret_cast(application_support));
>>
>> We should try to avoid it.
>
| Googling (strlen FSRefMakePath), I see lots of this sort of code:
>
| char array[PATH_MAX + 1];
| FSR
Lars Gullik Bjønnes wrote:
>>> Rather than hard-code these weird and wonderful additions to PATH, why
>>> don't we define a new LyXRC variable "path_prefix" which will be
>>> prepended to the existing PATH variable when LyX is initialised.
>>
> | Why not require that people set PATH correctly? I fa
Here's the final patch in all its glory, modulo ChangeLog entries. I
haven't managed to break it yet...
Below is what I consider to be an exhaustive set of tests on a PC running
Fedora Core 3. All tests passed.
Jean-Marc, if you're happy with the patch then I'd like to commit it.
That'll make it
Georg Baum <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>
>> Rather than hard-code these weird and wonderful additions to PATH, why
>> don't we define a new LyXRC variable "path_prefix" which will be prepended
>> to the existing PATH variable when LyX is initialised.
>
| Why not require that
Georg Baum wrote:
> See http://bugzilla.lyx.org/show_bug.cgi?id=1459. LyX can't read
>
> \begin{eqnarray}
> \displaystyle 1 & 2
> \end{eqnarray}
>
> It wants
>
> \begin{eqnarray}
> {\displaystyle 1} & 2
> \end{eqnarray}
>
> Otherwise everything after the & is ignored. The above is valid LaTeX.
Andre Poenitz wrote:
>> // The list of possible directories are relative to the path of the LyX
>> binary. list const possible_relative_system_lyxdirs()
>> {
>> list results;
>
> There is not need to prefer a list<> over a vector<> when there are at
> most two elements. On the contrary...
Thanks,
Angus Leeming wrote:
> At the moment, Mac users have their PATH modified so:
>
> string oldpath = GetEnv("PATH");
> string newpath = "PATH=" + oldpath + ":" + binpath + ":";
> newpath +=
>
"/sw/bin:/usr/local/bin:/usr/local/teTeX/bin/powerpc-apple-darwin-current";
> PutEnv(newpath);
> lyxerr
On Mon, Jan 03, 2005 at 01:55:30PM +0100, Jean-Marc Lasgouttes wrote:
> // The list of possible directories are relative to the path of the LyX
> binary.
> list const possible_relative_system_lyxdirs()
> {
> list results;
There is not need to prefer a list<> over a vector<> when there are a
On Mon, Jan 03, 2005 at 05:46:12PM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> On Thu, Nov 25, 2004 at 02:52:58PM +, Angus Leeming wrote:
> >> Actually, it's something of a conscious decision. Andre didn't want
> >> to force the us
Hi Ruurd,
I totally agree with you! However, there are still more issues with the
free
Qt. And, things will probably come up after more rigorous testing. Besides
the font thing, people reported cpu hogging and errors when selecting
text.
Did you compile the library with option "-release"? Sometim
Michael Schmitt wrote:
I can also provide you with a LyX 1.3.6cvs binary but I guess it
is no yet ready for public release (e.g., LyX/Win32 complains
about not being able to write to "/tmp").
Because this directory does not exist and LyX doesn't try and create it.
Create it yourself and things wil
Lars Gullik Bjønnes wrote:
> | Given this, which is MacOS X code to fill 'application_support':
>>
> | unsigned char application_support[PATH_MAX + 1];
> | OSStatus const status_code =
> | FSRefMakePath(&fsref, application_support, PATH_MAX);
>>
> | what's the correct way to create
Kayvan A. Sylvan wrote:
> Here's the latest compile failure:
> Undefined first referenced
> symbol in file
> std::basic_string, std::allocator >
> convert,
Thanks, Kayvan. Here's the patch. Committing now...
--
AngusIndex: src/support/ChangeLog
==
Here's the latest compile failure:
- Forwarded message from Kayvan Sylvan <[EMAIL PROTECTED]> -
From: Kayvan Sylvan <[EMAIL PROTECTED]>
Date: Fri, 7 Jan 2005 02:06:50 -0800 (PST)
To: [EMAIL PROTECTED]
Subject: Output from "cron" command
Your "cron" job on toolsrules
/u/ksylvan/src/lyx-bu
Georg Baum wrote:
>> Rather than hard-code these weird and wonderful additions to PATH, why
>> don't we define a new LyXRC variable "path_prefix" which will be
>> prepended to the existing PATH variable when LyX is initialised.
>
> Why not require that people set PATH correctly? I fail to see why
On Jan 7, 2005, at 10:14 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On Jan 7, 2005, at 4:53 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I didn't have it around, so I recreated it. Now it compiles
On Jan 7, 2005, at 10:39 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On Dec 10, 2004, at 9:49 AM, Jean-Marc Lasgouttes wrote:
However, a possibility would be to remove all this special code for
LyX/Mac in the startup code, and replace it with setti
Angus Leeming wrote:
> Rather than hard-code these weird and wonderful additions to PATH, why
> don't we define a new LyXRC variable "path_prefix" which will be prepended
> to the existing PATH variable when LyX is initialised.
Why not require that people set PATH correctly? I fail to see why set
Jean-Marc Lasgouttes wrote:
> Bennett, I never answered to this message because Angus was busy
> butchering the init process at the same time... Nevertheless, the
> scripts are sound. I propose we return to that when Angus' work has
> landed.
>
> Angus, do you think that we should unconditionally
Angus Leeming <[EMAIL PROTECTED]> writes:
| Given this, which is MacOS X code to fill 'application_support':
>
| unsigned char application_support[PATH_MAX + 1];
| OSStatus const status_code =
| FSRefMakePath(&fsref, application_support, PATH_MAX);
>
| what's the correct way to cre
Given this, which is MacOS X code to fill 'application_support':
unsigned char application_support[PATH_MAX + 1];
OSStatus const status_code =
FSRefMakePath(&fsref, application_support, PATH_MAX);
what's the correct way to create a std::string?
std::string(application_support
> "Kuba" == Kuba Ober <[EMAIL PROTECTED]> writes:
>> I have no idea if Windows shortcuts can be accomodated easily, it
>> would be great if at least the Qt file browser could handle them.
>> Any ideas?
Kuba> IIRC if you don't get too fancy the Qt file browser simply
Kuba> launches a standard
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On Dec 10, 2004, at 9:49 AM, Jean-Marc Lasgouttes wrote:
>> However, a possibility would be to remove all this special code for
>> LyX/Mac in the startup code, and replace it with setting user- and
>> lyx-dir from the script.
Be
> I have no idea if Windows shortcuts can be accomodated easily, it would
> be great if at least the Qt file browser could handle them. Any ideas?
IIRC if you don't get too fancy the Qt file browser simply launches a standard
windows dialog box which IIRC handles shortcuts fine? As long as it re
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
>> Your patch does not sound right. It says that under cygwin, all
>> programs should use dos-style paths. If this is the case, a simple
>> #ifdef __CYGWIN__ could be used to hardcode this into LyX...
Kayvan> No, it's the other way ar
> "Ruurd" == Ruurd Reitsma <[EMAIL PROTECTED]> writes:
Ruurd> "Jean-Marc Lasgouttes" <[EMAIL PROTECTED]> wrote in
Ruurd> message news:[EMAIL PROTECTED]
>> > "Ruurd" == Ruurd Reitsma
Ruurd> <[EMAIL PROTECTED]> writes:
>> Hmm, these values seem very weird to me... I cannot understand how
>>
Hi,
this follows yesterday file format.
The function changed looks for the section's title thus skiping the
paragraph parameters. The new condition is now accurate.
--
José Abílio
Index: LyX.py
===
RCS file: /usr/lo
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On Jan 7, 2005, at 4:53 AM, Jean-Marc Lasgouttes wrote:
>>> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
>>
Bennett> I didn't have it around, so I recreated it. Now it compiles
Bennett> without a problem.
>> Fine, o
Lars Gullik Bjønnes wrote:
> Now we just have to add specialization for the missing functions.
> Put this in convert.C:
>
> template <>
> string convert(unsigned long)
> {
> return lexical_cast(ul);
> }
Sure. I see you've done so already. Thanks.
--
Angus
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I just removed the 'warn'. I can put it back if you
Angus> want, but... <\shrug>
I do not care much. Go for it.
JMarc
> "Ruurd" == Ruurd Reitsma <[EMAIL PROTECTED]> writes:
Ruurd> "Jean-Marc Lasgouttes" <[EMAIL PROTECTED]> wrote in
Ruurd> message news:[EMAIL PROTECTED]
>> > "Ruurd" == Ruurd Reitsma
Ruurd> <[EMAIL PROTECTED]> writes:
>> Ruurd, about your distributions: I seem to remember that LyX/Win
>> 1
On Jan 7, 2005, at 4:53 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I didn't have it around, so I recreated it. Now it compiles
Bennett> without a problem.
Fine, one less problem...
Actually, I spoke too soon. It compiles fine with gcc-3.3, but the
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars, I think you should enable that static_assert in the unspecialised
| convert function. I'm getting link errors here on a 64 bit machine:
No... this is as intended. (and the static assert does not work on gcc 4)
Now we just have to add specializa
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Angus> However, I realize that mine is not the only opinion and that
>> | Angus> the 1.3.x tree is Jean-Marc's dominion. So, Jean-Marc, should I
>> | Angus> leave this functionality as-is, or may I abort() if the
>> | Angu
Lars, I think you should enable that static_assert in the unspecialised
convert function. I'm getting link errors here on a 64 bit machine:
(support/.libstabular.o(.text+0x554):/usr/include/c++/3.3/bits/vector.tcc:150:
undefined reference to `std::basic_string,
std::allocator > convert, std::al
Jean-Marc Lasgouttes wrote:
> Angus> Should I do the same with support/package.C? Ie, pass it
> Angus> LOCALEDIR, LYX_DIR and TOP_SRCDIR through the compiler in 1.3.x
> Angus> and generate it from support/package.C.in in 1.4.x.?
>
> I propose to put these variables in version.C.in, which is alread
Lars Gullik Bjønnes wrote:
> | Angus> However, I realize that mine is not the only opinion and that
> | Angus> the 1.3.x tree is Jean-Marc's dominion. So, Jean-Marc, should I
> | Angus> leave this functionality as-is, or may I abort() if the
> | Angus> user_lyxdir cannot be created?
>>
> | I think
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
| Angus> However, I realize that mine is not the only opinion and that
| Angus> the 1.3.x tree is Jean-Marc's dominion. So, Jean-Marc, should I
| Angus> leave this functionality as-is, or
Angus,
maybe you want to include this at some stage. The procedure is quite simple:
windres -i lyx.rc -o lyx.o
and include lyx.o in the final link step.
Cheers,
Ruurd
begin 666 lyx.ico
M```!``$`(" ```$`& "H# [EMAIL PROTECTED]"@[EMAIL PROTECTED] $`& ``@ P`
M```
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
>
> Angus> So, only the unix flavour is ever invoked (XForms, see) and the
> Angus> function is defined as
>
> Angus> void os::warn(string /*mesg*/) { return;
> Angus> }
>
> Angus> I'd replace it with
"Jean-Marc Lasgouttes" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> > "Ruurd" == Ruurd Reitsma
<[EMAIL PROTECTED]> writes:
>
> Ruurd, about your distributions: I seem to remember that LyX/Win 1.3.3
> was distributed with the docs from the HEAD of lyxdoc, which have been
> updat
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Should I do the same with support/package.C? Ie, pass it
Angus> LOCALEDIR, LYX_DIR and TOP_SRCDIR through the compiler in 1.3.x
Angus> and generate it from support/package.C.in in 1.4.x.?
I propose to put these variables in version
Jean-Marc Lasgouttes wrote:
> Ruurd> Some reverse engineering reveils that the height is substracted
> Ruurd> from the y value.
>
> This looks much better...
>
> Angus, what about checking that in?
Sure. Go for it. (My tree is currently full of package-related stuff.)
--
Angus
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> However, I realize that mine is not the only opinion and that
Angus> the 1.3.x tree is Jean-Marc's dominion. So, Jean-Marc, should I
Angus> leave this functionality as-is, or may I abort() if the
Angus> user_lyxdir cannot be created
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> So, only the unix flavour is ever invoked (XForms, see) and the
Angus> function is defined as
Angus> void os::warn(string /*mesg*/) { return;
Angus> }
Angus> I'd replace it with a call to lyxerr, but currently my tree is
Angus> ra
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I didn't have it around, so I recreated it. Now it compiles
Bennett> without a problem.
Fine, one less problem...
JMarc
Alfredo Braunstein wrote:
> In case someone wonders, I'm slightly homeless for the moment, let alone
> adsl-less... I'm trying to solve this problem ASAP...
I'd concentrate on the home first. Modems tend not to like it when they get
rained on.
> Happy new year everyone (a bit late) ;-)
A happy
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I've fixed the wrong y-values of boundingBox. qt/gpl now gives
Peter> the same as "3.3.3 Win32 Eval". I hope this is a step in the
Peter> right direction.
Thanks a lot, Peter. It seems that it really helps.
JMarc
> "Ruurd" == Ruurd Reitsma <[EMAIL PROTECTED]> writes:
Ruurd> "Jean-Marc Lasgouttes" <[EMAIL PROTECTED]> wrote in
Ruurd> message news:[EMAIL PROTECTED]
>> > "Ruurd" == Ruurd Reitsma
Ruurd> <[EMAIL PROTECTED]> writes:
>> Hmm, these values seem very weird to me... I cannot understand how
>>
In case someone wonders, I'm slightly homeless for the moment, let alone
adsl-less... I'm trying to solve this problem ASAP...
Happy new year everyone (a bit late) ;-)
Alfredo
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| On Thursday 06 January 2005 19:35, Lars Gullik Bjønnes wrote:
>> With gcc 3.3 as with FC3:
>
| FC3 comes with gcc 3.4...
FC2 then.
--
Lgb
> "Ruurd" == Ruurd Reitsma <[EMAIL PROTECTED]> writes:
Ruurd> I totally agree with you! However, there are still more issues
Ruurd> with the free Qt. And, things will probably come up after more
Ruurd> rigorous testing. Besides the font thing, people reported cpu
Ruurd> hogging and errors when
On Thursday 06 January 2005 19:35, Lars Gullik Bjønnes wrote:
> With gcc 3.3 as with FC3:
FC3 comes with gcc 3.4...
--
José Abílio
59 matches
Mail list logo
