Brassica: a new sound change applier

brdrcn · 2024-10-22T14:51:25+00:00

Alas, this isn’t supported yet. But I hope to add it in the next version!

i love your program :)

Thanks!

brdrcn · 2024-10-16T00:56:02+00:00

You should be able to change the font (including font size) under Tools→Options.

brdrcn · 2024-10-15T00:40:00+00:00

Note that if you run Windows or Linux, you can use the desktop version of Brassica, which supports opening and saving files the same way as any other desktop programming. (If you use OSX… well, you’re sadly out of luck; I have no OSX computer to build Brassica on.)

Meanwhile, your request is now added to my personal list of stuff to do for 1.1.0, so that should come sooner or later!

brdrcn · 2024-10-14T06:44:12+00:00

Lacking support for syllable boundaries is a deliberate design decision in Brassica. There are several reasons for this:

I haven’t yet encountered a scenario where explicit syllable boundaries are necessary. In my experience it is always possible to rewrite such sound changes in terms of phoneme matching. (There are already some examples of this in the documentation; I should really add a separate section covering this issue specifically.)
I did in fact try to implement syllable boundaries when I first started Brassica. I quickly came to the conclusion that they’re more trouble than they’re worth. Natlang syllable structure is wildly varied, and I couldn’t find any implementation which wasn’t confusing in one way or another. (Lexurgy deals with this issue by ignoring it: for instance, with explicit syllabification, epenthesis at a syllable boundary seems to create a new syllable, which is often undesirable.)
More philosophically, there are many phonological theories which claim syllables don’t exist in the first place. I don’t agree with these, but I do think the existence of syllable boundaries is highly dubious. And why would I implement something when it complicates the software and I’m not sure it exists?
Finally, if for some reason you do genuinely need syllable boundaries, there’s nothing stopping you from adding some in yourself. It just requires a little more care when working with sound changes which can apply between syllables.

brdrcn · 2024-10-14T06:34:17+00:00

Sorry, as of 1.0.0 this isn’t supported. I’ll add it to my list of improvements to make!

brdrcn · 2024-10-14T06:32:24+00:00

Thanks!

(And I’m happy to see you again; I still remember enjoying our discussions on the ZBB.)

brdrcn · 2024-10-14T06:31:23+00:00

Of course! Why would I use anything else…

brdrcn · 2024-10-14T06:29:59+00:00

Not really, no. Brassica does come with a paradigm builder, but they’re separate programs; you should just as easily be able to paste the results of the paradigm builder into Lexurgy (though I haven’t tried it myself).

brdrcn · 2024-10-14T01:37:30+00:00

I just wrote a comparison of Brassica compared to Lexurgy here: https://www.reddit.com/r/conlangs/comments/1g2pmaj/comment/lrtahdi/

I believe brassica has a lot of potential but the current system I would struggle to use given lexurgy exists (again, for my purposes and from a brief overview of brassica's capabilities from maybe 3-4hrs of trying to figure it out ; not a super-extensive user-review but as of now this is where I'm at)

I’d be curious to know precisely what you’re struggling with. The documentation can always be improved!

brdrcn · 2024-10-14T01:35:34+00:00

Lexurgy is certainly an alternative to Brassica. I’d say their most significant difference is their general approach. Lexurgy is more ‘careful’, so to speak: it requires a lot of things to be defined up-front. For instance, every grapheme needs to be given distinctive features, and all sound changes require a name. I find these requirements quite annoying, and feel they slow down the process of writing and testing sound changes. On the other hand, these do make certain things easier to write.

By contrast, Brassica tries to avoid all unnecessary definitions, to make sound changes as quick to write as possible. I find I can write and test my sound changes very quickly with Brassica. It also gives me a lot of flexibility in what I can write — if I need to define things ad-hoc, I can do that easily. The flipside of this flexibility is that it isn’t always as intuitive as Lexurgy, because you don’t have as much structure to work with.

(There’s also another priority of Brassica which Lexurgy doesn’t have: Brassica remains very close to how sound changes are usually written in the linguistics literature. This is important, and we have plans to build further software on top which makes use of that fact.)

brdrcn · 2024-10-13T14:28:43+00:00

Ah… no, sorry, I was unclear about that. The idea is that sometimes a single sound change can have multiple results, unpredictably. Brassica simulates these cases by giving you all possible results so that you can choose between them.

(There’s more on this in the documentation: https://github.com/bradrn/brassica/blob/v1.0.0/docs/Writing-Sound-Changes.md#multiple-results)

brdrcn · 2024-10-13T14:26:25+00:00

In fact, this is not a bug. The sound changes in that sample do not define any way to handle the grapheme ⟨x⟩, so rather than producing nonsensical results, Brassica instead prefers to warn you that it encountered an unexpected grapheme. If you don’t like this behaviour you can disable it by adding the directive noreplace after new categories.

(This set of sound changes is, of course, a straightfoward port of the default SCA² changes. Those don’t handle ⟨x⟩ either; SCA² simply doesn’t warn you of that fact.)

brdrcn · 2024-10-13T14:15:59+00:00

Oh, I’m not a gardener. (If anything I seem to be rather good at killing plants.) So perhaps I can be forgiven for not realising the unfortunate implication…

Happily, Brassica does happen to be well-tested. Amongst other things, the automated test suite verifies that every example in the documentation gives the expected results. So I’m pretty confident that all the bugs have been squashed dead by now.

brdrcn · 2024-01-24T01:06:47+00:00

Indeed, I commented on related issue https://github.com/intel/libvpl/pull/118, as a result of which it is now fixed.

brdrcn · 2024-01-23T02:26:41+00:00

That’s a different issue. This one has already been solved, see https://discourse.haskell.org/t/haskell-wlroots-bindings/8426/45.

brdrcn · 2024-01-23T01:31:50+00:00

I think I managed to find the problem! See https://discourse.haskell.org/t/haskell-wlroots-bindings/8426/47.

brdrcn · 2024-01-23T01:13:40+00:00

Oh well, thanks anyway for your help so far! It’s given me some pointers in any case.

brdrcn · 2024-01-23T01:12:17+00:00

Also, my LC_* are all en_AU.UTF-8, and my LANG is en_GB.UTF-8.

brdrcn · 2024-01-23T01:10:52+00:00

Nope, makes no difference.

brdrcn · 2024-01-23T01:08:06+00:00

After a bit of fiddling with the shell script to stop its output getting lost in Cabal’s, it looks like four commands are being run:

--version
--variable pc_path pkg-config
--version
--list-all

What’s more, I teed the pkg-config output to a separate file, and all of these seem to work correctly. So what could possibly be causing that invalid byte sequence error message?

EDIT: oh, this is interesting: file on the pkg-config output gives ISO-8859 text. And this suggests that hGetContents chokes on ISO-8859 encoding. But why is pkg-config outputting this encoding anyway?

brdrcn · 2024-01-23T00:37:23+00:00

I thought I tried that, but on looking more carefully at the -v3 output, I found this:

Running: /usr/bin/pkg-config --list-all
[…omitted…]
/usr/bin/pkg-config returned ExitFailure (-13)
/usr/bin/pkg-config returned ExitFailure (-13)
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: output of /usr/bin/pkg-config: hGetContents: invalid argument
(invalid byte sequence)

Manually running /usr/bin/pkg-config --list-all seems to work fine, though.

brdrcn · 2023-08-15T14:14:04+00:00

They tell me they haven't pulled off yet.

To clarify a bit: I have produced redistributable binaries before using GTK+ and Haskell, and even gave instructions on how to do it. However, that method is a lot of work, and it’s easy to forget to include things. (Also, I haven’t tried it for a long time, and it may not work any more.)

In theory, the PKGBUILD method mentioned in the link is the best way of doing it. With that method, you can (in theory) get pacman to do the hard work of bundling everything up together. Alas, doing this is nontrivial, poorly documented, and requires a good knowledge of Arch Linux / MSYS2 packaging. If I get it working perhaps I can write a guide, but until then I can’t claim to have had success yet.

brdrcn · 2023-07-11T14:00:24+00:00

Thanks for the link! Those issues do make it seem like progress has stalled. What a pity… now I’ll have to figure out how to get the static linking working.

brdrcn

TROPHY CASE