> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> That would also mean that LaTeXConfig.lyx would need to be
Georg> created from a Makefile.
No, it will only be created in the user directory. We should not
create anything in the system directory.
JMarc
Am Samstag, 18. März 2006 17:01 schrieb Jean-Marc Lasgouttes:
> Put it in.
Done.
> The better solution will be to run configure.py in userdir
> only.
That would also mean that LaTeXConfig.lyx would need to be created from a
Makefile.
Georg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> lib/configure.py cannot be run if you compile with a fresh
Georg> builddir != srcdir. The reason is that the main configure
Georg> script creates builddir/lib only after trying to run
Georg> lib/configure.py. The attached patch fixes t
Am Samstag, 18. März 2006 16:11 schrieb Angus Leeming:
> Georg Baum <[EMAIL PROTECTED]> writes:
> Just a second... What does
> foo || bar && baz
> mean? Does it mean:
> 1)
> * Run "foo".
> * If "foo" fails, run "bar".
> * If "foo" succeeds, run "baz".
> Or does it mean:
> 2)
>
Georg Baum <[EMAIL PROTECTED]> writes:
>
> lib/configure.py cannot be run if you compile with a fresh builddir !=
> srcdir. The reason is that the main configure script creates builddir/lib
> only after trying to run lib/configure.py.
> The attached patch fixes that. Does anybody know a better
lib/configure.py cannot be run if you compile with a fresh builddir !=
srcdir. The reason is that the main configure script creates builddir/lib
only after trying to run lib/configure.py.
The attached patch fixes that. Does anybody know a better solution? If not
I am going to put this in.
Geor
Andre Poenitz a écrit :
On Mon, Mar 13, 2006 at 02:54:13PM +0100, Abdelrazak Younes wrote:
Coming back to QProcess, I am sure we could use that in a clean manner
by using a virtual base class that would be inherited by a new
ForkedCall that would encapsulate QProcess. If rtti is enabled, the Ly
On Mon, Mar 13, 2006 at 02:54:13PM +0100, Abdelrazak Younes wrote:
> Coming back to QProcess, I am sure we could use that in a clean manner
> by using a virtual base class that would be inherited by a new
> ForkedCall that would encapsulate QProcess. If rtti is enabled, the Lyx
> kernel could ch
Angus Leeming a écrit :
Angus Leeming a écrit :
Ok, you asked... (regular listeners turn off now to prevent boredom from
setting in...)
I did two, separate things.
1. Implement a parser of command-line syntax:
http://www.lyx.org/~leeming/libs/child/doc/html/parse_pseudo_command_line.html
Thi
Abdelrazak Younes wrote:
> Angus Leeming a écrit :
>> Abdelrazak Younes wrote:
We don't need something for process creation, we already have
src/support/forkedcall.[C,h].
>>> Very good.
>>
>> Unfortunately, it doesn't handle IPC through pipes connected to the
>> std{in,out,err} streams.
Angus Leeming a écrit :
Abdelrazak Younes wrote:
We don't need something for process creation, we already have
src/support/forkedcall.[C,h].
Very good.
Unfortunately, it doesn't handle IPC through pipes connected to the
std{in,out,err} streams. I have code to do so in a platform independent
w
Abdelrazak Younes wrote:
>> We don't need something for process creation, we already have
>> src/support/forkedcall.[C,h].
>
> Very good.
Unfortunately, it doesn't handle IPC through pipes connected to the
std{in,out,err} streams. I have code to do so in a platform independent
way, but it never g
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I don't think so, the configure script was the biggest one. It
Georg> is simply that I have plenty of other things to do...
Good grief.
Georg> However I agree with Abdel that in the case of the converter
Georg> script that is built
Georg Baum a écrit :
Abdelrazak Younes wrote:
I just had a quick look at the code in GraphicsConverter.C". IMHO, it
should be possible to provide the same functionality in C++ with
boost::filesystems and something else to launch external process.
I agree.
I was
going to propose QProcess but
Jean-Marc Lasgouttes wrote:
> Please put it in 1.4 too. Since it is not in use yet, it does not hurt
> (but we keep all versions in sync).
That was my intention. I'll do so now.
> However, I think we should switch
> to this only when we have the code that gets rid of the msys
> dependency.
I a
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> We don't need something for process creation, we already have
> Georg> src/support/forkedcall.[C,h]. What would be needed is some sort
> Georg> of batch command processor that would check
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> We don't need something for process creation, we already have
Georg> src/support/forkedcall.[C,h]. What would be needed is some sort
Georg> of batch command processor that would check the result of a
Georg> command when it is finished
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| I will put this in trunk soon. Shall I also put it in 1.4? The next
| step will then be to ditch the m4 version in trunk.
Lars> No. Trunk only.
Please put it in 1.4 too. Since it is not in use yet, it does not hurt
(but we keep al
Abdelrazak Younes wrote:
> I just had a quick look at the code in GraphicsConverter.C". IMHO, it
> should be possible to provide the same functionality in C++ with
> boost::filesystems and something else to launch external process.
I agree.
> I was
> going to propose QProcess but I guess this i
Georg Baum a écrit :
Am Sonntag, 12. März 2006 19:37 schrieb Abdelrazak Younes:
With qt4 frontend, I have:
The image loader can load the following directly:
bmp, jpeg, jpg, mng, pbm, pgm, png, ppm, xbm, xpm,
Of these, LyX recognises the following formats:
bmp, jpg, jpg, pbm, pgm, png, ppm, xbm,
Am Sonntag, 12. März 2006 19:37 schrieb Abdelrazak Younes:
> With qt4 frontend, I have:
>
> The image loader can load the following directly:
> bmp, jpeg, jpg, mng, pbm, pgm, png, ppm, xbm, xpm,
> Of these, LyX recognises the following formats:
> bmp, jpg, jpg, pbm, pgm, png, ppm, xbm, xpm
>
> So
> IMHO, it would be very good to have this for 1.4.x windows users because
> it would get rid of the Msys dependency (if I understand correctly).
This is the main reason at the beginning. There are conversion scripts
but they can be easily translated to python. The biggest problems is
that there
Angus Leeming a écrit :
Abdelrazak Younes wrote:
Lars Gullik Bjønnes a écrit :
Georg Baum writes:
| I have replaced the m4 version of lib/configure with the python
version | since several weeks now. After fixing some bugs (mainly
typos) it works | fine.
| The attached patch contains these fix
Abdelrazak Younes wrote:
Lars Gullik Bjønnes a écrit :
Georg Baum writes:
| I have replaced the m4 version of lib/configure with the python
version | since several weeks now. After fixing some bugs (mainly
typos) it works | fine.
| The attached patch contains these fixes and makes lib/configur
Lars Gullik Bjønnes a écrit :
Georg Baum <[EMAIL PROTECTED]> writes:
| I have replaced the m4 version of lib/configure with the python version
| since several weeks now. After fixing some bugs (mainly typos) it works
| fine.
| The attached patch contains these fixes and makes lib/configure.py
Georg Baum <[EMAIL PROTECTED]> writes:
| I have replaced the m4 version of lib/configure with the python version
| since several weeks now. After fixing some bugs (mainly typos) it works
| fine.
| The attached patch contains these fixes and makes lib/configure.py a fully
| working replacement o
I have replaced the m4 version of lib/configure with the python version
since several weeks now. After fixing some bugs (mainly typos) it works
fine.
The attached patch contains these fixes and makes lib/configure.py a fully
working replacement of lib/configure. It also contains whitespace
adju
27 matches
Mail list logo
