On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Why do I get
| make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
| Making all in filesystem
| /bin/sh: line 1: cd: filesystem: No such file or directory
| even
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Why do I get
| make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
| Making all in filesystem
| /bin/sh: line 1: cd:
On Thu, Feb 05, 2004 at 08:53:54AM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Why do I get
| make[2]: Entering directory
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Feb 05, 2004 at 08:53:54AM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| Why do I get
|
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Feb 05, 2004 at 09:11:49AM +0100, Lars Gullik Bjønnes wrote:
There should be one in lyx-devel/boost/libs/ as well.
So what is wrong in your tree...
| Ok. I removed the boost subtree and cvs up'd. Its there now.
| It was not there after a
On Thu, Feb 05, 2004 at 09:17:38AM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Feb 05, 2004 at 09:11:49AM +0100, Lars Gullik Bjønnes wrote:
There should be one in lyx-devel/boost/libs/ as well.
So what is wrong in your tree...
| Ok. I
Andre Poenitz [EMAIL PROTECTED] writes:
| I am through through the whole autogen/configure/make cycle now and it
| works... And I've got now Makefile.am and Makefile.in in
| lib/filesystem...
good.
| Well, no problem anymore.
Wait until my next commit...
--
Lgb
What part of the code is responsible for writing that '00.00.' label
I get with 1.3.x?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
On Thu, Feb 05, 2004 at 10:16:57AM +0100, Andre' Poenitz wrote:
What part of the code is responsible for writing that '00.00.' label
I get with 1.3.x?
Urm.. found it. It's LabelString in the List layout.
No, hte next question: Is this changeable from within a LyX document?
I.e. can I
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Feb 05, 2004 at 10:16:57AM +0100, Andre' Poenitz wrote:
What part of the code is responsible for writing that '00.00.'
label I get with 1.3.x?
Andre Urm.. found it. It's LabelString in the List layout.
Andre No, hte next
Thank you, Jean-Marc.
I've played a bit with coordinates this morning, and tried to bring LyX
again to a working state (coord-wise). I think it can be a good starting
point to choose a right coordinate scheme.
currently is:
- LyXFunc::dispatch uses screen coords (ok)
- BufferView::Pimpl::workAreaDispatch receives
On Thu, Feb 05, 2004 at 12:43:23PM +0100, Alfredo Braunstein wrote:
I've played a bit with coordinates this morning, and tried to bring LyX
again to a working state (coord-wise). I think it can be a good starting
point to choose a right coordinate scheme.
currently is:
-
Andre Poenitz wrote:
On Thu, Feb 05, 2004 at 12:43:23PM +0100, Alfredo Braunstein wrote:
I've played a bit with coordinates this morning, and tried to bring LyX
again to a working state (coord-wise). I think it can be a good starting
point to choose a right coordinate scheme.
currently is:
On Thu, Feb 05, 2004 at 01:13:12PM +0100, Alfredo Braunstein wrote:
I'd think we should settle here for a clear scheme, i.e. either absolute
or screen-relative.
screen-relative is out of the question: it's clearly worse than absolute.
The only things that can use screen-relative coords are
Andre Poenitz wrote:
For internal things LyXText-relative, or par-relative is fine I think (as
long as things remain somewhat private).
Which 'internal things' do you mean?
row/par y-pos. It's faster to keep things relative to par/lyxtext (I think
it has shown on the profiles, right?)
On Thu, Feb 05, 2004 at 01:23:11PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
For internal things LyXText-relative, or par-relative is fine I think (as
long as things remain somewhat private).
Which 'internal things' do you mean?
row/par y-pos. It's faster to keep things
Jean-Marc Lasgouttes wrote:
In gettext.C:locale_init, we do a
setlocale(LC_NUMERIC, C);
which is supposed to reset LC_NUMERIC to a good value. Might it be the
C is not a valid locale for your glibc version? Maybe POSIX is
better? What does 'man setlocale' say?
SuSE seems to prefer
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen OK, I have added a debug message to xforms_helpers which
Juergen outputs the current LC_NUMERIC setting (setlocale
Juergen (LC_NUMERIC,NULL)) while running LyX.
Could you give me the exact patch, so that I can try here in the
Jean-Marc Lasgouttes wrote:
Could you give me the exact patch, so that I can try here in the same
conditions?
Yes. attached (against 1.3.4cvs).
Juergen This is indeeed [EMAIL PROTECTED], so the setlocale(LC_NUMERIC, C)
Juergen call in gettext.C seems to have no effect (or seems to be
Jean-Marc Lasgouttes wrote:
Actually, the call to setlocale(LC_ALL,) in xforms is IMO an
error, since a library should never set the locale like that. I
wonder though whether removing it would break some apps relying on
that. Angus, what do you think of that?
Why not make it configurable,
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote:
Actually, the call to setlocale(LC_ALL,) in xforms is IMO an
error, since a library should never set the locale like that. I
wonder though whether removing it would break some apps relying on
that. Angus, what
I am trying to build lyx 1.3.3 with a qt frontend on cygwin. I got to
the point that qt and lyx both build successfully (no changes to the lyx
sources, and almost none to qt-x11). Qt runs the examples, but lyx dies
before it opens the first window. It says it crashed with a segmentation
fault
Jean-Marc Lasgouttes wrote:
Actually, the call to setlocale(LC_ALL,) in xforms is IMO an
error, since a library should never set the locale like that. I
wonder though whether removing it would break some apps relying on
that. Angus, what do you think of that?
Angus Why not make it
This patch is really only what is left of the old iterator patch
series. And basically all the stuff that was dependant upon boost
1.31.0.
I am not sure about the functor stuff herein, but the iterator adaptor
usage seems nice to me. Also the boost::next change is IMHO good.
(the deref is
Can someone test the current patch with documents with external insets to
see if all works OK?
Attached also a testcase showing the bad behaviour before the patch.
Should we do something equivalent for converters?
I don't know if playing with the file name to be converted you can also
execute
On Thu, Feb 05, 2004 at 05:11:55PM +0200, Sivan Toledo wrote:
I am trying to build lyx 1.3.3 with a qt frontend on cygwin. I got to
the point that qt and lyx both build successfully (no changes to the lyx
sources, and almost none to qt-x11). Qt runs the examples, but lyx dies
before it
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Can someone test the current patch with documents with external insets to
| see if all works OK?
| Attached also a testcase showing the bad behaviour before the patch.
| Should we do something equivalent for converters?
| I don't know if playing
Lars Gullik Bjnnes wrote:
Is execvp really nice?
I would have prefered execv since malicious programs can then not be
called from arbitrary locations (in the PATH).
I don't see this as a problem, as you cannot even specify the name of the
program...
the attacker would have to introduce the
Alfredo Braunstein [EMAIL PROTECTED] writes:
| I don't see the point really.
Depends on how anal we want to be.
(and no-path is a bit more secure than path)
--
Lgb
Lars Gullik Bjnnes wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
| I don't see the point really.
Depends on how anal we want to be.
(and no-path is a bit more secure than path)
Of course. But we still have some uses of system... so I leave you the
interpretation of how anal we are
Lars Gullik Bjønnes wrote:
This patch is really only what is left of the old iterator patch
series. And basically all the stuff that was dependant upon boost
1.31.0.
I am not sure about the functor stuff herein, but the iterator
adaptor usage seems nice to me. Also the boost::next change
Alfredo Braunstein wrote:
Can someone test the current patch with documents with external
insets to see if all works OK?
Attached also a testcase showing the bad behaviour before the patch.
Can't happen with 1.4.x AFAIK.
Should we do something equivalent for converters?
Don't they use
Angus Leeming wrote:
Should we do something equivalent for converters?
Don't they use forkedcall already?
Nope:
[EMAIL PROTECTED] src]$ grep -l Systemcall *.C */*.C */*/*.C
Chktex.C
converter.C
LaTeX.C
lyx_cb.C
vc-backend.C
insets/insetgraphics.C
support/filetools.C
support/systemcall.C
Alfredo Braunstein wrote:
There's one default converter that won't work:
\converter tiff eps tiff2ps $$i $$o
Should we provide a script or do we just nuke it?
Alfredo
Would this work and, if so, is it safe?
$ cat redirect.sh
#! /bin/sh
exec $1 $2
\converter tiff eps sh
Angus Leeming wrote:
Would this work and, if so, is it safe?
Seems to be ok, but I'm no expert...
$ cat redirect.sh
#! /bin/sh
exec $1 $2
\converter tiff eps sh $$s/redirect.sh('tiff2ps $$i' $$o)
Alfredo
Angus Leeming wrote:
- vectorstring nvec;
- std::copy(bstore.begin(), bstore.end(),
- lyx::back_inserter_fun(nvec, Buffer::fileName));
+ vectorstring nvec(
+ make_transform_iterator(bstore.begin(),
+
Alfredo Braunstein wrote:
Angus Leeming wrote:
Would this work and, if so, is it safe?
Seems to be ok, but I'm no expert...
Ask on comp.lang.unix.whatever then...
$ cat redirect.sh
#! /bin/sh
exec $1 $2
\converter tiff eps sh $$s/redirect.sh('tiff2ps $$i' $$o)
Alfredo
--
Angus Leeming wrote:
Alfredo Braunstein wrote:
Angus Leeming wrote:
Would this work and, if so, is it safe?
Seems to be ok, but I'm no expert...
Ask on comp.lang.unix.whatever then...
Answer: whatever.
They always answer like that in that ng.
Alfredo
I'll check this in too if nobody objects.
- Martin
Index: converter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/converter.C,v
retrieving revision 1.96
diff -u -p -r1.96 converter.C
--- converter.C 31 Jan 2004 15:30:20 -
Like this. Based on user feedback (thanks Tim!)
- Martin
Index: aguplus.inc
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/layouts/aguplus.inc,v
retrieving revision 1.4
diff -u -p -r1.4 aguplus.inc
--- aguplus.inc 15 Sep 2003
On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Why do I get
> >
> | make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
> | Making all in filesystem
> | /bin/sh: line 1: cd: filesystem: No such file or directory
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | Why do I get
>> >
>> | make[2]: Entering directory `/usr/src/lyx/lyx-build/boost/libs'
>> | Making all in filesystem
>> | /bin/sh:
On Thu, Feb 05, 2004 at 08:53:54AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> >> | Why do I get
> >> >
> >> | make[2]: Entering
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Feb 05, 2004 at 08:53:54AM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Wed, Feb 04, 2004 at 07:37:10PM +0100, Lars Gullik Bjønnes wrote:
>> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
>> >>
>> >>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Feb 05, 2004 at 09:11:49AM +0100, Lars Gullik Bjønnes wrote:
>>
>> There should be one in lyx-devel/boost/libs/ as well.
>>
>> So what is wrong in your tree...
>
| Ok. I removed the boost subtree and cvs up'd. Its there now.
| It was not there
On Thu, Feb 05, 2004 at 09:17:38AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Feb 05, 2004 at 09:11:49AM +0100, Lars Gullik Bjønnes wrote:
> >>
> >> There should be one in lyx-devel/boost/libs/ as well.
> >>
> >> So what is wrong in your tree...
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I am through through the whole autogen/configure/make cycle now and it
| works... And I've got now Makefile.am and Makefile.in in
| lib/filesystem...
good.
| Well, no problem anymore.
Wait until my next commit...
--
Lgb
What part of the code is responsible for writing that '00.00.' label
I get with 1.3.x?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
On Thu, Feb 05, 2004 at 10:16:57AM +0100, Andre' Poenitz wrote:
>
> What part of the code is responsible for writing that '00.00.' label
> I get with 1.3.x?
Urm.. found it. It's LabelString in the List layout.
No, hte next question: Is this changeable from within a LyX document?
I.e. can I
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Thu, Feb 05, 2004 at 10:16:57AM +0100, Andre' Poenitz wrote:
>> What part of the code is responsible for writing that '00.00.'
>> label I get with 1.3.x?
Andre> Urm.. found it. It's LabelString in the List layout.
Andre>
Thank you, Jean-Marc.
I've played a bit with coordinates this morning, and tried to bring LyX
again to a working state (coord-wise). I think it can be a good starting
point to choose a right coordinate scheme.
currently is:
- LyXFunc::dispatch uses screen coords (ok)
- BufferView::Pimpl::workAreaDispatch receives
On Thu, Feb 05, 2004 at 12:43:23PM +0100, Alfredo Braunstein wrote:
> I've played a bit with coordinates this morning, and tried to bring LyX
> again to a working state (coord-wise). I think it can be a good starting
> point to choose a right coordinate scheme.
>
> currently is:
>
> -
Andre Poenitz wrote:
> On Thu, Feb 05, 2004 at 12:43:23PM +0100, Alfredo Braunstein wrote:
>> I've played a bit with coordinates this morning, and tried to bring LyX
>> again to a working state (coord-wise). I think it can be a good starting
>> point to choose a right coordinate scheme.
>>
>>
On Thu, Feb 05, 2004 at 01:13:12PM +0100, Alfredo Braunstein wrote:
> > I'd think we should settle here for a clear scheme, i.e. either absolute
> > or screen-relative.
>
> screen-relative is out of the question: it's clearly worse than absolute.
> The only things that can use screen-relative
Andre Poenitz wrote:
>> For internal things LyXText-relative, or par-relative is fine I think (as
>> long as things remain somewhat private).
>
> Which 'internal things' do you mean?
row/par y-pos. It's faster to keep things relative to par/lyxtext (I think
it has shown on the profiles, right?)
On Thu, Feb 05, 2004 at 01:23:11PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> For internal things LyXText-relative, or par-relative is fine I think (as
> >> long as things remain somewhat private).
> >
> > Which 'internal things' do you mean?
>
> row/par y-pos. It's faster
Jean-Marc Lasgouttes wrote:
> In gettext.C:locale_init, we do a
> setlocale(LC_NUMERIC, "C");
> which is supposed to reset LC_NUMERIC to a good value. Might it be the
> "C" is not a valid locale for your glibc version? Maybe POSIX is
> better? What does 'man setlocale' say?
SuSE seems to
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> OK, I have added a debug message to xforms_helpers which
Juergen> outputs the current LC_NUMERIC setting (setlocale
Juergen> (LC_NUMERIC,NULL)) while running LyX.
Could you give me the exact patch, so that I can try
Jean-Marc Lasgouttes wrote:
> Could you give me the exact patch, so that I can try here in the same
> conditions?
Yes. attached (against 1.3.4cvs).
> Juergen> This is indeeed [EMAIL PROTECTED], so the setlocale(LC_NUMERIC, "C")
> Juergen> call in gettext.C seems to have no effect (or seems to be
Jean-Marc Lasgouttes wrote:
> Actually, the call to setlocale(LC_ALL,"") in xforms is IMO an
> error, since a library should never set the locale like that. I
> wonder though whether removing it would break some apps relying on
> that. Angus, what do you think of that?
Why not make it
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> Actually, the call to setlocale(LC_ALL,"") in xforms is IMO an
>> error, since a library should never set the locale like that. I
>> wonder though whether removing it would break some apps relying on
I am trying to build lyx 1.3.3 with a qt frontend on cygwin. I got to
the point that qt and lyx both build successfully (no changes to the lyx
sources, and almost none to qt-x11). Qt runs the examples, but lyx dies
before it opens the first window. It says it crashed with a segmentation
fault
Jean-Marc Lasgouttes wrote:
>>> Actually, the call to setlocale(LC_ALL,"") in xforms is IMO an
>>> error, since a library should never set the locale like that. I
>>> wonder though whether removing it would break some apps relying on
>>> that. Angus, what do you think of that?
>
> Angus> Why not
This patch is really only what is left of the old iterator patch
series. And basically all the stuff that was dependant upon boost
1.31.0.
I am not sure about the functor stuff herein, but the iterator adaptor
usage seems nice to me. Also the boost::next change is IMHO good.
(the deref is
Can someone test the current patch with documents with external insets to
see if all works OK?
Attached also a testcase showing the bad behaviour before the patch.
Should we do something equivalent for converters?
I don't know if playing with the file name to be converted you can also
execute
On Thu, Feb 05, 2004 at 05:11:55PM +0200, Sivan Toledo wrote:
>
> I am trying to build lyx 1.3.3 with a qt frontend on cygwin. I got to
> the point that qt and lyx both build successfully (no changes to the lyx
> sources, and almost none to qt-x11). Qt runs the examples, but lyx dies
> before
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Can someone test the current patch with documents with external insets to
| see if all works OK?
>
| Attached also a testcase showing the bad behaviour before the patch.
>
| Should we do something equivalent for converters?
>
| I don't know if
Lars Gullik BjÃnnes wrote:
> Is execvp really nice?
>
> I would have prefered execv since malicious programs can then not be
> called from arbitrary locations (in the PATH).
I don't see this as a problem, as you cannot even specify the name of the
program...
the attacker would have to
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| I don't see the point really.
Depends on how anal we want to be.
(and no-path is a bit more secure than path)
--
Lgb
Lars Gullik BjÃnnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | I don't see the point really.
>
> Depends on how anal we want to be.
> (and no-path is a bit more secure than path)
Of course. But we still have some uses of system... so I leave you the
interpretation of how
Lars Gullik Bjønnes wrote:
> This patch is really only what is left of the old iterator patch
> series. And basically all the stuff that was dependant upon boost
> 1.31.0.
>
> I am not sure about the functor stuff herein, but the iterator
> adaptor usage seems nice to me. Also the boost::next
Alfredo Braunstein wrote:
> Can someone test the current patch with documents with external
> insets to see if all works OK?
>
> Attached also a testcase showing the bad behaviour before the patch.
Can't happen with 1.4.x AFAIK.
> Should we do something equivalent for converters?
Don't they
Angus Leeming wrote:
>> Should we do something equivalent for converters?
>
> Don't they use forkedcall already?
Nope:
[EMAIL PROTECTED] src]$ grep -l Systemcall *.C */*.C */*/*.C
Chktex.C
converter.C
LaTeX.C
lyx_cb.C
vc-backend.C
insets/insetgraphics.C
support/filetools.C
support/systemcall.C
Alfredo Braunstein wrote:
> There's one default converter that won't work:
>
> \converter tiff eps "tiff2ps $$i > $$o" ""
>
> Should we provide a script or do we just nuke it?
>
> Alfredo
Would this work and, if so, is it safe?
$ cat redirect.sh
#! /bin/sh
exec $1 > $2
\converter tiff eps
Angus Leeming wrote:
> Would this work and, if so, is it safe?
Seems to be ok, but I'm no expert...
> $ cat redirect.sh
> #! /bin/sh
> exec $1 > $2
>
>
> \converter tiff eps "sh $$s/redirect.sh('tiff2ps $$i' $$o)" ""
Alfredo
Angus Leeming wrote:
> - vector nvec;
> - std::copy(bstore.begin(), bstore.end(),
> - lyx::back_inserter_fun(nvec, ::fileName));
> + vector nvec(
> + make_transform_iterator(bstore.begin(),
> + bind(::fileName,
>
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> Would this work and, if so, is it safe?
>
> Seems to be ok, but I'm no expert...
Ask on comp.lang.unix.whatever then...
>
>> $ cat redirect.sh
>> #! /bin/sh
>> exec $1 > $2
>>
>>
>> \converter tiff eps "sh $$s/redirect.sh('tiff2ps $$i'
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> Angus Leeming wrote:
>>
>>> Would this work and, if so, is it safe?
>>
>> Seems to be ok, but I'm no expert...
>
> Ask on comp.lang.unix.whatever then...
Answer: "whatever."
They always answer like that in that ng.
Alfredo
I'll check this in too if nobody objects.
- Martin
Index: converter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/converter.C,v
retrieving revision 1.96
diff -u -p -r1.96 converter.C
--- converter.C 31 Jan 2004 15:30:20 -
Like this. Based on user feedback (thanks Tim!)
- Martin
Index: aguplus.inc
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/layouts/aguplus.inc,v
retrieving revision 1.4
diff -u -p -r1.4 aguplus.inc
--- aguplus.inc 15 Sep 2003
82 matches
Mail list logo
