Welcome to the MacNN Forums.

castagnini · Dec 19, 2009, 01:30 PM

Hi guys,

I hope to post this in the right section (if not sorry... this is my first post)

I developed a small (and free) utility to show disk usage with the ringchart effect (as in GNOME's baobab).
You can see better what it is about in a screenshot:

The problem is that I develop under snow leopard and I do not know if it runs well also under leopard. In particular I am interested in knowing if it works also on the PPC platform (I enabled it during the compiling, but I do not know how to test it)

You can download it here:
http://www.prototypeproject.org/diskring/download.php

If you could give me some feedback it would be very helpful.
Luca

reader50 · Dec 19, 2009, 03:03 PM

Fails to run under PPC Tiger (You cannot use the application "diskring.app" with this version of Mac OS X.)

I can check under PPC Leopard later today.

castagnini · Dec 19, 2009, 07:46 PM

thank you,

yes, it is supposed not to work under tiger, even for intel machines. I do not know under ppc leopard. I tryed to open the program with rosetta, the treeview seems to work bur the ringchart is not working, and I do not know if it is a problem of the program or of rosetta.

thanks again.
Luca

reader50 · Dec 19, 2009, 07:55 PM

This is on a Quad G5
14 GB ECC RAM
GeForce 7800 GT
dual 1920x1200 monitors

It doesn't run in PPC Tiger even after I edit the plist to allow 10.4 execution. Kern protection failure, yada yada.

Under a clean 10.5 install - nothing unusual installed other than the Dev tools:

I launched it from the disk image, pointed it to an unused Users folder on another partition. That partition is 64 GB, HFS+ (journaled). The Users folder is 5.7 MB.

Diskring was very unresponsive once I began the scan. It took several minutes to stabilize, using 100% out of 400% available CPU for 7-8 threads while scanning. It was flagged as an unresponsive app during this time. It presently settled down, with the above info printed, but the sizes are way wrong. It initially drew all 5 tracks, but they were substantially the same as the above picture - all red. Mousing around the controls or the menu choices would provoke another 100% bout lasting another minute. I took the pic, then force-quit before it could settle down again. It presumably would have redrawn all 5 tracks if I'd given it more time.

Under the theory that it was having trouble running from a disk image, I copied it to ~~the Desktop~~ the Applications folder in case the app was hardcoded to that location. Relaunched. Checking the menu choices are prefectly responsive before a scan is started. Launching the scan produces another 2-3 minutes of 100% CPU and no response until it draws this:

Same unused Users folder, still 5.7 MB actual size. Next, I considered that diskring may be confused by partitions. So I pointed it to a single-partition drive, using the Classic folder on it. That drive is 1.36 TB, HFS+, not journaled.

The folder tree shown is correct again, but off as to the sizes. Actual size for the Mac OS 9 folder is 667.2 MB.

All sizes reported by me are actual MB / GB sizes, where 1 MB = 2^20 bytes, and 1 GB = 2^30 bytes. Not the fakeo decimal versions pushed by HD manufacturers.

castagnini · Dec 19, 2009, 08:06 PM

mmm... ok, thank you. It definitely doesn't work for ppc. I will try to work more on it, even if at the moment I do not really know what to do... but I take some time to think about it.

thanks again for your help.
Luca

reader50 · Dec 19, 2009, 08:20 PM

Endian issues are a perennial favorite between PPC and x86. Just a thought, which might explain why the sizes are wrong.

It showed 7-8 (usually 7) threads. Since it only maxed one CPU, only one of the threads was doing it. By "mousing around the GUI" I meant mousing + clicking. Mousing alone did not provoke extra CPU usage. But since clicking on the GUI produced unresponsiveness, it was either the GUI thread that was hitting 100%, or it was a thread the GUI waits on.

castagnini · Dec 19, 2009, 08:36 PM

ok... I will check endianess. it could be also that st_blocks from stat structure doesn't use 512-byte units...

I use threads only when I do the scanning, to update the number of current scanned files/folders. But it is possible that the compiler auto-threads the program (I will check better the compiler options)

It is completely strange that everything is red... the color is a number between 0 and 1, which is a result of a division between integers... it is strange because I made the casting (otherwise you shouldn't see the blue sector...)

I am very tired now (it's 3 a.m. here), I will think about it tomorrow.
thanks again,
Luca