[PD] Ability to access error messages from patch

[IOhannes m zmölnig]

"On 6/17/21 23:47, Miller Puckette via Pd-list wrote:
> to scare people... more seriously, because I'd consider such a thing "meta"
> (such as message back-tracing, which I also want to add someday)
> 

i see.

> I don't have a precise idea what I mean by "meta" here.


:-)


afaict, there's a couple of different object-types:

1. "normal", modular-synth like objects
this probably includes practically *all* signal-processing objects (e.g. 
[osc~])
and other, simple operator objects (e.g. [+])

2. "language"-defining constructs.
this is the class of objects that define the "patcher language".
i think there are at least two subgroups
  a. data-flow objects ([trigger], [spigot], [select], [route], [until],...)
  b. abstract concepts, such as subpatches ([pd]), abtractions, 
arguments ($1), declarative objects ([declare], [namecanvas], 
[block~]/[switch~],...), but also [clone] and [pd~]

3. "introspection" thingies
objects that allow us to gather meta-information on the patch itself.
iemguts is an external collection of mostly such objects.
but there's also built-in support for introspection, e.g. the [dir( and 
[isvisible( messages to [pdcontrol].

for me, "meta"-objects would be of the 3rd kind (and probably 2b).

i think that error-reporting - as we know it from other languages like 
C++, java, python,... - is a typical "language" feature.
otoh, getting a backtrace is more about introspection of the running patch.

i understand that you are reluctant to add new "language" (or even 
"instrospection") features, as it's practically a bottomless pit (and 
where would we end up, if we stared too long into that? ;-))


now what i really hate about [pdcontrol], is that it belongs to all 
three categories.
of course the groups are not totally orthogonal, and there's certainly 
object that fit into more than one (e.g. [change]).

but with [pdcontrol] this is different, as it just bundles unrelated 
functionality into a single object, but the so-far implemented 
functionalities actually are rather easy to categorize:
- [browse(->[pdcontrol] just belongs to the "normal" group (it is 
somehow non-standard as it is asynchronous and involves the Pd-GUI, but 
that is actually an implementation detail)
- [args( is really just an extension of the argument-system (and it was 
always possible to get all arguments of a patch; it just involved a lot 
of idiosyncracies (which is ok, as we are on the "language"-level) and 
the only way to re-use the code was by copy-and-paste (instead of 
wrapping it into an abstraction)
- as mentioned above, [dir( and [isvisible( messages really give you 
meta-information about the patch, so they belong the "introspection" group.

and of course the name "pdcontrol" does not suggest *any* of the 
functionality we have so far.
leaving out the [browse( message (which could just be implemented in a 
dedicated object and no-one would be off any worse), all the other 
messages so far operate on either a canvas- or a patch-level.
at least for me, "pdcontrol" always suggests an "interface to 
control/communicate with Pd" (very much related to what we can already 
do by sending things to "pd"; but - being an object - theoretically much 
more powerful, as it allows us to get data back).
i definitely don't read that name as "interface to a [pd]".
it also doesn't convey the meaning of "this is a perilous realm; go away 
and be scared".

and then there is [pdcontrol catch-printout] which is actually a totally 
different objectclass. hmm.


for practical reasons, i think it might help if we could just separate 
the various functionalities into separate objectclasses.
at least like [pdcontrol args] and [pdcontrol dir].
i guess nobody actually has a need to query the selfsame object for both 
the visibility state of a window and to ask it where on the disk 
supplementary files are located.
probably also rename the object to [canvascontrol] or [patchcontrol].

in order to scare people away from using experimental objects, we might 
use some prefix clearly marking them as such: [XXX.browsefile]


and finally: which object would I use to get the version of the running Pd?




mfgds
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210618/0d81f9a1/attachment.sig>