Uwe Stöhr wrote:
> Am 24.02.2013 22:57, schrieb Felippe Beaklini:
>
>> We could possible offer a mirror of lyx in Brazil should it be of
>> interest. We already mirror some
>> linux distributions and we would like to contribute with LyX. We are
>> currently syncing from
>> ftp.lyx.org::. The addr
Hello,
I want to report a bug.
mhchem arrow -> doesn't work together with Czech (in English) language
text.
(Example Lyx file and pdf in attachment.)
bug_mhchem_czech.lyx
Description: Binary data
bug_mhchem_czech.pdf
Description: Adobe PDF document
On Mon, 2013-03-11 at 22:00 +0100, Uwe Stöhr wrote:
> Many thanks. It did not occur for me because I wrote my example file in
> German so that I got the
> necessary line break.
> I'm unsure if we should overwhelm the user in the tutorial with such a
> special issue or not.
> Currently I would p
Am 27.02.2013 21:08, schrieb John R. Hudson:
I followed the Tutorial and the problem occurred first in My first
document. So I attach two versions of this document and the exported
PDFs, one up to the point when the problem occurred (section 3.4.2) and
one after I had added more material as sugg
Am Montag, 11. März 2013 um 19:28:47, schrieb Jean-Marc Lasgouttes
>
> Kornel Benko a écrit :
> >Interested in the valgrind output (267 kb)?
>
>
> Sure.
Aaah. I incidentally replaced it with output of 'valgrind --tool=massif'
But will make a new one. Tomorrow, OK?
> JMarc
Kornel
s
Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
...
> >
> > add InsetBibtex::plaintext() again.
> >
> Can you post a backtrace showing where that is being called from? I
> don't know what advanced search is doing exactly, but I know it
Kornel Benko a écrit :
>Interested in the valgrind output (267 kb)?
Sure.
JMarc
Am Montag, 11. März 2013 um 17:46:50, schrieb Kornel Benko
> > Another possibility is to use the 'massif' tool of valgrind. It will
> > tell you where the data is allocated.
>
> I will try this one also.
>
I tried, but got only this output with
#valgrind --tool=massif ...
==21508== M
On 03/11/2013 12:46 PM, Kornel Benko wrote:
Am Montag, 11. März 2013 um 15:33:36, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 14:42, Kornel Benko a écrit :
> > ==11211== LEAK SUMMARY:
> > ==11211== definitely lost: 33,700 bytes in 189 blocks
> > ==11211== indirectly lost: 59,454 bytes in
Am Montag, 11. März 2013 um 15:33:36, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 14:42, Kornel Benko a écrit :
> > ==11211== LEAK SUMMARY:
> > ==11211== definitely lost: 33,700 bytes in 189 blocks
> > ==11211== indirectly lost: 59,454 bytes in 1,606 blocks
> > ==11211== possibly lost: 15,783 by
Am Montag, 11. März 2013 um 15:41:06, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 13:42, Kornel Benko a écrit :
> > > I tried the merged manual, and indeed it is very slow. Are you trying
> > > with stdlib-debug on?
> >
> > I don't think so. How can I check?
> >
> > In cmake I am creating a de
Le 11/03/2013 13:42, Kornel Benko a écrit :
> I tried the merged manual, and indeed it is very slow. Are you trying
> with stdlib-debug on?
I don't think so. How can I check?
In cmake I am creating a debug version, but without using LYX_STDLIB_DEBUG.
This means, the gcc does *not* have
-D_G
Le 11/03/2013 14:42, Kornel Benko a écrit :
==11211== LEAK SUMMARY:
==11211== definitely lost: 33,700 bytes in 189 blocks
==11211== indirectly lost: 59,454 bytes in 1,606 blocks
==11211== possibly lost: 15,783 bytes in 59 blocks
==11211== still reachable: 1,721,311 bytes in 8,392 blocks
==11211==
Am Montag, 11. März 2013 um 13:42:34, schrieb Kornel Benko
>
> Trying... takes nearly forever ... only 1 of my 4 cpu's is busy (100%) ...
>
> will mail again, when (and if?) the seach under valgrind ends.
>
> > JMarc
So, search finished, no visible memory lost.
The dialog
Opened files
Am Montag, 11. März 2013 um 12:43:30, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 12:22, Kornel Benko a écrit :
> > Hi,
> >
> > advanced search in my document (for a non-existent string on all opened
> > documents):
> >
> > takes 227 seconds. Moreover, at the end of search (dialog asking to
> >
Le 11/03/2013 12:22, Kornel Benko a écrit :
Hi,
advanced search in my document (for a non-existent string on all opened
documents):
takes 227 seconds. Moreover, at the end of search (dialog asking to
start over)
I tried the merged manual, and indeed it is very slow. Are you trying
with stdli
Hi,
advanced search in my document (for a non-existent string on all opened
documents):
takes 227 seconds. Moreover, at the end of search (dialog asking to start over)
eats so much memory ( > 4GB), that my computer starts to using swap disk.
Being warned on the plaintext problem, I checked the t
17 matches
Mail list logo
