Haedus SCA - Bugfix (01/24)

[Zju]

Hi, found another bug: instead of throwing an error

Code: Select all

b = b d g

causes the program to become irresponsive.

[Morrígan]

Hi, found another bug: instead of throwing an error

Code: Select all

b = b d g

causes the program to become irresponsive.

Can you post the rest of the rules file? Is this the first time you are defining b? If not, how is b defined previously?

[Zju]

b is in lowercase, this is what causes the problem, i think
anyway, this was the whole rules fule iirc

Code: Select all

P = pw p t k
B = bw b d g
V = a o
P > B / V_V
P = p t k
b = b d g
B > 0 / #_

I was just making sure redifining works properly.

[Morrígan]

b is in lowercase, this is what causes the problem, i think
anyway, this was the whole rules fule iirc

Code: Select all

P = pw p t k
B = bw b d g
V = a o
P > B / V_V
P = p t k
b = b d g
B > 0 / #_

I was just making sure redifining works properly.

Yeah ok, I'll have to look into this, though I'm not sure I'd say this is a bug, necessarily. In order to redefine b, you would first have to define b. That said, I'll look at this when I have access to my code - I didn't turn my workstation on at home this morning, so I have no remote access at the moment.

This should be an easy fix though, I am probably expanding variables in the definition in the wrong order.

[Morrígan]

Did you mean that to read "B = b d g"? I thought it was odd that you were using "b" as a variable name (which is legal, provided it doesn't conflict with an existing literal). Changing the "b" to "B" in the variable name allows it to work, and re-assigns the values correctly. Further, I re-tested the functionality that allows

Code: Select all

C = a b c
C = C d

and produces a final value for C of "a b c d".

Addendum:

The actual cause of the error is not during the parsing of "b = b d g" but rather the application of "B > 0 / #_c"; this occurs because the rule affects "B", which is defined as "B = bw b d g" and "b" has now been defined as a variable containing itself. I can add some kind of consistency check that will cause the command to fail if you are defining (and not re-defining) a variable with itself as a value.

[Boşkoventi]

I could use "^", "~" or another symbol instead of "!", whatever avoids using up characters people already use. Thoughts?

The one issue with "!" is that people might want to use it for clicks. After that, my first choice would be "^".

So, upon further not-terribly-detailed analysis, it seems to be the case that

Code: Select all

!(abc) = { !abc a!bc ab!c }

But a sequence "def" wouldn't match anything in "{ !abc a!bc ab!c }".

Code: Select all

a	b	c	
T	T	T	abc
T	T	F	ab!c
T	F	T	a!bc
T	F	F	a!b!c
F	T	T	!abc
F	T	F	!ab!c
F	F	T	!a!bc
F	F	F	!a!b!c

Therefore:

!(abc) = { ab!c a!bc a!b!c !abc !ab!c !a!bc !a!b!c }

[Morrígan]

I could use "^", "~" or another symbol instead of "!", whatever avoids using up characters people already use. Thoughts?

The one issue with "!" is that people might want to use it for clicks. After that, my first choice would be "^".

My concern exactly.

!(abc) = { ab!c a!bc a!b!c !abc !ab!c !a!bc !a!b!c }

Oh of course, I don't know why this wasn't immediately obvious to me. All the more reason why implementing it might be a nightmare.

[Herra Ratatoskr]

Hey, I was hoping you could help me debug a sound change I can't get to work. I'm trying to make a rule that makes inflectional vowels at the end of a word drop, when preceded by a consonant, which is preceded by an atonic vowel. If more than one consonant is between them, however, the vowel doesn't drop.

Here are the relevant variables I've set up, with their relevant values for the example I have.
AT = Atonic Vowels (î)
C = Consonants (þ s n)
IN = Inflectional Vowels (ĕ)

Here are the sample words I'm using, with their expected outcomes:
þîsĕ > þîs
þîsnĕ > þîsnĕ

Here is the first rule I tried:
IN > 0 / ATC_#
And the outcome was:
þîsĕ > þîsĕ
þîsnĕ > þîsnĕ

Then I tried this:
[AT] = AT
IN > 0 / [AT]C_#
With the same result

Then I tried this:
IN > 0 / (AT)C_#
With the same result

Then I tried this:
IN > 0 / AT(C)_#
And again the same result.

I then tried
IN > 0 / AT?C_#
and got:
þîsĕ > þîs
þîsnĕ > þîsn

Any idea what I'm doing wrong.

[Morrígan]

Those problems actually turn out to be a really really dumb error which, shockingly, none of my current tests apparently were affected by. This is now fixed though. Sorry for the dumb mistake.

Get it

[Zju]

A little nifty feature would be the ability to terminate the application of sound changes past a certain point without the need of cutting temporarily the text afterwards.

[Zju]

Okay, I learned this the hard way - the SC file has start from the second line, because the first line is ignored. Tested with:

Code: Select all

1 = i

2 = o

1 > 2

vs.

Code: Select all

%this should have been an empty line, but the forum software removes it automatically; anyway, a comment also works
1 = i

2 = o

1 > 2

The second SCs change i's to o's but the first ones don't!

[Morrígan]

Okay, I learned this the hard way - the SC file has start from the second line, because the first line is ignored.

I feel like I've seen this happen before, but I'm not sure why. Unless you are using a text editor which is inserting a byte-order marker at the start of the file.

I haven't had a lot of time to work on this project, but I have an approach for expanding the power of rule sets.

[Zju]

I have found another thing. It's not much of an issue, since there's an easy workaround, but I felt like letting the others know - the digraphs don't work in groups. To use them so, you have to temporarily make them something else, e.g. a number. So this will work:

Code: Select all

ay > 2
V = a o 2 u 
 .....
......
2 > ay

but this won't:

Code: Select all

V = a o ay u 
 .....
......