[PD-dev] automated library updates WAS: pd-extended 0.43 release push
Jonathan Wilkes
jancsika at yahoo.com
Thu Sep 15 18:48:13 CEST 2011
>________________________________
>From: Joe White <white.joe4 at gmail.com>
>To: Jonathan Wilkes <jancsika at yahoo.com>
>Cc: Hans-Christoph Steiner <hans at at.or.at>; "pd-dev at iem.at" <pd-dev at iem.at>
>Sent: Thursday, September 15, 2011 8:32 AM
>Subject: Re: [PD-dev] automated library updates WAS: pd-extended 0.43 release push
>
>
>Hi Jonathan,
>
>
>Thanks for the info!
>
>
>Although this seems to be mainly for internal information within the library i.e. object information. (not that this isn't important!).
>
>
>I was wondering whether there is a method for describing a library as a whole, such as library name, description, version, etc.. Maybe this could be a textfile included within the folder, it would be useful for Pd programs to be able to easily parse information regarding each library.
Right, that's in the *-meta.pd patch in the library's directory.
>
>
>Does it make sense to duplicate information such as website in every help file? Would a centralised info textfile be more appropriate for this?
Actually "WEBSITE" isn't used very often. But the others-- even AUTHOR-- can be different per class. Even
LICENSE could potentially be different.
>
>
>Is there any documentation available or just implemented in a few libraries and not in others?
I think all or most of the libraries have a *-meta.pd patch in them.
-Jonathan
>
>
>Cheers,
>Joe
>
>
>On 14 September 2011 18:11, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>I haven't done any work with the *-meta.pd files-- mostly because half of the extant
>>
>>libraries would have the recursive description "A collection of seemingly random objects
>>
>>created by Author x because Author x needed this collection of objects". Btw-- whoever
>>
>>created them must have tried to do an automated search/replace that went haywire,
>>
>>because several of them have comments sitting on top of each other, which makes them
>>
>>unreadable.
>>
>>What I've done is add a [pd META] subpatch to each help patch with comments in the
>>
>>"TAG value1 value2 etc." format. I use the following tags:
>>ALIAS alias for the object. For trigger, this would be t
>>KEYWORDS possible values are listed and defined in all_about_help_patches.pd
>>DESCRIPTION
>>LICENSE GPL v2 v3 SIBSD (I think there's a tcl/tk license somewhere in there, too)
>>INLET_0 possible values are: symbol float list bang pointer anything. Also custom
>>
>>selectors like: set clear etc.
>>INLET_1
>>INLET_2
>>etc.
>>OUTLET_0
>>OUTLET_1
>>etc.
>>INLET_N this is for an object that can have a variable number of inlets (usually based on
>>
>>a creation argument. Ex: [pack])
>>INLET_R refers the the rightmost inlet, for an object like [append] which always takes a
>>
>>pointer in its last inlet.
>>OUTLET_N
>>OUTLET_R
>>AUTHOR author(s) + author's email, or anything else you want to include here
>>
>>WEBSITE author's website link
>>
>>HELP_PATCH_AUTHORS
>>GENRE omitted for help patches, but you can use it to mark a patch as one of the following:
>>
>>tutorial all_about_pd. Could probably add "example" as well...
>>
>>I'm already using these for some searches with my search-plugin.
>>
>>-Jonathan
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>> To: Joe White <white.joe4 at gmail.com>
>>> Cc: pd-dev at iem.at
>>> Sent: Wednesday, September 14, 2011 10:44 AM
>>> Subject: [PD-dev] automated library updates WAS: pd-extended 0.43 release push
>>>
>>>
>>> I think that at this point, Jonathan Wilkes is the expert on the meta
>>> data. If you wanted to take on trying to do automatic updates using the
>>> existing library format [1], that would be awesome. That should be
>>> possible on any platform. The new downloads section should make it a
>>> lot easier to automatically find and download updates:
>>> http://puredata.info/downloads
>>>
>>> .hc
>>>
>>> [1] http://puredata.info/docs/developer/LibraryTemplate
>>>
>>> On Wed, 2011-09-14 at 14:22 +0100, Joe White wrote:
>>>> Sounds promising Hans,
>>>>
>>>>
>>>> Is there any more info about this meta structure you were referring
>>>> to. How far has this progressed? What are the implications for
>>>> existing libraries and for programs trying to interface with it?
>>>>
>>>>
>>>> I'm on OSX and have no knowledge of Debian so I'm not sure how
>>> helpful
>>>> I could be. If there is anything I could do let me know. I'm
>>>> interested in seeing how this would work from a user perspective, e.g.
>>>> being able to seeing available libraries, downloading and updating
>>>> them. I'm looking into adding git support in the app I'm writing.
>>>>
>>>> Cheers,
>>>> Joe
>>>>
>>>> On 13 September 2011 19:43, Hans-Christoph Steiner <hans at at.or.at>
>>>> wrote:
>>>>
>>>> Hey Joe,
>>>>
>>>> This is a great idea that has been talked about in the past
>>>> every now
>>>> and then. The big missing piece has always been someone who
>>>> wants to do
>>>> the work to implement it. Personally, I've been moving my own
>>>> Pd
>>>> packaging work to be based out of Debian. And I've been
>>>> trying to make
>>>> a similar process for Pd-extended (see GettingIntoPdextended
>>>> from the
>>>> original email) You can see the libraries I maintain because
>>>> they are
>>>> (almost) all in Debian:
>>>>
>>>> http://qa.debian.org/developer.php?login=hans@eds.org
>>>>
>>>> We know have a lot of the pieces in place to make this task a
>>>> lot
>>>> easier. For example, the libraries all have *-meta.pd files
>>>> which
>>>> contain meta information about the library. Jonathan Wilkes
>>>> has been
>>>> doing some great work around the meta data, but the more
>>>> people working
>>>> on this stuff, the more that gets done :)
>>>>
>>>> .hc
>>>>
>>>>
>>>> On Tue, 2011-09-13 at 17:36 +0100, Joe White wrote:
>>>> > Hey,
>>>> >
>>>> >
>>>> > Forgive me if this is not totally on topic but I had an idea
>>>> a while
>>>> > ago a wondered what the feasibility of it was.
>>>> >
>>>> >
>>>> > I don't really have a great knowledge of the Pd extended
>>>> package but
>>>> > how possible would it be to have each library versioned (say
>>>> on
>>>> > github) as individual repositories that then get pulled in
>>>> the build.
>>>> > Maybe you could see when certain libraries have been changed
>>>> and
>>>> > update them on your own machine. Along the idea of how
>>>> macports
>>>> > works.
>>>> >
>>>> > Again, apologies if this is a really stupid question.
>>>> >
>>>> >
>>>> > Cheers,
>>>> > Joe
>>>> >
>>>> > On 13 September 2011 17:06, Hans-Christoph Steiner
>>>> <hans at at.or.at>
>>>> > wrote:
>>>> >
>>>> > I was thinking that now would be a good time to
>>>> start a
>>>> > release cycle
>>>> > for Pd-extended 0.43. There is a ton of really
>>>> useful new
>>>> > stuff in the
>>>> > editor with the new gui, plugins, etc. So I'm
>>>> thinking I'll
>>>> > delay some
>>>> > of the library work I've been doing, and revert to
>>>> the 0.42.5
>>>> > behavior
>>>> > of loading a bunch of libraries by default at
>>>> startup. But I
>>>> > personally
>>>> > be dropping my support for a number of included
>>>> libraries, but
>>>> > anyone is
>>>> > welcome to pick them up if they want to see them
>>>> stay in
>>>> > Pd-extended.
>>>> > You can see the state of things here:
>>>> >
>>>> > http://puredata.info/docs/LibrariesInPdExtended
>>>> >
>>>> > This can be a trial run of the new process of
>>>> keeping things
>>>> > in
>>>> > Pd-extended. Basically, I need to reduce my
>>>> maintenance load,
>>>> > I just
>>>> > can't keep up any more. So I am proposing that
>>> the
>>>> new
>>>> > process for
>>>> > getting things into a Pd-extended release. First,
>>>> the new
>>>> > release
>>>> > branch will be a copy of the previous release
>>>> branch. Each
>>>> > library/doc
>>>> > has a maintainer, listed on the
>>>> LibrariesInPdExtended page.
>>>> > It is that
>>>> > maintainer's job to update their libraries/docs
>>> into
>>>> the
>>>> > pd-extended
>>>> > release branch, otherwise the version will be the
>>>> same as the
>>>> > previous
>>>> > version. Each version of a library included in
>>>> Pd-extended
>>>> > needs to a
>>>> > fully released version with a proper version number
>>>> and a
>>>> > release posted
>>>> > on its own page in the
>>>> http://puredata.info/downloads section,
>>>> > and
>>>> > ultimately uploaded to Debian/testing (I'm happy
>>> to
>>>> sponsor
>>>> > people's
>>>> > packages for upload to Debian once they are ready).
>>>> The full
>>>> > process is
>>>> > documented here:
>>>> >
>>>> >
>>>> http://puredata.info/docs/developer/GettingIntoPdextended
>>>> >
>>>> > Comments, feedback, concerns? I'd like to make
>>> this
>>>> a much
>>>> > more open
>>>> > and participatory process.
>>>> >
>>>> > .hc
>>>> >
>>>> > _______________________________________________
>>>> > Pd-dev mailing list
>>>> > Pd-dev at iem.at
>>>> > http://lists.puredata.info/listinfo/pd-dev
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>
>
>
>
More information about the Pd-dev
mailing list