Page 7 of 13
Re: Brassica SCA [v0.2.0]
Posted: Sat Mar 02, 2024 7:09 pm
by bradrn
Darren wrote: ↑Sat Mar 02, 2024 7:05 pm
bradrn wrote: ↑Sat Mar 02, 2024 7:03 pm
While trying to implement some new features, I realised I’m confused by this statement:
Darren wrote: ↑Sat Jan 27, 2024 6:03 pm
I always end up having to make a category "X" which is just all the left over shit like
ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.
If those graphemes never get used for anything, then why do you need to include them in a category in the first place?
It's the category that never gets used. When rules produce new graphemes, sometimes it doesn't mind but other times it just gives a bunch of question marks.
Hmm… surely it should only give question marks if there’s another category declaration afterwards? That was my intention, at least; if it’s not doing that, there’s a bug.
It's a minor inconvenience at worst.
Sure, but for the next version I’d like to focus on fixing these inconveniences (so I can finally release v1.0).
Re: Brassica SCA [v0.2.0]
Posted: Sat Mar 02, 2024 7:39 pm
by Darren
bradrn wrote: ↑Sat Mar 02, 2024 7:09 pm
Hmm… surely it should only give question marks if there’s another category declaration afterwards?
I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.
Re: Brassica SCA [v0.2.0]
Posted: Sat Mar 02, 2024 7:46 pm
by bradrn
Darren wrote: ↑Sat Mar 02, 2024 7:39 pm
bradrn wrote: ↑Sat Mar 02, 2024 7:09 pm
Hmm… surely it should only give question marks if there’s another category declaration afterwards?
I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.
As am I, which is why
categories … end adds to the existing categories rather than clearing them (which would be
new categories … end). I think the documentation is pretty clear on this point, though please let me know if it isn’t.
Re: Brassica SCA [v0.2.0]
Posted: Sat Mar 02, 2024 8:09 pm
by Darren
bradrn wrote: ↑Sat Mar 02, 2024 7:46 pm
Darren wrote: ↑Sat Mar 02, 2024 7:39 pm
bradrn wrote: ↑Sat Mar 02, 2024 7:09 pm
Hmm… surely it should only give question marks if there’s another category declaration afterwards?
I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.
As am I, which is why
categories … end adds to the existing categories rather than clearing them (which would be
new categories … end). I think the documentation is pretty clear on this point, though please let me know if it isn’t.
Hence why I use
categories and add a junk category for all the new graphemes I've produced.
Re: Brassica SCA [v0.2.0]
Posted: Fri May 10, 2024 7:11 am
by bradrn
Darren wrote: ↑Sat Jan 27, 2024 6:03 pm
I always end up having to make a category "X" which is just all the left over shit like
ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.
Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write
extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.
Re: Brassica SCA [v0.2.0]
Posted: Fri May 10, 2024 7:31 pm
by Darren
bradrn wrote: ↑Fri May 10, 2024 7:11 am
Darren wrote: ↑Sat Jan 27, 2024 6:03 pm
I always end up having to make a category "X" which is just all the left over shit like
ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.
Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write
extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.
Aye that's great I'll give it a crack today
Re: Brassica SCA [v0.2.0]
Posted: Sat May 11, 2024 4:10 am
by bradrn
Darren wrote: ↑Fri May 10, 2024 7:31 pm
bradrn wrote: ↑Fri May 10, 2024 7:11 am
Darren wrote: ↑Sat Jan 27, 2024 6:03 pm
I always end up having to make a category "X" which is just all the left over shit like
ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.
Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write
extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.
Aye that's great I'll give it a crack today
Note that it’s not released yet!
Re: Brassica SCA [v0.2.0]
Posted: Sat May 11, 2024 4:37 am
by Darren
bradrn wrote: ↑Sat May 11, 2024 4:10 am
Darren wrote: ↑Fri May 10, 2024 7:31 pm
bradrn wrote: ↑Fri May 10, 2024 7:11 am
Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write
extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.
Aye that's great I'll give it a crack today
Note that it’s not released yet!
Ah right guess I'll have to wait
Re: Brassica SCA [v0.2.0]
Posted: Sat May 11, 2024 5:29 am
by bradrn
For reference, this is my list of what to get done for the next release, which with luck could finally get to v1.0.0:
- Figure out some better way of handling stress, tone etc.
- Improve Brassica’s understanding of MDF dictionary files
- Allow display of intermediate results
- Get the CLI closer to feature parity with the GUI
- Improve documentation
And some things which I’ve already implemented:
- extra directive (as just mentioned)
- Up to 10× speed improvement on desktop by parallelisation
- Allow recognising combining diacritics as forming automatic multigraphs
- Wildcards can now occur in the replacement of a rule
Re: Brassica SCA [v0.2.0]
Posted: Fri May 24, 2024 11:24 pm
by Ketsuban
I have a couple of questions.
- I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?
- I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).
[o u] / [ø y] / _ C Frnt
[i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
a / [ɛ ɔ] / _ C Open
V / / _ #
This results in an ambiguity where it thinks words like tati and tatu could both end up as either tɛt and tɔt, rather than tati becoming tɛt and tatu becoming tɔt. I can fix this by breaking rule 3 into two rules, one for aCi and one for aCu, but that feels wrong. I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1" and then it wouldn't work until I refreshed the browser window. Is there another way to do what I want here that I missed in the documentation?
Re: Brassica SCA [v0.2.0]
Posted: Sat May 25, 2024 12:46 am
by Darren
Ketsuban wrote: ↑Fri May 24, 2024 11:24 pm
- I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).
[o u] / [ø y] / _ C Frnt
[i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
a / [ɛ ɔ] / _ C Open
V / / _ #
This results in an ambiguity where it thinks words like tati and tatu could both end up as either tɛt and tɔt, rather than tati becoming tɛt and tatu becoming tɔt. I can fix this by breaking rule 3 into two rules, one for aCi and one for aCu, but that feels wrong. I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1" and then it wouldn't work until I refreshed the browser window. Is there another way to do what I want here that I missed in the documentation?
You can fix it with
Code: Select all
a C [i u] / @2 [ɛ ɔ] @1 C @2 [i u]
since that way you're backreferencing a target element. Although that's not really much less complicated than writing out two rules.
Re: Brassica SCA [v0.2.0]
Posted: Sat May 25, 2024 4:18 am
by bradrn
Ketsuban wrote: ↑Fri May 24, 2024 11:24 pm
- I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?
I see no reason why not. I’ll add this to the list.
I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).
[o u] / [ø y] / _ C Frnt
[i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
a / [ɛ ɔ] / _ C Open
V / / _ #
This results in an ambiguity where it thinks words like
tati and
tatu could both end up as either
tɛt and
tɔt, rather than
tati becoming
tɛt and
tatu becoming
tɔt. I can fix this by breaking rule 3 into two rules, one for
aCi and one for
aCu, but that feels wrong.
Darren is correct here:
… / … / _ C Open means ‘apply this rule the same way before all open vowels’. To do this in a single rule, you need to put it in the target (so that the replacement can depend on it) and use backreferencing.
I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"
Now
this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?
Re: Brassica SCA [v0.2.0]
Posted: Sat May 25, 2024 5:21 am
by Ketsuban
bradrn wrote: ↑Sat May 25, 2024 4:18 am
I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"
Now
this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?
a / @1 [ɛ ɔ] / _ C @1 Open
Re: Brassica SCA [v0.2.0]
Posted: Sat May 25, 2024 5:27 am
by bradrn
Ketsuban wrote: ↑Sat May 25, 2024 5:21 am
bradrn wrote: ↑Sat May 25, 2024 4:18 am
I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"
Now
this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?
a / @1 [ɛ ɔ] / _ C @1 Open
OK, I can replicate this. This is very bad… I’ll need to look into it.
EDIT: simplified the trigger to
a / @1 [ɛ ɔ] / _ [p t] @1 [e i], which is enough to crash it still.
Re: Brassica SCA [v0.2.0]
Posted: Sat May 25, 2024 6:34 am
by bradrn
The bug should be fixed now. (At least in the code; I won’t update the website until the next release.) The problem was that the target @1 [ɛ ɔ] is referring to category 1, but that category doesn’t exist in the target (which just matches a single grapheme). The code shouldn’t crash in that case anyway, but some stupid bad code made it do so.
This reminds me of an idea I had a while ago, which is to add an extra pre-processing step to link up target and replacement categories. (Currently Brassica does this in an ad-hoc way on each rule application.) The benefit would be that it can catch problems like this early, before it’s even tried to run the rule. It could also be useful for things like e.g. the Index Diachronica, where we want to display category information ahead of time. The major disadvantage would be the added complexity, plus the fact that it might make rules slightly less flexible.
Re: Brassica SCA [v0.2.0]
Posted: Sat Jul 06, 2024 10:49 am
by bradrn
Ketsuban wrote: ↑Fri May 24, 2024 11:24 pm
- I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?
I finally got around to implementing this, though again it’s not released yet.
Speaking of which, I should mention my plans for the next couple of releases. Originally my plan was to make the next release v1.0.0, sorting out a bunch of fundamental issues in the process. But we’ve been
discussing those, and it seems that it may take a while before I reach a final design. So I think I’ll release v0.3.0 next, focussing on user interface improvements, and then work on v1.0.0 after that. (And then that should finally give us a good foundation to resume work on the
Index Diachronica.)
Re: Brassica SCA [v0.2.0]
Posted: Mon Jul 08, 2024 10:44 pm
by Man in Space
Thank you for all your hard work on this resource most valuable.
Re: Brassica SCA [v0.2.0]
Posted: Tue Jul 09, 2024 3:26 am
by bradrn
Man in Space wrote: ↑Mon Jul 08, 2024 10:44 pm
Thank you for all your hard work on this resource most valuable.
You’re very welcome!
(Although to be honest, it’s no longer
entirely altruism. There’s now a very faint chance that I could parlay this into a PhD opportunity… unlikely, of course, but people are interested in the
ID at least.)
Re: Brassica SCA [v0.2.0]
Posted: Mon Jul 15, 2024 5:48 pm
by bradrn
bradrn wrote: ↑Sat May 11, 2024 5:29 am
- Allow recognising combining diacritics as forming automatic multigraphs
I’m beginning to question whether this is really as good an idea as I thought. After all, if a combining diacritic forms a valid multigraph, then it should be listed in the
categories anyway, and therefore needs no special handling. And if it
doesn’t form a valid multigraph, then what business does Brassica have assuming that it does‽
The one case where it could be useful is very quick-and-dirty experimentation where you don’t even want to bother making
categories. But how often does that happen, anyway? When I do that, it’s mostly if I’m debugging, or otherwise using Brassica in a way it wasn’t specifically intended for.
Does anyone else have any particular preferences on this?
EDIT: Perusing previous conversations, I see Darren has explicitly mentioned this as an issue:
Darren wrote: ↑Sat Jan 27, 2024 5:44 pm
It's intuitive enough; or at least, it's not counterintuitive – with the guide it's easily usable even for me. I have had trouble getting it to understand non-precomposed characters like <ɛ́ ɔ́ ɑ̃>; it keeps treating the accents separately for some reason.
Given the above logic, I’m curious to know what your specific problem was, and why writing out the
categories wasn’t enough to solve it?
Re: Brassica SCA [v0.2.0]
Posted: Tue Jul 16, 2024 4:46 am
by Darren
bradrn wrote: ↑Mon Jul 15, 2024 5:48 pm
Given the above logic, I’m curious to know what your specific problem was, and why writing out the
categories wasn’t enough to solve it?
You know what, I can't work out what my problem was. I do remember having to avoid combining diacritics like the plague since they never worked. I'll have a play around with it and see if I can make it happen again.