Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is 
possible with a macro and not with \frac.



But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in 
different branches. But this may not be exactly what you are after.



In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro 
would be possible as long as the parameters of the macros have the same 
structure. But switching from a two parameters macro to a one parameter 
one is trickier.



About toggling, they had this discussion before some years ago:
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)

Thanks,
JMarc

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place, then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

 Le 14/05/15 22:31, Guillaume M-M a écrit :
 My typical use case is to change the macro while keeping the same
 arguments. In the absolute, it is easy to see that this can be useful
 occasionally at least. Indeed, in the absence of macro-unfolding, the
 alternative is to copy and paste the arguments one by one from the old
 macro to the new macro. With unfolding, one just edits the name of the
 macro, benefiting from name completion, etc.
 
 I see it better now. It does not make much sense though that this is
 possible with a macro and not with \frac.

I agree.

 In fact, I do not care so much about macro unfolding itself than the
 possibility of changing the macro in-place (with name completion). Am I
 missing anything?
 
 I do not think you are missing something. Obviously, changing macro
 would be possible as long as the parameters of the macros have the same
 structure. But switching from a two parameters macro to a one parameter
 one is trickier.

Not too difficult. We already have the machinery to (re-)interpret TeX 
snippets (this is used on copying into math).

 About toggling, they had this discussion before some years ago:
 http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
 don't use repeated unfolding so much. In addition, I do not use macro
 folding because the macros folds itself automatically once the name is
 changed. (But if other power users of unfolding and folding are reading
 this they will surely speak up, right?)

 I hope this clarifies.
 
 Well it indeed clarifies that macro-unfold is a very weird concept :)

Indeed. If the main reason to unfold a macro is to be able to edit its name 
I think we can have this in a much more robust and general way (which would 
work not only for macros but for any command, e.g. \frac):

On unfolding, convert the macro or command including all arguments to a new 
type of inset. This inset would behave like InsetMathUnknown before it is 
finalized (this is the editable ERT that you get when you start typing a 
new command). The difference to InsetMathUnknown would be that the new inset 
would still have the cells of the inset it was converted from attached. When 
editing of the new inset is finished, it would be finalized automatically, 
i.e. converted again into a macro (or built-in command). At that time the 
cells would be re-attached to the final inset, and if it takes less 
arguments then the left over ones would be placed as independent insets 
after the converted one.

This is however a long-term solution. For the short term I will simply try 
to get rid of the ArgumentProxy insets in detachMacroParameters() and re-
interpret each cell. This might result in less good looking detached macro 
parameters, but I believe that this is acceptable.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

 Le 14/05/2015 21:00, Georg Baum a écrit :
 Jean-Marc Lasgouttes wrote:

 It is a dummy inset that can be used like a MathInset from outside, but
 forwards every work to the math macro cell that it represents. This
 allows to store the expanded cells in a standard MathData, and it also
 allows to manage the cells like any other math inset if they are detached
 from the macro (well it would allow that if the bug we are currently
 discussing would not exist).
 
 Is there one per macro use or one per argument?

One per argument.

 Would it make sense for the macro inset to hold a copy of the argument
 proxy instead of a pointer? And then this copy would be somehow updated
 as needed.

 It is the other way round: The proxy holds a pointer to the math macro.
 
 Could we make a copy of the macro, then?

I think so, but where to put it? This would need to be an invisible copy.

Anyway, see my other mail, the idea described there could work.


Georg

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is 
possible with a macro and not with \frac.



But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in 
different branches. But this may not be exactly what you are after.



In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro 
would be possible as long as the parameters of the macros have the same 
structure. But switching from a two parameters macro to a one parameter 
one is trickier.



About toggling, they had this discussion before some years ago:
. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)

Thanks,
JMarc

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is "how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place", then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 14/05/15 22:31, Guillaume M-M a écrit :
>> My typical use case is to change the macro while keeping the same
>> arguments. In the absolute, it is easy to see that this can be useful
>> occasionally at least. Indeed, in the absence of macro-unfolding, the
>> alternative is to copy and paste the arguments one by one from the old
>> macro to the new macro. With unfolding, one just edits the name of the
>> macro, benefiting from name completion, etc.
> 
> I see it better now. It does not make much sense though that this is
> possible with a macro and not with \frac.

I agree.

>> In fact, I do not care so much about macro unfolding itself than the
>> possibility of changing the macro in-place (with name completion). Am I
>> missing anything?
> 
> I do not think you are missing something. Obviously, changing macro
> would be possible as long as the parameters of the macros have the same
> structure. But switching from a two parameters macro to a one parameter
> one is trickier.

Not too difficult. We already have the machinery to (re-)interpret TeX 
snippets (this is used on copying into math).

>> About toggling, they had this discussion before some years ago:
>> . I admit that I
>> don't use repeated unfolding so much. In addition, I do not use macro
>> folding because the macros folds itself automatically once the name is
>> changed. (But if other power users of unfolding and folding are reading
>> this they will surely speak up, right?)
>>
>> I hope this clarifies.
> 
> Well it indeed clarifies that macro-unfold is a very weird concept :)

Indeed. If the main reason to unfold a macro is to be able to edit its name 
I think we can have this in a much more robust and general way (which would 
work not only for macros but for any command, e.g. \frac):

On unfolding, convert the macro or command including all arguments to a new 
type of inset. This inset would behave like InsetMathUnknown before it is 
finalized (this is the editable "ERT" that you get when you start typing a 
new command). The difference to InsetMathUnknown would be that the new inset 
would still have the cells of the inset it was converted from attached. When 
editing of the new inset is finished, it would be "finalized" automatically, 
i.e. converted again into a macro (or built-in command). At that time the 
cells would be re-attached to the final inset, and if it takes less 
arguments then the left over ones would be placed as independent insets 
after the converted one.

This is however a long-term solution. For the short term I will simply try 
to get rid of the ArgumentProxy insets in detachMacroParameters() and re-
interpret each cell. This might result in less good looking detached macro 
parameters, but I believe that this is acceptable.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 14/05/2015 21:00, Georg Baum a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>> It is a dummy inset that can be used like a MathInset from outside, but
>> forwards every work to the math macro cell that it represents. This
>> allows to store the expanded cells in a standard MathData, and it also
>> allows to manage the cells like any other math inset if they are detached
>> from the macro (well it would allow that if the bug we are currently
>> discussing would not exist).
> 
> Is there one per macro use or one per argument?

One per argument.

>>> Would it make sense for the macro inset to hold a copy of the argument
>>> proxy instead of a pointer? And then this copy would be somehow updated
>>> as needed.
>>
>> It is the other way round: The proxy holds a pointer to the math macro.
> 
> Could we make a copy of the macro, then?

I think so, but where to put it? This would need to be an invisible copy.

Anyway, see my other mail, the idea described there could work.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Guillaume M-M wrote:

 Thank you for looking at these bugs. I reported 9418 and 9490, and I use
 macro unfolding quite often. Before discovering this feature, I would
 occasionally edit the lyx file externally (!) to change certain macros.
 Given that the original bug was about a crash occurring during
 unfolding, the second solution is a bit like curing a pain by
 amputation...

Sure. However, as I understand it now, this feature is not implemented in a 
way that fits with the math inset infrastructure. I do not have the time for 
a complete rewrite, and I honestly don't know what to do. At least I know 
now that the fold/unfold feature is actually used.

 I would really appreciate a long-term solution to the math macro bugs.
 It would be useful to know whether many other people had segmentation
 faults because of macros, because I suspect that these crashes have been
 under-reported due to how hard they were to reproduce.

I believe that not so many people are macro power users. I would guess that 
we would get many more reports otherwise.


Georg

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 13/05/2015 22:34, Georg Baum a écrit :

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?


I think I do not understand yet what an argumentproxy really is. Could 
you explain that to me (again??)?


Would it make sense for the macro inset to hold a copy of the argument 
proxy instead of a pointer? And then this copy would be somehow updated 
as needed.


What is math macro unfolding exactly?

JMarc

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/14/15 19:46, Georg Baum wrote:

Guillaume M-M wrote:


Thank you for looking at these bugs. I reported 9418 and 9490, and I use
macro unfolding quite often. Before discovering this feature, I would
occasionally edit the lyx file externally (!) to change certain macros.
Given that the original bug was about a crash occurring during
unfolding, the second solution is a bit like curing a pain by
amputation...


Sure. However, as I understand it now, this feature is not implemented in a
way that fits with the math inset infrastructure. I do not have the time for
a complete rewrite, and I honestly don't know what to do. At least I know
now that the fold/unfold feature is actually used.


I would really appreciate a long-term solution to the math macro bugs.
It would be useful to know whether many other people had segmentation
faults because of macros, because I suspect that these crashes have been
under-reported due to how hard they were to reproduce.


I believe that not so many people are macro power users. I would guess that
we would get many more reports otherwise.


Georg





Do you think that it would solve all the crashes currently happening due 
to macros, or would your solution only prevent crashes happening while 
unfolding?


Personally I would rather suffer from the occasional crash than losing 
unfolding... :)



Guillaume

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/14/15 20:37, Jean-Marc Lasgouttes wrote:

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This
allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it,
then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that
I have tried it, I am not so sure why it is useful. Moreover it uses
bindings that are not accessible with my french kbd. Why doesn't this
use inset-toggle? Why isn't macro-fold a toggle?

JMarc




Dear Jean-Marc,


Macro power user here, as Georg wrote...

My typical use case is to change the macro while keeping the same 
arguments. In the absolute, it is easy to see that this can be useful 
occasionally at least. Indeed, in the absence of macro-unfolding, the 
alternative is to copy and paste the arguments one by one from the old 
macro to the new macro. With unfolding, one just edits the name of the 
macro, benefiting from name completion, etc.


But, also, once one is aware of unfolding, one can start using it more 
systematically, because one can define similar, but different, macros, 
and switch between them when it is needed. (I can give you practical 
examples if you want...) I currently do not know how to achieve 
something similar without unfolding.


In fact, I do not care so much about macro unfolding itself than the 
possibility of changing the macro in-place (with name completion). Am I 
missing anything?


About toggling, they had this discussion before some years ago: 
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I 
don't use repeated unfolding so much. In addition, I do not use macro 
folding because the macros folds itself automatically once the name is 
changed. (But if other power users of unfolding and folding are reading 
this they will surely speak up, right?)


I hope this clarifies.


Best
Guillaume

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

 I think I do not understand yet what an argumentproxy really is. Could
 you explain that to me (again??)?

It is a dummy inset that can be used like a MathInset from outside, but 
forwards every work to the math macro cell that it represents. This allows 
to store the expanded cells in a standard MathData, and it also allows to 
manage the cells like any other math inset if they are detached from the 
macro (well it would allow that if the bug we are currently dioscussing 
would not exist).

 Would it make sense for the macro inset to hold a copy of the argument
 proxy instead of a pointer? And then this copy would be somehow updated
 as needed.

It is the other way round: The proxy holds a pointer to the math macro.

 What is math macro unfolding exactly?

In folded mode, the macro itself is not drawn unless you enter it, then the 
name is drawn in light grey at the top left corner. In unfolded mode, the 
macro name is drawn like ERT, and you can change it.


Georg

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it, then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that 
I have tried it, I am not so sure why it is useful. Moreover it uses 
bindings that are not accessible with my french kbd. Why doesn't this 
use inset-toggle? Why isn't macro-fold a toggle?


JMarc

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 13/05/2015 22:34, Georg Baum a écrit :

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?


I think I do not understand yet what an argumentproxy really is. Could 
you explain that to me (again??)?


Would it make sense for the macro inset to hold a copy of the argument 
proxy instead of a pointer? And then this copy would be somehow updated 
as needed.


What is math macro unfolding exactly?

JMarc

Re: math macro crashes again (bug 9490)

[Georg Baum]

Guillaume M-M wrote:

> Thank you for looking at these bugs. I reported 9418 and 9490, and I use
> macro unfolding quite often. Before discovering this feature, I would
> occasionally edit the lyx file externally (!) to change certain macros.
> Given that the original bug was about a crash occurring during
> unfolding, the second solution is a bit like curing a pain by
> amputation...

Sure. However, as I understand it now, this feature is not implemented in a 
way that fits with the math inset infrastructure. I do not have the time for 
a complete rewrite, and I honestly don't know what to do. At least I know 
now that the fold/unfold feature is actually used.

> I would really appreciate a long-term solution to the math macro bugs.
> It would be useful to know whether many other people had segmentation
> faults because of macros, because I suspect that these crashes have been
> under-reported due to how hard they were to reproduce.

I believe that not so many people are macro power users. I would guess that 
we would get many more reports otherwise.


Georg

Re: math macro crashes again (bug 9490)

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> I think I do not understand yet what an argumentproxy really is. Could
> you explain that to me (again??)?

It is a dummy inset that can be used like a MathInset from outside, but 
forwards every work to the math macro cell that it represents. This allows 
to store the expanded cells in a standard MathData, and it also allows to 
manage the cells like any other math inset if they are detached from the 
macro (well it would allow that if the bug we are currently dioscussing 
would not exist).

> Would it make sense for the macro inset to hold a copy of the argument
> proxy instead of a pointer? And then this copy would be somehow updated
> as needed.

It is the other way round: The proxy holds a pointer to the math macro.

> What is math macro unfolding exactly?

In folded mode, the macro itself is not drawn unless you enter it, then the 
name is drawn in light grey at the top left corner. In unfolded mode, the 
macro name is drawn like ERT, and you can change it.


Georg

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/14/15 19:46, Georg Baum wrote:

Guillaume M-M wrote:


Thank you for looking at these bugs. I reported 9418 and 9490, and I use
macro unfolding quite often. Before discovering this feature, I would
occasionally edit the lyx file externally (!) to change certain macros.
Given that the original bug was about a crash occurring during
unfolding, the second solution is a bit like curing a pain by
amputation...


Sure. However, as I understand it now, this feature is not implemented in a
way that fits with the math inset infrastructure. I do not have the time for
a complete rewrite, and I honestly don't know what to do. At least I know
now that the fold/unfold feature is actually used.


I would really appreciate a long-term solution to the math macro bugs.
It would be useful to know whether many other people had segmentation
faults because of macros, because I suspect that these crashes have been
under-reported due to how hard they were to reproduce.


I believe that not so many people are macro power users. I would guess that
we would get many more reports otherwise.


Georg





Do you think that it would solve all the crashes currently happening due 
to macros, or would your solution only prevent crashes happening while 
unfolding?


Personally I would rather suffer from the occasional crash than losing 
unfolding... :)



Guillaume

Re: math macro crashes again (bug 9490)

[Jean-Marc Lasgouttes]

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it, then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that 
I have tried it, I am not so sure why it is useful. Moreover it uses 
bindings that are not accessible with my french kbd. Why doesn't this 
use inset-toggle? Why isn't macro-fold a toggle?


JMarc

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/14/15 20:37, Jean-Marc Lasgouttes wrote:

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This
allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it,
then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that
I have tried it, I am not so sure why it is useful. Moreover it uses
bindings that are not accessible with my french kbd. Why doesn't this
use inset-toggle? Why isn't macro-fold a toggle?

JMarc




Dear Jean-Marc,


"Macro power user" here, as Georg wrote...

My typical use case is to change the macro while keeping the same 
arguments. In the absolute, it is easy to see that this can be useful 
occasionally at least. Indeed, in the absence of macro-unfolding, the 
alternative is to copy and paste the arguments one by one from the old 
macro to the new macro. With unfolding, one just edits the name of the 
macro, benefiting from name completion, etc.


But, also, once one is aware of unfolding, one can start using it more 
systematically, because one can define similar, but different, macros, 
and switch between them when it is needed. (I can give you practical 
examples if you want...) I currently do not know how to achieve 
something similar without unfolding.


In fact, I do not care so much about macro unfolding itself than the 
possibility of changing the macro in-place (with name completion). Am I 
missing anything?


About toggling, they had this discussion before some years ago: 
. I admit that I 
don't use repeated unfolding so much. In addition, I do not use macro 
folding because the macros folds itself automatically once the name is 
changed. (But if other power users of unfolding and folding are reading 
this they will surely speak up, right?)


I hope this clarifies.


Best
Guillaume

math macro crashes again (bug 9490)

[Georg Baum]

Hi,

after a lot of debugging I understand now what happens in 
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro 
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_ 
pointer. At that time, I assumed that the only place where an ArgumentProxy 
can occur is as an element of MathMacro::d-expanded_ (which is also 
indicated by the comment in ArgumentProxy::draw(). Under this assumption, 
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(), 
elements of MathMacro::d-expanded_ can be extracted and put into the same 
vector as the macro itself. Unfortunately, if you insert an element into a 
vector, the existing elements may be copied = pointers may become invalid. 
The fix for 9419 does not work for this case, since the ArgumentProxy 
instances in question are already extracted from the macro and stored in the 
local variable detachedArgs.

It would be relatively easy to do a local fix in 
MathData::detachMacroParameters(). However, since the detached ArgumentProxy 
instances stay alive after leaving MathData::detachMacroParameters(), this 
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the 
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably 
whenever a copy of a MathMacro is made. This works fine, but exposes another 
problem: When following the recipe of bug 9490, a MathMacro instance is 
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing 
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel 
in the discussion of 9419. This would solve the invalid pointer problems, 
but not the problem showed by the undo stack, and I fear that more hidden 
problems like this one exist. To me it is now more clear than during the 
discussion of 9418 that the self-contained property of a MathInset is 
really really important and assumed implicitly all over the place. The 
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature 
regression: Unfolding a math macro would no longer be possible. Is this an 
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get 
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend 
towards the second item, since the first does not solve all problems, and 
the last is too much work for me ATM.



Georg

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d-expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d-expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied = pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the self-contained property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

math macro crashes again (bug 9490)

[Georg Baum]

Hi,

after a lot of debugging I understand now what happens in 
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro 
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_ 
pointer. At that time, I assumed that the only place where an ArgumentProxy 
can occur is as an element of MathMacro::d->expanded_ (which is also 
indicated by the comment in ArgumentProxy::draw(). Under this assumption, 
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(), 
elements of MathMacro::d->expanded_ can be extracted and put into the same 
vector as the macro itself. Unfortunately, if you insert an element into a 
vector, the existing elements may be copied => pointers may become invalid. 
The fix for 9419 does not work for this case, since the ArgumentProxy 
instances in question are already extracted from the macro and stored in the 
local variable detachedArgs.

It would be relatively easy to do a local fix in 
MathData::detachMacroParameters(). However, since the detached ArgumentProxy 
instances stay alive after leaving MathData::detachMacroParameters(), this 
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the 
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably 
whenever a copy of a MathMacro is made. This works fine, but exposes another 
problem: When following the recipe of bug 9490, a MathMacro instance is 
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing 
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel 
in the discussion of 9419. This would solve the invalid pointer problems, 
but not the problem showed by the undo stack, and I fear that more hidden 
problems like this one exist. To me it is now more clear than during the 
discussion of 9418 that the "self-contained" property of a MathInset is 
really really important and assumed implicitly all over the place. The 
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature 
regression: Unfolding a math macro would no longer be possible. Is this an 
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get 
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend 
towards the second item, since the first does not solve all problems, and 
the last is too much work for me ATM.



Georg

Re: math macro crashes again (bug 9490)

[Guillaume M-M]

On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d->expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d->expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied => pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the "self-contained" property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume