Updates to Github #github
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
My suspicions go to the This is how I instrumented it :
For the parsing of the
We can clearly see that after What's your opinion on this ?
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
My suspicions go to the This is how I instrumented it :
For the parsing of the
We can clearly see that after What's your opinion on this ?
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
Thanks! So it is the following sequence that looks really suspicious :
After putting back a space in the stream, we jump far away in the file (in the
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Yeah, that looks like it is the issue. I'm not sure what is going on with that yet.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Check
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Yes, it's exactly what I was doing :-) Getting this sequence :
Looks like there were some calls to UngetItem, but not immediately before the jump.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
No better luck :-) Unfortunately it has no effect. I have to make a pause, but I'll get back at it later, and try to use GDB for better insight.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Have a good day.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Thanks, you too, and for your help!
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
Further investigation, it looks there's something really nasty happening with the stream, if I instrument like this :
The presence of
I wonder if the reason is not that we put back a character which is not the one it was before (?!). We get ')' but we unget ' ' after
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Further investigation, it looks like there's something really nasty happening with the stream, if I instrument like this :
The presence of
I wonder if the reason is not that we put back a character which is not the one it was before (?!). We get ')' but we unget ' ' after
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By rhdunn:
That is strange. On my machine, I get output like:
So
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
I'm trying to narrow the problem ; could you try to compile and launch this small program on your machine ?
The behaviour of that program is strange to me, it has the 'jump' effect :
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
This is the test file "testfile" that goes alongside the program :
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By rhdunn:
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Ouch. Looks like we have the problem :( The behavior of ungetc + ftell is no more compliant.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
I've been thinking of trying a local implementation of the unget behaviour, but haven't currently figured out how to get it working. I'm not sure why ungetc is not working properly on Mac in this case. It is most likely a bug in their implementation.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Funny enough, if I replace the
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By rhdunn:
http://man7.org/linux/man-pages/man3/ungetc.3p.html doesn't say that the ungot character has to be the same as the character previously read. The following simple ungetc replacement does not currently work:
I'm getting a lot of errors, starting with:
That looks suspiciously similar to what you are seeing (esp. re: the line numbers), so maybe that is what the Mac implementation is doing internally.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Can you check what
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
Ok, I've had a look at this. The result of ungetc looks ok : it always returns the value of the character that was ungot, even in the suspicious cases.
[espeak-ng:master] New Comment on Issue #652 Incorrect pronounciation of atelier
I added this as another word in en_list. Does atelier.wav.zip sounds right?
[espeak-ng:master] New Comment on Issue #655 Esperanto: pronunciation of A
I changed definition of a sound. Does this Esperanto.wav.zip sounds better?
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
However, I can see some potential problems with your implementation :
Maybe one possible implementation would be to work with one big buffer instead of a file stream ?
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
However, I can see some potential problems with your implementation :
Maybe one possible implementation would be to work with one big buffer instead of a file stream ?
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
However, I can see some potential problems with your implementation :
Maybe one possible implementation would be to work with one big buffer instead of a file stream ?
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By rhdunn:
Will do, thanks.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Note : one other potential problem I see is that f_in can be switched to another file in the stack (thus the buffered byte for one file may interfere with another file). I don't know if it should be taken into account or not.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By BenTalagan:
One additional note, I could not find the source for Catalina. But in precedent versions of macOS, the code of
In the first case, it's a simple rewind of the file pointer. In the second case, a buffer is used. That could explain why I see different behaviors depending on the fact that we push back the same character that was read and why it can interfere with ftell.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
One additional note, I could not find the source for Catalina. But in precedent versions of macOS, the code of In the first case, it's a simple rewind of the file pointer. In the second case, a buffer is used. That could explain why I see different behaviors depending on the fact that we push back the same character that was read and why it can interfere with ftell.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Interesting. Thanks. I wonder what is causing espeak to unget a character different to the previously read character. Maybe addressing that will fix the issue you are seeing on the Mac (and possibly on other BSD-based platforms).
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
By rhdunn:
That works on my machine, so feel free to create a patch. Are there any other problems?
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
I don't think so. I remember having a problem with emscripten a few months ago (#584), the compiled js was unable to parse correctly the bundled data. I don't know, it might be related (or not). Will give it a try again later, but I will prepare a PR for now.
[espeak-ng:master] New Comment on Issue #674 Build fails on MacOS Catalina
Great. Thanks.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
2 New Commits:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/compiledata.c
[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
Modified: src/libespeak-ng/compiledata.c
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#675 Fixing ungetc bad behavior under macOS Catalina This is a fix for (#674). For archiving purpose, the problem was the following : it seems that the The fix consists in avoiding such a situation.
[espeak-ng:master] New Comment on Pull Request #675 Fixing ungetc bad behavior under macOS Catalina
Merged. Thanks.
[espeak-ng:master] Label added to issue #674 Build fails on MacOS Catalina by BenTalagan.
[espeak-ng:master] Issue #674 Build fails on MacOS Catalina closed by BenTalagan.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
By BenTalagan:
After taking time to investigate, I think I have found the problem. It comes from the following lines : They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes. @rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
After taking some time to investigate, I think I have found the problem. It comes from the following lines : They behave differently when compiled with llvm and emscripten. Under llvm, like with gcc, this will have what I would call an 'expected' behaviour : the cast to unsigned int from any position in the char* buffer will take into account the fact that we are not aligned to a multiple of 4 bytes. Under emscripten it doesn't : shifting by n+0, n+1, n+2 or n+3 bytes leads indifferently to the same result when casting to an int. One of the rules of the 'en' dictionary falls under this case, so the condition of having 4 successive bytes at 0 is not met and the rule parser explodes. @rhdunn, I'd like your opinion on that issue : should we implement a simple fix for this (like testing the four bytes instead of casting to unsigned int), are there any other part of the code that may be concerned?
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
Add : after reading a bit on the net, it really looks like this should be rewritten. Some refs : https://stackoverflow.com/questions/26995151/how-to-cast-char-array-to-int-at-non-aligned-position
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng/espeak-ng] Pull request opened by BenTalagan:
#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided. Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.
[espeak-ng:master] New Comment on Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation
@rhdunn : Thanks for your answer ! I have prepared a PR (#676), and limited myself to add a function to test sequential bytes to zero. It's very close to what was intended originally and non intrusive (the original code only tests four bytes, but after that they are still read one by one, not 4 by 4).
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
4 New Commits:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: emscripten/Makefile
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/dictionary.c
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: src/libespeak-ng/readclause.c
[espeak-ng:master] By Reece H. Dunn <msclrhd@...>:
Modified: emscripten/Makefile
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo This is a fix for #584, but the PR scope may be potentially larger : without this fix, the handling of compiled rules is not guaranteed to be compliant across platforms, since casting to int* may happen on non aligned char* , which has to be avoided. Some minor options also have to be added to the emscripten compilation workflow to make it work again with newer versions.
[espeak-ng:master] New Comment on Pull Request #676 Rule alignment fixes for non compliant platforms / Fix for emscripten demo
That's what tests are for :). Thanks for the fix.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] Label added to issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation by BenTalagan.
[espeak-ng:master] Issue #584 emscripten demo broken, probably highlights underlying problem linked to dictionary compilation closed by BenTalagan.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng/espeak-ng] Pull request opened by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the language-replace.test script under MacOS. The
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By rhdunn:
Why not replace it directly with
[espeak-ng/espeak-ng] Pull request updated by BenTalagan:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Good point! I wasn't sure. I have done the change, just waiting for the tests to be over.
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Good point! I wasn't sure. I have made the change, just waiting for the tests to be over... done.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
1 New Commit:
[espeak-ng:master] By BenTalagan <ben_talagan@...>:
Modified: tests/language-replace.test
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
I've merged this commit by cherry-picking the last commit. Thanks for the fix.
[espeak-ng/espeak-ng] Pull request closed by rhdunn:
#677 Fixing "Language Replace" tests under MacOS A small PR for fixing the
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Ok! Thanks a lot.
|
|
espeak-ng@groups.io Integration <espeak-ng@...>
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
By valdisvi:
[espeak-ng:master] New Comment on Pull Request #677 Fixing "Language Replace" tests under MacOS
Under MacOS, it seems egrep and grep are the same binary.
|
|