I'm investigating a patch that's misbehaving on a Mac (but weirdly, not on Windows 7 or 10), and am seeing the following message in the parent window when it fails:

There's got to be more error text somewhere--how can I view it?

@jameslo In Vanilla for windows it would be coming from "pd_connect.tcl" (the only file that will send that error).

In     append cmds_from_pd [read $pd_socket]
     if {[string index $cmds_from_pd end] ne "\n" || \
             ![info complete $cmds_from_pd]} {
         # the block is incomplete, wait for the next block of data
         return
     } else {
         set docmds $cmds_from_pd
         set cmds_from_pd ""
         if {![catch {uplevel #0 $docmds} errorname]} {`

To do with opening the socket between wish and Pd.
Mentions a lack of closing brace }
But that might not be true for OSX.
If you have a tool to search for text within files then use it to search for "docmds" to find where it exists in your installation.
Also cmds...... could be start-up flags.
Here is the whole file which you might be able to open by changing its extension to txt......... pd_connect.tcl
David.

Thanks David, but--correct me if I'm wrong--you're suggesting I search for the tcl source code that could have generated that error message. As a simpler first step (seeing as I'm tcl-ignorant), is there a way of opening a tcl console on a Mac (assuming one exists) so I can see the full error text? The message in the pd parent window, which I've pasted above in its entirety, looks truncated to me. It looks like it might have been preceded by a cause, e.g. "division by zero" or "file handle limit exceeded".

@jameslo I don't think you will get a "wish" tcl console to look at the messaging.
If you look inside pd_connect.tcl the error message is sent as part of the procedure proc ::pd_connect::pd_readsocket

I am not up to date with real programming, but something called that procedure, passed it a string, and declared that there was an "uplevel" error in line 140 of that string.

The whole tcl file seems to deal with sockets..... and seems to be the communications between Pd and its terminal.
It is really unusual to see such a small uplevel error message.... so little information.
I think only someone like @jancsika will really know.
David.

@whale-av Yikes! Bash shell! Anyway, I verified that that instance you identified is the only one that contains "uplevel #0 $docmds" but it seems like the switch statement in the else clause immediately following that ought to have at least added "(Tcl) UNHANDLED ERROR" but that's just me reading it as though it were C#/Java/C++.

If you are not afraid to edit files inside the Pd package you could add:

catch {console show}

At the beginning of "Pd-0.49-1.app/Contents/Resources/tcl/pd-gui.tcl" just before:

if { [catch {wm withdraw .} fid] } { exit 2 }

@Nicolas-Danet Thanks, that definitely opened a console window, but it looks like the error is being caught and redirected to the PD window because the console is empty except for "() 1 %". So maybe what I'm seeing is the full (unhelpful) error message....

Note that for that kind of TCL error you could provide an issue on GitHub with a minimal patch to illustrate the problem.

@Nicolas-Danet I would like to, but I'm having a hard time understanding what constitutes a helpful, minimal patch in this case. The issue occurs right when the patch is loaded and it freezes the UI 95% of the time. If I disable the loadbangs it goes away. If I delete other objects instead, ones not involved with loadbang initialization, the patch starts working with higher and higher probability, and when there's about a 50% chance that the error will occur, the error message identifies a different line on each invocation.

Adding to the confusion, I went back and tested the main branch of my code, the one that I was continuing to develop assuming I'd have to run it on my windows laptop, and now that version runs brilliantly on the Mac--loads consistently, can be adjusted for very low latency without stuttering, etc. So it would not surprise me if this issue is related to the speed of my hardware, since it appears to be contingent on the time it takes to load and initialize the patch. It's as if there's a short window of time during start up where some object is being used before it has been fully initialized.

@jameslo I don't understand the context of your screenshot. What does the entire window look like?

@jameslo You could try delaying your loadbangs in each abstraction, or use a master loadbang with delays in your main patch to send message bangs to receivers where previously you have loadbangs to bang them in a sequence..... if that makes sense.
I have sometimes had to do that with really massive patches.
David.

@jancsika
I just now noticed that this window will not scroll.

@whale-av Good idea! On the Mac, I still get the error message, but at least now the patch UI has unfrozen. On Windows, the arrays from some of the abstractions are now erroneously being drawn in the main window.
How far apart do you space your loadbangs? What kinds of problems are you addressing when you have to do that?

What happens if you change the log level to the least verbose level? Does it print out the entire error?

If not, try running pd from the command line with the "-d 3" flag. That will make it print every message to and from Pd/GUI to the command line. Then you can look at the most recent printout to the command line to try to figure out what is triggering the error. (Note, however, that every mouse movement on a canvas will trigger command line output, so try to avoid interacting at all with the patch when you look at the command line output.)

@jameslo Spacing each loadbang for me has been trial and error..... to get a patch to work.... although you have to think the patch through in terms of "what" should load before "what".
I see you using [catch] but no "no corresponding catch" messages so maybe not the problem.

In the windows patch the arrays are strange? If you open them is there actually anything inside? I doubt it. The $0 has not been translated in their names, and they are exact copies of each other (all the "left" are the same and all the "right" are the same)...... unless the $0's are different having been drawn from separate abstractions with different $0 values. Again, I doubt that is the case looking at your screenshot.. But if they are different it must be a load timing issue again. The OS might need a little more time to re-read the file repeatedly.

So there is probably one that has created correctly, and the others cannot because they have the same name, or none have created because an I/O read was abandoned as a request to read again was received. Actually that is likely?? Read the same file again.... well, I will cancel the last read then!!... might be the response from the OS, and might be different depending on which OS it is, and whether it has an SSD or a hard drive. All OS's will treat media files differently than other file types. They often load just the header and a few Mbytes of media and wait for instruction to continue.

That is (maybe) where the problem lies, especially as the error prints just after loading the exact same wav file numerous times.
If the $0's are all the same then you should find that giving them $1 names instead of $0 will solve the problem.

You could try printing each loadbang in your sequence to the terminal (with an identifier) to narrow down the exact moment or the error, but I am pretty sure it is that $0, or a "read the file again" issue.
David.

@jameslo PS...... is there a reason not to read the audio into just one array, and then point all the players to that one array? They can all read it at the same time, so normally they would not need a copy each...... unless the arrays are modified by the patch during later operation.
And unless of course trying to write it over and over again is actually a problem caused by the error, and was never your intention.

As your players seem to have a $1 value you could load the audio into each one from a loadbang like this.
[loadbang]
[delay $1]
[open xxxxxxxxxxxxx.wav(
David.

@whale-av RE those arrays in the main window: they're not real. They can't be selected, opened or deleted. They're just graphic junk copied from some of the abstractions. So those $0s are not an issue--they're just plain local variable names that for some reason are being shown in the calling patch.

RE loading the same file over and over: remember, this is the code branch where I'm trying to find a minimal patch that still exhibits the original issue. I used to have a big initialization subpatch that sent unique filenames (among other data) to each abstraction. I got rid of it to see if the problem persisted (it did) and to avoid having to include 32 unique sound files in the event that I file a bug report.

RE [loadbang]->[delay $1]->...: yes, that's exactly what I did, which is why I asked you how far apart you separated your loadbangs.

Please don't read too much into that snapshot I posted. There's lots of stuff in it that no longer serves any purpose which I either haven't gotten around to removing, or seems to be required to reproduce the error.

@jancsika OK, I fell back to my last broken, half-minimized version (the one without David's loadbang delays), unchecked the verbose box in Pd->Preferences->Path...(not sure if that's really the least verbose level, but that's what I did) and suddenly everything works, and there are no messages in the parent window, error or otherwise. So I didn't try your "-d 3" flag suggestion.

I still don't know if the problem is reproducible on other Macs though. Would someone be willing to give it a try? player.zip Unzip it to some folder, run [player.pd], try to move any of the vertical sliders, and look for an error message in the parent window. Try with verbose checked and unchecked. On my machine with verbose checked, the vertical sliders look like they're not moving, but they actually are. If I click anywhere on the fader then click the upper right toggle, I hear the corresponding sound file.

Bingo! I reproduced the error on my ancient Lenovo and got the following error message: Note the noise in the command string. This has got to be helpful to a developer, no?

@jameslo AhHH..... totally misunderstood.
I am away for a few days in the "frozen" North (-14C) with no time to check your patch until next week. Someone else probably will though.
Frozen faders that are really moving (in the window below) I have had with complex patches and I think I wrote about it on this forum years ago. I can't for the life of me remember my conclusion or solution though.
I will post if I find it on my laptop but it is probably on the server at home.

But but but..... WOW..... how great is the internet.
https://forum.pdpatchrepo.info/topic/8226/dynamicaly-created-gop-s-frozen-until-child-opened-the-first-time
Even Dementure might not see the back of me.
And also maybe the "uplevel" error is meaningful for your patch after all.

So maybe write your entire patch into a sub-patch, so that it is not drawn as it is created, and then send it the vis 1 message once all is loaded.
David.

@jameslo Now that you've got more error output, try adding the "-d 3" flag to the startup flags. Keep it in verbose mode.

Then when you trigger the error, scroll back in the command line terminal until you find the same garbage that is quoted in the error in the Pd console.

Paste a chunk of that output which surrounds the garbage somewhere so we can inspect it.