Brassica SCA [v0.2.0]

[Man in Space]

How is the version ID determined?

[bradrn]

How is the version ID determined?

Since it’s written in Haskell, I try to follow https://pvp.haskell.org/.

[dhok]

Just to be clear, since I'm not a Linux person--is there a new Windows desktop release?

[Travis B.]

Just to be clear, since I'm not a Linux person--is there a new Windows desktop release?

Haven't seen you around here much, so welcome back!

[Raphael]

Just to be clear, since I'm not a Linux person--is there a new Windows desktop release?

Looks to me like there isn't. Oh, and welcome back from me, too!

[bradrn]

Just to be clear, since I'm not a Linux person--is there a new Windows desktop release?

Alas, no. It’s proven rather difficult to make one, and in the past week I haven’t had much free time. But I can assure you that the desktop version has very few features which have not yet been ported over to the web version. (The main ones are MDF support and a new ‘synchronise scroll positions’ option I added in this release. I also haven’t updated the paradigm builder to the new web interface, but I’ve kept the last version online at http://bradrn.com/brassica-0.3.0/builder/.)

(Hmm, now that I think of it, I guess I can at least release the CLI for Windows… it’s not a GUI, of course, but it would at least be something.)

[bradrn]

I managed to get Brassica working on Windows again! Hopefully I can cut a new release some time in the next few days. (The delay is because it required a bit of an internal rewrite, so I still need to update some of the documentation, make an installer, etc.)

[bradrn]

…and Brassica v0.1.1 is now released with a Windows installer! (And an improved distribution archive for Linux, too.) Get it from the usual place.

[bradrn]

No new release to announce, but I have just finished a major refactor! It shouldn’t affect the usage of Brassica at all, but the internals are now simpler and more flexible. The primary motivator for the moment is supporting the needs of the Index Diachronica project, but in the longer-term this should make it a bit easier to add new features. (I’m thinking in particular of marking intermediate stages, but there are others.)

Speaking of which, another thing I’m reconsidering is suprasegmentals. Currently, they’re shoehorned into the category system, which means that if you’re not really careful your whole sound change blows up. I’m thinking it might work better to represent them as autosegments: that is to say, on an entirely different tier than segments. Thus, an autosegment like +High would be insensitive to which segment it’s attached to, and a grapheme like a would match irrespective of whether it’s attached to any autosegments. (And, of course, a+High would match both!) The details will need a bit of working out, though.

[bradrn]

Brassica version 0.2.0 is now out! Get the desktop version or try it online at the usual places.

Release highlights:

• Category elements can now contain multiple lexemes (enclosed in curly braces)
• Backreferences can now occur in the environment
• The user can now choose the separator used between multiple results
• Performance improvements (>50% speedup by my measure)
• Usability improvements to paradigm builder, including a new web version

[Darren]

• Backreferences can now occur in the environment

I'm having trouble with this. I'm trying to get it to perform the change

C → / # _ ˈ V @1 C

but it doesn't like it; when the conditions are there it just plain doesn't do anything. The rule is otherwise fine since without the "@1" it works (obviously in the wrong way though). If I phrase it like

C ˈ V @1 C → ˈ @2 V @1 C / # _

then it works as intended.

[bradrn]

• Backreferences can now occur in the environment

I'm having trouble with this. I'm trying to get it to perform the change

C → / # _ ˈ V @1 C

but it doesn't like it; when the conditions are there it just plain doesn't do anything. The rule is otherwise fine since without the "@1" it works (obviously in the wrong way though). If I phrase it like

C ˈ V @1 C → ˈ @2 V @1 C / # _

then it works as intended.

Yeah, I should probably have clarified this point. Backreferences in the environment can only refer back to categories in the environment; similarly, backreferences in the target refer back to the target. The replacement is slightly different, since backreferences there refer to the target as well.

(On the other hand, if this happens to be for the new Index Diachronica, don’t worry; your first rule will display just fine on the website even if it doesn’t work in Brassica proper. Actually, for that matter, the ID’s handling of backreferences is generally a little wonky — I should probably find a solution to that…)

[Darren]

Yeah, I should probably have clarified this point. Backreferences in the environment can only refer back to categories in the environment; similarly, backreferences in the target refer back to the target. The replacement is slightly different, since backreferences there refer to the target as well.

(On the other hand, if this happens to be for the new Index Diachronica, don’t worry; your first rule will display just fine on the website even if it doesn’t work in Brassica proper. Actually, for that matter, the ID’s handling of backreferences is generally a little wonky — I should probably find a solution to that…)

Ah gotcha. It's not for the ID, I was just messing around to remind myself how Brassica works.

[bradrn]

Yeah, I should probably have clarified this point. Backreferences in the environment can only refer back to categories in the environment; similarly, backreferences in the target refer back to the target. The replacement is slightly different, since backreferences there refer to the target as well.

(On the other hand, if this happens to be for the new Index Diachronica, don’t worry; your first rule will display just fine on the website even if it doesn’t work in Brassica proper. Actually, for that matter, the ID’s handling of backreferences is generally a little wonky — I should probably find a solution to that…)

Ah gotcha. It's not for the ID, I was just messing around to remind myself how Brassica works.

Fair enough. I do hope it’s all reasonably intuitive… please tell me if anything isn’t!

[Darren]

Yeah, I should probably have clarified this point. Backreferences in the environment can only refer back to categories in the environment; similarly, backreferences in the target refer back to the target. The replacement is slightly different, since backreferences there refer to the target as well.

(On the other hand, if this happens to be for the new Index Diachronica, don’t worry; your first rule will display just fine on the website even if it doesn’t work in Brassica proper. Actually, for that matter, the ID’s handling of backreferences is generally a little wonky — I should probably find a solution to that…)

Ah gotcha. It's not for the ID, I was just messing around to remind myself how Brassica works.

Fair enough. I do hope it’s all reasonably intuitive… please tell me if anything isn’t!

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.

[bradrn]

Ah gotcha. It's not for the ID, I was just messing around to remind myself how Brassica works.

Fair enough. I do hope it’s all reasonably intuitive… please tell me if anything isn’t!

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.

Yes, this is a known problem. (Well, known to me.) Essentially, ⟨ɛ́⟩ is stored as two characters, ⟨ɛ◌́⟩, and Brassica doesn’t yet know that it has to treat it as a single multigraph. To get that to work, you currently have to define it as a multigraph by listing it somewhere in the categories.

Honestly, that whole ‘listing it somewhere in the categories’ idea has turned out less well than I thought… even ignoring this problem, I’ve found it makes quick experimentation a little difficult. I’ve been contemplating new syntax to improve this, probably something like:

recognise combining (to recognise combining diacritics as multigraphs)
recognise sh ch ng (to recognise those sequences as single graphemes)

[Darren]

Fair enough. I do hope it’s all reasonably intuitive… please tell me if anything isn’t!

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.

Yes, this is a known problem. (Well, known to me.) Essentially, ⟨ɛ́⟩ is stored as two characters, ⟨ɛ◌́⟩, and Brassica doesn’t yet know that it has to treat it as a single multigraph. To get that to work, you currently have to define it as a multigraph by listing it somewhere in the categories.

Honestly, that whole ‘listing it somewhere in the categories’ idea has turned out less well than I thought… even ignoring this problem, I’ve found it makes quick experimentation a little difficult. I’ve been contemplating new syntax to improve this, probably something like:

recognise combining (to recognise combining diacritics as multigraphs)
recognise sh ch ng (to recognise those sequences as single graphemes)

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. Not that that's a great deal of trouble, but if I forget I sometimes get lots of question marks (although other times it doesn't seem to mind). Regardless the extra functionalities make it better than any other SCAs I've used so I'm happy to put up with some quirks.

[bradrn]

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.

Yes, this is a known problem. (Well, known to me.) Essentially, ⟨ɛ́⟩ is stored as two characters, ⟨ɛ◌́⟩, and Brassica doesn’t yet know that it has to treat it as a single multigraph. To get that to work, you currently have to define it as a multigraph by listing it somewhere in the categories.

Honestly, that whole ‘listing it somewhere in the categories’ idea has turned out less well than I thought… even ignoring this problem, I’ve found it makes quick experimentation a little difficult. I’ve been contemplating new syntax to improve this, probably something like:

recognise combining (to recognise combining diacritics as multigraphs)
recognise sh ch ng (to recognise those sequences as single graphemes)

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.

Yes, that’s exactly what I do to. (I tend to call it Other, but X is probably a better choice.) It’s not great, which is why I’d like to improve the situation.

Regardless the extra functionalities make it better than any other SCAs I've used so I'm happy to put up with some quirks.

This makes me really happy to hear, thank you!

[bradrn]

While trying to implement some new features, I realised I’m confused by this statement:

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? If you actually use these, it would make more sense to me to place them in (say) a C category for consonants, or something like that.

[Darren]

While trying to implement some new features, I realised I’m confused by this statement:

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. It's a minor inconvenience at worst.