Bug 2137 – Nyquist: Assert when receiving multibyte characters

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 2137 - Nyquist: Assert when receiving multibyte characters


Summary:	Nyquist: Assert when receiving multibyte characters

Status:	RESOLVED FIXED

Product:	Audacity
Classification:	Unclassified
Component:	Nyquist
Version:	2.3.3
Hardware:	Per OS All

Importance:	P4 RepeatableAll
Assigned To:	Default Assignee for New Bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2019-06-20 19:47 UTC by Steve Daulton
Modified:	2019-07-29 11:27 UTC (History)
CC List:	5 users (show)

See Also:
Steps To Reproduce:	With a debug build 1) Select French as the locale 2) Enter the following code in the Nyquist Prompt: (format t "~a~%" (aud-do "GetInfo2: Type=Tracks Format=LISP")) (print "See debug output") 3) Click the Debug button. Note there is a series of Asserts: ../src/common/unichar.cpp(52): assert "Assert failure" failed in FromHi8bit(): invalid multibyte character Alternative steps for release build: 1) Select French as the locale 2) Enter the following in the Nyquist Prompt: (setf output (format nil "~a~%" (aud-do "GetInfo2: Type=Tracks Format=LISP"))) (print output) 3) Press the Debug button. Note that the message in the Debug window is displays accented characters incorrectly: "(Votre commande de traitement par lot de GetInfo2 n\342\200\231a pas \303\251t\303\251 reconnue.)"
Release Note:
First Git SHA:
Group:	---
Workaround:
Closed:	2019-07-29 00:00:00

Flags:	james.k.crook: Must‑Test‑All‑OS+ petersampsonaudacity: Test‑OK‑Win+ petersampsonaudacity: Test‑OK‑Mac+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Steve Daulton 2019-06-20 19:47:03 UTC

Nyquist may receive multibyte Unicode characters from AUD-DO, but is unable to handle them correctly.

James wrote:
"We have to make Nyquist multibyte safe.
For now, where Nyquist receives a unicode string (from aud-do) we need to do a conversion.

Converting Nyquist itself to operate on unicode strings is a rewrite of much of XLisp.  It won't happen.  So we need to adopt an approach such as using html encoding, and doing conversions on output."

Comment 1 James Crook 2019-07-16 09:21:55 UTC

DEVEL - FIX MADE
https://github.com/audacity/audacity/commit/20772c995d62e3552ae8432e6e3fbc5b65a94ed2

Comment 2 Peter Sampson 2019-07-17 04:14:18 UTC

Testing on W10 with audacity-2.3.3-alpha-290-20772c995d62e3552ae8432e6e3fbc5b65a94ed2

This works fine on the non-debug build.

I do not have access to debug builds to test this on.

Comment 3 Peter Sampson 2019-07-25 07:10:09 UTC

Testing on macOS 10,14.5 with mac 2.3.3 alpha jc004 of 25Jul19

This works fine on the non-debug build with the non-debug steps

I do not have access to debug builds for Mac to test this on further.

@Steve: can you please test with debug builds

Comment 4 Steve Daulton 2019-07-29 11:03:17 UTC

(In reply to Peter Sampson from comment #2)
Peter wrote:
> This works fine on the non-debug build.

The code should return an error message:
"Votre commande de traitement par lot de GetInfo2 n'a pas été reconnue."

What I see is an error message:
"Votre commande de traitement par lot de GetInfo2 n_a pas _t_ reconnue."


The assert is fixed, but the error message makes no sense in French.

I don't personally think that we need to support non-English languages here as this is only when working with code, but if we are to use translations, they should be readable.

Comment 5 James Crook 2019-07-29 11:26:43 UTC

Comment 4 confirms that the bug as stated is fixed.
When aud-do commands return multibytes there is now no assert.


Fixing Nyquist to handle multibytes is a feature request, and is too big a feature to be an Enhancement request in Bugzilla.  Mandating that aud-do never return multibytes is also too restrictive, as then scripting in python cannot use foreign alphabets, e.g. when reporting on menu items.  We might decide not to translate error messages, but when the UI is translated, so will be results like the GetInfo menu strings.

Accordingly this bug IS fixed and the 'residual' is a feature request for a big new feature.