Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose.
Here's the files in puredata-doc: http://packages.debian.org/sid/all/puredata-doc/filelist
.hc
--- On Mon, 6/27/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose.
The PDDP docs I did are all for vanilla objects (exceptions are expr family, and the other "vanilla" extras). If a new user clicks "Help" on a vanilla object, it should show the revised PDDP help patch by default.
So instead of what you propose, please make something like a legacy-vanilla-help package. That way, if someone really prefers the old docs, they can still find them, and we won't waste new users' time by forcing them to use outdated and unmaintained docs (until they figure out they're supposed to download a separate package for the current vanilla help patches, which nobody has to do for any of the external packages).
-Jonathan
Here's the files in puredata-doc: http://packages.debian.org/sid/all/puredata-doc/filelist
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote:
--- On Mon, 6/27/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose.
The PDDP docs I did are all for vanilla objects (exceptions are expr family, and the other "vanilla" extras). If a new user clicks "Help" on a vanilla object, it should show the revised PDDP help patch by default.
So instead of what you propose, please make something like a legacy-vanilla-help package. That way, if someone really prefers the old docs, they can still find them, and we won't waste new users' time by forcing them to use outdated and unmaintained docs (until they figure out they're supposed to download a separate package for the current vanilla help patches, which nobody has to do for any of the external packages).
-Jonathan
I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default. I think that making the PDDP docs as their own package and distro will make it easier for you to get your work out to users.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote:
--- On Mon, 6/27/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e. /usr/lib/pd/doc/*)
are
split out into a separate Debian package, I think it could make
sense to
package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was
thinking
that since you have wanted to work on all the patches there, we could
set it up
so the pddp-doc package mirrors the whole
/usr/lib/pd/doc*
directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so
choose.
The PDDP docs I did are all for vanilla objects
(exceptions are
expr family, and the other "vanilla" extras). If
a new user clicks
"Help" on a vanilla object, it should show the revised
PDDP help
patch by default.
So instead of what you propose, please make something
like a
legacy-vanilla-help package. That way, if
someone really prefers
the old docs, they can still find them, and we won't
waste new users' time
by forcing them to use outdated and unmaintained docs
(until they figure
out they're supposed to download a separate package
for the current
vanilla help patches, which nobody has to do for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default.
Ok.
I think that making the PDDP docs as their own package and distro will make it easier for you to get your work out to users.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote:
--- On Mon, 6/27/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e. /usr/lib/pd/doc/*)
are
split out into a separate Debian package, I think it could make
sense to
package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was
thinking
that since you have wanted to work on all the patches there, we could
set it up
so the pddp-doc package mirrors the whole
/usr/lib/pd/doc*
directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so
choose.
The PDDP docs I did are all for vanilla objects
(exceptions are
expr family, and the other "vanilla" extras). If
a new user clicks
"Help" on a vanilla object, it should show the revised
PDDP help
patch by default.
So instead of what you propose, please make something
like a
legacy-vanilla-help package. That way, if
someone really prefers
the old docs, they can still find them, and we won't
waste new users' time
by forcing them to use outdated and unmaintained docs
(until they figure
out they're supposed to download a separate package
for the current
vanilla help patches, which nobody has to do for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default.
Ok.
So we just need a plan of attack. If you can lead up this project, I will help as much as I can. Do you want to include the whole docs tree in the doc/pddp SVN? Or something else? It seems to me the easiest would be to start a separate repository for them, like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp
Or we could reorganize doc/pddp in the pure-data SVN.
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes
wrote:
--- On Mon, 6/27/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e.
/usr/lib/pd/doc/*)
are
split out into a separate Debian package, I think it could
make
sense to
package the PDDP docs in a kind of mirror or replacement
package.
Something like pddp-doc. Jonathan, in particular, I
was
thinking
that since you have wanted to work on all the patches there,
we could
set it up
so the pddp-doc package mirrors the whole
/usr/lib/pd/doc*
directory and patch structure, have this in SVN, git, or
whatever
somewhere. Then people could choose the pddp-doc package if they
so
choose.
The PDDP docs I did are all for vanilla
objects
(exceptions are
expr family, and the other "vanilla"
extras). If
a new user clicks
"Help" on a vanilla object, it should show the
revised
PDDP help
patch by default.
So instead of what you propose, please make
something
like a
legacy-vanilla-help package. That way,
if
someone really prefers
the old docs, they can still find them, and we
won't
waste new users' time
by forcing them to use outdated and
unmaintained docs
(until they figure
out they're supposed to download a separate
package
for the current
vanilla help patches, which nobody has to do
for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much better, that's
why I
want to get them out there more. Part of
packaging is
representing the upstream as it is and letting the
user
decide. So I think it makes sense to keep
puredata-doc
as what's included in the official tarball.
As for
Pd-extended, I think it should still use the PDDP
docs, so
like you say, showing the PDDP docs by default.
Ok.
So we just need a plan of attack. If you can lead up this project, I will help as much as I can. Do you want to include the whole docs tree in the doc/pddp SVN? Or something else? It seems to me the easiest would be to start a separate repository for them, like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp
Or we could reorganize doc/pddp in the pure-data SVN.
.hc
Since Pd-extended and Pd-l2ork already use the PDDP docs, the only thing we're talking about here is providing PDDP docs for people who use vanilla, and that's a simple commit. So I don't see why I have to head up some new project and learn Debian packaging in order to meander toward (or around) that goal.
The only problem is with pddplink and helplink dependencies, which should just be included in vanilla as internal objects. Is there a good reason why they aren't?
Maybe my time would be better spent making a "gui" plugin that just grabs all the stuff that should be core pd but isn't and installs it: revised/maintained docs, [initbang], [closebang], [pddplink], [helplink], $@, etc.
-Jonathan
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes
wrote:
--- On Mon, 6/27/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM
Now that the core Pd docs (i.e.
/usr/lib/pd/doc/*)
are
split out into a separate Debian package, I think it could
make
sense to
package the PDDP docs in a kind of mirror or replacement
package.
Something like pddp-doc. Jonathan, in particular, I
was
thinking
that since you have wanted to work on all the patches there,
we could
set it up
so the pddp-doc package mirrors the whole
/usr/lib/pd/doc*
directory and patch structure, have this in SVN, git, or
whatever
somewhere. Then people could choose the pddp-doc package if they
so
choose.
The PDDP docs I did are all for vanilla
objects
(exceptions are
expr family, and the other "vanilla"
extras). If
a new user clicks
"Help" on a vanilla object, it should show the
revised
PDDP help
patch by default.
So instead of what you propose, please make
something
like a
legacy-vanilla-help package. That way,
if
someone really prefers
the old docs, they can still find them, and we
won't
waste new users' time
by forcing them to use outdated and
unmaintained docs
(until they figure
out they're supposed to download a separate
package
for the current
vanilla help patches, which nobody has to do
for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much better, that's
why I
want to get them out there more. Part of
packaging is
representing the upstream as it is and letting the
user
decide. So I think it makes sense to keep
puredata-doc
as what's included in the official tarball.
As for
Pd-extended, I think it should still use the PDDP
docs, so
like you say, showing the PDDP docs by default.
Ok.
So we just need a plan of attack. If you can lead up this project, I will help as much as I can. Do you want to include the whole docs tree in the doc/pddp SVN? Or something else? It seems to me the easiest would be to start a separate repository for them, like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp
Or we could reorganize doc/pddp in the pure-data SVN.
.hc
Since Pd-extended and Pd-l2ork already use the PDDP docs, the only thing we're talking about here is providing PDDP docs for people who use vanilla, and that's a simple commit. So I don't see why I have to head up some new project and learn Debian packaging in order to meander toward (or around) that goal.
Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well.
I'm happy to do all of the Debian packaging, that part would be easy for me.
The only problem is with pddplink and helplink dependencies, which should just be included in vanilla as internal objects. Is there a good reason why they aren't?
That's something you'd have to take up with Miller, only he makes the call there. Honestly, I think we're better off keeping things as distinct libraries. Miller has limited time to spend on Pd, so the more stuff that's in Pd, the thinner his time is spread. pd-pddp is in Debian/Ubuntu/Mint etc. For someone who knows Fedora/RPM packaging, it would be really easy to package it. Then PDDP is included in Pd-extended already. So that means for the vast majority of users, pddplink and helplink are already part of the standard install.
Maybe my time would be better spent making a "gui" plugin that just grabs all the stuff that should be core pd but isn't and installs it: revised/maintained docs, [initbang], [closebang], [pddplink], [helplink], $@, etc.
That's done, that's called Pd-extended ;)
.hc
-Jonathan
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:33 PM
On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp
docs
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan
Wilkes
wrote:
--- On Mon, 6/27/11, Hans-Christoph
Steiner
wrote:
> From: Hans-Christoph Steiner
> Subject: [PD-dev] packaging the
pddp docs
> To: pd-dev@iem.at > Date: Monday, June 27, 2011, 9:21
PM
> > Now that the core Pd docs (i.e.
/usr/lib/pd/doc/*)
are
> split out into a > separate Debian package, I think
it could
make
sense to
> package the PDDP > docs in a kind of mirror or
replacement
package.
> Something like > pddp-doc. Jonathan, in
particular, I
was
thinking
> that since you have > wanted to work on all the patches
there,
we could
set it up
> so the > pddp-doc package mirrors the
whole
/usr/lib/pd/doc*
> directory and patch > structure, have this in SVN, git,
or
whatever
> somewhere. Then people > could choose the pddp-doc package
if they
so
choose.
The PDDP docs I did are all for
vanilla
objects
(exceptions are
expr family, and the other "vanilla"
extras). If
a new user clicks
"Help" on a vanilla object, it should
show the
revised
PDDP help
patch by default.
So instead of what you propose, please
make
something
like a
legacy-vanilla-help package.
That way,
if
someone really prefers
the old docs, they can still find
them, and we
won't
waste new users' time
by forcing them to use outdated and
unmaintained docs
(until they figure
out they're supposed to download a
separate
package
for the current
vanilla help patches, which nobody has
to do
for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much
better, that's
why I
want to get them out there more.
Part of
packaging is
representing the upstream as it is and
letting the
user
decide. So I think it makes sense to
keep
puredata-doc
as what's included in the official
tarball.
As for
Pd-extended, I think it should still use
the PDDP
docs, so
like you say, showing the PDDP docs by
default.
Ok.
So we just need a plan of attack. If you can
lead up
this project, I will help as much as I can. Do you want to
include
the whole docs tree in the doc/pddp SVN?
I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla.
Or something else? It
seems to me the easiest would be to start a separate repository
for them,
like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp
Or we could reorganize doc/pddp in the pure-data
SVN.
.hc
Since Pd-extended and Pd-l2ork already use the PDDP
docs, the only thing
we're talking about here is providing PDDP docs for
people who use
vanilla, and that's a simple commit. So I don't
see why I have to head up
some new project and learn Debian packaging in order
to meander toward (or
around) that goal.
Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well.
I'm happy to do all of the Debian packaging, that part would be easy for me.
So what is it you want me to do?
The only problem is with pddplink and helplink
dependencies, which should
just be included in vanilla as internal objects.
Is there a good reason
why they aren't?
That's something you'd have to take up with Miller, only he makes the call there. Honestly, I think we're better off keeping things as distinct libraries. Miller has limited time to spend on Pd, so the more stuff that's in Pd, the thinner his time is spread. pd-pddp is in Debian/Ubuntu/Mint etc. For someone who knows Fedora/RPM packaging, it would be really easy to package it. Then PDDP is included in Pd-extended already. So that means for the vast majority of users, pddplink and helplink are already part of the standard install.
Maybe my time would be better spent making a "gui"
plugin that just grabs
all the stuff that should be core pd but isn't and
installs it:
revised/maintained docs, [initbang], [closebang],
[pddplink], [helplink],
$@, etc.
That's done, that's called Pd-extended ;)
.hc
-Jonathan
Using ReBirth is like trying to play an 808 with a
long
stick. - David Zicarelli
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Jun 28, 2011, at 12:51 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:33 PM
On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp
docs
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan
Wilkes
wrote:
> > > --- On Mon, 6/27/11, Hans-Christoph
Steiner
wrote: > >> From: Hans-Christoph Steiner
>> Subject: [PD-dev] packaging the
pddp docs
>> To: pd-dev@iem.at >> Date: Monday, June 27, 2011, 9:21
PM
>> >> Now that the core Pd docs (i.e.
/usr/lib/pd/doc/*)
are >> split out into a >> separate Debian package, I think
it could
make
sense to >> package the PDDP >> docs in a kind of mirror or
replacement
package.
>> Something like >> pddp-doc. Jonathan, in
particular, I
was
thinking >> that since you have >> wanted to work on all the patches
there,
we could
set it up >> so the >> pddp-doc package mirrors the
whole
/usr/lib/pd/doc* >> directory and patch >> structure, have this in SVN, git,
or
whatever
>> somewhere. Then people >> could choose the pddp-doc package
if they
so
choose. > > The PDDP docs I did are all for
vanilla
objects
(exceptions are > expr family, and the other "vanilla"
extras). If
a new user clicks > "Help" on a vanilla object, it should
show the
revised
PDDP help > patch by default. > > So instead of what you propose, please
make
something
like a > legacy-vanilla-help package.
That way,
if
someone really prefers > the old docs, they can still find
them, and we
won't
waste new users' time > by forcing them to use outdated and
unmaintained docs
(until they figure > out they're supposed to download a
separate
package
for the current > vanilla help patches, which nobody has
to do
for any
of the external > packages). > > -Jonathan
I agree that the PDDP docs are much
better, that's
why I
want to get them out there more.
Part of
packaging is
representing the upstream as it is and
letting the
user
decide. So I think it makes sense to
keep
puredata-doc
as what's included in the official
tarball.
As for
Pd-extended, I think it should still use
the PDDP
docs, so
like you say, showing the PDDP docs by
default.
Ok.
So we just need a plan of attack. If you can
lead up
this project, I will help as much as I can. Do you want to
include
the whole docs tree in the doc/pddp SVN?
I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla.
I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core.
Or something else? It
seems to me the easiest would be to start a separate repository
for them,
like on SourceForge, pddp is available: http://sourceforge.net/projects/ pddp
Or we could reorganize doc/pddp in the pure-data
SVN.
.hc
Since Pd-extended and Pd-l2ork already use the PDDP
docs, the only thing
we're talking about here is providing PDDP docs for
people who use
vanilla, and that's a simple commit. So I don't
see why I have to head up
some new project and learn Debian packaging in order
to meander toward (or
around) that goal.
Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well.
I'm happy to do all of the Debian packaging, that part would be easy for me.
So what is it you want me to do?
To start with, choose a repository to work out of. Shall we just reorganize the doc/pddp folder in pure-data SVN? Then make that the home of your PDDP work, and I'll package it for Debian, and make sure the new layout works in Pd-extended.
.hc
The only problem is with pddplink and helplink
dependencies, which should
just be included in vanilla as internal objects.
Is there a good reason
why they aren't?
That's something you'd have to take up with Miller, only he makes the call there. Honestly, I think we're better off keeping things as distinct libraries. Miller has limited time to spend on Pd, so the more stuff that's in Pd, the thinner his time is spread. pd-pddp is in Debian/Ubuntu/Mint etc. For someone who knows Fedora/RPM packaging, it would be really easy to package it. Then PDDP is included in Pd-extended already. So that means for the vast majority of users, pddplink and helplink are already part of the standard install.
Maybe my time would be better spent making a "gui"
plugin that just grabs
all the stuff that should be core pd but isn't and
installs it:
revised/maintained docs, [initbang], [closebang],
[pddplink], [helplink],
$@, etc.
That's done, that's called Pd-extended ;)
.hc
-Jonathan
Using ReBirth is like trying to play an 808 with a
long
stick. - David Zicarelli
The arc of history bends towards justice.
- Dr. Martin Luther King, Jr.
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:58 PM
On Jun 28, 2011, at 12:51 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:33 PM
On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp
docs
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan
Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph
Steiner
wrote:
> From: Hans-Christoph Steiner
> Subject: Re: [PD-dev] packaging
the pddp
docs
> To: "Jonathan Wilkes" jancsika@yahoo.com > Cc: pd-dev@iem.at > Date: Tuesday, June 28, 2011, 6:27
AM
> > On Jun 27, 2011, at 6:45 PM,
Jonathan
Wilkes
wrote:
> >> >> >> --- On Mon, 6/27/11,
Hans-Christoph
Steiner
> wrote: >> >>> From: Hans-Christoph
Steiner
>>> Subject: [PD-dev]
packaging the
pddp docs
>>> To: pd-dev@iem.at >>> Date: Monday, June 27,
2011, 9:21
PM
>>> >>> Now that the core Pd docs
(i.e.
/usr/lib/pd/doc/*)
> are >>> split out into a >>> separate Debian package, I
think
it could
make
> sense to >>> package the PDDP >>> docs in a kind of mirror
or
replacement
package.
>>> Something like >>> pddp-doc. Jonathan,
in
particular, I
was
> thinking >>> that since you have >>> wanted to work on all the
patches
there,
we could
> set it up >>> so the >>> pddp-doc package mirrors
the
whole
> /usr/lib/pd/doc* >>> directory and patch >>> structure, have this in
SVN, git,
or
whatever
>>> somewhere. Then
people
>>> could choose the pddp-doc
package
if they
so
> choose. >> >> The PDDP docs I did are all
for
vanilla
objects
> (exceptions are >> expr family, and the other
"vanilla"
extras). If
> a new user clicks >> "Help" on a vanilla object, it
should
show the
revised
> PDDP help >> patch by default. >> >> So instead of what you
propose, please
make
something
> like a >> legacy-vanilla-help package.
That way,
if
> someone really prefers >> the old docs, they can still
find
them, and we
won't
> waste new users' time >> by forcing them to use
outdated and
unmaintained docs
> (until they figure >> out they're supposed to
download a
separate
package
> for the current >> vanilla help patches, which
nobody has
to do
for any
> of the external >> packages). >> >> -Jonathan > > > I agree that the PDDP docs are
much
better, that's
why I
> want to get them out there more.
Part of
packaging is
> representing the upstream as it is
and
letting the
user
> decide. So I think it makes
sense to
keep
puredata-doc
> as what's included in the
official
tarball.
As for
> Pd-extended, I think it should
still use
the PDDP
docs, so
> like you say, showing the PDDP
docs by
default.
Ok.
So we just need a plan of attack. If
you can
lead up
this project, I will help as much as I can. Do you
want to
include
the whole docs tree in the doc/pddp SVN?
I'm already kind of doing that with pd-l2ork.
I've revised Miller's
control/audio/ds tutorials. Pd-l2ork has fixed
the crasher bug when
a patch closes itself, so I've got a navigation
toolbar in those
tutorials that is currently incompatible with
pd-extended/vanilla.
I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core.
He's also working off 0.42 currently, so submitting to the tracker would be pointless. I think someone was working to port the changes forward to 0.43, but Ico is currently on vacation and I'm not sure where they are in the process.
Or something else? It
seems to me the easiest would be to start a separate
repository
for them,
like on SourceForge, pddp is available: http://sourceforge.net/projects/ pddp
Or we could reorganize doc/pddp in the
pure-data
SVN.
.hc
Since Pd-extended and Pd-l2ork already use the
PDDP
docs, the only thing
we're talking about here is providing PDDP
docs for
people who use
vanilla, and that's a simple commit. So
I don't
see why I have to head up
some new project and learn Debian packaging in
order
to meander toward (or
around) that goal.
Its not a new project. I see it as a better
representation
of what's currently happening. You are doing
great
work with the PDDP docs, I think we can make the
structure
of that project work better for you. Having
it as a
distinct entity means you are less encumbered by
others when
making decisions about what should happen with
PDDP.
That distinct entity can be either a folder in the
pure-data
SVN, a separate SourceForge project, or whatever
we think is
easiest. I think one of the first two
options would
work well.
I'm happy to do all of the Debian packaging, that
part
would be easy for me.
So what is it you want me to do?
To start with, choose a repository to work out of. Shall we just reorganize the doc/pddp folder in pure-data SVN? Then make that the home of your PDDP work, and I'll package it for Debian, and make sure the new layout works in Pd-extended.
That works. Should it be merged with the current pddp libdir?
.hc
The only problem is with pddplink and
helplink
dependencies, which should
just be included in vanilla as internal
objects.
Is there a good reason
why they aren't?
That's something you'd have to take up with
Miller, only he
makes the call there. Honestly, I think
we're better
off keeping things as distinct libraries.
Miller has
limited time to spend on Pd, so the more stuff
that's in Pd,
the thinner his time is spread. pd-pddp is
in
Debian/Ubuntu/Mint etc. For someone who
knows
Fedora/RPM packaging, it would be really easy to
package
it. Then PDDP is included in Pd-extended
already. So
that means for the vast majority of users,
pddplink and
helplink are already part of the standard
install.
Maybe my time would be better spent making a
"gui"
plugin that just grabs
all the stuff that should be core pd but isn't
and
installs it:
revised/maintained docs, [initbang],
[closebang],
[pddplink], [helplink],
$@, etc.
That's done, that's called Pd-extended ;)
.hc
-Jonathan
Using ReBirth is like trying to play an
808 with a
long
stick. - David Zicarelli
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes wrote:
I'm already kind of doing that with pd-l2ork.
I've revised Miller's
control/audio/ds tutorials. Pd-l2ork has fixed
the crasher bug when
a patch closes itself, so I've got a navigation
toolbar in those
tutorials that is currently incompatible with
pd-extended/vanilla.
I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core.
He's also working off 0.42 currently, so submitting to the tracker would be pointless. I think someone was working to port the changes forward to 0.43, but Ico is currently on vacation and I'm not sure where they are in the process.
I merged in a couple things from l2ork, like Joe Sarlo's Magic Glass and inlet/outlet highlighting. More patches would be great to have.
Its not a new project. I see it as a better
representation
of what's currently happening. You are doing
great
work with the PDDP docs, I think we can make the
structure
of that project work better for you. Having
it as a
distinct entity means you are less encumbered by
others when
making decisions about what should happen with
PDDP.
That distinct entity can be either a folder in the
pure-data
SVN, a separate SourceForge project, or whatever
we think is
easiest. I think one of the first two
options would
work well.
I'm happy to do all of the Debian packaging, that
part
would be easy for me.
So what is it you want me to do?
To start with, choose a repository to work out of. Shall we just reorganize the doc/pddp folder in pure-data SVN? Then make that the home of your PDDP work, and I'll package it for Debian, and make sure the new layout works in Pd-extended.
That works. Should it be merged with the current pddp libdir?
No, the 'pddp' lib is a standard Pd library of objects meant to support documentation. The idea of this chunk is a collection of reference and tutorials. What if, for now, we make doc/pddp/tutorials and add 2.control.examples, 3.audio.examples and 4.data.structures there. Then keep reference patches in doc/pddp for now while we figure out the best place for them.
It might make sense, for example, to keep the reference patches in the 'vanilla' libdir in externals/vanilla. That's a library of all the vanilla core objects split out into a library. But its probably not quite yet time to do this, since that library is only vaguely defined now.
.hc
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes wrote:
I'm already kind of doing that with pd-l2ork.
I've revised Miller's
control/audio/ds tutorials. Pd-l2ork has
fixed
the crasher bug when
a patch closes itself, so I've got a
navigation
toolbar in those
tutorials that is currently incompatible with
pd-extended/vanilla.
I had no idea. Ico seems to work on his
own. It
would be great to have those bug fixes submitted to the patch
tracker.
The patch tracker is what Miller, IOhannes, Martin Peach, me
and
others use for keeping track of patches that are meant to go
into
pure-data core.
He's also working off 0.42 currently, so submitting to
the
tracker would be pointless. I think someone was
working
to port the changes forward to 0.43, but Ico is
currently
on vacation and I'm not sure where they are in the
process.
I merged in a couple things from l2ork, like Joe Sarlo's Magic Glass and inlet/outlet highlighting. More patches would be great to have.
As far as I understand there are a lot of changes in Pd-l2ork to core Pd, and if you accepted them into Pd-extended it would introduce more discrepancies between vanilla and extended. If that's a possibility you'd entertain to get the some of the functionality that pd-l2ork adds, then I can help with this process.
Its not a new project. I see it as a
better
representation
of what's currently happening. You
are doing
great
work with the PDDP docs, I think we can
make the
structure
of that project work better for you.
Having
it as a
distinct entity means you are less
encumbered by
others when
making decisions about what should happen
with
PDDP.
That distinct entity can be either a
folder in the
pure-data
SVN, a separate SourceForge project, or
whatever
we think is
easiest. I think one of the first
two
options would
work well.
I'm happy to do all of the Debian
packaging, that
part
would be easy for me.
So what is it you want me to do?
To start with, choose a repository to work out
of.
Shall we just reorganize the doc/pddp folder in pure-data
SVN? Then
make that the home of your PDDP work, and I'll package it for
Debian, and
make sure the new layout works in Pd-extended.
That works. Should it be merged with the current
pddp libdir?
No, the 'pddp' lib is a standard Pd library of objects meant to support documentation. The idea of this chunk is a collection of reference and tutorials. What if, for now, we make doc/pddp/tutorials and add 2.control.examples, 3.audio.examples and 4.data.structures there. Then keep reference patches in doc/pddp for now while we figure out the best place for them.
It might make sense, for example, to keep the reference patches in the 'vanilla' libdir in externals/vanilla. That's a library of all the vanilla core objects split out into a library. But its probably not quite yet time to do this, since that library is only vaguely defined now.
.hc
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
On Jun 28, 2011, at 2:41 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes wrote:
I'm already kind of doing that with pd-l2ork.
I've revised Miller's
control/audio/ds tutorials. Pd-l2ork has
fixed
the crasher bug when
a patch closes itself, so I've got a
navigation
toolbar in those
tutorials that is currently incompatible with
pd-extended/vanilla.
I had no idea. Ico seems to work on his
own. It
would be great to have those bug fixes submitted to the patch
tracker.
The patch tracker is what Miller, IOhannes, Martin Peach, me
and
others use for keeping track of patches that are meant to go
into
pure-data core.
He's also working off 0.42 currently, so submitting to
the
tracker would be pointless. I think someone was
working
to port the changes forward to 0.43, but Ico is
currently
on vacation and I'm not sure where they are in the
process.
I merged in a couple things from l2ork, like Joe Sarlo's Magic Glass and inlet/outlet highlighting. More patches would be great to have.
As far as I understand there are a lot of changes in Pd-l2ork to core Pd, and if you accepted them into Pd-extended it would introduce more discrepancies between vanilla and extended. If that's a possibility you'd entertain to get the some of the functionality that pd-l2ork adds, then I can help with this process.
Bug fixes should definitely be included, other patches are on a case by case basis. Accepting patches is a time consuming process, especially if the patch submitted are not super clean or has not been thoroughly tested. That's the main reason for patches to be rejected or ignored.
I've gone thru a lot of patches from l2ork before, and found that they were not well tested, sometimes didn't even apply cleanly, and sometimes introduced new bugs. It seems that Ico didn't want to work thru the patch process, and instead is working on a fork. That's a good way to develop solid, well tested patches so it could be that a lot of the l2ork stuff is ready to be resubmitted.
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 8:52 PM
On Jun 28, 2011, at 2:41 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes
wrote:
I'm already kind of doing that with
pd-l2ork.
I've revised Miller's
control/audio/ds tutorials.
Pd-l2ork has
fixed
the crasher bug when
a patch closes itself, so I've got a
navigation
toolbar in those
tutorials that is currently incompatible with
pd-extended/vanilla.
I had no idea. Ico seems to work on
his
own. It
would be great to have those bug fixes submitted to the
patch
tracker.
The patch tracker is what Miller, IOhannes, Martin
Peach, me
and
others use for keeping track of patches that are meant to
go
into
pure-data core.
He's also working off 0.42 currently, so
submitting to
the
tracker would be pointless. I think
someone was
working
to port the changes forward to 0.43, but Ico
is
currently
on vacation and I'm not sure where they are in
the
process.
I merged in a couple things from l2ork, like Joe
Sarlo's
Magic Glass and inlet/outlet highlighting.
More
patches would be great to have.
As far as I understand there are a lot of changes in
Pd-l2ork
to core Pd, and if you accepted them into Pd-extended
it would
introduce more discrepancies between vanilla and
extended. If
that's a possibility you'd entertain to get the some
of the
functionality that pd-l2ork adds, then I can help with
this
process.
Bug fixes should definitely be included, other patches are on a case by case basis. Accepting patches is a time consuming process, especially if the patch submitted are not super clean or has not been thoroughly tested. That's the main reason for patches to be rejected or ignored.
I've gone thru a lot of patches from l2ork before, and found that they were not well tested, sometimes didn't even apply cleanly, and sometimes introduced new bugs. It seems that Ico didn't want to work thru the patch process, and instead is working on a fork. That's a good way to develop solid, well tested patches so it could be that a lot of the l2ork stuff is ready to be resubmitted.
Well, like I said, it's still based off 0.42. When it gets ported to 0.43, maybe we can figure out a way to do this.
-Jonathan
.hc
Mistrust authority - promote decentralization. - the hacker ethic
On Jun 28, 2011, at 4:06 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 8:52 PM
On Jun 28, 2011, at 2:41 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes
wrote:
> > I'm already kind of doing that with
pd-l2ork.
I've revised Miller's > control/audio/ds tutorials.
Pd-l2ork has
fixed
the crasher bug when > a patch closes itself, so I've got a
navigation
toolbar in those > tutorials > that is currently incompatible with pd-extended/vanilla.
I had no idea. Ico seems to work on
his
own. It
would be great to have those bug fixes submitted to the
patch
tracker.
The patch tracker is what Miller, IOhannes, Martin
Peach, me
and
others use for keeping track of patches that are meant to
go
into
pure-data core.
He's also working off 0.42 currently, so
submitting to
the
tracker would be pointless. I think
someone was
working
to port the changes forward to 0.43, but Ico
is
currently
on vacation and I'm not sure where they are in
the
process.
I merged in a couple things from l2ork, like Joe
Sarlo's
Magic Glass and inlet/outlet highlighting.
More
patches would be great to have.
As far as I understand there are a lot of changes in
Pd-l2ork
to core Pd, and if you accepted them into Pd-extended
it would
introduce more discrepancies between vanilla and
extended. If
that's a possibility you'd entertain to get the some
of the
functionality that pd-l2ork adds, then I can help with
this
process.
Bug fixes should definitely be included, other patches are on a case by case basis. Accepting patches is a time consuming process, especially if the patch submitted are not super clean or has not been thoroughly tested. That's the main reason for patches to be rejected or ignored.
I've gone thru a lot of patches from l2ork before, and found that they were not well tested, sometimes didn't even apply cleanly, and sometimes introduced new bugs. It seems that Ico didn't want to work thru the patch process, and instead is working on a fork. That's a good way to develop solid, well tested patches so it could be that a lot of the l2ork stuff is ready to be resubmitted.
Well, like I said, it's still based off 0.42. When it gets ported to 0.43, maybe we can figure out a way to do this.
While the pd-gui Tcl code is very different, most of the pd C code was unchanged in 0.42 --> 0.43. So stuff that doesn't really touch the Tcl code should be really easy to apply to 0.43.
.hc
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 11:00 PM
On Jun 28, 2011, at 4:06 PM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 8:52 PM
On Jun 28, 2011, at 2:41 PM, Jonathan Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp
docs
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM
On Jun 28, 2011, at 1:10 PM, Jonathan
Wilkes
wrote:
>> >> I'm already kind of doing that
with
pd-l2ork.
> I've revised Miller's >> control/audio/ds tutorials.
Pd-l2ork has
fixed
> the crasher bug when >> a patch closes itself, so I've
got a
navigation
> toolbar in those >> tutorials >> that is currently incompatible
with
> pd-extended/vanilla. > > I had no idea. Ico seems to
work on
his
own. It
> would be great to > have those bug fixes submitted to
the
patch
tracker.
> The patch > tracker is what Miller, IOhannes,
Martin
Peach, me
and
> others use for > keeping track of patches that are
meant to
go
into
> pure-data core.
He's also working off 0.42 currently,
so
submitting to
the
tracker would be pointless. I
think
someone was
working
to port the changes forward to 0.43,
but Ico
is
currently
on vacation and I'm not sure where
they are in
the
process.
I merged in a couple things from l2ork,
like Joe
Sarlo's
Magic Glass and inlet/outlet
highlighting.
More
patches would be great to have.
As far as I understand there are a lot of
changes in
Pd-l2ork
to core Pd, and if you accepted them into
Pd-extended
it would
introduce more discrepancies between vanilla
and
extended. If
that's a possibility you'd entertain to get
the some
of the
functionality that pd-l2ork adds, then I can
help with
this
process.
Bug fixes should definitely be included, other
patches are
on a case by case basis. Accepting patches
is a time
consuming process, especially if the patch
submitted are not
super clean or has not been thoroughly
tested. That's
the main reason for patches to be rejected or
ignored.
I've gone thru a lot of patches from l2ork before,
and
found that they were not well tested, sometimes
didn't even
apply cleanly, and sometimes introduced new
bugs. It
seems that Ico didn't want to work thru the patch
process,
and instead is working on a fork. That's a
good way to
develop solid, well tested patches so it could be
that a lot
of the l2ork stuff is ready to be resubmitted.
Well, like I said, it's still based off 0.42.
When it gets ported
to 0.43, maybe we can figure out a way to do this.
While the pd-gui Tcl code is very different, most of the pd C code was unchanged in 0.42 --> 0.43. So stuff that doesn't really touch the Tcl code should be really easy to apply to 0.43.
Speaking of which: Just found a crasher bug with the $@ in pd-extended nightly build: Bug ID: 3342314
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ola,
On 2011-06-27 21:21, Hans-Christoph Steiner wrote:
Here's the files in puredata-doc: http://packages.debian.org/sid/all/puredata-doc/filelist
in case this has gone unnoticed, i wanted to point out, that currently the reference-patches (doc/5.references) are _not_ packaged with puredata-doc but instead with puredata-core, which makes erplacing them a bit awkward. however, it is super simple to replace all the tuturial patches (puredata-doc)
fgmasdr IOhannes
PS: is this a bug in my thunderbird that all replies from jonathan seem to linebreak at 50 characters, which makes it a lot of lines to scroll, if people don't trim their replies?
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes