Re: [PD] working with integers

[cyrille henry]

Le 25/05/2021 à 23:16, ro...@dds.nl a écrit :

hi,

because of the problems i had with calculations using floating point math,

and following Roman's advice, i changed to integer math.


however that's easier said then done.

i'm running again into an unexpected limitation:

32-bits can represent signed integers upto 2.147...billion.

however, as soon as a number is greater then binary 27 bits the last byte stays 
0.( after 134217727 )

e.g. 13420 + 25000 = 134224992 (should be 134225000).


what am i missing?

there are no integer in pd. All number are float.
cheers
c




rolf






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] working with integers

[rolfm]

hi, 

because of the problems i had with calculations using floating point
math, 

and following Roman's advice, i changed to integer math. 

however that's easier said then done. 

i'm running again into an unexpected limitation: 

32-bits can represent signed integers upto 2.147...billion. 

however, as soon as a number is greater then binary 27 bits the last
byte stays 0.( after 134217727 ) 

e.g. 13420 + 25000 = 134224992 (should be 134225000). 

what am i missing? 

rolf___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Alexandre Torres Porres]

By the way, one thing that is very useful for ELSE's help files is my
[display] object (similar to Extended's [PRINT] from 'pddp') that can print
any data from the outlets right on the patch, which is something people
seem to hope for in a friendlier documentation - [display] also flashes
when receiving data.

I have a solution for atom boxes that I already proposed in
https://github.com/pure-data/pure-data/issues/1321 I could give it a try in
a PR.

But Pd would still need an object for 'anything', an 'anything' box (yes, a
newly compiled GUI object), or an abstraction like [PRINT]/[display]. In
order to ship it as part of Pd, it makes better sense to me a compiled
object, instead of a new 'extra' object. Unless we have this abstraction as
a helper abstraction for the help files only. Pd already does something
like that with its 'output~.pd' abstraction.

By the way, recently, we've been discussing if 'output~.pd' should be part
of 'extra', because we're using it in 3 different places (that is, we have
3 different copies of it): - in the help files folder (5.reference), in
3.audio.examples and 4.data.structures. I can't find now where me and
IOhannes were discussing it, but it's somewhere on github.

I don't think it's worth 'promoting' output~ to extra, but I wouldn't
oppose it either. I'm also unsure about having something like [display] in
extra. I don't have a strong opinion on this though and I could go either
way with the crowd.

What I think it's important is that we have an object to help us in the
documentation, so my strong opinion is that we should find a solution. A
compiled 'anything' box would be nice, but I don't think I can easily do
that myself, so my offer is that I can design a vanilla abstraction like
[display] - first as a helper abstraction (not an 'extra' object), and
that's it.

Cheers


Em ter., 25 de mai. de 2021 às 13:51, Alexandre Torres Porres <
por...@gmail.com> escreveu:

>
>
> Em ter., 25 de mai. de 2021 às 05:50, Dan Wilcox 
> escreveu:
>
>> Does anyone have a link, etc to the pddoc project/external from
>> Pd-extended?
>>
> I feel a lot of this was already approached over 10 years ago but not
>> ported over into Pd vanilla. It might be worth checking it out before
>> starting from scratch.
>>
>
> this? => http://puredata.info/dev/pddp/pddp-drafts
>
>
>> Also, keep in mind that old habits may be hard to break so don't be
>> surprised if enforcing "one pattern to rule them all" might become
>> "whack-a-mole."
>>
>
> :)
>
> > To point some examples of things already done in regard to better
> documentation:
>  > - Porres' ELSE documentation and the Live Electronics Tutorial are good
> because of
> > the care to register and create patches that are visually unified, that
> show a concern
> > with good practices of patches creation.
>
> Thanks for the compliments.
>
> Well. For ELSE and Cyclone I adopted a similar template than the ones
> above. They're all a bit different in design, but I think they all follow
> the same idea/concept, and here's the shocking revelation: *I think it's
> a bad idea and I hate them!*
>
> I know it can be useful and helpful, but forcing any of these templates
> into every possible help file ends up in a nightmare in some cases. It
> might be good for most help files but there'll always be exceptions where
> it's just not pertinent at all to stick to the restrictions that were good
> for the other cases. Take my word after applying this over 600 times. I can
> say I regret it and would like to change it but it's just undoable at this
> point.
>
> I'm totally onboard doing a complete rework of Pd's help files and
> contributing to the documentation in general. In fact, I've been doing a
> lot of that in recent times, by writing new manual sections and rewriting
> and fixing many help files. But I wouldn't embrace the idea of choosing a
> template for all. I wouldn't work on that and I can go on and on why I
> think it's a bad idea, giving many examples why I think this is bad, in
> opposition of anyone who thinks this is great and would like to do it
> themselves.
>
> The one good thing about these templates is that they do offer a quick
> reference guide telling you what are the accepted messages, number of
> arguments and things like that. Sometimes you wanna get to this information
> very very quickly, immediately, as you're "in the zone" creating a
> masterpiece and don't want to interrupt the workflow for any second - but
> Pd Vanilla's help files force you to hold your horses for a moment and fish
> for that info.
>
> I'm not saying we can't have that when I say the templates are
> problematic. I like that too! But I've been thinking of a
> different solution that doesn't involve forcing the same window area for
> every patch and having that kind of information right in the parent window.
>
> In short, the options are:
> - having a subpatch in a standardized way in the same spot of every help
> patch called [pd reference] with that info.
> - 

Re: [PD] Patterns for Pd Documentation

[hans w. koch]

as someone using pd in teaching in a german art academy context,
i agree, that sometimes the assumption that english = international is plain 
wrong (e.g. we have many korean students, for whom german is the second 
language and which are quite lost with english).

but i would like you to consider also a "two tiered” approach, based on my 
observations on how people learn: 
1. keep the english documentation as it is and maybe gradually introduce local 
translations into the helpfile patches with .po file strings (= a lot of work…)
2. around this core, try to coordinate the growing ecosystem of tutorial videos 
(very popular) available in many languages, also written tuts and blogs.
this, to have a kind of maintained ressources pool in all the languages. 
similar to this: https://puredata.info/docs/BooksAboutPd
e.g. how many people do know, that there is a spanish version of johannes 
kreidlers bang book, which -however outdated some of its content is- still 
covers a lot of ground? (i for one used it successfully in a short course with 
spanish only speaking housewives…)

reasoning:
the helpfiles as they are, are helpful only, if one already has some clues 
about the operation of pd. 
but then their (mostly) super concise style makes it easy to pluck information 
from.

but for construction patches / solutions to “real world” problems there is more 
often than not multiple ways to skin one cat.
and i´d say the more the merrier in any language.
the deeper one gets into, the easier it becomes to transcend the language 
barrier (thats my personal experience)
but beginnning is bloody hard in any language.

best
hans


> Am 25.05.2021 um 17:41 schrieb Esteban Viveros :
> 
> Reading this question makes me feel uncomfortable.  How would defining
> above criteria shape the way the documentation is going to be built?
> And isn't using that criteria to define the shape presumptuous, forcing
> you and me to make assumptions about groups of people you're/I'm not
> part of? IMHO, inclusiveness is not achieved with identity politics.
> Thanks thanks a lot for taking a stand and explaining gaps in my 
> communication! What I pretend is to put ourselves open to welcome other 
> points of view, welcome the needs of others than us when they surface. I 
> don't know at this moment how to surface this need without some friction. 
> Sorry about that and I think we can continue from the point of the 
> explicitness of the need of welcoming diverse points of view.
> 
> I'm sorry for not giving you a more interesting/challenging view. I'm
> not saying the documentation cannot be improved, but I fail to see
> obvious problems with it. OTOH, I'm interested to hear about problems
> people face with the current documentation.
> I think you showed strong points of the actual documentation that has to be 
> kept in a review if needed.
> 
> About the point 2. It is addressed to open the scope of feedbacks. I think 
> that the effort to create a new standard for documentation should cover as 
> many opinions as possible at first (like this one). It's like a brainstorm. 
> Then we will try to systematize and organize the material we have in order to 
> constitute a form that satisfies everyone as much as possible with easy 
> maintenance, open to collaborations.
> 
> Thanks again Roman!
> 
> 
> Em ter., 25 de mai. de 2021 às 11:00, Roman Haefeli  
> escreveu:
> Hi
> 
> On Mon, 2021-05-24 at 20:49 -0300, Esteban Viveros wrote:
> 
> > 1. What is the audience that you believe will make use of the Pd
> > documentation? Things like, advanced english speakers, academics, the
> > gender, low/high earning power, if they are programmers, musicians,
> > open source people, nationality... whatever you can write in a few
> > words.
> 
> Reading this question makes me feel uncomfortable.  How would defining
> above criteria shape the way the documentation is going to be built?
> And isn't using that criteria to define the shape presumptuous, forcing
> you and me to make assumptions about groups of people you're/I'm not
> part of? IMHO, inclusiveness is not achieved with identity politics. 
> 
> I'm rather interested in what _you_ think is wrong with existing
> documentation and what _you_ think how it can be improved. I think this
> would lead to a more honest discussion. 
> 
> Just to give you one data point: 
> 
> For me the most important part is a comprehensive reference. Pd already
> covers what I need with the existing help-files (section 5) describing
> object classes and their supported methods. However, the reference is
> only interesting once you know how the language works and when you are
> familiar with its concepts. I learned Pd with the documentation it is
> delivered with. So, the sections 1-4 - for me at least - already did a
> great job at introducing me into Pd. Having said that, it took me years
> until I even tried to use data structures and I am not even sure I
> understand them now.
> 
> I'm sorry for not giving you a more 

Re: [PD] Patterns for Pd Documentation

[Alexandre Torres Porres]

Em ter., 25 de mai. de 2021 às 05:50, Dan Wilcox 
escreveu:

> Does anyone have a link, etc to the pddoc project/external from
> Pd-extended?
>
I feel a lot of this was already approached over 10 years ago but not
> ported over into Pd vanilla. It might be worth checking it out before
> starting from scratch.
>

this? => http://puredata.info/dev/pddp/pddp-drafts


> Also, keep in mind that old habits may be hard to break so don't be
> surprised if enforcing "one pattern to rule them all" might become
> "whack-a-mole."
>

:)

> To point some examples of things already done in regard to better
documentation:
 > - Porres' ELSE documentation and the Live Electronics Tutorial are good
because of
> the care to register and create patches that are visually unified, that
show a concern
> with good practices of patches creation.

Thanks for the compliments.

Well. For ELSE and Cyclone I adopted a similar template than the ones
above. They're all a bit different in design, but I think they all follow
the same idea/concept, and here's the shocking revelation: *I think it's a
bad idea and I hate them!*

I know it can be useful and helpful, but forcing any of these templates
into every possible help file ends up in a nightmare in some cases. It
might be good for most help files but there'll always be exceptions where
it's just not pertinent at all to stick to the restrictions that were good
for the other cases. Take my word after applying this over 600 times. I can
say I regret it and would like to change it but it's just undoable at this
point.

I'm totally onboard doing a complete rework of Pd's help files and
contributing to the documentation in general. In fact, I've been doing a
lot of that in recent times, by writing new manual sections and rewriting
and fixing many help files. But I wouldn't embrace the idea of choosing a
template for all. I wouldn't work on that and I can go on and on why I
think it's a bad idea, giving many examples why I think this is bad, in
opposition of anyone who thinks this is great and would like to do it
themselves.

The one good thing about these templates is that they do offer a quick
reference guide telling you what are the accepted messages, number of
arguments and things like that. Sometimes you wanna get to this information
very very quickly, immediately, as you're "in the zone" creating a
masterpiece and don't want to interrupt the workflow for any second - but
Pd Vanilla's help files force you to hold your horses for a moment and fish
for that info.

I'm not saying we can't have that when I say the templates are problematic.
I like that too! But I've been thinking of a different solution that
doesn't involve forcing the same window area for every patch and having
that kind of information right in the parent window.

In short, the options are:
- having a subpatch in a standardized way in the same spot of every help
patch called [pd reference] with that info.
- having a html file, available with the Pd application and called from
within the help patch, kinda like [slop~].

By the way, such a separate 'reference' information is sort of what we have
in MAX, totally detached from the help file and its examples. For my work
in Cyclone, I can say I hate MAX's documentation and that it is quite
flawed, but I like this concept!

The easy option is to have this as a subpatch and this can also be done
first as an initial step for the second option (where we can get the
information and put it in a separate html file).

Cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Roman Haefeli]

On Tue, 2021-05-25 at 12:41 -0300, Esteban Viveros wrote:
> > 
> About the point 2. It is addressed to open the scope of feedbacks. I
> think that the effort to create a new standard for documentation
> should cover as many opinions as possible at first (like this
> one). It's like a brainstorm. Then we will try to systematize and
> organize the material we have in order to constitute a form that
> satisfies everyone as much as possible with easy maintenance, open to
> collaborations.

While what you says makes sense in my eyes, I'm curious to know what
triggered you to start this effort. I'm asking because I would like to
understand what different notions of "good documentation" are.
Personally, I like the self-contained nature of Pd with almost no
external dependencies. I'd welcome if this quality is considered while
evaluating documentation improvements.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Esteban Viveros]

>
> Reading this question makes me feel uncomfortable.  How would defining
> above criteria shape the way the documentation is going to be built?
> And isn't using that criteria to define the shape presumptuous, forcing
> you and me to make assumptions about groups of people you're/I'm not
> part of? IMHO, inclusiveness is not achieved with identity politics.

Thanks thanks a lot for taking a stand and explaining gaps in my
communication! What I pretend is to put ourselves open to welcome other
points of view, welcome the needs of others than us when they surface. I
don't know at this moment how to surface this need without some friction.
Sorry about that and I think we can continue from the point of the
explicitness of the need of welcoming diverse points of view.

I'm sorry for not giving you a more interesting/challenging view. I'm
> not saying the documentation cannot be improved, but I fail to see
> obvious problems with it. OTOH, I'm interested to hear about problems
> people face with the current documentation.

I think you showed strong points of the actual documentation that has to be
kept in a review if needed.

About the point 2. It is addressed to open the scope of feedbacks. I think
that the effort to create a new standard for documentation should cover as
many opinions as possible at first (like this one). It's like a brainstorm.
Then we will try to systematize and organize the material we have in order
to constitute a form that satisfies everyone as much as possible with easy
maintenance, open to collaborations.

Thanks again Roman!


Em ter., 25 de mai. de 2021 às 11:00, Roman Haefeli 
escreveu:

> Hi
>
> On Mon, 2021-05-24 at 20:49 -0300, Esteban Viveros wrote:
>
> > 1. What is the audience that you believe will make use of the Pd
> > documentation? Things like, advanced english speakers, academics, the
> > gender, low/high earning power, if they are programmers, musicians,
> > open source people, nationality... whatever you can write in a few
> > words.
>
> Reading this question makes me feel uncomfortable.  How would defining
> above criteria shape the way the documentation is going to be built?
> And isn't using that criteria to define the shape presumptuous, forcing
> you and me to make assumptions about groups of people you're/I'm not
> part of? IMHO, inclusiveness is not achieved with identity politics.
>
> I'm rather interested in what _you_ think is wrong with existing
> documentation and what _you_ think how it can be improved. I think this
> would lead to a more honest discussion.
>
> Just to give you one data point:
>
> For me the most important part is a comprehensive reference. Pd already
> covers what I need with the existing help-files (section 5) describing
> object classes and their supported methods. However, the reference is
> only interesting once you know how the language works and when you are
> familiar with its concepts. I learned Pd with the documentation it is
> delivered with. So, the sections 1-4 - for me at least - already did a
> great job at introducing me into Pd. Having said that, it took me years
> until I even tried to use data structures and I am not even sure I
> understand them now.
>
> I'm sorry for not giving you a more interesting/challenging view. I'm
> not saying the documentation cannot be improved, but I fail to see
> obvious problems with it. OTOH, I'm interested to hear about problems
> people face with the current documentation.
>
> > 2. Issues you see in actual way to document the objects, suggestions
> > to improve documentation to meet your imagined pd user.
>
> Why imagined? What you think is already interesting I find. Also, you
> may have made your experiences with other Pd users and gained some
> insight from that?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 

 Esteban Viveros

www.estebanviveros.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Esteban Viveros]

Thank you Dan for the tips!

Right now I think the discussion of documentation is centralized in
educational practice inside academic environment. I had contact with the Pd
in this environment but now I see a lot of people having contact with Pd
inside free workshops, which brought other ways to search for information.

An example is here in Brazil, I noticed that the English language has been
a big obstacle in the tool's learning path. Even for teachers who teach
classes to teenagers. So I have been thinking about ways to alleviate the
difficulties, which inevitably involves supporting multiple languages in
the documentation. There is a discussion about this in the list
.

There are various insights about efforts to provide support to
multi-language patches inside Pd, move the focus of objects reference to
html files to be opened on browser and called from Pd patch. There are
to references
about Processing and OpenFrameworks docs
 and a
draft survey of possibilities to provide a platform that allows the
inclusion of content tutorials regarding synthesis techniques and
everything else.

Personally I believe we have a lot of work done using this information and
the help patch models done in Pd-extended. Would be great if we can find
this documented.

To point some examples of things already done in regard to better
documentation:
 - Porres' ELSE documentation and the Live Electronics Tutorial are good
because of the care to register and create patches that are visually
unified, that show a concern with good practices of patches creation.
 - Recently I find Pd Spectral Toolkit Documentation
 which
implements a simple and functional navigation mode.
 - Now we have http://msp.ucsd.edu/Pd_documentation/index.htm#s2, which is
shipped with Pd which start to provide information in html, but without
multi-language support and with confusing visualization. You can’t
understand if it’s a tutorial or documentation by topic. In that way Pd
Spectral Toolkit Documentation
 was more
successful.

I started to asking about in Pd patch repo, telegram Pd group, discord and
Facebook, and there at this moment people sent:
- https://gridflow.ca/help/ - which I see interesting the use of colors in
the patch which is more apelative to the eyes. But to go in this way
mapping the audience is required.

Another very blowing mind in my view, which amplify the scope of the
problem in my point of view is the mscotthouston post on github related
issue
,
he reach at github issue from a call I did in pd discord channel.

Please, disagree, propose and take a stand. This way, it will be possible
to map a little of what the pd community needs in new documentation.



Em ter., 25 de mai. de 2021 às 05:48, Dan Wilcox 
escreveu:

> Does anyone have a link, etc to the pddoc project/external from
> Pd-extended? I feel a lot of this was already approached over 10 years ago
> but not ported over into Pd vanilla. It might be worth checking it out
> before starting from scratch.
>
> Also, keep in mind that old habits may be hard to break so don't be
> surprised if enforcing "one pattern to rule them all" might become
> "whack-a-mole."
>
> On May 25, 2021, at 1:50 AM, pd-list-requ...@lists.iem.at wrote:
>
> Date: Mon, 24 May 2021 20:49:37 -0300
> From: Esteban Viveros 
> To: Pd-List 
> Subject: [PD] Patterns for Pd Documentation
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hello list! I'm looking for beliefs, judgment, advice, and anything that
> can contribute to better documentation of the entire world for pd users
> only.
>
> I suggest explicit 2 points:
> 1. What is the audience that you believe will make use of the Pd
> documentation? Things like, advanced english speakers, academics, the
> gender, low/high earning power, if they are programmers, musicians, open
> source people, nationality... whatever you can write in a few words.
>
> 2. Issues you see in actual way to document the objects, suggestions to
> improve documentation to meet your imagined pd user.
>
> Educational experiences, examples of documentation patterns, opinions about
> how things have been done so far are welcome! If you want to contribute
> more in effort to improve Pd Docs Structure I have opened a issue in Pd
> github: Pattern design for Pd Documentation
> 
>
> Thanks for all! :)
>
>
>

-- 

 Esteban Viveros

www.estebanviveros.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Roman Haefeli]

Hi

On Mon, 2021-05-24 at 20:49 -0300, Esteban Viveros wrote:

> 1. What is the audience that you believe will make use of the Pd
> documentation? Things like, advanced english speakers, academics, the
> gender, low/high earning power, if they are programmers, musicians,
> open source people, nationality... whatever you can write in a few
> words.

Reading this question makes me feel uncomfortable.  How would defining
above criteria shape the way the documentation is going to be built?
And isn't using that criteria to define the shape presumptuous, forcing
you and me to make assumptions about groups of people you're/I'm not
part of? IMHO, inclusiveness is not achieved with identity politics. 

I'm rather interested in what _you_ think is wrong with existing
documentation and what _you_ think how it can be improved. I think this
would lead to a more honest discussion. 

Just to give you one data point: 

For me the most important part is a comprehensive reference. Pd already
covers what I need with the existing help-files (section 5) describing
object classes and their supported methods. However, the reference is
only interesting once you know how the language works and when you are
familiar with its concepts. I learned Pd with the documentation it is
delivered with. So, the sections 1-4 - for me at least - already did a
great job at introducing me into Pd. Having said that, it took me years
until I even tried to use data structures and I am not even sure I
understand them now.

I'm sorry for not giving you a more interesting/challenging view. I'm
not saying the documentation cannot be improved, but I fail to see
obvious problems with it. OTOH, I'm interested to hear about problems
people face with the current documentation.

> 2. Issues you see in actual way to document the objects, suggestions
> to improve documentation to meet your imagined pd user.

Why imagined? What you think is already interesting I find. Also, you
may have made your experiences with other Pd users and gained some
insight from that? 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patterns for Pd Documentation

[Dan Wilcox]

Does anyone have a link, etc to the pddoc project/external from Pd-extended? I 
feel a lot of this was already approached over 10 years ago but not ported over 
into Pd vanilla. It might be worth checking it out before starting from scratch.

Also, keep in mind that old habits may be hard to break so don't be surprised 
if enforcing "one pattern to rule them all" might become "whack-a-mole."

> On May 25, 2021, at 1:50 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Mon, 24 May 2021 20:49:37 -0300
> From: Esteban Viveros mailto:emvive...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: [PD] Patterns for Pd Documentation
> Message-ID:
>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello list! I'm looking for beliefs, judgment, advice, and anything that
> can contribute to better documentation of the entire world for pd users
> only.
> 
> I suggest explicit 2 points:
> 1. What is the audience that you believe will make use of the Pd
> documentation? Things like, advanced english speakers, academics, the
> gender, low/high earning power, if they are programmers, musicians, open
> source people, nationality... whatever you can write in a few words.
> 
> 2. Issues you see in actual way to document the objects, suggestions to
> improve documentation to meet your imagined pd user.
> 
> Educational experiences, examples of documentation patterns, opinions about
> how things have been done so far are welcome! If you want to contribute
> more in effort to improve Pd Docs Structure I have opened a issue in Pd
> github: Pattern design for Pd Documentation
>  >
> 
> Thanks for all! :)

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list