[PD] inconsistencies with lib names (was: representning classes

[martin.peach at sympatico.ca]

Frank Barknecht wrote:
> Hallo,
> Georg Holzmann hat gesagt: // Georg Holzmann wrote:
> 
> > As far as I undestood it the code of e.g. comport would go in this 
> > standard lib (e.g. to hardware/comport) but should not duplicate the 
> > code - instead the iem/comport code should be obsolete and now 
> > maintained in hardware/comport.
> 
> Yes, that would be the idea for binaries in the std-lib.
> 
> > But as the others convinced me at the pd conv I don't think that this 
> > will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
> 
> Depends on how you define "this": I don't think that every external
> has to move over to stdlib immediately, if at all. comport would be a
> good example for an external that could stay outside the stdlib for
> the next 8-10 years without any bigger problems, as it is an object
> with a rather specific purpose. [drip] OTOH would be a candidate to
> take immediately. The old build-system by Guenther ("flatspace" in
> pd-extended) already showed the how the whole stdlib could be built as
> far as externals are concerned, and abstractions are dead easy to
> handle (as long as they are core-Pd-abstractions).

I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend].
It looks like the function do_open_via_path in s_path.c is the one to fix...

Martin


Martin