Colet Patrice

----- Mail original -----

De: "Ivica Ico Bukvic" ico@vt.edu À: "Patrice Colet" colet.patrice@free.fr, "pd-list" pd-list@iem.at Envoyé: Vendredi 10 Février 2012 05:25:28 Objet: RE: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedbackappreciated

Hi Patrice,

As I already replied to you off-list you need 2 things:

1. development libraries for compiling the app (which should be

unnecessary if you are using Linux as there are prebuilt binaries)

Indeed, but some libs needs to be replaced by win32 versions, which works differently than under linux.

2. you need a linux machine as currently pd-l2ork may not work well

(or at all) on non-Linux platforms mainly because its pd.tk file needs to be cleaned-up of Linux-centric widgets.

ah, pd.tk is an obsolete file from pd-extended point of view, is a pd-gui.tcl planned for replacing it?

Hope this helps!

Thank you for fast reply :)

...

-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Patrice Colet Sent: Thursday, February 09, 2012 11:19 PM To: pd-list Subject: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedbackappreciated

Hello,

I've tried to run makefile.mingw but it ends up (after a clean ^^) with these error messages:

s_inter.c:83:22: fatal error: execinfo.h: No such file or directory compilation terminated. s_audio.c:18:26: fatal error: sys/resource.h: No such file or directory compilation terminated. x_misc.c:23:23: fatal error: sys/times.h: No such file or directory compilation terminated. x_list.c:15:20: fatal error: alloca.h: No such file or directory compilation terminated. make: *** [makefile.dependencies] Error 1

it seems the compiler is calling linux headers for reasons I don't really get, I don't really have time to go further.

Colet Patrice

----- Mail original -----

...

De: "Ivica Ico Bukvic" ico@vt.edu À: pd-list@iem.at, pd-dev@iem.at Envoyé: Jeudi 26 Janvier 2012 07:08:35 Objet: [PD-dev] New snapshot of pd-l2ork available -- feedback

appreciated

...

Fellow pd enthusiasts and devs,

Apart from a couple of fixes of bugs that surfaced after we implemented infinite undo last month, as of this evening pd-l2ork has added another important feature: moving gop-ed objects via tag. This means that even a 100000-point array will now be moved via gui with a single command with minimal changes to the core pd code, rather than redrawing the entire array every time the array is moved. Same goes for GOP objects and scalars. Needless to mention, this is the first time that my netbook allows me to move large arrays on screen as if they were simple objects :-)

If interested, check out the git at https://github.com/pd-l2ork

x86-64 and i386 builds coming up soon... I am uploading 64-bit builds as I type this, i386 should be up sometime tomorrow. In the meantime you can search older builds via L2Ork's website at http://l2ork.music.vt.edu/main/?page_id=56...

Enjoy!

Best wishes,

-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

---

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

---

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

Thanks a lot!

Ivica, what about using this for backtrace?

http://code.google.com/p/backtrace-mingw/

----- Mail original -----

De: "Mathieu Bouchard" matju@artengine.ca À: "Patrice Colet" colet.patrice@free.fr Cc: "pd-list" pd-list@iem.at Envoyé: Vendredi 10 Février 2012 06:28:44 Objet: Re: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedback appreciated

Le 2012-02-10 à 05:18:00, Patrice Colet a écrit :

...

s_inter.c:83:22: fatal error: execinfo.h: No such file or directory

<execinfo.h> used to be GNU-only, but now Apple supports it on OSX and iPhone. It is not available on Android (Linux but non-GNU) and it's not available on Windows.

...

s_audio.c:18:26: fatal error: sys/resource.h: No such file or directory

This is for the setrlimit (ulimit) and priority features.

...

x_misc.c:23:23: fatal error: sys/times.h: No such file or directory

That available on all platforms except Windows. It's used by Pd's [cputime] class.

...

x_list.c:15:20: fatal error: alloca.h: No such file or directory

Headers are split differently. On Linux, alloca() is in a header separate from malloc(), but on Windows, both are in <malloc.h>.

It looks like you don't have #define MSW. It won't solve all problems, but it will solve those common to pd-vanilla.

Colet Patrice

On Feb 12, 2012, at 12:43 AM, Mathieu Bouchard wrote:

Le 2012-02-12 à 06:06:00, Patrice Colet a écrit :

...

Thanks a lot! Ivica, what about using this for backtrace? http://code.google.com/p/backtrace-mingw/

Does anyone have such a thing for Android ?

I found something similar, except it doesn't work inside a signal handler, so, unlike any other Linux OS, I can't get backtrace() to give me the stack of a segfault.

That's probably because backtrace() is not Linux but GNU, and Android is Linux but not GNU. It uses its own "Bionic" libc, for example. I'll bet backtrace() works fine on Debian GNU/kFreeBSD, which is also not Linux but is GNU. So those who think "GNU/Linux" is just marketing aren't paying attention to the details :)

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

.hc

I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque

On Feb 12, 2012, at 11:09 AM, Mathieu Bouchard wrote:

Le 2012-02-12 à 10:41:00, Hans-Christoph Steiner a écrit :

...

On Feb 12, 2012, at 12:43 AM, Mathieu Bouchard wrote:

...

Does anyone have such a thing for Android ? I found something similar, except it doesn't work inside a signal handler, so, unlike any other Linux OS, I can't get backtrace() to give me the stack of a segfault.

That's probably because backtrace() is not Linux but GNU, and Android is Linux but not GNU. It uses its own "Bionic" libc, for example.

Yeah, I already know that part. The question is more about how to do it on Android. The native functions can't seem to go through the signal boundary, so they give a backtrace of 4 functions in my Android app when the app crashed inside of 50 nested functions, for example. The 4th stack frame looks like it's the end of the stack, and I need a way to access the 5th stack frame from there, and then I'd be able to access the 49 other frames. But it seems that even if I had a magical way of finding where the 5th frame is, Android's function would not allow me to tell it where to go.

Its not the same thing, but the 'log' library allows you to log all kinds of messages to the logcat, which you can watch live in the DDMS view in Eclipse.

.hc

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

Thanks a lot!

Ivica, what about using this for backtrace?

http://code.google.com/p/backtrace-mingw/

It is not necessary. It is a matter of making sure you use proper build system. The current code should build just fine on Windows (although I never tried it) as its build system is based on Pd-extended which also builds for Windows. The problem does not lie therefore in backtracing but rather revamping pd.tk to circumvent fixes and improvements that do not take into account OSs other than Linux. Some work has been already done with this in the early days when I was working on having these improvements submitted upstream. Also, understand that while pd.tk is on paper one version behind latest 0.43 tcl implementation, it also has plenty of improvements that do not exist in 0.43, so in some respects is ahead of curve (but is also behind in terms of code-cleanliness). At some point those may have to be reconciled (likely once 0.43 branch is rock solid tcl-wise (which may be already the case), I find enough time to do this, and a reason to do it).

Hope this helps!

Best wishes,

Ico

-----Original Message----- From: Mathieu Bouchard [mailto:matju@artengine.ca] Sent: Sunday, February 12, 2012 12:27 PM To: Ivica Ico Bukvic Cc: 'Patrice Colet'; 'pd-list' Subject: RE: [PD] Fwd: [PD-dev] New snapshot of pd-l2ork available -- feedback appreciated

Le 2012-02-12 à 12:22:00, Ivica Ico Bukvic a écrit :

...

(but is also behind in terms of code-cleanliness).

Do you mean something else than sprinkling colon-colon namespacing all over the source and splitting it over N files ?

Not really. But there are also some foundational changes how some of those basic functions operate. Otherwise, porting everything to the new version would be a breeze.

Colet Patrice

----- Mail original -----

De: "Ivica Ico Bukvic" ico@vt.edu À: "Patrice Colet" colet.patrice@free.fr, "pd-list" pd-list@iem.at Cc: "Mathieu Bouchard" matju@artengine.ca

It is not necessary. It is a matter of making sure you use proper build system. The current code should build just fine on Windows (although I never tried it) as its build system is based on Pd-extended which also builds for Windows. The problem does not lie

No it's not possible that those sources compiles on windows, because some includes needs to be surrounded by #ifndef MSW #endif, some libraries doesn't exist at all on windows, whatever the build system we use. I'll give a try when I got time to modify sources and see what happen...

therefore in backtracing but rather revamping pd.tk to circumvent fixes and improvements that do not take into account OSs other than Linux. Some work has been already done with this in the early days when I was working on having these improvements submitted upstream. Also, understand that while pd.tk is on paper one version behind latest 0.43 tcl implementation, it also has plenty of improvements that do not exist in 0.43, so in some respects is ahead of curve (but is also behind in terms of code-cleanliness). At some point those may have to be reconciled (likely once 0.43 branch is rock solid tcl-wise (which may be already the case), I find enough time to do this, and a reason to do it).

I'm particulary interested into using pd-l2ork for some projects where I need to compute data with an higher precision than 32bit floats, for some reasons this is happening on win64, not on linux, because of hardware compatibility problems.

Hope this helps!

Best wishes,

Ico

De: "IOhannes m zmoelnig" zmoelnig@iem.at À: pd-list@iem.at Envoyé: Lundi 13 Février 2012 18:50:17

On 2012-02-13 18:09, Patrice Colet wrote:

...

I'm particulary interested into using pd-l2ork for some projects where I need to compute data with an higher precision than 32bit floats, for some reasons this is happening on win64, not on linux, because of hardware compatibility problems.

is pd-l2ork using double as internal number representation? i thought that was only katja's fixes to some 0.43(vanilla) branch.

oupse I've confused both versions, sorry for that, a thousands excuses :")

Patrice Colet.

Le 2012-02-13 à 20:27:00, Patrice Colet a écrit :

oupse I've confused both versions, sorry for that, a thousands excuses :")

Je pense pas que ça veuille dire ce que tu penses que ça veut dire.

http://en.wiktionary.org/wiki/excuse#Noun

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC