Page MenuHome

Python output not showing consistently in on OS X
Closed, ArchivedPublic


Group: V 2.48a release
Category: Python

I am having problems getting Python messages and general Blender messages to show in on Mac OS X 10.5.5.

A workaround is to deliberately generate some Python errors. It seems to me that Blender is being conservative with dumping output to the log file. This probably helps performance, but makes it very difficult to debug scripts, both regular Blender scripts and from the game engine.

I'm not sure if there's a setting somewhere in Blender or the console, or an alternative IO stream to log to, but I've been unable to find it after extensive searching.

The attached .blend shows the behaviour on my machine. Instructions included.

Blender 2.48a / OS X 10.5.5 / intel Core 2 Duo 2.5 / 2GB RAM / Geforce 8600M GT.



Event Timeline

Since submitting this bug, I've found out you can have a terminal window monitoring the Python log. (By starting Blender from inside the .app package).

Still, this looks like erratic behaviour, and the recommendation to look at for output is still there in many tutorials and help threads.

I can confirm this issue. Still looking into it. :/

Using watch "syslog -C | tail" to watch the output you can see the python strings if you use the line sys.stdout.flush() after your python print statements

Yes, the osx terminal is not well configured for direct debugging, use Console instead.

I always run Blender in small window when testing, so console is visible;
./ -p 500 200 1000 800

Ton Roosendaal (ton) closed this task as Archived.Apr 20 2009, 6:37 PM

I'm curious why this bug was closed. People are still having issues with consistent monitoring in the console under 10.5.

There is indeed some confusion on this issue. The issue has even been submitted again after this one was closed: (also closed)

Maybe I can clear a couple of things up: / system.log is simply a bad place for this sort of output. The system.log is a useful place to see what your computer was doing at any given time, why an app crashed, etc. However, this log contains data from any app / process, and is continuously written to disk (as a large file including the backlog). This means that to see things in the log, the log process has to process them first. Naturally, if this wasn't done intelligently / with a buffer, every process would write to the disk several times a second - very bad for performance. So, the logging is done in the background and asynchronously, no promises made on when precisely things will appear, just that they eventually will, and in the correct order.

If you program your own app in XCode, and dump stuff to the log, you have the same issue - you can get the output in system.log, but you can't dictate when it appears. At least, if you try to, performance suffers. So, in XCode, use the debugger, which has a terminal directly showing output without having to write to the log. Memory vs. hard disk / focused task vs. general system tool.

We can do the same for Blender.

I found out how, and have put together sort of a walk-through on how to get a double-clickable application with the right icon that launches a terminal output window, here:

(It takes all of two minutes).

The issue remains one of education - "console" is sometimes used interchangeably with "terminal" or "shell", to describe the output window you see on e.g. Windows. Yet, on OS X you decidedly want a Terminal window, not a Console. (It doesn't help that Ton apparently mistakenly swapped the terms, in the comment above).

Now, this should be made clear somewhere, and we should spend some energy educating about this issue (since the other option - making it work well in means pleading with Apple, not Blender foundation.)

Except, as Campbell noted when he closed the other bug - Blender 2.5 has a built-in console planned. Much nicer, and the same for all platforms. So any solution we get now, will be moot in 2.5.

Hope this helps.

This task was automatically closed as archived as part of migration, because the project or tracker this task belonged to is no longer active.