[PD] help files was: Re: call for testing on the nightly builds!

Hans-Christoph Steiner hans at eds.org
Mon May 19 20:13:16 CEST 2008


On May 19, 2008, at 6:55 PM, Martin Peach wrote:

> Hans-Christoph Steiner wrote:
>> On May 18, 2008, at 12:09 PM, Roman Haefeli wrote:
>>> On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
>>>> Roman Haefeli wrote:
>>>>> On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
>>>>>> Hans-Christoph Steiner wrote:
>>>>>>>> i'm not a developer but i would vote for declare
>>>>>>>> i.e. [declare -stdlib mrpeach] to packOSC-help.pd
>>>>>>>> then it would work with pd vanilla too.
>>>>>>> The declare/namespace/import stuff is still very undefined, so I
>>>>>>> think some experiementation would be good.  I think you  
>>>>>>> should go
>>>>>>> ahead and try it using what you propose.  That will be a good  
>>>>>>> test
>>>>>>> case.  Then we'll figure out what works best.
>>>>>> putting the helppatches besides the objects should fix most of  
>>>>>> the
>>>>>> problems, no?
>>>>>> no need for [declare] orgies and such
>>>>> yo.. it would seem strange having to put [declare]s into help-  
>>>>> patches in
>>>>> order to load the the objects, that they are explaining, IMO.
>>>> maybe i miss something:
>>>>
>>>> to it seems _not_ strange to have a working help patch. the   
>>>> declare is
>>>> documenting how one can use the object-class of the external  
>>>> (one  of the
>>>> 4, 5... 6 ways).
>>> there are only so many in pd-extended, there aren't that many in
>>> pd-vanilla ( i can think of [declare] and pd-settings file only).
>>>
>>>> or do you think a user should configure the plist/pdrc/registry  
>>>> first
>>>> and restart Pd before he can use the documentation/helpfile?
>>> i think, as IOhannes said, that it would make sense to put classes
>>> (libraries, abstractions, single-object files) and their help- 
>>> files at
>>> the same place. i don't see a benefit in having to tell a help-file
>>> where to find the class.
>> Yeah, that's the idea of libdirs.  It just needs to be  
>> implemented  fully.  It's pretty close.
>
>
> I have all my help files in the same place as the source code in  
> the svn repository but they end up separated in pd-extended (the  
> binaries go to extra/mrpeach and the help files are in doc/ 
> 5.reference/mrpeach). As has already been remarked, I can  
> instantiate for example [mrpeach/tcpclient] but not [tcpclient] but  
> in either case the help file isn't found and if I open it manually  
> it won't make [tcpclient] either. So I'm just wondering what I can  
> do about that...
> If I put [mrpeach/tcpclient] in the help file it will work but it  
> doesn't do anything to make the help file findable. Is there some  
> make file I need to edit or does the libdir thing fix this?

What would fix this well is a completed libdir format.  If the help  
files are included in the same folder as the objectclasses, then the  
help files will be found either way, AFAIK.  But since 0.41-4 is out,  
and Pd-extended 0.40 has a lot of changes that are pretty well  
tested, I think it makes sense to release 0.40, then work on the  
whole libdir/import/declare issue in 0.41 (though I really hoped to  
do it for 0.40).

I am fine with leaving this how it is for this release, then fixing  
it properly for the next release.

.hc

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

                   ¡El pueblo unido jamás será vencido!






More information about the Pd-list mailing list