how the tier guide works

[davidjamesbeck]

I guess this isn't an issue, but I wanted to ask: as it is currently configured, the tierguide requires all and only the four "standard" lines, right? So we can't use an EAF file with only the textline and one translation.

BTW, I was going to add a Spanish translation to inferno.eaf, but it won't open in ELAN for me

[paul-shannon]

Hi Dad,

Two-tier models work. Try this:

cd ~/github/slexil/tests python test_text_MonkeyAndThunder.py open monkeyAndThunder.html

I cobbled inferno.eaf together manually. It -does- validate against the schema. Does ELAN give you an error message?

• Paul

On Mar 1, 2019, at 3:08 PM, David Beck notifications@github.com wrote:

I guess this isn't an issue, but I wanted to ask: as it is currently configured, the tierguide requires all and only the four "standard" lines, right? So we can't use an EAF file with only the textline and one translation.

BTW, I was going to add a Spanish translation to inferno.eaf, but it won't open in ELAN for me

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

On Mar 1, 2019, at 4:26 PM, Paul Shannon notifications@github.com wrote:

Hi Dad,

Two-tier models work. Try this:

cd ~/github/slexil/tests python test_text_MonkeyAndThunder.py open monkeyAndThunder.html

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

I cobbled inferno.eaf together manually. It -does- validate against the schema. Does ELAN give you an error message?

No, it just won’t open it—I get a blank project window. Now that may be because there is no .pfsx file. I’ve never been sure what those are, but ELAN makes one when you start a new project. Opening one (attached), it seems to be a kind of XML preferences file. (it would be like ELAN not to create a self-contained project file.) But let’s not worry about it, I just thought it would be more economical to use our little demo file for as much as possible.

• Paul

On Mar 1, 2019, at 3:08 PM, David Beck notifications@github.com wrote:

I guess this isn't an issue, but I wanted to ask: as it is currently configured, the tierguide requires all and only the four "standard" lines, right? So we can't use an EAF file with only the textline and one translation.

BTW, I was going to add a Spanish translation to inferno.eaf, but it won't open in ELAN for me

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468846674, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhknkpow877rAFqOpkWrhQuezXGMgks5vSbcqgaJpZM4bZ-Kc.

[paul-shannon]

Maybe you could create a very short eaf file, two lines, two tiers, write a test in the same style as the testtext*.py files, see what works, what doesn’t.

Then that test, if it fails, becomes our vehicle to improving the code. And if it works, we’re already there.

• Paul

On Mar 1, 2019, at 3:36 PM, David Beck notifications@github.com wrote:

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

[davidjamesbeck]

Hi, Paul

So I tried this by taking the Chatino prayer EAF file and deleting the two analysis tiers. I wrote a test file based on the test file for four-line version of the prayer where I changed the source file names (in createText()) and the assertions about the number and names of rows (in test_constructor()). However, that ran up against the code in text.py, which assumes four lines (line 52 in getTierSummary()). I didn’t want to mess with text.py since it is the basis of all the other tests (and it seems to use Panda (?) methods that I’m not familar with yet), but I did try running the two-line .eaf file through the full webapp.py to see what happens. When you get to the “Tier Guide” step, you can’t advance and get the message "Some choices not yet made.”

So, I could keep trying to tweak the tests to work with the 2 line file, but I’m actually not sure that that is going to tell us anything, since it looks to me that information about the structure of the different file formats is being given (or parameterized) in the tests themselves, and at least one road block to using the 2 line file is the webapp GUI itself. What do you think?

David

On Mar 1, 2019, at 4:39 PM, Paul Shannon notifications@github.com wrote:

Maybe you could create a very short eaf file, two lines, two tiers, write a test in the same style as the testtext*.py files, see what works, what doesn’t.

Then that test, if it fails, becomes our vehicle to improving the code. And if it works, we’re already there.

• Paul

On Mar 1, 2019, at 3:36 PM, David Beck notifications@github.com wrote:

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[paul-shannon]

Hi David,

I may not understand all that you did. But here’s what I would do.

• create (as you did) a two-tier only eaf
• create (as you did) a new test_text_Chatino_twoTier.py
• create a tierGuide.yml with (for now, at least) all four tiers, but with morpheme tiers marked as null
• avoid the webapp entirely
• get the test_tesxt_Chatino_twoTier.py to work - or, if it simply won’t, check it into github, with a new issue for me “get this to work!”

On Mar 2, 2019, at 6:43 AM, David Beck notifications@github.com wrote:

Hi, Paul

So I tried this by taking the Chatino prayer EAF file and deleting the two analysis tiers. I wrote a test file based on the test file for four-line version of the prayer where I changed the source file names (in createText()) and the assertions about the number and names of rows (in test_constructor()). However, that ran up against the code in text.py, which assumes four lines (line 52 in getTierSummary()). I didn’t want to mess with text.py since it is the basis of all the other tests (and it seems to use Panda (?) methods that I’m not familar with yet), but I did try running the two-line .eaf file through the full webapp.py to see what happens. When you get to the “Tier Guide” step, you can’t advance and get the message "Some choices not yet made.”

So, I could keep trying to tweak the tests to work with the 2 line file, but I’m actually not sure that that is going to tell us anything, since it looks to me that information about the structure of the different file formats is being given (or parameterized) in the tests themselves, and at least one road block to using the 2 line file is the webapp GUI itself. What do you think?

David

On Mar 1, 2019, at 4:39 PM, Paul Shannon notifications@github.com wrote:

Maybe you could create a very short eaf file, two lines, two tiers, write a test in the same style as the testtext*.py files, see what works, what doesn’t.

Then that test, if it fails, becomes our vehicle to improving the code. And if it works, we’re already there.

• Paul

On Mar 1, 2019, at 3:36 PM, David Beck notifications@github.com wrote:

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidjamesbeck]

Hi, Paul

Okay, I can try that—do you mark the morpheme tiers by typing “null”? Or “None”?

I will clone the text.py script and play with that as well, and if that doesn’t work, I’ll send it to GitHub. I’m a bit nervous about accidentally sending things from my mucking-around-with-stuff branch, but so far so good. As long as I don’t add > commit anything, it doesn’t go to GitHub when I do a push, right?

David

On Mar 2, 2019, at 8:25 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I may not understand all that you did. But here’s what I would do.

• create (as you did) a two-tier only eaf
• create (as you did) a new test_text_Chatino_twoTier.py
• create a tierGuide.yml with (for now, at least) all four tiers, but with morpheme tiers marked as null
• avoid the webapp entirely
• get the test_tesxt_Chatino_twoTier.py to work - or, if it simply won’t, check it into github, with a new issue for me “get this to work!”

On Mar 2, 2019, at 6:43 AM, David Beck notifications@github.com wrote:

Hi, Paul

So I tried this by taking the Chatino prayer EAF file and deleting the two analysis tiers. I wrote a test file based on the test file for four-line version of the prayer where I changed the source file names (in createText()) and the assertions about the number and names of rows (in test_constructor()). However, that ran up against the code in text.py, which assumes four lines (line 52 in getTierSummary()). I didn’t want to mess with text.py since it is the basis of all the other tests (and it seems to use Panda (?) methods that I’m not familar with yet), but I did try running the two-line .eaf file through the full webapp.py to see what happens. When you get to the “Tier Guide” step, you can’t advance and get the message "Some choices not yet made.”

So, I could keep trying to tweak the tests to work with the 2 line file, but I’m actually not sure that that is going to tell us anything, since it looks to me that information about the structure of the different file formats is being given (or parameterized) in the tests themselves, and at least one road block to using the 2 line file is the webapp GUI itself. What do you think?

David

On Mar 1, 2019, at 4:39 PM, Paul Shannon notifications@github.com wrote:

Maybe you could create a very short eaf file, two lines, two tiers, write a test in the same style as the testtext*.py files, see what works, what doesn’t.

Then that test, if it fails, becomes our vehicle to improving the code. And if it works, we’re already there.

• Paul

On Mar 1, 2019, at 3:36 PM, David Beck notifications@github.com wrote:

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468930091, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhii71VWl9pfL6Y_IZunIVSn1R1Y5ks5vSpf7gaJpZM4bZ-Kc.

[paul-shannon]

Null or None tiers are brand new today! Maybe None is more pythonic. It could be that you could put anything in there, and they won’t be used if those tiers are not in the eaf file.

tests> grep tierGuide *.py

shows me that test_IjalLine.py has most of the references to tierGuide. So that is almost certainly the code to study, along with ijalLine.py

We may need to refactor that to support other than 4-tier lines. So close study of ijalLine.py is the first thing to do!

The classic way to use github for new explorations is for you to create a new branch:

https://help.github.com/en/articles/creating-and-deleting-branches-within-your-repository

The you checkout that branch, (say "two-tier experiments”), add, commit and push to it, and we later merge your changes with the master branch.

Don’t worry about disturbing the repo. We can always roll it back.

• Paul

On Mar 2, 2019, at 7:32 AM, David Beck notifications@github.com wrote:

Hi, Paul

Okay, I can try that—do you mark the morpheme tiers by typing “null”? Or “None”?

I will clone the text.py script and play with that as well, and if that doesn’t work, I’ll send it to GitHub. I’m a bit nervous about accidentally sending things from my mucking-around-with-stuff branch, but so far so good. As long as I don’t add > commit anything, it doesn’t go to GitHub when I do a push, right?

David

On Mar 2, 2019, at 8:25 AM, Paul Shannon notifications@github.com wrote:

Hi David,

I may not understand all that you did. But here’s what I would do.

• create (as you did) a two-tier only eaf
• create (as you did) a new test_text_Chatino_twoTier.py
• create a tierGuide.yml with (for now, at least) all four tiers, but with morpheme tiers marked as null
• avoid the webapp entirely
• get the test_tesxt_Chatino_twoTier.py to work - or, if it simply won’t, check it into github, with a new issue for me “get this to work!”

On Mar 2, 2019, at 6:43 AM, David Beck notifications@github.com wrote:

Hi, Paul

So I tried this by taking the Chatino prayer EAF file and deleting the two analysis tiers. I wrote a test file based on the test file for four-line version of the prayer where I changed the source file names (in createText()) and the assertions about the number and names of rows (in test_constructor()). However, that ran up against the code in text.py, which assumes four lines (line 52 in getTierSummary()). I didn’t want to mess with text.py since it is the basis of all the other tests (and it seems to use Panda (?) methods that I’m not familar with yet), but I did try running the two-line .eaf file through the full webapp.py to see what happens. When you get to the “Tier Guide” step, you can’t advance and get the message "Some choices not yet made.”

So, I could keep trying to tweak the tests to work with the 2 line file, but I’m actually not sure that that is going to tell us anything, since it looks to me that information about the structure of the different file formats is being given (or parameterized) in the tests themselves, and at least one road block to using the 2 line file is the webapp GUI itself. What do you think?

David

On Mar 1, 2019, at 4:39 PM, Paul Shannon notifications@github.com wrote:

Maybe you could create a very short eaf file, two lines, two tiers, write a test in the same style as the testtext*.py files, see what works, what doesn’t.

Then that test, if it fails, becomes our vehicle to improving the code. And if it works, we’re already there.

• Paul

On Mar 1, 2019, at 3:36 PM, David Beck notifications@github.com wrote:

But Monkey and Thunder has the four tiers, they are empty for some lines. If the tiers aren’t there at all, will it still work? (If so, I guess I haven’t completely got my head around the code yet.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468930091, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhii71VWl9pfL6Y_IZunIVSn1R1Y5ks5vSpf7gaJpZM4bZ-Kc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[paul-shannon]

I don’t think I ever explained this. Better late than never, I hope.

but I did try running the two-line .eaf file through the full webapp.py to see what happens

webapp.py is “just” an interface to all of the slexil non-ui classes. So we should evolve those classes independently if we need to support new features from eaf files. The strategy is to capture the new cases in testData/ directories, write tests which demonstrate current problems. Evolve ijalLine.py. See that the new test passes. Make sure all of the other tests still pass. Then evolve, if needed, text.py, following the same write-the-test-first policy.

Then, after all the classes are in good shape -only then will it be time for me (or you) to evolve webapp.py.

I think we missed an opportunity, and that is bringing a lot of fuss your way. You are digging deep into code I wrote: this is a hard way to learn! I am asking you to understand and ue github branches. test-driven-development. yaml. python classes. Too much.

So we may want to pause. Early last year we tried to gather up a truly representative sample of eaf files for me to design around. It is so much easier to get the design right at the start. We should - guided by you - now expand our collection of test cases to include every conceivable use of eaf which IJAL will ever see and accept. With that expanded and, we hope, exhaustive set in hand, I could pretty quickly revise the classes I wrote to handle them all.

What do you think?

• Paul

[davidjamesbeck]

Hi, Paul

Most of what I’ve been playing around with has been for my benefit as I try to understand the big picture stuff, which is indeed hard, but I recognize that you probably don’t want to spend the rest of your life supporting slexil so I will have to get my head around it sometime. Anything that I did with webapp.py was just so I can see what is happening with the code, and doesn’t have anything to do with rsolving the two-line vs. four-line vs. six-line model problem. Since you assure me that any obstacles webapp.py threw up to the new models isn’t relevant, I’ll stick to the tests for the models. Hopefully, the “None” tiers will now mean NOT having to work on anything but the specific test files.

I have also made a bit of headway on the first task you set me, tweaking the .css and some of the rendering problems in the HTML and those fixes are on the GitHub repo now. That’s the easy stuff.

This is a lot for me, but really you have no idea of the near-psychotic levels of frustration I experienced when I first started playing with Python and coding. I don’t know if I ever told you this story, but when I first started fieldwork I was using a program called HyperCard, later SuperCard, and about 12 years into it I had all my data in there and it was becoming clear to me that that software was doomed. Being completely unaware of what I was getting into, I decided to try to recreate the whole thing in Python, which then required me to learn Qt and PyQt to build the GUI. Stupid, stupid, stupid. But I’m stubborn, so I managed in the end. So this is nothing as long as you don’t get mad at me for asking simple-minded questions and messing up now and then.

Cheers,

David

On Mar 2, 2019, at 9:15 AM, Paul Shannon notifications@github.com wrote:

I don’t think I ever explained this. Better late than never, I hope.

but I did try running the two-line .eaf file through the full webapp.py to see what happens

webapp.py is “just” an interface to all of the slexil non-ui classes. So we should evolve those classes independently if we need to support new features from eaf files. The strategy is to capture the new cases in testData/ directories, write tests which demonstrate current problems. Evolve ijalLine.py. See that the new test passes. Make sure all of the other tests still pass. Then evolve, if needed, text.py, following the same write-the-test-first policy.

Then, after all the classes are in good shape -only then will it be time for me (or you) to evolve webapp.py.

I think we missed an opportunity, and that is bringing a lot of fuss your way. You are digging deep into code I wrote: this is a hard way to learn! I am asking you to understand and ue github branches. test-driven-development. yaml. python classes. Too much.

So we may want to pause. Early last year we tried to gather up a truly representative sample of eaf files for me to design around. It is so much easier to get the design right at the start. We should - guided by you - now expand our collection of test cases to include every conceivable use of eaf which IJAL will ever see and accept. With that expanded and, we hope, exhaustive set in hand, I could pretty quickly revise the classes I wrote to handle them all.

What do you think?

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468934536, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhjeWnZpcLFyK_WlJwWxfpSC1vTeYks5vSqOcgaJpZM4bZ-Kc.

[davidjamesbeck]

SOLVED: two-tier model works if:

1) text.py is modified to catch an IndexError exception thrown by a null tier (line 57ff) 2) the four assertions in test_constructor (lines 32–35) are commented out

So, simple-minded question. What does this mean? None of these changes affect ijalLine.py or anything that I understand not to be specific to the tests we’re running. So we’re good for two-line models as far as the important part of the app goes, and we will just need to fix the way webapp.py handles this use case down the road? If so, I’ll move on to a five and then a six line model.

Do I need to push the modified text.py and the new Chatino_2Line stuff for you?

David

On Mar 2, 2019, at 9:15 AM, Paul Shannon notifications@github.com wrote:

I don’t think I ever explained this. Better late than never, I hope.

but I did try running the two-line .eaf file through the full webapp.py to see what happens

webapp.py is “just” an interface to all of the slexil non-ui classes. So we should evolve those classes independently if we need to support new features from eaf files. The strategy is to capture the new cases in testData/ directories, write tests which demonstrate current problems. Evolve ijalLine.py. See that the new test passes. Make sure all of the other tests still pass. Then evolve, if needed, text.py, following the same write-the-test-first policy.

Then, after all the classes are in good shape -only then will it be time for me (or you) to evolve webapp.py.

I think we missed an opportunity, and that is bringing a lot of fuss your way. You are digging deep into code I wrote: this is a hard way to learn! I am asking you to understand and ue github branches. test-driven-development. yaml. python classes. Too much.

So we may want to pause. Early last year we tried to gather up a truly representative sample of eaf files for me to design around. It is so much easier to get the design right at the start. We should - guided by you - now expand our collection of test cases to include every conceivable use of eaf which IJAL will ever see and accept. With that expanded and, we hope, exhaustive set in hand, I could pretty quickly revise the classes I wrote to handle them all.

What do you think?

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468934536, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhjeWnZpcLFyK_WlJwWxfpSC1vTeYks5vSqOcgaJpZM4bZ-Kc.

[davidjamesbeck]

And I managed to fix the assertion statements so they don’t trigger errors anymore. Yay!

On Mar 2, 2019, at 11:09 AM, David Beck dbeck@ualberta.ca wrote:

SOLVED: two-tier model works if:

1) text.py is modified to catch an IndexError exception thrown by a null tier (line 57ff) 2) the four assertions in test_constructor (lines 32–35) are commented out

So, simple-minded question. What does this mean? None of these changes affect ijalLine.py or anything that I understand not to be specific to the tests we’re running. So we’re good for two-line models as far as the important part of the app goes, and we will just need to fix the way webapp.py handles this use case down the road? If so, I’ll move on to a five and then a six line model.

Do I need to push the modified text.py and the new Chatino_2Line stuff for you?

David

On Mar 2, 2019, at 9:15 AM, Paul Shannon <notifications@github.com mailto:notifications@github.com> wrote:

I don’t think I ever explained this. Better late than never, I hope.

but I did try running the two-line .eaf file through the full webapp.py to see what happens

webapp.py is “just” an interface to all of the slexil non-ui classes. So we should evolve those classes independently if we need to support new features from eaf files. The strategy is to capture the new cases in testData/ directories, write tests which demonstrate current problems. Evolve ijalLine.py. See that the new test passes. Make sure all of the other tests still pass. Then evolve, if needed, text.py, following the same write-the-test-first policy.

Then, after all the classes are in good shape -only then will it be time for me (or you) to evolve webapp.py.

I think we missed an opportunity, and that is bringing a lot of fuss your way. You are digging deep into code I wrote: this is a hard way to learn! I am asking you to understand and ue github branches. test-driven-development. yaml. python classes. Too much.

So we may want to pause. Early last year we tried to gather up a truly representative sample of eaf files for me to design around. It is so much easier to get the design right at the start. We should - guided by you - now expand our collection of test cases to include every conceivable use of eaf which IJAL will ever see and accept. With that expanded and, we hope, exhaustive set in hand, I could pretty quickly revise the classes I wrote to handle them all.

What do you think?

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468934536, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhjeWnZpcLFyK_WlJwWxfpSC1vTeYks5vSqOcgaJpZM4bZ-Kc.

[paul-shannon]

very cool, David!

We probably don’t want to comment out assertions. Can you see how to make them more accurate, testing the actual possibilities that two-tier lines bring? Let’s defer modifications to webapp.py - and even defer thinking about them - until the core code expands conceptually to handle tier != 4 texts.

That is: we don’t want to just code around what I failed to anticipate. We want to revise the abstractions embodied in the code. I hope that makes sense!

• Paul

On Mar 2, 2019, at 10:17 AM, David Beck notifications@github.com wrote:

And I managed to fix the assertion statements so they don’t trigger errors anymore. Yay!

On Mar 2, 2019, at 11:09 AM, David Beck dbeck@ualberta.ca wrote:

SOLVED: two-tier model works if:

1) text.py is modified to catch an IndexError exception thrown by a null tier (line 57ff) 2) the four assertions in test_constructor (lines 32–35) are commented out

So, simple-minded question. What does this mean? None of these changes affect ijalLine.py or anything that I understand not to be specific to the tests we’re running. So we’re good for two-line models as far as the important part of the app goes, and we will just need to fix the way webapp.py handles this use case down the road? If so, I’ll move on to a five and then a six line model.

Do I need to push the modified text.py and the new Chatino_2Line stuff for you?

David

On Mar 2, 2019, at 9:15 AM, Paul Shannon <notifications@github.com mailto:notifications@github.com> wrote:

I don’t think I ever explained this. Better late than never, I hope.

but I did try running the two-line .eaf file through the full webapp.py to see what happens

webapp.py is “just” an interface to all of the slexil non-ui classes. So we should evolve those classes independently if we need to support new features from eaf files. The strategy is to capture the new cases in testData/ directories, write tests which demonstrate current problems. Evolve ijalLine.py. See that the new test passes. Make sure all of the other tests still pass. Then evolve, if needed, text.py, following the same write-the-test-first policy.

Then, after all the classes are in good shape -only then will it be time for me (or you) to evolve webapp.py.

I think we missed an opportunity, and that is bringing a lot of fuss your way. You are digging deep into code I wrote: this is a hard way to learn! I am asking you to understand and ue github branches. test-driven-development. yaml. python classes. Too much.

So we may want to pause. Early last year we tried to gather up a truly representative sample of eaf files for me to design around. It is so much easier to get the design right at the start. We should - guided by you - now expand our collection of test cases to include every conceivable use of eaf which IJAL will ever see and accept. With that expanded and, we hope, exhaustive set in hand, I could pretty quickly revise the classes I wrote to handle them all.

What do you think?

• Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/paul-shannon/slexil/issues/10#issuecomment-468934536, or mute the thread https://github.com/notifications/unsubscribe-auth/ApvDhjeWnZpcLFyK_WlJwWxfpSC1vTeYks5vSqOcgaJpZM4bZ-Kc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.