On Oct 3, 2011, at 9:12 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-10-03 14:28, katja wrote:
On Sun, Oct 2, 2011 at 11:36 PM, Hans-Christoph Steiner <[email protected]
> wrote:
I think it makes sense to work off of
pure-data.git rather than pd-extended.git since this is a patch
targetted at
getting into Miller's repo.
Right. Even then, we could add some external libs to work on,
starting
with zexy and cyclone for example. The question is how to load
appropriate executables into local single and double precision test
builds of vanilla Pd. A single preference file is shared by all
vanilla Pd installations, therefore setting searchpaths via
preferences is no option. Each Pd should only load from it's own
'extra' directory. With the extra's included in vanilla Pd, this
works
i'm not sure whether i really understand what you are saying here.
however, as long as a double-precision Pd looks into different paths
than a single precision Pd, we won't have any problems.
however, as soon as a double precision enabled Pd will find such an
external in there, it will go kaboom.
possible solutions to the problem that come to my mind are:
- - use a different filename suffix for double-precision externals.
e.g.
bonk~.pd_linux and bonk~.double.pd_linux
pro: you can ship single and double precision files in a single zip
file
con: yet another special suffix
- - use a different setup function name for double precision, e.g.
bonk_tilde_setup() vs bink_tilde_dsetup()
pro: allows to have both single and double precision objects in a
single
binary
con: needs extra code in each external (esp. if you want to exploit
the
'pro' without resorting to C++-templates...)
con: code need to be made aware for which width it is compiled
- - use a special exported function in the code, that indicates the
width,
for which the object was compiled [*]
pro: backward compatible,
con: needs extra code in each external (could probably done with a
macro).
[*] something like:
int pd_floattype_compatcheck(int runtimetype) {
return runtimetype && COMPILETIMETYPE);
}
COMPILETIMETYPE would be defined in m_pd.h
during load time, before Pd calls the _setup function, it would check
for pd_floattype_compatcheck() and call it with
runtimetype=COMPILETIMETYPE. if the compatcheck returns!=0, then the
external is considered to be compatible with the currently used
COMPILETIMETYPE and can thus be safely used.
if 0 is returned, the external is incompatible and the setup
function is
not called at all (and hopefully the search for a compatible
external is
continued).
if there is no pd_floattype_compatcheck() exported, then we really
don't
know whether we are compatible.
i would suggest to assume compatibility, but make Pd issue a warning
before it tries to load (and run) the object, so people would have a
way
to find out what caused the crash.
alternatively, one could assume "single precision" if the
compatcheck is
missing, and refuse to load it in double precision mode.
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.
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.
I think this could also apply to the file extensions. The 64-bit
ones, like .l_ia64, would assume double-precision, and 32-bit ones
like .l_i386 would be single precision. I'm not yet sure what to do
about .pd_linux. On Mac OS X, we'd still only need .pd_darwin since
the fat binaries handle all the archs. Then the 64-bit code would be
double-precision, and the 32-bit single.
.hc
fine as far as I have seen. I tested bonk~ in single and double
precision Pd simultaneously without symbol collision.
which symbols are supposed to collide?
fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6JtKUACgkQkX2Xpv6ydvTZZgCgu8d045+iv0ju7wvgSTefJBXa
ZfMAoIh2eVZ2uwgh7e5gkjU+itRw3IlT
=vbHJ
-----END PGP SIGNATURE-----
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
