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 direc
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:
>> >>
>> >> |
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 simple cvs up.
That's strange.
> Have you co
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 t
> "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> N
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 sc
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:
>
> - LyXFunc::d
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.
>>
>> cur
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 coor
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
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 pre
> "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 her
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
>
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 a
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 m
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 horrib
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 ar
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 i
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 playi
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 introduce
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 "ana
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 cha
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 us
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 "s
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, &Buffer::fileName));
> + vector nvec(
> + make_transform_iterator(bstore.begin(),
> + bind(&Buffer
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 15:
42 matches
Mail list logo