On Fri, Nov 11, 2005 at 12:30:01AM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
> | + pit_type pit = &par - &pars_[0];
>
>
> No... this is in the ball park of pointer arithmetic
>
> Hmm... I think I basically dislike all of this... passing pointers...
> pa
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: text2.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
| retrieving revision 1.634
| diff -u -p -r1.634 text2.C
| --- text2.C 25 Oct 2005 09:14:11 -
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
|
| Martin> So... can this go in?
|
| Since there is a suspicion that the code is going to be slow, it would
| be better to write it to be faster, like (untested):
|
| + Paragraph
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
|
| Angus> Jean-Marc Lasgouttes wrote:
| >> I have a different idea right now: since ParagraphList is a vector,
| >> can't we just say that pit = &par - &pars_[0]; ?
|
| Angus> I'm not s
> On Nov 10, 2005, at 3:47 PM, Michael Abshoff wrote:
>
> Wouldn't you know it: Xcode 2.2 has just shown up on Apple's server,
> containing gcc-4.0.1. At 833MB, it'll take a while for me to
> download; I'll test tomorrow.
>
> Bennett
>
Hello Bennett,
thanks for the tip. I just downloaded and inst
On Nov 10, 2005, at 3:47 PM, Michael Abshoff wrote:
Correct. As it appears that doesn't fix your problem. Have you tried
compiling a gcc 4.0.2 yourself and using that?
Wouldn't you know it: Xcode 2.2 has just shown up on Apple's server,
containing gcc-4.0.1. At 833MB, it'll take a while for
> On Nov 10, 2005, at 1:49 PM, Hammer Armin wrote:
>
>> Hi Michael,
>
> Michael, is this what you intended: the difference between the
> original gcc-4.0 build 4061 and the gcc-4.0 build 5026 I have?
>
Correct. As it appears that doesn't fix your problem. Have you tried
compiling a gcc 4.0.2 you
On Nov 10, 2005, at 12:40 PM, Georg Baum wrote:
Bennett Helm wrote:
I've normally been compiling lyx-140 on Mac OS X with gcc 3.3 for
backwards compatibility, and everything works fine. However, looking
forward to supporting Intel-based Macs will require gcc-4.0. When I
try, however, I get the
On Nov 10, 2005, at 1:49 PM, Hammer Armin wrote:
Hi Michael,
Hello,
while I have not tried to compile lyx with gcc 4.0 on MacOSX the
group I
work in had some problems with that particular gcc. In our case
updating
to XCode 2.1 (which you get for free on the apple development
website -
c
http://bugzilla.lyx.org/show_bug.cgi?id=1952
Has anyone an idea why the inset owner of tabular cells is set to tabular, not
insettext, after undo (which is the reason for this bug)?
The relevant code seems to be the following, but I do not understand it:
undo.C:185
for (; pit != end; ++pit)
Hi,
I have to admit I didn't get the whole mailing list concept so I hope
I can bother you with my questions.
I'm currently writting my diploma thesis using lyx and I have to problems.
How can I turn the hyphenate function off?
I used the bibliography function and now I have a list of authors
w
Hi Michael,
> Hello,
>
> while I have not tried to compile lyx with gcc 4.0 on MacOSX the group I
> work in had some problems with that particular gcc. In our case updating
> to XCode 2.1 (which you get for free on the apple development website -
> caution download size is roughly 750M) solved ou
Hi Bennett,
I've encountered the same problem on Tiger using XCode 2.1 (which uses
gcc 4.0.0). My solution was to build gcc 4.0.2 on macosx from the source
and compile lyx-1.4.0cvs with it. With gcc 4.0.2 lyx compiles without
problem on macosx.
I expect Apple upgrade to gcc4.0.2 on XCode 2.2.
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Why not both. Good idea, and still works :-)
+ BOOST_ASSERT(pit >=0 && pit < pars_.size() && &pars_[pit] == &par);
would be even better.
And also a comment that this is going to break hard with anything else
than vector.
> Bennett Helm wrote:
>
>> I've normally been compiling lyx-140 on Mac OS X with gcc 3.3 for
>> backwards compatibility, and everything works fine. However, looking
>> forward to supporting Intel-based Macs will require gcc-4.0. When I
>> try, however, I get the error copied below.
>>
>> Any sugges
On 10 Nov 2005, Lars Gullik Bjønnes wrote:
> | Lars> Yes, why not... (have an english translation as well...)
> |
> | I do not see what problem this would solve, actually.
>
> It would probably make us see problems in l10n/i18n sooner, sine all
> languages (even english) would be on equal footin
Bennett Helm wrote:
> I've normally been compiling lyx-140 on Mac OS X with gcc 3.3 for
> backwards compatibility, and everything works fine. However, looking
> forward to supporting Intel-based Macs will require gcc-4.0. When I
> try, however, I get the error copied below.
>
> Any suggestions on
On Thu, 2005-11-10 at 18:08 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Anyway this is a great idea at this point. The cost is a small
> Martin> constant instead of linear with doc size.
>
> Martin> Tested and works. OK to go in?
>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Anyway this is a great idea at this point. The cost is a small
Martin> constant instead of linear with doc size.
Martin> Tested and works. OK to go in?
I'd rather see the patch first.
You may want to
BOOST_ASSERT(&pars_[pit] =
On Thu, Nov 10, 2005 at 04:11:03PM +, Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
> > I have a different idea right now: since ParagraphList is a vector,
> > can't we just say that
> > pit = &par - &pars_[0];
> > ?
>
> I'm not saying that would be a bad thing to do, but would note tha
I've normally been compiling lyx-140 on Mac OS X with gcc 3.3 for
backwards compatibility, and everything works fine. However, looking
forward to supporting Intel-based Macs will require gcc-4.0. When I
try, however, I get the error copied below.
Any suggestions on a fix?
Thanks.
Bennett
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> I have a different idea right now: since ParagraphList is a vector,
>> can't we just say that pit = &par - &pars_[0]; ?
Angus> I'm not saying that would be a bad thing to do, but would note
Angus> tha
Jean-Marc Lasgouttes wrote:
> I have a different idea right now: since ParagraphList is a vector,
> can't we just say that
> pit = &par - &pars_[0];
> ?
I'm not saying that would be a bad thing to do, but would note that
the fact that ParagraphList is a std::vector is meant to be an
implementati
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Why would that be faster (I'm happy to comply, but why?)?
do not recompute pars_size() repeatedly
do not invoke operator[] repeatedly, it may be expensive.
All this things are small, but there is not much more in the loop, so
Jean-Marc Lasgouttes wrote:
> Concerning the 1.4.0cvs version, when loading it I get:
> Warning: Malformed LyX file: Missing 'collapsed'.
> Warning: Malformed LyX file: Missing 'collapsed'.
> Warning: Malformed lyx file: Missing 'wide'.
> Warning: Malformed lyx file: Missing 'wide'.
> Handling unk
On Thu, Nov 10, 2005 at 04:22:47PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> So... can this go in?
>
> Since there is a suspicion that the code is going to be slow, it would
> be better to write it to be faster, like (untested):
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> So... can this go in?
Since there is a suspicion that the code is going to be slow, it would
be better to write it to be faster, like (untested):
+ ParagraphList::const_iterator it = pars_.begin();
+ ParagraphList::
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> And do we have a consensus-of-sorts on the attached?
I think it is OK, but I have not followed the discussion very closely.
JMarc
> "Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:
Hartmut> I'm sorry, Jean-Marc, I think I've sent you a corrupted file.
Hartmut> Here is a new one. I also send you some xpm's I need for the
Hartmut> UserGuide, which I have modified with Gimp to get rid of the
Hartmut> greyish backgroun
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> | The current mechanism with "[[...]]" ensures both.
|
| Lars> Well... it is fairly ugly. A nicer syntax could be choosen.
|
| Why? I think it is clearer for a non progra
> "Edjard" == Edjard Mota <[EMAIL PROTECTED]> writes:
Edjard> Could this be fixed so that only standards LaTeX classes are
Edjard> involked by the examples (i.e. article, report, book, etc.)?
Edjard> Not all templates in the template directory seem to be classes
Edjard> that come by default wi
On Wed, 2005-11-09 at 14:17 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> So then the original patch should go in, with break added? How
> Martin> expensive is this with big documents? It scales linearly.
>
> The good thing is that w
On Wed, 2005-11-09 at 12:14 +0100, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> >> Nice explanation. It should be in insetbase.h :-)
>
> Juergen> I'll gladly provide a documentation patch, but first someone
> Juergen> who knows better than
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | The current mechanism with "[[...]]" ensures both.
Lars> Well... it is fairly ugly. A nicer syntax could be choosen.
Why? I think it is clearer for a non programmer that this thing is a
note. The goal was not to have a synta
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Georg Baum <[EMAIL PROTECTED]>
| > writes:
| >
| > | Can you give an example? That would mean that the machinery to
| > | disambiguate such words with "fly[[as in 'to fly']]" and "fly[[as in 'a
| > | fly']]" in messages.C
On Wed, 9 Nov 2005, Helge Hafting wrote:
> On Wed, Nov 09, 2005 at 01:04:37PM +0100, [EMAIL PROTECTED] wrote:
> [...]
> > In case the developers don't want it for this release, just upload it to
> > the wiki...
> >
> > http://wiki.lyx.org/Layouts/Layouts
> >
> Thanks for the tip, I did that
Jean-Marc Lasgouttes wrote:
> I noticed the following chunk in the diff:
>
>
> @@ -16770,7 +16075,7 @@ math-matrix 1 2
> -- Insert a stacked array
> \begin_inset Formula $\begin{array}{c}
> \begin{array}{c}
> -\\\end{array}\end{array}$
> +\end{array}\end{array}$
> \end_inset
>
> .
>
> Is
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> This patch adapts the layout file documentation to the current
Georg> file format and documents manual conversion. I left out a lot
Georg> of whitespace that was added by current LyX in order to make
Georg> the patch readable. The only
John Levon wrote:
> This makes the sources diverge, it essentially means you're now the
> maintainer of qt.m4. Fine by me.
???
I've retired. I'm maintaining nowt. Anyway, this thread has gone on
way too long, so I'll shut up and bugger off.
--
Angus
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> In anycase we need to change to have only one way of defining
>> shortcuts.
>>
>> But all this is 1.5 stuff.
Georg> Yes.
Note that this is something that should be tackled early enough in the
1.5.x cycle. It is a pity that we have this
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
>
> | Can you give an example? That would mean that the machinery to
> | disambiguate such words with "fly[[as in 'to fly']]" and "fly[[as in 'a
> | fly']]" in messages.C is not needed at all.
>
> And I don't think we should u
Georg Baum wrote:
Can you give an example? That would mean that the machinery to disambiguate
such words with "fly[[as in 'to fly']]" and "fly[[as in 'a fly']]" in
messages.C is not needed at all.
I was wrong. I thought they couldn't possibly have made the assumption
that a string always ca
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote: I'll gladly provide a
Juergen> documentation patch, but first someone who knows better than
Juergen> me should confirm that this is actually correct.
>> I think it is 100% correct.
Juergen> O
Georg Baum <[EMAIL PROTECTED]> writes:
| Can you give an example? That would mean that the machinery to disambiguate
| such words with "fly[[as in 'to fly']]" and "fly[[as in 'a fly']]" in
| messages.C is not needed at all.
And I don't think we should use that style of disambiguating the
phrases
Jean-Marc Lasgouttes wrote:
> Juergen> I'll gladly provide a documentation patch, but first someone
> Juergen> who knows better than me should confirm that this is actually
> Juergen> correct.
>
> I think it is 100% correct.
OK, here's the patch.
Jürgen
Index: insetbase.h
Daniel Watkins wrote:
> > Is this fixed by this patch?
> > http://marc.theaimsgroup.com/?l=lyx-devel&m=113137862006884&w=2
>
> This patch means that the cursor now goes into the appropriate location
It's in. The patch restores completely the old behaviour
> (ie. the top or bottom of a fraction),
Helge Hafting wrote:
> On Wed, Nov 09, 2005 at 09:21:25PM +0100, Georg Baum wrote:
>> This does only work if the original string is different, too, but in the
>> example above it is not.
>
> Are you sure?
Pretty sure. From
http://www.gnu.org/software/gettext/manual/html_chapter/gettext_7.html#S
47 matches
Mail list logo
