ASCA v0.1.6 - NEW

[linguofreak]

That might be possible now, if you use CSV mode and start the cell with # it should work;

OK. The documentation only mentions # as being valid in the rules file, though.

[Morrígan]

That might be possible now, if you use CSV mode and start the cell with # it should work;

OK. The documentation only mentions # as being valid in the rules file, though.

Yeah, this is something I think I implemented as a hack and didn't document because it was supposed to be temporary and I didn't really like it. It might work if the cell starts with a single quote ' or grave ` too, I forget.

[Nortaneous]

Hmm... sets in the initial aren't allowed, are they? That's easy enough to work around, but would it be possible to give a more informative error message than "initial/final mismatch"? (unless I did something wrong in k{ə o u}w x{ə o u}w χ{ə o u}w > kw xw xw and I'm just not seeing it; considering my previous stupidity here, I wouldn't be surprised.)

edit: also --changes doesn't work for me on Linux with a three-line lexicon file that I created in nano (all the words were the same), but it works on my original lexicon. weird. I don't think it's a CRLF thing, since I'm pretty sure I converted it to unix format.

[zyxw59]

A feature that I'd like is multiple daughter languages, so you can have some changes applied in all of them, some only applied in some of them, others only applied in others, etc.

[linguofreak]

--changes doesn't work for me with DOS-format linefeeds, but I converted them to Unix and it worked
running Win7

I'll take a look at that; I'm probably just writing these using LF and not CR-LF.

There is also an outstanding problem with Kleene Star operators: C*_ won't work, but _C* will - I know basically why this is happening, but haven't had time to sift through the code to find out exactly why it's matching the wrong strings.

The + operator also doesn't seem to work, except after the _.

Code: Select all

C+ > 0 / _#

doesn't work (I'm trying to delete all final consonant clusters)

nor does

Code: Select all

[grave] > [long] / [any]_[any] UNLESS #C+_

(With [any] being a workaround for needing an actual condition instead of just a _ for an unless statement).

or

Code: Select all

[short] > [grave] / #C+_C+{I U}

EDIT:

Also, --changes files seem never be output in their entirety. They are truncated to lengths that are exact multiples of 8192 bytes. I'm getting on file that's getting truncated straight down to 0 bytes in length, another that's being truncated to 8192 bytes, and a third that's being truncated to 16384 bytes.

EDIT 2: After adding some data to one of my source language files, I'm now seeing a 24 kB and a 32 kB --changes file. What I think is happening is that it's generating an N byte file, then writing it out in 8 kB chunks. The last chunk is less than 8 kB and doesn't get written for some reason or other, either because an error happens when it tries to write a < 8 kB chunk, or because it determines how many chunks to right by taking N / 8 kB and rounding down instead of up.

So a 5 kB changes file gets written as an empty file, a 10 or 15 kB changes file gets its first 8 kB written, a 20 kB file gets its first 16 kB written, and so on.

[linguofreak]

The previous post was bug reports, this one is feature requests.

Is there any way to implement metathesis?

Code: Select all

VA > AV / %Insert environment here

doesn't work (where V is "vowel" and A is "approximant"), for obvious reasons, and implementing it as individual rules of the form

Code: Select all

Vl > lV / %environment

works, but is tedious and leads to ordering issues.

Also, it would be nice if, when waiting for "Enter" after an error, the program would print "Press enter to continue", or the like.

[linguofreak]

That might be possible now, if you use CSV mode and start the cell with # it should work;

OK. The documentation only mentions # as being valid in the rules file, though.

Yeah, this is something I think I implemented as a hack and didn't document because it was supposed to be temporary and I didn't really like it. It might work if the cell starts with a single quote ' or grave ` too, I forget.

I've finally gotten around to trying CSV mode, and I've found that it doesn't seem to be working properly. I've tried using both commas and semicolons as separators, but rules that are supposed to apply at the end of a word don't apply at the end of non-line-final cells.

[Bedelato]

Rule exceptions don't work right unless there's a positive condition. Just using a plain underscore for the condition will completely ignore the exception part, applying the rule unconditionally.

Yeah, this is not a surprise. I realized that it might be a problem this morning; also, you can't use OR with UNLESS, so each rule can only be blocked by one environment, which is obviously not good enough.

Also, ASCA seems to ignore the first line of the rules file. (This goes back to 0.1.3, actually, but I didn't get around to sharing it until now.)

This is most likely an encoding problem, where the file has a byte-order marker in it. I thought I was scrubbing the file for BOMs, but possibly not.

Oh yeah. I checked; it is indeed the pesky UTF-8 byte-order mark that's responsible. That little byte sequence trips up pretty much any program I've ever used.

[Lyhoko Leaci]

I solved that problem by putting comments up there.

Edit: The not reading the first line problem, that is.

[garysk]

Oh yeah. I checked; it is indeed the pesky UTF-8 byte-order mark that's responsible. That little byte sequence trips up pretty much any program I've ever used.

Um, IIRC, UTF-8 does not use a BOM, that being a "feature" of the ghastly UTF-16. UTF-16 is notorious for terminal meltdown in the face of minor corruption, not to mention ASCII incompatibility.

UTF-8 (UCS[1] Transformation Format — 8-bit) is a multibyte character encoding for Unicode. Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set. Unlike them, it is backward-compatible with ASCII and avoids the complications of endianness and byte order marks (BOM).

Suggestion: if you have BOM problems, switch your encoding to UTF-8.

[Bedelato]

No, UTF-8 doesn't need a byte-order mark, but for some reason most programs put one in there anyway.

blahblah_utf8.PNG (31.82 KiB) Viewed 6854 times

blahblah_cmd.PNG (19.91 KiB) Viewed 6854 times

What do you think that garbage in the console window is?

Just to say stuff: the Windows console uses code page 437 by default. It doesn't understand Unicode. While a most UTF-8 supporting programs recognize those three bytes (which are actually, if I understand correctly, a completely unnecessary byte-order mark) and throw them away, programs that don't recognize it will show garbage characters at the start of the file.

I've solved the problem by either putting a blank line at the top of the file, or by telling Notepad++ to "encode in UTF-8 without BOM". Windows Notepad doesn't give you that choice

[faiuwle]

Well, I have opened up with a hex editor various UTF-8 encoded text files saved in Windows and linux using (g)vim, and none of them have any kind of byte-order mark. So just using vim instead of Notepad++ might solve the problem.

[garysk]

<TOPIC_DRIFT>

No, UTF-8 doesn't need a byte-order mark, but for some reason most programs put one in there anyway.

What do you think that garbage in the console window is?

While a most UTF-8 supporting programs recognize those three bytes (which are actually, if I understand correctly, a completely unnecessary byte-order mark) and throw them away, programs that don't recognize it will show garbage characters at the start of the file.

I've solved the problem by either putting a blank line at the top of the file, or by telling Notepad++ to "encode in UTF-8 without BOM". Windows Notepad doesn't give you that choice

Thanks Bedelato for straightening me out on that! At least UTF-8 CAN be less brain-damaged than UTF-16, which is DOA.
</TOPIC_DRIFT>
------------------------------
From the Continent's left edge

[Grzanka]

I don't know if this project is still alive or not, but I have a problem with the newest version (0.1.6) and maybe someone here could help me.

I want to change a sequence of [dental]s[dental] to ss, e.g. widstós > wissós. My function for this is:

Code: Select all

[dental] = t d dʰ

[dental]s[dental] > ss

It seems to be doing fine, but only if the two dentals are the same. witstós gives wissós, but witsdós doesn't change at all. It's as if when two variables are inserted into an Initial, function only works with the same variables' values. I don't know what to do.

[Torco]

talk about necromancy!

[Grzanka]

Yeah, I know, but maybe, just maybe, someone could help me. You know, from beyond the grave...

[linguofreak]

Since Goatface is back I'm bumping this in hope that some of the outstanding bugs can be resolved.

[Morrígan]

Interesting, I must have done something very sloppy when writing variable propogation. You basically have three options right now, one would be to make two [Dental] variables with the same contents --- this should work, but I can't test it. Another option would be to use the literals on one place, so you have three lines instead of one or nine.

The best might be to do something a little different like:

Code: Select all

[dental] > s / _s[dental]
[dental] > 0 / ss_

or something along those lines. I'm working on another project at the moment but am only a few days away from being able to shelve it (I'll have it running again where it was before). I lost a lot of code somehow, and the codebase for ASCA 0.1.6 had grown out of control so I'll be starting over, hopefully letting me make something more powerful using the same rule format (so old rulesets will still be runnable)

[The Hanged Man]

Well... is something going on about the project? A lot of time passed since the last news, and the version is still 0.1.6. I'm writing this, because I have a problem with using both [ː] and [:] as markers of vowel lenght. I want to turn [ I've tried these:

i u > ɪ ʊ / _ UNLESS _ː
then
iː uː > i u

and

iː uː i u > i u ɪ ʊ

and none of them worked, I always got iː uː i u > ɪː ʊː ɪ ʊ. The marker of length seems to be ignored.

[Lyhoko Leaci]

Well... is something going on about the project? A lot of time passed since the last news, and the version is still 0.1.6. I'm writing this, because I have a problem with using both [ː] and [:] as markers of vowel lenght. I want to turn [ I've tried these:

i u > ɪ ʊ / _ UNLESS _ː
then
iː uː > i u

and

iː uː i u > i u ɪ ʊ

and none of them worked, I always got iː uː i u > ɪː ʊː ɪ ʊ. The marker of length seems to be ignored.

Use this?
i u > ɪ ʊ
ɪː ʊː > i u
I think that's what I use whenever that situation comes up.

(If for whatever reason there's already [ɪː] [ʊː] before those changes and you don't want those to merge with the final , then try something like this:
iː uː > I U (with I U being two characters that aren't used anywhere else, if I U are used somewhere)
i u > ɪ ʊ
I U > i u

And/or it's confusion from using both [ː] and [:]. (in which case, maybe add a ː > : or : > ː at the beginning, if the confusion is coming from the input)

[Qwynegold]

Is this still alive? Is the program stabile? The ASCA website is down.

[CaesarVincens]

Is this still alive? Is the program stabile? The ASCA website is down.

Morrigan left the ZBB a while back. I don't know anything about her site.

[Zju]

Is this still alive? Is the program stabile? The ASCA website is down.

There's HSCA in L&L, which seems somewhat similar to ASCA from the few examples I've seen, and is a quite good SCA. It could even be a continuation of ASCA, but I'm not quite sure about this.

[Hallow XIII]

this, whose thread is here

[Qwynegold]

Is this still alive? Is the program stabile? The ASCA website is down.

Morrigan left the ZBB a while back.

What? Oh no.

I don't know anything about her site.

I was referring to the links that she kept posting throughout this thread.