from:"IOhannes m zmoelnig"

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-30 22:41, Hans-Christoph Steiner wrote:
 
 Having the name SHARED_SOURCE singular highlights that its a single file, 
 which I think it should be.  But since its an internal variable, I would be 
 OK with it having a different name.

i really cannot understand, why SHARED_SOURCE _should_ only be a single
file. do you have any reference that claims that single-file libraries
are somewhat superior (e.g. less confusing to the casual onlooker)?

anyhow...

 
 I don't see a gain to making it multiple files, unless you are doing 
 something very complicated, in which case, you'll need to customize the 
 Makefile.  At that point, the Makefile is easy enough to read for someone who 
 does Makefiles, so they don't need it documented.
 
 - - standardize the shared library name to lib$(LIBNAME).$(EXT)

 that is all.

 It already is:
 
 SHARED_SOURCE ?= $(wildcard lib$(LIBRARY_NAME).c)
 SHARED_HEADER ?= $(shell test ! -e $(LIBRARY_NAME).h || echo 
 $(LIBRARY_NAME).h)
 SHARED_LIB = $(SHARED_SOURCE:.c=.$(SHARED_EXTENSION))

not really.
SHARED_LIB is generated by replacing all .c extension by
.$(SHARED_EXTENSION) within SHARED_SOURCE, which is a space delimited
list of tokens.
your SHARED_SOURCE happens to consist only of a single token, but at the
same time it is settable by the user (and indeed documents that it could
be overridden by the use of ?=)

whereas LIBRARY_NAME is documented to be a single name (well i thought
so; i cannot find any reference to this either)

if we leave variable names as they are, my proposed change is a
one-liner (see attachment)


 SHARED_TCL_LIB = $(wildcard lib$(LIBRARY_NAME).tcl)

does this already do anything?
it seems like the only use of SHARED_TCL_LIB is within the showsetup
target.

 I figured you'd want something more complicated, so I put in the ?= for you.  
 Like before with ALL_*, take the template and modify it for your library. If 
 its implemented in a way that still meets the goal of a simple interface, 
 I'll merge it in.

ah, we should create some code for me to say this is _really_ a simple
change

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

iEYEARECAAYFAk6uYhQACgkQkX2Xpv6ydvQXKwCg8aASpKApdG7MLDffKHtlrWF8
JTQAoJ7CrewiC49OnefL2oKyL9bsCM34
=yPTG
-END PGP SIGNATURE-
--- Makefile.template   2011-10-31 09:36:43.0 +0100
+++ Makefile2011-10-31 09:41:03.0 +0100
@@ -234,7 +234,7 @@
 
 SHARED_SOURCE ?= $(wildcard lib$(LIBRARY_NAME).c)
 SHARED_HEADER ?= $(shell test ! -e $(LIBRARY_NAME).h || echo $(LIBRARY_NAME).h)
-SHARED_LIB = $(SHARED_SOURCE:.c=.$(SHARED_EXTENSION))
+SHARED_LIB ?= lib$(LIBRARY_NAME:=.$(SHARED_EXTENSION))
 SHARED_TCL_LIB = $(wildcard lib$(LIBRARY_NAME).tcl)
 
 .PHONY = install libdir_install single_install install-doc install-examples 
install-manual clean distclean dist etags $(LIBRARY_NAME)


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building iemnet on Windows and OS X

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-30 20:03, Roman Haefeli wrote:
 
 Building iemnet on the Windows build machine still failed:
 http://autobuild.puredata.info/auto-build/2011-10-30/logs/2011-10-30_03.31.00_mingw32_nt-5.1_windowsxp-i386_pd-extended.txt

seems like the template/Makefile assumes that the shared code doesn't
know anything about Pd.

i'd like to hear hans' opinion about this (e.g. why)

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

iEYEARECAAYFAk6uY2YACgkQkX2Xpv6ydvSCdgCgnXbVGsKugtbs+zU3BBzHEb5m
5hcAoPOBybJi9B1+ujgJSFPcvIXfc6nX
=TISG
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building iemnet on Windows and OS X

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-31 15:39, Hans-Christoph Steiner wrote:
 
 On Oct 31, 2011, at 4:59 AM, IOhannes m zmoelnig wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2011-10-30 20:03, Roman Haefeli wrote:

 Building iemnet on the Windows build machine still failed:
 http://autobuild.puredata.info/auto-build/2011-10-30/logs/2011-10-30_03.31.00_mingw32_nt-5.1_windowsxp-i386_pd-extended.txt

 seems like the template/Makefile assumes that the shared code doesn't
 know anything about Pd.

 i'd like to hear hans' opinion about this (e.g. why)
 
 Hmm, probably purely because the shared library is not linking against 
 pd.dll.  Perhaps there are issues with that many circular links in Windows.  
 I know that Windows linking is testy, that's why there is a pd.exe which 
 links to a pd.dll.  Try linking the shared library to pd and see if it works.
 

what i meant is, that the PD_INCLUDES do not get propagated to the
SHARED_CFLAGS, hence the compiler cannot find headers like m_pd.h;
once that is done, we will get to the linker problems.

but all there problems are solved for the external itself, so i wondered
whether there is a reason to not apply those flags to the shared code.

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

iEYEARECAAYFAk6utKsACgkQkX2Xpv6ydvRDHACfcRrlQhYyhc7TPpq8BTr77mTo
FPgAnA9ZLY8WCo3yg3+i2sFcwZ/tRbs3
=Jf/+
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to load shared code for libraries

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-31 15:35, Hans-Christoph Steiner wrote:
 
 You should create some code that solves your issue in your library.  Then 
 we'll take it from there.
 

hmm, the diff i posted was a cleaned up diff taken from
iem/iemnet/Makefile.

the code is already working
(well kindof, if we don't take the w32 problems into account which are a
different problem)

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

iEYEARECAAYFAk6utRcACgkQkX2Xpv6ydvTwlACdEAFkdor6BDtL4RgWFVNwjJDh
LRgAmQHfcfkHetQU8JqclLDswHNv2EHN
=PZhY
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] signal object test template for automated unit testing

2011-10-27 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-26 19:29, katja wrote:
 Hello,
 
 Here is a .zip with an improved method for unit-testing of signal

before the list gets flooded with updates of updates of zip archives
with the current installment of the unit-testing framework, how about
getting write access to the repository (katja, you already have that,
don't you?) and create a new folder unittests?

i would probably put that into TRUNK/externals/unittests (which really
should read TRUNK/libraries :-)) for now, and later move it into TRUNK/.
or start right away with TRUNK/unittests

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

iEYEARECAAYFAk6pDPEACgkQkX2Xpv6ydvT+SACeNgjXvoSMzXke5U/6FhxJbOjJ
dEkAnRmKt7Y2UqDni9Wx0c4aqNsWG7K8
=dQaT
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 'tests' section of pure-data/trunk svn?

2011-10-24 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-24 22:10, Marvin Humphrey wrote:
 
 I propose we use the suffix -regressiontest.pd for tests, then we can 
 have a script that crawls the whole pure-data SVN and runs the tests in 
 place with the libraries they are part of.  (-test.pd is already used a 
 lot of places, so a new suffix would be better to avoid confusion).

how about adding a check target (which i think is the standard target
to run regression tests) to the template/Makefile, in order to run the
actual tests?

e.g.
$ make check -C zexy
make  check-TESTS
make[2]: Entering directory
`/Net/iem/Benutzer/zmoelnig/src/cvs/pure-data/externals/zexy/tests'
running tests in .
./absgn~/abs: OK
[...]
./or~/dualnoise: OK
./or~/singlenoise: OK
./repeat/noargs: OK
./s2l/numsymbols: OK
./sgn~/simple: OK
./testtests/fail_noresult: failed
./testtests/fail: failed
./testtests/fail_wait0: failed
./testtests/fail_wait10: failed
./testtests/pass: OK
./testtests/pass_wait0: OK
./testtests/pass_wait10: OK
101 tests passed
4 tests failed
==
105 regression-tests total
105 regression-tests passed
0 regression-tests failed
==
PASS: runtests.sh
=
1 test passed
=
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6lyiIACgkQkX2Xpv6ydvRpdACffqfXHS0o4nUIqDsFzeIMMTpE
I2YAoO5Hjpi/MGQzx6DyOiCp79uqyBmU
=K23z
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to load shared code for libraries

2011-10-20 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-19 18:33, Hans-Christoph Steiner wrote:
 
 Does it work for you?
 

it seems to work ok. at least the objects are loading (though i get a
lot of tcl/tk errors with some of the examples, but i guess that's
unrelated to the main problem)

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

iEYEARECAAYFAk6gIvYACgkQkX2Xpv6ydvSFRgCgg1c/WtKPQZkwLSdvi3dRFU2m
qCwAn26d3+F46aug0GP113/6VxJ1tOrm
=di0M
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-double: how to selectively build external libs for development?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-18 22:16, katja wrote:
 On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner h...@at.or.at wrote:
 
 Another idea for handling this is to use the ./configure
 --enable-double-precision flag, but have it generate a config.h, which is
 included by m_pd.h.  That should solve this issue, since config.h would be
 auto-generated based on the flag, but all externals would use m_pd.h, which
 reads the PD_FLOAT_PRECISION value from config.h
 
 Ah yes that sounds like a good solution. But what if a lib is built

i don't think so, mainly because i encountered lots of problems with
this in the past.
config.h is BAD, because it is a very commonly named file.

if we have
 pd/m_pd.h
 pd/config.h
 myexternal/myexternal.c
 myexternal/config.h

then i think the inclusion of config.h can be ambiguous;
your compiler might happen to know which config.h to include; it might
as well not know; i'd rather not chance the odd case where the wrong
config.h is included.

even if the inclusion gets right, there are pitfalls if you use
config.h as the general output of configure (which i assume, since you
chose this naming), where you define things like which header is present
(something like HAVE_ALSA_ASOUNDLIB_H): the header might have well
existed when pd was built, but there is absolutely no guarantee that it
is there when the external is build.
however, the external might include code that could use that very
header, and the build will fail spectacularily.

so, i would definitely separate the files that hold information on how
to build Pd (either by simply adding flags to the DEFS or by use the
traditional config.h) from the files that hold information on how to
build _for_ pd (e.g. externals), aka the public API.

i fail to see the drawbacks of my suggestion [1] to use a file
m_types.h that contains solely the information about how to deal with
types, and this could be (partly) generated from information for configure.

mfgsdr
IOhannes



[1] http://lists.puredata.info/pipermail/pd-dev/2011-10/017415.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6efFAACgkQkX2Xpv6ydvQiqwCeKSd9LaJKgBdI9YI+3+EwRVhE
K8UAnAmhdYW57L/TgrJJqBB5iCBS0COV
=9ENm
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to load shared code for libraries

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-19 01:29, Hans-Christoph Steiner wrote:
 
 Yes!  I got it working.  I see the way to use it for this situation,

this looks like great news!

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

iEYEARECAAYFAk6efJcACgkQkX2Xpv6ydvSwXACfd+SSahk1+v2LyVJpLCj9P5LQ
tWoAoNouCLNYhvAZU+yZ5CL/Z0v0AQqA
=ziPc
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-double: how to selectively build external libs for development?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-19 21:07, Hans-Christoph Steiner wrote:

 I don't really understand what you're saying here. 

it seems so.

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

iEYEARECAAYFAk6fIb4ACgkQkX2Xpv6ydvT/TgCdFfqhQK/vFX3BmNCLtQaZ35fd
DlgAmgKdi2WGfU5+oOfAgjCChcVO3OA5
=lRZW
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-double: how to selectively build external libs for development?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-19 21:15, Hans-Christoph Steiner wrote:
 
 On Oct 19, 2011, at 3:15 PM, IOhannes m zmoelnig wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2011-10-19 21:07, Hans-Christoph Steiner wrote:

 I don't really understand what you're saying here.

 it seems so.

 
 
 Yes, it is actually true.  I do not understand. Care to explain?
 

sure, sorry.

i will try to do that tomorrow (12hrs of work is quite enough for now)

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

iEYEARECAAYFAk6fIuwACgkQkX2Xpv6ydvTULwCg04X8sycMn7M+C7Ij4HEXdExU
ebAAn3jAZcT9h6HSghSiaaPIEQRMpcFu
=0KDE
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] makefile template

2011-10-18 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-18 05:01, Patrice Colet wrote:

 then you did something weird :-)
 i had the same problem after changing CC to CXX and replacing
 myobject.c
 with myobject.cpp

 the template/Makefile is full of assumptions that the sources end
 with
 .c; to compile .cpp files, you will have to replace all the
 pattern
 substitutions throughout the makefile from %.c to %.cpp
 mainly you will find this in constructs like $(SOURCES:.c=.o)
 which
 need to be changed to $(SOURCES:.cpp=.o)

 
 that's what I did, after changing all .c to .cpp and CC to CXX it compiles.
 
[...]
 that's right, if I replace .c with .cpp in clean method, make doesn't remove 
 .cpp files anymore,
 but it still removes the .tcl files

that is why i said 'constructs _like_ $(SOURCES:.c=.o)' rather than
'replace all occurences of .c=.o with .cpp=.o'

you really should go through the _entire_ Makefile and search for all
.c (indicating filename suffixes...so check the context) and replace
it with .cpp.
there might be occurences of .c that are not related to filename
extensions so take care.

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

iEYEARECAAYFAk6dHV0ACgkQkX2Xpv6ydvRuyQCg6DnttMnTjXIAAZHfq2TCC7v+
p4gAoJmnGkR+31iy+c21CRRVRmmfU0Tw
=xdm+
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] makefile template

2011-10-18 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-18 05:01, Patrice Colet wrote:
 
 Also I still have same question about pd includes, but more accurately...

i missed that question :-)

 
 gui externals needs m_imp.h, because of this:
 
[...]
 
 c_externdir-s_name and c_name-s_name are declared in m_imp.h
 but it's not in pd/include, there only is m_pd.h.

where did you get the pd/include from?
i don't have it on my system.

 
 So do I have to add this file to my project or, do I have to modify the 
 Makefile to look for it?
 For the moment I keep a copy of m_imp.h in my project it's easier to handle 
 ^^.

you should definitely NOT keep it in your project.
unlike m_pd.h, m_imp.h is a private header, things in there might change
significantly from release to release. this is not an empty threat,
changes in the private header files are the reason why some nifty
(mainly gui related) externals compiled with 0.41 will crash when used
on 0.42.

so if you must include m_imp.h, you should always use the one that comes
with the version of Pd that it relates to.
therefore you must tell the buld process where it should look for those
headers. in template/Makefile, this is done via the PD_INCLUDE
variable. it defaults to something like /usr/local/include/pd (ah, i
guess your pd/include above was meant to be include/pd?), which is
where headers are expected on un*x like systems adhering to the FSS.
w32 does not really care about FSS, hence the default doesn't really work.

there are a couple of workarounds to get your build going:
set the PD_INCLUDE to the path of your Pd-headers (or sources) when
building.
something like:
$ make PD_INCLUDE=/c/cygdrive/Programmas/Pd/src
should do the trick.
afair, the Pd-extended nightly builds will set the PD_INCLUDE to point
to the correct path automatically.

if this is too much annoying during the test phase and if you are
working from a standard layout (with Pd-sources in /pd/src and
your external in /externals/yourexternal) you might _additionally_
add ../../pd/src to the includes in ALL_CXXFLAGS _after_ PD_INCLUDE.
something like Makefile:57
ALL_CFLAGS = -I$(PD_INCLUDE) -I../../pd/src

it should be after the PD_INCLUDE so that the user can point PD_INCLUDE
to the directory with the correct m_imp.h, and use ../../pd/src only as
fallback.


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

iEYEARECAAYFAk6dIWQACgkQkX2Xpv6ydvR6RQCgsYj1h1RtBM/em81QWNY8lLvD
g0cAnRROFc0t0/YlR6K153+itliVfAbA
=7EHE
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-double: how to selectively build external libs for development?

2011-10-18 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-17 22:27, katja wrote:

 There's however a small issue to reckon with: at the moment, the only
 way to force double precision compilation upon the external libs, is
 to hardcode #define PF_FLOAT_PRECISION 64 in m_pd.h. If we put it in

i think this is the only solution on the long way anyhow.

when building an external for a given Pd-binary, there is no way to tell
whether it was a single or double precision build (apart from checking
whether the resulting external produces nonsense or even crashes).
the only reference is the include file, which must be non-ambiguous.

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

iEYEARECAAYFAk6dIowACgkQkX2Xpv6ydvRvGACgzFA5WQ5re+2f3iSCTOiLjtJ6
B+wAnAg172TMkK9H52Pop5oEKuu9LxaC
=YHLC
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] makefile template

2011-10-17 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-15 04:08, Patrice Colet wrote:
 
 also I've added
 
 CXX=g++
 
 because i'm using mingw, and it starts compile :)
 

hmm, what is the default for CXX on mingw?

i think it's a bad idea to hardcode the used compiler for no compelling
reason
...ah after inspecting the template/Makefile, it seems that CC is set
explicitely as well. so does MinGW's make indeed does not use a working
compiler in CC/CXX?

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

iEYEARECAAYFAk6b1uoACgkQkX2Xpv6ydvQZpACfdKLxIKwYwWMS1pUw/LGhyc3x
yRIAnA1ORcAjUsS0S+PJmlJ02cuK+mc7
=WdXQ
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] makefile template

2011-10-17 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-17 17:11, Patrice Colet wrote:
 Hello IOhannes,
 
  all I could say is this:
 
 $ make -p -n | grep CXX
 make: *** No targets specified and no makefile found.  Stop.
 LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
 COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
 CXX = g++

what do you mean by that?
why does it mean that you have to manually add a CXX=g++ line to your
Makefile?
here (on linux), i get approximately the same.
note that there is a line CXX = g++ is the following output, though
this is set implicitely by make and not explicitely in the makefile.

snip
$ make -p -n | grep CXX
ALL_CXXFLAGS := -I/usr/include/pd -DPD -DVERSION='0.0' -fPIC -Wall
- -W -g -O6 -funroll-loops -fomit-frame-pointer
CXXFLAGS = -Wall -W -g
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
OPT_CXXFLAGS = -O6 -funroll-loops -fomit-frame-pointer
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
CXX = g++
$(CXX) $(ALL_CXXFLAGS) -o $*.o -c $*.cpp
$(CXX) $(ALL_LDFLAGS) -o $*.$(EXTENSION) $*.o  $(ALL_LIBS)
$(SHARED_LIB)
$(CXX) $(ALL_LDFLAGS) -o $*.$(EXTENSION) $*.o  $(ALL_LIBS)
$(SHARED_LIB)
$(CXX) $(ALL_LDFLAGS) -o $(LIBRARY_NAME).$(EXTENSION)
$(SOURCES:.cpp=.o) $(LIBRARY_NAME).o $(ALL_LIBS)
@echo CXX: $(CXX)
@echo CXXFLAGS: $(CXXFLAGS)
@echo ALL_CXXFLAGS: $(ALL_CXXFLAGS)
$(CXX) $(ALL_CXXFLAGS) -o $*.o -c $*.cpp
/snip


 There another thing very unlikely in template/Makefile, if do a 'make clean', 
 it removes all the sources as well as objects and binaries
 so for not loosing sources I have to remove these lines:
 
  -rm -f -- $(SOURCES:.cpp=.o) $(SOURCES_LIB:.cpp=.o) $(SHARED_SOURCE:.cpp=.o)
  -rm -f -- $(SOURCES:.cpp=.$(EXTENSION))


then you did something weird :-)
i had the same problem after changing CC to CXX and replacing myobject.c
with myobject.cpp

the template/Makefile is full of assumptions that the sources end with
.c; to compile .cpp files, you will have to replace all the pattern
substitutions throughout the makefile from %.c to %.cpp
mainly you will find this in constructs like $(SOURCES:.c=.o) which
need to be changed to $(SOURCES:.cpp=.o)

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

iEYEARECAAYFAk6cUukACgkQkX2Xpv6ydvR/zACfVyDERq+FZPjNe8iEUoR4qlbB
8ooAoOsFletXdVJbAXT2Bf5LDDnfFoyb
=oPGx
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh

2011-10-05 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 18:48, Hans-Christoph Steiner wrote:
 
 On Oct 3, 2011, at 5:06 AM, IOhannes m zmoelnig wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2011-10-02 22:27, Hans-Christoph Steiner wrote:

 FYI:

 http://autobuild.puredata.info/auto-build/2011-10-02/logs/2011-10-02_03.15.26_darwin_macosx105-i386_pd-extended.txt



 hmm, i cannot reach this machine anymore...
 
 Yeah, it seems to be down, I'll check it tomorrow.


thanks.
now that it is online again, i did a little test:

snip
macosx105-i386:~ pddev$ cd tmp/externals/
macosx105-i386:externals pddev$ make
/Users/pddev/tmp/externals/zexy/configure

grep: /Users/pddev/tmp/externals/loaders/pdlua/src/config.h: No such
file or directory
cd /Users/pddev/tmp/externals/zexy  ./autogen.sh
PATH:
/sw/bin:/Users/pddev/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
running autoreconf
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
aclocal.m4:20: warning: this file was generated for autoconf 2.68.
You have another version of autoconf.  It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
configure.ac:5: error: Autoconf version 2.62 or higher is required
aclocal.m4:8945: AM_INIT_AUTOMAKE is expanded from...
configure.ac:5: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
aclocal.m4:20: warning: this file was generated for autoconf 2.68.
You have another version of autoconf.  It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
configure.ac:5: error: Autoconf version 2.62 or higher is required
aclocal.m4:8945: AM_INIT_AUTOMAKE is expanded from...
configure.ac:5: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
autoreconf: /usr/bin/autoconf failed with exit status: 63
make: *** [/Users/pddev/tmp/externals/zexy/configure] Error 63

macosx105-i386:externals pddev$ . /sw/bin/init.sh
macosx105-i386:externals pddev$ make
/Users/pddev/tmp/externals/zexy/configure

grep: /Users/pddev/tmp/externals/loaders/pdlua/src/config.h: No such
file or directory
cd /Users/pddev/tmp/externals/zexy  ./autogen.sh
PATH:
/sw/bin:/sw/bin:/sw/sbin:/Users/pddev/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/X11R6/bin
running autoreconf
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /sw/bin/autoconf-2.68 --force
autoreconf: running: /sw/bin/autoheader-2.68 --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:6: installing `./config.guess'
configure.ac:6: installing `./config.sub'
configure.ac:5: installing `./install-sh'
configure.ac:5: installing `./missing'
src/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
/snip


this basically indicates, that zexy's autogen.sh is working fine, as
long as we have Fink support (by running: sourcing /sw/bin/init.sh)
actually, only /sw/bin has to be added to the PATH

the logfiles reveal that PATH is set to
/sw/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/sw/bin:/sw/sbin
which seems to be OK but obviously isn't:
bummer #1: the leading /sw/bin is set in zexy's autogen.sh, but actually
it is set too late (after AUTORECONF has been evaluated to
/usr/bin/autoreconf)) - indeed that was a difference between
puredata.git/autogen.sh and the one used in zexy :-)
fixed in current SVN, so zexy should build on OSX from now on

bummer #2: the path settings for building Pd-extended make sure that
fink installed replacements are only fallbacks for the system installed
programmes. e.g. fink comes with autoconf-2.68 while the system comes
with autoconf-2.61; the path settings make sure that the older one is used.
is there a compelling reason to append /sw/bin rather than to prepend it
(as is done by /sw/bin/init.s)?


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

iEYEARECAAYFAk6MD7YACgkQkX2Xpv6ydvSy7QCgiQTIpsrmzT8nxjzTySojXokJ
oqcAoOfewIC+ZuXcRit6VnfUNzJap+0+
=kcYI
-END PGP

Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh

2011-10-05 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-05 18:16, Hans-Christoph Steiner wrote:

On Oct 5, 2011, at 4:05 AM, IOhannes m zmoelnig wrote:

The logfile I see says its set to:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/sw/bin:/sw/sbin

http://autobuild.puredata.info/auto-build/2011-10-05/logs/2011-10-05_03.15.09_darwin_macosx105-i386_pd-extended.txt

the same logfiles also says:
PATH: /sw/bin:/usr/bin:/bin:/usr/sbin:/sbin:/sw/bin:/sw/sbin

Its set in run-automated-builder here:

# On Mac OS X, there are some handy things in Fink, but don't override the
# built-in tools
PATH=${PATH}:/sw/bin:/sw/sbin
export PATH

This is set like this so that we can ensure that Fink is not required
for building things that use autotools. Most Mac OS X users do not have
Fink, MacPorts, Brew, etc. installed, so things like libraries really
should build without Fink.

if there is no fink at all, then this shouldn't be a problem either.
the way zexy's autogen.sh script worked, it might mix up the two.

but as i said, that is supposed to be fixed.

I don't really know what the issue here.

i set the PATH too late, resulting in using the system's autoreconf, but
the system's autoreconf would then (eventually) use (some of) the
autoconf tools from fink.

And don't forget, in every build, it runs ./autogen.sh ./configure in
pd/ and that is working.

i think i already got that part.

Following that hunch, I copied the
pd/autogen.sh into zexy/autogen.sh and it works fine in the auto-build

not needed any more, see above

'pd' acccount. Also, on my 10.5 machine, I load Fink using . .
/sw/bin/init.sh, so the path is prepended, and it still doesn't work,
but with a different error:

which suggests that your libtool setup is broken :-)

you could try comparing the ./libtool generated on your machine and the
one generated on the PdLab machine.

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

iEYEARECAAYFAk6MiZ8ACgkQkX2Xpv6ydvTonQCePcpbtvDMbeD1uMmtWwc4Slys
7KoAoLaUPqdlGBNQI3Zqc90550YugUYd
=Kgmh
-END PGP SIGNATURE-

smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] where is Pd's -stdlib?

2011-10-04 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-04 11:19, Roman Haefeli wrote:
 
 Applied to standard paths this would lead to the following search order:
 
 1) ~/pd-externals
 2) /usr/local/lib/puredata/extra
 3) /usr/local/lib/pd/extra
 4) /usr/lib/puredata/extra
 5) /usr/lib/pd/extra
 
 (please add some more, if I forgot some)

please don't add more :-)
these are already too many.

currently the stdpaths for pd are:

1) ~/pd-externals/
2) pd-install-path/extra/
3) /usr/local/lib/pd-externals/


note that #3 is not /usr/local/lib/pd/extra/ but really .../pd-externals/
this is there to keep it separate(!) from the case where
pd-install-path is /usr/local/lib/pd/

the idea is to have some paths independent from pd-install-path, where
the user (~/pd-externals/) or the sysadmin (/usr/local/lib/pd-externals)
can install externals.

on debian (where pd-install-path is /usr/lib/puredata), there is an
additional compatibilty and cross-pd stdpath
4) /usr/lib/pd/extra

both pd-vanilla and pd-extended will search this path as a last resort.

 to assume that /usr/lib/pdextended/extra should be search first, so that
 the patch gets the same 'zexy' as it would get in some other Pd-extended
 installation on some other OS.

a pdextended specific package would install to /usr/lib/pdextended/extra
this path will not be searched by pd-vanilla (nor will pdx search
/usr/lib/puredata/extra)

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

iEYEARECAAYFAk6K5rgACgkQkX2Xpv6ydvQipwCfdPNhvC0jpV732OTdW8a/7tWU
/C4AoOD+dz5XsZMcsmsqDaRs7wyLDWwh
=/eA/
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

@pd-dev: in the course of making packages for debian, we discovered
another slight problem with the -stdpath and -stdlib flags for
declare (and probably this also expands to the -nostdpath startup
flag). following is an excerpt of the discussion in the debian packaging
team:


On 2011-10-01 14:11, Roman Haefeli wrote:
 
 On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote:

 i'm not entirely sure though (given the nastiness of [declare])
 if you think that it is a bug in puredata-core, please file a bugreport.
 
 Yeah, that is indeed the case. Before filing a bug report, I'd like to
 clear up the meanings of the different paths.
 
 /usr/lib/pd/extra
   Am I right in assuming that this path is supposed to be searched by
   all flavors of Pd (all packages that provide the virtual package pd)?
   This also the path where usually external libraries are installed to 
   because from there they can be loaded from any flavor of pd?
 
 /usr/lib/puredata/extra
   is only searched by puredata / pd from the puredata package?
   This is where libraries are installed that only are suitable for
   the pd provided by the puredata package?
   
 /usr/lib/pd-extended/extra
   is only searched by pdextended / pd from the pd-extended package?
   Libs that are only useful with pdextended go there?
 
 If that is the case, then there is definitely a bug in the puredata-core
 package as it is ignoring /usr/lib/pd/extra.

it might as well be a bug in puredata upstream (that's why i want to
discuss it; probably a more appropriate place for discussion is the
pd-dev mailinglist which i include in the recipients)

imho, the issue boils down to the question what are stdpaths? (and i
assume that stdlibs are std because they live in stdpaths).

for the sake of simplicity, i will only talk about the linux version
of Pd (and with Pd i mean Pd-vanilla)

before Pd-0.43 (vanilla!), there was only a single stdpath, which was
the path were the Pd binaries lived in. this usually was
/usr/local/lib/pd/ or /usr/lib/pd/

since 0.43, a few more paths have been added, namely:
/usr/local/lib/pd-externals and ~/pd-externals
on Debian and derivatives, yet another path is added: since Pd is
installed into /usr/lib/puredata/ (in order to allow pd-extended live
side by side with puredata), the path /usr/lib/pd is also added as a
common system-managed search path.

now all these paths are handled separately from the user defined
search-paths; e.g. they do not show up in the path dialog, and they can
be disabled with the -nostdpaths flag.

otoh, [declare] has not adapted to these changes.
if you add -stdpath extra/foo, it will only search in
/usr/local/lib/pd/extra/foo (given that pd is installed in
/usr/local/lib/pd), but it will not search in
/usr/local/lib/pd-externals/extra/foo nor in ~/pd-externals/extra/foo.
(the same applies for the additional Debian-specific search path
/usr/lib/pd/extra/foo).
hence i do think that the problem is general problem with Pd-vanilla
(and not specific to Debian; it only shows here)

 
 This also means, that currently all Pd libraries in unstable that
 install to /usr/lib/pd/extra (most of them do) are currently broken, as
 there is no proper way to actually load them in pd (you still can
 specify the absolute path to the library, which renders your patch
 unportable to other OS').

you could also simply start Pd with -lib foo and it will just work.
so i wouldn't consider all broken.
obviously, we lack the possibility to express a library dependency
within the patch, which is a shame (but which is also due to the current
broken implementation of [declare] in general).


anyhow, what i'm mainly asking is, whether std prefixed declare
options and the std prefixed cmdline flags are supposed to work on the
same standard. if so, does this mean to be exclusive (e.g. only have
the Pd install path) or inclusive (additionally have
/usr/local/lib/pd-externals/ and ~/pd-externals/ (and on debian the
additional /usr/lib/pd/extra/)

i generally tend towards an inclusive solution, though i'm not 100% sure
whether this is the user expectancy with regards to ~/pd-externals/

fgm,asdr
IOhannes

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

iEYEARECAAYFAk6JajEACgkQkX2Xpv6ydvSVzgCgh78s7H3JNu5Ev/dhl3i2CxWj
lPAAn2o/jopO8jnzi+Z6rRkUXxkCkO08
=rmN+
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] w32 PdLab machine down?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

when i try to login to the machine, i get:

Uptime for this computer is  10 [main] gawk 2200
C:\cygwin\bin\gawk.exe: *** fatal error - CreateFileMapping
Global\cygwin1S4.cygpid.3780, Win32 error 5.  Terminating.

and i don't get a shell, which makes it a bit awkward to do any svn
updates (port forwarding works though, so rdesktop is ok)

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

iEYEARECAAYFAk6JhSAACgkQkX2Xpv6ydvTISACg25+zbcXZEXUDkHTB2v5aIP5M
JQQAn1dV7vPv6JjrafYb6/bj+enS96AQ
=JI4h
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] w32 PdLab machine broken (was Re: w32 PdLab machine down?)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 11:49, IOhannes m zmoelnig wrote:
 when i try to login to the machine, i get:
 
 Uptime for this computer is  10 [main] gawk 2200
 C:\cygwin\bin\gawk.exe: *** fatal error - CreateFileMapping
 Global\cygwin1S4.cygpid.3780, Win32 error 5.  Terminating.
 
 and i don't get a shell, which makes it a bit awkward to do any svn
 updates (port forwarding works though, so rdesktop is ok)

which of course means, that it is somehow broken, rather than down.

anyhow, i tried opening a cygwin shell from the rdesktop, and i get the
same error.
so it seems that (only) cygwin is broken somwhat.

fgmasdr
IOhannes


 
 fgamnsdr
 IOhannes

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

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

iEYEARECAAYFAk6JhjUACgkQkX2Xpv6ydvR62ACg5H4qGjLfFGUsKwCBxoafJ6L0
sBgAoK2/ehwDae1MIZ7j+6RK47xyw8HG
=JT/0
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 16:31, Hans-Christoph Steiner wrote:
 
 These all sound like good ideas to try.  My only concern is that we
 might let the deployment issues distract from the issues at hand about
 getting it actually working first.

i'm definitely with you here.
what is still missing in terms of getting it actually working first?

afaict, katja's patches do make pd itself double-precision ready (the
patches might have to be reviewed as far as coding-style is concerned
though)

otoh, i wouldn't start porting externals before we have a deployment
strategy.



one important thing missing right now, is how to compile Pd in a given
precision without having to edit m_pd.h
technically i think that the define stuff and the like should go into a
separate file types.h (probably m_types.h) which is generated from
m_types.h.in during configure time, and which is included by m_pd.h
(which should remain non-generated)
the question is, what miller would think of such a thing.

 In terms of packaging, I can see having 64-bit distros run
 double-precision Pd for all packages, and 32-bit distros run single
 precision.  That should cover the bulk of situations, the other
 situations can be covered by custom builds.  Having all the 64-bit
 packages use double-precision Pd is of course going to happen after a
 while, once we have the bugs worked out.  Here I can see an advantage of
 the monolithic Pd-extended package: its an easy, self-contained test bed.

definitely, the traditional Pd-extended will have an easier time here.

nevertheless, the advent of ~/pd-externals for the user has made things
significantly more complicated in terms of just works.

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

iEYEARECAAYFAk6J0n4ACgkQkX2Xpv6ydvQMzgCgkdnTzhJhn9XC+7zXP5VZBjss
QEQAoPEt0kvhxm9LPW+biXH1gXSd1+mX
=sWcN
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Help for sourceforge.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 17:16, Roman Haefeli wrote:
 
 On Mon, 2011-10-03 at 10:47 -0400, Hans-Christoph Steiner wrote:
 Looks like it was set to Pending, do you still need help with it?
 
 No, that is what I am saying. It can be closed. But I seem to lack the
 privileges to do so (or I am blind).
 

i (being patcher admin) set it to pending, which is the way i usually
handle closing of bugs. they will be automatically closed if nobody
objects (by adding a reply to the issue) within the next 2 weeks.

i hope this is ok for everybody.

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

iEYEARECAAYFAk6J0uoACgkQkX2Xpv6ydvQ3DgCeJ+CwtjGBwZz7Dpe5+/opufBm
DW8AoPcFY/h3iijHNZxwZEM+zzBa4YVq
=Q85x
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 17:44, katja wrote:
 Thanks IOhannes for all your comments and suggestions.
 
 I just realized that there are several ways in which identical symbols
 for different function definitions could cause a problem and I did not
 distinguish them.
 
 1. Pd looks for a setup symbol when trying to load an external binary.
 2. A loaded external calls an exported function in Pd.
 3. Pd calls an exported function in Pd
 
 Case 2. and 3. can only lead to symbol collision when a single
 precision and double precision Pd are running simultaneously. So far,

how is that going to happen?
by running simultaneously, do you mean something like this?
$ pd32 
$ pd64

i think all modern OSs will protect the memory (including loaded
libraries) of an application from other applications.
e.g. if i happen to have a library with an exported symbol sqrt which
viciously returns the (x+1) rather than sqrt(x), and i start an
application that links to this library (thus making use of the bad
sqrt()), this will not magically make Excel forget it's math.

the problem might obivously appear, if Pd would actually create a
libpd.so providing all the exported functions, and pd32 / pd64 would
make heavy use of those.
in which case, pd32 might get a double-precision libpd.so, and thus be
not single precision any more.

but this is really not a problem of running the single and double
precision on the same machine, but installing them on the same machine.

 
 For case 1., protection is needed indeed. As IOhannes' list of
 possible approaches indicates, it's not a trivial intervention. I've
 also been thinking of a mechanism where Pd 'probes' a class at load
 time in order to find it's float type before instantiating any object.
 Rather it creates a private test instance for that purpose and tries
 to solicit output and check the size. To program this is not trivial
 either, if possible at all, but the advantage would be that it does
 not have consequence for class code.


i cannot really think of a way to do that.
if we only consider signals, we could do some tests (as the object has a
well defined interface to acquire and output numbers), though i fail
to see how we could validate these tests, without knowing what the
object is actually supposed to do.
if we consider message objects as well, i don't even know how to
properly send a message that might reveal something useful.

 knows they are in it's own extra dir, wherever the installation may be
 located. I do not know where this path is set but we need an option to
 add more dirs to that local  path without using preferences.

i don't see how this would help.
whether those paths can be modified via preferences or only via startup
flags, doesn't really matter. if we want them to not be editable at all,
i don't see the point in adding them.

people do use the preferences to add paths to find their libraries.
if those paths contain libraries expecting the wrong precision we have a
problem.


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

iEYEARECAAYFAk6J3RQACgkQkX2Xpv6ydvSxlgCfSWr1xxFrd/VQ/13lgARF88EL
Qk0An22WlbXva6O/Q3YWasMn/57M+XK6
=OVlg
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 18:00, Charles Henry wrote:
 
 Would you prefer to set the types at configure time through a file--or
 for example by adding a -DDOUBLE compiler flag?  The affected
 locations of code defining the types could just use #ifdef DOUBLE

no, not at all.

 
 In either case, the configure option seems necessary.  It still seems
 an open question how best to offer the double-precision types to
 externals developers.

yes, of course this is the point.
if the external includes (the correct) m_pd.h, it should get the
correct precision for free.
right now, the default is to use 32bit. if you set the
PD_FLOAT_PRECISION macro to 64 (e.g. by adding -DPD_FLOAT_PRECISION=64
to the preprocessor-flags or by modifying m_pd.h), you will get a double
precision build.

if you set CPPFLAGS, no external will be able to track the current
precision.
if you modify m_pd.h, then you are modifying upstream sources, which
makes it complicated for distribution.


 
 In some cases, the setup() function allocates memory, which needs to
 be aware of the data type size.

well, just use t_float or t-sample (as appropriate) with the correctly
defined PD_FLOAT_PRECISION.

i'm really only talking about how to make sure that PD_FLOAT_PRECISION
is defined to the right value.

 Adding additional methods seems unnecessary--unless specific
 performance problems can be avoided.

it's only about guaranteeing consistency between the host (pd) and the
client (the external).
i don't see so many alternatives, but probably you know some clever trick.

 I don't anticipate any problems with running 64-bit Pd on a 32-bit

i'd suggest to use double precision Pd (i know it's longer to type) if
you refer to 64bit data types, and 64bit Pd if you refer to address size.

 system, in principle, just as long as the correct data types are set
 for pointers (same size as t_int) and signals (size of t_sample)
 differently.

that's the problem i'm trying to solve.

fgmasdr
IOhannes

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

iEYEARECAAYFAk6J32oACgkQkX2Xpv6ydvR0UQCg9+ZNB6M3uLNucL2DfQ0B3RoU
qN8AoLRJj7sfglMBwsyXDAXnln/x937X
=/L5s
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 18:04, katja wrote:
 On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote:
 
 Do you have access to an ARM
 machine?  If not, I could probably get one online with ssh access, if that's
 useful.
 
 I've mailed Joe White with the question if he can patch the code for
 libpd and check performance on ARM. 

apropos performance:
on my i5 650 @ 3.2GHz, running debian
and trying to osc-delay-perfotest.pd (with only 400 osc-delay
abstractions, as 500 would max out the CPU in new double mode) i get:
original  : 28%
debian: 31%
new single: 64%
new double: 86%

the new versions are Pd-0.43.1-test4 with only the PD_FLOAT_PRECISION
set to 32 resp. 64.

the original version is a 0.43.1-test2, where i cannot recall any
special optimization flags.

the debian version is a 0.43.0 with most optimization turned OFF (as
is debian policy)

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

iEYEARECAAYFAk6J4SQACgkQkX2Xpv6ydvR+hgCgwWuetmj86YFr7iXsHkIZolVc
b5YAoPA4DJnkKb6Gtu5YnbMheDSkUvwy
=js8N
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 18:32, Hans-Christoph Steiner wrote:
 
 More on actually trying the patch.  I tried to apply it to the HEAD of
 pure-data.git, and one section failed:
 
 pd@debian-lenny-i386 src $ patch -p1 
 ../../pd_doubleready/make_Pd_core_0430_double_ready.patch
 patching file d_array.c
 patching file d_math.c
 patching file d_misc.c
 Hunk #2 FAILED at 37.
 1 out of 2 hunks FAILED -- saving rejects to file d_misc.c.rej

this one is quite easy to fix if you inspect the patch manually.
anyhow, i patched the sources and pushed them to my github repository,
into the double branch.
https://github.com/umlaeute/pd-vanilla/tree/double


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

iEYEARECAAYFAk6J5LcACgkQkX2Xpv6ydvSTwACgrCNNwp00bIw+yDtTGnfTwEn7
kq4AoJkqTYQYtrDnMokeqhCOylexjLgV
=MMS0
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 18:48, Hans-Christoph Steiner wrote:
 
 
 I don't really know why this is happening, but I do know that the
 ./autogen.sh in pure-data.git and pd-extended.git works everywhere since
 it is used in the builds every night.  Why not just use that one?
 

it's virtually the same.

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

iEYEARECAAYFAk6J7o8ACgkQkX2Xpv6ydvTAKQCfV1YJ+r1sJSQYXdsLXpW3xDHX
vEAAoOuRyXKc7i90FkyXzxkFuQuUNyS2
=bBtO
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-03 19:19, IOhannes m zmoelnig wrote:
 On 2011-10-03 18:48, Hans-Christoph Steiner wrote:
 
 
 I don't really know why this is happening, but I do know that the
 ./autogen.sh in pure-data.git and pd-extended.git works everywhere since
 it is used in the builds every night.  Why not just use that one?
 
 
 it's virtually the same.
 

esp. in the trivial case, where there is autoreconf (and not mingw),
where both scripts just call:
$ autoreconf -fiv

so it's not that autogen.sh script that causes trouble, but autoreconf.
i'm not saying that it is broken, i'm only saying that i find it weird
that autoreconf generates a file for autoconf and then complains that it
is has been generated for another version of autoconf.

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

iEYEARECAAYFAk6J71gACgkQkX2Xpv6ydvRAbgCeLyeVEJVKYlXn20uNHjXvBwON
8V0AoL2U6h4a1DDVsylsyFRktrwz6MPL
=rxLE
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] remove all .la (libtool archives) files created by autotools

2011-09-29 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-29 17:15, Hans-Christoph Steiner wrote:

Hey Roman,

I just saw this commit:

http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/Makefile?r1=15393r2=15397

.la files generally should not be installed, that makes sense to me.
This seems like a heavy hand to do a global deletion for something like
this. The problem would be in the build system that is installing them,
and should be fixed there. Then it'll be fixed wherever that library is
used, not just in Pd-extended.

libtool is convinced that you need .la files.
from their perspective it is probably correct.

if you can come up with a proper way to avoid installing .la files from
within automake/libtool (without dumping automake/libtool), feel free to
suggest fixes.
else you will either have to live with those files or to delete them in
some other way (e.g. with the one i proposed to roman, and which is
currently in externals/Makefile)

probably it is a safer guess to only delete .la files if there is a
matching .$(EXTENSION) file and/or a matching .so/.dll file.

nevertheless, i don't see any harm done now.

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

iEYEARECAAYFAk6EkKQACgkQkX2Xpv6ydvSYRQCgx+5THaNg1qaGWhYMJH3U/49n
NHoAoPgp3okMUZkG3nzdtnfLe96Oj8+3
=dSSA
-END PGP SIGNATURE-

smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] remove all .la (libtool archives) files created by autotools

2011-09-29 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-29 17:41, Hans-Christoph Steiner wrote:

 What is the problem this is trying to solve?  How are the .la files
 causing problems ?  The Pd-extended is crufty enough as it is with lots
 of kludges like this that I'm mostly responsible for.  I've learned thru
 the error of my ways, and have been working to make it all much cleaner
 and simpler.

roman asked why zexy installs a large number of never-before-seen files,
and i told him that they can safely be deleted.

so the problem is that they are pointless files, lying around on the
filesystem doing no good, and only lead to confusion.

if you prefer to have the files around, feel free to keep them.

mfgasdr
IOhannes


PS: btw, debian strongly recommends to remove .la files from packages,
e.g. http://wiki.debian.org/ReleaseGoals/LAFileRemoval and a number of
lintian warnings.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ElCsACgkQkX2Xpv6ydvQhwgCguVPaXXaGkv5l4+7vtABggwbM
uuAAoLgFNYFKkt05dX2Gc7wQodY1N+ss
=Wh3K
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to load shared code for libraries

2011-09-27 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-26 23:29, Hans-Christoph Steiner wrote:
 
 My guess is that it'll be something like this:
 
 #ifdef _WIN32
 PATH
 #elif defined(__APPLE__)
 DYLD_LIBRARY_PATH
 #else
 LD_LIBRARY_PATH
 #endif

i would go for something with less logic involved:
push(PATH); push(LD_LIBRARY_PATH); push(DYLD_LIBRARY_PATH);
...
pop(PATH); pop(LD_LIBRARY_PATH); pop(DYLD_LIBRARY_PATH);


the only drawback i see right now is, that is doesn't work.
at least on linux, any modification to LD_LIBRARY_PATH is nicely ignored
and only the value taken when starting the application is taken into
account :-(

maybe there is a soltuin for this problem, but i haven't come across one
yet.

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

iEYEARECAAYFAk6BcoAACgkQkX2Xpv6ydvTe9wCeKw+0k+S61dSBLfwYvnZLmKVH
m+oAmwRTnW6ewoR5FUKt97R0wT3Vu8m8
=Tich
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to load shared code for libraries

2011-09-27 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


http://cocoaconvert.net/2009/08/02/frameworks-with-private-frameworks/

 
 fgmasdr
 IOhannes

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

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

iEYEARECAAYFAk6BflIACgkQkX2Xpv6ydvSK+gCgqhyxJVkNuR8hjsB4NWfGnmgi
QXgAoMrmStRdLgq/WGf6XVgUSWBXa6BP
=9UUb
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] iemguts release?

2011-09-26 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-26 14:14, Roman Haefeli wrote:
 On Thu, 2011-09-22 at 17:36 -0400, Hans-Christoph Steiner wrote:
 Hey IOhannes,

 I think iemguts is ready primetime, I think it should be included in  
 the next Pd-extended 0.43 release.  Do you have any plans on making an  
 official release?
 
 I cannot speak for IOhannes, of course, but I noticed he already posted
 an ITP request on Debian for an pd-iemguts package:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603182
 

which has been closed due to my inactivity :-)

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

iEYEARECAAYFAk6AeOQACgkQkX2Xpv6ydvQkngCfZYIY3m85qisj+uZhLVtl2CJB
x9gAn2UZCa49qUmVriU2z5EchPxc7hF1
=aWr0
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Creating an external / sinewave equation example

2011-09-19 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-10 03:42, Rick T wrote:
 # Makefile
 # (c) 2006 IOhannes m zmölnig

oh, where did you get that one from?

nowadays, i would recommend using the Makefile template as found in
externals/template
(i should change the build system in doc/tutorial/externals-howto/example*/)

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

iEYEARECAAYFAk528Q0ACgkQkX2Xpv6ydvRtAACaA98E4xNoXQix3y1CSOMiYzwy
IcAAoMF9b0e6r3MLzCzbjirSXxd4RwzI
=BwbV
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Tabread/write on array bigger than 16777216 points

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Tabread/write on array bigger than 16777216 points

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Tabread/write on array bigger than 16777216 points

-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 zmoel...@iem.atwrote:
 
 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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] struct _canvasenvironment

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pdextended 0.43.1 and vista

2011-07-12 Thread IOhannes m zmoelnig

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [ pure-data-Patches-3307639 ] updated FR localization

2011-07-12 Thread IOhannes m zmoelnig

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pdextended 0.43.1 and vista

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pdextended 0.43.1 and vista

-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-
From 18878d89cfe3b02ff2649b48b6a9902fd1d0a4de Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig zmoel...@iem.at
Date: Mon, 11 Jul 2011 11:00:21 +0200
Subject: [PATCH] force C++-linker when linking with ASIO

---
 src/Makefile.am |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index b85f726..b73c44e 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -11,12 +11,20 @@ INCLUDES = @INCLUDES@
 
 SUFFIXES = .@EXTENSION@ .@SHARED_LIB@
 
+pd_LDADD   =
+pd_SOURCES =
+nodist_EXTRA_pd_SOURCES=
+
+# ASIO is C++, so it needs a C++ linker
+if ASIO
+nodist_EXTRA_pd_SOURCES += dummy.cpp
+endif
+
 bin_PROGRAMS = pd pdsend pdreceive
 pdsend_SOURCES = u_pdsend.c
 pdreceive_SOURCES = u_pdreceive.c
 pd_watchdog_SOURCES = s_watchdog.c
-pd_LDADD = 
-pd_SOURCES = g_canvas.c g_graph.c g_text.c g_rtext.c g_array.c g_template.c \
+pd_SOURCES += g_canvas.c g_graph.c g_text.c g_rtext.c g_array.c g_template.c \
 	g_io.c g_scalar.c g_traversal.c g_guiconnect.c g_readwrite.c g_editor.c \
 g_all_guis.c g_bang.c g_hdial.c g_hslider.c g_mycanvas.c g_numbox.c \
 g_toggle.c g_vdial.c g_vslider.c g_vumeter.c \
-- 
1.7.5.4



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pdextended 0.43.1 and vista

-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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pdextended 0.43.1 and vista

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-07-11 19:02, Patrice Colet wrote:
 
 - Patrice Colet colet.patr...@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-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] packaging the pddp docs

2011-06-29 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ola,


On 2011-06-27 21:21, Hans-Christoph Steiner wrote:
 
 Here's the files in puredata-doc:
 http://packages.debian.org/sid/all/puredata-doc/filelist
 

in case this has gone unnoticed, i wanted to point out, that currently
the reference-patches (doc/5.references) are _not_ packaged with
puredata-doc but instead with puredata-core, which makes erplacing them
a bit awkward.
however, it is super simple to replace all the tuturial patches
(puredata-doc)

fgmasdr
IOhannes


PS: is this a bug in my thunderbird that all replies from jonathan seem
to linebreak at 50 characters, which makes it a lot of lines to scroll,
if people don't trim their replies?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4K0r8ACgkQkX2Xpv6ydvSl7ACg48f7m/IeYRvy6Z5tLIxozAgt
P04AoO500nUQSS3WAWQ89aAXacBvdcmq
=PVpF
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] revised search-plugin.tcl

2011-06-21 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-06-21 02:13, Jonathan Wilkes wrote:

 How does one tell the difference?
 

i think the idea is to segregrate based on the paths libraries are
installed to.
usually there are directories where you need suprt-user rights to write
to. whenever something gets installed there, i think it would classify
as being included.

e.g., everything in /path/to/pd/bin/../extra would be included,
whereas everything in /home/${USER}/ would be user-installed.

a simpler discrimination would be to differentiate between
'administrator-installed' (paths starting with /usr; eventually also
include paths starting with /opt and /var) 'user-installed' (the rest)

paths like /usr/local/lib/pd-externals which are searched automatically,
are somewhere inbetween, as they require su priviliges for installation
but can definitely not be considered as 'included'.

for other operating systems, the paths will obviously be different.

i would probably find it more convenient, if there was a simple way to
see the full path of a certain object.
i can then figure out myself, whether this is user-installed or
system-installed, and it helps me discriminate between multiple entries
of the same name.

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

iEYEARECAAYFAk4ARfIACgkQkX2Xpv6ydvSvSwCeIKcHoA3XydXEoTZh2wF387tb
liEAoPAlaBgcE9hLMgggKOUxF+rTk7IH
=mi6B
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] New externals

2011-05-30 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-05-29 21:40, András Murányi wrote:
 
 use [speedlim] from... err, it's included in iemlib, maxlib and cyclone, and


or write one yourself. it takes about 6 basic objects.

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

iEYEARECAAYFAk3jRGoACgkQkX2Xpv6ydvTNjACeISrd7hJykUiw1erSOuds9TG4
2YcAoL3QFL4ErPAOGLEboOpT7+0hKmfQ
=DmQr
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pd-cvs Digest, Vol 75, Issue 5

2011-05-30 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-05-30 12:00, pd-cvs-requ...@iem.at wrote:
 Message: 1
 Date: Thu,  1 Jan 1970 07:39:28 -0500 (EST)
 From: p...@macosx104-powerpc.idmi.poly.edu (Pd User)
 Subject: [PD-cvs] autobuild: pd-extended macosx104-powerpc 1970-01-01
   03.15.05

seems like the system time of the osx10.4 build bot has been reset.


 
 Message: 2
 Date: Sun, 29 May 2011 08:02:52 -0400 (EDT)
 From: p...@ubuntu-dapper-i386.idmi.poly.edu
 Subject: [PD-cvs] autobuild: pd-extended ubuntu-lucid-i386 2011-05-29
   08.01.11
 sh: cannot create /dev/null: Permission denied

and

 Message: 3
 Date: Sun, 29 May 2011 08:03:33 -0400 (EDT)
 From: p...@ubuntu-dapper-i386.idmi.poly.edu
 Subject: [PD-cvs] autobuild: pd-extended ubuntu-natty-i386 2011-05-29
   08.01.11
 sh: cannot create /dev/null: Permission denied


seems like the chroot jails do not have /dev mounted properly.

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

iEYEARECAAYFAk3jl5MACgkQkX2Xpv6ydvRb4wCgrV8BNUeB8BnQetNEUOGPrnur
AHkAn24Q4aay8LNi2HGoJOYsOPAdbFSe
=yP5r
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pointers changing/corrupting (used to be signal nan values)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-04-27 12:08, Andrew Hassall wrote:
 
 Anyone have any ideas why the pointer would change so dramatically? Is
 it being corrupted? if so any ideas what by?

do you mind sharing the complete code?

and an unrelated issue with your code:
you shouldn't call outlet_list() from within your perform routine;
rather, it should be scheduled in the next tick (using
clock_delay(0))...of course this will delay the analysis by one block

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

iEYEARECAAYFAk23764ACgkQkX2Xpv6ydvQAzQCfZNq2N06FQ3GPAWA89cdUE7W0
Ac4An0xrX0Kt7c6dRAqVzIdFLB657b9G
=/Ocz
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pointers changing/corrupting (used to be signal nan values)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-04-27 13:17, Andrew Hassall wrote:
 No thats fine, I've attached both c files. (they are a bit messy at
 the moment due to debugging and tearing them apart sorry, if you need
 cleaner commented code I can comment it up no problem)

a quick glance at lpcanalysis_tilde_new() reveils, that you are
allocating data on the stack (which will be freed as soon as you leave
lpcanalysis_tilde_new()!), store their addresses and re-use them later
(when the memory is already freed).

you cannot do:
ko
void*lpca_new() {
 //...
 t_sample winlis[2088];
 x-win=winlis;
 //...
}
/ko

instead you have to do:
ok
void lpca_free(x) {
 freebytes(x-win);
 //...
}
void*lpca_new() {
 //...
 x-win=getbytes(2088*sizeof(t_sample));
 //...
}
/ok

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

iEYEARECAAYFAk24A0wACgkQkX2Xpv6ydvQ5EACaAtBHvzr0T7QpzvcfsaFTR4X9
ugAAoIdCSDfLOc1qMiegTv0+gRncrJq0
=Tt6y
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pointers changing/corrupting (used to be signal nan values)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

some more comments, to fill in the gaps:

On 2011-04-27 13:51, IOhannes m zmoelnig wrote:
 a quick glance at lpcanalysis_tilde_new() reveils, that you are
 allocating data on the stack (which will be freed as soon as you leave
 lpcanalysis_tilde_new()!), store their addresses and re-use them later
 (when the memory is already freed).

which is not a good idea.
instead, you have to allocate on the heap, and manually free once you
don't need the data anymore.

 
 you cannot do:
 ko
 void*lpca_new() {
  //...
  t_sample winlis[2088];
  x-win=winlis;
  //...
 }
 /ko
 
 instead you have to do:
 ok
 void lpca_free(x) {
  freebytes(x-win);

which really should read:
freebytes(x-win, 2088*sizeof(t_sample));

  //...
 }
 void*lpca_new() {
  //...
  x-win=getbytes(2088*sizeof(t_sample));
  //...
 }
 /ok

and of course it would be nice, if 2088 was not hardcoded, but insteadbe
settable; e.g.
nice
void lpca_free(x) {
 freebytes(x-win, x-winsize*sizeof(t_sample));
 //...
}
void*lpca_new() {
 //...
 x-winsize=2088;
 x-win=getbytes(x-winsize*sizeof(t_sample));
 //...
}
/nice


fgmasdr
IOhannes


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

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

iEYEARECAAYFAk24BRAACgkQkX2Xpv6ydvRiZwCguQoy5rXGsBSX+5BRrFssYDOi
EckAoKyLf08ZtXkFWZnraZF2Y9QOnDpP
=1g/W
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pointers changing/corrupting (used to be signal nan values)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-04-27 18:09, Andrew Hassall wrote:
 When allocating memory with getbytes how do you refer to it as an
 array? I can't seem to set values in the allocated memory using
 *(mybytes+index) like normal.

as long as you only have one-dimensional arrays, the 2 are exactly the
same: a linear memory allocation.
array is only how you chose to think of it.

btw, normal is something very subjective, but i would access array
elements as:
mbytes[index] rather than *(mbytes+index)

 x-win=getbytes(x-winsize*sizeof(t_sample)); do you still refer to
 them in the same way as arrays e.g. *(win+10) to get value at index
 10?

don't get me wrong, but a good book on C would probably help :-)

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

iEYEARECAAYFAk24SHUACgkQkX2Xpv6ydvSsogCgvmke4fM/k55xl5KwnclP9ONj
oxwAnjseLJqCBCt9gKym5jsztnHd59tV
=QLMb
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] svn: let's move pdgui-plugins

2011-02-28 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

right now the gui-plugins in our svn-repository live in
 /trunk/scripts/guiplugins/


i find this most unfortunate, since
a) the other scripts in the /trunk/scripts/ section are mainly
concerned with build-systems and the like, and could thus be considered
meta, unlike the gui-plugins

b) as a user i couldn't care less whether the gui-plugins are written in
a scripted language or not



i would therefore propose to immediately move the
/trunk/scripts/guiplugins/ to /trunk/guiplugins/ to avoid any further
confusion.


sidenote: right now, there are 8 subdirectories in
/trunk/scripts/guiplugins, all of them committed by hans.

so the switch is unlikely to create any havoc.



fmgasdr
IOhannes


PS: i would also like to re-propose to move trunk/abstractions into
trunk/externals
while they are not externals in the compiled binary objects that are
dlopen()ed sense, they are external to Pd. otoh, many libraries in the
trunk/externals/ section contain not only compilable code but also (or
exclusively) abstractions.
the segregation between the two seems artificial.



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

iEYEARECAAYFAk1reNUACgkQkX2Xpv6ydvQAuQCgsUmlRRDA++y87jbg7DqsJ52m
2OYAn2bOCae07DfjBcHQIapdCQANygqZ
=Ebrr
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-24 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-23 21:52, Hans-Christoph Steiner wrote:
 It seems to me the way to really do this would be to have post() and
 logpost() find out the calling object instance on its own, if that's
 possible.  Then it would automatically apply to all externals, which
 would be sweet.

i think this is partly possible (afair, maju had something like this in
desiredata).

however, i imagine it will only work for objects which are triggered via
messages (as Pd could track when a message enters an instance, and set a
static variable to this instance)

otoh, it most likely won't work with objects triggered directly by
t_clock events, it makes delegation hard (e.g. when creating an
abstraction, you might want to appear a message to come from the
abstraction itself, rather than from one of the objects inside of the
abstraction...cf. iemgut's pderror object)
and it will go havoc with multithreading  (not that Pd properly supports
multithreading; however, i'm a firm believer that global states are evil
and we should try to generate as few thread-unsafe-by-design code)

finally, post() is sometimes used to printout messages that are not
associated with an object at all.
e.g., where do you want to jump to at I/O error, audio stuck, or at
GEM: Authors : Mark Danks (original version)


therefore i think it is a good idea to make the new logpost() behave
similar to pd_error(), as it allows us to explicitely associate an
object (of our choice!) with a message.
since it might be a nice feature to have traditional error and post
messages associated with an object, this functionality could be added
for the sake of those old APIs

but let's not do automagic if there is no need at all.

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

iEYEARECAAYFAk1mEiwACgkQkX2Xpv6ydvTNVgCg0ltEgxaZCE4cPJOGOAo5BKE7
KA4AoJDG0iH/q2kDDhZ5eJkroiLBdJK0
=2DuL
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-23 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-22 23:26, Hans-Christoph Steiner wrote:

 This would be very nice, I could see being about to double-click any
 line in the log and have it pop up which object made the log message.  I
 won't have time to implement this in the foreseeable future.

well, the thing is that for now we only have to reserve an additional
variable objectID for the logpost(), which could be NULL/empty.

logpost(objectID, level, msg,...)

then, time permitting, fill in the missing code on both the C and the
tcl side.

i only try to avoid re-defining functions in each release.

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

iEYEARECAAYFAk1kv+EACgkQkX2Xpv6ydvSwBgCgo6RN/x9JLYFllMCQ+qbvuZPD
HhsAn2lm8oarnFAjoaUGhwl0qIRIzluU
=yiC7
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-23 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
 On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
 
 This would be very nice, I could see being about to double-click any
 line in the log and have it pop up which object made the log message.  I
 won't have time to implement this in the foreseeable future.
 
 well, the thing is that for now we only have to reserve an additional
 variable objectID for the logpost(), which could be NULL/empty.
 
 logpost(objectID, level, msg,...)
 
 then, time permitting, fill in the missing code on both the C and the
 tcl side.
 
 i only try to avoid re-defining functions in each release.
 

anyhow, here is a draft for how this would work (to be applied on top of
pd-extended.git#fac011b1)

apart from changing the logpost() functions, it also adds a new global
method to Pd that allows for selecting/highlighting an object based on a
symbolic representation of it's address.

like alway, most work was spent in trying to figure out things in tcl :-)


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

iEYEARECAAYFAk1k48MACgkQkX2Xpv6ydvS8VwCfYq29mkl4YkiFmY7tRa4yraag
ucIAnijfsT7Io+WR0ImMnwxDgdhcCU1C
=dseN
-END PGP SIGNATURE-
From 1d09f7ec70eb5eefb8ef48d8347eeef8605f21dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?IOhannes=20m=20zm=C3=B6lnig?= zmoel...@iem.at
Date: Wed, 23 Feb 2011 09:56:06 +0100
Subject: [PATCH] find errors by double-clicking on the error-message

---
 src/m_glob.c|3 ++
 src/m_pd.h  |2 +-
 src/s_print.c   |   62 +++---
 tcl/pd-gui.tcl  |6 ++--
 tcl/pd_connect.tcl  |8 +++---
 tcl/pdwindow.tcl|   45 +-
 tcl/wheredoesthisgo.tcl |2 +-
 7 files changed, 82 insertions(+), 46 deletions(-)

diff --git a/src/m_glob.c b/src/m_glob.c
index 613603a..1e0dffa 100644
--- a/src/m_glob.c
+++ b/src/m_glob.c
@@ -20,6 +20,7 @@ void glob_meters(void *dummy, t_floatarg f);
 void glob_key(void *dummy, t_symbol *s, int ac, t_atom *av);
 void glob_audiostatus(void *dummy);
 void glob_finderror(t_pd *dummy);
+void glob_findobjectid(t_pd *dummy, t_symbol*s);
 void glob_audio_properties(t_pd *dummy, t_floatarg flongform);
 void glob_audio_dialog(t_pd *dummy, t_symbol *s, int argc, t_atom *argv);
 void glob_audio_setapi(t_pd *dummy, t_floatarg f);
@@ -103,6 +104,8 @@ void glob_init(void)
 gensym(audiostatus), 0);
 class_addmethod(glob_pdobject, (t_method)glob_finderror,
 gensym(finderror), 0);
+class_addmethod(glob_pdobject, (t_method)glob_findobjectid,
+gensym(findobjectid), A_SYMBOL, 0);
 class_addmethod(glob_pdobject, (t_method)glob_audio_properties,
 gensym(audio-properties), A_DEFFLOAT, 0);
 class_addmethod(glob_pdobject, (t_method)glob_audio_dialog,
diff --git a/src/m_pd.h b/src/m_pd.h
index 9bdf5b9..c2de403 100644
--- a/src/m_pd.h
+++ b/src/m_pd.h
@@ -451,7 +451,7 @@ EXTERN t_propertiesfn class_getpropertiesfn(t_class *c);
 
 /*    printing - */
 EXTERN void post(const char *fmt, ...);
-EXTERN void logpost(int level, const char *fmt, ...) ATTRIBUTE_FORMAT_PRINTF(2, 3);
+EXTERN void logpost(const void*object, const int level, const char *fmt, ...) ATTRIBUTE_FORMAT_PRINTF(3, 4);
 EXTERN void startpost(const char *fmt, ...);
 EXTERN void poststring(const char *s);
 EXTERN void postfloat(t_floatarg f);
diff --git a/src/s_print.c b/src/s_print.c
index f1c7f2f..3ecf39d 100644
--- a/src/s_print.c
+++ b/src/s_print.c
@@ -38,7 +38,16 @@ static char* strnescape(char *dest, const char *src, size_t len)
 return dest;
 }
 
-static void dopost(const char *s)
+static char* strnpointerempty(char *dest, const void*ptr, size_t len) {
+  *dest=0;
+  if(ptr) {
+snprintf(dest, len, .x%lx, ptr);
+  }
+  return dest;
+}
+
+
+static void dopost(const void* obj, const char *s)
 {
 if (sys_printhook)
 (*sys_printhook)(s);
@@ -46,12 +55,12 @@ static void dopost(const char *s)
 fprintf(stderr, %s, s);
 else
 {
-char upbuf[MAXPDSTRING];
-sys_vgui(::pdwindow::logpost 3 {%s}\n, strnescape(upbuf, s, MAXPDSTRING));
+  char upbuf[MAXPDSTRING], obuf[MAXPDSTRING];
+sys_vgui(::pdwindow::logpost {%s} 3 {%s}\n, strnpointerempty(obuf, obj, MAXPDSTRING), strnescape(upbuf, s, MAXPDSTRING));
 }
 }
 
-static void doerror(const char *s)
+static void doerror(const void*obj, const char *s)
 {
 char upbuf[MAXPDSTRING];
 upbuf[MAXPDSTRING-1]=0;
@@ -66,11 +75,12 @@ static void doerror(const char *s)
 fprintf(stderr, error: %s, s);
 else
 {
-sys_vgui(::pdwindow::logpost 1 {%s}\n, strnescape(upbuf, s, MAXPDSTRING));
+  char obuf[MAXPDSTRING];
+  sys_vgui(::pdwindow::logpost {%s} 1 {%s}\n, strnpointerempty(obuf, obj, MAXPDSTRING), strnescape(upbuf, s

Re: [PD-dev] status of verbose() in 0.43?

2011-02-22 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-22 07:32, Hans-Christoph Steiner wrote:

 So how about this:

 - keep verbose() as it is
 - add logpost(level, message) to both Tcl and C
 - change ::pdwindow::post to mirror the C post() i.e. remove level
 - remove ::pdwindow::fatal, ::pdwindow::warn, ::pdwindow::info since
 they are not used anywhere
 - keep ::pdwindow::post ::pdwindow::error ::pdwindow::bug

seems like a good idea.

 I just pushed to pd-extended.git a reworking of the Pd window and the

i haven't looked into that yet.

 post code, adding logpost() and dynamic updating of the log level.  It
 now keeps all messages in a buffer, then when you select a loglevel from
 the Pd window, it'll clear the Pd window and refilter the whole log
 based on the new log level. 

i don't know whether this is so practical.
e.g. in my personal way of working i find that i often (ab?)use the
pd-console as a scratchpad, where i add comments or (more often) insert
spaces to group important information together.

but maybe the 2 interests don't clash in reality, so i don't have s very
strong opinion about it.


  In the process I found some tweaks that
 make things run much faster when posting lots of messages, so that's
 nice.  

sounds good.

 I'd like to refactor this into something for Pd 0.43. Miller, IOhannes,
 what do you think?

while we are at it, there is one more thing which i would like to have
in post() on the long run: attach the calling object to a special message.
the idea is, that (esp. with errors, but why not other messages as
well?), that you could double click on a message and it will bring you
to the object that sent it (if available/applicable)

right now this is only possible with pd_error (as this is the only fun
that explicitely gets a reference to the sending object), but it would
be nice if this could be done  for all printouts.

this would obviously need another argument on the tcl-side.

fgasdmr
IOhannes

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

iEYEARECAAYFAk1jcTEACgkQkX2Xpv6ydvT3pQCg0VQQd/KoCuKTAJhxgmVUp8Fb
QRUAoLpszau/lvZ+bHc4ehRUkFi/N5zy
=54AH
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-16 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-16 04:53, Hans-Christoph Steiner wrote:
 
 Do you remember why those incr 4 and level+4 are there to begin

yes, so that verbose(0, is not the same as error(

 with?  I think removing that is the best solution, 

the duplication should be removed.

 and then leave 0-5
 levels.  That way 5=all.

i don't think so.
verbose(3, should have higher priority than verbose(6,

even if nobody uses such high verbosity levels now (at least i don't
know any use cases), all should be ALL, and not =5.

it's a conceptual difference, and we shan't mingle our ideas with what
might be practical with conceptual differences
(ah, it's still early in the morning; forgive my pompousness)

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

iEYEARECAAYFAk1bmDkACgkQkX2Xpv6ydvRzXQCfT/IGS8u65Zn4QIM01zEAbdEe
5c8AoLoYU2fTLpGOCQlhouxGQq60ym6b
=BHJM
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-15 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-15 01:59, Hans-Christoph Steiner wrote:
 
 Hmm, this might be the problem, in doverbose():
 
 sys_vgui(::pdwindow::post %d {%s}\n, level+4, strnescape(upbuf, s,
 MAXPDSTRING));
 
 Why is there level+4?  Why not just pass level straight thru?
 

because level#0==pd_error, level#1=error, level#2=post, ...
or similar (and without looking at the code, i don't know what level#3
is for)

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

iEYEARECAAYFAk1aQaEACgkQkX2Xpv6ydvQ9/gCffurcYLodCgIrY2ibhnfv1taj
+qwAnieI23vNVLxjshHGXIJ/krRRwMB/
=t561
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] status of verbose() in 0.43?

2011-02-15 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-02-15 16:15, Hans-Christoph Steiner wrote:

 I get the ranked levels, that stuff make sense.  I am wondering about
 the algorithm.  In both C and Tcl, the verbose() posting is adding 4 to
 the level value, so that means if people are doing verbose(4, my
 message), it actually gets set to (8, my message), and from what I
 see, then it never gets printed, since the available display levels are
 0-5.


yes, that (having only display-levels 0-5) is probably a problem/bug.
maybe it would be good to have a level all.


fgmasdr
IOhannes


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

 


 There is no way to peace, peace is the way.   -A.J. Muste




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

iEYEARECAAYFAk1aoX0ACgkQkX2Xpv6ydvSPzQCfdgABUXGS32DdQJPvrb9GKueZ
2cgAnjYNYCp8LFuTJ7XRk216BJImZJBT
=Iong
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] sourceforge cleanup

2011-02-10 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi all,

i want to inform you, that i have done a routine cleanup of our
developers at sourceforge.

18 people, who have not committed anything within the last two (2)
years, were contacted on the 2011-01-20 (that was also the deadline for
the 2 years period), that they are scheduled for removal within one (1)
week, if they do not oppose.

after that i got into contact with 3 people opposing to their removal,
and 3 people aggreing to their removal.

today (after 3 weeks of waiting rather than 1 as promised), i have
revoked developer status of the following inactive members:
aschix, chr15m, chunlee, david_merrill, grholzi, j45ch, krzyszcz,
mjmcgonagle, morellid, olafmatt, reakin, xovo

those who do check their fingers, might notice that 2 developers are
missing. i consider them still pending: ggeiger, of puredata fame, who
has not yet answered (and it's technically more complicated to remove an
admin than an ordinary developer); and ix9 who had a bouncing email
address (but who might be reachable via IRC)


mfgadr
IOhannes

PS: that's the original mail body i sent to all those devs:

snip
Hi,

you are a registered developer at the pure-data sourceforge project,
which means that you have write access to the repository hosted there.

our project currently has 43 registered developers, some (18) of them
being inactive.
as the administrator of the project, i would like to reduce the number
of developers to the active ones.

since you haven't committed anything within the last two (2) years, you
are considered to be inactive, and therefore i would like to remove
you from the list of developers.

if you ever feel like you need developer status (=write access to the
repository) again, just send an email to the pd-dev mailinglist.

the list of inactive developers has been assembled in an half-automated
way.
so if you feel that this is totally unjustified, please tell me within
the next week and i will not remove you from the list of active-developers

mfg.asdr
IOhannes
/snip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1TuSQACgkQkX2Xpv6ydvRYdQCg2kCx9iT6DSqL3BPKU25pOjdB
7Z4AoI7xx4M5hXCA0Qnlk7qX8hsNakWY
=aDqD
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 64bit linux compiling issue

2011-01-24 Thread IOhannes m zmoelnig

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-01-24 19:57, Felix Pfeifer wrote:
 Hi,
 
 
 
 Here is what i did:
 I compiled pd-extended-0.42.5 on a 64bit slackware
 linux. Everything seemed to work fine until i try to run

then i would say it is _not_ a compilation issue.

 pdextended. I tried to fix the errors but after that i
 encountered new errors which i wasn't able to fix.
 
 Here is the console output and my commands:
 
 $ pdextended
 sh: /usr/bin/pd-gui: No such file or directory
 ^CPd: signal 2
 $ locate pd-gui
 /usr/lib64/pd-extended/bin/pd-gui
 $ su
 # ln -s /usr/lib64/pd-extended/bin/pd-gui /usr/bin/pd-gui
 $ pdextended
 tcl: /usr/bin/pd.tk: can't open script

this strongly reminds me of a bug we fixed in debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596780


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

iEYEARECAAYFAk09zPQACgkQkX2Xpv6ydvRPOACeMJvnUVF3uTY4lP0VuzLsexez
zmEAoNjaNvgN7eVHf3CRymif/HSNs7jG
=cRft
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] about [tcpserver] (mrpeach and iemnet)

2010-12-13 Thread IOhannes m zmoelnig

On 2010-12-13 17:43, Hans-Christoph Steiner wrote:

 
 From what I've seen, most network buffering is done with a ring buffer,
 so a fixed size.  That's my two bits...


flames
so what exactly are you trying to tell us?

one of the reasons for me to change my entire system and to switch to Pd
was choice: to make computers do what i prefer rather than what 'they'
think i ought to prefer.
even if i choose to prefer what has been chosen for me anyhow.
/flames


mfgdf
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] about [tcpserver] (mrpeach and iemnet)

2010-12-13 Thread IOhannes m zmoelnig

On 2010-12-13 23:15, Roman Haefeli wrote:
 On Mon, 2010-12-13 at 14:42 -0500, Martin wrote:
 What? It's better to crash the server than to disconnect an unresponsive 
 client?
 
 Why crashing the server? I don't get the alarmism. If a patch needs to

i think martin commented on my if you rather go and crash or
whatever...it's up to you.

and yes, i do think that if i as a patcher decide that it is the proper
response to an unresponsive client to fill up the buffer until the
server crashes, than i should be able to do this.

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] removing non-free code from pure-data SVN

2010-12-09 Thread IOhannes m zmoelnig

On 2010-12-08 21:37, Xavier Miller wrote:
 Hello,
.
 
 So, yes, please list ALL the licences which are included in
 PD/PD-extended, especially those that are not compatible with common
 Open Source / Free licences !
 At least users need to know they use non-free parts of software, and use
 it being aware of it.

i head the impression, that we are not talking what is included in
pd-extended here.
instead we are talking about the source code hosted in the public
pure-data repository at sourceforge.
while Pd-extended includes most stuff from this repository and hardly
anything else, the two are independent.

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] removing non-free code from pure-data SVN

2010-12-09 Thread IOhannes m zmoelnig

On 2010-12-09 16:32, Hans-Christoph Steiner wrote:
 
 First off, I need to say I think Yves' code is great and very useful,
 and he's doing important work that no one else is currently doing.  This
 has nothing to do with that.  Yves changed his license to a non-free
 license, which he is free to do, but there are real effects to doing that:
 
 - SourceForge does not allow non-free code

again, i'd suggest to wait till sf takes action.

 - it cannot be legally distributed because the terms of each license are
 in conflict with each other (Yves' license vs GPL)

then we should not distribute it.

 - it cannot be included in Pd-extended, its GPLv3

i haven't checked closely, but i guess there are other parts of PdX that
would violate that as well.
i'm thinking of code that its GPLv2 without the or any later version
clause.

 Yves' license is in direct conflict with the GPL'ed code of others that
 is included in both pidip and unauthorized. So if you use it, either
 Yves or the other GPL'ed copyright holders can sue you for copyright
 violations.

but this is not really a problem of the files being hosted.
it is a problem, if you distribute these libraries and tell people they
are safe (and the code is GPLv3, or whatelse)

 
 Yves has made his decision, and he said to remove his code
 (http://lists.puredata.info/pipermail/pd-list/2010-12/084998.html), so

i interprete his statement as please remove pidip/unauthorized from
Pd-extended and not as please remove my code from sourceforge.
even if it was the latter i'd ignore it, as yves has full access to the
repository and can remove the code himself (which he did not do; instead
he did something else: he changed the license in the repository, which
(for me) implies that he still thinks the repository of some relevance)

 now we need to make ours.  I'm not touching pidip anymore, so I'm fine
 with it staying in pure-data SVN or not.  unauthorized was GPL until a
 few days ago, so I think we should maintain a clean GPL fork in the
 pure-data SVN.  That means removing the non-free unauthorized.

not at all.
if you want to fork unauthorized, then do a fork, and remove the
original code.
i'd suggest forking it under the name authorized :-)

fgmadsr
IOhannes






smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] general makefile question

2010-12-02 Thread IOhannes m zmoelnig

On 2010-12-01 22:38, Bryan Jurish wrote:
 moin folks,
 
 On 2010-12-01 18:00:21, IOhannes m zmoelnig zmoel...@iem.at appears to
 have written:
 what is the canonical way to use the passed FLAGS and at the same time
 adding whatever is needed?
 something like 'PD_LDFLAGS=-Wl,--export-dynamic  -shared $(LDFLAGS)'
 and then consequently using $(PD_LDFLAGS) in the linking stage?
 
 That's probably the safest way, but a bit unwieldy...  I would tend to
 favor:
 
   LDFLAGS += -Wl,--export-dynamic

yes that was my first guess.
unfortunately this does not work at all.
it seems that make will simply ignore any assignments to a variable that
has been defined via cmdline arguments (not via environment variables
though, which have low precedence)

 
 in the local (pd) Makefile, just in case there happens to be something
 important in the caller's (packager's) flags... but maybe the +=
 operator is a GNU make extension?  Maybe := in the Makefile would work

the same as above.
really the only way i found to do an assignment to a variable declared like
$ make MYVAR=foo
was to add the override directive in the Makefile.

 to append to any predefined LDFLAGS?  Or is := also a GNU extension...
 I don't really ever write makefiles for anything other than GNU make, so
 I'm not too sure...

and all this without even bothering about GNU extensions yet!

 
 On 2010-12-01 18:16:47, Hans-Christoph Steiner h...@at.or.at appears
 to have written:
 But if you really want to have all the possibilities for overriding
 things, then go with autotools, especially with automake.  They generate
 makefiles that have lots of room for customization.
 
 +1

again, i do like autoconf but sometimes it is really out of question.
right now i am _also_ talking about the template Makefile (and how to
make this more robust and behave like expected), and autotools is a
no-go here.

 
 ... but I'd like to note that autotools involve a whole new dimension of
 headaches with *FLAGS variables.  In particular, AC_PROG_CC() sets
 CFLAGS=-g -O2 by default for gcc (if it's otherwise unset), which is
 not the kind of default I usually prefer.  You can reset it explicitly
 in configure.ac or Makefile.am (say CFLAGS=-O2), *but* then you lose
 any CFLAGS your caller might have actually passed in explicitly (e.g.
 CFLAGS=-O32767 -fSuperDuperPooperScooper -WWillRobinson).  I usually

i think this is basically the same problem as i have.

the user should be able to set the CFLAGS they like, while at the same
time when doing so they should not be breaking the build system by
default, which they are currently doing.


mfgsdr
IOhannes





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] general makefile question

2010-12-02 Thread IOhannes m zmoelnig

On 2010-12-01 23:56, Albert Graef wrote:
 IOhannes m zmölnig wrote:
 however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by
 the user, so setting those should not break the build system.
 
 Exactly. Therefore a Makefile should *not* set CFLAGS, CXXFLAGS, LDFLAGS
 and the like, or only set them to some reasonable defaults which can be
 freely overridden by the user. Of course this means that build-specific
 options must be passed in the corresponding Makfile rules in addition to
 these variables.

finarlly someone who understands me!

 
 This is only a convention, of course, but it's part of the GNU Coding
 Standards 

ha, thank you very much for the pointer.
i think the curcial part is:
If there are C compiler options that must be used for proper
compilation of certain files, do not include them in CFLAGS. Users
expect to be able to specify CFLAGS freely themselves.

and i think this can also be extrapolated for any of the standard flags
(CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS)

masdr
IOhannes




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] split out 'osc' and 'net' from 'mrpeach'?

2010-12-01 Thread IOhannes m zmoelnig

On 2010-12-01 03:02, Hans-Christoph Steiner wrote:
 
 I call mrpeach/net canonical not because I believe is it perfect and
 bugfree, but rather because it is the established, proven way of doing
 more elaborate networking.  

i think it is not canonical as it tends to change it's API to workaround
certain problems.

 Its the best option out there. iemnet is
 just a fork of that with some specific changes.  iemnet is very new and
 not tested as much, so it seems a really bad idea to start basing things
 off of it,

i'd rather not read the above.

anyhow, i definitely wouldn't call iemnet the canonical.
i think canonicity should be more about the object's API than about the
implementation itself.

  like how to package things in Debian, etc.  Who knows,
 perhaps mrpeach/net and iemnet will merge again.


that is desireable from my pov (but there is still some work todo on the
iemnet part, which i would like to be not hindered by legacy code)

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] general makefile question

2010-12-01 Thread IOhannes m zmoelnig

during the debian packaging of externals i once more stumbled across one
of my many problems with make, which i was never able to solve in a
satisfactory way.

it is:
the Makefile uses CFLAGS and LDFLAGS to set crucial flags to the build
process e.g. LDFLAGS uses -Wl,--export-dynamic -shared to build shared
libraries (in our case: externals)

however, some meta build processes (like debian packaging) explicitely
set these FLAGS to what they think are good optimization/debugging defaults
e.g. make get's called like
$ /usr/bin/make LDFLAGS= CFLAGS=-I/usr/local/include

this however effectively disables all the settings done within the
Makefile, which leads to not passing -Wl,--export-dynamic  -shared to
the linker, leading to a fatal error when linking.

what is the canonical way to use the passed FLAGS and at the same time
adding whatever is needed?
something like 'PD_LDFLAGS=-Wl,--export-dynamic  -shared $(LDFLAGS)'
and then consequently using $(PD_LDFLAGS) in the linking stage?

this is such a fundamental thing that i'm sure there has to be an
elegant solution to this but i never came across one.
the PD_LDFLAGS seems a bit like a kludge to me.

fgmsdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Where to report issues with 0.43 development branch?

2010-11-30 Thread IOhannes m zmoelnig

On 2010-11-30 11:43, Roman Haefeli wrote:
 Hi
 
 If people are supposed to already report bugs with the current dev
 (0.43) branch, where should they do so?

i'd say here or at the sf-tracker.


 
 Is this the correct place to get most recent sources from:
 git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data

yes.


fgmkasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] split out 'osc' and 'net' from 'mrpeach'?

2010-11-29 Thread IOhannes m zmoelnig

On 2010-11-29 18:36, Hans-Christoph Steiner wrote:

 
 It is OK IMHO to have iemnet use the names as the mrpeach objects as
 long as the stated goal is interface compatibility.  But I think this
 packaging idea is just added complication without and real benefit.  A
 library is a library in Debian from what I have seen.  I've never seen
 this kind of arrangement for libraries in Debian, so I think it would be
 a bad idea to start it with Pd.

i mean something like libGL; this has been in debian for a while.

b,sdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread IOhannes m zmoelnig

On 2010-11-10 22:06, Roman Haefeli wrote:

 
 In the case of iemmatrix (and also zexy, which actually already is
 packaged as a multi-object-single-file library in Debian, but as a
 one-object-one-file library in Pd-extended) and assuming that there
 won't be any intelligent loader loader soon, what is the best way to go?


as upstream i would highly recommend to package it as a library.
if someone sees a need to _also_ package it as multi-file library, one
could create 2 binary packages out of the one source package.
but _please_ package iemmatrix as single-file-library until all problems
with hexloader are sorted out.

fgmnasdr
IOhannes

PS: i knew there was another library i should have packaged for debian.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread IOhannes m zmoelnig

On 2010-11-11 10:07, Roman Haefeli wrote:

 
 pd-iemmatrix:
   generic single-file library depending on the metapackage 'pd'.
 
 pdextended-iemmatrix:
   dedicated iemmatrix package for Pd-extended, dependent on 
   'pd-extendeded', compiled as one-object-per-file library.
 
 What do you think? Does that work for everyone, Hans, IOhannes?


i agree, that the prefixes should reflect the Depends: clause.
(pdextended-iemmatrix should thus 'Depend' on pd-extended)

however, i don't see, why pd-iemmatrix-multifile (this is _not_ a
proposal for a good name) should not be able to run with puredata (if
the user deliberately choses so), so one should not tie this package to
pdextended.

 OTOH, i could imagine that there won't be acceptance from the
 pkg-multimedia team for including the same package twice, besides the

this we should probably discuss on the pkg-multimedia list.

 fact that this is very ugly. But I don't see another way than this or
 consciously breaking Pd-extended. 

the question is, how much will break in reality.
people using [import iemmatrix] and consequently using [mtx_egg] will
not experience any degradation in flavour.
people wanting to use [mtx_*] with multifile have a stale flavour anyhow.

anyhow, until pd-hexloader is packaged, this discussion is quite moot
anyhow.
i don't think that switching from single-binary to multi-binary in the
package would cause much trouble.

 PS: i knew there was another library i should have packaged for debian.
 
 I didn't mean to take that away from you. Before I started I wanted to
 point out possible issues. 
 

though now i have created some ITPs for various iem-packages, including
iemmatrix ;-)

mcvasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] some late 0.43 patches...

2010-10-18 Thread IOhannes m zmoelnig

hi miller, list...

i hear you are busy doing some bugfixing for the 0.43 release with hans...
working on the integra-live project i noticed a number of problems with
the portaudio support in Pd, some of them being real showstoppers (read:
they crash Pd)

i submitted a number of patches to sourceforge that should fix these
problems (as well as one last amendment to the functions exported in
s_stuff.h, needed for my external controlling the audio settings)

it would be great if you could include them.

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] autotools on MinGW/MSYS

On 2010-09-14 17:42, Hans-Christoph Steiner wrote:

 i believe the patch i attached to the ticket to solve the problem but
 have not been able to test on the very platform.
 

ok, i managed to log in, and my patch indeed solves the reported problem.

however, there are more issues, coming from parts of the new build
system which i never touched.
so i would like to discuss them, before i remove them:


#1 when building with msys, the new build system includes pd-watchdog
unfortunately, the watchdog uses signals and other quite linux specific
stuff. i don't know whether this can be ported, and whether this
actually make sense.

conclusion: i would exclude pd-watchdog from all w32 builds (if people
need signals and whatnot, why don't they use an os that has signals and
whatnot)


#2 when building with msys, the compiler is forced to g++.
there are several problems with this:
-- the user cannot chose the compiler themselves anymore, as the CC
variable is silently ignored and reset to g++
-- no check is done whether there actually is an executable named g++,
it is just assumed. this kind of leads autoconf ad absurdum, as we can
simply check for a valid c++ compiler if needed.

-- most important however: compiling Pd with a c++ compiler can be a bad
idea! the Pd source uses C++ keywords (e.g. template is often used).
throwing this code onto a c++ compiler leads to errors.

conclusion: don't force autoconf to use g++ as the c-compiler, but
rather let it choose the right compiler automagically

if we need a c++-aware linker, then we should ask for a c++-aware linker
(rather than force a c++ compiler). afaik, automake can handle this with
a 1-liner.



masdrt
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] using the MSYS and Cygwin shells on the PdLab server

On 2010-09-15 15:25, Hans-Christoph Steiner wrote:
 
 I'm cc'ing pd-dev so others may benefit from this.  There is nothing
 magic about the files in Cygwin and MSYS, they are all on the same file
 system. The problem is each system has its own root path:
 

sure.

 * in MSYS, its /c

ha, i didn't know that.
c doesn't show up when doing ls /


 I'll check the home dir perms, Windows is a pain to deal with, so sorry
 its messed up.
 

super.

mfgasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] autotools on MinGW/MSYS

On 2010-09-15 15:20, Hans-Christoph Steiner wrote:


 if we need a c++-aware linker, then we should ask for a c++-aware linker
 (rather than force a c++ compiler). afaik, automake can handle this with
 a 1-liner.
 
 
 Try building with the ASIO sources, which are C++ and need to be built

i have to admit that i am unable to get that properly setup on the PdLab
machine (no time for such things).

if i could get a copy of everything needed for building (really no time
for installing things on an os which i don't like; it's ok for just
fixing bugs :-) i know somebody has to do that work and i hate to
delegate it to e.g. you, but i think this is really a matter of
efficiency), i will try.



 with g++.  gcc won't link C++ code into a C binary from what I could
 tell.  So at least the final linking needs to be done with g++.  In

that's what i was saying above: if we need a c++-aware linker, then we
should ask for a c++-aware linker (rather than force a c++ compiler)

 makefile.mingw, all C is built with gcc and all C++ is built with g++,
 then the whole thing is linked with g++.

that's how it is supposed to be.
afaik, automake provides easy ways for that...

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] autotools on MinGW/MSYS