Re: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.

Re: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.

[Glenn Morris]

> branch: master
> commit badcd38aa86ed7973f2be2743c405710973a0bdd
> Author: Vincent Belaïche <vincentb1@users.sourceforge.net>
> Commit: Vincent Belaïche <vincentb1@users.sourceforge.net>
>
>     Correct a whole bunch of bugs coming with renamed cell relocation.

If these are bugs, I wonder if you wanted to fix them in the emacs-25 branch?
(I haven't looked at the code.)

Re: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.

[Vincent Belaïche]

Yes these are bugs, and they have been there since 2011 when I
introduced the renamed cell feature. I was aware fo them, and I really
should have corrected them earlier, but unfortunately I was too busy /
not enough motivated for that.
So yes, as these are bugs, I would like to port these correction also
on the emacs-25 branch.

After this, I think that I need to redesign the way th

2016-01-20 17:51 GMT+01:00 Glenn Morris <rgm@gnu.org>:
>
>> branch: master
>> commit badcd38aa86ed7973f2be2743c405710973a0bdd
>> Author: Vincent Belaïche <vincentb1@users.sourceforge.net>
>> Commit: Vincent Belaïche <vincentb1@users.sourceforge.net>
>>
>>     Correct a whole bunch of bugs coming with renamed cell relocation.
>
> If these are bugs, I wonder if you wanted to fix them in the emacs-25 branch?
> (I haven't looked at the code.)

Re: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.

[Glenn Morris]

Vincent Belaïche wrote:

> So yes, as these are bugs, I would like to port these correction also
> on the emacs-25 branch.

Ideally you would hop in your time machine and make the changes on the
emacs-25 branch in the first place, then let them get merged to master.
If you don't have a time machine to hand, then just do it that way next
time. :)

RE: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.

[Vincent Belaïche]

If I had a time machine at hand, I would first use it to correct
the biggest mistake I have done in my life... :-/

Anyway, as you noted I had sent my previous message before I
could finish writing it. Here is the continuation for information 
about my intentions concerning SES:

After this [porting the correction to emacs-25 branch], I think
that I need to redesign the way that SES does the whole
relocation in order to be able to support easily column/row/cell
transposition/permutation. The current scheme is that fomulas,
reference lists, deferred write list, and deferred eval list, all
of them contain cell symbols. I would like to change this and
have directly the cell structures (ie 5 element vectors harboring
almost all the cell data) instead of the symbols, or rather, as
far as formula are concerned, some sort of (ses* CELL) sexp
holding that cell structure CELL. This way, when doing any
permutation of cells you just need :

1) save the cell value from cell symbol to cell property list
2) carry out the cell permutation
3) to update the standard symbol (eg change A1 to B1 if you transpose
   the 2 first cells) in cells that were permutated, and push them to
   the deferred write list,
4) to get back the value from cell property into value of updated
   symbol

So you don't need any longer to do any changes in formulas or
reference lists. That would be quite more simple, IMHO, for all
relocations.

The cost of that (replacing symbols by cell) is to convert from
the cell structure to the cell symbol, resp. vice versa, in the
following occasion :

- writing resp. reading the SES file
- writing editing resp. reading editing the formula.


The motivation for such a change is that it would allow
completely generic permutation : in the current scheme you rely
on this that the permutation is a translation, so you can
relocate values by reading values before they are written. Well,
one could make this more generically, as any permutation can be
decomposed in finite number of cycles, and within a cycle you
could also propagate the move.

So, yes, I could also keep the current scheme of using symbols to
refer to cells, provided that cell value relocation is carried
out in a clever way.

But anyway, either way would require a rather deep redesign to
support generic cell permutation, and as far as this is needed I
had rather make it in a way which seems more adequate to me (ie
use cell rather than symbol to refer to cells).

The above would be some major change in SES, and since that does not
correct any bug, but rather enables new features/better maintenance,
that won't go the the emacs-25 branch.

   Vincent.

----------------------------------------
> From: rgm@gnu.org
> To: vincent.belaiche@gmail.com
> Subject: Re: master badcd38 1/2: Correct a whole bunch of bugs coming with renamed cell relocation.
> Date: Wed, 20 Jan 2016 14:42:46 -0500
> CC: emacs-devel@gnu.org
>
> Vincent Belaïche wrote:
>
>> So yes, as these are bugs, I would like to port these correction also
>> on the emacs-25 branch.
>
> Ideally you would hop in your time machine and make the changes on the
> emacs-25 branch in the first place, then let them get merged to master.
> If you don't have a time machine to hand, then just do it that way next
> time. :)
>