On Fri, Jul 4, 2008 at 1:37 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Luke Iannini wrote:
So, sorry to pick on the hexloader some more : ) but it seems it is the culprit. Can anyone confirm?
it makes sense.
could you send me the complete output of the pd-console when loading your patch with "-verbose". (might get big; so zip it and send it to me privately; or put it somewhere online...)
Hi IOhannes, Sorry for the wait, I had a busy week. Here's the output... I put it online in case anyone else is interested. (I cleared the initial output messages, so it starts immediately after I click off the [sft.coral] object) Big indeed; 616 megs, be ready for that (luckily it's ideal for compression: 20.4megs zipped).* And this is only one module... if I had tried the patch where I load 16 of them I would have run out of HD space (not to mention RAM); glad I didn't : ). http://www.proyekto.net/sndrft/GiantLoad.txt.zip
It occurred to me that it might make sense to cache the last known location of an object and try that location first? Or is that a hack... I don't know. But it seems it would help all loaders to do so.
Also, I'm guessing stripping down my Pd-prefs to include a minimum of directories would greatly help, yea? Or, put another way, it's a good argument to accelerate use of [import].
Best Luke
i am not sure how to handle the problem generally yet. ideas are:
- remove the recursive library search in hexloader (no more hexloading
for non-C externals; who is using that anyhow? libdir doesn't seem to like hexloader so much anyhow)
- remove the the HEXLOADER_PATCHES functionality (it seems to be not
working anyhow)
- remove the entire hexloader quirks and just claim that you cannot
write objects with filenames containing special characters.
after all the endless struggles with hexloader, i start tending towards the last one...
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list