[PD] [PD-announce] Pd-0.40.3-extended-rc2 released

[Hans-Christoph Steiner]

On Jul 21, 2008, at 6:28 PM, Luke Iannini wrote:

> On Tue, Jul 8, 2008 at 9:43 PM, Luke Iannini <lukexipd at gmail.com>  
> wrote:
>> On Fri, Jul 4, 2008 at 1:37 AM, IOhannes m zmoelnig  
>> <zmoelnig at 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].
>>
> Could anyone comment on this?  I'd be interested to know whether this
> is actually good practice (minimizing one's path entries), and I'd
> also be interested in the feasibility of the caching idea (and equally
> interested in why (if) it's a bad idea)

Caching would speed up load times, but would also add complexity and  
would mean that you would have to restart or clear the cache if you  
changed  I think a better bet would be to reduce the search path.

The grand plan is to have no libraries loaded by default.  Then the  
library configuration would be completely embedded in the patch, like  
python does with import.

.hc

>
> Cheers
> 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 at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>>> listinfo/pd-list
>>>
>>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



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

If you are not part of the solution, you are part of the problem.