johnpitcairn

OK, I've reinstalled 4.6b11, and when building a standalone, the runtime executable bit still isn't being set. After fixing that, the support folder isn't being found when the standalone is run. Details:

PPC (G4), Mac OS X 10.4.3, CFM support not installed

All patches and builds are on a separate partition, not the boot partition. MaxMSP is installed in /Applications on the boot partition.

No 3rd-party MaxMSP objects or extensions installed.

"Ignore permissions" is not set on the build partition.

The resulting "support folder.app" will not run:

-rwxr-xr-x 1 john john 11181736 Jun 24 04:59 support folder

• error: folder: ./support: not a folder

Change the original patch (add a comment). Build it again, answering "yes" to the "replace" dialog to overwrite the original standalone.

The build script produces no errors, but the .mxf and the support folder are placed in the same folder as the original Max patch, not in the application bundle.

Run "support folder.app" and the same error is produced, but the app does not include the added comment.

All patches and builds are on a separate partition, not the boot  partition. MaxMSP is installed in /Applications on the boot partition.

Result:
Starting Build for support folder.app...
Processing script...
Copying External folder
Copying External standalone
Investigating MidiSetup Input.pat...
Saving Patcher MidiSetup Input.pat...
Copying External umenu
Investigating MidiSetup Output.pat...
Saving Patcher MidiSetup Output.pat...
Copying External umenu
Investigating MidiSetup Buttons.pat...
Saving Patcher MidiSetup Buttons.pat...
Copying External panel
Copying External ubutton
Finished script.

ls -l
total 21840
-rwxr-xr-x   1 john  john  11181736 Jun 24 04:59 support folder
chmod +x ./support folder

ub-standalone-executable-bit-not-set-support-folder-not-found

My guess is that this is going to end up being something related to 

the your having the patches etc.. on the separate partition.

Have you tried with that stuff located on the boot partition?

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

My guess is that this is going to end up being something related to 
the your having the patches etc.. on the separate partition.

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


Quote: Dan Nigrin wrote on Tue, 27 June 2006 23:37

----------------------------------------------------

> My guess is that this is going to end up being something 

> related to the your having the patches etc.. on the separate 

> partition. Have you tried with that stuff located on the boot 

A - Example patch on non-boot partition, build to boot partition:

Runs, but takes quite a while (15+ seconds, beachball) to start.

B - Original patch on boot partition, build to boot partition:

Quote: Dan Nigrin wrote on Tue, 27 June 2006 23:37
----------------------------------------------------
> My guess is that this is going to end up being something 
> related to the your having the patches etc.. on the separate 
> partition. Have you tried with that stuff located on the boot 
> partition?

A - Example patch on non-boot partition, build to boot partition:
Builds successfully.
Is executable.
Runs, but takes quite a while (15+ seconds, beachball) to start.
Can't find ./support folder.

Build-replace replaces correctly.
Runs as above.

B - Original patch on boot partition, build to boot partition:
Same as above.

Am 28.06.2006 um 04:48 schrieb John Pitcairn:

> Runs, but takes quite a while (15+ seconds, beachball) to start.

The default path now points to where the app bundle is, not to the 

collective inside of it. So ./yourapp.app/Contents/support

However: The searchpath also changed back to OS9 behaviour, meaning 

that the folder in which the app resides is added to the searchpath on 

startup. Great thing if you want to provide a folder with a few 

soundfiles and you want to load them easily with their names, not so 

great if you want to make a well behaving self-contained OS X app. I 

built my first app to the desktop, and had to force-quit after minutes 

of beachball. The application folder also isn't a good place for a 

standalone built with the beta, as it will recursivly search the 

application folder (and all apps in there are folders with subfolders 

It would be cool if the standalone object could get an option to limit 

the searchpath to the bundle itself, apparently unchecking "Search for 

Files Not in the Application's Collective" doesn't do it (plus it would 

be nice to be able to provide extra files outside the collective but 

Am 28.06.2006 um 04:48 schrieb John Pitcairn:
> Runs, but takes quite a while (15+ seconds, beachball) to start.
> Can't find ./support folder.

The default path now points to where the app bundle is, not to the 
collective inside of it. So ./yourapp.app/Contents/support
should work.

However: The searchpath also changed back to OS9 behaviour, meaning 
that the folder in which the app resides is added to the searchpath on 
startup. Great thing if you want to provide a folder with a few 
soundfiles and you want to load them easily with their names, not so 
great if you want to make a well behaving self-contained OS X app. I 
built my first app to the desktop, and had to force-quit after minutes 
of beachball. The application folder also isn't a good place for a 
standalone built with the beta, as it will recursivly search the 
application folder (and all apps in there are folders with subfolders 
to Max!).

It would be cool if the standalone object could get an option to limit 
the searchpath to the bundle itself, apparently unchecking "Search for 
Files Not in the Application's Collective" doesn't do it (plus it would 
be nice to be able to provide extra files outside the collective but 
inside the bundle).

Quote: grg wrote on Thu, 29 June 2006 00:03

> The default path now points to where the app bundle is, not to 

> the collective inside of it. So ./yourapp.app/Contents/support

And indeed it does, thanks. I stupidly hadn't considered the new default path.

It still won't build as executable to a non-boot partition however, and build-replace to a non-boot partition puts the .mxf and support folder in the same folder as the original patch.

> However: The searchpath also changed back to OS9 behaviour, 

> meaning that the folder in which the app resides is added to 

> the searchpath on startup. Great thing if you want to provide 

> a folder with a few soundfiles and you want to load them 

> easily with their names, not so great if you want to make a 

Indeed. It's traversing any aliases in the folder too. I'd vote for this behaviour to be reverted - Mac users expect to be able to put an app in the /Applications folder (and I tell them to do so), or indeed anywhere, and not have that affect how long it takes to start up.

Quote: grg wrote on Thu, 29 June 2006 00:03
----------------------------------------------------
> The default path now points to where the app bundle is, not to 
> the collective inside of it. So ./yourapp.app/Contents/support
> should work.

> However: The searchpath also changed back to OS9 behaviour, 
> meaning that the folder in which the app resides is added to 
> the searchpath on startup. Great thing if you want to provide 
> a folder with a few soundfiles and you want to load them 
> easily with their names, not so great if you want to make a 
> well behaving self-contained OS X app.

Indeed. It's traversing any aliases in the folder too. I'd vote for this behaviour to be reverted - Mac users expect to be able to put an app in the /Applications folder (and I tell them to do so), or indeed anywhere, and not have that affect how long it takes to start up.


OK, I have a UB that functions perfectly on PPC. My next problem is mxj syscommand (as shell replacement) not working on Intel. See you in the Java forum...

UB standalone: executable bit not set, support folder not found