Martin Vermeer wrote:
What he means is that the figure is formally embedded in a paragraph
inside the float, which is formatted "justified" (out of alternatives
left, right, justified and centred). This means the picture will align
with the left edge, being just one huge "character" in the paragrap
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Hmm.. I now see that I didn't try the exact same src.rpm. I will try
| yours now.
and that just worked...
--
Lgb
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Angus Leeming <[EMAIL PROTECTED]> writes:
>
| | Lars Gullik Bjønnes wrote:
>>> I need to get an xforms for x86_64 first, do you have a rpm?
>>
| | wget http://devel.lyx.org/~leeming/xforms-1.0.90-1.src.rpm
>>
| | About 1MB in size.
>
| It failed.
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> I need to get an xforms for x86_64 first, do you have a rpm?
>
| wget http://devel.lyx.org/~leeming/xforms-1.0.90-1.src.rpm
>
| About 1MB in size.
It failed.
rpmbuild --rebuild /home/larsbj/xforms-1.0-release.src.rpm
ends
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Anything more you want to know? :-)
>
| Yes. What can we do about this poor freebsd compiler? Do you have
| ideas about that?
There are two errors about concept checks flyin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Anything more you want to know? :-)
>
| Yes. What can we do about this poor freebsd compiler? Do you have
| ideas about that?
Why anything if the -- switch fixes the proble
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Anything more you want to know? :-)
Yes. What can we do about this poor freebsd compiler? Do you have
ideas about that?
JMarc
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> I need to get an xforms for x86_64 first, do you have a rpm?
>
| wget http://devel.lyx.org/~leeming/xforms-1.0.90-1.src.rpm
>
| About 1MB in size.
I already got it... building now.
--
Lgb
Lars Gullik Bjønnes wrote:
> I need to get an xforms for x86_64 first, do you have a rpm?
wget http://devel.lyx.org/~leeming/xforms-1.0.90-1.src.rpm
About 1MB in size.
--
Angus
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Lars, did you read that thread?
>
| Lars> This thread?
>
| Yes.
So yes then.
Anything more you want to know? :-)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Lars, did you read that thread?
Lars> This thread?
Yes.
JMarc
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> The Q is if we should do any of this for 1.4.x.
>
| Strip out the XForms dialog, see what's left of FileInfo and then decide.
I need to get an xforms for x86_64 first, do you have a rpm?
--
Lgb
Lars Gullik Bjønnes wrote:
> The Q is if we should do any of this for 1.4.x.
Strip out the XForms dialog, see what's left of FileInfo and then decide.
--
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Microsoft released the compiler that ships with .NET 2003 Professional
>> | for free, here: http://msdn.microsoft.com/visualc/vctoolkit2003/
>>>
>> | Do we need to support anything older?
>> | Having said that, I see only
Lars Gullik Bjønnes wrote:
> | Microsoft released the compiler that ships with .NET 2003 Professional
> | for free, here: http://msdn.microsoft.com/visualc/vctoolkit2003/
>>
> | Do we need to support anything older?
> | Having said that, I see only two compiler work-arounds in Asger's
> | patch, so
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> What verison of MSVS and/or MSVC++ are we planning to support?
>
| Microsoft released the compiler that ships with .NET 2003 Professional for
| free, here: http://msdn.microsoft.com/visualc/vctoolkit2003/
>
| Do we need to s
Lars Gullik Bjønnes wrote:
> What verison of MSVS and/or MSVC++ are we planning to support?
Microsoft released the compiler that ships with .NET 2003 Professional for
free, here: http://msdn.microsoft.com/visualc/vctoolkit2003/
Do we need to support anything older?
Having said that, I see only tw
What verison of MSVS and/or MSVC++ are we planning to support?
--
Lgb
Lars Gullik Bjønnes wrote:
> Keep it in your tree, pester the rest of us about the missing
> abstractions and the end restult should be that your extra patch
> dwindles to nothingness.
Hear, hear!
--
Angus
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
>
| | Angus Leeming wrote:
>>> Ok, I did misunderstand you.
>>
| | Thank you.
>>
| | Then we agree that using _WIN32 for pure Windows stuff is superior to
| | HAVE_THIS_OR_THAT guards which *only* ben
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> Ok, I did misunderstand you.
>
| Thank you.
>
| Then we agree that using _WIN32 for pure Windows stuff is superior to
| HAVE_THIS_OR_THAT guards which *only* benefit that platform.
Tja... that might be so. But having this k
Asger Ottar Alstrup wrote:
> But the question is this:
>
> 1) Do you want me to do this kind of janitor stuff?
> 2) or do you want me to find and fix the difficult bugs in the kernel?
>
> It's your choice.
2) please. I'm quite happy to integrate the janitor stuff slowly. I picked
up Ruurd's pat
I got this playing around in a new file. I'm not sure how.
recordUndo: pos: 0
BufferView::Pimpl::update(fc=1, fu=0) buffer: 01182A98
npit: 2 pit1: 0 pit2: 0
bv:metrics: y1: 0 y2: 92
LyXText::getPitNearY: y: 93 cache size: 3
examining: pit: 0 y: 40
examining: pit: 1 y: 66
examining: pit: 2 y
Asger Ottar Alstrup wrote:
You want to go for the difference algorithm based on the edit distance
measure. It is better suited for this. See this link, which also
explains the relation to LCS:
http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Dynamic/Edit/
Since this algorithm has an O(n^2) comple
Angus Leeming wrote:
Ok, I did misunderstand you.
Thank you.
Then we agree that using _WIN32 for pure Windows stuff is superior to
HAVE_THIS_OR_THAT guards which *only* benefit that platform.
> Your patch cripples FileInfo. Agree? The code in FileInfo.C
works perfectly well under MinGW, so your p
Andreas Vox wrote:
> So ParIterator defines ++ to forwardPar() and InsetIterator defines
> ++ to forwardInset() ?
Exactly. Have a look at insetiterator.[Ch] for instance, it's very small.
Alfredo
Asger Ottar Alstrup wrote:
> Angus Leeming wrote:
>> I sent you the patch that was needed to compile LyX 1.3.x with MinGW.
>> Your patch contains vast changes to FileInfo.C, no? Mine does not. Yet
>> appart from the change of lyx::Assert to BOOST_ASSERT, the only change
>> to the file is to the na
To All:
Please accept my apologies for sending a message with attachments to the list.
I used the wrong setting in Kmail. It should have been privately to Georg
Baum.
Regards
Basil Fowler
On Tuesday 25 January 2005 16:39, Basil Fowler wrote:
> Sehr geehrter Herr Baum,
>
> hier sind die Erge
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> Not quite: These two are mere wrappers arount DocIterator, basically
> DocIterator is NOT a forward iterator (it doesn't have operator++, but
> forward{Par,Pos,Inset} methods), and these two are. All three iterate in a
> full subtree of the lyx d
Sehr geehrter Herr Baum,
hier sind die Ergebnisse der Versuche, die Sie von mir verlangt haben. Auch
dienen sie als eine genaue Darstellung des Problems.
Versuch 1
Die Datei »testfile1*« enthalten die ursprunglische LyX-Datei, und die
entsprechenden .tex und .dvi Tochter-Datei. Dieser Satz Dat
Angus Leeming wrote:
I sent you the patch that was needed to compile LyX 1.3.x with MinGW. Your
patch contains vast changes to FileInfo.C, no? Mine does not. Yet appart
from the change of lyx::Assert to BOOST_ASSERT, the only change to the
file is to the namespace.
Good enough for you?
No. You
Asger Ottar Alstrup wrote:
> I do not accept your evidence. Compile the code with my patch with mingw
> and show me the errors. When I see that, I accept your evidence.
I sent you the patch that was needed to compile LyX 1.3.x with MinGW. Your
patch contains vast changes to FileInfo.C, no? Mine d
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> All insets, not only top-level (but you probably meant that).
>
> Ahh yes, you're right. However, note that the code *use to* iterate over
> all insets with the proviso that the entire contents of a math inset were
> treated as a single whole
Alfredo Braunstein wrote:
> All insets, not only top-level (but you probably meant that).
Ahh yes, you're right. However, note that the code *use to* iterate over
all insets with the proviso that the entire contents of a math inset were
treated as a single whole. That is, all those bit-of-math
Angus Leeming wrote:
This is hardly rapid progress. It shows that LyX is a slowly evolving
beast. Indeed, if only one person is committing many changes quickly,
then I expect the code to become more buggy not less. Wouldn't you?
I think the number of bugs is very hard to predict nomatter what
pr
Angus Leeming wrote:
> Andreas Vox wrote:
>> 3. Which iterator would I use to iterate all mathhull-insets
>> for snippet collection? Insetiterator?
>
> See src/graphics/Previews.C
> This iterates over all top level insets.
>
> void Previews::generateBufferPreviews(Buffer const & buffer) const
>
Angus Leeming wrote:
Andreas Vox wrote:
3. Which iterator would I use to iterate all mathhull-insets
for snippet collection? Insetiterator?
See src/graphics/Previews.C
This iterates over all top level insets.
void Previews::generateBufferPreviews(Buffer const & buffer) const
{
PreviewLoader &
Andreas Vox wrote:
> Hi!
Hi Andreas,
> As a newbie I'm still trying to figure out how to use
> the various iterators. My current hypotheses are:
>
> DocIterator is used to iterate the whole document in a
> preorder style.
Ok.
> ParagraphIterator is used to iterate over paragraphs local
> to
Andreas Vox wrote:
> $ gdb /Applications/LyX.app/Contents/MacOS/lyx
>
> BTW: is your unstripped binary also 200 MB ?
> Takes some time to load into gdb!
No. Only 126MB and I'm typing this from a 64bit Alpha machine, so I'd
expect my binary to be twice the size of yours. Means that your version o
Andreas Vox <[EMAIL PROTECTED]> writes:
| 4. Are these iterators compatible with STL?
Almost. not quite.
--
Lgb
Andreas Vox wrote:
> 3. Which iterator would I use to iterate all mathhull-insets
> for snippet collection? Insetiterator?
See src/graphics/Previews.C
This iterates over all top level insets.
void Previews::generateBufferPreviews(Buffer const & buffer) const
{
PreviewLoader & ploader = loade
Angus Leeming <[EMAIL PROTECTED]> writes:
| Why make a big deal about this. HAVE_SYS_TIM_H is immediately
| understandable. Add the nasty shit in config.h.
>
>> So you believe that it is a good idea that the documents in CVS are
>> using an old version?
>
| Sure. Why not if it enables us to also
Asger Ottar Alstrup wrote:
> Because you are asking me to do things which I can not test. Therefore,
> I'm dependent on others to do the work, which adds required
> synchronisation points to the process, when everything could be done
> with one operation instead of 5.
I had a look at the cvs commi
Hi!
As a newbie I'm still trying to figure out how to use
the various iterators. My current hypotheses are:
DocIterator is used to iterate the whole document in a
preorder style.
ParagraphIterator is used to iterate over paragraphs local
to one surrounding inset.
InsetIterator iterates over the who
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Andreas Vox wrote:
> > For me it's more a kind of bug aid It's like having lots of
> > "Quit without saving" buttons in the document.
>
> Nonsense. lyxbreaker calls BOOST_ASSERT which calls
> assertion_failed (src/boost.C) which calls emergencyClea
Angus Leeming wrote:
And if you tried the MinGW compiler you'd find that this statement was
just wrong.
So you tried my patch with Ming? How did it fare?
Why make a big deal about this.
Because you are asking me to do things which I can not test. Therefore,
I'm dependent on others to do the work,
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Unless _really_ big, do you have to attach as octed-stream and bzip?
>
| Is 61k ok to send as raw?
for me: semi-ok
>
| I used Thunderbird as my mailer. Teach me how to change the MIME and I
| will. Do you prefer som
Asger Ottar Alstrup wrote:
>> The stuff in the Qt frontend is obviously correct. Please add a comment
>> to the QLPainter change and just commit it.
>
> I hate changelogs. You love them. Help me out.
I meant to the bloody code.
// MSVC can't handle the use of QString::operator[] here.
//
Andreas Vox wrote:
> For me it's more a kind of bug aid ;-) It's like having lots of
> "Quit without saving" buttons in the document.
Nonsense. lyxbreaker calls BOOST_ASSERT which calls assertion_failed
(src/boost.C) which calls emergencyCleanup which saves your data.
> When is it supposed to tr
The stuff in the Qt frontend is obviously correct. Please add a comment to
the QLPainter change and just commit it.
I hate changelogs. You love them. Help me out.
> Presumably this needs a configure test leading to something like:
> #if HAVE_STD_TIME
> using std::time;
> #endif
and
support/chdir.
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Hi,
>
| The attached patch to dociterator.C should be obviously correct. You
| can not access a textRow if there are none. If you apply this, you
| will also get an assertion failure in text.C breakParagraph as I do
| without even this patch, becau
Lars Gullik Bjønnes wrote:
Unless _really_ big, do you have to attach as octed-stream and bzip?
Is 61k ok to send as raw?
I used Thunderbird as my mailer. Teach me how to change the MIME and I
will. Do you prefer something else than bzip?
Regards,
Asger
Asger Ottar Alstrup wrote:
> Hi,
>
> I attach the latest MSVC patch. Please comment. What is required before
> you can accept this?
Let's see:
src/DepTable.C
+# ifndef _WIN32
using std::time;
+# endif
Presumably this needs a configure test leading to something like:
#if HAVE_STD_TIME
using s
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Well, I meant to include a patch to text.C, but it has been trying to
| make a diff for half an hour without any success. I just attach the
| latest version instead. You can make your own diff.
Unless _really_ big, do you have to attach as octed-s
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
| Hi,
>
| I attach the latest MSVC patch. Please comment. What is required
| before you can accept this?
With that much _WIN32 stuff? Quite a lot.
| Notes:
>
| - The stuff in Buffer.C suggests that we should add a
| lyx::support::copyfile method.
Hi,
The attached patch to dociterator.C should be obviously correct. You can
not access a textRow if there are none. If you apply this, you will also
get an assertion failure in text.C breakParagraph as I do without even
this patch, because MSVC is so kind to flag a memory access error due to
p
Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > Andreas Vox wrote:
> > > When I activate previews and then click on a previewed formula I get:
> > >
> > > Assertion triggered in void lyxbreaker(const void*, const char*,
> > > int) by failing check "false" in file coordcache.C:20
...
> This
Georg Baum <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>
>> g++ 3.3.5 on a Linux/Alpha machine running Debian unstable. Not what I was
>> using last night where I had the problems. That was an i686 machine
>> running FC3 and g++ 3.4.2?. Presumably the settings above are different
>> there.
Hi,
I attach the latest MSVC patch. Please comment. What is required before
you can accept this?
Notes:
- The stuff in Buffer.C suggests that we should add a
lyx::support::copyfile method.
- All the stuff in forkedcall and friends awaits proposal from Angus.
Angus, the train is moving. I have
Basil Fowler wrote:
> Perhaps the LyX -> LaTeX routine could be altered so that the newline and
> excess space characters are removed as a default? Or is there a reason
> for the present arrangement?
Do you have a space at the end of the paragraph in the .lyx file? If yes,
does it help to remove
Angus Leeming wrote:
> g++ 3.3.5 on a Linux/Alpha machine running Debian unstable. Not what I was
> using last night where I had the problems. That was an i686 machine
> running FC3 and g++ 3.4.2?. Presumably the settings above are different
> there.
I described here:
http://bugzilla.lyx.org/sho
Lars Gullik Bjønnes wrote:
> | Is it just a case of adding these to a config file to mirror what it in
> | the LyX config.h?
>>
> | #define _GLIBCPP_CONCEPT_CHECKS 1
> | /* #undef _GLIBCXX_CONCEPT_CHECKS */
> | /* #undef _GLIBCXX_DEBUG */
> | /* #undef _GLIBCXX_DEBUG_PEDANTIC
>
> this snipped is f
Firstly - Thanks for a great program.
There is a minor point but annoying. I use a style with 'noindent' for
paragraphs, with the paragraphs being separated with 'medskip'. This works
correctly 98% of the time. The other times there is excess space between the
paragraphs. This occurs when
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars, did you read that thread?
This thread?
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | $ g++ -fno-exceptions -g -Ilyx/devel/boost -o trial2 trial2.cpp \
>> | -Llyx/devel/build/boost/libs/signals/src/.libs -lboost_signals
>>
>> You seem to have a mixed build. half with stdlib debug half without...
>> that
Lars Gullik Bjønnes wrote:
> | $ g++ -fno-exceptions -g -Ilyx/devel/boost -o trial2 trial2.cpp \
> | -Llyx/devel/build/boost/libs/signals/src/.libs -lboost_signals
>
> You seem to have a mixed build. half with stdlib debug half without...
> that won't work.
>
> Either everything must be built w
John Weiss wrote:
> On Fri, Jan 21, 2005 at 09:57:48PM +, Angus Leeming wrote:
>> Cygwin's POSIX emulation layer avoids
>> the need for the various workarounds required when using other
>> compilers under MS-Windows.
>
> See! See! I *am* speaking from real experience! I'm not just some
> id
Andreas Vox wrote:
I wanted to polish my C++ and STL knowledge, so I thought
it would be more interesting to adapt the diff algorithm
directly to the list of insets -- longest common subsequence
just sounds like a good algorithm for iterators, doesn't it?
You want to go for the difference algorithm
Angus Leeming <[EMAIL PROTECTED]> writes:
| The attached program compiles perfectly when compiled against the LyX 1.3.x
| and 1.4.x versions of Boost, but segfaults when the 1.4.x version is run.
| At least, it does here
>
| I don't think that this is too controversial, is it?
>
| int main()
| {
|
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jan 24, 2005 at 01:58:24PM +0100, Asger Ottar Alstrup wrote:
>> Lars Gullik Bjønnes wrote:
>> >Please figure on list.
>>
>> You're such a control freak.
>
| Last time I saw him he was pretty much out of control of the sleigh he
| was riding...
So this will appear on Google for the benefit of those who need it.
The problem:
1) Dead keys ("accents") don't work in LyX. Typing, e.g., "Â" "e" in
succession does not produce à (e-sharp) as it should.
2) The ^ key, which should produce in the math editor a superscript,
does not. It enters a ^
John Weiss wrote:
[A great opportunity to have a little flame-fest.]
Not FUD. Reality. [Long story about something irrelevant.]
> Took them YEARS to get it to that state.
Sad for them. I have a working LyX. It took a week of work while Elias
was sleeping. All you are saying is FUD, and the proof
On Mon, 2005-01-24 at 15:30, John Weiss wrote:
> On Thu, Jan 20, 2005 at 01:09:21AM +0100, Uwe StÃhr wrote:
> > Hello LyXers,
> >
> > since LyX 1.2.x a figure is by default inserted into a float as a
> > justified paragraph instead of a centered one. This behaviour is very
> > annoying for many
73 matches
Mail list logo
