<feed xmlns='http://www.w3.org/2005/Atom'>
<title>rep.git/chain/src/item/default/splone.rs, branch attempt1</title>
<subtitle>Parser generator for Emacs written in Rust
</subtitle>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/'/>
<entry>
<title>new start</title>
<updated>2026-10-16T06:02:10+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2026-10-16T06:01:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=fba9a90cfc6aca2a26cce72f55fb261789139781'/>
<id>fba9a90cfc6aca2a26cce72f55fb261789139781</id>
<content type='text'>
Now I tested and discussed with claude, and had a working version of
this project.  The rest is to port the claude version to my own
writings.  So this serves as the starting point before that attempt.

In the new attempt the design is better, and a number of bugs were
found and supposedly fixed, so let us see how this goes at the end.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now I tested and discussed with claude, and had a working version of
this project.  The rest is to port the claude version to my own
writings.  So this serves as the starting point before that attempt.

In the new attempt the design is better, and a number of bugs were
found and supposedly fixed, so let us see how this goes at the end.
</pre>
</div>
</content>
</entry>
<entry>
<title>splone: fix the bug of finding the wrong node</title>
<updated>2023-08-04T02:11:24+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-08-04T02:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=228b51fe7941e2b180ee3ea99dfea4bfcbd6770b'/>
<id>228b51fe7941e2b180ee3ea99dfea4bfcbd6770b</id>
<content type='text'>
* chain/src/item/default/splone.rs: A function for finding the node to
  plant used to ignore the condition that the children should match.
  Now this is fixed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* chain/src/item/default/splone.rs: A function for finding the node to
  plant used to ignore the condition that the children should match.
  Now this is fixed.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix some bugs</title>
<updated>2023-08-01T03:47:44+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-08-01T03:47:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=81854107bcf0b4480cfb11e8af7fec6894240c0c'/>
<id>81854107bcf0b4480cfb11e8af7fec6894240c0c</id>
<content type='text'>
Some bugs are fixed:

1. If a non-terminal expansion can be reduced immediately, previously
an extra node would be created that had no parents.  Now this strange
behaviour is corrected.

2. When performing reductions, a leaf non-terminal node would
previously be regarded as completed.  Now we will first try to
complete that node, and then determine if the completion is
successful, and finally determine the completedness according to the
result.

Of course some more tests are still pending, before I can confirm that
no more bugs lurk around.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some bugs are fixed:

1. If a non-terminal expansion can be reduced immediately, previously
an extra node would be created that had no parents.  Now this strange
behaviour is corrected.

2. When performing reductions, a leaf non-terminal node would
previously be regarded as completed.  Now we will first try to
complete that node, and then determine if the completion is
successful, and finally determine the completedness according to the
result.

Of course some more tests are still pending, before I can confirm that
no more bugs lurk around.
</pre>
</div>
</content>
</entry>
<entry>
<title>splone: splitting parents properly.</title>
<updated>2023-07-21T03:37:09+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-07-21T03:37:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=d31961c3ef5341413efb8681302ebd666dbcc4a5'/>
<id>d31961c3ef5341413efb8681302ebd666dbcc4a5</id>
<content type='text'>
* chain/src/item/default/splone.rs: Previouslt the function
  `split_node` used to split the parents of splitted nodes by an ugly
  logic.  Now that is moved into a dedicated function, which properly
  handles the splitting of parents, including the case when the new
  node is open whereas the old node is closed, in which situation we
  ought to put the new node under the opened node only, as a closed
  node cannot contain an open node as a child by definition.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* chain/src/item/default/splone.rs: Previouslt the function
  `split_node` used to split the parents of splitted nodes by an ugly
  logic.  Now that is moved into a dedicated function, which properly
  handles the splitting of parents, including the case when the new
  node is open whereas the old node is closed, in which situation we
  ought to put the new node under the opened node only, as a closed
  node cannot contain an open node as a child by definition.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix a bug of unnecessarily cloning nodes.</title>
<updated>2023-07-18T03:58:00+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-07-18T03:55:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=5a5f7e5be9498af219a36401b1d2a13b553402e8'/>
<id>5a5f7e5be9498af219a36401b1d2a13b553402e8</id>
<content type='text'>
* chain/src/item/default/splone.rs: Previously when we split nodes, we
  always clone the parent if the labels differ.  This turns out to be
  incorrect if the new label is open whereas the old label is closed.
  In that case, the old parent should not contain the new node as a
  child, as a closed node should not contain an open node.

  I am not yet entirely sure this fix is correct, so more test await
  us.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* chain/src/item/default/splone.rs: Previously when we split nodes, we
  always clone the parent if the labels differ.  This turns out to be
  incorrect if the new label is open whereas the old label is closed.
  In that case, the old parent should not contain the new node as a
  child, as a closed node should not contain an open node.

  I am not yet entirely sure this fix is correct, so more test await
  us.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix the bug of forgetting to check cloned nodes.</title>
<updated>2023-07-16T10:06:18+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-07-16T10:06:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=780f3cc80cadf87ecfdb702ef90fcb606f2783fd'/>
<id>780f3cc80cadf87ecfdb702ef90fcb606f2783fd</id>
<content type='text'>
In the process of splitting, cloning, and planting the forest, I
forgot to check whether some cloned node of the node inquestion
satisfy the condition.  This used to cause forests that violate some
fundamental assumptions.  Now this is supposed to be fixed, but more
tests await us.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the process of splitting, cloning, and planting the forest, I
forgot to check whether some cloned node of the node inquestion
satisfy the condition.  This used to cause forests that violate some
fundamental assumptions.  Now this is supposed to be fixed, but more
tests await us.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix the bug of testing prefixes and planting</title>
<updated>2023-07-12T02:29:50+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-07-12T02:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=cd977c17ee5cd4ef68d0021dc69c131364122376'/>
<id>cd977c17ee5cd4ef68d0021dc69c131364122376</id>
<content type='text'>
Previously the functions `is_prefix` and `plant` did not take the
situation of packed nodes into considerations.  That was because I
only dealt with non-packed nodes in the past: the fragment to test for
prefixes and for planting did not intersect the packed nodes in the
forest, and the grammar is so simple that the fragments do not contain
packed nodes.

Then a test revealed this situation, so I have to fix this lack of
considerations now.  This commit attempts to fix this issue.

From the newly added unit-tests, it seems that this fix works.  :)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously the functions `is_prefix` and `plant` did not take the
situation of packed nodes into considerations.  That was because I
only dealt with non-packed nodes in the past: the fragment to test for
prefixes and for planting did not intersect the packed nodes in the
forest, and the grammar is so simple that the fragments do not contain
packed nodes.

Then a test revealed this situation, so I have to fix this lack of
considerations now.  This commit attempts to fix this issue.

From the newly added unit-tests, it seems that this fix works.  :)
</pre>
</div>
</content>
</entry>
<entry>
<title>Finished the Emacs binding.</title>
<updated>2023-07-08T04:31:13+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-07-08T04:30:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=9a317e56f8a6126583f7d0c431bf878d9b1fe7b1'/>
<id>9a317e56f8a6126583f7d0c431bf878d9b1fe7b1</id>
<content type='text'>
Now the binding part is finished.

What remains is a bug encountered when planting a fragment to the
forest which intersects a packed node, which would lead to invalid
forests.  This will also cause problem when planting a packed
fragment, but until now my testing grammars do not produce packed
fragments, so this problem is not encountered yet.

I am still figuring out efficient ways to solve this problem.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now the binding part is finished.

What remains is a bug encountered when planting a fragment to the
forest which intersects a packed node, which would lead to invalid
forests.  This will also cause problem when planting a packed
fragment, but until now my testing grammars do not produce packed
fragments, so this problem is not encountered yet.

I am still figuring out efficient ways to solve this problem.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed the bugs of node duplications and left-open nodes</title>
<updated>2023-06-18T07:03:34+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-06-18T07:03:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=a80db17473ff09cc72acba2c1975101e6dbedf39'/>
<id>a80db17473ff09cc72acba2c1975101e6dbedf39</id>
<content type='text'>
There were two main issues in the previous version.

One is that there are lots of duplications of nodes when manipulating
the forest.  This does not mean that labels repeat: by the use of the
data type this cannot happen.  What happened is that there were cloned
nodes whose children are exactly equal.  In this case there is no need
to clone that node in the first place.  This is now fixed by checking
carefully before cloning, so that we do not clone unnecessary nodes.

The other issue, which is perhaps more important, is that there are
nodes which are not closed.  This means that when there should be a
reuction of grammar rules, the forest does not mark the corresponding
node as already reduced.  The incorrect forests thus caused is hard to
fix: I tried several different approaches to fix it afterwards, but
all to no avail.  I also tried to record enough information to fix
these nodes during the manipulations.  It turned out that recording
nodes is a dead end, as I cannot properly syncronize the information
in the forest and the information in the chain-rule machine.  Any
inconsistencies will result in incorrect operations later on.

The approach I finally adapt is to perform every possible reduction at
each step.  This might lead to some more nodes than what we need.  But
those are technically expected to be there after all, and it is easy
to filter them out, so it is fine, from my point of view at the
moment.

Therefore, what remains is to filter those nodes out and connect it to
the holy Emacs.  :D
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There were two main issues in the previous version.

One is that there are lots of duplications of nodes when manipulating
the forest.  This does not mean that labels repeat: by the use of the
data type this cannot happen.  What happened is that there were cloned
nodes whose children are exactly equal.  In this case there is no need
to clone that node in the first place.  This is now fixed by checking
carefully before cloning, so that we do not clone unnecessary nodes.

The other issue, which is perhaps more important, is that there are
nodes which are not closed.  This means that when there should be a
reuction of grammar rules, the forest does not mark the corresponding
node as already reduced.  The incorrect forests thus caused is hard to
fix: I tried several different approaches to fix it afterwards, but
all to no avail.  I also tried to record enough information to fix
these nodes during the manipulations.  It turned out that recording
nodes is a dead end, as I cannot properly syncronize the information
in the forest and the information in the chain-rule machine.  Any
inconsistencies will result in incorrect operations later on.

The approach I finally adapt is to perform every possible reduction at
each step.  This might lead to some more nodes than what we need.  But
those are technically expected to be there after all, and it is easy
to filter them out, so it is fine, from my point of view at the
moment.

Therefore, what remains is to filter those nodes out and connect it to
the holy Emacs.  :D
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix a bug of duplication from planting after sploing</title>
<updated>2023-06-02T07:00:48+00:00</updated>
<author>
<name>JSDurand</name>
<email>mmemmew@gmail.com</email>
</author>
<published>2023-06-02T07:00:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.jsdurand.xyz/rep.git/commit/?id=8486474f377faf2d800d79166a7abe6b975e3e50'/>
<id>8486474f377faf2d800d79166a7abe6b975e3e50</id>
<content type='text'>
I should have staged and committed these changes separately, but I am
too lazy to deal with that.

The main changes in this commit are that I added the derive macro that
automates the delegation of the Graph trait.  This saves a lot of
boiler-plate codes.

The second main change, perhaps the most important one, is that I
found and tried to fix a bug that caused duplication of nodes.  The
bug arises from splitting or cloning a node multiple times, and
immediately planting the same fragment under the new "sploned" node.
That is, when we try to splone the node again, we found that we need
to splone, because the node that was created by the same sploning
process now has a different label because of the planting of the
fragment.  Then after the sploning, we plant the fragment again.  This
makes the newly sploned node have the same label (except for the clone
index) and the same children as the node that was sploned and planted
in the previous rounds.

The fix is to check for the existence of a node that has the same set
of children as the about-to-be-sploned node, except for the last one,
which contains the about-to-be-planted fragment as a prefix.  If that
is the case, treat it as an already existing node, so that we do not
have to splone the node again.

This is consistent with the principle to not create what we do not
need.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I should have staged and committed these changes separately, but I am
too lazy to deal with that.

The main changes in this commit are that I added the derive macro that
automates the delegation of the Graph trait.  This saves a lot of
boiler-plate codes.

The second main change, perhaps the most important one, is that I
found and tried to fix a bug that caused duplication of nodes.  The
bug arises from splitting or cloning a node multiple times, and
immediately planting the same fragment under the new "sploned" node.
That is, when we try to splone the node again, we found that we need
to splone, because the node that was created by the same sploning
process now has a different label because of the planting of the
fragment.  Then after the sploning, we plant the fragment again.  This
makes the newly sploned node have the same label (except for the clone
index) and the same children as the node that was sploned and planted
in the previous rounds.

The fix is to check for the existence of a node that has the same set
of children as the about-to-be-sploned node, except for the last one,
which contains the about-to-be-planted fragment as a prefix.  If that
is the case, treat it as an already existing node, so that we do not
have to splone the node again.

This is consistent with the principle to not create what we do not
need.
</pre>
</div>
</content>
</entry>
</feed>
