Adam Murray

I encountered a strange bug in my patch tonight and I'm trying to understand what Max/mxj is doing.

I had a message with an escaped semicolon, like 'a;b'. It went through an [sprintf] object before getting sent to an [mxj] external. Then in my anything(String msg, Atom[] args) method, one of the args was null and I got a NullPointerException.

I also see a strange error in the Max window: 

After some debugging I determined that the semicolon character came through as an Atom in the args array, but it was represented by a null.

I fixed my patch by using a [sprintf symout ...] but I'd like to make my mxj objects as robust as possible.

If anyone can enlighten me as to what's going on here I'd appreciate it. Is it safe to assume that whenever anything() receives a null argument, that it represents the semicolon character? Is it possible this is a bug in [mxj]?

Here's some Java code and a patch to demonstrate. When clicking on the right message box, the Max window shows:

public class wheresMySemicolon extends MaxObject {

    public void anything(String msg, Atom[] args) {

        System.out.println("Message '" + msg + "' with " + args.length + " args:");

            if (arg == null) {

                System.out.println(" null");

            else if (arg.isString()) {

                System.out.println(" '" + arg + "'");

                System.out.println(" " + arg);

I had a message with an escaped semicolon, like 'a;b'. It went through an [sprintf] object before getting sent to an [mxj] external. Then in my anything(String msg, Atom[] args) method, one of the args was null and I got a NullPointerException. 

I also see a strange error in the Max window: 
newAtom: default (10)

newAtom: default (10)
Message 'a' with 2 args:
  null
  'b'

import com.cycling74.max.Atom;
import com.cycling74.max.MaxObject;

	public void anything(String msg, Atom[] args) {
		System.out.println("Message '" + msg + "' with " + args.length + " args:");
		for (Atom arg : args) {
			if (arg == null) {
				System.out.println("  null");
			}
			else if (arg.isString()) {
				System.out.println("  '" + arg + "'");
			}
			else {
				System.out.println("  " + arg);
			}
		}
	}
}

escaped-semicolon-sprintf-weirdness

Quote: Adam Murray wrote on Wed, 05 November 2008 23:17

----------------------------------------------------

> Is it safe to assume that whenever anything() receives a null argument, that it represents the semicolon character?

It is in fact NOT safe to assume this. If I send the message 'a,b' (a comma) then the [mxj] object exhibits the same behavior.

(semicolon was almost the same error except 10 instead of 11).

So can I distinguish a semicolon from a comma in this situation from inside an [mxj]? I'm thinking it's currently not possible. Maybe the Atom class could use a few new methods, like:

or getType() and a set of constants for the different internal Max types.

I don't suppose there's any way to help flesh out the Java API? Sometimes I wish this part of Max were open source. Oh well.

Quote: Adam Murray wrote on Wed, 05 November 2008 23:17
----------------------------------------------------
> Is it safe to assume that whenever anything() receives a null argument, that it represents the semicolon character? 

It is in fact NOT safe to assume this. If I send the message 'a,b' (a comma) then the [mxj] object exhibits the same behavior. 

But I see this in the Max window:
newAtom: default (11)
(semicolon was almost the same error except 10 instead of 11).

I don't suppose there's any way to help flesh out the Java API? Sometimes I wish this part of Max were open source. Oh well.


On 6 nov. 08, at 08:17, Adam Murray wrote:

The only way to have "a;b" is to have that as a symbol. The problem 

is not even in java, when you look at the output of sprintf (which 

doesn't have the symout argument) the output is changed because of the 

> newAtom: default (10)
> Message 'a' with 2 args:
>  null
>  'b'

The only way to have "a;b" is to have that as a symbol. The problem  
is not even in java, when you look at the output of sprintf (which  
doesn't have the symout argument) the output is changed because of the  
specific behavior of the semicolon

Quote: Emmanuel Jourdan wrote on Thu, 06 November 2008 03:40

> The only way to have "a;b" is to have that as a symbol. The problem 

> is not even in java, when you look at the output of sprintf (which 

> doesn't have the symout argument) the output is changed because of the 

I think you misunderstood. I am not trying to get "a;b" in Java. I am trying to properly interpret any input sent to the Java object. It's an object for processing arbitrary text and I'd like it to "just work".

In the patch you just provided, even if I don't use symout with sprintf, the message box displays the ';' so Max is definitely passing this token around even if its meaning has changed.

If I hook this up to the [printit] external from CNMAT, I see:

printit: received MESSAGE "a" (0x50e770, s_thing 0x0) with 2 argument(s):

A_SEMI (semicolon: ";") - its own special undocumented Max data type

The problem here is that Java doesn't seem to understand anything about that "A_SEMI special undocumented Max data type"

I want information like that inside [mxj]. Instead it just gives me a null atom. And it does the same thing with comma. How can I distinguish a semicolon from a comma? I can't...

See my problem? This situation can be worked around in the patch, but I could more cleanly work around it in the Java code if I had this extra piece of information.

It's not a big deal, just one of those small cracks in the Java API that could be filled in to make life a little easier for some external developers.

Quote: Emmanuel Jourdan wrote on Thu, 06 November 2008 03:40
----------------------------------------------------
> The only way to have "a;b" is to have that as a symbol. The problem  
> is not even in java, when you look at the output of sprintf (which  
> doesn't have the symout argument) the output is changed because of the  
> specific behavior of the semicolon
>

In the patch you just provided, even if I don't use symout with sprintf, the message box displays the ';' so Max is definitely passing this token around even if its meaning has changed. 

printit: received MESSAGE "a" (0x50e770, s_thing 0x0) with 2 argument(s):
 A_SEMI (semicolon: ";") - its own special undocumented Max data type
 SYMBOL "b" (0x50e778, s_thing 0x0)

It's not a big deal, just one of those small cracks in the Java API that could be filled in to make life a little easier for some external developers.


On 6 nov. 08, at 17:12, Adam Murray wrote:

> See my problem? This situation can be worked around in the patch, 

> but I could more cleanly work around it in the Java code if I had 

Sorry I read too quickly. This is currently not possible. Sorry for 

> See my problem? This situation can be worked around in the patch,  
> but I could more cleanly work around it in the Java code if I had  
> this extra piece of information.

Sorry I read too quickly. This is currently not possible. Sorry for  
any inconvenience.

Quote: Emmanuel Jourdan wrote on Thu, 06 November 2008 11:04

---------------------------------------------------- 

> Sorry I read too quickly. This is currently not possible. Sorry for 

No problem, I was just wondering if there was a way to do it right now. So question answered.

Maybe at the bottom of the C74 todo list you could add an issue for exposing this special type information to the Java API. I won't expect it to be resolved any time soon but I may bug you about it in a year or two ;)

Quote: Emmanuel Jourdan wrote on Thu, 06 November 2008 11:04
---------------------------------------------------- 
> Sorry I read too quickly. This is currently not possible. Sorry for  
> any inconvenience.
>

No problem, I was just wondering if there was a way to do it right now. So question answered. 

Maybe at the bottom of the C74 todo list you could add an issue for exposing this special type information to the Java API. I won't expect it to be resolved any time soon but I may bug you about it in a year or two ;)


Escaped semicolon + sprintf weirdness