From noreply at sourceforge.net  Fri Jul  1 06:42:13 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 01 Jul 2011 04:42:13 +0000
Subject: [PD-dev] [ pure-data-Patches-3348635 ] 6Ab8vo <a
	href="http://eredbuekutjm.com/">eredbuekutjm</a>, 
Message-ID: <mailman.0.1309495366.2522.pd-dev@iem.at>


Patches item #3348635, was opened at 2011-07-01 04:42
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3348635&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 6Ab8vo  <a href="http://eredbuekutjm.com/">eredbuekutjm</a>,

Initial Comment:
6Ab8vo  <a href="http://eredbuekutjm.com/">eredbuekutjm</a>, [url=http://prwkdtygxldi.com/]prwkdtygxldi[/url], [link=http://kgrhbjcqwcke.com/]kgrhbjcqwcke[/link], http://mjlkhqmjgvcx.com/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3348635&group_id=55736


From colet.patrice at free.fr  Fri Jul  1 08:40:07 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Fri, 1 Jul 2011 08:40:07 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <C02E16EC-BC02-4BDF-9618-E7DEF64A4403@at.or.at>
Message-ID: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> Yeah, that's a annoyance of that build system.  I think you need to  
> make sure your source dir is called 'pd', not something like 'pure- 
> data' or 'pure-data.git'.  We really should finalize the configure.ac 
> 
> and Makefile.am for MinGW.  Its quite close.  I think someone just  
> needs to figure out how to do the final linking using g++ to link the
> C 
> ++ ASIO files and C files from the rest.
> 

why not using cc for compiling portaudio files, or what's the magic trick for this:

libtool: compile:  g++ -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" -DPACKAGE_VERSION=\"0.43.0\" "-DPACKAGE_STRING=\"pd 0.43.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"pd\" -DVERSION=\"0.43.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DSTDC_HEADERS=1 -DHAVE_ALLOCA=1 -DHAVE_UNISTD_H=1 -I. -Iinclude -Isrc/common -Isrc/os/win -DPA_NO_ASIO -c -DPD_INTERNAL -DMSW -D_WIN32 -DPA_NO_DS -DUSEAPI_MMIO -DUSEAPI_PORTAUDIO -DPA19 -DPA_LITTLE_ENDIAN -mms-bitfields -O6 -funroll-loops -fomit-frame-pointer -MT libportaudio_la-pa_win_wmme.lo -MD -MP -MF .deps/libportaudio_la-pa_win_wmme.Tpo -c src/hostapi/wmme/pa_win_wmme.c  -DDLL_EXPORT -DPIC -o .libs/libportaudio_la-pa_win_wmme.o
src/hostapi/wmme/pa_win_wmme.c: In function `PaError PaWinMme_Initialize(PaUtilHostApiRepresentation**, PaHostApiIndex)':
src/hostapi/wmme/pa_win_wmme.c:942: warning: converting of negative value `-0x000000001' to `DWORD'
src/hostapi/wmme/pa_win_wmme.c:946: warning: converting of negative value `-0x000000001' to `DWORD'
src/hostapi/wmme/pa_win_wmme.c: In function `PaError IsFormatSupported(PaUtilHostApiRepresentation*, const PaStreamParameters*, const PaStreamParameters*, double)':
src/hostapi/wmme/pa_win_wmme.c:1179: error: invalid conversion from `void* const' to `PaWinMmeStreamInfo*'
src/hostapi/wmme/pa_win_wmme.c:1243: error: invalid conversion from `void* const' to `PaWinMmeStreamInfo*'
src/hostapi/wmme/pa_win_wmme.c: In function `PaError StartStream(PaStream*)':
src/hostapi/wmme/pa_win_wmme.c:3314: error: invalid conversion from `DWORD (*)(void*)' to `unsigned int (*)(void*)'
src/hostapi/wmme/pa_win_wmme.c:3314: error:   initializing argument 3 of `long unsigned int _beginthreadex(void*, unsigned int, unsigned int (*)(void*), void*, unsigned int, unsigned int*)'
src/hostapi/wmme/pa_win_wmme.c:3314: error: invalid conversion from `DWORD*' to `unsigned int*'
src/hostapi/wmme/pa_win_wmme.c:3314: error:   initializing argument 6 of `long unsigned int _beginthreadex(void*, unsigned int, unsigned int (*)(void*), void*, unsigned int, unsigned int*)'
make[2]: *** [libportaudio_la-pa_win_wmme.lo] Error 1
make[2]: Leaving directory `/home/patko/pd-extended/0.43/pd/portaudio'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/patko/pd-extended/0.43/pd'
make: *** [all] Error 2


?

> .hc
> 
> On Jun 29, 2011, at 4:38 PM, Patrice Colet wrote:
> 
> > hello, I've been trying to comile pd-vanilla with makefile.mingw
> > but something weird is happening,
> >
> > the file in makefile.dependencies aren't compiled, I could figure  
> > out why.
> >
> >
> > ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
> >
> >> Ok, it was a weird one, I think its fixed, please try it and let
> me
> >> know.
> >>
> >> .hc
> >>
> >> On Sun, 19 Jun 2011 23:51 +0100, "Tris Whyte"
> <slippycurb at yahoo.com>
> >> wrote:
> >>> damn i wish i could code, maybe i should try and build it on
> vista,
> >>
> >>> have successfully built it on linux before, i would just use the
> >> linux
> >>> version
> >>> but i use a lot of vsts and swapping between two O.Ss can be a
> bit
> >>> tiresome.
> >>> (kid on the way? somone has been doing the dirty!! congrats
> man:-)
> >>>
> >>> thank you
> >>> _______________________________________________
> >>> Pd-dev mailing list
> >>> Pd-dev at iem.at
> >>> http://lists.puredata.info/listinfo/pd-dev
> >>>
> >>
> >> _______________________________________________
> >> Pd-dev mailing list
> >> Pd-dev at iem.at
> >> http://lists.puredata.info/listinfo/pd-dev
> >
> > -- 
> > Patrice Colet
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Mistrust authority - promote decentralization.  - the hacker ethic

-- 
Patrice Colet 


From zmoelnig at iem.at  Fri Jul  1 11:08:20 2011
From: zmoelnig at iem.at (=?UTF-8?B?SU9oYW5uZXMgbSB6bcO2bG5pZw==?=)
Date: Fri, 01 Jul 2011 11:08:20 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <4E0D8E84.5010505@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/2011 08:40 AM, Patrice Colet wrote:
> 
>> needs to figure out how to do the final linking using g++ to link the
>> C 
>> ++ ASIO files and C files from the rest.
>>
> 
> why not using cc for compiling portaudio files, 

because you need a c++ compiler to compile c++ code.

and you need a c++ linker to link with c++ objects (such as the
portaudio objects)
the trick to use g++ for linking, is to use a dummy .cpp file, so
autotools will automatically choose g++.

something like:
<snip>
nodist_EXTRA_pd_SOURCES=
if PORTAUDIO
nodist_EXTRA_pd_SOURCES += dummy.cpp
endif
</snip>

fgmsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4NjoEACgkQkX2Xpv6ydvTuOACdFHGNF2qVQz+TbvgjXDHSisjH
YHQAnjK/SViMF1aXY51Bi59UmgezhFxR
=u+vA
-----END PGP SIGNATURE-----


From hans at at.or.at  Fri Jul  1 18:24:27 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 01 Jul 2011 12:24:27 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <4E0D8E84.5010505@iem.at>
References: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<4E0D8E84.5010505@iem.at>
Message-ID: <1309537467.8902.1469387881@webmail.messagingengine.com>


On Fri, 01 Jul 2011 11:08 +0200, "IOhannes m zm?lnig" <zmoelnig at iem.at>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/01/2011 08:40 AM, Patrice Colet wrote:
> > 
> >> needs to figure out how to do the final linking using g++ to link the
> >> C 
> >> ++ ASIO files and C files from the rest.
> >>
> > 
> > why not using cc for compiling portaudio files, 
> 
> because you need a c++ compiler to compile c++ code.
> 
> and you need a c++ linker to link with c++ objects (such as the
> portaudio objects)

> the trick to use g++ for linking, is to use a dummy .cpp file, so
> autotools will automatically choose g++.
> 
> something like:
> <snip>
> nodist_EXTRA_pd_SOURCES=
> if PORTAUDIO
> nodist_EXTRA_pd_SOURCES += dummy.cpp
> endif
> </snip>

It would be worth trying:

LD=$CXX

It might be more complicated than that, but the makefile.mingw seems to
disprove this:

- You must use your C++ compiler when compiling main() (e.g., for static
initialization)
- Your C++ compiler should direct the linking process (e.g., so it can
get its special libraries)

Other potentially useful info here:
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

.hc


From zmoelnig at iem.at  Fri Jul  1 19:36:58 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Fri, 01 Jul 2011 19:36:58 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1309537467.8902.1469387881@webmail.messagingengine.com>
References: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>	<4E0D8E84.5010505@iem.at>
	<1309537467.8902.1469387881@webmail.messagingengine.com>
Message-ID: <4E0E05BA.8000607@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> 
>> the trick to use g++ for linking, is to use a dummy .cpp file, so
>> autotools will automatically choose g++.
>>
>> something like:
>> <snip>
>> nodist_EXTRA_pd_SOURCES=
>> if PORTAUDIO
>> nodist_EXTRA_pd_SOURCES += dummy.cpp
>> endif
>> </snip>
> 
> It would be worth trying:
> 
> LD=$CXX
> 

http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries

mfsadr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4OBbcACgkQkX2Xpv6ydvSowgCfTO8F4qYjR++MoL3UfLCaQ7wA
8VIAn2awJvaQmTXsObzcPIwQT5oqXZCe
=ObFC
-----END PGP SIGNATURE-----


From noreply at sourceforge.net  Fri Jul  1 20:23:04 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 01 Jul 2011 14:23:04 -0400
Subject: [PD-dev] [ pure-data-Patches-3336039 ] fix Windows non-starting
Message-ID: <mailman.2.1309544598.2522.pd-dev@iem.at>


Patches item #3336039, was opened at 2011-06-26 23:11
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: puredata
Group: None
>Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix Windows non-starting

Initial Comment:
Removed bizarre 'k' character in 'package' command, causing Windows to not start.  This was in the proc get_config_win in tcl/pd_guiprefs.tcl.  My smallest patch ever, literally changing one character ;)


----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 14:23

Message:
Martin Peach found another ? in pd_guiprefs.tcl, the updated patch fixes
it.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 14:21

Message:
This artifact has been marked as a duplicate of artifact 3307680 with
reason:
separate patch tracker item

----------------------------------------------------------------------

Comment By: Yvan Volochine (elgusanorojo)
Date: 2011-06-27 06:34

Message:
oops, my mistake (k with an accent), thanks for spotting.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736


From hans at at.or.at  Fri Jul  1 20:58:55 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 01 Jul 2011 14:58:55 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <4E0E05BA.8000607@iem.at>
References: <1307336088.17821309502406959.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<4E0D8E84.5010505@iem.at><1309537467.8902.1469387881@webmail.messagingengine.com>
	<4E0E05BA.8000607@iem.at>
Message-ID: <1309546735.19921.1469434665@webmail.messagingengine.com>


On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig" <zmoelnig at iem.at>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> > 
> >> the trick to use g++ for linking, is to use a dummy .cpp file, so
> >> autotools will automatically choose g++.
> >>
> >> something like:
> >> <snip>
> >> nodist_EXTRA_pd_SOURCES=
> >> if PORTAUDIO
> >> nodist_EXTRA_pd_SOURCES += dummy.cpp
> >> endif
> >> </snip>
> > 
> > It would be worth trying:
> > 
> > LD=$CXX
> > 
> 
> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries

That solution at the bottom of that page looks easy but a bit odd.  I
suppose its the 'official' way.  Patco, do you think you can try to get
that working?

.hc


From colet.patrice at free.fr  Sat Jul  2 13:01:54 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Sat, 2 Jul 2011 13:01:54 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1177902445.254091309604427334.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <712121709.254271309604514114.JavaMail.root@zimbra4-e1.priv.proxad.net>


I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.

> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
> > On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> > > 
> > >> the trick to use g++ for linking, is to use a dummy .cpp file,
> so
> > >> autotools will automatically choose g++.
> > >>
> > >> something like:
> > >> <snip>
> > >> nodist_EXTRA_pd_SOURCES=
> > >> if PORTAUDIO
> > >> nodist_EXTRA_pd_SOURCES += dummy.cpp
> > >> endif
> > >> </snip>
> > > 
> > > It would be worth trying:
> > > 
> > > LD=$CXX
> > > 
> > 
> >
> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
> 
> That solution at the bottom of that page looks easy but a bit odd.  I
> suppose its the 'official' way.  Patco, do you think you can try to
> get
> that working?
> 
> .hc
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-- 
Patrice Colet 


From noreply at sourceforge.net  Sat Jul  2 17:13:00 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 02 Jul 2011 11:13:00 -0400
Subject: [PD-dev] [ pure-data-Patches-3348635 ] 6Ab8vo <a
	href="http://eredbuekutjm.com/">eredbuekutjm</a>, 
Message-ID: <mailman.5.1309619592.2522.pd-dev@iem.at>


Patches item #3348635, was opened at 2011-07-01 00:42
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3348635&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
>Status: Deleted
>Resolution: Invalid
>Priority: 1
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 6Ab8vo  <a href="http://eredbuekutjm.com/">eredbuekutjm</a>,

Initial Comment:
6Ab8vo  <a href="http://eredbuekutjm.com/">eredbuekutjm</a>, [url=http://prwkdtygxldi.com/]prwkdtygxldi[/url], [link=http://kgrhbjcqwcke.com/]kgrhbjcqwcke[/link], http://mjlkhqmjgvcx.com/

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-02 11:13

Message:
spam

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3348635&group_id=55736


From noreply at sourceforge.net  Sat Jul  2 17:25:43 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 02 Jul 2011 11:25:43 -0400
Subject: [PD-dev] [ pure-data-Patches-1963983 ] use FILENAME_MAX for all
	filenames, since its < MAXPDSTRING
Message-ID: <mailman.6.1309620367.2522.pd-dev@iem.at>


Patches item #1963983, was opened at 2008-05-14 13:36
Message generated for change (Settings changed) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1963983&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Closed
>Resolution: Out of Date
Priority: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
>Assigned to: Nobody/Anonymous (nobody)
Summary: use FILENAME_MAX for all filenames, since its < MAXPDSTRING

Initial Comment:
On Windows, FILENAME_MAX is much smaller than MAXPDSTRING, so I replaced MAXPDSTRING with FILENAME_MAX everywhere I could find that is related to filenames.  FILENAME_MAX is a POSIX standard macro for defining the max length of a complete filename.

The current situation could result in crashes on Windows.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-02 11:25

Message:
this is out of date

----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2010-07-28 20:47

Message:
I'm not sure but I don't think Windows should have trouble trying to open
files with too-long names -- if it's anything near correct it should simply
refuse.  And it's better to have as few POSIX dependencies as possible (Pd
bios, anyone? :)

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-14 13:47

Message:
Logged In: YES 
user_id=27104
Originator: YES

ok, this time really removed all bits of
add_tilde_support_toopen-0.41.4.patch
File Added: use_FILENAME_MAX_for_file_operations-0.41.4.patch

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-14 13:39

Message:
Logged In: YES 
user_id=27104
Originator: YES

oops, removed add_tilde_support_toopen-0.41.4.patch from this one
File Added: use_FILENAME_MAX_for_file_operations-0.41.4.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1963983&group_id=55736


From hans at at.or.at  Sat Jul  2 20:36:50 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Sat, 2 Jul 2011 14:36:50 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <712121709.254271309604514114.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <712121709.254271309604514114.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <E3DEED58-D368-4B2B-9B39-A4BC0550F0BE@at.or.at>


Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any luck  
with the LD=$(CXX) option?

.hc

On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:

>
> I've found the odd part of that page is that they use LTLIBRARIES  
> variable while pd/src/Makefile.am doesn't.
>
>> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
>>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
>>>>
>>>>> the trick to use g++ for linking, is to use a dummy .cpp file,
>> so
>>>>> autotools will automatically choose g++.
>>>>>
>>>>> something like:
>>>>> <snip>
>>>>> nodist_EXTRA_pd_SOURCES=
>>>>> if PORTAUDIO
>>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
>>>>> endif
>>>>> </snip>
>>>>
>>>> It would be worth trying:
>>>>
>>>> LD=$CXX
>>>>
>>>
>>>
>> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
>>
>> That solution at the bottom of that page looks easy but a bit odd.  I
>> suppose its the 'official' way.  Patco, do you think you can try to
>> get
>> that working?
>>
>> .hc
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
> -- 
> Patrice Colet



----------------------------------------------------------------------------

Mistrust authority - promote decentralization.  - the hacker ethic




From colet.patrice at free.fr  Sun Jul  3 09:31:19 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Sun, 3 Jul 2011 09:31:19 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1358923408.337531309678203413.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <1267268697.337711309678279405.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any luck 
> 
> with the LD=$(CXX) option?
> 

Still same error, this is exactly like this one:

http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html

the only solution that is working so far is about using CC to compile portaudio,
I don't know if I could get time to reorg the build system for libtool conveniences.



> .hc
> 
> On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
> 
> >
> > I've found the odd part of that page is that they use LTLIBRARIES  
> > variable while pd/src/Makefile.am doesn't.
> >
> >> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
> >>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> >>>>
> >>>>> the trick to use g++ for linking, is to use a dummy .cpp file,
> >> so
> >>>>> autotools will automatically choose g++.
> >>>>>
> >>>>> something like:
> >>>>> <snip>
> >>>>> nodist_EXTRA_pd_SOURCES=
> >>>>> if PORTAUDIO
> >>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
> >>>>> endif
> >>>>> </snip>
> >>>>
> >>>> It would be worth trying:
> >>>>
> >>>> LD=$CXX
> >>>>
> >>>
> >>>
> >>
> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
> >>
> >> That solution at the bottom of that page looks easy but a bit odd. 
> I
> >> suppose its the 'official' way.  Patco, do you think you can try
> to
> >> get
> >> that working?
> >>
> >> .hc
> >>
> >> _______________________________________________
> >> Pd-dev mailing list
> >> Pd-dev at iem.at
> >> http://lists.puredata.info/listinfo/pd-dev
> >
> > -- 
> > Patrice Colet
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Mistrust authority - promote decentralization.  - the hacker ethic

-- 
Patrice Colet 


From noreply at sourceforge.net  Mon Jul  4 07:24:02 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jul 2011 01:24:02 -0400
Subject: [PD-dev] [ pure-data-Patches-3353285 ] fix crasher bug when closing
	a window with Perf Mode on
Message-ID: <mailman.8.1309757076.2522.pd-dev@iem.at>


Patches item #3353285, was opened at 2011-07-04 01:24
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3353285&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix crasher bug when closing a window with Perf Mode on 

Initial Comment:
fix crasher bug when closing a window with Perf Mode on and no changes to window.  It was using the wrong variable, g, which is null.  I changed it to x and no crash.  Also, I adjusted the dialog to make sense.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3353285&group_id=55736


From hans at at.or.at  Mon Jul  4 20:11:59 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 4 Jul 2011 14:11:59 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1267268697.337711309678279405.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <1267268697.337711309678279405.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <AAA136AA-556E-469D-8C74-E5F2B1A4D26D@at.or.at>


On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:

>
> ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
>
>> Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any luck
>>
>> with the LD=$(CXX) option?
>>
>
> Still same error, this is exactly like this one:
>
> http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
>
> the only solution that is working so far is about using CC to  
> compile portaudio,
> I don't know if I could get time to reorg the build system for  
> libtool conveniences.

I tried changing the "if ASIO" section in pd/Makefile.am to this:

if ASIO
EXTRA_SUBDIRS += asio
# automake hack to force linking with g++
lib_LTLIBRARIES = libdummy.la
libdummy_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
endif

And it did indeed switch to using g++, but for compiling too, and that  
triggers the same issue.  It seems that you can't compile portaudio  
WMME with g++, and the current build system is using g++ by default.  
So I think we actually need the opposite than that solution. If we  
include the ASIO files, automake switches to g++.  So we need to force  
portaudio to always be built using gcc.  Anyone have any ideas there?


.hc

>
>
>
>> .hc
>>
>> On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
>>
>>>
>>> I've found the odd part of that page is that they use LTLIBRARIES
>>> variable while pd/src/Makefile.am doesn't.
>>>
>>>> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
>>>>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>>> the trick to use g++ for linking, is to use a dummy .cpp file,
>>>> so
>>>>>>> autotools will automatically choose g++.
>>>>>>>
>>>>>>> something like:
>>>>>>> <snip>
>>>>>>> nodist_EXTRA_pd_SOURCES=
>>>>>>> if PORTAUDIO
>>>>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
>>>>>>> endif
>>>>>>> </snip>
>>>>>>
>>>>>> It would be worth trying:
>>>>>>
>>>>>> LD=$CXX
>>>>>>
>>>>>
>>>>>
>>>>
>> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
>>>>
>>>> That solution at the bottom of that page looks easy but a bit odd.
>> I
>>>> suppose its the 'official' way.  Patco, do you think you can try
>> to
>>>> get
>>>> that working?
>>>>
>>>> .hc
>>>>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>> -- 
>>> Patrice Colet
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Mistrust authority - promote decentralization.  - the hacker ethic
>
> -- 
> Patrice Colet





----------------------------------------------------------------------------

Programs should be written for people to read, and only incidentally  
for machines to execute.
  - from Structure and Interpretation of Computer Programs



From colet.patrice at free.fr  Tue Jul  5 13:04:40 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Tue, 5 Jul 2011 13:04:40 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <AAA136AA-556E-469D-8C74-E5F2B1A4D26D@at.or.at>
Message-ID: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>

I've removed this in configure.ac:

# ASIO is a C++ library, so if its included, then use g++ to build
CC=g++

compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.

from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.

----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
> 
> >
> > ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
> >
> >> Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any
> luck
> >>
> >> with the LD=$(CXX) option?
> >>
> >
> > Still same error, this is exactly like this one:
> >
> > http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
> >
> > the only solution that is working so far is about using CC to  
> > compile portaudio,
> > I don't know if I could get time to reorg the build system for  
> > libtool conveniences.
> 
> I tried changing the "if ASIO" section in pd/Makefile.am to this:
> 
> if ASIO
> EXTRA_SUBDIRS += asio
> # automake hack to force linking with g++
> lib_LTLIBRARIES = libdummy.la
> libdummy_la_SOURCES =
> # Dummy C++ source to cause C++ linking.
> nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
> endif
> 
> And it did indeed switch to using g++, but for compiling too, and that
>  
> triggers the same issue.  It seems that you can't compile portaudio  
> WMME with g++, and the current build system is using g++ by default. 
> 
> So I think we actually need the opposite than that solution. If we  
> include the ASIO files, automake switches to g++.  So we need to force
>  
> portaudio to always be built using gcc.  Anyone have any ideas there?
> 
> 
> .hc
> 
> >
> >
> >
> >> .hc
> >>
> >> On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
> >>
> >>>
> >>> I've found the odd part of that page is that they use LTLIBRARIES
> >>> variable while pd/src/Makefile.am doesn't.
> >>>
> >>>> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
> >>>>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> >>>>>>
> >>>>>>> the trick to use g++ for linking, is to use a dummy .cpp
> file,
> >>>> so
> >>>>>>> autotools will automatically choose g++.
> >>>>>>>
> >>>>>>> something like:
> >>>>>>> <snip>
> >>>>>>> nodist_EXTRA_pd_SOURCES=
> >>>>>>> if PORTAUDIO
> >>>>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
> >>>>>>> endif
> >>>>>>> </snip>
> >>>>>>
> >>>>>> It would be worth trying:
> >>>>>>
> >>>>>> LD=$CXX
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
> >>>>
> >>>> That solution at the bottom of that page looks easy but a bit
> odd.
> >> I
> >>>> suppose its the 'official' way.  Patco, do you think you can try
> >> to
> >>>> get
> >>>> that working?
> >>>>
> >>>> .hc
> >>>>
> >>>> _______________________________________________
> >>>> Pd-dev mailing list
> >>>> Pd-dev at iem.at
> >>>> http://lists.puredata.info/listinfo/pd-dev
> >>>
> >>> -- 
> >>> Patrice Colet
> >>
> >>
> >>
> >>
> ----------------------------------------------------------------------------
> >>
> >> Mistrust authority - promote decentralization.  - the hacker ethic
> >
> > -- 
> > Patrice Colet
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Programs should be written for people to read, and only incidentally 
> 
> for machines to execute.
>   - from Structure and Interpretation of Computer Programs

-- 
Patrice Colet 


From hans at at.or.at  Tue Jul  5 18:02:48 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Tue, 5 Jul 2011 12:02:48 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <35B705A6-4848-4BDA-9DD2-6F4D915FBA69@at.or.at>


Hmm, that sounds like progress.  Perhaps removing CC=g++ and then  
adding something like this would work:

if ASIO
EXTRA_SUBDIRS += asio
# automake hack to force linking with g++
lib_LTLIBRARIES = libdummy.la
libdummy_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
endif

.hc

On Jul 5, 2011, at 7:04 AM, Patrice Colet wrote:

> I've removed this in configure.ac:
>
> # ASIO is a C++ library, so if its included, then use g++ to build
> CC=g++
>
> compiles fine, only pd.exe is not working but pd.dll is fine,  
> everything is built.
>
> from all I've read in gnu manuals, automake automatically set g++  
> for cpp files so there is no need to set CC.
>
> ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
>
>> On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
>>
>>>
>>> ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
>>>
>>>> Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any
>> luck
>>>>
>>>> with the LD=$(CXX) option?
>>>>
>>>
>>> Still same error, this is exactly like this one:
>>>
>>> http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
>>>
>>> the only solution that is working so far is about using CC to
>>> compile portaudio,
>>> I don't know if I could get time to reorg the build system for
>>> libtool conveniences.
>>
>> I tried changing the "if ASIO" section in pd/Makefile.am to this:
>>
>> if ASIO
>> EXTRA_SUBDIRS += asio
>> # automake hack to force linking with g++
>> lib_LTLIBRARIES = libdummy.la
>> libdummy_la_SOURCES =
>> # Dummy C++ source to cause C++ linking.
>> nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
>> endif
>>
>> And it did indeed switch to using g++, but for compiling too, and  
>> that
>>
>> triggers the same issue.  It seems that you can't compile portaudio
>> WMME with g++, and the current build system is using g++ by default.
>>
>> So I think we actually need the opposite than that solution. If we
>> include the ASIO files, automake switches to g++.  So we need to  
>> force
>>
>> portaudio to always be built using gcc.  Anyone have any ideas there?
>>
>>
>> .hc
>>
>>>
>>>
>>>
>>>> .hc
>>>>
>>>> On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
>>>>
>>>>>
>>>>> I've found the odd part of that page is that they use LTLIBRARIES
>>>>> variable while pd/src/Makefile.am doesn't.
>>>>>
>>>>>> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
>>>>>>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
>>>>>>>>
>>>>>>>>> the trick to use g++ for linking, is to use a dummy .cpp
>> file,
>>>>>> so
>>>>>>>>> autotools will automatically choose g++.
>>>>>>>>>
>>>>>>>>> something like:
>>>>>>>>> <snip>
>>>>>>>>> nodist_EXTRA_pd_SOURCES=
>>>>>>>>> if PORTAUDIO
>>>>>>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
>>>>>>>>> endif
>>>>>>>>> </snip>
>>>>>>>>
>>>>>>>> It would be worth trying:
>>>>>>>>
>>>>>>>> LD=$CXX
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
>>>>>>
>>>>>> That solution at the bottom of that page looks easy but a bit
>> odd.
>>>> I
>>>>>> suppose its the 'official' way.  Patco, do you think you can try
>>>> to
>>>>>> get
>>>>>> that working?
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-dev mailing list
>>>>>> Pd-dev at iem.at
>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>
>>>>> -- 
>>>>> Patrice Colet
>>>>
>>>>
>>>>
>>>>
>> ----------------------------------------------------------------------------
>>>>
>>>> Mistrust authority - promote decentralization.  - the hacker ethic
>>>
>>> -- 
>>> Patrice Colet
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Programs should be written for people to read, and only incidentally
>>
>> for machines to execute.
>>  - from Structure and Interpretation of Computer Programs
>
> -- 
> Patrice Colet





----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own  
government." - Martin Luther King, Jr.





From colet.patrice at free.fr  Tue Jul  5 18:57:29 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Tue, 5 Jul 2011 18:57:29 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <35B705A6-4848-4BDA-9DD2-6F4D915FBA69@at.or.at>
Message-ID: <45861010.853811309885049586.JavaMail.root@zimbra4-e1.priv.proxad.net>

 oopse I didn't see that pd.dll isn't deleted by make clean, if fact it isn't even built, sorry I'll try something else tomorrow.

----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> Hmm, that sounds like progress.  Perhaps removing CC=g++ and then  
> adding something like this would work:
> 
> if ASIO
> EXTRA_SUBDIRS += asio
> # automake hack to force linking with g++
> lib_LTLIBRARIES = libdummy.la
> libdummy_la_SOURCES =
> # Dummy C++ source to cause C++ linking.
> nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
> endif
> 
> .hc
> 
> On Jul 5, 2011, at 7:04 AM, Patrice Colet wrote:
> 
> > I've removed this in configure.ac:
> >
> > # ASIO is a C++ library, so if its included, then use g++ to build
> > CC=g++
> >
> > compiles fine, only pd.exe is not working but pd.dll is fine,  
> > everything is built.
> >
> > from all I've read in gnu manuals, automake automatically set g++  
> > for cpp files so there is no need to set CC.
> >
> > ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
> >
> >> On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote:
> >>
> >>>
> >>> ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
> >>>
> >>>> Ah, right, supporting LTLIBRARIES would be a bigger reorg.  Any
> >> luck
> >>>>
> >>>> with the LD=$(CXX) option?
> >>>>
> >>>
> >>> Still same error, this is exactly like this one:
> >>>
> >>> http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html
> >>>
> >>> the only solution that is working so far is about using CC to
> >>> compile portaudio,
> >>> I don't know if I could get time to reorg the build system for
> >>> libtool conveniences.
> >>
> >> I tried changing the "if ASIO" section in pd/Makefile.am to this:
> >>
> >> if ASIO
> >> EXTRA_SUBDIRS += asio
> >> # automake hack to force linking with g++
> >> lib_LTLIBRARIES = libdummy.la
> >> libdummy_la_SOURCES =
> >> # Dummy C++ source to cause C++ linking.
> >> nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
> >> endif
> >>
> >> And it did indeed switch to using g++, but for compiling too, and 
> 
> >> that
> >>
> >> triggers the same issue.  It seems that you can't compile
> portaudio
> >> WMME with g++, and the current build system is using g++ by
> default.
> >>
> >> So I think we actually need the opposite than that solution. If we
> >> include the ASIO files, automake switches to g++.  So we need to  
> >> force
> >>
> >> portaudio to always be built using gcc.  Anyone have any ideas
> there?
> >>
> >>
> >> .hc
> >>
> >>>
> >>>
> >>>
> >>>> .hc
> >>>>
> >>>> On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote:
> >>>>
> >>>>>
> >>>>> I've found the odd part of that page is that they use
> LTLIBRARIES
> >>>>> variable while pd/src/Makefile.am doesn't.
> >>>>>
> >>>>>> On Fri, 01 Jul 2011 19:36 +0200, "IOhannes m zm?lnig"
> >>>>>>> On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote:
> >>>>>>>>
> >>>>>>>>> the trick to use g++ for linking, is to use a dummy .cpp
> >> file,
> >>>>>> so
> >>>>>>>>> autotools will automatically choose g++.
> >>>>>>>>>
> >>>>>>>>> something like:
> >>>>>>>>> <snip>
> >>>>>>>>> nodist_EXTRA_pd_SOURCES=
> >>>>>>>>> if PORTAUDIO
> >>>>>>>>> nodist_EXTRA_pd_SOURCES += dummy.cpp
> >>>>>>>>> endif
> >>>>>>>>> </snip>
> >>>>>>>>
> >>>>>>>> It would be worth trying:
> >>>>>>>>
> >>>>>>>> LD=$CXX
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries
> >>>>>>
> >>>>>> That solution at the bottom of that page looks easy but a bit
> >> odd.
> >>>> I
> >>>>>> suppose its the 'official' way.  Patco, do you think you can
> try
> >>>> to
> >>>>>> get
> >>>>>> that working?
> >>>>>>
> >>>>>> .hc
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Pd-dev mailing list
> >>>>>> Pd-dev at iem.at
> >>>>>> http://lists.puredata.info/listinfo/pd-dev
> >>>>>
> >>>>> -- 
> >>>>> Patrice Colet
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ----------------------------------------------------------------------------
> >>>>
> >>>> Mistrust authority - promote decentralization.  - the hacker
> ethic
> >>>
> >>> -- 
> >>> Patrice Colet
> >>
> >>
> >>
> >>
> >>
> >>
> ----------------------------------------------------------------------------
> >>
> >> Programs should be written for people to read, and only
> incidentally
> >>
> >> for machines to execute.
> >>  - from Structure and Interpretation of Computer Programs
> >
> > -- 
> > Patrice Colet
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> "[T]he greatest purveyor of violence in the world today [is] my own  
> government." - Martin Luther King, Jr.

-- 
Patrice Colet 


From noreply at sourceforge.net  Thu Jul  7 18:46:29 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 12:46:29 -0400
Subject: [PD-dev] [ pure-data-Patches-3109768 ] [bugfix] gop patch name
	uneditable after disabling gop
Message-ID: <mailman.13.1310057212.2522.pd-dev@iem.at>


Patches item #3109768, was opened at 2010-11-15 16:10
Message generated for change (Comment added) made by jancsika1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3109768&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] gop patch name uneditable after disabling gop

Initial Comment:
Last lingering GOP bug (after all previous GOP bugfixes that I submitted have been applied). Namely, when:

1) open a new patch and create [pd something]
2) right-click on object's properties, enable both GOP and "hide text" options and click on OK/Apply
3) the object will revert to its original object-like appearance and will be open-able but its name (text) will not be editable
4) right-clicking on its properties shows that both "hide text" and GOP are still enabled

This is because disabling GOP function does not reset hidetext variable. Following patch fixes this.

----------------------------------------------------------------------

Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-07-07 12:46

Message:
There's still a problem:
5) Uncheck "hide text", then uncheck "Graph on parent". Now text is not
editable.

Alternatively, unchecking "Graph on parent" without unchecking "hide text"
will not revert the subpatch to an object box.

Test with Pd 0.43.0 on Maverick.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 06:15

Message:
i attached a simple fix for the problem that deals with it in the tcl
domain.
this applies (only) to 0.43.

file: 0001-disabling-GOP-should-also-disable-hidetext.patch
created for 0.43.0test4

this obsoletes ico's "gop_patch_20101115" (which i leave here for
reference)

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2010-11-15 16:11

Message:
Forgot to mention, this applies to 0.42.5 branch of both pd and
pd-extended. It has not been tested against 0.43.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3109768&group_id=55736


From noreply at sourceforge.net  Thu Jul  7 18:56:16 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 12:56:16 -0400
Subject: [PD-dev] [ pure-data-Patches-3106799 ] [bugfix] GOP leaving zombie
	objects after disabling GOP
Message-ID: <mailman.14.1310057787.2522.pd-dev@iem.at>


Patches item #3106799, was opened at 2010-11-10 13:21
Message generated for change (Comment added) made by jancsika1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] GOP leaving zombie objects after disabling GOP

Initial Comment:
Apologies for previous post without logging in. Please disregard the previous report and use this one instead.

Following applies to pd-extended and pd 0.42.5. Open attached gop_test.pd patch and do the following:

1) right-click on [pd something] and click on "properties
2) check "enable gop" option and apply (*do not* close properties window)
3) uncheck "enable gop" option and apply
4) you should see zombified GOP items that were not properly erased, in some cases the original pd something will be impossible to open by clicking on the object with tk errors being reported to the console

This to the best of my knowledge together with other patches I submitted before via mailing list should take care of all GOP bugs I am currently aware of.

----------------------------------------------------------------------

Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-07-07 12:56

Message:
Problem still exists in Pd-vanilla 0.43.0.  (Ubuntu Maverick)

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:18

Message:
btw, the patch still applies cleanly and the problem does go away

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:15

Message:
i think this bug is still in 0.43.0test4

----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2011-01-09 00:12

Message:
I think this is fixed already in 0.43.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736


From noreply at sourceforge.net  Thu Jul  7 21:08:08 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 15:08:08 -0400
Subject: [PD-dev] [ pure-data-Patches-3108513 ] [bugfix] collection of fixes
	improving scrolling/popup
Message-ID: <mailman.15.1310065718.2522.pd-dev@iem.at>


Patches item #3108513, was opened at 2010-11-13 13:48
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
>Assigned to: Nobody/Anonymous (nobody)
Summary: [bugfix] collection of fixes improving scrolling/popup

Initial Comment:
For detailed info please see my post to pd-dev list http://www.mail-archive.com/pd-dev at iem.at/msg08015.html

This patch differs from one submitted to pd-dev mailing list in that it adjusts changes to pd.tk to reflect additions that have been made to it since (some chunks apply with "fuzz" enabled but they should all apply rather cleanly). It should be applied against latest Pd-extended 0.42.5 svn branch. NB: I have not had a chance to do the porting to 0.43 as I am still using 0.42.5.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 15:08

Message:
These patches should be updated to apply to the HEAD of the pure-data git. 
Also, its easiest to manage if all changes are in a single patch file. 
"git format-patch" works nicely for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736


From noreply at sourceforge.net  Thu Jul  7 21:12:03 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 15:12:03 -0400
Subject: [PD-dev] [ pure-data-Patches-3106837 ] [bugfix] paste/undo/redo
	sometimes leaves patchcords below
Message-ID: <mailman.16.1310065932.2522.pd-dev@iem.at>


Patches item #3106837, was opened at 2010-11-10 14:47
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106837&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: [bugfix] paste/undo/redo sometimes leaves patchcords below

Initial Comment:
Affects only pd-extended 0.42.5 (may also affect 0.43--has not been tested).

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 15:12

Message:
Looks worth including, but with GOP bugs, I'm currently waiting to see what
Miller is going to do with GOP restructuring before tackling this stuff.  I
still don't really have a grasp of the GOP code, so I don't know what the
repercussions of GOP-related patches are.  From my experience, one little
simple fix causes some weird behavior elsewhere.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:24

Message:
the problem only applies to Pd-extended (hence i re-assign it to hans), as
with pd-vanilla, all msg- and obj-boxes are transparent (non-filled), thus
there is no real problem with the layer-depth of cords vs objects.

furthermore, i actually fail to see the problem anyhow: why do you think
it is a bug if the cord is drawn on top of the object?
isn't this what you usually get anyhow?

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2010-11-12 11:50

Message:
Small update to the patch to remove redundant redrawing when duplicating
objects.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2010-11-10 14:49

Message:
Ugh... How does one edit the Details once the file has been uploaded?

At any rate, it is all explained in the test pd patch so please consult
the attached patchcord_test.pd

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106837&group_id=55736


From noreply at sourceforge.net  Fri Jul  8 03:10:04 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 20:10:04 -0500
Subject: [PD-dev] [ pure-data-Patches-3108513 ] [bugfix] collection of fixes
	improving scrolling/popup
Message-ID: <mailman.19.1310087419.2522.pd-dev@iem.at>


Patches item #3108513, was opened at 2010-11-13 13:48
Message generated for change (Comment added) made by ico_bukvic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Open
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Nobody/Anonymous (nobody)
Summary: [bugfix] collection of fixes improving scrolling/popup

Initial Comment:
For detailed info please see my post to pd-dev list http://www.mail-archive.com/pd-dev at iem.at/msg08015.html

This patch differs from one submitted to pd-dev mailing list in that it adjusts changes to pd.tk to reflect additions that have been made to it since (some chunks apply with "fuzz" enabled but they should all apply rather cleanly). It should be applied against latest Pd-extended 0.42.5 svn branch. NB: I have not had a chance to do the porting to 0.43 as I am still using 0.42.5.

----------------------------------------------------------------------

>Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-07 20:10

Message:
Since a number of users have reported that 0.43 is not yet production
ready, this may be very appropriate for a 0.42.7 release. That said, there
is an even better version of the scrolling code and supporting features in
the 20110427 pd-l2ork snapshot.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 14:08

Message:
These patches should be updated to apply to the HEAD of the pure-data git. 
Also, its easiest to manage if all changes are in a single patch file. 
"git format-patch" works nicely for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736


From noreply at sourceforge.net  Fri Jul  8 03:11:48 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jul 2011 20:11:48 -0500
Subject: [PD-dev] [ pure-data-Patches-3106799 ] [bugfix] GOP leaving zombie
	objects after disabling GOP
Message-ID: <mailman.20.1310087522.2522.pd-dev@iem.at>


Patches item #3106799, was opened at 2010-11-10 13:21
Message generated for change (Comment added) made by ico_bukvic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] GOP leaving zombie objects after disabling GOP

Initial Comment:
Apologies for previous post without logging in. Please disregard the previous report and use this one instead.

Following applies to pd-extended and pd 0.42.5. Open attached gop_test.pd patch and do the following:

1) right-click on [pd something] and click on "properties
2) check "enable gop" option and apply (*do not* close properties window)
3) uncheck "enable gop" option and apply
4) you should see zombified GOP items that were not properly erased, in some cases the original pd something will be impossible to open by clicking on the object with tk errors being reported to the console

This to the best of my knowledge together with other patches I submitted before via mailing list should take care of all GOP bugs I am currently aware of.

----------------------------------------------------------------------

>Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-07 20:11

Message:
Please note that this works just fine in pd-l2ork, likely due to a bunch of
other improvements to the GOP mechanism, so the suggested step 5) reported
below does not apply to pd-l2ork. 

----------------------------------------------------------------------

Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-07-07 11:56

Message:
Problem still exists in Pd-vanilla 0.43.0.  (Ubuntu Maverick)

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:18

Message:
btw, the patch still applies cleanly and the problem does go away

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:15

Message:
i think this bug is still in 0.43.0test4

----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2011-01-09 00:12

Message:
I think this is fixed already in 0.43.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736


From noreply at sourceforge.net  Fri Jul  8 11:03:39 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 Jul 2011 11:03:39 +0200
Subject: [PD-dev] [ pure-data-Patches-3106799 ] [bugfix] GOP leaving zombie
	objects after disabling GOP
Message-ID: <mailman.21.1310115849.2522.pd-dev@iem.at>


Patches item #3106799, was opened at 2010-11-10 19:21
Message generated for change (Comment added) made by jmmmp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] GOP leaving zombie objects after disabling GOP

Initial Comment:
Apologies for previous post without logging in. Please disregard the previous report and use this one instead.

Following applies to pd-extended and pd 0.42.5. Open attached gop_test.pd patch and do the following:

1) right-click on [pd something] and click on "properties
2) check "enable gop" option and apply (*do not* close properties window)
3) uncheck "enable gop" option and apply
4) you should see zombified GOP items that were not properly erased, in some cases the original pd something will be impossible to open by clicking on the object with tk errors being reported to the console

This to the best of my knowledge together with other patches I submitted before via mailing list should take care of all GOP bugs I am currently aware of.

----------------------------------------------------------------------

Comment By: Jo?o Pais (jmmmp)
Date: 2011-07-08 11:03

Message:
to my knowledge, usually these kind of mistakes disappear if the window is
closed/opened again (ie. redrawn). In case you're working on a subpatch, of
course.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-08 03:11

Message:
Please note that this works just fine in pd-l2ork, likely due to a bunch of
other improvements to the GOP mechanism, so the suggested step 5) reported
below does not apply to pd-l2ork. 

----------------------------------------------------------------------

Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-07-07 18:56

Message:
Problem still exists in Pd-vanilla 0.43.0.  (Ubuntu Maverick)

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 11:18

Message:
btw, the patch still applies cleanly and the problem does go away

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 11:15

Message:
i think this bug is still in 0.43.0test4

----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2011-01-09 06:12

Message:
I think this is fixed already in 0.43.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736


From noreply at sourceforge.net  Fri Jul  8 12:02:40 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 Jul 2011 05:02:40 -0500
Subject: [PD-dev] [ pure-data-Patches-3106799 ] [bugfix] GOP leaving zombie
	objects after disabling GOP
Message-ID: <mailman.22.1310119371.2522.pd-dev@iem.at>


Patches item #3106799, was opened at 2010-11-10 13:21
Message generated for change (Comment added) made by ico_bukvic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] GOP leaving zombie objects after disabling GOP

Initial Comment:
Apologies for previous post without logging in. Please disregard the previous report and use this one instead.

Following applies to pd-extended and pd 0.42.5. Open attached gop_test.pd patch and do the following:

1) right-click on [pd something] and click on "properties
2) check "enable gop" option and apply (*do not* close properties window)
3) uncheck "enable gop" option and apply
4) you should see zombified GOP items that were not properly erased, in some cases the original pd something will be impossible to open by clicking on the object with tk errors being reported to the console

This to the best of my knowledge together with other patches I submitted before via mailing list should take care of all GOP bugs I am currently aware of.

----------------------------------------------------------------------

>Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-08 05:02

Message:
Sure, I however would not call that a fix or a workaround.

----------------------------------------------------------------------

Comment By: Jo?o Pais (jmmmp)
Date: 2011-07-08 04:03

Message:
to my knowledge, usually these kind of mistakes disappear if the window is
closed/opened again (ie. redrawn). In case you're working on a subpatch, of
course.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-07 20:11

Message:
Please note that this works just fine in pd-l2ork, likely due to a bunch of
other improvements to the GOP mechanism, so the suggested step 5) reported
below does not apply to pd-l2ork. 

----------------------------------------------------------------------

Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-07-07 11:56

Message:
Problem still exists in Pd-vanilla 0.43.0.  (Ubuntu Maverick)

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:18

Message:
btw, the patch still applies cleanly and the problem does go away

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-02-08 05:15

Message:
i think this bug is still in 0.43.0test4

----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2011-01-09 00:12

Message:
I think this is fixed already in 0.43.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3106799&group_id=55736


From noreply at sourceforge.net  Sun Jul 10 14:57:39 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 Jul 2011 08:57:39 -0400
Subject: [PD-dev] [ pure-data-Patches-3361846 ] bonk~ max/msp fixes
Message-ID: <mailman.23.1310302686.2522.pd-dev@iem.at>


Patches item #3361846, was opened at 2011-07-10 08:57
Message generated for change (Tracker Item Submitted) made by pfaffian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3361846&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony Lauzon (pfaffian)
Assigned to: Nobody/Anonymous (nobody)
Summary: bonk~ max/msp fixes

Initial Comment:
Patch consists of 3 changes:
1. Moving some PD specific code inside of #ifdef PD blocks so bonk~ compiles for Max/MSP
2. Bonk template reading/writing correctly works from Max/MSP.
3. "learn" was not using its argument, so every hit was being interpreted as a new template. changed that behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3361846&group_id=55736


From noreply at sourceforge.net  Sun Jul 10 19:19:30 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 Jul 2011 13:19:30 -0400
Subject: [PD-dev] [ pure-data-Patches-3361846 ] bonk~ max/msp fixes
Message-ID: <mailman.25.1310318387.2522.pd-dev@iem.at>


Patches item #3361846, was opened at 2011-07-10 08:57
Message generated for change (Settings changed) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3361846&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony Lauzon (pfaffian)
>Assigned to: Miller Puckette (millerpuckette)
Summary: bonk~ max/msp fixes

Initial Comment:
Patch consists of 3 changes:
1. Moving some PD specific code inside of #ifdef PD blocks so bonk~ compiles for Max/MSP
2. Bonk template reading/writing correctly works from Max/MSP.
3. "learn" was not using its argument, so every hit was being interpreted as a new template. changed that behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3361846&group_id=55736


From zmoelnig at iem.at  Mon Jul 11 08:55:38 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Mon, 11 Jul 2011 08:55:38 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <712121709.254271309604514114.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <712121709.254271309604514114.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <4E1A9E6A.1010103@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-02 13:01, Patrice Colet wrote:
> 
> I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't.
>

does this mean that you have had no success with the dummy.cpp file
(output?) or that you decided to not try because you were unsure?

fgjadsr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4anmgACgkQkX2Xpv6ydvSEbwCg6vuPOxCl80WGU0cvgtnSMg2r
T2AAn23EyKziCJH/dKJFJZDfX9n6ijtV
=/gNQ
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/06bb877a/attachment.bin>

From zmoelnig at iem.at  Mon Jul 11 08:58:19 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Mon, 11 Jul 2011 08:58:19 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <35B705A6-4848-4BDA-9DD2-6F4D915FBA69@at.or.at>
References: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<35B705A6-4848-4BDA-9DD2-6F4D915FBA69@at.or.at>
Message-ID: <4E1A9F0B.7020906@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-05 18:02, Hans-Christoph Steiner wrote:
> 
> Hmm, that sounds like progress.  Perhaps removing CC=g++ and then adding
> something like this would work:
> 
> if ASIO
> EXTRA_SUBDIRS += asio
> # automake hack to force linking with g++
> lib_LTLIBRARIES = libdummy.la
> libdummy_la_SOURCES =
> # Dummy C++ source to cause C++ linking.
> nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx
> endif

hmm, no this shouldn't work at all.
it only tells automake to also build an additional (dummy) c++-library
if ASIO was defined. it won't affect linking of pd at all (libdummy is
not linked agains pd). if it does succeed, than i would suggest to
report a bug agains automake...

fgmadr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4anwsACgkQkX2Xpv6ydvSkZwCfVY7sgmCN+/+BFUeXpGgPusPN
J24AoOrQCn69cjU3bJrn3aFIMbtu18iX
=yemY
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/cfec596d/attachment.bin>

From noreply at sourceforge.net  Mon Jul 11 09:04:37 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 Jul 2011 09:04:37 +0200
Subject: [PD-dev] [ pure-data-Patches-3108513 ] [bugfix] collection of fixes
	improving scrolling/popup
Message-ID: <mailman.26.1310367894.2522.pd-dev@iem.at>


Patches item #3108513, was opened at 2010-11-13 19:48
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Nobody/Anonymous (nobody)
Summary: [bugfix] collection of fixes improving scrolling/popup

Initial Comment:
For detailed info please see my post to pd-dev list http://www.mail-archive.com/pd-dev at iem.at/msg08015.html

This patch differs from one submitted to pd-dev mailing list in that it adjusts changes to pd.tk to reflect additions that have been made to it since (some chunks apply with "fuzz" enabled but they should all apply rather cleanly). It should be applied against latest Pd-extended 0.42.5 svn branch. NB: I have not had a chance to do the porting to 0.43 as I am still using 0.42.5.

----------------------------------------------------------------------

>Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-11 09:04

Message:
hein?

maybe this changed while i was on holidays, but afair whenever there was a
new Pd version then old versions would not be bug-fixed anymore (e.g. once 
0.37.0 was released, there was never a 0.36.17). however, maybe someone has
offered to generously sponsor an old-stable maintainance programme.

if 0.43 is "not yet production ready", then i would like to ask everybody
to not (back)port bugfixes for 0.42.8 but instead make 0.43 ready for
primetime.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-08 03:10

Message:
Since a number of users have reported that 0.43 is not yet production
ready, this may be very appropriate for a 0.42.7 release. That said, there
is an even better version of the scrolling code and supporting features in
the 20110427 pd-l2ork snapshot.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 21:08

Message:
These patches should be updated to apply to the HEAD of the pure-data git. 
Also, its easiest to manage if all changes are in a single patch file. 
"git format-patch" works nicely for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736


From zmoelnig at iem.at  Mon Jul 11 11:08:28 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Mon, 11 Jul 2011 11:08:28 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <4E1ABD8C.8030300@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-05 13:04, Patrice Colet wrote:
> I've removed this in configure.ac:
> 
> # ASIO is a C++ library, so if its included, then use g++ to build
> CC=g++
> 
> compiles fine, only pd.exe is not working but pd.dll is fine, everything is built.
> 
> from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC.
> 

this what i have been suggesting (i think)

attached is a diff against upstreams Pd that should use g++ for linking
when using ASIO (it might use g++ for all linking, but that should be ok
as well), by letting automake choose (rather than forcing it to use a
special linker like "g++" (which hardcodes the compiler name...u?hh))

it works on linux :-)


fmgasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4avYkACgkQkX2Xpv6ydvTwPACeOmrqMSLAdz/YA+68e4zgWYHO
cZcAn32FOZOtnyIsGBoDfSDq/xYwwFFX
=Djnx
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-force-C-linker-when-linking-with-ASIO.patch
Type: text/x-patch
Size: 1187 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/fce442c9/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/fce442c9/attachment-0003.bin>

From hans at at.or.at  Mon Jul 11 17:59:42 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 11 Jul 2011 11:59:42 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <4E1ABD8C.8030300@iem.at>
References: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<4E1ABD8C.8030300@iem.at>
Message-ID: <D13E689D-7196-4173-AAD8-51EA8CD9578F@at.or.at>


On Jul 11, 2011, at 5:08 AM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-07-05 13:04, Patrice Colet wrote:
>> I've removed this in configure.ac:
>>
>> # ASIO is a C++ library, so if its included, then use g++ to build
>> CC=g++
>>
>> compiles fine, only pd.exe is not working but pd.dll is fine,  
>> everything is built.
>>
>> from all I've read in gnu manuals, automake automatically set g++  
>> for cpp files so there is no need to set CC.
>>
>
> this what i have been suggesting (i think)
>
> attached is a diff against upstreams Pd that should use g++ for  
> linking
> when using ASIO (it might use g++ for all linking, but that should  
> be ok
> as well), by letting automake choose (rather than forcing it to use a
> special linker like "g++" (which hardcodes the compiler name...u?hh))
>
> it works on linux :-)

We have the opposite problem than that automake hack is trying to  
solve.  When ASIO is including, then everything including portaudio is  
built and linked using g++.  Portaudio fails to build with g++, so we  
need to find a way to make only ASIO build with g++, while the rest  
build with gcc.  I think automake will still choose g++ for linking  
since its choosing g++ for ASIO.

.hc


----------------------------------------------------------------------------

Mistrust authority - promote decentralization.  - the hacker ethic




From zmoelnig at iem.at  Mon Jul 11 18:12:37 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Mon, 11 Jul 2011 18:12:37 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <D13E689D-7196-4173-AAD8-51EA8CD9578F@at.or.at>
References: <965161935.769921309863880948.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<4E1ABD8C.8030300@iem.at>
	<D13E689D-7196-4173-AAD8-51EA8CD9578F@at.or.at>
Message-ID: <4E1B20F5.4020609@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
> 
> We have the opposite problem than that automake hack is trying to
> solve.  When ASIO is including, then everything including portaudio is
> built and linked using g++.  Portaudio fails to build with g++, so we
> need to find a way to make only ASIO build with g++, while the rest
> build with gcc.  I think automake will still choose g++ for linking
> since its choosing g++ for ASIO.
> 

ah thanks for clarifying the problem.

however: automake will chose the _compiler_ on a file-per-file basis; so
forcing the _linker_ to be CXX for pd, should have no effect on the
compilining portaudio (and creating the portaudio library)

fgamdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
j68AnjgGtdThIklLxRGBSN9vK4anSbjx
=HAmS
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/0fd00e4d/attachment.bin>

From colet.patrice at free.fr  Mon Jul 11 18:29:34 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 11 Jul 2011 18:29:34 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <4E1B20F5.4020609@iem.at>
Message-ID: <1205032271.1088261310401774654.JavaMail.root@zimbra4-e1.priv.proxad.net>

 The problem I'm encountering on win32 with makefile.am is that pd.dll is not built


----- "IOhannes m zmoelnig" <zmoelnig at iem.at> a ?crit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
> > 
> > We have the opposite problem than that automake hack is trying to
> > solve.  When ASIO is including, then everything including portaudio
> is
> > built and linked using g++.  Portaudio fails to build with g++, so
> we
> > need to find a way to make only ASIO build with g++, while the rest
> > build with gcc.  I think automake will still choose g++ for linking
> > since its choosing g++ for ASIO.
> > 
> 
> ah thanks for clarifying the problem.
> 
> however: automake will chose the _compiler_ on a file-per-file basis;
> so
> forcing the _linker_ to be CXX for pd, should have no effect on the
> compilining portaudio (and creating the portaudio library)
> 
> fgamdr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
> j68AnjgGtdThIklLxRGBSN9vK4anSbjx
> =HAmS
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-- 
Patrice Colet 


From colet.patrice at free.fr  Mon Jul 11 19:02:24 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 11 Jul 2011 19:02:24 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <629510936.1094661310403714498.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <339048571.1094751310403744386.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :

> The problem I'm encountering on win32 with makefile.am is that pd.dll
> is not built
> 
> 

if I add this:

if WINDOWS
LIBS += -lwsock32 -lwinmm -lole32
pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
lib_LTLIBRARIES = libpd.la
libpd_la_SOURCES     = $(pd_sources)
libpd_la_LDFLAGS     = -no-undefined
pd_LDADD             = libpd.la
bin_SCRIPTS = 
endif

libpd.dll building is initiated:

Creating library file: .libs/libpd.dll.a but the linker complains about 


> ----- "IOhannes m zmoelnig" <zmoelnig at iem.at> a ?crit :
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
> > >
> > > We have the opposite problem than that automake hack is trying to
> > > solve.  When ASIO is including, then everything including
> portaudio
> > is
> > > built and linked using g++.  Portaudio fails to build with g++, so
> > we
> > > need to find a way to make only ASIO build with g++, while the
> rest
> > > build with gcc.  I think automake will still choose g++ for
> linking
> > > since its choosing g++ for ASIO.
> > >
> >
> > ah thanks for clarifying the problem.
> >
> > however: automake will chose the _compiler_ on a file-per-file
> basis;
> > so
> > forcing the _linker_ to be CXX for pd, should have no effect on the
> > compilining portaudio (and creating the portaudio library)
> >
> > fgamdr
> > IOhannes
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
> > j68AnjgGtdThIklLxRGBSN9vK4anSbjx
> > =HAmS
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 
> --
> Patrice Colet
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-- 
Patrice Colet 


From zmoelnig at iem.at  Mon Jul 11 19:03:26 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Mon, 11 Jul 2011 19:03:26 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <339048571.1094751310403744386.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <339048571.1094751310403744386.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <4E1B2CDE.8060201@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-11 19:02, Patrice Colet wrote:
> 
> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
> 
>> The problem I'm encountering on win32 with makefile.am is that pd.dll
>> is not built
>>
>>
> 
> if I add this:
> 
> if WINDOWS
> LIBS += -lwsock32 -lwinmm -lole32
> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
> lib_LTLIBRARIES = libpd.la
> libpd_la_SOURCES     = $(pd_sources)
> libpd_la_LDFLAGS     = -no-undefined
> pd_LDADD             = libpd.la
> bin_SCRIPTS = 
> endif
> 
> libpd.dll building is initiated:
> 
> Creating library file: .libs/libpd.dll.a but the linker complains about 
> 

about what?

fjgasdrt
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4bLN4ACgkQkX2Xpv6ydvT1twCfd111ppwNPHpl95gQwc165us0
JTUAnium3rHF+20UVSBccWdcqTc+OT7i
=qx1m
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110711/8cb52a74/attachment.bin>

From colet.patrice at free.fr  Mon Jul 11 19:06:05 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 11 Jul 2011 19:06:05 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1205032271.1088261310401774654.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :

> The problem I'm encountering on win32 with makefile.am is that pd.dll
> is not built
> 
> 

following this doc page:

http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html

I've added those lines in makefile.am:

if WINDOWS
LIBS += -lwsock32 -lwinmm -lole32
pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
lib_LTLIBRARIES = libpd.la
libpd_la_SOURCES     = $(pd_sources)
libpd_la_LDFLAGS     = -no-undefined
pd_LDADD             = libpd.la
bin_SCRIPTS = 
endif

it's getting closer because dll building is initiated:

Creating library file: .libs/libpd.dll.a

pd.dll isn't a libtool standard file

but the linker complains:

pd-m_sched.o:m_sched.c:(.text+0x1514): undefined reference to `_imp__pthread_mutex_lock'
pd-m_sched.o:m_sched.c:(.text+0x1528): undefined reference to `_imp__pthread_mutex_unlock'
pd-m_sched.o:m_sched.c:(.text+0x1920): undefined reference to `_imp__pthread_mutex_trylock'
pd-s_loader.o:s_loader.c:(.text+0x233): undefined reference to `dlopen'
pd-s_loader.o:s_loader.c:(.text+0x247): undefined reference to `dlsym'
pd-s_loader.o:s_loader.c:(.text+0x4a7): undefined reference to `dlerror'
pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference to `_imp__pthread_mutex_lock'
<snip>

it's seems closer

> ----- "IOhannes m zmoelnig" <zmoelnig at iem.at> a ?crit :
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
> > >
> > > We have the opposite problem than that automake hack is trying to
> > > solve.  When ASIO is including, then everything including
> portaudio
> > is
> > > built and linked using g++.  Portaudio fails to build with g++, so
> > we
> > > need to find a way to make only ASIO build with g++, while the
> rest
> > > build with gcc.  I think automake will still choose g++ for
> linking
> > > since its choosing g++ for ASIO.
> > >
> >
> > ah thanks for clarifying the problem.
> >
> > however: automake will chose the _compiler_ on a file-per-file
> basis;
> > so
> > forcing the _linker_ to be CXX for pd, should have no effect on the
> > compilining portaudio (and creating the portaudio library)
> >
> > fgamdr
> > IOhannes
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
> > j68AnjgGtdThIklLxRGBSN9vK4anSbjx
> > =HAmS
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 
> --
> Patrice Colet
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-- 
Patrice Colet 


From noreply at sourceforge.net  Mon Jul 11 19:19:45 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 Jul 2011 13:19:45 -0400
Subject: [PD-dev] [ pure-data-Bugs-3363274 ] selection appears in msg box
	after Ctrl/Cmd triple-clicking
Message-ID: <mailman.27.1310404808.2522.pd-dev@iem.at>


Bugs item #3363274, was opened at 2011-07-11 13:19
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3363274&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.43
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: selection appears in msg box after Ctrl/Cmd triple-clicking 

Initial Comment:
Here's how to reproduce

- new patch
- create msg box
- add some text in the message box
- click background to create
- hold down Ctrl/Cmd and triple-click the message box fast

You will see the msg box is not in the editing state, but the text gets selected


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3363274&group_id=55736


From hans at at.or.at  Mon Jul 11 19:29:10 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 11 Jul 2011 13:29:10 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at>


On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote:

>
> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
>
>> The problem I'm encountering on win32 with makefile.am is that pd.dll
>> is not built
>>
>>
>
> following this doc page:
>
> http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html
>
> I've added those lines in makefile.am:
>
> if WINDOWS
> LIBS += -lwsock32 -lwinmm -lole32
> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
> lib_LTLIBRARIES = libpd.la
> libpd_la_SOURCES     = $(pd_sources)
> libpd_la_LDFLAGS     = -no-undefined
> pd_LDADD             = libpd.la
> bin_SCRIPTS =
> endif
>
> it's getting closer because dll building is initiated:
>
> Creating library file: .libs/libpd.dll.a
>
> pd.dll isn't a libtool standard file
>
> but the linker complains:
>
> pd-m_sched.o:m_sched.c:(.text+0x1514): undefined reference to  
> `_imp__pthread_mutex_lock'
> pd-m_sched.o:m_sched.c:(.text+0x1528): undefined reference to  
> `_imp__pthread_mutex_unlock'
> pd-m_sched.o:m_sched.c:(.text+0x1920): undefined reference to  
> `_imp__pthread_mutex_trylock'


> pd-s_loader.o:s_loader.c:(.text+0x233): undefined reference to  
> `dlopen'
> pd-s_loader.o:s_loader.c:(.text+0x247): undefined reference to `dlsym'
> pd-s_loader.o:s_loader.c:(.text+0x4a7): undefined reference to  
> `dlerror'
> pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference to  
> `_imp__pthread_mutex_lock'

try changing:

LIBS += -lwsock32 -lwinmm -lole32

to:

LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl

.hc


> <snip>
>
> it's seems closer
>
>> ----- "IOhannes m zmoelnig" <zmoelnig at iem.at> a ?crit :
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
>>>>
>>>> We have the opposite problem than that automake hack is trying to
>>>> solve.  When ASIO is including, then everything including
>> portaudio
>>> is
>>>> built and linked using g++.  Portaudio fails to build with g++, so
>>> we
>>>> need to find a way to make only ASIO build with g++, while the
>> rest
>>>> build with gcc.  I think automake will still choose g++ for
>> linking
>>>> since its choosing g++ for ASIO.
>>>>
>>>
>>> ah thanks for clarifying the problem.
>>>
>>> however: automake will chose the _compiler_ on a file-per-file
>> basis;
>>> so
>>> forcing the _linker_ to be CXX for pd, should have no effect on the
>>> compilining portaudio (and creating the portaudio library)
>>>
>>> fgamdr
>>> IOhannes
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
>>> j68AnjgGtdThIklLxRGBSN9vK4anSbjx
>>> =HAmS
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>
>> --
>> Patrice Colet
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
> -- 
> Patrice Colet



----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.




From hans at at.or.at  Mon Jul 11 19:37:10 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 11 Jul 2011 13:37:10 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at>
References: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at>
Message-ID: <403DD131-0BAF-4554-821E-90920F126446@at.or.at>


On Jul 11, 2011, at 1:29 PM, Hans-Christoph Steiner wrote:

>
> On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote:
>
>>
>> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
>>
>>> The problem I'm encountering on win32 with makefile.am is that  
>>> pd.dll
>>> is not built
>>>
>>>
>>
>> following this doc page:
>>
>> http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html
>>
>> I've added those lines in makefile.am:
>>
>> if WINDOWS
>> LIBS += -lwsock32 -lwinmm -lole32
>> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
>> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
>> lib_LTLIBRARIES = libpd.la
>> libpd_la_SOURCES     = $(pd_sources)
>> libpd_la_LDFLAGS     = -no-undefined
>> pd_LDADD             = libpd.la
>> bin_SCRIPTS =
>> endif
>>
>> it's getting closer because dll building is initiated:
>>
>> Creating library file: .libs/libpd.dll.a
>>
>> pd.dll isn't a libtool standard file
>>
>> but the linker complains:
>>
>> pd-m_sched.o:m_sched.c:(.text+0x1514): undefined reference to  
>> `_imp__pthread_mutex_lock'
>> pd-m_sched.o:m_sched.c:(.text+0x1528): undefined reference to  
>> `_imp__pthread_mutex_unlock'
>> pd-m_sched.o:m_sched.c:(.text+0x1920): undefined reference to  
>> `_imp__pthread_mutex_trylock'
>
>
>> pd-s_loader.o:s_loader.c:(.text+0x233): undefined reference to  
>> `dlopen'
>> pd-s_loader.o:s_loader.c:(.text+0x247): undefined reference to  
>> `dlsym'
>> pd-s_loader.o:s_loader.c:(.text+0x4a7): undefined reference to  
>> `dlerror'
>> pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference  
>> to `_imp__pthread_mutex_lock'
>
> try changing:
>
> LIBS += -lwsock32 -lwinmm -lole32
>
> to:
>
> LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
>
> .hc


That makes me think.... so ./configure is finding libdl find, and then  
setting HAVE_LIBDL, and then the code in s_loader.c is going to do  
both HAVE_LIBDL and the MSW section below it.  So I guess we should  
force this build system to not use HAVE_LIBDL on Windows, or fix the  
define to be something like:

#ifdef HAVE_LIBDL
     dlobj = dlopen(filename, RTLD_NOW | RTLD_GLOBAL);
     if (!dlobj)
     {
         post("%s: %s", filename, dlerror());
         class_set_extern_dir(&s_);
         return (0);
     }
     makeout = (t_xxx)dlsym(dlobj,  symname);
     /* fprintf(stderr, "symbol %s\n", symname); */
-#endif
-#ifdef MSW
+#elif defined(_WIN32)
     sys_bashfilename(filename, filename);
     ntdll = LoadLibrary(filename);
     if (!ntdll)
     {
         post("%s: couldn't load", filename);
         class_set_extern_dir(&s_);
         return (0);
     }
     makeout = (t_xxx)GetProcAddress(ntdll, symname);
+#else
+#error "No dynamic loading mechanism found!"
#endif


.hc









>
>
>> <snip>
>>
>> it's seems closer
>>
>>> ----- "IOhannes m zmoelnig" <zmoelnig at iem.at> a ?crit :
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 2011-07-11 17:59, Hans-Christoph Steiner wrote:
>>>>>
>>>>> We have the opposite problem than that automake hack is trying to
>>>>> solve.  When ASIO is including, then everything including
>>> portaudio
>>>> is
>>>>> built and linked using g++.  Portaudio fails to build with g++, so
>>>> we
>>>>> need to find a way to make only ASIO build with g++, while the
>>> rest
>>>>> build with gcc.  I think automake will still choose g++ for
>>> linking
>>>>> since its choosing g++ for ASIO.
>>>>>
>>>>
>>>> ah thanks for clarifying the problem.
>>>>
>>>> however: automake will chose the _compiler_ on a file-per-file
>>> basis;
>>>> so
>>>> forcing the _linker_ to be CXX for pd, should have no effect on the
>>>> compilining portaudio (and creating the portaudio library)
>>>>
>>>> fgamdr
>>>> IOhannes
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>
>>>> iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1
>>>> j68AnjgGtdThIklLxRGBSN9vK4anSbjx
>>>> =HAmS
>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>> --
>>> Patrice Colet
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>
>> -- 
>> Patrice Colet
>
>
>
> ----------------------------------------------------------------------------
>
> The arc of history bends towards justice.     - Dr. Martin Luther  
> King, Jr.
>
>



----------------------------------------------------------------------------

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."        -John Gilmore




From colet.patrice at free.fr  Mon Jul 11 19:55:10 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 11 Jul 2011 19:55:10 +0200 (CEST)
Subject: [PD-dev] Fwd: [PD]  Pdextended 0.43.1 and vista
In-Reply-To: <687454885.1104851310406321745.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <257750548.1107561310406910567.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- Mail transf?r? -----
De: "Patrice Colet" <colet.patrice at free.fr>
?: "pd-list" <pd-list at iem.at>
Cc: "IOhannes m zmoelnig" <zmoelnig at iem.at>
Envoy?: Lundi 11 Juillet 2011 19h45:21 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [PD] [PD-dev] Pdextended 0.43.1 and vista


----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> On Jul 11, 2011, at 1:29 PM, Hans-Christoph Steiner wrote:
> 
> >
> > On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote:
> >
> >>
> >> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
> >>
> >>> The problem I'm encountering on win32 with makefile.am is that  
> >>> pd.dll
> >>> is not built
> >>>
> >>>
> >>
> >> following this doc page:
> >>
> >>
> http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html
> >>
> >> I've added those lines in makefile.am:
> >>
> >> if WINDOWS
> >> LIBS += -lwsock32 -lwinmm -lole32
> >> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
> >> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
> >> lib_LTLIBRARIES = libpd.la
> >> libpd_la_SOURCES     = $(pd_sources)
> >> libpd_la_LDFLAGS     = -no-undefined
> >> pd_LDADD             = libpd.la
> >> bin_SCRIPTS =
> >> endif
> >>

<snip>

> >> pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference 
> 
> >> to `_imp__pthread_mutex_lock'
> >
> > try changing:
> >
> > LIBS += -lwsock32 -lwinmm -lole32
> >
> > to:
> >
> > LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
> >
> > .hc

that resolve almost everything, we just need to resolve portaudio linking

pd-s_audio_pa.o:s_audio_pa.c:(.text+0x4a6): undefined reference to `Pa_IsFormatSupported'

<snip>

pd-s_audio_pa.o:s_audio_pa.c:(.text+0x179d): undefined reference to `Pa_GetErrorText

-- 
Patrice Colet 

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

-- 
Patrice Colet 


From noreply at sourceforge.net  Mon Jul 11 23:20:03 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 Jul 2011 21:20:03 +0000
Subject: [PD-dev] [ pure-data-Patches-3307639 ] updated FR localization
Message-ID: <E1QgNtb-0007zD-Ig@sec-sog-1.v99.ch3.sourceforge.com>


Patches item #3307639, was opened at 2011-05-25 17:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307639&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexandre Castonguay (alxe)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: updated FR localization

Initial Comment:
Mise ? jour de la localisation fran?aise

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-07-11 21:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-06-27 20:44

Message:
Ok, I added this to Pd-extended.  Be very careful to not copy things that
are not being translated.  I.e. if "DSP" is going to remain "DSP", then it
should look like this:

msgid "DSP"
msgstr ""

NOT like this:

msgid "DSP"
msgstr "DSP"

There are a number of reasons to do this.  This is the way the PO system
expects, msgstr "" means use the original text.  Also, having the "DSP",
etc. duplicated caused a weird bug where the Log menu on the Pd Window was
not showing up which took me about an hour to figure out :(.  And lastly,
it will help your translation, since tools like POedit will show you which
lines have not been translated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307639&group_id=55736


From abonnements at revolwear.com  Tue Jul 12 00:28:41 2011
From: abonnements at revolwear.com (Max)
Date: Tue, 12 Jul 2011 00:28:41 +0200
Subject: [PD-dev] 10.6 64bit autobuild computer will be inaccessible until
	monday
Message-ID: <8837D204-86AA-4027-B4DC-17383E912D4C@revolwear.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dear devs,

chaos.medien.uni-weimar.de will most probably have downtime until sunday because it's the final week in the semester and we'll transform the room into an exhibition space. I can't say when exactly it will start, maybe tomorrow or on thursday but service will be restored on monday.

sorry for the inconvenience.

max
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAk4beRkACgkQ3EB7kzgMM6LAagCfQ+uQUe8+8JDzrHtgaUnXvAqD
WGAAmQHOG6vAHYFDk3cl+JW7anCBNAPQ
=V9Fg
-----END PGP SIGNATURE-----


From hans at at.or.at  Tue Jul 12 05:11:35 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 11 Jul 2011 23:11:35 -0400
Subject: [PD-dev] 10.6 64bit autobuild computer will be inaccessible
	until monday
In-Reply-To: <8837D204-86AA-4027-B4DC-17383E912D4C@revolwear.com>
References: <8837D204-86AA-4027-B4DC-17383E912D4C@revolwear.com>
Message-ID: <F2DA262A-D5F2-41E0-9CF3-418CBF7A2585@at.or.at>


As long as there is a build tonight, which there should be, we should  
have a working 10.6 build, so its fine by me.  Thanks for the update!

.hc

On Jul 11, 2011, at 6:28 PM, Max wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> dear devs,
>
> chaos.medien.uni-weimar.de will most probably have downtime until  
> sunday because it's the final week in the semester and we'll  
> transform the room into an exhibition space. I can't say when  
> exactly it will start, maybe tomorrow or on thursday but service  
> will be restored on monday.
>
> sorry for the inconvenience.
>
> max
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAk4beRkACgkQ3EB7kzgMM6LAagCfQ+uQUe8+8JDzrHtgaUnXvAqD
> WGAAmQHOG6vAHYFDk3cl+JW7anCBNAPQ
> =V9Fg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev




----------------------------------------------------------------------------

All mankind is of one author, and is one volume; when one man dies,  
one chapter is not torn out of the book, but translated into a better  
language; and every chapter must be so translated.... -John Donne




From noreply at sourceforge.net  Tue Jul 12 05:22:32 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 Jul 2011 23:22:32 -0400
Subject: [PD-dev] [ pure-data-Patches-3108513 ] [bugfix] collection of fixes
	improving scrolling/popup
Message-ID: <mailman.30.1310440979.2522.pd-dev@iem.at>


Patches item #3108513, was opened at 2010-11-13 13:48
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Pending
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Nobody/Anonymous (nobody)
Summary: [bugfix] collection of fixes improving scrolling/popup

Initial Comment:
For detailed info please see my post to pd-dev list http://www.mail-archive.com/pd-dev at iem.at/msg08015.html

This patch differs from one submitted to pd-dev mailing list in that it adjusts changes to pd.tk to reflect additions that have been made to it since (some chunks apply with "fuzz" enabled but they should all apply rather cleanly). It should be applied against latest Pd-extended 0.42.5 svn branch. NB: I have not had a chance to do the porting to 0.43 as I am still using 0.42.5.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-11 23:22

Message:
Ico, I think you're the only one wanting to maintain an 'oldstable' 0.42
branch.  I think basically all other Pd development is done on the HEAD of
git and svn, so for working for the rest of the pd devs, I think its safe
to say that the HEAD of git and svn is the standard which to base patches
on.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-11 03:04

Message:
hein?

maybe this changed while i was on holidays, but afair whenever there was a
new Pd version then old versions would not be bug-fixed anymore (e.g. once 
0.37.0 was released, there was never a 0.36.17). however, maybe someone has
offered to generously sponsor an old-stable maintainance programme.

if 0.43 is "not yet production ready", then i would like to ask everybody
to not (back)port bugfixes for 0.42.8 but instead make 0.43 ready for
primetime.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-07 21:10

Message:
Since a number of users have reported that 0.43 is not yet production
ready, this may be very appropriate for a 0.42.7 release. That said, there
is an even better version of the scrolling code and supporting features in
the 20110427 pd-l2ork snapshot.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 15:08

Message:
These patches should be updated to apply to the HEAD of the pure-data git. 
Also, its easiest to manage if all changes are in a single patch file. 
"git format-patch" works nicely for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736


From zmoelnig at iem.at  Tue Jul 12 09:22:24 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 12 Jul 2011 09:22:24 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <403DD131-0BAF-4554-821E-90920F126446@at.or.at>
References: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>	<BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at>
	<403DD131-0BAF-4554-821E-90920F126446@at.or.at>
Message-ID: <4E1BF630.2070401@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-11 19:37, Hans-Christoph Steiner wrote:
> 
> 
> That makes me think.... so ./configure is finding libdl find, and then
> setting HAVE_LIBDL, and then the code in s_loader.c is going to do both
> HAVE_LIBDL and the MSW section below it.  So I guess we should force
> this build system to not use HAVE_LIBDL on Windows, or fix the define to
> be something like:
> 

shouldn't it be more like trying all available dylib loading mechanisms?
e.g. if HAVE_LIBDL than try using dlopen, if that fails fall back to the
w32 native LoadLibrary.

and finally, Pd should probably still be able to compile even if no
dylib mechanism is present (think iOS). if the system cannot loading
libraries, than Pd won't be able to load externals, but internals and
abstractions will continue to work.

fgamsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4b9i8ACgkQkX2Xpv6ydvR69wCcCkGaSVhyoJ6cv/ZYn/B2sYSg
nhoAoLNoQkdkh6bMtZWVcUARzHqBOTvh
=7i7B
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110712/4d90e673/attachment.bin>

From zmoelnig at iem.at  Tue Jul 12 09:29:13 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 12 Jul 2011 09:29:13 +0200
Subject: [PD-dev] [ pure-data-Patches-3307639 ] updated FR localization
In-Reply-To: <E1QgNtb-0007zD-Ig@sec-sog-1.v99.ch3.sourceforge.com>
References: <E1QgNtb-0007zD-Ig@sec-sog-1.v99.ch3.sourceforge.com>
Message-ID: <4E1BF7C9.2040507@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-11 23:20, SourceForge.net wrote:
>
> Message:
> Ok, I added this to Pd-extended.  Be very careful to not copy things that
> are not being translated.  I.e. if "DSP" is going to remain "DSP", then it
> should look like this:
> 
> msgid "DSP"
> msgstr ""
> 
> NOT like this:
> 
> msgid "DSP"
> msgstr "DSP"
> 
> There are a number of reasons to do this.  This is the way the PO system
> expects, msgstr "" means use the original text.  Also, having the "DSP",
> etc. duplicated caused a weird bug where the Log menu on the Pd Window was
> not showing up which took me about an hour to figure out :(.  And lastly,
> it will help your translation, since tools like POedit will show you which
> lines have not been translated.
> 

hmm, i understand the reasoning, when indeed there is no translation (so
PO will fallback to the original text).
however, i believe there are situations where the translation looks
indeed identically (on the byte level), even though it is a translation.
esp. if you have fancy tools like POedit that will show you which lines
have not been translated yet: if somebody did the work and concluded
that the words are exactly the same in both languages, than the
translation has happened, and any editor marking that as TODO only
yields a false positive.

and of course, if the log menu does not show up because somebody decided
(accidentally or on purpose) that they translate "DSP" with "DSP", then
this is clearly a bug _elsewhere_ that should be fixed.

fgamsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4b98kACgkQkX2Xpv6ydvTmKQCeIC+u2i4/BGG//Ia1RqKbmKCF
gSkAn0lDSHCxzmJ7fiHHX11iUguDofne
=WkBr
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110712/a88b07d3/attachment.bin>

From noreply at sourceforge.net  Tue Jul 12 09:30:50 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 12 Jul 2011 09:30:50 +0200
Subject: [PD-dev] [ pure-data-Patches-3108513 ] [bugfix] collection of fixes
	improving scrolling/popup
Message-ID: <mailman.31.1310455864.2522.pd-dev@iem.at>


Patches item #3108513, was opened at 2010-11-13 19:48
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Pending
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Ivica Ico Bukvic (ico_bukvic)
Assigned to: Nobody/Anonymous (nobody)
Summary: [bugfix] collection of fixes improving scrolling/popup

Initial Comment:
For detailed info please see my post to pd-dev list http://www.mail-archive.com/pd-dev at iem.at/msg08015.html

This patch differs from one submitted to pd-dev mailing list in that it adjusts changes to pd.tk to reflect additions that have been made to it since (some chunks apply with "fuzz" enabled but they should all apply rather cleanly). It should be applied against latest Pd-extended 0.42.5 svn branch. NB: I have not had a chance to do the porting to 0.43 as I am still using 0.42.5.

----------------------------------------------------------------------

>Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-12 09:30

Message:
which reminds me that somebody should probably import the git head (well at
laest 0.43.0) into SVN (which is still 0.42.5)

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-12 05:22

Message:
Ico, I think you're the only one wanting to maintain an 'oldstable' 0.42
branch.  I think basically all other Pd development is done on the HEAD of
git and svn, so for working for the rest of the pd devs, I think its safe
to say that the HEAD of git and svn is the standard which to base patches
on.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-11 09:04

Message:
hein?

maybe this changed while i was on holidays, but afair whenever there was a
new Pd version then old versions would not be bug-fixed anymore (e.g. once 
0.37.0 was released, there was never a 0.36.17). however, maybe someone has
offered to generously sponsor an old-stable maintainance programme.

if 0.43 is "not yet production ready", then i would like to ask everybody
to not (back)port bugfixes for 0.42.8 but instead make 0.43 ready for
primetime.

----------------------------------------------------------------------

Comment By: Ivica Ico Bukvic (ico_bukvic)
Date: 2011-07-08 03:10

Message:
Since a number of users have reported that 0.43 is not yet production
ready, this may be very appropriate for a 0.42.7 release. That said, there
is an even better version of the scrolling code and supporting features in
the 20110427 pd-l2ork snapshot.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-07 21:08

Message:
These patches should be updated to apply to the HEAD of the pure-data git. 
Also, its easiest to manage if all changes are in a single patch file. 
"git format-patch" works nicely for that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3108513&group_id=55736


From noreply at sourceforge.net  Tue Jul 12 11:00:18 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 12 Jul 2011 09:00:18 +0000
Subject: [PD-dev] [ pure-data-Bugs-3364091 ] pdextended gem_film*.so
	backends not in package/build dir
Message-ID: <mailman.32.1310461253.2522.pd-dev@iem.at>


Bugs item #3364091, was opened at 2011-07-12 09:00
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3364091&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Charles Goyard ()
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pdextended gem_film*.so backends not in package/build dir

Initial Comment:
Hi,
while building pd-extended rsynced from the auto-build farm, on Archlinux (gcc 4.6.1) with :
cd packages/linux_make
edit Makefile to replace -march=386 with -march=i686
make install
the gem_filmGMERLIN.so and gem_filmQT4L.so don't get copied in the extra/Gem build dir, leading to pix_film fail. A manual copy of the files fixes that.
Cheers,
Charles

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3364091&group_id=55736


From hans at at.or.at  Tue Jul 12 22:18:38 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Tue, 12 Jul 2011 16:18:38 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <4E1BF630.2070401@iem.at>
References: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at><403DD131-0BAF-4554-821E-90920F126446@at.or.at>
	<4E1BF630.2070401@iem.at>
Message-ID: <1310501918.4157.2151040565@webmail.messagingengine.com>

On Tue, 12 Jul 2011 09:22 +0200, "IOhannes m zmoelnig" <zmoelnig at iem.at>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2011-07-11 19:37, Hans-Christoph Steiner wrote:
> > 
> > 
> > That makes me think.... so ./configure is finding libdl find, and then
> > setting HAVE_LIBDL, and then the code in s_loader.c is going to do both
> > HAVE_LIBDL and the MSW section below it.  So I guess we should force
> > this build system to not use HAVE_LIBDL on Windows, or fix the define to
> > be something like:
> > 
> 
> shouldn't it be more like trying all available dylib loading mechanisms?
> e.g. if HAVE_LIBDL than try using dlopen, if that fails fall back to the
> w32 native LoadLibrary.
> 
> and finally, Pd should probably still be able to compile even if no
> dylib mechanism is present (think iOS). if the system cannot loading
> libraries, than Pd won't be able to load externals, but internals and
> abstractions will continue to work.

Yes, defiitely.  Here's how I am thinking (also attached):


--- a/src/s_loader.c
+++ b/src/s_loader.c
@@ -178,8 +178,7 @@ gotone:
     }
     makeout = (t_xxx)dlsym(dlobj,  symname);
     /* fprintf(stderr, "symbol %s\n", symname); */
-#endif
-#ifdef MSW
+#elif defined(_WIN32)
     sys_bashfilename(filename, filename);
     ntdll = LoadLibrary(filename);
     if (!ntdll)
@@ -189,6 +188,8 @@ gotone:
         return (0);
     }
     makeout = (t_xxx)GetProcAddress(ntdll, symname);  
+#else
+# warning "No dynamic loading mechanism specified, libdl or WIN32
required for loading externa
 #endif
 
     if (!makeout)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libdl_windows.patch
Type: text/x-patch
Size: 637 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110712/93e5f0bb/attachment.bin>

From zmoelnig at iem.at  Tue Jul 12 22:29:33 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Tue, 12 Jul 2011 22:29:33 +0200
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1310501918.4157.2151040565@webmail.messagingengine.com>
References: <509229127.1095431310403965230.JavaMail.root@zimbra4-e1.priv.proxad.net>
	<BD16185E-F3FC-44D9-9205-CDC57B593A7C@at.or.at><403DD131-0BAF-4554-821E-90920F126446@at.or.at>
	<4E1BF630.2070401@iem.at>
	<1310501918.4157.2151040565@webmail.messagingengine.com>
Message-ID: <4E1CAEAD.8010608@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/12/2011 10:18 PM, Hans-Christoph Steiner wrote:
> +#else
> +# warning "No dynamic loading mechanism specified, libdl or WIN32
> required for loading externa
>  #endif


"#warning" is a gcc extension, so it's not very portable.

btw, "#error" is as well, but since other compilers will bail out with
an error (for not understanding #error), the effect is similar to that
in gcc)

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4crq0ACgkQkX2Xpv6ydvTLfwCgqfUy1RgnBlE+buV4VVBcsMTg
b/4An3WRShxKFR8FRnqtkVRuo7sJ2r9R
=KNIY
-----END PGP SIGNATURE-----


From nicolas_montgermont at yahoo.fr  Wed Jul 13 14:20:41 2011
From: nicolas_montgermont at yahoo.fr (Nicolas Montgermont)
Date: Wed, 13 Jul 2011 14:20:41 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
Message-ID: <4E1D8D99.60308@yahoo.fr>

Hello all,

I want to develop a serie of externals that allow to use tables bigger 
than 2^24 points. After a few missed attempt (redefining PDFLOATTYPE, 
using double inside the objects...) i think i have managed two working 
externals [tabread_double] and [tabwrite_double] that use two float to 
point an integer : n = f1 + 2^24*f2.

Before going further (tabread~, tabread4,...) I wanted to know if 
someone has already done something similar or if you have advices on 
names and behavior.
I've chosen to have compatibility with existing object, simply adding 
one inlet on the right that set f2.

If it's the first serie of external for that i'll try to add that on the 
svn in a few weeks.
best,
n
-- 
http://nim.on.free.fr


From zmoelnig at iem.at  Wed Jul 13 14:29:28 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Wed, 13 Jul 2011 14:29:28 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1D8D99.60308@yahoo.fr>
References: <4E1D8D99.60308@yahoo.fr>
Message-ID: <4E1D8FA8.8030805@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-13 14:20, Nicolas Montgermont wrote:
> Before going further (tabread~, tabread4,...) I wanted to know if
> someone has already done something similar or if you have advices on
> names and behavior.

i think thomas musil did something like a "double precision table
library" once, using the same approach.
i simultaneously worked on the problem with the totally different
approach of making Pd "double precision" aware.

thomas is on holidays right now (won't be back before august), and i
would be interested in what failed to work when using PD_FLOATTYPE=double.

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dj6QACgkQkX2Xpv6ydvRzPQCfdM2t07txfuCUNbO/9S4frxBN
/jIAoKWG0LXRrcORhI34CYGAjYXXXMn0
=xZI2
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/8d9e5ef2/attachment.bin>

From nicolas_montgermont at yahoo.fr  Wed Jul 13 15:30:21 2011
From: nicolas_montgermont at yahoo.fr (Nicolas Montgermont)
Date: Wed, 13 Jul 2011 15:30:21 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1D8FA8.8030805@iem.at>
References: <4E1D8D99.60308@yahoo.fr> <4E1D8FA8.8030805@iem.at>
Message-ID: <4E1D9DED.80509@yahoo.fr>



Le 13/07/11 14:29, IOhannes m zmoelnig a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-07-13 14:20, Nicolas Montgermont wrote:
>> Before going further (tabread~, tabread4,...) I wanted to know if
>> someone has already done something similar or if you have advices on
>> names and behavior.
> i think thomas musil did something like a "double precision table
> library" once, using the same approach.
  can i find it on the svn?
> i simultaneously worked on the problem with the totally different
> approach of making Pd "double precision" aware.
>
> thomas is on holidays right now (won't be back before august), and i
> would be interested in what failed to work when using PD_FLOATTYPE=double.
I use
#define PD_FLOATTYPE double
before including m_pd.h
in an external.

it compiles but it occurred to me that i have to recompile Pd with the 
same definition to test it,
that was not what i searched cause i prefer to use "standard" pd and to 
add externals.

with the [tabread_double] paradigm, it'll work regarding any floattype 
of the Pd used.
otoh, im' not sure i can manage transparent operation keeping the 
precision i want, i mean building an abstraction that takes as an input 
a float that can be bigger than 2^24 and that automaticcaly use 
tabread_double or tabwrite_double the good way.
Maybe i'll need to do a special + - or % / or >> << to achieve that.
mmm tricky
n

-- 
http://nim.on.free.fr


From zmoelnig at iem.at  Wed Jul 13 15:51:26 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Wed, 13 Jul 2011 15:51:26 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1D9DED.80509@yahoo.fr>
References: <4E1D8D99.60308@yahoo.fr> <4E1D8FA8.8030805@iem.at>
	<4E1D9DED.80509@yahoo.fr>
Message-ID: <4E1DA2DE.8070006@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-13 15:30, Nicolas Montgermont wrote:
> 
> 
> Le 13/07/11 14:29, IOhannes m zmoelnig a ?crit :
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 2011-07-13 14:20, Nicolas Montgermont wrote:
>>> Before going further (tabread~, tabread4,...) I wanted to know if
>>> someone has already done something similar or if you have advices on
>>> names and behavior.
>> i think thomas musil did something like a "double precision table
>> library" once, using the same approach.
>  can i find it on the svn?
>> i simultaneously worked on the problem with the totally different
>> approach of making Pd "double precision" aware.
>>
>> thomas is on holidays right now (won't be back before august), and i
>> would be interested in what failed to work when using
>> PD_FLOATTYPE=double.
> I use
> #define PD_FLOATTYPE double
> before including m_pd.h
> in an external.
> 
> it compiles but it occurred to me that i have to recompile Pd with the
> same definition to test it,

yes, you need a Pd that is compiled with "PD_FLOATTYPE double"

> that was not what i searched cause i prefer to use "standard" pd and to
> add externals.

the idea is to make "double" the standard for Pd in the future.
if nobody spents time for that it will never happen.


> with the [tabread_double] paradigm, it'll work regarding any floattype
> of the Pd used.
> otoh, im' not sure i can manage transparent operation keeping the
> precision i want, i mean building an abstraction that takes as an input
> a float that can be bigger than 2^24 and that automaticcaly use
> tabread_double or tabwrite_double the good way.
> Maybe i'll need to do a special + - or % / or >> << to achieve that.

if you want transparent operation, than you need to make Pd "double
aware", in which case it comes for free.

though it appears to me that we are talking about different things.
could it be that you are talking about the "values" in the table (y-axis)?
i was mainly concerned about the "indices" of the table (x-axis), where
it becomes impossible to index a value sample-accurately once it is >1e9.

the reason why tables won't store very large and very small values are
denormals (i think); the idea is to prevent such values from occuring in
the signal chain as they would induce a performance penalty. since
[table] can be easily converted to a signal, it simply prevents these
values to get in.
if you don't need the full range between 1e-24 and 1e+24, than you
should consider scaling your values appropriately before storing them in
tables.

if you are indeed talking about indices, then i would like to invite you
to come here and share with me some of your yottabyte modules.


fmasdr
IOhannes



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dotsACgkQkX2Xpv6ydvTWowCeMropR81hvv4g5nm0YpE7MWXu
bJcAoMo1GpTHB5rYgrgImYW0MbyvTx4d
=Q0Eo
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/9ea649eb/attachment.bin>

From nicolas_montgermont at yahoo.fr  Wed Jul 13 16:23:38 2011
From: nicolas_montgermont at yahoo.fr (Nicolas Montgermont)
Date: Wed, 13 Jul 2011 16:23:38 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1DA2DE.8070006@iem.at>
References: <4E1D8D99.60308@yahoo.fr>
	<4E1D8FA8.8030805@iem.at>	<4E1D9DED.80509@yahoo.fr>
	<4E1DA2DE.8070006@iem.at>
Message-ID: <4E1DAA6A.3010505@yahoo.fr>



Le 13/07/11 15:51, IOhannes m zmoelnig a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-07-13 15:30, Nicolas Montgermont wrote:
>>
>> Le 13/07/11 14:29, IOhannes m zmoelnig a ?crit :
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 2011-07-13 14:20, Nicolas Montgermont wrote:
>>>> Before going further (tabread~, tabread4,...) I wanted to know if
>>>> someone has already done something similar or if you have advices on
>>>> names and behavior.
>>> i think thomas musil did something like a "double precision table
>>> library" once, using the same approach.
>>   can i find it on the svn?
>>> i simultaneously worked on the problem with the totally different
>>> approach of making Pd "double precision" aware.
>>>
>>> thomas is on holidays right now (won't be back before august), and i
>>> would be interested in what failed to work when using
>>> PD_FLOATTYPE=double.
>> I use
>> #define PD_FLOATTYPE double
>> before including m_pd.h
>> in an external.
>>
>> it compiles but it occurred to me that i have to recompile Pd with the
>> same definition to test it,
> yes, you need a Pd that is compiled with "PD_FLOATTYPE double"
>
>> that was not what i searched cause i prefer to use "standard" pd and to
>> add externals.
> the idea is to make "double" the standard for Pd in the future.
That is definitely a good thing :)
> if nobody spents time for that it will never happen.
That is sure. The point is that this problem has happen to me very often 
the past few months and I was searching a workaround and not a 
definitive solution.
I think this is a major limitation for many people and so i tried to 
find a way to have this possible.
I am not aware of all the developments of the 0.43 version is this 
planned to be include soon?
let me know if i can help (mainly compiling on osx)
>> with the [tabread_double] paradigm, it'll work regarding any floattype
>> of the Pd used.
>> otoh, im' not sure i can manage transparent operation keeping the
>> precision i want, i mean building an abstraction that takes as an input
>> a float that can be bigger than 2^24 and that automaticcaly use
>> tabread_double or tabwrite_double the good way.
>> Maybe i'll need to do a special + - or % / or>>  <<  to achieve that.
i finally manage something that is a dedicated counter for double 
precision. it can work everywhere. see attached.
> if you want transparent operation, than you need to make Pd "double
> aware", in which case it comes for free.
>
> ...
>
> if you are indeed talking about indices, then i would like to invite you
> to come here and share with me some of your yottabyte modules.
Not sure what you want. The code for this double float inlets solution 
is not in the svn,
cause i have not worked on it for a while and i'm afraid of breaking the 
autobuilds.
but you can find it attached (standard makefile)
all is about using "long" instead of "int"
if you want the code i tested with PD_FLOATTYPE double
it was simply the code of the float object with this definition as a 
starting line.
n
-- 
http://nim.on.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tab_double.zip
Type: application/x-zip-compressed
Size: 4581 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/33788155/attachment-0001.bin>

From katjavetter at gmail.com  Wed Jul 13 19:31:34 2011
From: katjavetter at gmail.com (katja)
Date: Wed, 13 Jul 2011 19:31:34 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1DA2DE.8070006@iem.at>
References: <4E1D8D99.60308@yahoo.fr> <4E1D8FA8.8030805@iem.at>
	<4E1D9DED.80509@yahoo.fr> <4E1DA2DE.8070006@iem.at>
Message-ID: <CAFY0eapGSeHQGS0PUK5_EYnRMtJPfxkF7HqX-hkLmASEpMooJA@mail.gmail.com>

On Wed, Jul 13, 2011 at 3:51 PM, IOhannes m zmoelnig <zmoelnig at iem.at>wrote:

>> the idea is to make "double" the standard for Pd in the future.
>> if nobody spents time for that it will never happen.

I'd like to help with this if I can (with only fragmentary knowledge of Pd
core code I must say). I recall looking at the options to compile Pd with
type double, but running into union tabfudge and UNITBIT32 which are used by
rather central Pd objects like [osc~] and [phasor~]. I did not fully grasp
the working of this clever type punning hack, but assumed it cannot be
translated to type double rightaway. Is it true that this trick is crucial
for computational speed of [osc~] & co, and must an equivalent routine still
be developed (if possible at all)? Or are there other, more important
bottlenecks to solve?

Katja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/c0f0d869/attachment.htm>

From zmoelnig at iem.at  Wed Jul 13 19:38:19 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Wed, 13 Jul 2011 19:38:19 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <CAFY0eapGSeHQGS0PUK5_EYnRMtJPfxkF7HqX-hkLmASEpMooJA@mail.gmail.com>
References: <4E1D8D99.60308@yahoo.fr>
	<4E1D8FA8.8030805@iem.at>	<4E1D9DED.80509@yahoo.fr>
	<4E1DA2DE.8070006@iem.at>
	<CAFY0eapGSeHQGS0PUK5_EYnRMtJPfxkF7HqX-hkLmASEpMooJA@mail.gmail.com>
Message-ID: <4E1DD80B.1090201@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-13 19:31, katja wrote:
> On Wed, Jul 13, 2011 at 3:51 PM, IOhannes m zmoelnig <zmoelnig at iem.at>wrote:
> 
>>> the idea is to make "double" the standard for Pd in the future.
>>> if nobody spents time for that it will never happen.
> 
> I'd like to help with this if I can (with only fragmentary knowledge of Pd
> core code I must say). I recall looking at the options to compile Pd with
> type double, but running into union tabfudge and UNITBIT32 which are used by
> rather central Pd objects like [osc~] and [phasor~]. I did not fully grasp
> the working of this clever type punning hack, but assumed it cannot be
> translated to type double rightaway. Is it true that this trick is crucial
> for computational speed of [osc~] & co, and must an equivalent routine still
> be developed (if possible at all)? Or are there other, more important
> bottlenecks to solve?
> 

i think this is the main showstopper right now.
the type punning tricks used to be crucial (i assume), but nowadays the
speed gain should be rather low (at least according to some tests we did).

i would suggest to come up with a generic implementatin of those
objects, do benchmarking and if needed (and possible) provide an
alternative optimized solution (in addition to the generic one)

fgmadsr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d2AgACgkQkX2Xpv6ydvQxMQCfWS9vWrq9VFBAPOD7a92A0SYO
fu0AoNbMEpEs1EGdQC9RmBBeNyHSJDqf
=5vXD
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/2ba20d33/attachment.bin>

From jancsika at yahoo.com  Wed Jul 13 20:11:19 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Wed, 13 Jul 2011 11:11:19 -0700 (PDT)
Subject: [PD-dev] struct _canvasenvironment
Message-ID: <1310580679.94734.YahooMailClassic@web39414.mail.mud.yahoo.com>

Hello,
     Why is "struct _canvasenvironment" in g_canvas.c instead of g_canvas.h?  I want to take a t_object inside g_text.c and-- if it's an abstraction-- get its name and dir.  I can get the name but cannot get the dir because "struct _canvasenvironment" isn't in g_canvas.h.  Would it break things if it were moved there?

Thanks,
Jonathan


From zmoelnig at iem.at  Wed Jul 13 20:31:18 2011
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Wed, 13 Jul 2011 20:31:18 +0200
Subject: [PD-dev] struct _canvasenvironment
In-Reply-To: <1310580679.94734.YahooMailClassic@web39414.mail.mud.yahoo.com>
References: <1310580679.94734.YahooMailClassic@web39414.mail.mud.yahoo.com>
Message-ID: <4E1DE476.9080204@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-07-13 20:11, Jonathan Wilkes wrote:
> Hello,
>      Why is "struct _canvasenvironment" in g_canvas.c instead of g_canvas.h?  I want to take a t_object inside g_text.c and-- if it's an abstraction-- get its name and dir.  I can get the name but cannot get the dir because "struct _canvasenvironment" isn't in g_canvas.h.  Would it break things if it were moved there?
> 

maybe because it is considered an opaque type?

it's a way of telling you: "t_canvasenvironment is private property, do
not trespass".
you don't have right of ways and if the next time you drop by, the owner
decided to change everything, you are not supposed to complain.

mfgasdfr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d5GoACgkQkX2Xpv6ydvR5CgCgmk4QxjBdeDW58g9G/KxVnVtT
gfEAn0Rw8pouk0ikU4+DXVAEBBrY3+gn
=Y2de
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/85a1627e/attachment.bin>

From katjavetter at gmail.com  Wed Jul 13 21:30:50 2011
From: katjavetter at gmail.com (katja)
Date: Wed, 13 Jul 2011 21:30:50 +0200
Subject: [PD-dev] Tabread/write on array bigger than 16777216 points
In-Reply-To: <4E1DD80B.1090201@iem.at>
References: <4E1D8D99.60308@yahoo.fr> <4E1D8FA8.8030805@iem.at>
	<4E1D9DED.80509@yahoo.fr> <4E1DA2DE.8070006@iem.at>
	<CAFY0eapGSeHQGS0PUK5_EYnRMtJPfxkF7HqX-hkLmASEpMooJA@mail.gmail.com>
	<4E1DD80B.1090201@iem.at>
Message-ID: <CAFY0eaqv5ax20x19WMCcyqiEtyL9UPk3bppju5Y+KePC4rJaSw@mail.gmail.com>

On Wed, Jul 13, 2011 at 7:38 PM, IOhannes m zmoelnig <zmoelnig at iem.at>wrote:


>> i think this is the main showstopper right now.
>> the type punning tricks used to be crucial (i assume), but nowadays the
>> speed gain should be rather low (at least according to some tests we
did).

A double precision Pd is high on my wishlist, and if the union tabfudge
thing is the main showstopper, then it's certainly worthwhile to put effort
in it. I'm often running into precision issues with Pd, not only by lack of
an integer type for indexes but also in the case of signal data. In some
cases I write a new external instead of a patch for this reason, which is a
pity. I'll do as you say, first write and test a generic alternative with
straightforward implementation, then try to optimize.

Katja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/d805915e/attachment-0001.htm>

From jancsika at yahoo.com  Wed Jul 13 22:46:06 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Wed, 13 Jul 2011 13:46:06 -0700 (PDT)
Subject: [PD-dev] struct _canvasenvironment
In-Reply-To: <4E1DE476.9080204@iem.at>
Message-ID: <1310589966.1004.YahooMailClassic@web39408.mail.mud.yahoo.com>



--- On Wed, 7/13/11, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> From: IOhannes m zmoelnig <zmoelnig at iem.at>
> Subject: Re: [PD-dev] struct _canvasenvironment
> To: pd-dev at iem.at
> Date: Wednesday, July 13, 2011, 8:31 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2011-07-13 20:11, Jonathan Wilkes wrote:
> > Hello,
> >? ? ? Why is "struct _canvasenvironment"
> in g_canvas.c instead of g_canvas.h?? I want to take a
> t_object inside g_text.c and-- if it's an abstraction-- get
> its name and dir.? I can get the name but cannot get
> the dir because "struct _canvasenvironment" isn't in
> g_canvas.h.? Would it break things if it were moved
> there?
> > 
> 
> maybe because it is considered an opaque type?
> 
> it's a way of telling you: "t_canvasenvironment is private
> property, do
> not trespass".
> you don't have right of ways and if the next time you drop
> by, the owner
> decided to change everything, you are not supposed to
> complain.
> 

Oops, I overlooked canvas_getdir.  But am I not supposed to "trespass" into this function since it's not in g_canvas.h?

> mfgasdfr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4d5GoACgkQkX2Xpv6ydvR5CgCgmk4QxjBdeDW58g9G/KxVnVtT
> gfEAn0Rw8pouk0ikU4+DXVAEBBrY3+gn
> =Y2de
> -----END PGP SIGNATURE-----
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 


From msp at ucsd.edu  Thu Jul 14 02:08:52 2011
From: msp at ucsd.edu (Miller Puckette)
Date: Wed, 13 Jul 2011 17:08:52 -0700
Subject: [PD-dev] struct _canvasenvironment
In-Reply-To: <1310589966.1004.YahooMailClassic@web39408.mail.mud.yahoo.com>
References: <4E1DE476.9080204@iem.at>
	<1310589966.1004.YahooMailClassic@web39408.mail.mud.yahoo.com>
Message-ID: <20110714000851.GA19970@fuzz.ucsd.edu>

It's in m_pd.h - that's a pretty good guarantee of stability (although
not 100% perfect I'm afraid.)

One caution -- if soneone 'saves' the patch into a new directory, the
canvas's directory will then change -- so it's best not to store the
result of canvas_settid() but to call it each time it gets used.

cheers
Miller

On Wed, Jul 13, 2011 at 01:46:06PM -0700, Jonathan Wilkes wrote:
> 
> 
> --- On Wed, 7/13/11, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> 
> > From: IOhannes m zmoelnig <zmoelnig at iem.at>
> > Subject: Re: [PD-dev] struct _canvasenvironment
> > To: pd-dev at iem.at
> > Date: Wednesday, July 13, 2011, 8:31 PM
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 2011-07-13 20:11, Jonathan Wilkes wrote:
> > > Hello,
> > >? ? ? Why is "struct _canvasenvironment"
> > in g_canvas.c instead of g_canvas.h?? I want to take a
> > t_object inside g_text.c and-- if it's an abstraction-- get
> > its name and dir.? I can get the name but cannot get
> > the dir because "struct _canvasenvironment" isn't in
> > g_canvas.h.? Would it break things if it were moved
> > there?
> > > 
> > 
> > maybe because it is considered an opaque type?
> > 
> > it's a way of telling you: "t_canvasenvironment is private
> > property, do
> > not trespass".
> > you don't have right of ways and if the next time you drop
> > by, the owner
> > decided to change everything, you are not supposed to
> > complain.
> > 
> 
> Oops, I overlooked canvas_getdir.  But am I not supposed to "trespass" into this function since it's not in g_canvas.h?
> 
> > mfgasdfr
> > IOhannes
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAk4d5GoACgkQkX2Xpv6ydvR5CgCgmk4QxjBdeDW58g9G/KxVnVtT
> > gfEAn0Rw8pouk0ikU4+DXVAEBBrY3+gn
> > =Y2de
> > -----END PGP SIGNATURE-----
> > 
> > 
> > -----Inline Attachment Follows-----
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> > 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


From jancsika at yahoo.com  Thu Jul 14 05:22:28 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Wed, 13 Jul 2011 20:22:28 -0700 (PDT)
Subject: [PD-dev] struct _canvasenvironment
In-Reply-To: <20110714000851.GA19970@fuzz.ucsd.edu>
Message-ID: <1310613748.37576.YahooMailClassic@web39422.mail.mud.yahoo.com>



--- On Thu, 7/14/11, Miller Puckette <msp at ucsd.edu> wrote:

> From: Miller Puckette <msp at ucsd.edu>
> Subject: Re: [PD-dev] struct _canvasenvironment
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: pd-dev at iem.at, "IOhannes m zmoelnig" <zmoelnig at iem.at>
> Date: Thursday, July 14, 2011, 2:08 AM
> It's in m_pd.h - that's a pretty good
> guarantee of stability (although
> not 100% perfect I'm afraid.)

Oh, thanks.  I should have looked there first.

> 
> One caution -- if soneone 'saves' the patch into a new
> directory, the
> canvas's directory will then change -- so it's best not to
> store the
> result of canvas_settid() but to call it each time it gets
> used.

Did you mean canvas_getdir?  If that's the case I think I'm safe, since I'm only using it if the canvas in question is an abstraction.  (And it's an absolute path.)  I don't think this would lead to any problems.

Also, in the canvas "get" method patch I put on the tracker it just calls canvas_getdir and returns the result.

-Jonathan

> 
> cheers
> Miller
> 
> On Wed, Jul 13, 2011 at 01:46:06PM -0700, Jonathan Wilkes
> wrote:
> > 
> > 
> > --- On Wed, 7/13/11, IOhannes m zmoelnig <zmoelnig at iem.at>
> wrote:
> > 
> > > From: IOhannes m zmoelnig <zmoelnig at iem.at>
> > > Subject: Re: [PD-dev] struct _canvasenvironment
> > > To: pd-dev at iem.at
> > > Date: Wednesday, July 13, 2011, 8:31 PM
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > On 2011-07-13 20:11, Jonathan Wilkes wrote:
> > > > Hello,
> > > >? ? ? Why is "struct _canvasenvironment"
> > > in g_canvas.c instead of g_canvas.h?? I want to
> take a
> > > t_object inside g_text.c and-- if it's an
> abstraction-- get
> > > its name and dir.? I can get the name but cannot
> get
> > > the dir because "struct _canvasenvironment" isn't
> in
> > > g_canvas.h.? Would it break things if it were
> moved
> > > there?
> > > > 
> > > 
> > > maybe because it is considered an opaque type?
> > > 
> > > it's a way of telling you: "t_canvasenvironment
> is private
> > > property, do
> > > not trespass".
> > > you don't have right of ways and if the next time
> you drop
> > > by, the owner
> > > decided to change everything, you are not
> supposed to
> > > complain.
> > > 
> > 
> > Oops, I overlooked canvas_getdir.? But am I not
> supposed to "trespass" into this function since it's not in
> g_canvas.h?
> > 
> > > mfgasdfr
> > > IOhannes
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.11 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > > 
> > >
> iEYEARECAAYFAk4d5GoACgkQkX2Xpv6ydvR5CgCgmk4QxjBdeDW58g9G/KxVnVtT
> > > gfEAn0Rw8pouk0ikU4+DXVAEBBrY3+gn
> > > =Y2de
> > > -----END PGP SIGNATURE-----
> > > 
> > > 
> > > -----Inline Attachment Follows-----
> > > 
> > > _______________________________________________
> > > Pd-dev mailing list
> > > Pd-dev at iem.at
> > > http://lists.puredata.info/listinfo/pd-dev
> > > 
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 


From msp at ucsd.edu  Thu Jul 14 06:43:03 2011
From: msp at ucsd.edu (Miller Puckette)
Date: Wed, 13 Jul 2011 21:43:03 -0700
Subject: [PD-dev] struct _canvasenvironment
In-Reply-To: <1310613748.37576.YahooMailClassic@web39422.mail.mud.yahoo.com>
References: <20110714000851.GA19970@fuzz.ucsd.edu>
	<1310613748.37576.YahooMailClassic@web39422.mail.mud.yahoo.com>
Message-ID: <20110714044303.GB19970@fuzz.ucsd.edu>

Oops, yep, that's what I meant...  typed too fast.

cheers
M

> 
> Did you mean canvas_getdir?  If that's the case I think I'm safe, since I'm only using it if the canvas in question is an abstraction.  (And it's an absolute path.)  I don't think this would lead to any problems.
> 
> Also, in the canvas "get" method patch I put on the tracker it just calls canvas_getdir and returns the result.
> 
> -Jonathan

I'm planning to go through those Real Soon Now :)

M


From noreply at sourceforge.net  Thu Jul 14 07:36:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 14 Jul 2011 13:36:07 +0800
Subject: [PD-dev] [ pure-data-Patches-3366721 ] Give [netsend] an outlet for
	data from the server
Message-ID: <mailman.33.1310621795.2522.pd-dev@iem.at>


Patches item #3366721, was opened at 2011-07-14 13:36
Message generated for change (Tracker Item Submitted) made by chr15m
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3366721&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris McCormick (chr15m)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give [netsend] an outlet for data from the server

Initial Comment:
Attached is a patch to give [netsend] a second outlet which reports anything received from the server it is connected to. It functions the same 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3366721&group_id=55736


From noreply at sourceforge.net  Thu Jul 14 07:41:58 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 14 Jul 2011 13:41:58 +0800
Subject: [PD-dev] [ pure-data-Patches-3366721 ] Give [netsend] an outlet for
	data from the server
Message-ID: <mailman.34.1310622130.2522.pd-dev@iem.at>


Patches item #3366721, was opened at 2011-07-14 13:36
Message generated for change (Comment added) made by chr15m
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3366721&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: puredata
>Group: feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris McCormick (chr15m)
>Assigned to: Miller Puckette (millerpuckette)
Summary: Give [netsend] an outlet for data from the server

Initial Comment:
Attached is a patch to give [netsend] a second outlet which reports anything received from the server it is connected to. It functions the same 

----------------------------------------------------------------------

>Comment By: Chris McCormick (chr15m)
Date: 2011-07-14 13:41

Message:
Dammit I hit submit too soon. :(

The patch should apply cleanly against Pd 0.43 and does not affect the
existing [netsend] functionality. It is backwards compatible. Also included
is an updated netsend-help.pd with instructions regarding the new second
outlet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3366721&group_id=55736


From chris at mccormick.cx  Thu Jul 14 07:50:28 2011
From: chris at mccormick.cx (Chris McCormick)
Date: Thu, 14 Jul 2011 01:50:28 -0400
Subject: [PD-dev] Patch to give [netsend] a second outlet which reports
 anything sent back on the socket
Message-ID: <811739ff24a108e8149f7de46e56e798.squirrel@mccormick.cx>

Hello,

This patch adds a second outlet to [netsend] which reports data sent back
from the server it is connected to, in order to turn it into a more
traditional socket-like entity.

https://sourceforge.net/tracker/?func=detail&aid=3366721&group_id=55736&atid=478072

I think this will be useful to users as it will more easily enable them to
create "multiplayer" Pd patches which connect to a central server to
communicate between them.

I hope this patch will be considered for inclusion in your version of Pd,
Miller. If there is any way in which I should change it to improve the
chances of it going in there, do let me know!

Cheers,

Chris.



From jancsika at yahoo.com  Thu Jul 14 23:55:10 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Thu, 14 Jul 2011 14:55:10 -0700 (PDT)
Subject: [PD-dev] replace spaces in list class names with hyphens
Message-ID: <1310680510.41545.YahooMailClassic@web39404.mail.mud.yahoo.com>

I've got a working tooltip prototype going, and I just noticed that all the list classes screw up things on the tcl side, because with "list append" (for example) it suddenly looks like there is one more arg to the proc.

Are there any other objects that have a space in the creator name?  If not, could we just make it official that creator names can't have spaces, and change all the "list foo" creators objects to "list-foo"?

This would be transparent to the user*, since they can still type "list foo" and list_new will instantiate the right class.  (Although going forward I would suggest using "list-foo" as it is the standard for all the listabs abstractions.)

-Jonathan

*Except for anyone crazy enough to be doing:

[32(
|
[makefilename list%csplit]
|
[obj 10 10 $1(
|
[s patch-of-a-crazy-person]


From zmoelnig at iem.at  Fri Jul 15 10:18:25 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Fri, 15 Jul 2011 10:18:25 +0200
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <1310680510.41545.YahooMailClassic@web39404.mail.mud.yahoo.com>
References: <1310680510.41545.YahooMailClassic@web39404.mail.mud.yahoo.com>
Message-ID: <4E1FF7D1.1070301@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> I've got a working tooltip prototype going, and I just noticed that all the list classes screw up things on the tcl side, because with "list append" (for example) it suddenly looks like there is one more arg to the proc.
> 
> Are there any other objects that have a space in the creator name?  If not, could we just make it official that creator names can't have spaces, and change all the "list foo" creators objects to "list-foo"?
> 
> This would be transparent to the user*, since they can still type "list foo" and list_new will instantiate the right class.  (Although going forward I would suggest using "list-foo" as it is the standard for all the listabs abstractions.)
> 

while i was always opposed to using object names with spaces [1], i
don't think that we should forbid it at all. i would rather have the GUI
side have an idea of what is the object name and what are the arguments
(e.g. "create {list split} {1}" rather than "text list split 1") than to
add arbitrary limitations.

some externals use "proxy objects" for full-fledged non-first inlets,
and those proxies tend to have "hard to type" names as well. how do your
tooltips deal with those?

gfmasdr
IOhannes

[1]
https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
=XO7J
-----END PGP SIGNATURE-----


From hans at at.or.at  Fri Jul 15 17:01:38 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 15 Jul 2011 11:01:38 -0400
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <4E1FF7D1.1070301@iem.at>
References: <1310680510.41545.YahooMailClassic@web39404.mail.mud.yahoo.com>
	<4E1FF7D1.1070301@iem.at>
Message-ID: <000054AE-7906-45DC-BE6F-325AC90EFD97@at.or.at>


On Jul 15, 2011, at 4:18 AM, IOhannes m zm?lnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
>> I've got a working tooltip prototype going, and I just noticed that  
>> all the list classes screw up things on the tcl side, because with  
>> "list append" (for example) it suddenly looks like there is one  
>> more arg to the proc.
>>
>> Are there any other objects that have a space in the creator name?   
>> If not, could we just make it official that creator names can't  
>> have spaces, and change all the "list foo" creators objects to  
>> "list-foo"?
>>
>> This would be transparent to the user*, since they can still type  
>> "list foo" and list_new will instantiate the right class.   
>> (Although going forward I would suggest using "list-foo" as it is  
>> the standard for all the listabs abstractions.)
>>
>
> while i was always opposed to using object names with spaces [1], i
> don't think that we should forbid it at all. i would rather have the  
> GUI
> side have an idea of what is the object name and what are the  
> arguments
> (e.g. "create {list split} {1}" rather than "text list split 1")  
> than to
> add arbitrary limitations.
>
> some externals use "proxy objects" for full-fledged non-first inlets,
> and those proxies tend to have "hard to type" names as well. how do  
> your
> tooltips deal with those?


I have to agree. Though it is more work, I think we should support  
object names with any character in them.  Tcl can definitely do it  
without much difficulty, as long as  the details aren't ignored.

.hc



----------------------------------------------------------------------------

Programs should be written for people to read, and only incidentally  
for machines to execute.
  - from Structure and Interpretation of Computer Programs



From jancsika at yahoo.com  Fri Jul 15 18:46:38 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Fri, 15 Jul 2011 09:46:38 -0700 (PDT)
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <4E1FF7D1.1070301@iem.at>
Message-ID: <1310748398.4846.YahooMailClassic@web39414.mail.mud.yahoo.com>



--- On Fri, 7/15/11, IOhannes m zm?lnig <zmoelnig at iem.at> wrote:

> From: IOhannes m zm?lnig <zmoelnig at iem.at>
> Subject: Re: [PD-dev] replace spaces in list class names with hyphens
> To: pd-dev at iem.at
> Date: Friday, July 15, 2011, 10:18 AM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> > I've got a working tooltip prototype going, and I just
> noticed that all the list classes screw up things on the tcl
> side, because with "list append" (for example) it suddenly
> looks like there is one more arg to the proc.
> > 
> > Are there any other objects that have a space in the
> creator name?? If not, could we just make it official
> that creator names can't have spaces, and change all the
> "list foo" creators objects to "list-foo"?
> > 
> > This would be transparent to the user*, since they can
> still type "list foo" and list_new will instantiate the
> right class.? (Although going forward I would suggest
> using "list-foo" as it is the standard for all the listabs
> abstractions.)
> > 
> 
> while i was always opposed to using object names with
> spaces [1], i
> don't think that we should forbid it at all. i would rather
> have the GUI
> side have an idea of what is the object name and what are
> the arguments
> (e.g. "create {list split} {1}" rather than "text list
> split 1") than to
> add arbitrary limitations.
> 
> some externals use "proxy objects" for full-fledged
> non-first inlets,
> and those proxies tend to have "hard to type" names as
> well. how do your
> tooltips deal with those?

So if object "foo" has a 2nd inlet controlled by a proxy object "bar", which class is referred to by t_object *ob of glist_drawio in g_text.c: foo or bar?

> 
> gfmasdr
> IOhannes
> 
> [1]
> https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> =XO7J
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 


From msp at ucsd.edu  Fri Jul 15 19:41:01 2011
From: msp at ucsd.edu (Miller Puckette)
Date: Fri, 15 Jul 2011 10:41:01 -0700
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <1310748398.4846.YahooMailClassic@web39414.mail.mud.yahoo.com>
References: <4E1FF7D1.1070301@iem.at>
	<1310748398.4846.YahooMailClassic@web39414.mail.mud.yahoo.com>
Message-ID: <20110715174101.GA1552@fuzz.ucsd.edu>

THere isn't a 1-to-1 correspondence between the string that invokes an
object and its class -- hence, "list" can give rise to several different
classes, but also, there are sometimes multiple classes in Pd that have
the same "class name", like "select".  The string was originally only
there to help in pringing out error messages, (i.e. human readable), not
as a way to disamiguate anything.

I think the only way to know everything relevant is to know the whole
argument list and parse it, ouch...

cheers
Miller

On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
> 
> 
> --- On Fri, 7/15/11, IOhannes m zm?lnig <zmoelnig at iem.at> wrote:
> 
> > From: IOhannes m zm?lnig <zmoelnig at iem.at>
> > Subject: Re: [PD-dev] replace spaces in list class names with hyphens
> > To: pd-dev at iem.at
> > Date: Friday, July 15, 2011, 10:18 AM
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> > > I've got a working tooltip prototype going, and I just
> > noticed that all the list classes screw up things on the tcl
> > side, because with "list append" (for example) it suddenly
> > looks like there is one more arg to the proc.
> > > 
> > > Are there any other objects that have a space in the
> > creator name?? If not, could we just make it official
> > that creator names can't have spaces, and change all the
> > "list foo" creators objects to "list-foo"?
> > > 
> > > This would be transparent to the user*, since they can
> > still type "list foo" and list_new will instantiate the
> > right class.? (Although going forward I would suggest
> > using "list-foo" as it is the standard for all the listabs
> > abstractions.)
> > > 
> > 
> > while i was always opposed to using object names with
> > spaces [1], i
> > don't think that we should forbid it at all. i would rather
> > have the GUI
> > side have an idea of what is the object name and what are
> > the arguments
> > (e.g. "create {list split} {1}" rather than "text list
> > split 1") than to
> > add arbitrary limitations.
> > 
> > some externals use "proxy objects" for full-fledged
> > non-first inlets,
> > and those proxies tend to have "hard to type" names as
> > well. how do your
> > tooltips deal with those?
> 
> So if object "foo" has a 2nd inlet controlled by a proxy object "bar", which class is referred to by t_object *ob of glist_drawio in g_text.c: foo or bar?
> 
> > 
> > gfmasdr
> > IOhannes
> > 
> > [1]
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> > EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> > =XO7J
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> > 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


From hans at at.or.at  Fri Jul 15 20:00:07 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 15 Jul 2011 14:00:07 -0400
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <20110715174101.GA1552@fuzz.ucsd.edu>
References: <4E1FF7D1.1070301@iem.at>
	<1310748398.4846.YahooMailClassic@web39414.mail.mud.yahoo.com>
	<20110715174101.GA1552@fuzz.ucsd.edu>
Message-ID: <0FEC0DB2-DC66-4EC1-90EF-5C3DD2ACB17D@at.or.at>


Besides [list], what are other exceptions to the rule of the class  
being all characters before the first space?  It might just be easier  
to code in an exception for [list].

.hc

On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:

> THere isn't a 1-to-1 correspondence between the string that invokes an
> object and its class -- hence, "list" can give rise to several  
> different
> classes, but also, there are sometimes multiple classes in Pd that  
> have
> the same "class name", like "select".  The string was originally only
> there to help in pringing out error messages, (i.e. human readable),  
> not
> as a way to disamiguate anything.
>
> I think the only way to know everything relevant is to know the whole
> argument list and parse it, ouch...
>
> cheers
> Miller
>
> On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
>>
>>
>> --- On Fri, 7/15/11, IOhannes m zm?lnig <zmoelnig at iem.at> wrote:
>>
>>> From: IOhannes m zm?lnig <zmoelnig at iem.at>
>>> Subject: Re: [PD-dev] replace spaces in list class names with  
>>> hyphens
>>> To: pd-dev at iem.at
>>> Date: Friday, July 15, 2011, 10:18 AM
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
>>>> I've got a working tooltip prototype going, and I just
>>> noticed that all the list classes screw up things on the tcl
>>> side, because with "list append" (for example) it suddenly
>>> looks like there is one more arg to the proc.
>>>>
>>>> Are there any other objects that have a space in the
>>> creator name?  If not, could we just make it official
>>> that creator names can't have spaces, and change all the
>>> "list foo" creators objects to "list-foo"?
>>>>
>>>> This would be transparent to the user*, since they can
>>> still type "list foo" and list_new will instantiate the
>>> right class.  (Although going forward I would suggest
>>> using "list-foo" as it is the standard for all the listabs
>>> abstractions.)
>>>>
>>>
>>> while i was always opposed to using object names with
>>> spaces [1], i
>>> don't think that we should forbid it at all. i would rather
>>> have the GUI
>>> side have an idea of what is the object name and what are
>>> the arguments
>>> (e.g. "create {list split} {1}" rather than "text list
>>> split 1") than to
>>> add arbitrary limitations.
>>>
>>> some externals use "proxy objects" for full-fledged
>>> non-first inlets,
>>> and those proxies tend to have "hard to type" names as
>>> well. how do your
>>> tooltips deal with those?
>>
>> So if object "foo" has a 2nd inlet controlled by a proxy object  
>> "bar", which class is referred to by t_object *ob of glist_drawio  
>> in g_text.c: foo or bar?
>>
>>>
>>> gfmasdr
>>> IOhannes
>>>
>>> [1]
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
>>> EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
>>> =XO7J
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev





----------------------------------------------------------------------------

"[T]he greatest purveyor of violence in the world today [is] my own  
government." - Martin Luther King, Jr.





From msp at ucsd.edu  Fri Jul 15 21:19:29 2011
From: msp at ucsd.edu (Miller Puckette)
Date: Fri, 15 Jul 2011 12:19:29 -0700
Subject: [PD-dev] replace spaces in list class names with hyphens
In-Reply-To: <0FEC0DB2-DC66-4EC1-90EF-5C3DD2ACB17D@at.or.at>
References: <4E1FF7D1.1070301@iem.at>
	<1310748398.4846.YahooMailClassic@web39414.mail.mud.yahoo.com>
	<20110715174101.GA1552@fuzz.ucsd.edu>
	<0FEC0DB2-DC66-4EC1-90EF-5C3DD2ACB17D@at.or.at>
Message-ID: <20110715191929.GB1552@fuzz.ucsd.edu>

I think that's the only one.

cheers
M

On Fri, Jul 15, 2011 at 02:00:07PM -0400, Hans-Christoph Steiner wrote:
> 
> Besides [list], what are other exceptions to the rule of the class
> being all characters before the first space?  It might just be
> easier to code in an exception for [list].
> 
> .hc
> 
> On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:
> 
> >THere isn't a 1-to-1 correspondence between the string that invokes an
> >object and its class -- hence, "list" can give rise to several
> >different
> >classes, but also, there are sometimes multiple classes in Pd that
> >have
> >the same "class name", like "select".  The string was originally only
> >there to help in pringing out error messages, (i.e. human
> >readable), not
> >as a way to disamiguate anything.
> >
> >I think the only way to know everything relevant is to know the whole
> >argument list and parse it, ouch...
> >
> >cheers
> >Miller
> >
> >On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
> >>
> >>
> >>--- On Fri, 7/15/11, IOhannes m zm?lnig <zmoelnig at iem.at> wrote:
> >>
> >>>From: IOhannes m zm?lnig <zmoelnig at iem.at>
> >>>Subject: Re: [PD-dev] replace spaces in list class names with
> >>>hyphens
> >>>To: pd-dev at iem.at
> >>>Date: Friday, July 15, 2011, 10:18 AM
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> >>>>I've got a working tooltip prototype going, and I just
> >>>noticed that all the list classes screw up things on the tcl
> >>>side, because with "list append" (for example) it suddenly
> >>>looks like there is one more arg to the proc.
> >>>>
> >>>>Are there any other objects that have a space in the
> >>>creator name?  If not, could we just make it official
> >>>that creator names can't have spaces, and change all the
> >>>"list foo" creators objects to "list-foo"?
> >>>>
> >>>>This would be transparent to the user*, since they can
> >>>still type "list foo" and list_new will instantiate the
> >>>right class.  (Although going forward I would suggest
> >>>using "list-foo" as it is the standard for all the listabs
> >>>abstractions.)
> >>>>
> >>>
> >>>while i was always opposed to using object names with
> >>>spaces [1], i
> >>>don't think that we should forbid it at all. i would rather
> >>>have the GUI
> >>>side have an idea of what is the object name and what are
> >>>the arguments
> >>>(e.g. "create {list split} {1}" rather than "text list
> >>>split 1") than to
> >>>add arbitrary limitations.
> >>>
> >>>some externals use "proxy objects" for full-fledged
> >>>non-first inlets,
> >>>and those proxies tend to have "hard to type" names as
> >>>well. how do your
> >>>tooltips deal with those?
> >>
> >>So if object "foo" has a 2nd inlet controlled by a proxy object
> >>"bar", which class is referred to by t_object *ob of
> >>glist_drawio in g_text.c: foo or bar?
> >>
> >>>
> >>>gfmasdr
> >>>IOhannes
> >>>
> >>>[1]
> >>>https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> >>>-----BEGIN PGP SIGNATURE-----
> >>>Version: GnuPG v1.4.11 (GNU/Linux)
> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>>
> >>>iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> >>>EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> >>>=XO7J
> >>>-----END PGP SIGNATURE-----
> >>>
> >>>_______________________________________________
> >>>Pd-dev mailing list
> >>>Pd-dev at iem.at
> >>>http://lists.puredata.info/listinfo/pd-dev
> >>>
> >>
> >>_______________________________________________
> >>Pd-dev mailing list
> >>Pd-dev at iem.at
> >>http://lists.puredata.info/listinfo/pd-dev
> >
> >_______________________________________________
> >Pd-dev mailing list
> >Pd-dev at iem.at
> >http://lists.puredata.info/listinfo/pd-dev
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> "[T]he greatest purveyor of violence in the world today [is] my own
> government." - Martin Luther King, Jr.
> 
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


From hans at at.or.at  Fri Jul 15 22:37:11 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 15 Jul 2011 16:37:11 -0400
Subject: [PD-dev] source repo for pd_l2ork
Message-ID: <17AFE877-95FC-44CA-851E-C6ED193D173A@at.or.at>


Is there any source repo like git or SVN for pd_l2ork?  Having that  
would make collaboration much easier.  If there isn't already  
something, I'd recommend starting a git repo for the 'pd' core part  
based on the pure-data git starting at 0.42.6.  That'll also have the  
benefit of making it much easier for pd_l2ork to merge in changes from  
pure-data and pd-extended git.

.hc


----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.




From colet.patrice at free.fr  Sun Jul 17 06:26:06 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Sun, 17 Jul 2011 06:26:06 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1733664051.1933501310876673327.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <861308762.1933591310876766625.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :

> On Jul 11, 2011, at 1:45 PM, Patrice Colet wrote:
> 
> >
> > ----- "Hans-Christoph Steiner" <hans at at.or.at> a ?crit :
> >
> >> On Jul 11, 2011, at 1:29 PM, Hans-Christoph Steiner wrote:
> >>
> >>>
> >>> On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote:
> >>>
> >>>>
> >>>> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
> >>>>
> >>>>> The problem I'm encountering on win32 with makefile.am is that
> >>>>> pd.dll
> >>>>> is not built
> >>>>>
> >>>>>
> >>>>
> >>>> following this doc page:
> >>>>
> >>>>
> >>
> http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html
> >>>>
> >>>> I've added those lines in makefile.am:
> >>>>
> >>>> if WINDOWS
> >>>> LIBS += -lwsock32 -lwinmm -lole32
> >>>> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
> >>>> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
> >>>> lib_LTLIBRARIES = libpd.la
> >>>> libpd_la_SOURCES     = $(pd_sources)
> >>>> libpd_la_LDFLAGS     = -no-undefined
> >>>> pd_LDADD             = libpd.la
> >>>> bin_SCRIPTS =
> >>>> endif
> >>>>
> >
> > <snip>
> >
> >>>> pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined
> reference
> >>
> >>>> to `_imp__pthread_mutex_lock'
> >>>
> >>> try changing:
> >>>
> >>> LIBS += -lwsock32 -lwinmm -lole32
> >>>
> >>> to:
> >>>
> >>> LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
> >>>
> >>> .hc
> >
> > that resolve almost everything, we just need to resolve portaudio  
> > linking
> >
> > pd-s_audio_pa.o:s_audio_pa.c:(.text+0x4a6): undefined reference to 
> 
> > `Pa_IsFormatSupported'
> >
> > <snip>
> >
> > pd-s_audio_pa.o:s_audio_pa.c:(.text+0x179d): undefined reference to 
> 
> > `Pa_GetErrorText
> >
> > -- 
> > Patrice Colet
> 
> 
> Any luck with this?
> 
> .hc
> 
>

Yes, there are several files to modify and the building is quite different, but it seems to work


please could you try this:

--- src/Makefile.am.old 2011-07-17 04:18:39 +0000
+++ src/Makefile.am.new 2011-07-17 04:12:45 +0000
@@ -129,9 +129,15 @@
 endif
 
 if WINDOWS
-LIBS += -lwsock32 -lwinmm -lole32
+lib_LTLIBRARIES = libpd.la 
+#lib_LTLIBRARIES               += ../portaudio/libportaudio.la
+libpd_la_SOURCES     = $(pd_sources)
+libpd_la_LDFLAGS     = -no-undefined
+LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
 pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
 pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
+pd_LDADD += libpd.la
+#pd_LDADD += libportaudio.la
 bin_SCRIPTS = 
 endif
 
@@ -140,7 +146,7 @@
 pd_CFLAGS += -DWISHAPP='"wish85.exe"' -DMSW #kludge, MSW should be _WIN32
 pdsend_CFLAGS += -DMSW #kludge, should use _WIN32
 pdreceive_CFLAGS += -DMSW #kludge, should use _WIN32
-bin_PROGRAMS += pd-watchdog
+#bin_PROGRAMS += pd-watchdog
 endif
 
 etags: TAGS

----------------------------------

there is a typo in configure.ac

--- configure.ac.old    2011-07-17 04:11:39 +0000
+++ configure.ac        2011-07-17 03:53:40 +0000
@@ -138,7 +138,7 @@
 dnl AC_CHECK_HEADER(Jackmp/jack.h, [jack=yes], [jack=no])
 
 dnl portaudio/CoreAudio doesn't work with iPhone
-test x$IPHONEOS = xyes && coreaudio=no
+test x$IPHONEOS = xyes && coreaudio= xno
 
 AM_CONDITIONAL(COREAUDIO, test x$coreaudio = xyes)


the command for building comes from the libtool link:

aclocal && autoheader && libtoolize --force --copy && automake 
--foreign --add-missing --copy && make


I have to put libpthread-2.dll with pd.exe and pd starts :)

Now I have certainly to apply the changes you've discussed with IOhannes to resolve this:

C:\\msys\\1.0\\home\\patko\\pd-extended\\0.43\\packages\\win32_inno\\build\\startup\\libdir.dll: couldn't load
C:/msys/1.0/home/patko/pd-extended/0.43/packages/win32_inno/build/startup/libdir: can't load startup library'!




 
> ----------------------------------------------------------------------------
> 
> I have always wished for my computer to be as easy to use as my  
> telephone; my wish has come true because I can no longer figure out  
> how to use my telephone."  --Bjarne Stroustrup (creator of C++)

lol

-- 
Patrice Colet 


From colet.patrice at free.fr  Mon Jul 18 02:07:54 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 18 Jul 2011 02:07:54 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <981246279.2042181310947453309.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <1621830716.2042241310947674247.JavaMail.root@zimbra4-e1.priv.proxad.net>

I've got asio linking with g++ working, this is explained in here:

http://www.mail-archive.com/libtool at gnu.org/msg11308.html

# ASIO needs to go after PORTAUDIO in order for it to link properly
if ASIO
# automake hack to force linking with g++
SUBDIRS = ../asio
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libpd_la_SOURCES = dummy.cxx
pd_LDADD += ../asio/libasio.la
pd_LINK = $(CXXLINK)
endif

if WINDOWS
lib_LTLIBRARIES += libpd.la 
libpd_la_SOURCES     = $(pd_sources)
libpd_la_LDFLAGS     = -no-undefined
LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
pd_LDADD += libpd.la
bin_SCRIPTS = 
endif

now how can we fix startup/libdir.dll?

when starting pd, console shows:

C:/msys/1.0/home/patko/pd-extended/0.43/packages/win32_inno/build/startup/libdir: can't load startup library'!





From colet.patrice at free.fr  Mon Jul 18 02:59:31 2011
From: colet.patrice at free.fr (Patrice Colet)
Date: Mon, 18 Jul 2011 02:59:31 +0200 (CEST)
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <1621830716.2042241310947674247.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <849785960.2042941310950771321.JavaMail.root@zimbra4-e1.priv.proxad.net>


----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :

> I've got asio linking with g++ working, this is explained in here:
> 
> http://www.mail-archive.com/libtool at gnu.org/msg11308.html
> 
> # ASIO needs to go after PORTAUDIO in order for it to link properly
> if ASIO
> # automake hack to force linking with g++
> SUBDIRS = ../asio
> # Dummy C++ source to cause C++ linking.
> nodist_EXTRA_libpd_la_SOURCES = dummy.cxx
> pd_LDADD += ../asio/libasio.la
> pd_LINK = $(CXXLINK)
> endif
> 
> if WINDOWS
> lib_LTLIBRARIES += libpd.la 
> libpd_la_SOURCES     = $(pd_sources)
> libpd_la_LDFLAGS     = -no-undefined
> LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
> pd_LDADD += libpd.la
> bin_SCRIPTS = 
> endif
> 
> now how can we fix startup/libdir.dll?
> 
> when starting pd, console shows:
> 
> C:/msys/1.0/home/patko/pd-extended/0.43/packages/win32_inno/build/startup/libdir:
> can't load startup library'!
> 
> 

I've tried in packages make install command after doing this into packages/win32_inno/Makefile:

--- Makefile.old        2011-07-18 00:55:45 +0000
+++ Makefile    2011-07-18 00:20:44 +0000
@@ -57,14 +57,14 @@
        @echo "win32_inno install succeeded!"
 
 build_pd:
-       cd $(pd_src)/src && $(MAKE) -f makefile.mingw
+       $(MAKE) -C $(packages_src) $(DEST_PATHS)
 
 PD_NAME=Pd
 pd_install: build_pd
 # the autoconf/MinGW setup doesn't compile the extras yet
 #      $(MAKE) -C $(pd_src)/src $(DEST_PATHS) bin
 #      -$(MAKE) -C $(pd_src)/src $(DEST_PATHS) install
-       $(MAKE) -C $(pd_src)/src -f makefile.mingw $(DEST_PATHS) install
+       $(MAKE) -C $(packages_src) $(DEST_PATHS) install
 # install notes.txt into the help browser
        install -d $(DESTDIR)$(manualsdir)/$(PD_NAME)
        install -p $(pd_src)/src/notes.txt $(DESTDIR)$(manualsdir)/$(PD_NAME)


the build system stops after popping this error:

ln -s ../extra/libdir/libdir.dll \
                /home/patko/pd-extended/0.43/packages/build/startup/libdir.dll
ln: creating symbolic link `/home/patko/pd-extended/0.43/packages/build/startup/libdir.dll' to `../extra/libdir/libdir.dll': No such file or directory
make: *** [pd_install] Error 1

> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-- 
Patrice Colet 


From abonnements at revolwear.com  Mon Jul 18 19:41:27 2011
From: abonnements at revolwear.com (Max)
Date: Mon, 18 Jul 2011 19:41:27 +0200
Subject: [PD-dev] 10.6 64bit autobuild computer will be inaccessible
	until monday
In-Reply-To: <F2DA262A-D5F2-41E0-9CF3-418CBF7A2585@at.or.at>
References: <8837D204-86AA-4027-B4DC-17383E912D4C@revolwear.com>
	<F2DA262A-D5F2-41E0-9CF3-418CBF7A2585@at.or.at>
Message-ID: <E08385D2-8FE6-4CFC-9979-28DDA80D3BD5@revolwear.com>

access has been restored, the remote connection should be working as usual from now on.

Am 12.07.2011 um 05:11 schrieb Hans-Christoph Steiner:
> As long as there is a build tonight, which there should be, we should have a working 10.6 build, so its fine by me.  Thanks for the update!
> 
> .hc
> 
> On Jul 11, 2011, at 6:28 PM, Max wrote:
>> dear devs,
>> 
>> chaos.medien.uni-weimar.de will most probably have downtime until sunday because it's the final week in the semester and we'll transform the room into an exhibition space. I can't say when exactly it will start, maybe tomorrow or on thursday but service will be restored on monday.
>> 
>> sorry for the inconvenience.


From default at spiralix.org  Thu Jul 21 21:26:12 2011
From: default at spiralix.org (Louis-Philippe)
Date: Thu, 21 Jul 2011 15:26:12 -0400
Subject: [PD-dev] async callback?
Message-ID: <CANr+4PtHVWHQbLcTZFJYa-Gs_BX72e6t6Eg_fYkSbX8C+ATp9g@mail.gmail.com>

Hi PD-Dev Peoples,

I was wondering how I should deal with async callbacks inside an external?
What I have in mind:


   1. message sent to external inlet
   2. external proceed to trigger some blocking io with async callback
   3. external sends trigger status on outlet
   4. ticking continues
   5. the blocking io answers with the callback
   6. the external sends result to outlet as result of callback

anybody has a take on these?

regards,

L-P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110721/59c2fa12/attachment.htm>

From zmoelnig at iem.at  Sat Jul 23 15:58:14 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Sat, 23 Jul 2011 15:58:14 +0200
Subject: [PD-dev] async callback?
In-Reply-To: <CANr+4PtHVWHQbLcTZFJYa-Gs_BX72e6t6Eg_fYkSbX8C+ATp9g@mail.gmail.com>
References: <CANr+4PtHVWHQbLcTZFJYa-Gs_BX72e6t6Eg_fYkSbX8C+ATp9g@mail.gmail.com>
Message-ID: <4E2AD376.2080303@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/21/2011 09:26 PM, Louis-Philippe wrote:
> Hi PD-Dev Peoples,
> 
> I was wondering how I should deal with async callbacks inside an external?
> What I have in mind:
> 
> 
>    1. message sent to external inlet
>    2. external proceed to trigger some blocking io with async callback
>    3. external sends trigger status on outlet
>    4. ticking continues
>    5. the blocking io answers with the callback
>    6. the external sends result to outlet as result of callback
> 
> anybody has a take on these?
> 

i use this quite a lot, most prominently probably in "Gem" (which has a
big code-base; a good start would be Gem/Workerthread.cpp and
Gem/SynchedWorkerThread.cpp) and in "iemnet" (much smaller; in C)

the callback-code usually looks like:
1. push the data retrieved async into a (threadsafe) queue
2. notify Pd to do a sync callback using clock_delay(x, 0)
 note that clock_delay itself is not threadsafe (there is a patch in the
sftracker), so you have to protect it using sys_lock() and sys_unlock()
3. when Pd calls back within the main thread, pop the data from the queu
and send it to the output

a more (too) naive way would be to just run outlet_foo() from within the
async callback and protect that with sys_lock()/sys_unlock(); which is
usually less performant as the above, esp. if the async callback might
be called quite often.

a more elaborate way would be to reduce the calls to clock_delay() even
further (as you don't need to call it again, if it has already been
called and not reacted upon yet)

in general you have to be aware, that virtually all functions in Pd are
not threadsafe (e.g. don't use gensym() from within your async
callback!), and the only way to deal with that is using the BIG KERNEL
LOCK with sys_lock() / sys_unlock()

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4q03IACgkQkX2Xpv6ydvTmjACgrea3jIOAnM8LbKl4KEvjrZZl
ZdYAn3owpmIY7ydzYgAlnudX5fntqo0F
=QZQ6
-----END PGP SIGNATURE-----


From pierre at 314r.net  Mon Jul 25 00:02:15 2011
From: pierre at 314r.net (Pierre Mersadier)
Date: Mon, 25 Jul 2011 00:02:15 +0200
Subject: [PD-dev] amd64 pdextended nightly-builds
Message-ID: <1311544935.2538.0.camel@ReepFraag>

Hi list,
it could be nice to provide more 64bits builds of pd-extended,
I've just compiled pdextended on my webserver online 24/7, a debian
squeeze amd_64 and it seams that all went fine. For this I've used the
pd-extended-auto-builder.sh script that does all the job, and I have
also added a cron job to run this script 1 time per day. 
So I have somes questions :

a) how to share this debian package ? Because the final uploading
procedure of pd-extended-auto-builder.sh fail... 
(for now I can host the packages on this webserver :
http://88.191.140.38/ )

b) the final name of the debian package I have is :
Pd-0.43.1-extended-20110724.deb 
which is not as significant as
Pd-0.43.1-extended-debian-squeeze-amd64.deb
so how to improve that ? Edit the Makefile in
pd-extended/packages/linux_make ? rename it by hand... ?

Pierre




From pierre at 314r.net  Sun Jul 24 23:57:37 2011
From: pierre at 314r.net (Pierre Mersadier)
Date: Sun, 24 Jul 2011 23:57:37 +0200
Subject: [PD-dev] amd64 pdextended nightly-builds
Message-ID: <1311544657.1912.67.camel@ReepFraag>

Hi list,
it could be nice to provide more 64bits builds of pd-extended,
I've just compiled pdextended on my webserver online 24/7, a debian
squeeze amd_64 and it seams that all went fine. For this I've used the
pd-extended-auto-builder.sh script that does all the job, and I have
also added a cron job to run this script 1 time per day. 
So I have somes questions :

a) how to share this debian package ? Because the final uploading
procedure of pd-extended-auto-builder.sh fail... 
(for now I can host the packages on this webserver :
http://88.191.140.38/ )

b) the final name of the debian package I have is :
Pd-0.43.1-extended-20110724.deb 
which is not as significant as
Pd-0.43.1-extended-debian-squeeze-amd64.deb
so how to improve that ? Edit the Makefile in
pd-extended/packages/linux_make ? rename it by hand... ?

Pierre



From hans at at.or.at  Mon Jul 25 05:46:28 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Sun, 24 Jul 2011 23:46:28 -0400
Subject: [PD-dev] amd64 pdextended nightly-builds
In-Reply-To: <1311544935.2538.0.camel@ReepFraag>
References: <1311544935.2538.0.camel@ReepFraag>
Message-ID: <58EE2212-A8AC-42D3-965A-D549843426FA@at.or.at>


This is great, Pierre!  The first part is easy, I added your IP to the  
'hosts allow' list for uploaders.  Next time the script runs, it  
should upload.  One minor glitch, the dates are based on NYC/Eastern  
time, so you have to make sure your auto-build doesn't try to upload  
before midnight Eastern (-6 from CET).

The 'debian-squeeze-amd64' part comes from the hostname.  Yours will  
be tagged with whatever hostname your server has, then I'll put a  
little cron'd script to rename it.  I did this for Andras' Ubuntu 64- 
bit builds.

.hc

On Jul 24, 2011, at 6:02 PM, Pierre Mersadier wrote:

> Hi list,
> it could be nice to provide more 64bits builds of pd-extended,
> I've just compiled pdextended on my webserver online 24/7, a debian
> squeeze amd_64 and it seams that all went fine. For this I've used the
> pd-extended-auto-builder.sh script that does all the job, and I have
> also added a cron job to run this script 1 time per day.
> So I have somes questions :
>
> a) how to share this debian package ? Because the final uploading
> procedure of pd-extended-auto-builder.sh fail...
> (for now I can host the packages on this webserver :
> http://88.191.140.38/ )
>
> b) the final name of the debian package I have is :
> Pd-0.43.1-extended-20110724.deb
> which is not as significant as
> Pd-0.43.1-extended-debian-squeeze-amd64.deb
> so how to improve that ? Edit the Makefile in
> pd-extended/packages/linux_make ? rename it by hand... ?
>
> Pierre
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


----------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic




From hans at at.or.at  Wed Jul 27 02:22:07 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Tue, 26 Jul 2011 20:22:07 -0400
Subject: [PD-dev] Pdextended 0.43.1 and vista
In-Reply-To: <849785960.2042941310950771321.JavaMail.root@zimbra4-e1.priv.proxad.net>
References: <849785960.2042941310950771321.JavaMail.root@zimbra4-e1.priv.proxad.net>
Message-ID: <B6DD2EC6-055A-4659-89A0-3ED4D7F547D0@at.or.at>


On Jul 17, 2011, at 8:59 PM, Patrice Colet wrote:

>
> ----- "Patrice Colet" <colet.patrice at free.fr> a ?crit :
>
>> I've got asio linking with g++ working, this is explained in here:
>>
>> http://www.mail-archive.com/libtool at gnu.org/msg11308.html
>>
>> # ASIO needs to go after PORTAUDIO in order for it to link properly
>> if ASIO
>> # automake hack to force linking with g++
>> SUBDIRS = ../asio
>> # Dummy C++ source to cause C++ linking.
>> nodist_EXTRA_libpd_la_SOURCES = dummy.cxx
>> pd_LDADD += ../asio/libasio.la
>> pd_LINK = $(CXXLINK)
>> endif
>>
>> if WINDOWS
>> lib_LTLIBRARIES += libpd.la
>> libpd_la_SOURCES     = $(pd_sources)
>> libpd_la_LDFLAGS     = -no-undefined
>> LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl
>> pd_CFLAGS +=  -DUSEAPI_MMIO -DPD_INTERNAL
>> pd_SOURCES += s_audio_mmio.c s_midi_mmio.c
>> pd_LDADD += libpd.la
>> bin_SCRIPTS =
>> endif
>>
>> now how can we fix startup/libdir.dll?
>>
>> when starting pd, console shows:
>>
>> C:/msys/1.0/home/patko/pd-extended/0.43/packages/win32_inno/build/ 
>> startup/libdir:
>> can't load startup library'!
>>
>>
>
> I've tried in packages make install command after doing this into  
> packages/win32_inno/Makefile:
>
> --- Makefile.old        2011-07-18 00:55:45 +0000
> +++ Makefile    2011-07-18 00:20:44 +0000
> @@ -57,14 +57,14 @@
>        @echo "win32_inno install succeeded!"
>
> build_pd:
> -       cd $(pd_src)/src && $(MAKE) -f makefile.mingw
> +       $(MAKE) -C $(packages_src) $(DEST_PATHS)
>
> PD_NAME=Pd
> pd_install: build_pd
> # the autoconf/MinGW setup doesn't compile the extras yet
> #      $(MAKE) -C $(pd_src)/src $(DEST_PATHS) bin
> #      -$(MAKE) -C $(pd_src)/src $(DEST_PATHS) install
> -       $(MAKE) -C $(pd_src)/src -f makefile.mingw $(DEST_PATHS)  
> install
> +       $(MAKE) -C $(packages_src) $(DEST_PATHS) install
> # install notes.txt into the help browser
>        install -d $(DESTDIR)$(manualsdir)/$(PD_NAME)
>        install -p $(pd_src)/src/notes.txt $(DESTDIR)$(manualsdir)/$ 
> (PD_NAME)
>
>
> the build system stops after popping this error:
>
> ln -s ../extra/libdir/libdir.dll \
>                /home/patko/pd-extended/0.43/packages/build/startup/ 
> libdir.dll
> ln: creating symbolic link `/home/patko/pd-extended/0.43/packages/ 
> build/startup/libdir.dll' to `../extra/libdir/libdir.dll': No such  
> file or directory
> make: *** [pd_install] Error 1


That should work since that happens every night when building with the  
makefile.mingw.  I'll try that once we get the other changes into the  
git.

Do you want to make a git patch for the fixes you've done so far?   
That way you're name will be in the git history, so you'll get credit.

.hc



----------------------------------------------------------------------------

'You people have such restrictive dress for women,? she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - ?Hijab Scene #2", by Mohja Kahf




From noreply at sourceforge.net  Wed Jul 27 06:26:12 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jul 2011 00:26:12 -0400
Subject: [PD-dev] [ pure-data-Patches-3299609 ] [pdp] Compilation option
	change for gcc 4.6
Message-ID: <mailman.50.1311740802.2522.pd-dev@iem.at>

Patches item #3299609, was opened at 2011-05-09 16:10
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3299609&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: externals
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Christoph Steiner (eighthave)
Summary: [pdp] Compilation option change for gcc 4.6

Initial Comment:
A change (bugfix) in gcc 4.6 prevents pdp to compile. The fix is to replace "-export-dynamic" with "-rdynamic" in the Makefiles.
I did not test the change with gcc 4.5 and previous.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-27 00:26

Message:
fixed with this commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=15168

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3299609&group_id=55736


From noreply at sourceforge.net  Wed Jul 27 06:27:00 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jul 2011 00:27:00 -0400
Subject: [PD-dev] [ pure-data-Patches-3299602 ] [pdp] Compilation option
	change for gcc 4.6
Message-ID: <mailman.51.1311740838.2522.pd-dev@iem.at>

Patches item #3299602, was opened at 2011-05-09 15:54
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3299602&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: externals
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Christoph Steiner (eighthave)
Summary: [pdp] Compilation option change for gcc 4.6

Initial Comment:
A change (bugfix) in gcc 4.6 prevents pdp to compile. The fix is to replace "-export-dynamic" with "-rdynamic" in the Makefiles.
I did not test the change with gcc 4.5 and previous.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-27 00:27

Message:
fixed with this commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=15168

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3299602&group_id=55736


From katjavetter at gmail.com  Wed Jul 27 09:39:55 2011
From: katjavetter at gmail.com (katja)
Date: Wed, 27 Jul 2011 09:39:55 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
Message-ID: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>

Hello,

Triggered by a recent thread (
http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html) I've
written alternative code for Pd classes like phasor~, osc~, and vcf~, in
preparation for double precision builds of Pd. These classes currently
employ Hoeldrich's method, a fascinating type punning trick for optimization
of phase-wrapping jobs. Considering available data types in C, this method
can not be translated to double precision input/output format.

Phasor~ and osc~ are typically used by the dozens in Pd setups, and even a
modest performance loss could be a show stopper for setups which are on the
limit of acceptable CPU load. Fortunately it was possible to define
double-ready versions without performance loss, by tedious elimination of
redundancy instead of fancy bit hacking. How often must a phase be wrapped?
Even at high frequencies like half the Nyquist rate, only one in four
iterations goes out of bounds. On average it proves efficient to do the
phase wrapping conditionally. Phasor~ profits most, being up to three times
faster than before, at moderate frequencies. The others did not speed up so
much, but at least none of them is slower than the original version, when
both are compared within the same Pd build. Also, the alternative versions
do not suffer from phase drift, like the Hoeldrich versions do. I have
tested this on OSX / IntelMac for single and double precision builds.
Performance may be different on other platforms / architectures. Macro
PD_BIGORSMALL was redefined to work with arbitrary precision.

A Pd running with PD_FLOATTYPE double immediately shouted at me that there's
a lot more work to do. The audio API (PortAudio in this case) couldn't
handle 64 bit output samples from dac~. Vectors are apparently read as type
float, and maximum level digital noise is the useless output. I've not
delved into this yet. Internally things seems to work well, for what I've
seen so far.

Ah, almost forgot to mention the pro's of a double precision Pd, if it will
ever work:

- indexing of large audio buffers with ample resolution for interpolation
- accurate sine and sinc of small angles, useful for things like fractional
delay
- FFT with frames larger than 2^17, I hope
- long sine sweeps without artifacts
- probably many more of such meticulous dsp jobs, you name them

If you're interested in double precision Pd, please find the attached
pd_doubletest.zip with C code and test-patches. Let me know if you have test
results on different platforms, or if you find stupid bugs in my code. Is
anyone working on other aspects of double precision Pd? I'd like to join
forces.

Katja Vetter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/5c34c628/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pd_doubletest.zip
Type: application/zip
Size: 30102 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/5c34c628/attachment-0001.zip>

From hans at at.or.at  Wed Jul 27 23:11:30 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Wed, 27 Jul 2011 17:11:30 -0400
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
Message-ID: <2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>


Hey Katya,

I'm very happy you're working on this, I think its a big and very  
valuable step for Pd for many reasons.  For me, things like accessing  
large arrays and also working with UNIX timestamps and other large  
integers directly, make Pd a lot easier in cases that touch on those  
limitations.   It brings Pd 99% to the goal of having a generic  
"number" type that handles all the floats and ints that are used with  
any frequency.

Sounds like you've done a fair amount of testing.  I think the big  
question that needs to be answered before this gets included is: can  
this be done without majoring impacting 32-bit operation?  It sounds  
like you've covered that already.  As for 64-bit floats to output, a  
quick hack to get things working is to just hammer samples down to 32- 
bits...

.hc

On Jul 27, 2011, at 3:39 AM, katja wrote:

> Hello,
>
> Triggered by a recent thread (http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html 
> ) I've written alternative code for Pd classes like phasor~, osc~,  
> and vcf~, in preparation for double precision builds of Pd. These  
> classes currently employ Hoeldrich's method, a fascinating type  
> punning trick for optimization of phase-wrapping jobs. Considering  
> available data types in C, this method can not be translated to  
> double precision input/output format.
>
> Phasor~ and osc~ are typically used by the dozens in Pd setups, and  
> even a modest performance loss could be a show stopper for setups  
> which are on the limit of acceptable CPU load. Fortunately it was  
> possible to define double-ready versions without performance loss,  
> by tedious elimination of redundancy instead of fancy bit hacking.  
> How often must a phase be wrapped? Even at high frequencies like  
> half the Nyquist rate, only one in four iterations goes out of  
> bounds. On average it proves efficient to do the phase wrapping  
> conditionally. Phasor~ profits most, being up to three times faster  
> than before, at moderate frequencies. The others did not speed up so  
> much, but at least none of them is slower than the original version,  
> when both are compared within the same Pd build. Also, the  
> alternative versions do not suffer from phase drift, like the  
> Hoeldrich versions do. I have tested this on OSX / IntelMac for  
> single and double precision builds. Performance may be different on  
> other platforms / architectures. Macro PD_BIGORSMALL was redefined  
> to work with arbitrary precision.
>
> A Pd running with PD_FLOATTYPE double immediately shouted at me that  
> there's a lot more work to do. The audio API (PortAudio in this  
> case) couldn't handle 64 bit output samples from dac~. Vectors are  
> apparently read as type float, and maximum level digital noise is  
> the useless output. I've not delved into this yet. Internally things  
> seems to work well, for what I've seen so far.
>
> Ah, almost forgot to mention the pro's of a double precision Pd, if  
> it will ever work:
>
> - indexing of large audio buffers with ample resolution for  
> interpolation
> - accurate sine and sinc of small angles, useful for things like  
> fractional delay
> - FFT with frames larger than 2^17, I hope
> - long sine sweeps without artifacts
> - probably many more of such meticulous dsp jobs, you name them
>
> If you're interested in double precision Pd, please find the  
> attached pd_doubletest.zip with C code and test-patches. Let me know  
> if you have test results on different platforms, or if you find  
> stupid bugs in my code. Is anyone working on other aspects of double  
> precision Pd? I'd like to join forces.
>
> Katja Vetter
> <pd_doubletest.zip>_______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev







----------------------------------------------------------------------------

"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/1423edbb/attachment.htm>

From zmoelnig at iem.at  Wed Jul 27 23:47:42 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Wed, 27 Jul 2011 23:47:42 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
Message-ID: <4E30877E.7040205@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2011 11:11 PM, Hans-Christoph Steiner wrote:
> 
> like you've covered that already.  As for 64-bit floats to output, a
> quick hack to get things working is to just hammer samples down to
> 32-bits...
> 

i don't think that's such a great idea.
loads of problems (mainly with granular synthesis or other applications
where you want to access large tables sample accurately in the signal(!)
flow) can simply be fixed by making signals be 64bit too.

and then, quite some infrastructure code makes no clear separations
between t_float and t_sample, so it might be simpler to make Pd use
doubles throughout and not just for one type of numbers.

gfasdrm
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4wh34ACgkQkX2Xpv6ydvQAnwCeNee8gJz1xUgo5IorIB9JPLXg
fD0AnidU8L4v1WB1VZpQADshUZ5BlUko
=RzYs
-----END PGP SIGNATURE-----


From hans at at.or.at  Wed Jul 27 23:56:01 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Wed, 27 Jul 2011 17:56:01 -0400
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <4E30877E.7040205@iem.at>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
	<4E30877E.7040205@iem.at>
Message-ID: <AD7FB92D-9BF1-4A7F-A0EE-2DCF698692F1@at.or.at>


On Jul 27, 2011, at 5:47 PM, IOhannes m zm?lnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/27/2011 11:11 PM, Hans-Christoph Steiner wrote:
>>
>> like you've covered that already.  As for 64-bit floats to output, a
>> quick hack to get things working is to just hammer samples down to
>> 32-bits...
>>
>
> i don't think that's such a great idea.
> loads of problems (mainly with granular synthesis or other  
> applications
> where you want to access large tables sample accurately in the  
> signal(!)
> flow) can simply be fixed by making signals be 64bit too.
>
> and then, quite some infrastructure code makes no clear separations
> between t_float and t_sample, so it might be simpler to make Pd use
> doubles throughout and not just for one type of numbers.


I'm saying only as the final output stage to portaudio as a temporary  
hack to get things working.  Its not a good idea otherwise.

.hc


----------------------------------------------------------------------------

?We must become the change we want to see. - Mahatma Gandhi



From msp at ucsd.edu  Thu Jul 28 00:48:44 2011
From: msp at ucsd.edu (Miller Puckette)
Date: Wed, 27 Jul 2011 15:48:44 -0700
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <AD7FB92D-9BF1-4A7F-A0EE-2DCF698692F1@at.or.at>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
	<4E30877E.7040205@iem.at>
	<AD7FB92D-9BF1-4A7F-A0EE-2DCF698692F1@at.or.at>
Message-ID: <20110727224844.GH30372@fuzz.ucsd.edu>

Hi all --

I'm not sure it's done right, but my intention in s_audio_pa.c is to
use 'float' when talking to the portaudio API and t_sample to talk to
the rest of Pd -- so t_sample could be made double without affecting
portaudio.   

The only situation I can imagine in which t_sample might want to differ
from t_float is to do ficed-point audio... but I think nowadays that's
almost never needed.

cheers
Miller

On Wed, Jul 27, 2011 at 05:56:01PM -0400, Hans-Christoph Steiner wrote:
> 
> On Jul 27, 2011, at 5:47 PM, IOhannes m zm?lnig wrote:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On 07/27/2011 11:11 PM, Hans-Christoph Steiner wrote:
> >>
> >>like you've covered that already.  As for 64-bit floats to output, a
> >>quick hack to get things working is to just hammer samples down to
> >>32-bits...
> >>
> >
> >i don't think that's such a great idea.
> >loads of problems (mainly with granular synthesis or other
> >applications
> >where you want to access large tables sample accurately in the
> >signal(!)
> >flow) can simply be fixed by making signals be 64bit too.
> >
> >and then, quite some infrastructure code makes no clear separations
> >between t_float and t_sample, so it might be simpler to make Pd use
> >doubles throughout and not just for one type of numbers.
> 
> 
> I'm saying only as the final output stage to portaudio as a
> temporary hack to get things working.  Its not a good idea
> otherwise.
> 
> .hc
> 
> 
> ----------------------------------------------------------------------------
> 
> ?We must become the change we want to see. - Mahatma Gandhi
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


From katjavetter at gmail.com  Thu Jul 28 02:15:42 2011
From: katjavetter at gmail.com (katja)
Date: Thu, 28 Jul 2011 02:15:42 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
Message-ID: <CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>

On Wed, Jul 27, 2011 at 11:11 PM, Hans-Christoph Steiner <hans at at.or.at>wrote:

>> I think the big question that needs to be answered before this gets
included is:
>> can this be done without majoring impacting 32-bit operation?

The intention is:
- Pd source code with unaltered functionality
- compilable with pd floattype 'float' or 'double'
- as little conditional compilation as possible
- no performance loss respective to current Pd

Based on test results I think it's possible to rewrite the code in such a
way that single precision Pd will not be affected in any way. I still have
to rewrite tabosc~ which also uses Hoeldrich's method, this will be easy.

>> As for 64-bit floats to output, a quick hack to get things working is
>> to just hammer samples down to 32-bits...

I was looking for a suitable spot in the code to do this. First looked at
dac~, but since there may be many dac~s instantiated this is not most
efficient. Then I found sys_send_dacs(), where the integrated sample values
are checked for max absolute value. It is however not possible to do a
simple typecast here because samples are just stored back into *sys_soundin
and *sys_soundout which are type t_sample. Maybe dac~ should integrate
samplevalues in an intermediate vector of type t_sample. And then, in
sys_send_dacs(),
integrated samples could be checked, cast to float and stored into
*sys_soundout
vector of type float. And something similar for the input. That's what I'll
try.

Katja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110728/83b4dfb7/attachment-0001.htm>

From noreply at sourceforge.net  Thu Jul 28 05:17:54 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jul 2011 11:17:54 +0800
Subject: [PD-dev] [ pure-data-Bugs-3380575 ] [makefilename] patch reliably
	segfaults
Message-ID: <mailman.52.1311823106.2522.pd-dev@iem.at>

Bugs item #3380575, was opened at 2011-07-28 11:17
Message generated for change (Tracker Item Submitted) made by chr15m
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3380575&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris McCormick (chr15m)
Assigned to: Nobody/Anonymous (nobody)
Summary: [makefilename] patch reliably segfaults

Initial Comment:
Attached is a patch that reliably segfaults Pd.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3380575&group_id=55736


From zmoelnig at iem.at  Thu Jul 28 11:53:03 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Thu, 28 Jul 2011 11:53:03 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
	<CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>
Message-ID: <4E31317F.7060805@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/28/2011 02:15 AM, katja wrote:
> I was looking for a suitable spot in the code to do this. First looked at
> dac~, but since there may be many dac~s instantiated this is not most
> efficient. Then I found sys_send_dacs(), where the integrated sample values
> are checked for max absolute value. It is however not possible to do a
> simple typecast here because samples are just stored back into *sys_soundin
> and *sys_soundout which are type t_sample. Maybe dac~ should integrate
> samplevalues in an intermediate vector of type t_sample. And then, in
> sys_send_dacs(),
> integrated samples could be checked, cast to float and stored into
> *sys_soundout
> vector of type float. And something similar for the input. That's what I'll
> try.
> 

imho, the only sensible place to do this is the actual audio backend
code (s_audio_*.c), since your audio backend might support double floats
(e.g. jackd is prepared for that already, though i don't known whether
anybody ever used it that way).

you don't want to do the calculations in double, then convert to single
only to output as double, do you?

fgmadr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xMXsACgkQkX2Xpv6ydvRedACeLQ+kcKMaXRwz4n6p2Dquje4P
118AoKXn+0TMlRKSO7VPrc9HOZO/Vu88
=X+v+
-----END PGP SIGNATURE-----


From noreply at sourceforge.net  Thu Jul 28 12:49:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jul 2011 12:49:07 +0200
Subject: [PD-dev] [ pure-data-Patches-3380575 ] [makefilename] patch
	reliably segfaults
Message-ID: <mailman.54.1311850181.2522.pd-dev@iem.at>

Patches item #3380575, was opened at 2011-07-28 05:17
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: puredata
>Group: None
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Chris McCormick (chr15m)
>Assigned to: Miller Puckette (millerpuckette)
Summary: [makefilename] patch reliably segfaults

Initial Comment:
Attached is a patch that reliably segfaults Pd.

----------------------------------------------------------------------

>Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-28 12:49

Message:
attached is a patch that checks whether there are multiple format
specifiers, and if so, complains and refuses to work.
this effectively prevents the crash (though it still does not enable
multiple format specifiers)

the patch applies to todays git master.
raised priority since it is a crasher bug.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-28 12:46

Message:
while the docs are a bit confusion about this, [makefilename] really can
only handle a _single_ format specifier;

so using a format-string like "%s-%s" is illegal.

however, Pd should never segfault

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&group_id=55736


From katjavetter at gmail.com  Thu Jul 28 22:47:57 2011
From: katjavetter at gmail.com (katja)
Date: Thu, 28 Jul 2011 22:47:57 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <4E31317F.7060805@iem.at>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
	<CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>
	<4E31317F.7060805@iem.at>
Message-ID: <CAFY0earADP3JMdrpQdY_0+87W5vCJ3rBV4omWb63epORvwj_Fw@mail.gmail.com>

2011/7/28 IOhannes m zm?lnig <zmoelnig at iem.at> wrote:
>
>
> imho, the only sensible place to do this is the actual audio backend
> code (s_audio_*.c)


right


> your audio backend might support double floats
> (e.g. jackd is prepared for that already, though i don't known whether
> anybody ever used it that way).
>

Thanks for pointing to that. Anyway some sort of galvanic separation between
arrays with t_sample and arrays passed from/to audio API must be introduced,
in case they need be of different (primitive) type. PortAudio does not
currently support 64 bit samples, for one thing. My first concern is to hear
decent sound coming out of double precision Pd, that would really make me
happy for a while.....

Katja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110728/4726c470/attachment.htm>

From noreply at sourceforge.net  Thu Jul 28 23:24:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jul 2011 21:24:28 +0000
Subject: [PD-dev] [ pure-data-Bugs-3381374 ] tabread4 doesn't respond to set
	messages
Message-ID: <mailman.55.1311888310.2522.pd-dev@iem.at>

Bugs item #3381374, was opened at 2011-07-28 21:24
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3381374&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: v0.42
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: tabread4 doesn't respond to set messages

Initial Comment:
Set messages do not affect the array argument to tabread4. Visit "help" subpatch for tabread4. Change [tabread4~ array99] to [tabread4~ array]. Bang [set array99(. Still reads [tabread4~ array].

Pd 0.42.5-extended
Mac OS X 10.6.8/Intel.
built-in sound

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3381374&group_id=55736


From hans at at.or.at  Fri Jul 29 01:42:05 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 28 Jul 2011 19:42:05 -0400
Subject: [PD-dev] amd64 pdextended nightly-builds
In-Reply-To: <1311853185.5830.117.camel@ReepFraag>
References: <1311544935.2538.0.camel@ReepFraag>
	<58EE2212-A8AC-42D3-965A-D549843426FA@at.or.at>
	<1311580364.2113.16.camel@ReepFraag>
	<2FB4A11D-A48C-4F9B-8148-C17891AF9A3F@at.or.at>
	<1311853185.5830.117.camel@ReepFraag>
Message-ID: <B1B5BCA3-751F-4B12-B229-9894FE5D1801@at.or.at>


On Jul 28, 2011, at 7:39 AM, Pierre Mersadier wrote:

> Hi HansChristoph,
>
> Le mardi 26 juillet 2011 ? 14:04 -0400, Hans-Christoph Steiner a  
> ?crit :
>> Ok, its posting now on the auto-builds page :)
>>
>> .hc
>
> I now trying to work with pbuilder which seems to be a very good  
> tool to
> build debian packages for differents versions of debian/ubuntu
> distributions, my goal is to provide multiples x86_64 builds for  
> ubuntu
> natty/maverick/etc/... and debian stable/unstable/etc/... all these
> builds could be done on the same 64bits computer.
> From what I understand it is really doable with pbuilder, I did some
> tests this morning.

> somes questions/remarks :
>
> A) is there some debian rules for the whole pdextended source tree ?
> 'pd-extended/pd' contains './debian 'but if I run pdebuild it seems it
> build only pd and not all the externals...
> see logs : http://pastebin.com/EK8MhaDj
>
> B) alsoI had to delete pd/debian/patches/* because pdebuil wasn't able
> to apply patches to the source tree :
> <snip...>
> 	quilt --quiltrc /dev/null push -a || test $? = 2
> Applying patch 01_big_endian.diff
> patching file src/s_audio_alsa.c
> Hunk #1 FAILED at 469.
> Hunk #2 FAILED at 581.
> 2 out of 2 hunks FAILED -- rejects in file src/s_audio_alsa.c
> Patch 01_big_endian.diff does not apply (enforce with -f)
> dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2
> returned exit code 1
> make: *** [build] Error 25
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> E: Failed autobuilding of package
> I: unmounting /var/cache/pbuilder/ccache filesystem
> I: unmounting dev/pts filesystem
> I: unmounting proc filesystem
> I: cleaning the build env
> I: removing directory /var/cache/pbuilder/build//10491 and its
> subdirectories
>
>
>
> So, on my free time I'll continue to test/learn because these tools
> seems very powerfull !

This would be really awesome to have all those builds.  pbuilder is a  
very powerful tool, but sadly, the Pd-extended package is a big hack  
and not created in a way that'll let you use pbuilder, as far as I  
know.  Instead, I've been setting up chroots with debootstrap.  The  
build scripts can already handle many chroots as long as they are in / 
var/chroot.

> Do you go to the pdcon 2011 in weimar ?

My wife and I just had a baby one week ago, so I can't go this year.   
I've been to every other, and almost nothing else would have made me  
miss the PdCon.  Its always been a great time and immersive experience.

.hc



----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.




From hans at at.or.at  Sat Jul 30 00:52:24 2011
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 29 Jul 2011 18:52:24 -0400
Subject: [PD-dev] amd64 pdextended nightly-builds
In-Reply-To: <1311929042.2909.44.camel@ReepFraag>
References: <1311544935.2538.0.camel@ReepFraag>
	<58EE2212-A8AC-42D3-965A-D549843426FA@at.or.at>
	<1311580364.2113.16.camel@ReepFraag>
	<2FB4A11D-A48C-4F9B-8148-C17891AF9A3F@at.or.at>
	<1311853185.5830.117.camel@ReepFraag>
	<B1B5BCA3-751F-4B12-B229-9894FE5D1801@at.or.at>
	<1311929042.2909.44.camel@ReepFraag>
Message-ID: <3AD6FBA8-B8FC-4315-A22F-F586AA867BB2@at.or.at>


On Jul 29, 2011, at 4:44 AM, Pierre Mersadier wrote:

> Le jeudi 28 juillet 2011 ? 19:42 -0400, Hans-Christoph Steiner a  
> ?crit :
>> On Jul 28, 2011, at 7:39 AM, Pierre Mersadier wrote:
>>
>>> Hi HansChristoph,
>>>
>>> Le mardi 26 juillet 2011 ? 14:04 -0400, Hans-Christoph Steiner a
>>> ?crit :
>>>> Ok, its posting now on the auto-builds page :)
>>>>
>>>> .hc
>>>
>>> I now trying to work with pbuilder which seems to be a very good
>>> tool to
>>> build debian packages for differents versions of debian/ubuntu
>>> distributions, my goal is to provide multiples x86_64 builds for
>>> ubuntu
>>> natty/maverick/etc/... and debian stable/unstable/etc/... all these
>>> builds could be done on the same 64bits computer.
>>> From what I understand it is really doable with pbuilder, I did some
>>> tests this morning.
>>
>>> somes questions/remarks :
>>>
>>> A) is there some debian rules for the whole pdextended source tree ?
>>> 'pd-extended/pd' contains './debian 'but if I run pdebuild it  
>>> seems it
>>> build only pd and not all the externals...
>>> see logs : http://pastebin.com/EK8MhaDj
>>>
>>> B) alsoI had to delete pd/debian/patches/* because pdebuil wasn't  
>>> able
>>> to apply patches to the source tree :
>>> <snip...>
>>> 	quilt --quiltrc /dev/null push -a || test $? = 2
>>> Applying patch 01_big_endian.diff
>>> patching file src/s_audio_alsa.c
>>> Hunk #1 FAILED at 469.
>>> Hunk #2 FAILED at 581.
>>> 2 out of 2 hunks FAILED -- rejects in file src/s_audio_alsa.c
>>> Patch 01_big_endian.diff does not apply (enforce with -f)
>>> dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2
>>> returned exit code 1
>>> make: *** [build] Error 25
>>> dpkg-buildpackage: error: debian/rules build gave error exit  
>>> status 2
>>> E: Failed autobuilding of package
>>> I: unmounting /var/cache/pbuilder/ccache filesystem
>>> I: unmounting dev/pts filesystem
>>> I: unmounting proc filesystem
>>> I: cleaning the build env
>>> I: removing directory /var/cache/pbuilder/build//10491 and its
>>> subdirectories
>>>
>>>
>>>
>>> So, on my free time I'll continue to test/learn because these tools
>>> seems very powerfull !
>>
>> This would be really awesome to have all those builds.  pbuilder is a
>> very powerful tool, but sadly, the Pd-extended package is a big hack
>> and not created in a way that'll let you use pbuilder, as far as I
>> know.  Instead, I've been setting up chroots with debootstrap.  The
>> build scripts can already handle many chroots as long as they are  
>> in /
>> var/chroot.
>
> Ok, I can try the chroot method, in fact I have already have a  
> chrooted
> env for ubuntu on this server, but the way pbuilder works is just  
> great
> (a one line command for build !).
> Build in a chroot environment seems to me much harder, as I dont know
> how to tell cron to run the comand inside the chrooted env...

The build script already changes to each chroot. You just need to cron  
the ~pd/auto-build/pd-extended/scripts/auto-build/run-automated- 
builder build script, then it'll look into ~pd/auto-build for builds  
to run (in the form of named folders, i.e. pd-extended). And it'll run  
the pd-extended-auto-builder.sh in each chroot it finds in /var/chroot.

> (Also I understand that the only thing that pbuilder/pdebuild miss
> is ./debian folders (rules, changelog, etc) in each project (every
> externals and pd)... Maybe it is not a big deal as we can provide  
> empty
> or fake infos to satisfy pdebuild ??)

There is no debian/rules for that package.  My guess is that it would  
be a fair amount of work, but I could be wrong.  Plus if that approach  
is more interesting to you, that'll probably mean that more work  
that's interesting is better than less annoying work.

.hc


>>> Do you go to the pdcon 2011 in weimar ?
>>
>> My wife and I just had a baby one week ago, so I can't go this year.
>> I've been to every other, and almost nothing else would have made me
>> miss the PdCon.  Its always been a great time and immersive  
>> experience.
>
> I understand what you mean, I have 2 boys : 2 and 9 years old, and  
> they
> take a loooooot of time and energy, but hey! I love them ! :D
>
> we keep in touch,
> pierre
>



----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams




From katjavetter at gmail.com  Sat Jul 30 13:04:40 2011
From: katjavetter at gmail.com (katja)
Date: Sat, 30 Jul 2011 13:04:40 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <CAFY0earADP3JMdrpQdY_0+87W5vCJ3rBV4omWb63epORvwj_Fw@mail.gmail.com>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>
	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>
	<CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>
	<4E31317F.7060805@iem.at>
	<CAFY0earADP3JMdrpQdY_0+87W5vCJ3rBV4omWb63epORvwj_Fw@mail.gmail.com>
Message-ID: <CAFY0eaoEoVXkSf9zVzAzEaJuv=2iy8zMj4AWc+n2J-YqZZri7w@mail.gmail.com>

Managed to get a double precision Pd working with PortAudio, after small
modifications in s_audio_pa.c.

In function pa_open_audio(), *soundin and *soundout (pointers to type
t_sample) used to be aliased to *pa_soundin resp. *pa_soundout, pointers to
type float. If instead, *pa_soundin and *pa_soundout (and it's own aliases)
are declared of type t_sample, the hard copying of samples from PortAudion
arrays to Pd arrays and vice versa does the typecast between types of
different sizes correctly (tested for Pd 0.42.6, I'll do it for 0.43 soon as
possible).

Since I am not familiar with this part of Pd code, my proceedings are slow
and I've not found the time to scan s_audio_jack.c, s_audio_alsa.c etcetera
for similar issues. Yet, on the dsp side of things, I feel we're close to a
properly functioning double precision Pd.
>
>
In the meantime I'd like to toss another topic of concern. While testing, I
found that a single precision Pd can easily load double precision
executables if they are present in the search path for some reason. The
other way round will undoubtedly be possible as well - the C symbols in
single and double precision builds are identical. Pd crashes on such a size
mismatch. Some protection against the loading of 'type aliens' must be
implemented before double precision Pd (and externals in particular) can be
distributed as stable release, whenever that will happen. And this
protection must preferably be backwards compatible, in such a way that old
Pd installations from the 'single only era' can not accidentally load new
double precision classes.


Katja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110730/62061f63/attachment.htm>

From zmoelnig at iem.at  Sat Jul 30 16:04:30 2011
From: zmoelnig at iem.at (=?ISO-8859-1?Q?IOhannes_m_zm=F6lnig?=)
Date: Sat, 30 Jul 2011 16:04:30 +0200
Subject: [PD-dev] preparing phasor~&Co. for double precision Pd
In-Reply-To: <CAFY0eaoEoVXkSf9zVzAzEaJuv=2iy8zMj4AWc+n2J-YqZZri7w@mail.gmail.com>
References: <CAFY0eaph8Wrd_tdjzVTA=X3hmMTjzLEKSG6mSy+wbA-KM56iiA@mail.gmail.com>	<2F8D2E62-5329-40C1-A63F-AB597C1B63FB@at.or.at>	<CAFY0eaoxdme16QQPtz2cGhr+acuuQZh0XkWn=u8UnXgs77mtSQ@mail.gmail.com>	<4E31317F.7060805@iem.at>	<CAFY0earADP3JMdrpQdY_0+87W5vCJ3rBV4omWb63epORvwj_Fw@mail.gmail.com>
	<CAFY0eaoEoVXkSf9zVzAzEaJuv=2iy8zMj4AWc+n2J-YqZZri7w@mail.gmail.com>
Message-ID: <4E340F6E.1080006@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/30/2011 01:04 PM, katja wrote:

> Since I am not familiar with this part of Pd code, my proceedings are slow
> and I've not found the time to scan s_audio_jack.c, s_audio_alsa.c etcetera
> for similar issues. Yet, on the dsp side of things, I feel we're close to a
> properly functioning double precision Pd.

i had correct output using double precision samples using (iirc) ALSA
and jack, back then when i started the patch set (which eventually made
it into Pd-0.42), so that shouldn't be a problem.

looking at the code, the relevant changes are definitely there for jack;
and alsa will most likely work if it's not trying to do mmap() - if the
device does support mmap  we might have problems.

> distributed as stable release, whenever that will happen. And this
> protection must preferably be backwards compatible, in such a way that old
> Pd installations from the 'single only era' can not accidentally load new
> double precision classes.

totally true.


fmgsadr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk40D24ACgkQkX2Xpv6ydvSWVACg2WVSLxH+BdHmOF4dlLqmkxwm
yDEAoIwLp9IWpRUFSlpovmtTDr2sjnQl
=F4Hv
-----END PGP SIGNATURE-----


From noreply at sourceforge.net  Sat Jul 30 21:41:24 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Jul 2011 12:41:24 -0700
Subject: [PD-dev] [ pure-data-Patches-3336039 ] fix Windows non-starting
Message-ID: <mailman.58.1312054917.2522.pd-dev@iem.at>

Patches item #3336039, was opened at 2011-06-26 20:11
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix Windows non-starting

Initial Comment:
Removed bizarre 'k' character in 'package' command, causing Windows to not start.  This was in the proc get_config_win in tcl/pd_guiprefs.tcl.  My smallest patch ever, literally changing one character ;)


----------------------------------------------------------------------

>Comment By: Miller Puckette (millerpuckette)
Date: 2011-07-30 12:41

Message:
applied

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 11:23

Message:
Martin Peach found another ? in pd_guiprefs.tcl, the updated patch fixes
it.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 11:21

Message:
This artifact has been marked as a duplicate of artifact 3307680 with
reason:
separate patch tracker item

----------------------------------------------------------------------

Comment By: Yvan Volochine (elgusanorojo)
Date: 2011-06-27 03:34

Message:
oops, my mistake (k with an accent), thanks for spotting.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736


From noreply at sourceforge.net  Sat Jul 30 21:41:44 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Jul 2011 12:41:44 -0700
Subject: [PD-dev] [ pure-data-Patches-3336039 ] fix Windows non-starting
Message-ID: <mailman.59.1312054928.2522.pd-dev@iem.at>

Patches item #3336039, was opened at 2011-06-26 20:11
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
>Status: Pending
>Resolution: Accepted
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix Windows non-starting

Initial Comment:
Removed bizarre 'k' character in 'package' command, causing Windows to not start.  This was in the proc get_config_win in tcl/pd_guiprefs.tcl.  My smallest patch ever, literally changing one character ;)


----------------------------------------------------------------------

Comment By: Miller Puckette (millerpuckette)
Date: 2011-07-30 12:41

Message:
applied

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 11:23

Message:
Martin Peach found another ? in pd_guiprefs.tcl, the updated patch fixes
it.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-07-01 11:21

Message:
This artifact has been marked as a duplicate of artifact 3307680 with
reason:
separate patch tracker item

----------------------------------------------------------------------

Comment By: Yvan Volochine (elgusanorojo)
Date: 2011-06-27 03:34

Message:
oops, my mistake (k with an accent), thanks for spotting.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3336039&group_id=55736


From noreply at sourceforge.net  Sat Jul 30 21:50:42 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Jul 2011 12:50:42 -0700
Subject: [PD-dev] [ pure-data-Patches-3307503 ] segfault in DSP-loop
	detection
Message-ID: <mailman.60.1312055458.2522.pd-dev@iem.at>

Patches item #3307503, was opened at 2011-05-25 06:32
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307503&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
>Status: Pending
>Resolution: Accepted
Priority: 8
Private: No
Submitted By: IOhannes m zm?lnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: segfault in DSP-loop detection

Initial Comment:
given a patch that contains a DSP-loop _and_ an [inlet~] _and_ and [outlet~]  (see attached patch).

if this file is opened as a toplevel patch (via File->Open) and you then turn on DSP, Pd will segfault.

if [outlet~] is missing, Pd will give an error about "DSP-loop detected" and refuses to calculate (which is ok and expected).
however, a segfault is not ok.

----------------------------------------------------------------------

>Comment By: Miller Puckette (millerpuckette)
Date: 2011-07-30 12:50

Message:
applied

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-05-25 06:36

Message:
hunting down the bug i found that it crashes in the "fill borrowed outputs"
loop around d_ugen.c:1064.
the crash happens because dc_iosigs==NULL (due to the patch being run as
toplevel ) and dc_noutlets==dc_ninlets==1 (because there is inlet~ and
outlet~).

this combination leads to an access of (*dc_iosigs)->s_borrowedFrom which
is invalid (dc_iosigs==NULL)

the attached patch tries to fix the underlying problem, by forcing
dc_noutlets=dc_ninlets=0 if the toplevel flag is set.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307503&group_id=55736


From noreply at sourceforge.net  Sat Jul 30 22:47:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 30 Jul 2011 13:47:07 -0700
Subject: [PD-dev] [ pure-data-Patches-3380575 ] [makefilename] patch
	reliably segfaults
Message-ID: <mailman.63.1312058850.2522.pd-dev@iem.at>

Patches item #3380575, was opened at 2011-07-27 20:17
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Chris McCormick (chr15m)
Assigned to: Miller Puckette (millerpuckette)
Summary: [makefilename] patch reliably segfaults

Initial Comment:
Attached is a patch that reliably segfaults Pd.

----------------------------------------------------------------------

>Comment By: Miller Puckette (millerpuckette)
Date: 2011-07-30 13:47

Message:
This is rather confusingly written (and badly indented)... I'd suggest
having makefilename_scanformat()
simply scan through the string in one pass.  I can hack on this later if
necessary.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-28 03:49

Message:
attached is a patch that checks whether there are multiple format
specifiers, and if so, complains and refuses to work.
this effectively prevents the crash (though it still does not enable
multiple format specifiers)

the patch applies to todays git master.
raised priority since it is a crasher bug.

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2011-07-28 03:46

Message:
while the docs are a bit confusion about this, [makefilename] really can
only handle a _single_ format specifier;

so using a format-string like "%s-%s" is illegal.

however, Pd should never segfault

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3380575&group_id=55736


From jancsika at yahoo.com  Sun Jul 31 07:12:45 2011
From: jancsika at yahoo.com (Jonathan Wilkes)
Date: Sat, 30 Jul 2011 22:12:45 -0700 (PDT)
Subject: [PD-dev] menu checkbutton
Message-ID: <1312089165.18812.YahooMailNeo@web39408.mail.mud.yahoo.com>

Hi,
???? What is the reason the "Editmode" menu checkbutton is changed to green on TRUE and has option "-selectcolor grey85" instead of just a default black check?

I tried making a demo menu with a checkbutton in wish (8.5) and didn't see any obvious bugs in MacOS Lion, WinXP, or Fedora15 with Gnome Shell.? Additionally I could just set the variable associated with the widget, and the menu checkbutton would update correctly.

-Jonathan