AI scripting - misleading log ...I just analyzed a code created by a less favorite AI:
dt = Open("$SAMPLE_DATA/Big Class.jmp");
kd = dt << KDTable("hello");
result = kd << K Nearest Rows(1, 3);<BR />print("finished");
The log said:
Object 'Data Table' does not recognize the message 'K Nearest Rows'; perhaps you mean one of these: <<<<<<<<<<<<<<<<<<<<<
finished
Sure: if a scriptable object doesn't understand a message, it shows such a warning message in the log.
And a Data Table doesn't understand the the message K nearest Rows().
But wait, why is kd a data table?!
This is easy to answer: In the previous line of code, the data table doesn't understand the command << KDTable("hello");
And therefore, instead of returning a KD table, it returns a reference to itself.
Unfortunately, here is NO warning message:
Object 'Data Table' does not recognize the message 'KD Table("hello")'
A JSL scripter will spot the error within seconds : KD Table("hello") , tztztz!
But you’d probably agree—it’s hard to find the error from the information JMP provides!
How to escape this issue? Is there a general rule or trick?
Can JMP / the JSL interpreter be improved to help AI and the users understand the errors?
Users with paranoia could add If (type(name Expr(returned object) == ...) after every message sent to a scriptable object. Hm ...
Automation and ScriptingRe: AI programming - misleading log ...JMP is designed this way. I also wish it was different. The parts of the design that make this happen are (1) objects ignore messages they don't understand and (2) messages can be chained. Many releases ago JMP added a preference to make some objects report unrecognized messages. Whether it works depends on the object; I think the display boxes all have some common code to deal with it.
Chaining messages, like tb<
By those rules, line 2 of your example does what it is supposed to.
I think the silently ignore unrecognized messages probably originated from studying the MS-windows message handling (previous century); there are an incredible number of messages that are silently ignored (like the mouse is moving over you, but you have no intention of ever responding to the mouse.) In JMP it could be used like this: { textBox, outlineBox } << setcolor("red") << close(1); where any box in the list that understands <<
The difference between the two messages your examples sends to the data table is kdtable() is a global platform-like function while < is a message that is only known to a kdtable object. The datatable itself likes to see messages that look like platform launches, dt< for example. There is a bug here. I suspect kdtable is at fault for not reporting an issue with the "hello" argument, and the data table may think a platform was launched. Maybe the empty platform (sorry, there is no such thing.)
kdtable("hello")
/*:
Empty()Re: AI programming - misleading log ...Hi
@Craige_Hales , thanks a lot for the detailed background – Sure, I can understand
why JSL was designed this way back then (silent ignore of unknown messages + chaining returning the left‑hand object).
However, I also hope that the JSL developers see that this pattern has become somewhat “incompatible” with today’s AI‑assisted vibe coding:
LLMs happily invent messages, platform calls and arguments, and with the current behavior they often just get silently ignored. That doesn’t only confuse, it can also turn debugging into pure hell – you end up hunting the symptom instead of the root cause.
Maybe, developers can provide a JSL‑level switch for “AI debug / chatty mode” :
to deliberately turn on noisy, but incredibly helpful diagnostics for selected object classes (e.g. display objects, platforms, general scriptable objects).
The idea is that when the end result looks weird, you enable this mode and JMP starts complaining exactly where things first go off the rails, instead of failing quietly and only shouting much later. I’ve put this into a Wish List item here for voting:
chatty mode() for AI debugging
Thanks again for the insights and for confirming that this is an area where behavior could be improved.
