On Mon, May 15, 2006 at 11:55:33PM +0200, Jean-Marc Lasgouttes wrote:
> OK, here is what I had in mind. The fixCommand helper looks a bit long
> but this makes its intent clear I think.
>
> How does this fare in windows?
I tested it on cygwin. I only have what I expect to see in the View menu
an
Hi,
I just noticed that LyX 1.4.1 (Win XP) puts the .aspell.en.prepl and
.aspell.en.pws files in the LyX root directory (C:\Program Files\LyX141)
rather than in the user home directory (C:\Documents and Settings\your
name here\Application Data\LyX1.4.x). No big deal, but I was wondering
if t
Joost Verburg <[EMAIL PROTECTED]> writes:
> When I export or preview the DVI output of a document that contains a
> Postscript image, LyX/Win 1.4 always copies this PS image to another
> file with a name that has been generated so that it doesn't contain
> spaces or other special characters.
>
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> That is the plan. I'll send a patch, and we'll see whether
Jean-Marc> it works.
OK, here is what I had in mind. The fixCommand helper looks a bit long
but this makes its intent clear I think.
How does this fare in w
Joost Verburg <[EMAIL PROTECTED]> writes:
>
> Andre Poenitz wrote:
> > Right, and it took two years or so to change that.
> >
> > I don't think you'd be much faster than Angus _even if
> > everybody agreed_.
>
> OK, so the only remaining possibility is to drop Win98/Me support.
In fact, it s
On Mon, May 15, 2006 at 10:11:04PM +0100, Jose' Matos wrote:
> On Monday 15 May 2006 22:00, Enrico Forestieri wrote:
> > But I am a tcsh fellow... (this is becoming quite surreal).
>
> If we had this talk more than 10 years ago I would point you that "*csh
> considered harmful", but since we a
On 5/15/06, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> The new version has just be submitted. I guess you will still have the
> re.sub problem, but linking should be fine.
it breaks here:
OK. I am discussing this with Abdel this morning. It seems that
windows/mingw does not have, or have a diff
On Monday 15 May 2006 22:00, Enrico Forestieri wrote:
> But I am a tcsh fellow... (this is becoming quite surreal).
If we had this talk more than 10 years ago I would point you that "*csh
considered harmful", but since we are not in the 90's I will smile with this
remembrance. ;-)
This is j
The new version has just be submitted. I guess you will still have the
re.sub problem, but linking should be fine.
it breaks here:
g++ -o release\common\support\mkdir.o -c -Iboost -Isrc src\support\mkdir.C
c:/programs/minGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/io.h:
In func
tion `
On Mon, May 15, 2006 at 09:08:30PM +0200, Andre Poenitz wrote:
> On Mon, May 15, 2006 at 02:01:27AM +0200, Enrico Forestieri wrote:
> > > Btw if you prefer "15s startup time + nice scrollbars" over
> > > "<1s startup + ugly scrollbars", I probably can't help you at all.
> >
> > I am with you. I w
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> And "auto" should be set for _all_ platforms when we did not
>> succeed to find a viewer. This auto value will be ignored when it
>> does not make sense.
Bo> Then you would like to differentiate between "" and "auto" for
Bo> other platforms as
it linked and launched!
I am glad to know this. The re.sub was troublesome when I first
tackled it. I guess I need a safer way to do substitution.
thanks for the help here
The new version has just be submitted. I guess you will still have the
re.sub problem, but linking should be fine.
Yo
Bo> Currently, "should not be viewed" is denoted by "" (or possibly
Bo> none), which is *not* os dependent.
It is not "should not be viewed", it is "I did not find a viewer and I
am not under windows".
I am not quite sure, but my understanding is that for many formats
(like the image one), it i
I notice this one only after I test this by myself. Abdel seems to be
using a more decent (?) g++ that is clever enough (like the linux
case) to link against stdc++. What you need to do is add -lstdc++ to
the last step,
it linked and launched!
or wait five more minutes for me to submit a new
v
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Another possibility would be to have a special value like "never"
>> or "noauto" for the viewer meaning we should not make it viewable
>> even if the OS claims it can do it.
Bo> "" means never, "auto" means ...
>> Bo, one thing I do not like i
upgraded to this one (but stull need to comment out the re.sub line)
I will have a look.
now it compiles, but fails during linking:
I notice this one only after I test this by myself. Abdel seems to be
using a more decent (?) g++ that is clever enough (like the linux
case) to link against st
Hi,
When I export or preview the DVI output of a document that contains a
Postscript image, LyX/Win 1.4 always copies this PS image to another
file with a name that has been generated so that it doesn't contain
spaces or other special characters.
Isn't it supposed to keep using the original
Bo Peng wrote:
C:\svn>scons -v
SCons by Steven Knight et al.:
engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on
casablanca
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
I am using 0.96.92. I will have a detailed look at the re.sub part
tonight with win/mingw, but yo
Another possibility would be to have a special value like "never" or
"noauto" for the viewer meaning we should not make it viewable even if
the OS claims it can do it.
"" means never, "auto" means ...
Bo, one thing I do not like in your "auto" approach is that it is
system-dependent. The flagg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> Enrico has seen a long list of unwanted menu items and I guess they
>> are all "viewable"? Your solution does not solve this problem.
Georg> I think it does. We have basicaly two groups of formats:
Georg> Document formats (like tex, ps, d
C:\svn>scons -v
SCons by Steven Knight et al.:
engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
I am using 0.96.92. I will have a detailed look at the re.sub part
tonight with win/mingw, but you may consider upg
Bo Peng wrote:
So, you are under windows, using python2.4, mingw (?) and which scons
version?
C:\svn>scons -v
SCons by Steven Knight et al.:
engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
C:\svn>g++ --versi
On Mon, May 15, 2006 at 02:01:27AM +0200, Enrico Forestieri wrote:
> > Btw if you prefer "15s startup time + nice scrollbars" over
> > "<1s startup + ugly scrollbars", I probably can't help you at all.
>
> I am with you. I would still be using chimera instead of mozilla if
> it had worked. But it
> this works now
and stopped:
env_subst(["release\common\version.C"], ["src\version.C.in"])
File "C:\svn\development\scons\scons_utils.py", line 67, in env_subst
contents = re.sub('@'+k+'@',
env.subst('$'+k).replace('\n',r'\\n\\\n'), cont
ents)
So, you are under windows, using pytho
Bo Peng wrote:
I can not reproduce the problem here. Could you please tell me lyx
rev number,
13848
and platform you are running?
win xp prof with sp2 installed
thanks, edwin
Edwin Leuven wrote:
Can not reproduce this problem. Where do you start scons? You should
either start from the top source directory with
scons -f development/scons/SConstruct ...
this works now
and stopped:
env_subst(["release\common\version.C"], ["src\version.C.in"])
scons: *** [release\c
this works now
Good.
> cd development/scons
> scons
yet this doesn't (is what i was doing)
I can not reproduce the problem here. Could you please tell me lyx
rev number, and platform you are running?
Cheers,
Bo
Bo Peng wrote:
scons: *** Source directory must be under top of build tree.
File "SConscript", line 22, in ?
Can not reproduce this problem. Where do you start scons? You should
either start from the top source directory with
scons -f development/scons/SConstruct ...
this works now
or
cd
scons: *** Source directory must be under top of build tree.
File "SConscript", line 22, in ?
Can not reproduce this problem. Where do you start scons? You should
either start from the top source directory with
scons -f development/scons/SConstruct ...
or
cd development/scons
scons
Bo
Not quite:
msgfmt -V => crash! (it's the test in scons_utils.py)
msgfmt --version" => crash!
D:\cygwin\home\yns\lyx\trunk\po>msgfmt
msgfmt: no input file given
Try `(null) --help' for more information.
But if I do:
D:\cygwin\home\yns\lyx\trunk\po>msgfmt --help
Usage: (null)
Bo Peng a écrit :
D:\cygwin\home\yns\lyx\trunk\po>msgfmt bg.po
D:\cygwin\home\yns\lyx\trunk\po>msgfmt ca.po
D:\cygwin\home\yns\lyx\trunk\po>msgfmt cs.po
Seems to work...
Not quite:
msgfmt -V => crash! (it's the test in scons_utils.py)
msgfmt --version" => crash!
D:\cygwin\hom
If that is OK with you I'd suggest that either you or Jean-Marc apply
Jean-Marcs version of the patch, and I'll work from there. We would live
with may view items, but I will have a patch in the next few days (or the
weekend et the latest).
Since JMarc's version of the patch does not solve every
Bo Peng wrote:
> Let me summarize your logic (correct me if I am wrong):
>
> 1. noview: no view anyway (with or without viewer)
> 2. can view: will show up under view if a viewer is available.
Correct.
> Enrico has seen a long list of unwanted menu items and I guess they
> are all "viewable"?
Bo Peng a écrit :
#include
int main()
{
mkdir("somedir");
}
This does not compile because mkdir is not defined in (it
is defined in my glic extension glibc\sys\stat.h). But it is defined in
:
_CRTIMP int __cdecl mkdir (const char*);
Abdel.
#undef HAVE_MKDIR
But I see that MKDIR_TAKES_ONE_ARG is commented out in scons "config.h":
/* #undef MKDIR_TAKES_ONE_ARG */
Under windows, mkdir should take one arg, so there is something wrong
here. Please check:
line 811 (?) of SConstruct
# MKDIR_TAKES_ONE_ARG
if conf.CheckMkdirOneA
Bo Peng a écrit :
No. Please manually change it, and I will see what is going on.
I guess you should try
scons --config=force fast_start=no
and see the generated config.h.
I done that already, I learn fast man ;-)
Abdel.
Abdelrazak Younes a écrit :
libqt4 was compiled successfully (and very quickly :-)) but I had a
compiling error:
g++ -o release\common\support\path.o -c
-ID:\cygwin\home\yns\lyx\trunk\boost -ID:\cygwin\home\yns\lyx\trunk\src
D:\cygwin\home\yns\lyx\trunk\src\support\path.C
D:\cygwin\home\yns\l
D:\cygwin\home\yns\lyx\trunk\po>msgfmt bg.po
D:\cygwin\home\yns\lyx\trunk\po>msgfmt ca.po
D:\cygwin\home\yns\lyx\trunk\po>msgfmt cs.po
Seems to work...
I will test this at home. I do not seem to have msgfmt installed.
> Anyway, you only need to do 'scons ... qt4' to test the included moc fi
Bo Peng a écrit :
> Yes. It also has some other improvement, like creating prefix
> directory, full locale/gettext support, and some cleaning of code.
Didn't you say you were having a week-end vacation? ;-)
Most of are done on last Friday, and I managed to test it a bit during
the weekend, wit
> Yes. It also has some other improvement, like creating prefix
> directory, full locale/gettext support, and some cleaning of code.
Didn't you say you were having a week-end vacation? ;-)
Most of are done on last Friday, and I managed to test it a bit during
the weekend, without sacrificing pl
Bo Peng a écrit :
Decrease from 20s to 23s? The math seems wrong here :-)
increase of course :-) I have figured out the reason. The patch
disables implicit_cache if fast_start=no. This option is on all the
time before.
Note that fast_start means skip the configure step, and go to the
build ste
Decrease from 20s to 23s? The math seems wrong here :-)
increase of course :-) I have figured out the reason. The patch
disables implicit_cache if fast_start=no. This option is on all the
time before.
Note that fast_start means skip the configure step, and go to the
build step directly, by cach
| Is there any strong opinion against that?
What is the change?
Adding '#include "foo.moc"' at the end of 'foo.C'. This will improve
compile time.
Bo
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Bo Peng a écrit :
| >> > * Adding '#include "foo.moc"' at the end of 'foo.C'
| >> > will reduce compilation times by 30-40% on the
| >> > average. The old scheme will not be supported in Waf
| >> > and i believe scons now supports the foo.moc scheme
Neal Becker <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Neal Becker <[EMAIL PROTECTED]> writes:
| >
| > | Didn't seem to work for me, lots of undefined stuff from boost
| > | filesystem. Is it supposed to work?
| >
| > Yes... kindo... but you have to show the errors you get.
Bo Peng a écrit :
> * Adding '#include "foo.moc"' at the end of 'foo.C'
> will reduce compilation times by 30-40% on the
> average. The old scheme will not be supported in Waf
> and i believe scons now supports the foo.moc scheme
> too.
>
> ## Bo: Does anydoby know this?
We could maybe do that i
Lars Gullik Bjønnes wrote:
> Neal Becker <[EMAIL PROTECTED]> writes:
>
> | Didn't seem to work for me, lots of undefined stuff from boost
> | filesystem. Is it supposed to work?
>
> Yes... kindo... but you have to show the errors you get...
>
Lots of errors like this:
package.C:(.text+0x2284)
If Enrico marks those formats as noview that will not show up in the menu.
What is wrong with that?
Maybe not.
That property can be set by the user, or the installer.
You see, the noview flag has multiple purposes, and I am not 100% sure
if it is safe to turn it on for all formats *excep
Neal Becker <[EMAIL PROTECTED]> writes:
| Didn't seem to work for me, lots of undefined stuff from boost filesystem.
| Is it supposed to work?
Yes... kindo... but you have to show the errors you get...
--
Lgb
On Monday 15 May 2006 14:43, Bo Peng wrote:
> Enrico has seen a long list of unwanted menu items and I guess they
> are all "viewable"? Your solution does not solve this problem.
If Enrico marks those formats as noview that will not show up in the menu.
What is wrong with that?
That property
Bo Peng wrote:
Success:
scons frontend=qt3 prefix=/usr
fedora FC5 x86_64
Didn't seem to work for me, lots of undefined stuff from boost filesystem.
Is it supposed to work?
Your ooffice example would not require any setting by the user: It would be
listed as viewable format, and when ooffice is installed it will be
detected as autoviewable and show up in the menu.
Let me summarize your logic (correct me if I am wrong):
1. noview: no view anyway (with or without vi
Bo Peng wrote:
>> A "" viewer could either mean "don't view this format" or "use the auto
>> viewer". If we make it the latter (as in Jean-Marcs patch) we can use the
>> noview flag that I want to introduce (and that we need anyway to get rid
>> of some hardcoding) to mark those formats that shoul
A "" viewer could either mean "don't view this format" or "use the auto
viewer". If we make it the latter (as in Jean-Marcs patch) we can use the
noview flag that I want to introduce (and that we need anyway to get rid of
some hardcoding) to mark those formats that should not be viewable at all.
I
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> It is the flag thing we already discussed (and I still need to
Georg> merge your comments). That means that the configuration file
Georg> format will change, and that older 1.4.x versions will choke on
Georg> newer configuration files.
I just want to inform you that we have a new crash bug in LyX 1.4.1:
http://bugzilla.lyx.org/show_bug.cgi?id=2597
Jean-Marc Lasgouttes wrote:
> But is this something that could go in 1.4 too? I'd like to have
> autoopen in there in some way.
It is the flag thing we already discussed (and I still need to merge your
comments). That means that the configuration file format will change, and
that older 1.4.x vers
> "Mark" == Kortink, Mark A <[EMAIL PROTECTED]> writes:
Mark> Hi Just visited the www.lyx.org site. The screenshots on aren't
Mark> loading.
Hello,
Could you give an URL where the screenshots are missing?
JMarc
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> No time (it is still weekend :-) to test the patch. But the exact
Bo> reason for the auto entries is to tell lyx we want autoview for
Bo> certain formats, not for all entries with "" viewer.
OK, I understand that better now. In this case, I th
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Enrico Forestieri wrote:
>> With this patch I get much more entries in the View menu. I even
>> get a "View->Plain text" and a "View->LyX" which launches another
>> instance of LyX on a copy of the current file in tmpdir ;-)
Georg> Ig
Bo Peng wrote:
> No time (it is still weekend :-) to test the patch. But the exact
> reason for the auto entries is to tell lyx we want autoview for
> certain formats, not for all entries with "" viewer.
A "" viewer could either mean "don't view this format" or "use the auto
viewer". If we make i
Lv wrote:
> All used to work but do not anymore and I suspect that something was
> replaced during an apt-get upgrade of some libraries it might use.
>
> I could not find any such behavior reported in the buglists.
> If it is known is there a remedy, as this is seemingly a bug.
>
> I uninstalled
Enrico Forestieri wrote:
> With this patch I get much more entries in the View menu. I even get
> a "View->Plain text" and a "View->LyX" which launches another instance
> of LyX on a copy of the current file in tmpdir ;-)
Ignore this for now. I have a nice and clean solution for that, but it sort
64 matches
Mail list logo
