>
>>>> 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. He has done some extremely popular
>>>> RjDj apps and needed to optimize for them as well. Think it would be
&…
[View More]gt;>>> good anyway to keep in touch with libpd users and app programmers
>>>> about this topic, even though we're in an early stage with it.
>>>>
>>>
>>>
>>> Yes definitely, we should let everyone who wants to be get involved. I
>>> am just saying with need a development platform to start with. Once that's
>>> nailed down, we can deal with more issues, like porting to libpd, dealing
>>> with externals that could be either 32-bit or 64-bit, etc.
>>>
>>> I setup a nightly build on the macosx106-x86_64 and called it pd-double.
>>> Andras and r33p, if you are listening, could you run this build on your
>>> 64-bit boxes also? All you need to do is:
>>>
>>> ~pd/auto-build
>>> cp -a pd-extended pd-double
>>>
>>>
>> Listening now.
>> I did:
>> $ cd ~pd/auto-build
>> $ sudo cp -a pd-extended pd-double
>> What's next? Shall I try patching or rather pull IOhannes's sources?
>>
>>
>> If you have the run-automated-builder script in a cron job, that is all
>> you have to do.
>>
>> .hc
>>
>>
> Ah, so tomorrow a single and double precision build will automatically be
> made? Cool.
>
> Also, as I was busy with my life (buying a flat) these days, and I couldn't
> follow the list as precisely as I wished, could you advise me what's the
> current best way to roll my own double precision pd? Because I would like to
> benchmark a fully optimised one.
>
>
> That would great to have those numbers. [...]
>
Aaargh. I've arrived to the point where I have almost no functional pd on my
box (with the exception of l2ork).
vanilla says: "bash: /usr/bin/pd: No such file or directory" (i remember
this is a known issue... for 64bit? can it be fixed by any chance?)
extended (latest autobuild), and the fresh-built double keep on saying
"watchdog: signaling pd..."
What did I mess up? Will complete removals/reinstalls help?
Andras
[View Less]
hi all,
i would like to introduce myself and kindly request for an SVN write access
to pd repository.
My name is Antoine Villeret and i'm working with pd since i met Cyrille
Henry last year.
I'm mainly working on computer vision.
At the very beginning i'm a musician and sound technician then
I started computer vision in 2008 by turning a bodhrán into a touchscreen
during my master thesis.
After that, I worked with Cyrille on a dynamic video mapping system to
project video on moving objects on …
[View More]stage.
It is used in the show *Les Fuyantes *by the French circus company Les
Choses de Rien.
You can have a small overview of the the work here :
http://vimeo.com/37387879
For that work i have to add some features to pix_opencv that are already on
the repository like pix_opencv_calibration, pix_opencv_warpperspective...
(commited by Cyrille).
But i've made some others externals and also corrected lots of bugs.
I also made some examples on how to use my externals.
Moreover I've planned to develop an OpenCL based object mainly to do binary
texture readback.
And I will be happy to share my work with the community :-).
Actually i've already made a copy of the SVN repository on my github
account but it's quite experimental and only used in my personal projects.
I saw that pd, pd-extended and Gem have already migrated to git but about
externals repository ? and mainly pix_opencv ? is it planned to switch to
git too ?
My SF username is : avilleret
Kind regards
antoine
--
do it yourself
http://antoine.villeret.free.frhttp://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour
me contacter
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted …
[View More]By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-30 11:42
Message:
I attached a patch for my solution to the problem at hand: Android file
extensions. It will also fix file extensions for GNU/Linux on ARM. The
original code would make GNU/Linux/ARM use .l_i386.
This also adds '.so' as the default extension when the particular case is
undefined. I think this is better than having the default be nothing at
all, and it should be quite safe since .so is the standard extension for
shared libraries on GNU systems, BSD systems, Android, and others.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-30 07:36
Message:
How about we instead solve the problem listed above in this bug report? I
think we should have the add an #else that sets the file extension to
".so". The generic .dll extension has been used for Windows since forever
and I don't hear about problems there. And then ditch the __ANDROID__
section and move the ARM arch under the __linux__ section.
The file extensions are a mess in terms of accurate naming. __GNU__ and
__FreeBSD_kernel__ are not Linux at all, and they are set to use .pd_linux.
I don't think the kernel even matters for generic externals, it is
probably the libc that matters, so it should be something like .gnu_i386 or
.bsd_i386. Or maybe its the binary format that's more important, i.e.
.elf_i386 and .mach_i386. Makes me think this approach to naming is just
fundamentally flawed.
Lastly, IOhannes, the key part that you are missing about .d_fat/.d_ppc is
that they do not solve any problems. So something that causes a minor
problem, but solves nothing seems pretty worthless to me. Even discussing
it as much as we have seems like a waste of time.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-30 00:28
Message:
for the record, here are the relevant threads i found in the archives:
- http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html
- http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html
as you will see, the only real issue that was ever raised was the increased
load-time when adding more and more extensions. all the "other" issues
where always referred to as "there are other issues which i don't remember
right now, check the archive", without ever giving evidence that there are
indeed other issues.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 20:14
Message:
File extensions are very OS-specific. The Linux extensions are fine
(except perhaps the l_ia64 being the wrong arch). Mac OS X does not need
different ones since you can build universal "fat" binaries.
One example of a problem caused by adding more extensions is that it
increases the load time since Pd will have to check for more variations on
filenames. There are other issues, I don't remember them, but they're in
the archives.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03
Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS. In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted …
[View More]By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-30 07:36
Message:
How about we instead solve the problem listed above in this bug report? I
think we should have the add an #else that sets the file extension to
".so". The generic .dll extension has been used for Windows since forever
and I don't hear about problems there. And then ditch the __ANDROID__
section and move the ARM arch under the __linux__ section.
The file extensions are a mess in terms of accurate naming. __GNU__ and
__FreeBSD_kernel__ are not Linux at all, and they are set to use .pd_linux.
I don't think the kernel even matters for generic externals, it is
probably the libc that matters, so it should be something like .gnu_i386 or
.bsd_i386. Or maybe its the binary format that's more important, i.e.
.elf_i386 and .mach_i386. Makes me think this approach to naming is just
fundamentally flawed.
Lastly, IOhannes, the key part that you are missing about .d_fat/.d_ppc is
that they do not solve any problems. So something that causes a minor
problem, but solves nothing seems pretty worthless to me. Even discussing
it as much as we have seems like a waste of time.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-30 00:28
Message:
for the record, here are the relevant threads i found in the archives:
- http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html
- http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html
as you will see, the only real issue that was ever raised was the increased
load-time when adding more and more extensions. all the "other" issues
where always referred to as "there are other issues which i don't remember
right now, check the archive", without ever giving evidence that there are
indeed other issues.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 20:14
Message:
File extensions are very OS-specific. The Linux extensions are fine
(except perhaps the l_ia64 being the wrong arch). Mac OS X does not need
different ones since you can build universal "fat" binaries.
One example of a problem caused by adding more extensions is that it
increases the load time since Pd will have to check for more variations on
filenames. There are other issues, I don't remember them, but they're in
the archives.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03
Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS. In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By:…
[View More]https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-30 00:28
Message:
for the record, here are the relevant threads i found in the archives:
- http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html
- http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html
as you will see, the only real issue that was ever raised was the increased
load-time when adding more and more extensions. all the "other" issues
where always referred to as "there are other issues which i don't remember
right now, check the archive", without ever giving evidence that there are
indeed other issues.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 20:14
Message:
File extensions are very OS-specific. The Linux extensions are fine
(except perhaps the l_ia64 being the wrong arch). Mac OS X does not need
different ones since you can build universal "fat" binaries.
One example of a problem caused by adding more extensions is that it
increases the load time since Pd will have to check for more variations on
filenames. There are other issues, I don't remember them, but they're in
the archives.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03
Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS. In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted …
[View More]By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 20:14
Message:
File extensions are very OS-specific. The Linux extensions are fine
(except perhaps the l_ia64 being the wrong arch). Mac OS X does not need
different ones since you can build universal "fat" binaries.
One example of a problem caused by adding more extensions is that it
increases the load time since Pd will have to check for more variations on
filenames. There are other issues, I don't remember them, but they're in
the archives.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03
Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS. In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
…
[View More]Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-04-29 11:03
Message:
My intention in having the wierd extensions was to permit people to
distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version
and any OS. In this context
"externs" can be directories containing the various binaries which Pd
distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need
the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the
context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted …
[View More]By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-29 10:36
Message:
Personally, I think its a waste your time and mine. Its been discussed,
check out the archives for the problems it causes. I've long since moved
on. We should be putting this energy solving the issue in this tracker,
rather than beating the .d_ppc/.d_fat dead horse.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
Patches item #3521816, was opened at 2012-04-26 19:25
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By:…
[View More]https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting externals file extension, check for ANDROID platform
Initial Comment:
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-28 10:16
Message:
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any
"problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the
functionality; should i create a patch that re-adds the extensions or
should i modify (eventually remove) the patch that erroneously removes the
extensions?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 19:32
Message:
In response to #1: very few people are using .d_ppc and .d_fat files with
Pd vanilla.
and #2: patches welcome
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-04-27 08:54
Message:
<flames>
"Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extension"...what
exactly is the "lot of issues" here? no other program for Darwin/MacOSX is
called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing
so breaks compatibility with Pd-vanilla, i would say this is a bug in
Pd-extended.
</moreflames>
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-27 07:36
Message:
What about just defining '.so' has a possibility if __linux__, __FreeBSD__,
__FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to
manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no
other program for Darwin/MacOSX uses per-arch file extensions: they use
universal binaries. For this reason , Pd-extended on Mac OS X only uses
.pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also,
Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so
that file extension is just wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3521816&group_…
[View Less]
hey hans,
i just removed my fink install and started over because i somehow made
a huge mess of it.
anyway. other than the gmerlin/gavl/gmerlin-avdecoder packages that
will need to be replaced with burkhards future release your
pd-extended-dev.info works OK ... although I am getting this "The
following packages will be REMOVED: jack-dev "
i am not sure what the issue is there but fink is making me do:
sudo apt-get install pd-extended-dev=0.43.1-1
rather than
fink install pd-extended-dev
…
[View More]not sure what the issue is there but it seems very minor. i dont
remember this before. the whole console output is below.
I also just emailed the maintainers of libdca and amrnb to add their
.infos to fink 10.7. they build fine. they just need to be added to
10.7.
cheers
m
megrimm-mbp:pd-extended-dev.infos megrimm$ sudo apt-get install
pd-extended-dev=0.43.1-1
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
jack-dev
The following NEW packages will be installed:
pd-extended-dev
0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B/1402B of archives. After unpacking 147kB will be freed.
Do you want to continue? [Y/n] n
Abort.
megrimm-mbp:pd-extended-dev.infos megrimm$ fink install
pd-extended-devInformation about 4678 packages read in 1 seconds.
The following package will be installed or updated:
pd-extended-dev
Reading buildlock packages...
Could not resolve inconsistent dependencies!
Fink isn't sure how to install the above packages safely. You may be able to fix
things by running:
fink scanpackages
sudo apt-get update
sudo apt-get install pd-extended-dev=0.43.1-1
Failed: Fink::SysState: Could not resolve inconsistent dependencies
megrimm-mbp:pd-extended-dev.infos megrimm$ sudo apt-get install
pd-extended-dev=0.43.1-1
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
jack-dev
The following NEW packages will be installed:
pd-extended-dev
0 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B/1402B of archives. After unpacking 147kB will be freed.
Do you want to continue? [Y/n]
(Reading database ... 38909 files and directories currently installed.)
Removing jack-dev ...
Selecting previously deselected package pd-extended-dev.
(Reading database ... 38888 files and directories currently installed.)
Unpacking pd-extended-dev (from
.../pd-extended-dev_0.43.1-1_darwin-x86_64.deb) ...
Setting up pd-extended-dev (0.43.1-1) ...
--
____________________
m.e.grimm | m.f.a | ed.m.
megrimm(a)gmail.com
_________________________________
[View Less]