Re: Memory leak ?

[Stephan Witt]

Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes:

 Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
 My testing so far says the opposite. We are continually using more and
 more memory. Not especially fast, but it is there.
 
 A good tool to know where memory goes is the massif tool of valgrind.

I've tried to use Instruments Leak-Detector on Mac.

1. It doesn't find any suspicious leaks - the growing memory is not lost.
2. The growing memory is allocated in TextClass constructor - about 40k per 
autosave operation.
3. Call Stack:

Total % Bytes   Library Symbol Name
...
11.41.65 MB lyx::frontend::GuiView::autoSave()
11.41.64 MB lyx::Buffer::cloneBufferOnly() const
11.41.64 MB lyx::Buffer::Buffer(std::string const, bool, lyx::Buffer 
const*)
11.41.64 MB lyx::Buffer::Impl::Impl(lyx::Buffer*, lyx::support::FileName 
const, bool, lyx::Buffer const*)
11.41.64 MB lyx::BufferParams::BufferParams()
11.41.64 MB lyx::BufferParams::makeDocumentClass()
11.41.64 MB lyx::DocumentClassBundle::makeDocumentClass(lyx::LayoutFile 
const, lyx::LayoutModuleList const)
11.41.64 MB lyx::DocumentClassBundle::newClass(lyx::LayoutFile const)
11.21.61 MB lyx::DocumentClass::DocumentClass(lyx::LayoutFile const)
11.21.61 MB lyx::TextClass::TextClass(lyx::TextClass const)

1 minute later

Total % Bytes   Library Symbol Name
...
11.71.69 MB lyx::DocumentClassBundle::newClass(lyx::LayoutFile const)
11.41.65 MB lyx::TextClass::TextClass(lyx::TextClass const)

Stephan

Re: Memory leak ?

[Jean-Marc Lasgouttes]

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
-01.02% (303,120B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-03.16% (972,720B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-03.06% (1,262,880B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-03.56% (1,486,080B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-05.12% (1,642,320B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-04.06% (1,709,280B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-05.74% (1,865,520B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-04.54% (1,932,480B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I think 
that we never release buffers cloned by autosave.


JMarc

Re: [patch] move citation engine to layout modules

[Julien Rioux]

On 01/21/2012 09:49 PM, Richard Heck wrote:

On 01/10/2012 09:19 PM, Julien Rioux wrote:

Looking for your comments!


The approach looks very good to me, though the patch is so
huge---unavoidably so, to be sure---that it's hard to have much to say
about the details.

Can you say a bit about the format of the CiteFormat entries? I take it
you are reusing the RefStyle formats a bit here.

Richard



Hi Richard,

I'm not sure what RefStyle formats are. What I'm reusing is the 
CiteFormat block since it allows templating and extracting information 
from citation entries. It was already part of the layout syntax so I 
could avoid rewriting a bunch of stuff.


This CiteFormat infrastructure is used to provide e.g. the little 
preview of a citation entry in the Citation dialog, with templates for 
article, book and so on... In this new patch I add templates for 
cite citep citet citeyear etc. and use those in the GUI. To the 
CiteFormat block I added an argument, either authoryear or numerical, so 
that different templates are used reflecting e.g. the output of the 
latex command \citep which depends on the natbib option used.


The nice thing about having everything (well, almost) in the layout file 
is that customization is flexible and relatively easy. If you wrote a 
module that added a citation style \bibtexkey to actually output the 
BibTeX key itself in the PDF, you would also add a template in the 
CiteFormat block so that the UI reflects this. We can also add a number 
of the yet unsupported jurabib citation styles and so on.


Cheers,
Julien

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Vincent van Ravesteijn]

Op 23-1-2012 2:49, uwesto...@lyx.org schreef:

Author: uwestoehr
Date: Mon Jan 23 02:49:49 2012
New Revision: 40663
URL: http://www.lyx.org/trac/changeset/40663


  revert =  [
-   [423, [revert_cite_engine_type]],
+   [424, [revert_cancel]],
+   [423, [revert_cite_engine_type, revert_cancel]],
 [422, [revert_use_mathtools]],
 [421, [revert_use_packages]],
 [420, [revert_longtable_captions]],


Uwe,

Is it intended to revert_cancel when going to format 423 ?

Vincent

Re: Memory leak ?

[Richard Heck]

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
-01.02% (303,120B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-03.16% (972,720B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const) (new_allocator.h:92)
-03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, but 
we do not, it is true, release the TextClass objects that are associated 
with them. There's actually a good reason for that where ordinary 
Buffers are concerned---there could be something on the cut stack that 
still has a reference to the TextClass in question---but in the case of 
AutoSave, there is no reason we need to keep these around. See the 
comments at the end of TextClass.h, concerning the DocumentClassBundle.


I'll try to have a look shortly, but classes start again on Wednesday. 
If anyone else had ideas, I'd be happy to hear them.


Richard

Re: SVN Down?

[Vincent van Ravesteijn]

Op 23-1-2012 1:47, Lars Gullik Bjønnes schreef:

Jean-Marc Lasgoutteslasgout...@lyx.org  writes:

| Le 22/01/12 14:00, Lars Gullik Bjønnes a écrit :

| No problems here.  Neither with svn up nor when logging in ti trac.

The dist was pretty full. I cleaned out some.

| Last time I saw that, it was because of the svn dumps (I removed some
| at that time). Can we make sure we keep less of these, in order to use
| less disk?

Yes, this time I will really fix it.

| Unlss you found another good source of useless bits, of
| course.
| BTW, is our svn db backuped somewhere else?

I do a back from time to time, and I have the git conversion that is
continously updated.


Is the git conversion already online and accessible somewhere ?

Maybe we can continue to prepare the switch.

Vincent

Re: [patch] move citation engine to layout modules

[Richard Heck]

On 01/23/2012 08:21 AM, Julien Rioux wrote:

On 01/21/2012 09:49 PM, Richard Heck wrote:

On 01/10/2012 09:19 PM, Julien Rioux wrote:

Looking for your comments!


The approach looks very good to me, though the patch is so
huge---unavoidably so, to be sure---that it's hard to have much to say
about the details.

Can you say a bit about the format of the CiteFormat entries? I take it
you are reusing the RefStyle formats a bit here.

Richard



Hi Richard,

I'm not sure what RefStyle formats are. What I'm reusing is the 
CiteFormat block since it allows templating and extracting information 
from citation entries. It was already part of the layout syntax so I 
could avoid rewriting a bunch of stuff.



Yes, sorry, that's what I meant.

This CiteFormat infrastructure is used to provide e.g. the little 
preview of a citation entry in the Citation dialog, with templates for 
article, book and so on... In this new patch I add templates for 
cite citep citet citeyear etc. and use those in the GUI. To 
the CiteFormat block I added an argument, either authoryear or 
numerical, so that different templates are used reflecting e.g. the 
output of the latex command \citep which depends on the natbib option 
used.



OK, I understand.

The nice thing about having everything (well, almost) in the layout 
file is that customization is flexible and relatively easy. If you 
wrote a module that added a citation style \bibtexkey to actually 
output the BibTeX key itself in the PDF, you would also add a template 
in the CiteFormat block so that the UI reflects this. We can also add 
a number of the yet unsupported jurabib citation styles and so on.


Presumably this will be especially useful for BibLaTeX, where formats 
are much easier to write.


Richard

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Pavel Sanda]

uwesto...@lyx.org wrote:
 Author: uwestoehr
 Date: Mon Jan 23 02:49:49 2012
 New Revision: 40663
 URL: http://www.lyx.org/trac/changeset/40663
 
 Log:
 add support for the package cancel in math (fixes #6819); fileformat change 
 only for the preamble handling
 
 + /// Nothing for HTML
 + void htmlize(HtmlStream ) const {}

what about using del tag ?

pavel

Re: Memory leak ?

[Vincent van Ravesteijn]

Op 23-1-2012 15:54, Richard Heck schreef:

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
-01.02% (303,120B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.16% (972,720B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, but 
we do not, it is true, release the TextClass objects that are 
associated with them. There's actually a good reason for that where 
ordinary Buffers are concerned---there could be something on the cut 
stack that still has a reference to the TextClass in question---but in 
the case of AutoSave, there is no reason we need to keep these around. 
See the comments at the end of TextClass.h, concerning the 
DocumentClassBundle.


I'll try to have a look shortly, but classes start again on Wednesday. 
If anyone else had ideas, I'd be happy to hear them.


Richard



We don't need a new TextClass everytime. If we already have one for the 
documentclass/layout, we can reuse it again.


This also means that with every preview we lose memory.

Vincent

Re: r40656 - lyx-devel/trunk/src/insets

[Vincent van Ravesteijn]

Op 22-1-2012 22:44, v...@lyx.org schreef:

Author: vfr
Date: Sun Jan 22 22:44:27 2012
New Revision: 40656
URL: http://www.lyx.org/trac/changeset/40656

Log:
Fix bug #7644: Crash when copying table column or row

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Sun Jan 22 22:36:39 2012
(r40655)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Sun Jan 22 22:44:27 2012
(r40656)
@@ -759,14 +759,37 @@

  void Tabular::copyRow(row_type const row)
  {
-   row_info.insert(row_info.begin() + row, row_info[row]);
-   cell_info.insert(cell_info.begin() + row, cell_info[row]);
-
-   if (buffer().params().trackChanges)
-   for (col_type c = 0; c  ncols(); ++c)
+   row_info.insert(row_info.begin() + row + 1, RowData(row_info[row]));
+   cell_info.insert(cell_info.begin() + row + 1,
+   cell_vector(0, CellData(buffer_)));
+   
+   for (col_type c = 0; c  ncols(); ++c) {
+   cell_info[row + 1].insert(cell_info[row + 1].begin() + c,
+   CellData(cell_info[row][c]));
+   if (buffer().params().trackChanges)
cell_info[row + 
1][c].inset-setChange(Change(Change::INSERTED));
-
+   if (cell_info[row][c].multirow == CELL_BEGIN_OF_MULTIROW)
+   cell_info[row + 1][c].multirow = CELL_PART_OF_MULTIROW;
+   }
+   
updateIndexes();
+   for (col_type c = 0; c  ncols(); ++c) {
+   if (isPartOfMultiRow(row, c))
+   continue;
+   // inherit line settings
+   idx_type const i = cellIndex(row + 1, c);
+   idx_type const j = cellIndex(row, c);
+   setLeftLine(i, leftLine(j));
+   setRightLine(i, rightLine(j));
+   setTopLine(i, topLine(j));
+   if (topLine(j)  bottomLine(j)) {
+   setBottomLine(i, true);
+   setBottomLine(j, false);
+   }
+   // mark track changes
+   if (buffer().params().trackChanges)
+   cellInfo(i).inset-setChange(Change(Change::INSERTED));
+   }
  }


@@ -826,14 +849,30 @@
  void Tabular::copyColumn(col_type const col)
  {
BufferParams const  bp = buffer().params();
-   column_info.insert(column_info.begin() + col, column_info[col]);
+   column_info.insert(column_info.begin() + col + 1, 
ColumnData(column_info[col]));

for (row_type r = 0; r  nrows(); ++r) {
-   cell_info[r].insert(cell_info[r].begin() + col, 
cell_info[r][col]);
+   cell_info[r].insert(cell_info[r].begin() + col + 1, 
CellData(cell_info[r][col]));
if (bp.trackChanges)
cell_info[r][col + 
1].inset-setChange(Change(Change::INSERTED));
+   if (cell_info[r][col].multicolumn == CELL_BEGIN_OF_MULTICOLUMN)
+   cell_info[r][col + 1].multicolumn = 
CELL_PART_OF_MULTICOLUMN;
}
updateIndexes();
+   for (row_type r = 0; r  nrows(); ++r) {
+   // inherit line settings
+   idx_type const i = cellIndex(r, col + 1);
+   idx_type const j = cellIndex(r, col);
+   setBottomLine(i, bottomLine(j));
+   setTopLine(i, topLine(j));
+   setLeftLine(i, leftLine(j));
+   if (rightLine(j)  rightLine(j)) {
+   setRightLine(i, true);
+   setRightLine(j, false);
+   }
+   if (buffer().params().trackChanges)
+   cellInfo(i).inset-setChange(Change(Change::INSERTED));
+   }
  }



For branch ?

Vincent

Re: r40656 - lyx-devel/trunk/src/insets

[Richard Heck]

On 01/23/2012 12:07 PM, Vincent van Ravesteijn wrote:

Op 22-1-2012 22:44, v...@lyx.org schreef:

Author: vfr
Date: Sun Jan 22 22:44:27 2012
New Revision: 40656
URL: http://www.lyx.org/trac/changeset/40656

Log:
Fix bug #7644: Crash when copying table column or row

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp



For branch ?


If you're happy with it, sure.

Richard

Re: [patch] support for the LaTeX package cancel in math (bug 6819)

[Georg Baum]

Uwe Stöhr wrote:

 Am 07.01.2012 19:25, schrieb Georg Baum:
 
 This would be a fileformat change and will fix
 http://www.lyx.org/trac/ticket/6819 .

 I would prefer to fix the GUI first before adding more packages.
 
 In fact there is no GUI entry necessary.
 
 Is there a reason why one should not want to use cancel when entering
 the \cancel command? Is the intent of Georg's patch really to list all
 packages known to mankind, or only handle the few ones that are known to
 cause incompatibilities?

 I am aware of some issues that require to skip automatic loading of
 packages:

 1) Conflicts with self defined macros or other packages.
 
 Not the case for cancel. For self-defined commands it is the duty of the
 user to check possible interferences with packages. Our policy is not to
 try to provide workarounds for things the user can do wrong in the
 preamble.

Sometimes there are reasons why a user cannot decide himself. For example, 
document classes provided by publishers often define a lot of commands that 
need to be used. Or consider customized stuff at universities, or working 
with colleagues who come from LaTeX and still want to use the commands they 
are used to. \cancel is a quite generic name, so I would not be surprised to 
see it in personal or corporate macro collections.

 2) The user wants to provide an alternative definition of some commands.
 This is frequently the case for special symbols, e.g. \coloneq.
 mathtools.sty contains a generic definition, but if you use times fonts
 you might prefer the native character, which is made accessible by
 txfonts.sty.
 
 Not the case for cancel.
 (Btw. in this case the user could use TeX-code at the beginning of the
 document to redefine it.)

This does not work if the other stuff is loaded before cancel. In any case 
it is ugly.

 3) You use a combination of symbols that require two incompatible
 packages.
 
 Also not known for cancel. I had a look at the usual newsgroups and
 forums.

Yes, for cancel this is true.

 I do not think that each already supported package needs an auto setting,
 but I would not introduce support for new packages without it.
 
 I don't agree to this. The majority of our modules are there to add
 support for a certain package. There might always be conflicts to other
 packages, but unless no conflict was reported, we don't need to act. It is
 in my opinion not a good UI to provide expert stuff which is only
 hypothetically useful. For the rare cases where an expert user wants to
 play with packages and definitions, he can use the preamble or TeX-Code.

In fact this is not possible for packages loaded by math insets. It works 
for packages loaded by text insets: In this case the user simply does not 
need to use these insets, but write his own commands in ERT. Then LyX will 
not load any package for those commands. In math, there is no real ERT, 
since the math parser _always_ creates insets for known commands. Using ERT 
for the whole formula may be an option if these commands are isolated in 
simple formulas, but if they occur in bigger formulas putting the whole 
formula in ERT is not an option, since you do not understand the formula 
anymore without syntax highlighting.

 We should only provide an UI for packages where conflicts are known or
 cases like your second point.

You can make a UI that does not get in the way, e.g. where you only see 
those packages that are not set to default values, and the opther ones only 
if you want to change something. Apart from that this should clearly be 
labelled as expert stuff, so that people who do not understand what it means 
do not touch it.

I really do not understand why you are so reluctant to add this little 
setting. It have made it really easy now, and there are requests for even 
more control over autoloaded packages in trac, so why not start with this 
simple yet useful option?


Georg

Re: Memory leak ?

[Richard Heck]

On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote:

Op 23-1-2012 15:54, Richard Heck schreef:

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :

| A good tool to know where memory goes is the massif tool of 
valgrind.


This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
-01.02% (303,120B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.16% (972,720B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)
-04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, 
but we do not, it is true, release the TextClass objects that are 
associated with them. There's actually a good reason for that where 
ordinary Buffers are concerned---there could be something on the cut 
stack that still has a reference to the TextClass in question---but 
in the case of AutoSave, there is no reason we need to keep these 
around. See the comments at the end of TextClass.h, concerning the 
DocumentClassBundle.


I'll try to have a look shortly, but classes start again on 
Wednesday. If anyone else had ideas, I'd be happy to hear them.


Richard



We don't need a new TextClass everytime. If we already have one for 
the documentclass/layout, we can reuse it again.


I'm afraid it's more complicated than that. I mean, in principle we 
could do that, but the new TextClass (actually DocumentClass) object is 
created in the BufferParams constructor. I think I have a good idea what 
to do here, though. Minimally, we could delete the clone's DocumentClass 
on destruction since we know that no-one else will have a reference to it.



This also means that with every preview we lose memory.

Yes, this is all an unforeseen consequence of the cloning business. 
(Enrico strikes again!) But there are other places we create these 
objects and never get rid of them.


Richard

Re: SVN Down?

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

| Op 23-1-2012 1:47, Lars Gullik Bjønnes schreef:
 Jean-Marc Lasgoutteslasgout...@lyx.org  writes:

 | Le 22/01/12 14:00, Lars Gullik Bjønnes a écrit :
 | No problems here.  Neither with svn up nor when logging in ti trac.

 The dist was pretty full. I cleaned out some.
 | Last time I saw that, it was because of the svn dumps (I removed some
 | at that time). Can we make sure we keep less of these, in order to use
 | less disk?

 Yes, this time I will really fix it.

 | Unlss you found another good source of useless bits, of
 | course.
 | BTW, is our svn db backuped somewhere else?

 I do a back from time to time, and I have the git conversion that is
 continously updated.

| Is the git conversion already online and accessible somewhere ?

| Maybe we can continue to prepare the switch.

Hmm it could be on ipv6...
on ipv4 I have to fight against nat.

OTOH. it is not quite clear for being used.

-- 
   Lgb

Re: LyX 2.0.3

[Jean-Marc Lasgouttes]

Le 19/01/12 16:11, Richard Heck a écrit :


It has been almost two months since the release of LyX 2.0.2, and we
have collected a good number of fixes and updates, which you can find here:
http://www.lyx.org/trac/wiki/BugTrackerHome
You can find a list there, too, of bugs targeted to 2.0.3. Please let me
know if there are any that you think are essential before we release.

Once I have some input on this issue, I'll schedule the string freeze.


I'd like to add knitr support, (see #7887). It is a new module and some 
R support script.


JMarc

Re: LyX 2.0.3

[Richard Heck]

On 01/23/2012 05:43 PM, Jean-Marc Lasgouttes wrote:

Le 19/01/12 16:11, Richard Heck a écrit :


It has been almost two months since the release of LyX 2.0.2, and we
have collected a good number of fixes and updates, which you can find 
here:

http://www.lyx.org/trac/wiki/BugTrackerHome
You can find a list there, too, of bugs targeted to 2.0.3. Please let me
know if there are any that you think are essential before we release.

Once I have some input on this issue, I'll schedule the string freeze.


I'd like to add knitr support, (see #7887). It is a new module and 
some R support script.


OK, the module will change strings. How soon can that go? If necessary, 
you could add a stub of the module and finish the actual work before 
release.


rh

Re: r40670 - lyx-devel/trunk/lib

[Richard Heck]

On 01/23/2012 06:02 PM, lasgout...@lyx.org wrote:

Author: lasgouttes
Date: Tue Jan 24 00:02:53 2012
New Revision: 40670
URL: http://www.lyx.org/trac/changeset/40670

Log:
Forgot that in r40669.

I assume these are also needed in branch. If so, please go ahead.

rh

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Uwe Stöhr]

Am 23.01.2012 16:48, schrieb Pavel Sanda:


+   /// Nothing for HTML
+   void htmlize(HtmlStream) const {}


what about usingdel  tag ?


I don't nkow. I only used Richard's standard solution to be comliant with the 
other mathed files.

regards Uwe

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Uwe Stöhr]

Am 23.01.2012 15:27, schrieb Vincent van Ravesteijn:


revert = [
- [423, [revert_cite_engine_type]],
+ [424, [revert_cancel]],
+ [423, [revert_cite_engine_type, revert_cancel]],
[422, [revert_use_mathtools]],
[421, [revert_use_packages]],
[420, [revert_longtable_captions]],


Is it intended to revert_cancel when going to format 423 ?


This was a mistake. (Leftover from testing.) It is already kindly corrected now.

regards Uwe

Re: Memory leak ?

[Stephan Witt]

Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes:

> Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
>> My testing so far says the opposite. We are continually using more and
>> more memory. Not especially fast, but it is there.
> 
> A good tool to know where memory goes is the massif tool of valgrind.

I've tried to use Instruments Leak-Detector on Mac.

1. It doesn't find any suspicious leaks - the growing memory is not lost.
2. The growing memory is allocated in TextClass constructor - about 40k per 
autosave operation.
3. Call Stack:

Total % Bytes   Library Symbol Name
...
11.41.65 MB lyx::frontend::GuiView::autoSave()
11.41.64 MB lyx::Buffer::cloneBufferOnly() const
11.41.64 MB lyx::Buffer::Buffer(std::string const&, bool, lyx::Buffer 
const*)
11.41.64 MB lyx::Buffer::Impl::Impl(lyx::Buffer*, lyx::support::FileName 
const&, bool, lyx::Buffer const*)
11.41.64 MB lyx::BufferParams::BufferParams()
11.41.64 MB lyx::BufferParams::makeDocumentClass()
11.41.64 MB lyx::DocumentClassBundle::makeDocumentClass(lyx::LayoutFile 
const&, lyx::LayoutModuleList const&)
11.41.64 MB lyx::DocumentClassBundle::newClass(lyx::LayoutFile const&)
11.21.61 MB lyx::DocumentClass::DocumentClass(lyx::LayoutFile const&)
11.21.61 MB lyx::TextClass::TextClass(lyx::TextClass const&)

1 minute later

Total % Bytes   Library Symbol Name
...
11.71.69 MB lyx::DocumentClassBundle::newClass(lyx::LayoutFile const&)
11.41.65 MB lyx::TextClass::TextClass(lyx::TextClass const&)

Stephan

Re: Memory leak ?

[Jean-Marc Lasgouttes]

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I think 
that we never release buffers cloned by autosave.


JMarc

Re: [patch] move citation engine to layout modules

[Julien Rioux]

On 01/21/2012 09:49 PM, Richard Heck wrote:

On 01/10/2012 09:19 PM, Julien Rioux wrote:

Looking for your comments!


The approach looks very good to me, though the patch is so
huge---unavoidably so, to be sure---that it's hard to have much to say
about the details.

Can you say a bit about the format of the CiteFormat entries? I take it
you are reusing the RefStyle formats a bit here.

Richard



Hi Richard,

I'm not sure what RefStyle formats are. What I'm reusing is the 
CiteFormat block since it allows templating and extracting information 
from citation entries. It was already part of the layout syntax so I 
could avoid rewriting a bunch of stuff.


This CiteFormat infrastructure is used to provide e.g. the little 
preview of a citation entry in the Citation dialog, with templates for 
"article", "book" and so on... In this new patch I add templates for 
"cite" "citep" "citet" "citeyear" etc. and use those in the GUI. To the 
CiteFormat block I added an argument, either authoryear or numerical, so 
that different templates are used reflecting e.g. the output of the 
latex command \citep which depends on the natbib option used.


The nice thing about having everything (well, almost) in the layout file 
is that customization is flexible and relatively easy. If you wrote a 
module that added a citation style \bibtexkey to actually output the 
BibTeX key itself in the PDF, you would also add a template in the 
CiteFormat block so that the UI reflects this. We can also add a number 
of the yet unsupported jurabib citation styles and so on.


Cheers,
Julien

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Vincent van Ravesteijn]

Op 23-1-2012 2:49, uwesto...@lyx.org schreef:

Author: uwestoehr
Date: Mon Jan 23 02:49:49 2012
New Revision: 40663
URL: http://www.lyx.org/trac/changeset/40663


  revert =  [
-   [423, [revert_cite_engine_type]],
+   [424, [revert_cancel]],
+   [423, [revert_cite_engine_type, revert_cancel]],
 [422, [revert_use_mathtools]],
 [421, [revert_use_packages]],
 [420, [revert_longtable_captions]],


Uwe,

Is it intended to revert_cancel when going to format 423 ?

Vincent

Re: Memory leak ?

[Richard Heck]

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass 
const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, but 
we do not, it is true, release the TextClass objects that are associated 
with them. There's actually a good reason for that where ordinary 
Buffers are concerned---there could be something on the cut stack that 
still has a reference to the TextClass in question---but in the case of 
AutoSave, there is no reason we need to keep these around. See the 
comments at the end of TextClass.h, concerning the DocumentClassBundle.


I'll try to have a look shortly, but classes start again on Wednesday. 
If anyone else had ideas, I'd be happy to hear them.


Richard

Re: SVN Down?

[Vincent van Ravesteijn]

Op 23-1-2012 1:47, Lars Gullik Bjønnes schreef:

Jean-Marc Lasgouttes  writes:

| Le 22/01/12 14:00, Lars Gullik Bjønnes a écrit :

| No problems here.  Neither with svn up nor when logging in ti trac.

The dist was pretty full. I cleaned out some.

| Last time I saw that, it was because of the svn dumps (I removed some
| at that time). Can we make sure we keep less of these, in order to use
| less disk?

Yes, this time I will really fix it.

| Unlss you found another good source of useless bits, of
| course.
| BTW, is our svn db backuped somewhere else?

I do a back from time to time, and I have the git conversion that is
continously updated.


Is the git conversion already online and accessible somewhere ?

Maybe we can continue to prepare the switch.

Vincent

Re: [patch] move citation engine to layout modules

[Richard Heck]

On 01/23/2012 08:21 AM, Julien Rioux wrote:

On 01/21/2012 09:49 PM, Richard Heck wrote:

On 01/10/2012 09:19 PM, Julien Rioux wrote:

Looking for your comments!


The approach looks very good to me, though the patch is so
huge---unavoidably so, to be sure---that it's hard to have much to say
about the details.

Can you say a bit about the format of the CiteFormat entries? I take it
you are reusing the RefStyle formats a bit here.

Richard



Hi Richard,

I'm not sure what RefStyle formats are. What I'm reusing is the 
CiteFormat block since it allows templating and extracting information 
from citation entries. It was already part of the layout syntax so I 
could avoid rewriting a bunch of stuff.



Yes, sorry, that's what I meant.

This CiteFormat infrastructure is used to provide e.g. the little 
preview of a citation entry in the Citation dialog, with templates for 
"article", "book" and so on... In this new patch I add templates for 
"cite" "citep" "citet" "citeyear" etc. and use those in the GUI. To 
the CiteFormat block I added an argument, either authoryear or 
numerical, so that different templates are used reflecting e.g. the 
output of the latex command \citep which depends on the natbib option 
used.



OK, I understand.

The nice thing about having everything (well, almost) in the layout 
file is that customization is flexible and relatively easy. If you 
wrote a module that added a citation style \bibtexkey to actually 
output the BibTeX key itself in the PDF, you would also add a template 
in the CiteFormat block so that the UI reflects this. We can also add 
a number of the yet unsupported jurabib citation styles and so on.


Presumably this will be especially useful for BibLaTeX, where formats 
are much easier to write.


Richard

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Pavel Sanda]

uwesto...@lyx.org wrote:
> Author: uwestoehr
> Date: Mon Jan 23 02:49:49 2012
> New Revision: 40663
> URL: http://www.lyx.org/trac/changeset/40663
> 
> Log:
> add support for the package cancel in math (fixes #6819); fileformat change 
> only for the preamble handling
> 
> + /// Nothing for HTML
> + void htmlize(HtmlStream &) const {}

what about using  tag ?

pavel

Re: Memory leak ?

[Vincent van Ravesteijn]

Op 23-1-2012 15:54, Richard Heck schreef:

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :


| A good tool to know where memory goes is the massif tool of valgrind.

This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, but 
we do not, it is true, release the TextClass objects that are 
associated with them. There's actually a good reason for that where 
ordinary Buffers are concerned---there could be something on the cut 
stack that still has a reference to the TextClass in question---but in 
the case of AutoSave, there is no reason we need to keep these around. 
See the comments at the end of TextClass.h, concerning the 
DocumentClassBundle.


I'll try to have a look shortly, but classes start again on Wednesday. 
If anyone else had ideas, I'd be happy to hear them.


Richard



We don't need a new TextClass everytime. If we already have one for the 
documentclass/layout, we can reuse it again.


This also means that with every preview we lose memory.

Vincent

Re: r40656 - lyx-devel/trunk/src/insets

[Vincent van Ravesteijn]

Op 22-1-2012 22:44, v...@lyx.org schreef:

Author: vfr
Date: Sun Jan 22 22:44:27 2012
New Revision: 40656
URL: http://www.lyx.org/trac/changeset/40656

Log:
Fix bug #7644: Crash when copying table column or row

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Sun Jan 22 22:36:39 2012
(r40655)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Sun Jan 22 22:44:27 2012
(r40656)
@@ -759,14 +759,37 @@

  void Tabular::copyRow(row_type const row)
  {
-   row_info.insert(row_info.begin() + row, row_info[row]);
-   cell_info.insert(cell_info.begin() + row, cell_info[row]);
-
-   if (buffer().params().trackChanges)
-   for (col_type c = 0; c<  ncols(); ++c)
+   row_info.insert(row_info.begin() + row + 1, RowData(row_info[row]));
+   cell_info.insert(cell_info.begin() + row + 1,
+   cell_vector(0, CellData(buffer_)));
+   
+   for (col_type c = 0; c<  ncols(); ++c) {
+   cell_info[row + 1].insert(cell_info[row + 1].begin() + c,
+   CellData(cell_info[row][c]));
+   if (buffer().params().trackChanges)
cell_info[row + 
1][c].inset->setChange(Change(Change::INSERTED));
-
+   if (cell_info[row][c].multirow == CELL_BEGIN_OF_MULTIROW)
+   cell_info[row + 1][c].multirow = CELL_PART_OF_MULTIROW;
+   }
+   
updateIndexes();
+   for (col_type c = 0; c<  ncols(); ++c) {
+   if (isPartOfMultiRow(row, c))
+   continue;
+   // inherit line settings
+   idx_type const i = cellIndex(row + 1, c);
+   idx_type const j = cellIndex(row, c);
+   setLeftLine(i, leftLine(j));
+   setRightLine(i, rightLine(j));
+   setTopLine(i, topLine(j));
+   if (topLine(j)&&  bottomLine(j)) {
+   setBottomLine(i, true);
+   setBottomLine(j, false);
+   }
+   // mark track changes
+   if (buffer().params().trackChanges)
+   cellInfo(i).inset->setChange(Change(Change::INSERTED));
+   }
  }


@@ -826,14 +849,30 @@
  void Tabular::copyColumn(col_type const col)
  {
BufferParams const&  bp = buffer().params();
-   column_info.insert(column_info.begin() + col, column_info[col]);
+   column_info.insert(column_info.begin() + col + 1, 
ColumnData(column_info[col]));

for (row_type r = 0; r<  nrows(); ++r) {
-   cell_info[r].insert(cell_info[r].begin() + col, 
cell_info[r][col]);
+   cell_info[r].insert(cell_info[r].begin() + col + 1, 
CellData(cell_info[r][col]));
if (bp.trackChanges)
cell_info[r][col + 
1].inset->setChange(Change(Change::INSERTED));
+   if (cell_info[r][col].multicolumn == CELL_BEGIN_OF_MULTICOLUMN)
+   cell_info[r][col + 1].multicolumn = 
CELL_PART_OF_MULTICOLUMN;
}
updateIndexes();
+   for (row_type r = 0; r<  nrows(); ++r) {
+   // inherit line settings
+   idx_type const i = cellIndex(r, col + 1);
+   idx_type const j = cellIndex(r, col);
+   setBottomLine(i, bottomLine(j));
+   setTopLine(i, topLine(j));
+   setLeftLine(i, leftLine(j));
+   if (rightLine(j)&&  rightLine(j)) {
+   setRightLine(i, true);
+   setRightLine(j, false);
+   }
+   if (buffer().params().trackChanges)
+   cellInfo(i).inset->setChange(Change(Change::INSERTED));
+   }
  }



For branch ?

Vincent

Re: r40656 - lyx-devel/trunk/src/insets

[Richard Heck]

On 01/23/2012 12:07 PM, Vincent van Ravesteijn wrote:

Op 22-1-2012 22:44, v...@lyx.org schreef:

Author: vfr
Date: Sun Jan 22 22:44:27 2012
New Revision: 40656
URL: http://www.lyx.org/trac/changeset/40656

Log:
Fix bug #7644: Crash when copying table column or row

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp



For branch ?


If you're happy with it, sure.

Richard

Re: [patch] support for the LaTeX package cancel in math (bug 6819)

[Georg Baum]

Uwe Stöhr wrote:

> Am 07.01.2012 19:25, schrieb Georg Baum:
> 
 This would be a fileformat change and will fix
 http://www.lyx.org/trac/ticket/6819 .
>>
>> I would prefer to fix the GUI first before adding more packages.
> 
> In fact there is no GUI entry necessary.
> 
>>> Is there a reason why one should not want to use cancel when entering
>>> the \cancel command? Is the intent of Georg's patch really to list all
>>> packages known to mankind, or only handle the few ones that are known to
>>> cause incompatibilities?
>>
>> I am aware of some issues that require to skip automatic loading of
>> packages:
>>
>> 1) Conflicts with self defined macros or other packages.
> 
> Not the case for cancel. For self-defined commands it is the duty of the
> user to check possible interferences with packages. Our policy is not to
> try to provide workarounds for things the user can do wrong in the
> preamble.

Sometimes there are reasons why a user cannot decide himself. For example, 
document classes provided by publishers often define a lot of commands that 
need to be used. Or consider customized stuff at universities, or working 
with colleagues who come from LaTeX and still want to use the commands they 
are used to. \cancel is a quite generic name, so I would not be surprised to 
see it in personal or corporate macro collections.

>> 2) The user wants to provide an alternative definition of some commands.
>> This is frequently the case for special symbols, e.g. \coloneq.
>> mathtools.sty contains a generic definition, but if you use times fonts
>> you might prefer the native character, which is made accessible by
>> txfonts.sty.
> 
> Not the case for cancel.
> (Btw. in this case the user could use TeX-code at the beginning of the
> document to redefine it.)

This does not work if the other stuff is loaded before cancel. In any case 
it is ugly.

>> 3) You use a combination of symbols that require two incompatible
>> packages.
> 
> Also not known for cancel. I had a look at the usual newsgroups and
> forums.

Yes, for cancel this is true.

>> I do not think that each already supported package needs an auto setting,
>> but I would not introduce support for new packages without it.
> 
> I don't agree to this. The majority of our modules are there to add
> support for a certain package. There might always be conflicts to other
> packages, but unless no conflict was reported, we don't need to act. It is
> in my opinion not a good UI to provide expert stuff which is only
> hypothetically useful. For the rare cases where an expert user wants to
> play with packages and definitions, he can use the preamble or TeX-Code.

In fact this is not possible for packages loaded by math insets. It works 
for packages loaded by text insets: In this case the user simply does not 
need to use these insets, but write his own commands in ERT. Then LyX will 
not load any package for those commands. In math, there is no real ERT, 
since the math parser _always_ creates insets for known commands. Using ERT 
for the whole formula may be an option if these commands are isolated in 
simple formulas, but if they occur in bigger formulas putting the whole 
formula in ERT is not an option, since you do not understand the formula 
anymore without syntax highlighting.

> We should only provide an UI for packages where conflicts are known or
> cases like your second point.

You can make a UI that does not get in the way, e.g. where you only see 
those packages that are not set to default values, and the opther ones only 
if you want to change something. Apart from that this should clearly be 
labelled as expert stuff, so that people who do not understand what it means 
do not touch it.

I really do not understand why you are so reluctant to add this little 
setting. It have made it really easy now, and there are requests for even 
more control over autoloaded packages in trac, so why not start with this 
simple yet useful option?


Georg

Re: Memory leak ?

[Richard Heck]

On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote:

Op 23-1-2012 15:54, Richard Heck schreef:

On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:

Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :

| A good tool to know where memory goes is the massif tool of 
valgrind.


This is the result from a ~6hrs run.
I am not quite sure how to read it.


Like what Stephan reported, we see:

fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F: 
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)


We see that the number of allocated TextClass objects increses. I 
think that we never release buffers cloned by autosave.


I think I understand what's going on here. We release the Buffers, 
but we do not, it is true, release the TextClass objects that are 
associated with them. There's actually a good reason for that where 
ordinary Buffers are concerned---there could be something on the cut 
stack that still has a reference to the TextClass in question---but 
in the case of AutoSave, there is no reason we need to keep these 
around. See the comments at the end of TextClass.h, concerning the 
DocumentClassBundle.


I'll try to have a look shortly, but classes start again on 
Wednesday. If anyone else had ideas, I'd be happy to hear them.


Richard



We don't need a new TextClass everytime. If we already have one for 
the documentclass/layout, we can reuse it again.


I'm afraid it's more complicated than that. I mean, in principle we 
could do that, but the new TextClass (actually DocumentClass) object is 
created in the BufferParams constructor. I think I have a good idea what 
to do here, though. Minimally, we could delete the clone's DocumentClass 
on destruction since we know that no-one else will have a reference to it.



This also means that with every preview we lose memory.

Yes, this is all an unforeseen consequence of the cloning business. 
(Enrico strikes again!) But there are other places we create these 
objects and never get rid of them.


Richard

Re: SVN Down?

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

| Op 23-1-2012 1:47, Lars Gullik Bjønnes schreef:
>> Jean-Marc Lasgouttes  writes:
>>
>> | Le 22/01/12 14:00, Lars Gullik Bjønnes a écrit :
 | No problems here.  Neither with svn up nor when logging in ti trac.

 The dist was pretty full. I cleaned out some.
>> | Last time I saw that, it was because of the svn dumps (I removed some
>> | at that time). Can we make sure we keep less of these, in order to use
>> | less disk?
>>
>> Yes, this time I will really fix it.
>>
>> | Unlss you found another good source of useless bits, of
>> | course.
>> | BTW, is our svn db backuped somewhere else?
>>
>> I do a back from time to time, and I have the git conversion that is
>> continously updated.
>
| Is the git conversion already online and accessible somewhere ?
>
| Maybe we can continue to prepare the switch.

Hmm it could be on ipv6...
on ipv4 I have to fight against nat.

OTOH. it is not quite clear for being used.

-- 
   Lgb

Re: LyX 2.0.3

[Jean-Marc Lasgouttes]

Le 19/01/12 16:11, Richard Heck a écrit :


It has been almost two months since the release of LyX 2.0.2, and we
have collected a good number of fixes and updates, which you can find here:
http://www.lyx.org/trac/wiki/BugTrackerHome
You can find a list there, too, of bugs targeted to 2.0.3. Please let me
know if there are any that you think are essential before we release.

Once I have some input on this issue, I'll schedule the string freeze.


I'd like to add knitr support, (see #7887). It is a new module and some 
R support script.


JMarc

Re: LyX 2.0.3

[Richard Heck]

On 01/23/2012 05:43 PM, Jean-Marc Lasgouttes wrote:

Le 19/01/12 16:11, Richard Heck a écrit :


It has been almost two months since the release of LyX 2.0.2, and we
have collected a good number of fixes and updates, which you can find 
here:

http://www.lyx.org/trac/wiki/BugTrackerHome
You can find a list there, too, of bugs targeted to 2.0.3. Please let me
know if there are any that you think are essential before we release.

Once I have some input on this issue, I'll schedule the string freeze.


I'd like to add knitr support, (see #7887). It is a new module and 
some R support script.


OK, the module will change strings. How soon can that go? If necessary, 
you could add a stub of the module and finish the actual work before 
release.


rh

Re: r40670 - lyx-devel/trunk/lib

[Richard Heck]

On 01/23/2012 06:02 PM, lasgout...@lyx.org wrote:

Author: lasgouttes
Date: Tue Jan 24 00:02:53 2012
New Revision: 40670
URL: http://www.lyx.org/trac/changeset/40670

Log:
Forgot that in r40669.

I assume these are also needed in branch. If so, please go ahead.

rh

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Uwe Stöhr]

Am 23.01.2012 16:48, schrieb Pavel Sanda:


+   /// Nothing for HTML
+   void htmlize(HtmlStream&) const {}


what about using  tag ?


I don't nkow. I only used Richard's standard solution to be comliant with the 
other mathed files.

regards Uwe

Re: r40663 - in lyx-devel/trunk: development/scons lib lib/lyx2lyx src src/insets src/mathed

[Uwe Stöhr]

Am 23.01.2012 15:27, schrieb Vincent van Ravesteijn:


revert = [
- [423, [revert_cite_engine_type]],
+ [424, [revert_cancel]],
+ [423, [revert_cite_engine_type, revert_cancel]],
[422, [revert_use_mathtools]],
[421, [revert_use_packages]],
[420, [revert_longtable_captions]],


Is it intended to revert_cancel when going to format 423 ?


This was a mistake. (Leftover from testing.) It is already kindly corrected now.

regards Uwe