Re: [PD] arraysize WAS apt.puredata.info is back!

[Jonathan Wilkes]

- Original Message -
> From: Simon Wise 
> To: Jonathan Wilkes 
> Cc: "pd-list@iem.at" 
> Sent: Friday, September 28, 2012 11:11 PM
> Subject: Re: [PD] arraysize WAS apt.puredata.info is back!
> 
> On 29/09/12 00:57, Jonathan Wilkes wrote:
> 
>>  So if you think the debian repos are the first place to look, then you 
> would agree
> 
> they are the first place I look for a file I am missing, so if someone 
> referred 
> to [arraysize] I'd check if I have it available by:
> 
> $ apt-file search arraysize.pd
> pd-arraysize: /usr/lib/pd/extra/arraysize/arraysize.pd_linux
> $
> 
> then apt-get install pd-arraysize  or apt-cache show pd-arraysize if I wanted 
> to 
> see a description or dependency info first.
> 
>>  that arraysize should tell the user they can get the same functionality 
> with
>>  expr which is already installed with pd-extended, pd-l2ork, and pd vanilla 
> and
>>  therefore more modular, right?
> 
> yes .. that info is useful to include - perhaps in the arraysize help file, 
> perhaps in the package description, and your expr example in help is the 
> right 
> one in that context. It is your suggestion that arraysize be deprecated that 
> I 
> do not like.

You're right, because it isn't superseded by a new feature, but rather by an old
one.  There's probably not a term for that because the normal response is 
"please
don't add bloat to the system".

-Jonathan

> 
> Simon
> 

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

Re: [PD] arraysize WAS apt.puredata.info is back!

[Simon Wise]

On 29/09/12 00:57, Jonathan Wilkes wrote:


So if you think the debian repos are the first place to look, then you would 
agree


they are the first place I look for a file I am missing, so if someone referred 
to [arraysize] I'd check if I have it available by:


$ apt-file search arraysize.pd
pd-arraysize: /usr/lib/pd/extra/arraysize/arraysize.pd_linux
$

then apt-get install pd-arraysize  or apt-cache show pd-arraysize if I wanted to 
see a description or dependency info first.



that arraysize should tell the user they can get the same functionality with
expr which is already installed with pd-extended, pd-l2ork, and pd vanilla and
therefore more modular, right?


yes .. that info is useful to include - perhaps in the arraysize help file, 
perhaps in the package description, and your expr example in help is the right 
one in that context. It is your suggestion that arraysize be deprecated that I 
do not like.


Simon

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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Hans-Christoph Steiner]

On 09/28/2012 04:03 PM, András Murányi wrote:
>
 I think it'll be a lot easier if you start with just 'puredata' and the
 libs based on the Library Template.  Then once you get the hang of basic
 RPM packaging, you can take on the whole pd-extended, which can be
 painful.  Also, I think that Pd-extended 0.43.1 will be a lot easier to
 package since I've fixed all of the problems that came up during the
 proper debian packaging.


>>> Well... I'm actually enjoying RPM packaging, it's a nice compact thing
>> with
>>> everything controlled from a single spec file, and at the moment the
>>> simpler way for me is to try to get pd-extended build, and to get into
>> the
>>> Library Template, which I'm completely unfamiliar with, at a later point.
>>> The problems which I'm having are with some individual externals, but
>> this
>>> way when I solve one, the next one comes up, so it's easy to go through
>> all
>>> of them. At least I hope so.
>>> I'd even say: let me finish packaging 0.42.5-extended as a monolith now
>>> (according to the original topic), and let's do 0.43 with the Library
>>> Template approach later. Is that OK?
>>>
>>> Again, I'm focusing more on the RPM side and I'd by happy if I could
>> feed a
>>> debian-ready source tar.gz to the OBS, and I'd provide only the dsc. The
>>> less cool way is to upload a static file (like the one generated by
>>> pd-extended-source-tarball.sh), the more cool way would be to link to one
>>> which is online somewhere. Is there one?
>> You should do it how you want to do it.  I suggested starting with the
>> library template because I think it would be a lot easier, since the
>> Makefile was custom made to work well with Debian packaging by providing
>> very standard names for commands "make clean", "make", "make install",
>> "make dist", etc.
>
> Alrite, let's see if the whole thing proves to be a bite too big... :)
> For the separate RPM packages, one source package will be enough since it's
> possible to define multiple binary packages with the same spec file. It's
> rather handy from the source package side, I'll just have to see how to
> apply it to the Library Template.
> For the separate DEBs, I'm not yet sure which kind of organization will be
> the best. Maybe a bunch if dsc files in the same OBS source package, but I
> wonder if they could use the same tar.gz at least.
>
> András
>

With debs, you can also have one source package make many binary
packages.  All of that is already handled by the library template, so if
you want to build the per-library debs, you can just get the debian
package sources and upload those.  You can find many of those via our
Debian QA pages:

http://qa.debian.org/developer.php?login=h...@eds.org
http://qa.debian.org/developer.php?login=zmoel...@iem.at
http://qa.debian.org/developer.php?login=reduz...@gmail.com

.hc

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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Hans-Christoph Steiner]

On 09/28/2012 03:24 PM, Hans-Christoph Steiner wrote:
> On 09/28/2012 12:10 PM, András Murányi wrote:
>>> It could be a useful way to provide Debian/squeeze packages.
> If you want to try my new Pd-extended proper debian support, run:
>
> $
>>> ~/auto-build/pd-extended/scripts/auto-build/pd-extended-source-tarball.sh
> $ mv /tmp/Pd-extended_0.43.1~20120926-source.tar.bz2
> ~/auto-build/pd-extended_0.43.1~20120926.orig.tar.bz2
> $ cd ~/auto-build/pd-extended
> $ debuild -S -uc -us
>
 Hm, I don't have this script yet in ~auto-build/ ... It seems it doesn't
 work if I just download it to any place along with its whole folder, but
>>> I
 cannot run it from the main run-automated-builder script either, because
 rsync cannot reach the server.
>>> you need to get them from SVN:
>>>
>>> cd ~/auto-build/pd-extended/scripts
>>> svn up
>>> cd ..
>>> svn up
>>>
>> That did the trick!
>> The script itself didn't succeed at the first run but the third run
>> completed clean.
>> And it deletes the file at the end so I needed to copy it before it
>> finished :o)
> I just committed some fixes for that. :)  But you can also get a source
> tarball that's generated each night:
>
> http://blinky.at.or.at/auto-build/2012-09-28/
>
>
>>> The rsync method is gone for now, and perhaps permanently.  I'm trying
>>> to see if I can make the cleaning process work without rsync.
>>>
> (the -uc -us) means ignore the whole signing procedure, including the
> name in the debian/changelog)
> Also, its great that you are taking on the spec file for RPMs!  Once you
 get 'puredata' working, then it would be very handy if you could make
> one for the externals/template.  Then it'll be easy to make RPMs for
> most of the libraries in Pd-extended, just like what's in Debian.
>
> I've never made RPMs before, but I've done a lot of other packaging, so
> I'll help where I can.
>
 Well, the deb thing is stuck at this line now:

> dpkg-source: error: unrecognized file for a v1.0 source package:
> Pd-0.42.5-extended.tar.gz
>
 The file is pulled from

>>> http://sourceforge.net/projects/pure-data/files/pd-extended/0.42.5/Pd-0.42.5-extended.tar.gz
 (It has a packages/linux_make/debian folder but still no good.)
 Is there a .tar.gz for pd-extended online which is suitable for deb
 packaging and I could link to it? I don't want to reinvent the wheel...
 BTW, Is there a Pd-0.42.5-extended-dev.deb (or alike) that I could study
>>> or
 use for parts?

 The rpm is losing it here:

> `test -f
>
>>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs
> && cat
>
>>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs`
> /usr/bin/ld: cannot find -lmp3lame
>
 As far as I understood lame-devel is not available in Fedora. How do I
 proceed?

 András

>>> For Debian/squeeze, we rely on the libmp3lame-dev that's in
>>> squeeze-backports.  Previously, it was required that people downloaded
>>> it from deb-multimedia.org.  I guess you'd need to get it from somewhere
>>> else, but I don't know enough about Fedora to say.  Does PlanetCCRMA
>>> include lame?  I think that would be the best place for dependencies.
>>>
>> Planet CCRMA does have lame, but the OBS doesn't have Planet CCRMA.
>> It is possible to fetch and build the lame sources into with pd but then we
>> would have the lame binary bundled into pd which is not something we want,
>> do we?
>> So my best idea right now is to disable the external(s) that use lame.
> That's easiest for now.  I think only 'unauthorized' and maybe 'iemlib'
> require lame.
>
>>> I think it'll be a lot easier if you start with just 'puredata' and the
>>> libs based on the Library Template.  Then once you get the hang of basic
>>> RPM packaging, you can take on the whole pd-extended, which can be
>>> painful.  Also, I think that Pd-extended 0.43.1 will be a lot easier to
>>> package since I've fixed all of the problems that came up during the
>>> proper debian packaging.
>>>
>>>
>> Well... I'm actually enjoying RPM packaging, it's a nice compact thing with
>> everything controlled from a single spec file, and at the moment the
>> simpler way for me is to try to get pd-extended build, and to get into the
>> Library Template, which I'm completely unfamiliar with, at a later point.
>> The problems which I'm having are with some individual externals, but this
>> way when I solve one, the next one comes up, so it's easy to go through all
>> of them. At least I hope so.
>> I'd even say: let me finish packaging 0.42.5-extended as a monolith now
>> (according to the original topic), and let's do 0.43 with the Library
>> Template approach later. Is that OK?
>>
>> Again, I'm focusing more on the RPM side and I'd by happy if I could feed a
>> debian-ready

Re: [PD] arraysize WAS apt.puredata.info is back!

[Jonathan Wilkes]

- Original Message -
> From: Hans-Christoph Steiner 
> To: pd-list@iem.at
> Cc: 
> Sent: Friday, September 28, 2012 2:55 PM
> Subject: Re: [PD] arraysize WAS apt.puredata.info is back!
> 
> On 09/28/2012 12:57 PM, Jonathan Wilkes wrote:
>> 
>> 
>> 
>>  - Original Message -
>>>  From: Simon Wise 
>>>  To: Jonathan Wilkes 
>>>  Cc: "pd-list@iem.at" 
>>>  Sent: Friday, September 28, 2012 7:32 AM
>>>  Subject: Re: [PD] arraysize WAS apt.puredata.info is back!
>>> 
>>>  On 28/09/12 12:48, Jonathan Wilkes wrote:
>>> 
>>     I'm referring to what Hans wrote:
>>>     For me, apt-get install pd-arraysize is far easier 
> than 
>>>  trying to
>>          remember that [expr] trick.  And thankfully we can 
> write 
>>>  externals,
>>          so we can have choice. :-)
>    exactly ...
    Not exactly-- you were referring to using the Debian packaging
    system in a general sense to find packages, and you were saying 
> that
    calling someone who uses it a mythical user is not inaccurate.
>>>  no .. I was saying that debian users who treat their debian repository 
> as an 
>>>  extension of their system and the first place to look for something 
> they need to 
>>>  do are not mythical at all, that if you are familiar with the debian 
> tools it is 
>>>  very quick and easy to find which package has a file or functionality 
> you are 
>>>  looking for, and that not surprisingly some of these users are able and 
> willing 
>>>  to do the extra bit of work to make things they find useful available 
> in the way 
>>>  they find convenient.
>> 
>>  So if you think the debian repos are the first place to look, then you 
> would agree
>>  that arraysize should tell the user they can get the same functionality 
> with
>>  expr which is already installed with pd-extended, pd-l2ork, and pd vanilla 
> and
>>  therefore more modular, right?
> 
> Add it to the arraysize-help.pd and it'll be included in the next release.
> 
> .hc

Alright.

How about the expr-help.pd problem I asked you about?  I can't exactly ask
the author to use the PDDP revised patches because they rely on
pddplink and helplink, and expr ships with Pd vanilla which doesn't have those.

Any ideas?

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

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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Hans-Christoph Steiner]

On 09/28/2012 12:10 PM, András Murányi wrote:
>> It could be a useful way to provide Debian/squeeze packages.
 If you want to try my new Pd-extended proper debian support, run:

 $
>> ~/auto-build/pd-extended/scripts/auto-build/pd-extended-source-tarball.sh
 $ mv /tmp/Pd-extended_0.43.1~20120926-source.tar.bz2
 ~/auto-build/pd-extended_0.43.1~20120926.orig.tar.bz2
 $ cd ~/auto-build/pd-extended
 $ debuild -S -uc -us

>>> Hm, I don't have this script yet in ~auto-build/ ... It seems it doesn't
>>> work if I just download it to any place along with its whole folder, but
>> I
>>> cannot run it from the main run-automated-builder script either, because
>>> rsync cannot reach the server.
>> you need to get them from SVN:
>>
>> cd ~/auto-build/pd-extended/scripts
>> svn up
>> cd ..
>> svn up
>>
> That did the trick!
> The script itself didn't succeed at the first run but the third run
> completed clean.
> And it deletes the file at the end so I needed to copy it before it
> finished :o)

I just committed some fixes for that. :)  But you can also get a source
tarball that's generated each night:

http://blinky.at.or.at/auto-build/2012-09-28/


>> The rsync method is gone for now, and perhaps permanently.  I'm trying
>> to see if I can make the cleaning process work without rsync.
>>
 (the -uc -us) means ignore the whole signing procedure, including the
 name in the debian/changelog)
 Also, its great that you are taking on the spec file for RPMs!  Once you
>>> get 'puredata' working, then it would be very handy if you could make
 one for the externals/template.  Then it'll be easy to make RPMs for
 most of the libraries in Pd-extended, just like what's in Debian.

 I've never made RPMs before, but I've done a lot of other packaging, so
 I'll help where I can.

>>> Well, the deb thing is stuck at this line now:
>>>
 dpkg-source: error: unrecognized file for a v1.0 source package:
 Pd-0.42.5-extended.tar.gz

>>> The file is pulled from
>>>
>> http://sourceforge.net/projects/pure-data/files/pd-extended/0.42.5/Pd-0.42.5-extended.tar.gz
>>> (It has a packages/linux_make/debian folder but still no good.)
>>> Is there a .tar.gz for pd-extended online which is suitable for deb
>>> packaging and I could link to it? I don't want to reinvent the wheel...
>>> BTW, Is there a Pd-0.42.5-extended-dev.deb (or alike) that I could study
>> or
>>> use for parts?
>>>
>>> The rpm is losing it here:
>>>
 `test -f

>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs
 && cat

>> /home/abuild/rpmbuild/BUILD/Pd-0.42.5-extended/externals/unauthorized/mp3live~/../linux/mp3streamin~.libs`
 /usr/bin/ld: cannot find -lmp3lame

>>> As far as I understood lame-devel is not available in Fedora. How do I
>>> proceed?
>>>
>>> András
>>>
>> For Debian/squeeze, we rely on the libmp3lame-dev that's in
>> squeeze-backports.  Previously, it was required that people downloaded
>> it from deb-multimedia.org.  I guess you'd need to get it from somewhere
>> else, but I don't know enough about Fedora to say.  Does PlanetCCRMA
>> include lame?  I think that would be the best place for dependencies.
>>
> Planet CCRMA does have lame, but the OBS doesn't have Planet CCRMA.
> It is possible to fetch and build the lame sources into with pd but then we
> would have the lame binary bundled into pd which is not something we want,
> do we?
> So my best idea right now is to disable the external(s) that use lame.

That's easiest for now.  I think only 'unauthorized' and maybe 'iemlib'
require lame.

>> I think it'll be a lot easier if you start with just 'puredata' and the
>> libs based on the Library Template.  Then once you get the hang of basic
>> RPM packaging, you can take on the whole pd-extended, which can be
>> painful.  Also, I think that Pd-extended 0.43.1 will be a lot easier to
>> package since I've fixed all of the problems that came up during the
>> proper debian packaging.
>>
>>
> Well... I'm actually enjoying RPM packaging, it's a nice compact thing with
> everything controlled from a single spec file, and at the moment the
> simpler way for me is to try to get pd-extended build, and to get into the
> Library Template, which I'm completely unfamiliar with, at a later point.
> The problems which I'm having are with some individual externals, but this
> way when I solve one, the next one comes up, so it's easy to go through all
> of them. At least I hope so.
> I'd even say: let me finish packaging 0.42.5-extended as a monolith now
> (according to the original topic), and let's do 0.43 with the Library
> Template approach later. Is that OK?
>
> Again, I'm focusing more on the RPM side and I'd by happy if I could feed a
> debian-ready source tar.gz to the OBS, and I'd provide only the dsc. The
> less cool way is to upload a static file (like the one generated by
> pd-extended-source-tarball.sh), the m

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Hans-Christoph Steiner]

Yup, exactly.  I'm working on getting it working on oneiric and
precise... those two will definitely be included.

.hc

On 09/28/2012 02:32 PM, batinste wrote:
> Have a look at
> https://launchpad.net/~eighthave/+archive/pd-extended/+packages :
> Precise and Oneiric versions failed to build, so synaptic cannot show
> you any installable version.
>
> On 28/09/2012 19:07, Rick T wrote:
>> Greets Hans
>>
>> I'm testing your new version in ubuntu 12.04 64bit.  However when I
>> add the ppa and the deb line and do an "sudo apt-get update" the
>> ubuntu software center does not find it.  Any idea why?
>>
>> Aloha
>> Rick
>>
>> On Fri, Sep 21, 2012 at 3:06 PM, Hans-Christoph Steiner
>> mailto:h...@at.or.at>> wrote:
>>
>>
>> Back in Jan/Feb, I put together a pd-extended.deb package that
>> uses the
>> normal process for building .deb packages rather than the crazy hack
>> that normally builds the Pd-extended .deb packages.  I finally
>> worked
>> out the final kinks, and there are now working packages for Ubuntu
>> i386
>> and amd64 for Lucid and Maverick.
>>
>> Doing it this way means that anyone can build it using launchpad,
>> opensuse build, or any other standard method.  That means its
>> easy to
>> support both i386/amd64 32-bit/64-bit on Ubuntu lucid, maverick,
>> natty,
>> oneiric, precise, and quantal.
>>
>> I just uploaded builds for Hardy, Jaunty, Karmic, Lucid, Natty,
>> Oneiric,
>> Precise, and Quantal. Hopefully those all build.  If this works out,
>> then I'm going to switch
>> all .deb building to this method.
>>
>> So please test these packages and let me know if they work for you!
>>
>> https://launchpad.net/~eighthave/+archive/pd-extended
>> 
>>
>> .hc
>>
>>
>> ___
>> Pd-list@iem.at  mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>
>


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

Re: [PD] arraysize WAS apt.puredata.info is back!

[Hans-Christoph Steiner]

On 09/28/2012 12:57 PM, Jonathan Wilkes wrote:
>
>
>
> - Original Message -
>> From: Simon Wise 
>> To: Jonathan Wilkes 
>> Cc: "pd-list@iem.at" 
>> Sent: Friday, September 28, 2012 7:32 AM
>> Subject: Re: [PD] arraysize WAS apt.puredata.info is back!
>>
>> On 28/09/12 12:48, Jonathan Wilkes wrote:
>>
>I'm referring to what Hans wrote:
>>For me, apt-get install pd-arraysize is far easier than 
>> trying to
> remember that [expr] trick.  And thankfully we can write 
>> externals,
> so we can have choice. :-)
   exactly ...
>>>   Not exactly-- you were referring to using the Debian packaging
>>>   system in a general sense to find packages, and you were saying that
>>>   calling someone who uses it a mythical user is not inaccurate.
>> no .. I was saying that debian users who treat their debian repository as an 
>> extension of their system and the first place to look for something they 
>> need to 
>> do are not mythical at all, that if you are familiar with the debian tools 
>> it is 
>> very quick and easy to find which package has a file or functionality you 
>> are 
>> looking for, and that not surprisingly some of these users are able and 
>> willing 
>> to do the extra bit of work to make things they find useful available in the 
>> way 
>> they find convenient.
>
> So if you think the debian repos are the first place to look, then you would 
> agree
> that arraysize should tell the user they can get the same functionality with
> expr which is already installed with pd-extended, pd-l2ork, and pd vanilla and
> therefore more modular, right?

Add it to the arraysize-help.pd and it'll be included in the next release.

.hc


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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Rick T]

Thanks ;-)

Aloha
Rick

On Fri, Sep 28, 2012 at 8:32 AM, batinste  wrote:

>  Have a look at
> https://launchpad.net/~eighthave/+archive/pd-extended/+packages : Precise
> and Oneiric versions failed to build, so synaptic cannot show you any
> installable version.
>
>
> On 28/09/2012 19:07, Rick T wrote:
>
> Greets Hans
>
> I'm testing your new version in ubuntu 12.04 64bit.  However when I add
> the ppa and the deb line and do an "sudo apt-get update" the ubuntu
> software center does not find it.  Any idea why?
>
> Aloha
> Rick
>
> On Fri, Sep 21, 2012 at 3:06 PM, Hans-Christoph Steiner wrote:
>
>>
>> Back in Jan/Feb, I put together a pd-extended.deb package that uses the
>> normal process for building .deb packages rather than the crazy hack
>> that normally builds the Pd-extended .deb packages.  I finally worked
>> out the final kinks, and there are now working packages for Ubuntu i386
>> and amd64 for Lucid and Maverick.
>>
>> Doing it this way means that anyone can build it using launchpad,
>> opensuse build, or any other standard method.  That means its easy to
>> support both i386/amd64 32-bit/64-bit on Ubuntu lucid, maverick, natty,
>> oneiric, precise, and quantal.
>>
>> I just uploaded builds for Hardy, Jaunty, Karmic, Lucid, Natty, Oneiric,
>> Precise, and Quantal. Hopefully those all build.  If this works out,
>> then I'm going to switch
>> all .deb building to this method.
>>
>> So please test these packages and let me know if they work for you!
>>
>> https://launchpad.net/~eighthave/+archive/pd-extended
>>
>> .hc
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> ___pd-l...@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[batinste]

Have a look at 
https://launchpad.net/~eighthave/+archive/pd-extended/+packages : 
Precise and Oneiric versions failed to build, so synaptic cannot show 
you any installable version.


On 28/09/2012 19:07, Rick T wrote:

Greets Hans

I'm testing your new version in ubuntu 12.04 64bit.  However when I 
add the ppa and the deb line and do an "sudo apt-get update" the 
ubuntu software center does not find it.  Any idea why?


Aloha
Rick

On Fri, Sep 21, 2012 at 3:06 PM, Hans-Christoph Steiner > wrote:



Back in Jan/Feb, I put together a pd-extended.deb package that
uses the
normal process for building .deb packages rather than the crazy hack
that normally builds the Pd-extended .deb packages.  I finally worked
out the final kinks, and there are now working packages for Ubuntu
i386
and amd64 for Lucid and Maverick.

Doing it this way means that anyone can build it using launchpad,
opensuse build, or any other standard method.  That means its easy to
support both i386/amd64 32-bit/64-bit on Ubuntu lucid, maverick,
natty,
oneiric, precise, and quantal.

I just uploaded builds for Hardy, Jaunty, Karmic, Lucid, Natty,
Oneiric,
Precise, and Quantal. Hopefully those all build.  If this works out,
then I'm going to switch
all .deb building to this method.

So please test these packages and let me know if they work for you!

https://launchpad.net/~eighthave/+archive/pd-extended


.hc


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




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


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

Re: [PD] array size (was Re: arraysize)

[Charles Goyard]

Hi,

Cyrille Henry wrote:
> - if you include a list_lenght in pd, lot's of people abstraction may
> have the same name

No, only people with bad speling.


ok, noisy useless post :)

++
-- 
Charlot

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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[Rick T]

Greets Hans

I'm testing your new version in ubuntu 12.04 64bit.  However when I add the
ppa and the deb line and do an "sudo apt-get update" the ubuntu software
center does not find it.  Any idea why?

Aloha
Rick

On Fri, Sep 21, 2012 at 3:06 PM, Hans-Christoph Steiner wrote:

>
> Back in Jan/Feb, I put together a pd-extended.deb package that uses the
> normal process for building .deb packages rather than the crazy hack
> that normally builds the Pd-extended .deb packages.  I finally worked
> out the final kinks, and there are now working packages for Ubuntu i386
> and amd64 for Lucid and Maverick.
>
> Doing it this way means that anyone can build it using launchpad,
> opensuse build, or any other standard method.  That means its easy to
> support both i386/amd64 32-bit/64-bit on Ubuntu lucid, maverick, natty,
> oneiric, precise, and quantal.
>
> I just uploaded builds for Hardy, Jaunty, Karmic, Lucid, Natty, Oneiric,
> Precise, and Quantal. Hopefully those all build.  If this works out,
> then I'm going to switch
> all .deb building to this method.
>
> So please test these packages and let me know if they work for you!
>
> https://launchpad.net/~eighthave/+archive/pd-extended
>
> .hc
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] arraysize WAS apt.puredata.info is back!

[Jonathan Wilkes]

- Original Message -
> From: Simon Wise 
> To: Jonathan Wilkes 
> Cc: "pd-list@iem.at" 
> Sent: Friday, September 28, 2012 7:32 AM
> Subject: Re: [PD] arraysize WAS apt.puredata.info is back!
> 
> On 28/09/12 12:48, Jonathan Wilkes wrote:
> 
    I'm referring to what Hans wrote:
>    For me, apt-get install pd-arraysize is far easier than 
> trying to
         remember that [expr] trick.  And thankfully we can write 
> externals,
         so we can have choice. :-)
>>> 
>>>  exactly ...
>> 
>>  Not exactly-- you were referring to using the Debian packaging
>>  system in a general sense to find packages, and you were saying that
>>  calling someone who uses it a mythical user is not inaccurate.
> 
> no .. I was saying that debian users who treat their debian repository as an 
> extension of their system and the first place to look for something they need 
> to 
> do are not mythical at all, that if you are familiar with the debian tools it 
> is 
> very quick and easy to find which package has a file or functionality you are 
> looking for, and that not surprisingly some of these users are able and 
> willing 
> to do the extra bit of work to make things they find useful available in the 
> way 
> they find convenient.


So if you think the debian repos are the first place to look, then you would 
agree
that arraysize should tell the user they can get the same functionality with
expr which is already installed with pd-extended, pd-l2ork, and pd vanilla and
therefore more modular, right?


> 
> If some debian users find it convenient then it isn't obsolete and 
> shouldn't be deprecated unless the maintainer is tired of keeping it there 
> or it is becoming incompatible with other things in that system.
> 
> A huge number of non-debian users also benefit from the work done in debian 
> maintaining dependency information, documenting licensing and building for a 
> variety of hardware platforms ... they benefit via developers using that 
> information to set up the systems that are widely used. A few extra bits and 
> pieces that are mainly useful to a few debian users isn't a problem.
> 
> 
> Simon
>


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

Re: [PD] pd-extended 0.42.5 packages for many Ubuntu releases, i386/amd64

[András Murányi]

> > I hear that OpenSUSE's build server will build Debian packages, but
> >> I've
> > never used it.  It would be very useful if someone set that up, I
> >> think can
> > also build Fedora and SUSE packages.
> >
> >
>  I played around with OpenSUSE's OBS but it's not a success yet.
>  It needs a something.spec file for building RPMs and a something.dsc
> >> file
>  for DEBs. Both files serve to define a source package.
>  For the spec file, I started from one well worked out for Planet CCRMA
> >> by
>  Fernando Lopez-Lezcano. It's looking good for the OBS right now except
> >> that
>  I'm struggling with the source definition, i.e. it doesn't seem to be
> >> able
>  to grab the tar.gz from sourceforge.
>  For the debian dsc file, I used Paul Brossier's one. The dsc is much
>  simpler, but it cannot accept source urls, only local files. That's
> >> where
>  OBS's so-called "Source Service" comes into the picture, which can
> >> download
>  a tar.gz or even checkout an svn repo and tar.gz it for me. I'm
> >> struggling
>  with this too, because (1) I'm unable to grab the resulting tar.gz
> from
> >> the
>  dsc (it's created with an odd name that contains a colon) and (2) in
> the
>  dsc an MD5 checksum of the tar.gz needs to be present which is unknown
> >> in
>  the case of an archive newly created from SVN.
>  I'll try to grow smarter with OBS, but in the meantime, any advice is
>  highly appreciated. :)
> 
> >>> Update: both source access problems are solved for now.
> >>> The deb build at the moment is stuck at the point where it doesn't
> >>> recognize the source package as a valid one. Dunno why.
> >>> The rpm build got as far as where it would have needed mp3lame - seems
> >> that
> >>> it's only available with Planet CCRMA (?). GEM builds fine. I'm playing
> >>> around with conditionals for requires for different CPU capabilities,
> >>> because OBS's spec file parser is somewhat limited.
> >>> More news soon, hopefully.
> >> Deb source packages are too tricky to create manually, use the Debian
> >> tools.  If you are working from a git repo, like for puredata, the use
> >> "git-buildpackage -S".   For any repo with the debian/ folder there, you
> >> can use "debuild -S"
> >>
> >> You will need to change the debian/changelog to have your name and email
> >> in it, so that the signing part works, if opensuse requires signed
> >> packages.  Launchpad, Debian, and Ubuntu all do.
> >>
> >> At the very least, you'll want to do:
> >>
> >> sudo apt-get install dpkg-dev devscripts debhelper cdbs
> >>
> >> You can also download the source packages from the Debian or Ubuntu
> >> official packages, but they'll be signed by the original uploaders key.
> >> That wouldn't work with Launchpad but might with OBS, if it has looser
> >> signing restrictions.
> >>
> > Cool, I've actually paid less attention to the deb process on OBS knowing
> > that it's already worked out and up-to-date somewhere else. I'll take a
> > look at how I can reuse those packages.
> > OBS doesn't need signed packages, an I haven't tried if it accepts
> packages
> > signed by someone else.
>
> It could be a useful way to provide Debian/squeeze packages.
>
> >> If you want to try my new Pd-extended proper debian support, run:
> >>
> >> $
> ~/auto-build/pd-extended/scripts/auto-build/pd-extended-source-tarball.sh
> >> $ mv /tmp/Pd-extended_0.43.1~20120926-source.tar.bz2
> >> ~/auto-build/pd-extended_0.43.1~20120926.orig.tar.bz2
> >> $ cd ~/auto-build/pd-extended
> >> $ debuild -S -uc -us
> >>
> > Hm, I don't have this script yet in ~auto-build/ ... It seems it doesn't
> > work if I just download it to any place along with its whole folder, but
> I
> > cannot run it from the main run-automated-builder script either, because
> > rsync cannot reach the server.
>
> you need to get them from SVN:
>
> cd ~/auto-build/pd-extended/scripts
> svn up
> cd ..
> svn up
>

That did the trick!
The script itself didn't succeed at the first run but the third run
completed clean.
And it deletes the file at the end so I needed to copy it before it
finished :o)


>
> The rsync method is gone for now, and perhaps permanently.  I'm trying
> to see if I can make the cleaning process work without rsync.
>
> >
> >> (the -uc -us) means ignore the whole signing procedure, including the
> >> name in the debian/changelog)
> >
> >> Also, its great that you are taking on the spec file for RPMs!  Once you
> > get 'puredata' working, then it would be very handy if you could make
> >> one for the externals/template.  Then it'll be easy to make RPMs for
> >> most of the libraries in Pd-extended, just like what's in Debian.
> >>
> >> I've never made RPMs before, but I've done a lot of other packaging, so
> >> I'll help where I can.
> >>
> > Well, the deb thing is stuck at this line now:
> >
> >> dpkg-source: error: unrecognized file for a v1.0 source package:
> >> Pd-0.42.5-extended.tar.gz

Re: [PD] array size (was Re: arraysize)

[Cyrille Henry]

hello,

i'm very concern about compatibility, but on the other hand :
- if you include a list_lenght in pd, lot's of people abstraction may have the 
same name, but chances are that they all do the same, and that patch will not 
be broken.
- one still can use it's abstraction with 
myabstraction_folder/myabstraction_name, a shell script can easily fix that
- compatibility should not prevent a software improvement. i've got the 
impression that in Max/MSP, most object could be simpler if compatibility with 
30 years old version was abandoned.

so, if you introduce lot's of new objects, i'll be very happy, even if it break 
my patch.

cheers
cyrille

Le 28/09/2012 17:23, Miller Puckette a écrit :

Well, I'm persuadable on this front.  I'm concerned with unduly hogging
the object namespace - in general, every time I add an object name I
potentially introduce incompatiblities with someone's abstraction that
might have the same name.  And there are 50 or so new classes (!) to provide.
I don't even have a list yet (no pun intended)

cheers
M

On Fri, Sep 28, 2012 at 10:01:40AM -0400, Hans-Christoph Steiner wrote:

On 09/28/2012 04:00 AM, IOhannes m zmölnig wrote:

On 09/28/2012 02:01 AM, Miller Puckette wrote:

Hmm... I agree there's bad confusion between array and table in Pd
nomenclature.  I've tried to use "table" for a specifically floating-point
array, and "array" for the more general thing, but I think I've been
less than consistent (case in point, the "array" menu which creates what
I would call a "table".

One idea might be to use the name [tab] instead of [array], as in
[tab size] - then [tabwrite] could get a synonym, [tab write], etc.


i'm quite with hans here: what exactly do we gain from having an object
[tab write], instead of [tabwrite]?
and i totally fail to see how [tab size] is superior to [tabsize].

in terms of remembering the names, they see quite on par;
it is made clear that those objects belong to the same family regardless
of whether the prefix is "tab" "tab " or "tab_", as long as there is a
common short prefix;
in terms of typing there is one more character to type;
and from the implementation side, it needlessly compilates the
object-lookup mechanism, as can be seen in the current implementation of
the "list" family of objects (where the objectcreator is made aware of
an object named "list\ size", but this object is practically never
requested from the objectmaker, and instead the constructor function of
"list" has to re-implement the dispatching.

it's not that "foo bar" is bad by itself; i just don't see that it is
anywhere better than what we already have.

And to hammer on this point some more, this subcommand syntax
complicates the implementation, as IOhannes points out, and complicates
the syntax.  Its very nice to be able to say "Pd syntax is like
sentences where the first word is the command and the rest of the words
are data for that command."  For all the newbies that I have taught from
all sorts of realms, from 10 year olds to practicing architects, this is
something that has really quickly clicked with basically everyone.  In
my intro teaching, I avoid [list] for exactly this reason, because I'd
have to explain the exception to this simple "first word is the command"
rule, and some people are always confused by it.

And from an advanced users point of view, the simpler the rules of the
syntax are, the brain space is taken up managing all of the exceptions
to nice, simple rules.  And that means less brain space for far more
interesting things.

.hc

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


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



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

Re: [PD] array size (was Re: arraysize)

[Claude Heiland-Allen]

On 28/09/12 16:23, Miller Puckette wrote:

Well, I'm persuadable on this front.  I'm concerned with unduly hogging
the object namespace - in general, every time I add an object name I
potentially introduce incompatiblities with someone's abstraction that
might have the same name.  And there are 50 or so new classes (!) to provide.
I don't even have a list yet (no pun intended)


Perhaps it would be better to refactor the object / abstraction / binary 
/ loading / namespace mechanism first, something along the lines of an 
old discussion I had with HCS:


http://claudiusmaximus.goto10.org/cm/2010-07-16_pure-data_libraries_conversation.html

Once that is fixed to something less baroque/crufty then it should be 
easier for everyone to go nuts and have their own namespaces without 
clobbering or hogging anything, and make patches more portable between 
Pd variants.


I have no time to work on this for the forseeable future, but it's 
something that needs doing sooner rather than later...



cheers
M


Thanks,


Claude
--
http://mathr.co.uk

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

Re: [PD] Stdout, stderr, and vice versa.

[Pierre Massat]

Ok, i'll try this flag.
Thanks!

2012/9/28 Miller Puckette 

> There is a good bit of stuff Pd prints out on stderr (and it shouldn't
> be - it should appear on the "Pd window" - I've started painfully moving
> the messages over for 0.44 but it will be a while before I find them all.
> Meanwhile, from a terminal window, you can type "pd -stderr" and everything
> will come out on the terminal together.
>
> cheers
> M
>
> On Fri, Sep 28, 2012 at 04:35:42PM +0200, Pierre Massat wrote:
> > Hey List,
> >
> > I studied a very good book about the linux command line this summer, and
> > it's changed my life (opened a few doors, at least. Get it here :
> >
> http://ignum.dl.sourceforge.net/project/linuxcommand/TLCL/09.12/TLCL-09.12.pdf
> ).
> >
> > Anyways, I would like to know where i could find information on Pd's
> stdout
> > and stderr.
> > In particular, i would like to intercept closing of audio and plain crash
> > of Pd (the former at least).
> > Is it always output in the main window ? Is there something easier to
> read
> > for a machine when the audio goes off than "Audio stuck, closing
> audio..."
> > ?
> >
> > Cheers,
> >
> > Pierre.
>
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Stdout, stderr, and vice versa.

[Miller Puckette]

There is a good bit of stuff Pd prints out on stderr (and it shouldn't
be - it should appear on the "Pd window" - I've started painfully moving
the messages over for 0.44 but it will be a while before I find them all.
Meanwhile, from a terminal window, you can type "pd -stderr" and everything
will come out on the terminal together.

cheers
M

On Fri, Sep 28, 2012 at 04:35:42PM +0200, Pierre Massat wrote:
> Hey List,
> 
> I studied a very good book about the linux command line this summer, and
> it's changed my life (opened a few doors, at least. Get it here :
> http://ignum.dl.sourceforge.net/project/linuxcommand/TLCL/09.12/TLCL-09.12.pdf).
> 
> Anyways, I would like to know where i could find information on Pd's stdout
> and stderr.
> In particular, i would like to intercept closing of audio and plain crash
> of Pd (the former at least).
> Is it always output in the main window ? Is there something easier to read
> for a machine when the audio goes off than "Audio stuck, closing audio..."
> ?
> 
> Cheers,
> 
> Pierre.

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


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

Re: [PD] debugging sporadic hangs at startup

[Miller Puckette]

The (ridiculous) thing I'd do in this situation would be to save Pd's tcl
output to a file, then run wish from the command line, and in the console
have tcl execute the saved file.

cheers
M
On Fri, Sep 28, 2012 at 10:31:34AM -0400, Hans-Christoph Steiner wrote:
> On 09/28/2012 10:19 AM, Ivica Ico Bukvic wrote:
> >> For an example of that on GNU/Linux, run 'wish'.  You'll see that it
> > launches a
> >> barebones wish window, but you'll also see that wish gives you a prompt.
> >> That's a live prompt where you can edit the currently running program, as
> >> well as get stdout and stderr.  The GNU/Linux code in s_inter.c suppresses
> >> that console entirely so that the 'pd' process doesn't give the same
> > console.
> >
> > I am familiar with wish but am a bit lost by the latter part of this
> > paragraph. How is s_inter.c suppressing console? Can you give an example how
> > this can be fixed? Will a simple redirection to a file work when starting
> > pd-gui?
> >
> 
> If I knew how to fix it, I probably would have already.  The code in
> question is in sys_startgui().
> 
> .hc
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

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

Re: [PD] array size (was Re: arraysize)

[Miller Puckette]

Well, I'm persuadable on this front.  I'm concerned with unduly hogging
the object namespace - in general, every time I add an object name I
potentially introduce incompatiblities with someone's abstraction that
might have the same name.  And there are 50 or so new classes (!) to provide.
I don't even have a list yet (no pun intended)

cheers
M

On Fri, Sep 28, 2012 at 10:01:40AM -0400, Hans-Christoph Steiner wrote:
> On 09/28/2012 04:00 AM, IOhannes m zmölnig wrote:
> > On 09/28/2012 02:01 AM, Miller Puckette wrote:
> >> Hmm... I agree there's bad confusion between array and table in Pd
> >> nomenclature.  I've tried to use "table" for a specifically floating-point
> >> array, and "array" for the more general thing, but I think I've been
> >> less than consistent (case in point, the "array" menu which creates what
> >> I would call a "table".
> >>
> >> One idea might be to use the name [tab] instead of [array], as in 
> >> [tab size] - then [tabwrite] could get a synonym, [tab write], etc.
> >>
> > i'm quite with hans here: what exactly do we gain from having an object
> > [tab write], instead of [tabwrite]?
> > and i totally fail to see how [tab size] is superior to [tabsize].
> >
> > in terms of remembering the names, they see quite on par;
> > it is made clear that those objects belong to the same family regardless
> > of whether the prefix is "tab" "tab " or "tab_", as long as there is a
> > common short prefix;
> > in terms of typing there is one more character to type;
> > and from the implementation side, it needlessly compilates the
> > object-lookup mechanism, as can be seen in the current implementation of
> > the "list" family of objects (where the objectcreator is made aware of
> > an object named "list\ size", but this object is practically never
> > requested from the objectmaker, and instead the constructor function of
> > "list" has to re-implement the dispatching.
> >
> > it's not that "foo bar" is bad by itself; i just don't see that it is
> > anywhere better than what we already have.
> And to hammer on this point some more, this subcommand syntax
> complicates the implementation, as IOhannes points out, and complicates
> the syntax.  Its very nice to be able to say "Pd syntax is like
> sentences where the first word is the command and the rest of the words
> are data for that command."  For all the newbies that I have taught from
> all sorts of realms, from 10 year olds to practicing architects, this is
> something that has really quickly clicked with basically everyone.  In
> my intro teaching, I avoid [list] for exactly this reason, because I'd
> have to explain the exception to this simple "first word is the command"
> rule, and some people are always confused by it.
> 
> And from an advanced users point of view, the simpler the rules of the
> syntax are, the brain space is taken up managing all of the exceptions
> to nice, simple rules.  And that means less brain space for far more
> interesting things.
> 
> .hc
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

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

[PD] Stdout, stderr, and vice versa.

[Pierre Massat]

Hey List,

I studied a very good book about the linux command line this summer, and
it's changed my life (opened a few doors, at least. Get it here :
http://ignum.dl.sourceforge.net/project/linuxcommand/TLCL/09.12/TLCL-09.12.pdf).

Anyways, I would like to know where i could find information on Pd's stdout
and stderr.
In particular, i would like to intercept closing of audio and plain crash
of Pd (the former at least).
Is it always output in the main window ? Is there something easier to read
for a machine when the audio goes off than "Audio stuck, closing audio..."
?

Cheers,

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

Re: [PD] debugging sporadic hangs at startup

[Hans-Christoph Steiner]

On 09/28/2012 10:19 AM, Ivica Ico Bukvic wrote:
>> For an example of that on GNU/Linux, run 'wish'.  You'll see that it
> launches a
>> barebones wish window, but you'll also see that wish gives you a prompt.
>> That's a live prompt where you can edit the currently running program, as
>> well as get stdout and stderr.  The GNU/Linux code in s_inter.c suppresses
>> that console entirely so that the 'pd' process doesn't give the same
> console.
>
> I am familiar with wish but am a bit lost by the latter part of this
> paragraph. How is s_inter.c suppressing console? Can you give an example how
> this can be fixed? Will a simple redirection to a file work when starting
> pd-gui?
>

If I knew how to fix it, I probably would have already.  The code in
question is in sys_startgui().

.hc

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

Re: [PD] debugging sporadic hangs at startup

[Ivica Ico Bukvic]

> For an example of that on GNU/Linux, run 'wish'.  You'll see that it
launches a
> barebones wish window, but you'll also see that wish gives you a prompt.
> That's a live prompt where you can edit the currently running program, as
> well as get stdout and stderr.  The GNU/Linux code in s_inter.c suppresses
> that console entirely so that the 'pd' process doesn't give the same
console.

I am familiar with wish but am a bit lost by the latter part of this
paragraph. How is s_inter.c suppressing console? Can you give an example how
this can be fixed? Will a simple redirection to a file work when starting
pd-gui?


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

Re: [PD] debugging sporadic hangs at startup

[Hans-Christoph Steiner]

This might be a good opportunity to rewrite some parts of the s_inter.c
mess.  I did this kind of debugging on Mac OS X simply because the way
s_inter.c handles the Tcl process means that you can run the Tcl
console, which is incredibly valuable for debugging the GUI.

For an example of that on GNU/Linux, run 'wish'.  You'll see that it
launches a barebones wish window, but you'll also see that wish gives
you a prompt.  That's a live prompt where you can edit the currently
running program, as well as get stdout and stderr.  The GNU/Linux code
in s_inter.c suppresses that console entirely so that the 'pd' process
doesn't give the same console.

The Mac OS X Wish.app handles this nicely making this issue easy: it
provides a default menu bar with an option to launch the console in its
own window, or that is launchable with the command "console show":
http://www.tcl.tk/man/tcl8.5/TkCmd/console.htm

It would be nice to be able to do this on other platforms besides Mac OS
X.  That will require changes in how s_inter.c starts the wish process,
I think.  Perhaps there could be a -tclconsole command line flag to
enable it.

.hc

On 09/28/2012 09:27 AM, Ivica Ico Bukvic wrote:
> So, this does not catch any of the tcl errors (or perhaps none were
> generated). Short of rewriting how messages are broadcast, is there an easy
> and global way of redirecting all tcl output errors to a file? I read about
> interp bgerror, but am not sure if this will catch networked stuff (which is
> the likely offender here) or even work at all...
>
> Similarly, I am wondering if a part of the problem is the 2 size limit
> on the networked data buffer (CHUNKSIZE in t_tkcmd.c) in that during the
> startup because atom cpu is getting swamped perhaps it does not have enough
> time to catch-up with queued networked messages being spewed out of C code
> over the socket and then drops some stuff and hence the non-functioning gui?
> If so, another possible offender would be INBUFSIZE in s_inter.c that deals
> with messages coming from the pd-gui...
>
> Any thoughts?
>
>> -Original Message-
>> From: Miller Puckette [mailto:m...@ucsd.edu]
>> Sent: Thursday, September 27, 2012 1:34 PM
>> To: Ivica Ico Bukvic
>> Cc: pd-list@iem.at
>> Subject: Re: [PD] debugging sporadic hangs at startup
>>
>> I've never done this but perhaps it would work to edit the line in
>> pd-gui.tcl:
>>
>> exec -- $pd_exec -guiport $::port &
>>
>> to:
>>
>> exec -- $pd_exec -guiport $::port -d 1 >& /tmp/foo &
>>
>> (not sure if '>&" or '2>' depending on shell).
>>
>> cheers
>> Miller
>>
>> On Thu, Sep 27, 2012 at 01:23:23PM -0400, Ivica Ico Bukvic wrote:
>>> This is actually on Linux.
>>>
>>> The problem is likely not in C, since program does start up and
>>> creates the main Pd window and then hangs during loading of the patch
>>> (the patch window is created but canvas remains empty and after that
>>> nothing responds any more). It seems to me this is probably because at
>>> some point messages sent to tcl/tk over network (from C) get mangled
>>> after which gui stops responding. I had issues like these before with
>>> network externals and solved them, but this is the one that I had a
>>> hard time weeding out since it is so sporadic. For this reason, I
>>> would like to somehow output all  tcl/tk commands that were sent to
>>> gui. Any way to do this and send it to a separate log file without
> opening a
>> terminal?
 -Original Message-
 From: Miller Puckette [mailto:m...@ucsd.edu]
 Sent: Thursday, September 27, 2012 12:27 PM
 To: Ivica Ico Bukvic
 Cc: pd-list@iem.at
 Subject: Re: [PD] debugging sporadic hangs at startup

 On Macintosh I presume...

 Maybe you can use gdb to 'attach' to the running Pd process,
 assuming it
>>> at
 least gets started up (which I assume it must have in order to start
>>> loading
 the patch).

 cheers
 Miller

 On Thu, Sep 27, 2012 at 12:22:57PM -0400, Ivica Ico Bukvic wrote:
> All,
>
>
>
> I am noticing sporadic GUI freezes when loading complex patches on
 startup.
> How would one go about debugging this when most of such startups
> happen by clicking on the app icon (so no access to gdb or console).
> Short of changing the app icon to make everyone's apps always
> start with gdb, is there a way to redirect debugging output to a
> file?
>
>
> On a related matter, any other users noticed these ocassional
> hangs when loading a complex patch (the window opens but remains
> blank and clicking on any options in the menu does nothing)?
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___

Re: [PD] array size (was Re: arraysize)

[Hans-Christoph Steiner]

On 09/28/2012 04:00 AM, IOhannes m zmölnig wrote:
> On 09/28/2012 02:01 AM, Miller Puckette wrote:
>> Hmm... I agree there's bad confusion between array and table in Pd
>> nomenclature.  I've tried to use "table" for a specifically floating-point
>> array, and "array" for the more general thing, but I think I've been
>> less than consistent (case in point, the "array" menu which creates what
>> I would call a "table".
>>
>> One idea might be to use the name [tab] instead of [array], as in 
>> [tab size] - then [tabwrite] could get a synonym, [tab write], etc.
>>
> i'm quite with hans here: what exactly do we gain from having an object
> [tab write], instead of [tabwrite]?
> and i totally fail to see how [tab size] is superior to [tabsize].
>
> in terms of remembering the names, they see quite on par;
> it is made clear that those objects belong to the same family regardless
> of whether the prefix is "tab" "tab " or "tab_", as long as there is a
> common short prefix;
> in terms of typing there is one more character to type;
> and from the implementation side, it needlessly compilates the
> object-lookup mechanism, as can be seen in the current implementation of
> the "list" family of objects (where the objectcreator is made aware of
> an object named "list\ size", but this object is practically never
> requested from the objectmaker, and instead the constructor function of
> "list" has to re-implement the dispatching.
>
> it's not that "foo bar" is bad by itself; i just don't see that it is
> anywhere better than what we already have.
And to hammer on this point some more, this subcommand syntax
complicates the implementation, as IOhannes points out, and complicates
the syntax.  Its very nice to be able to say "Pd syntax is like
sentences where the first word is the command and the rest of the words
are data for that command."  For all the newbies that I have taught from
all sorts of realms, from 10 year olds to practicing architects, this is
something that has really quickly clicked with basically everyone.  In
my intro teaching, I avoid [list] for exactly this reason, because I'd
have to explain the exception to this simple "first word is the command"
rule, and some people are always confused by it.

And from an advanced users point of view, the simpler the rules of the
syntax are, the brain space is taken up managing all of the exceptions
to nice, simple rules.  And that means less brain space for far more
interesting things.

.hc

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

Re: [PD] Font usage in vanilla

[Julian Brooks]

Ok, bugger.

Ah well, will have to put my pedantic aestheticism to one side for now.

Possible future feature request?

Cheers IOhannes,

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

Re: [PD] Font usage in vanilla

[IOhannes m zmölnig]

On 09/28/2012 01:55 PM, Julian Brooks wrote:
> Hey all,
> 
> I'm kinda stuck...
> 
> I want to add a font (linux-libertine) for use in Pd vanilla,
> specifically for use with [cnv], and I'm not sure how to add it in.
> 

afair, all the iemguis have hardcoded fonts which cannot be changed in a
simple way.

fgmasdr
IOhannes

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

Re: [PD] debugging sporadic hangs at startup

[Ivica Ico Bukvic]

So, this does not catch any of the tcl errors (or perhaps none were
generated). Short of rewriting how messages are broadcast, is there an easy
and global way of redirecting all tcl output errors to a file? I read about
interp bgerror, but am not sure if this will catch networked stuff (which is
the likely offender here) or even work at all...

Similarly, I am wondering if a part of the problem is the 2 size limit
on the networked data buffer (CHUNKSIZE in t_tkcmd.c) in that during the
startup because atom cpu is getting swamped perhaps it does not have enough
time to catch-up with queued networked messages being spewed out of C code
over the socket and then drops some stuff and hence the non-functioning gui?
If so, another possible offender would be INBUFSIZE in s_inter.c that deals
with messages coming from the pd-gui...

Any thoughts?

> -Original Message-
> From: Miller Puckette [mailto:m...@ucsd.edu]
> Sent: Thursday, September 27, 2012 1:34 PM
> To: Ivica Ico Bukvic
> Cc: pd-list@iem.at
> Subject: Re: [PD] debugging sporadic hangs at startup
> 
> I've never done this but perhaps it would work to edit the line in
> pd-gui.tcl:
> 
> exec -- $pd_exec -guiport $::port &
> 
> to:
> 
> exec -- $pd_exec -guiport $::port -d 1 >& /tmp/foo &
> 
> (not sure if '>&" or '2>' depending on shell).
> 
> cheers
> Miller
> 
> On Thu, Sep 27, 2012 at 01:23:23PM -0400, Ivica Ico Bukvic wrote:
> > This is actually on Linux.
> >
> > The problem is likely not in C, since program does start up and
> > creates the main Pd window and then hangs during loading of the patch
> > (the patch window is created but canvas remains empty and after that
> > nothing responds any more). It seems to me this is probably because at
> > some point messages sent to tcl/tk over network (from C) get mangled
> > after which gui stops responding. I had issues like these before with
> > network externals and solved them, but this is the one that I had a
> > hard time weeding out since it is so sporadic. For this reason, I
> > would like to somehow output all  tcl/tk commands that were sent to
> > gui. Any way to do this and send it to a separate log file without
opening a
> terminal?
> >
> > > -Original Message-
> > > From: Miller Puckette [mailto:m...@ucsd.edu]
> > > Sent: Thursday, September 27, 2012 12:27 PM
> > > To: Ivica Ico Bukvic
> > > Cc: pd-list@iem.at
> > > Subject: Re: [PD] debugging sporadic hangs at startup
> > >
> > > On Macintosh I presume...
> > >
> > > Maybe you can use gdb to 'attach' to the running Pd process,
> > > assuming it
> > at
> > > least gets started up (which I assume it must have in order to start
> > loading
> > > the patch).
> > >
> > > cheers
> > > Miller
> > >
> > > On Thu, Sep 27, 2012 at 12:22:57PM -0400, Ivica Ico Bukvic wrote:
> > > > All,
> > > >
> > > >
> > > >
> > > > I am noticing sporadic GUI freezes when loading complex patches on
> > > startup.
> > > > How would one go about debugging this when most of such startups
> > > > happen by clicking on the app icon (so no access to gdb or console).
> > > > Short of changing the app icon to make everyone's apps always
> > > > start with gdb, is there a way to redirect debugging output to a
file?
> > > >
> > > >
> > > >
> > > > On a related matter, any other users noticed these ocassional
> > > > hangs when loading a complex patch (the window opens but remains
> > > > blank and clicking on any options in the menu does nothing)?
> > > >
> > >
> > > > ___
> > > > Pd-list@iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> > > > http://lists.puredata.info/listinfo/pd-list
> >


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

[PD] Font usage in vanilla

[Julian Brooks]

Hey all,

I'm kinda stuck...

I want to add a font (linux-libertine) for use in Pd vanilla, specifically
for use with [cnv], and I'm not sure how to add it in.

I've done this:

julian@brooks:~/Desktop$ fc-match mono
//suggested from here:
http://puredata.info/docs/faq/faqsection_view?section=Problems%20and%20Fixes
which gives this
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

Which seems to be saying there's only one font available?!? Whereas I know
this isn't the case as I can access 3 different fonts from within [cnv]
already.

I've also added the startup flag:
-font-face "Libertine(and other such name variations)" where pd then seems
to be looking for a 'Mono' folder?  There wasn't one anywhere and after
making one and putting the font inside still no joy.

Pah - very confused.

Noticeably in the notes for the most recent Libertine they have added a
mono version so I'm presuming (dangerously) that "LinLibertine_M.otf" (no
M_ttf available from sourceforge) is the one I'm after.

So a few questions here I guess:
1. How can I change vanillas font
2. How and where does Pd do that
3. Does it have to be a mono .ttf
4. Can I see a list of available fonts
5. Anyone else making use of the lovely looking Libertine font?

Pd 0.43.2 - Debian Sid/Wheezy

Many thanks in advance,

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

Re: [PD] arraysize WAS apt.puredata.info is back!

[Simon Wise]

On 28/09/12 12:48, Jonathan Wilkes wrote:


  I'm referring to what Hans wrote:

  For me, apt-get install pd-arraysize is far easier than trying to

   remember that [expr] trick.  And thankfully we can write externals,
   so we can have choice. :-)


exactly ...


Not exactly-- you were referring to using the Debian packaging
system in a general sense to find packages, and you were saying that
calling someone who uses it a mythical user is not inaccurate.


no .. I was saying that debian users who treat their debian repository as an 
extension of their system and the first place to look for something they need to 
do are not mythical at all, that if you are familiar with the debian tools it is 
very quick and easy to find which package has a file or functionality you are 
looking for, and that not surprisingly some of these users are able and willing 
to do the extra bit of work to make things they find useful available in the way 
they find convenient.


If some debian users find it convenient then it isn't obsolete and shouldn't be 
deprecated unless the maintainer is tired of keeping it there or it is becoming 
incompatible with other things in that system.


A huge number of non-debian users also benefit from the work done in debian 
maintaining dependency information, documenting licensing and building for a 
variety of hardware platforms ... they benefit via developers using that 
information to set up the systems that are widely used. A few extra bits and 
pieces that are mainly useful to a few debian users isn't a problem.



Simon

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

[PD] Changing camera position in GEM with buffer set to 1

[Antonio Roberts]

Is it possible to change the position of the camera in GEM when the
buffer is set to 1?

In my initial tests I've only been able to do this when I also send a
bang to the GEM window. Even the [camera] object doesn't allow me to
update the view

Thanks

Antonio

-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

Re: [PD] The HISSTools Impulse Response Toolbox: Convolution for the Masses. Call for port to Pd from Max

[Julian Brooks]

P.S. Of course it doesn't 'have' to be GEM but I guess that's the obvious
initial thought.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] The HISSTools Impulse Response Toolbox: Convolution for the Masses. Call for port to Pd from Max

[Julian Brooks]

Excellent start - hey Katja, good to hear from you.

Yes indeed, my brief look at the patches suggests the graphics will be
tricky and I presume not very native to Pd, we are going to require someone
with decent GEM skills methinks (anyone up for that?).  Agreed too that for
live performance they sound really interesting - ripe for subversion.

Cheers,

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

[PD] array size (was Re: arraysize)

[IOhannes m zmölnig]

On 09/28/2012 02:01 AM, Miller Puckette wrote:
> Hmm... I agree there's bad confusion between array and table in Pd
> nomenclature.  I've tried to use "table" for a specifically floating-point
> array, and "array" for the more general thing, but I think I've been
> less than consistent (case in point, the "array" menu which creates what
> I would call a "table".
> 
> One idea might be to use the name [tab] instead of [array], as in 
> [tab size] - then [tabwrite] could get a synonym, [tab write], etc.
> 

i'm quite with hans here: what exactly do we gain from having an object
[tab write], instead of [tabwrite]?
and i totally fail to see how [tab size] is superior to [tabsize].

in terms of remembering the names, they see quite on par;
it is made clear that those objects belong to the same family regardless
of whether the prefix is "tab" "tab " or "tab_", as long as there is a
common short prefix;
in terms of typing there is one more character to type;
and from the implementation side, it needlessly compilates the
object-lookup mechanism, as can be seen in the current implementation of
the "list" family of objects (where the objectcreator is made aware of
an object named "list\ size", but this object is practically never
requested from the objectmaker, and instead the constructor function of
"list" has to re-implement the dispatching.

it's not that "foo bar" is bad by itself; i just don't see that it is
anywhere better than what we already have.

fgmasdr
IOhannes

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