On Sep 18, 2007, at 11:04 AM, 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).
It's all a matter of perspective. I use [comport] all the time and
really want a [io/serial] that is based on comport, but has a clean,
standardized interface in common with all IO objects (i.e. same basic
messages, inlets, outlets, etc.). I have never used [drip], so it
doesn't matter to me whether that was included now or in 10 years.
Whether iem/comport is maintained is also a non-issue. If someone
wants to do the work to maintain both, why stop them?
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television