On Monday, July 14, 2014 2:00:48 PM UTC-5, Edward K. Ream wrote:
On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
I asked a vague question about the status of vc.find_absolute_unl_node
and vc.find_position_for_relative_unl the other day,
On Tue, 15 Jul 2014 04:39:06 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
On Monday, July 14, 2014 2:00:48 PM UTC-5, Edward K. Ream wrote:
On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
I asked a vague question about the
The repo now contains a rewritten, non-recursive, version of
pd.find_position_for_relative_unl.
Don't even *think* about replacing this code unless your code passes all
the test cases in @test pd.find_position_for_relative_unl. Previous
versions failed one or more parts of this test.
The new
On Tue, Jul 15, 2014 at 7:04 AM, 'Terry Brown' via leo-editor
It seems that the uA persisting code really should try and save uA info on
nodes it can't match...
So what I was thinking was that the orphan nodes could have an UNL (in
their uAs :-) which points to the best guess imported node,
On Tue, 15 Jul 2014 17:50:21 -0500
Edward K. Ream edream...@gmail.com wrote:
On Tue, Jul 15, 2014 at 7:04 AM, 'Terry Brown' via leo-editor
It seems that the uA persisting code really should try and save uA
info on nodes it can't match...
So what I was thinking was that the orphan nodes
