Update eSpeak NG used with NVDA

[lukaszgo1]

Steps to reproduce:

Update eSpeak NG submodule to the latest master and try to build NVDA.

Actual behavior:

Build fails with the following output:

espeak_compileDict_buildAction(["include\espeak\espeak-ng-data\ur_dict"], ["include\espeak\dictsource\ur_list", "include\espeak\dictsource\ur_rules"])
Can't read dictionary file: 'C:\Users\Lukasz\nvda\include\espeak/espeak-ng-data\ur_dict'
Using phonemetable: 'ur'
Compiling: 'C:\Users\Lukasz\nvda\include\espeak\dictsource/ur_list'
        3028 entries
Compiling: 'C:\Users\Lukasz\nvda\include\espeak\dictsource/ur_rules'
        1488 rules, 62 groups (44)

Install file: "include\espeak\espeak-ng-data\ur_dict" as "source\synthDrivers\espeak-ng-data\ur_dict"
espeak_compileDict_buildAction(["include\espeak\espeak-ng-data\ar_dict"], ["include\espeak\dictsource\ar_listx", "include\espeak\dictsource\ar_list", "include\espeak\dictsource\ar_rules"])
Error: The requested functionality has not been built into espeak-ng.
scons: *** [include\espeak\espeak-ng-data\ar_dict] ValueError : 2 is not a valid espeak_ng_STATUS
ValueError: 2 is not a valid espeak_ng_STATUS

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Lukasz\nvda\.venv\lib\site-packages\SCons\Action.py", line 1279, in execute
    result = self.execfunction(target=target, source=rsources, env=env)
  File "C:\Users\Lukasz\nvda\build\x86\espeak\sconscript", line 325, in espeak_compileDict_buildAction
    f"Failed to compile dictionary: '{target}'"
  File "C:\Python37\lib\enum.py", line 315, in __call__
    return cls.__new__(cls, value)
  File "C:\Python37\lib\enum.py", line 569, in __new__
    raise exc
  File "C:\Python37\lib\enum.py", line 553, in __new__
    result = cls._missing_(value)
  File "C:\Python37\lib\enum.py", line 582, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 2 is not a valid espeak_ng_STATUS
scons: building terminated because of errors.
Deactivating NVDA Python virtual environment

Expected behavior:

Build succeeds

System configuration

NVDA installed/portable/running from source:

From source

NVDA version:

Latest master

Windows version:

N/A

Name and version of other software in use when reproducing the issue:

N/A

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

N/A

If NVDA add-ons are disabled, is your problem still occurring?

N/A

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

Technical:

I've bisected the issue and it was introduced by espeak-ng/espeak-ng@572fe31
Frankly I do not understand why it affects us since we do not use Mbrola at all but perhaps the fact that we're excluding Mbrola files is the culprit here.
cc @sthibaul Since the eSpeak NG commit was written by you perhaps you have some ideas?

[sthibaul]

I don't see how the execution can end up in that part of the code since it's only reached in the V_MBROLA case, which is produced only when seeing the mbrola keyword. From your log piece it seems that the ur language went fine, but ar didn't. Do you perhaps have a modified version of the ar voice files that could include an mbrola keyword?

[lukaszgo1]

No - this log has been taken with the clean master branch of the eSpeak NG repo. Reverting 572fe31 allowed eSpeak to build as it should.

[sthibaul]

• did a lot of other languages build fine before in the log?
• If you comment the ar_dict part from the build, do other languages build fine? (possibly it's just nvdaHelper/espeak/sconscript which needs fixing)
• possibly some other languages fail, it'd be important to determine what is common among them

My best guess at this point is that somehow the voice files are parsed incorrectly and somehow end up seeing an mbrola keyword in an improper context, thus believing that the voice is about mbrola, which it really shouldn't at all, and my commit just reveals that completely improper parsing.

[lukaszgo1]

• did a lot of other languages build fine before in the log?

The following languages compiled fine before "ar":

• pt
• cmn
• qu
• gd
• tn
• sw
• lfn

* If you comment the ar_dict part from the build, do other languages build fine? (possibly it's just `nvdaHelper/espeak/sconscript` which needs fixing)

No - while a next wave of languages compiles build eventually fails in the same way.

* possibly some other languages fail, it'd be important to determine what is common among them

Commenting out the following languages results in a successful build:
ar, hi, ja, ms, cs, es, el

[sthibaul]

Commenting out the following languages results in a successful build: ar, hi, ja, ms, cs, es, el

Uh. I don't really see a pattern here :)

It would be really helpful if somebody could put a breakpoint on the espeak_ng_PrintStatusCodeMessage(status, stderr, NULL); call in the V_MBROLA case and get a backtrace with full info, to determine how the hell we end up here.

(note: erroneously ending up here doesn't seem like a new thing, if you look at the build logs with the older espeak-ng, you will see that Error: The requested functionality has not been built into espeak-ng. message already for these languages)

[sthibaul]

(just to make it clear:

	espeak_Initialize(AUDIO_OUTPUT_PLAYBACK, 0, DATAPATH, espeakINITIALIZE_DONT_EXIT);

	char * lang = "ar";
	espeak_VOICE voice = { .languages = lang, };
	err = espeak_SetVoiceByProperties(&voice);
	printf("%d\n", err);
	err = espeak_ng_CompileDictionary(RULESPATH "/", NULL, NULL, 0, NULL);
	printf("%d\n", err);

doesn't spit any error on Linux, so there must be something misbehaving on Windows)

[seanbudd]

Like what @sthibaul has said, it's likely nvdaHelper/espeak/sconscript that needs fixing. Just to confirm, did you follow the instructions in espeak.md?

[lukaszgo1]

Like what @sthibaul has said, it's likely nvdaHelper/espeak/sconscript that needs fixing.

This is very unlikely - as discussed above the error in eSpeak was always there it just was not causing a failure before espeak-ng/espeak-ng@572fe31 was introduced.

Just to confirm, did you follow the instructions in espeak.md?

There were no changes to makefile between the commit of eSpeak we're currently using in master and espeak-ng/espeak-ng@572fe31 which causes a failure so no updates to our sconstruct file were necessary.

[sthibaul]

By "fixing" I only meant to make the build pass, I didn't mean a proper fix.

My best guess at the moment is that somehow the voice files are getting parsed in a bizarre way that makes somehow the "mbrola" word showing for whatever reason, and thus the mbrola code be hit. That's why a backtrace would be very precious to replace all the "somehow" words in the previous sentence.