Pd-dev June 2015

pd-dev@lists.iem.at

23 participants
23 discussions

[pure-data:bugs] #1202 expr mega bug report (concentrating all issues here)
by Alexandre Porres 10 Jun '15

10 Jun '15

--- ** [bugs:#1202] expr mega bug report (concentrating all issues here)** **Status:** open **Group:** v0.46 **Labels:** expr **Created:** Tue Jun 09, 2015 10:03 PM UTC by Alexandre Porres **Last Updated:** Tue Jun 09, 2015 10:03 PM UTC **Owner:** Miller Puckette This report concentrates all the open bug reports I found over here regarding the expr family of objects. I've also raised many issues myself in the Pd list and discussed it with Shahrokh, but the developers convinced me I should also open a report. Here are the other reports that partially relate to this one (but let me emphasize that I'm raising even more issues) they should be closed if this mega report is completely dealt with. https://sourceforge.net/p/pure-data/bugs/1136/ https://sourceforge.net/p/pure-data/bugs/598/ https://sourceforge.net/p/pure-data/bugs/543/ https://sourceforge.net/p/pure-data/bugs/425/ https://sourceforge.net/p/pure-data/bugs/497/ https://sourceforge.net/p/pure-data/bugs/360/ https://sourceforge.net/p/pure-data/bugs/352/ https://sourceforge.net/p/pure-data/bugs/53/ Anyway, my report is described in the attached patch. It opens in Vanilla 0.46, but mentions issues specific to 0.42 extended, where it may crash. cheers Alex --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Re: [PD-dev] Compiling objects with gnu++14
by Robert Esler 03 Jun '15

03 Jun '15

Hi Arshia, I’ve built numerous C++ Pd objects and have found at times C++ doesn’t seem to work well with C when it comes to binary runtime. I learned that here: http://stackoverflow.com/questions/5397447/struct-padding-in-c Though I haven’t encountered what Miller is saying that all struct elements are 64-bit aligned, did he mean pointers? Because that is certainly the case. I don’t fully comprehend the scope of your code, essentially what is the need for a 4 byte offset? And why does this statement need to be true: (boundmsg->a_w.w_symbol->s_name == atom_getsymbol(boundmsg)->s_name) ? Or maybe I’m completely misinterpreting your issue? For the former, can you eliminate the issue by checking for offset size, like: #include <stddef.h> #include <iostream> struct D { double *d; }; struct T { int *i; short *j; D *k; }; int main() { int a = offsetof(T, i); int b = offsetof(T, j); int c = offsetof(T, k); if(b - a == 8 && c - b == 8) std::cout << "8 offset" << std::endl; // do something here else if (b - a == 4 && c - b == 4) std::cout << "4 offset" << std::endl; // do something else here } Best, Rob Esler ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 Jun 2015 11:29:42 +0200 From: Arshia Cont <Arshia.Cont(a)ircam.fr> To: Antoine Rousseau <ant1rousseau1(a)gmail.com> Cc: pd-dev <pd-dev(a)lists.iem.at> Subject: Re: [PD-dev] Compiling objects with gnu++14 Message-ID: <30D6E725-3B91-4A4E-B5B7-F22714396B02(a)ircam.fr> Content-Type: text/plain; charset="utf-8" Antoine, Ignore details of my short code… the t_atom is actually correctly allocated.. What happens is that when boundmsg is accessed outside this score (using atom_getsymbol) the address of its struct members are NOT the same (we have verified this in different ways). Miller suggested that “It looks like C++11 has decided that structure elements should all be 64-bit aligned. This would mean that you simply can’t link C++11 and Gnu C code together” You could check it by printing out the pointers, boundmsg->a_type boundmsg->a_w.w_symbol These differ by 4 in Pd - if your compiler wants them to differ by 8, the two aren’t compatible. I can’t seem to find a compiler flag in clang that globally sets the alignment!!! I can do that locally for each struct but this will make the object non-distributable… . > On 03 Jun 2015, at 10:33, Antoine Rousseau <ant1rousseau1(a)gmail.com> wrote: > > Maybe I don't understand well, but your short code example is incorrect : > > t_atom *boundmsg; > boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss; > > because you are assigning fields of a not allocated structure : boundmsg here is just the undefined address of a potential storage. > > This should work : > > t_atom boundmsg; > boundmsg.a_type = A_SYMBOL; boundmsg.a_w.w_symbol = ss; > > > Or : > > t_atom *boundmsg = getbytes(sizeof(t_atom)); > boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss; > > > Hope this helps, sorry if I'm off topic. > > 2015-06-03 10:00 GMT+02:00 Arshia Cont <Arshia.Cont(a)ircam.fr <mailto:Arshia.Cont@ircam.fr>>: > Thomas, > > My clang version is > Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) > Target: x86_64-apple-darwin14.3.0 > Thread model: posix > > > Before I give you the compilation flags, here is what it comes down to.. basically, the following code gives indeterministic behaviour due to memory misalignment when the atom pointer is passed to : > > t_atom *boundmsg; // etc. > boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss; > > assert(boundmsg->a_w.w_symbol->s_name == atom_getsymbol(boundmsg)->s_name); // imagine that my assert works on char*! simplifying here > > > Here is an example of the compilation, following Katja’s blog on soundtouch~. I am using i386 on purpose here for testing.You can ignore capital letter flags that come from us: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu++1y -stdlib=libc++ -Wno-trigraphs -fshort-enums -Os -Wno-missing-field-initializers -Wmissing-prototypes -Wno-return-type -Wunreachable-code -Wnon-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wmissing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wempty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wassign-enum -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DNDEBUG=1 -DDEPLOYMENT_VERSION=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.7 -g -fvisibility-inlines-hidden -Wno-sign-conversion -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/antescofo~.hmap -I/Users/acont/Devs/MyFlextProjects/antescofo/build/Deployment/include -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/DerivedSources/i386 -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/DerivedSources -Wmost -Wno-unknown-pragmas -Wno-four-char-constants -F/Users/acont/Devs/MyFlextProjects/antescofo/build/Deployment -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks -DNDEBUG=1 -DARCHI_MAC_OS=4 -DARCHI_LINUX=5 -DARCHI_WINDOWS=6 -DANTESCOFO_ARCHI=ARCHI_MAC_OS -DTARGET_PD=2 -DTARGET_STANDALONE_FILE=3 -DTARGET_MAXSDK=4 -DTARGET_ASCOGRAPH=7 -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/oscpack_1_1_0_RC2/ip -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/oscpack_1_1_0_RC2/osc -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -DANTESCOFO_TARGET=TARGET_PD -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/pd-0.46-6/src -fvisibility=hidden -fcheck-new -MMD -MT dependencies -MF /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.d --serialize-diagnostics /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.dia -c /Users/acont/Devs/MyFlextProjects/antescofo/sources/Antescofo_PdClass.cpp -o /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.o > > Arshia Cont > > > > >> On 02 Jun 2015, at 21:43, Thomas Grill <gr(a)grrrr.org <mailto:gr@grrrr.org>> wrote: >> >> Hi Arshia, >> which compiler is it exactly that you use? Can you copy the options? >> best, Thomas >> >> 2015-06-02 14:35 GMT+02:00 Arshia Cont <Arshia.Cont(a)ircam.fr <mailto:Arshia.Cont@ircam.fr>>: >> Thank you Katja for the swift response! We will wait for that then. >> >> Any one running into run-time problems when compiling with C++11 or C++14? We seem to have memory alignment issues… . >> >> Arshia Cont >> >> >> >> >>> On 02 Jun 2015, at 14:23, katja <katjavetter(a)gmail.com <mailto:katjavetter@gmail.com>> wrote: >>> >>> On Tue, Jun 2, 2015 at 1:07 PM, Arshia Cont <Arshia.Cont(a)ircam.fr <mailto:Arshia.Cont@ircam.fr>> wrote: >>> >>> [...] >>> >>>> My second question would be on double-precision audio externals.. I see discussions on class_new64 but can’t seem to find any trace of it in 0.46-6.. I dig into the archives to figure this one out first! >>> >>> In 2011 I made a set of patch files for vanilla pd 0.43 to enable >>> double precision builds (where t_float and t_sample are doubles). That >>> can be found here: >>> >>> https://github.com/pd-projects/pd-double <https://github.com/pd-projects/pd-double> >>> >>> You could try it out for evaluation but Miller wants to scrutinize, >>> test and improve the patch files before accepting them. >>> >>> Katja >>> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> >> http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev> >> >> >> >> -- >> Thomas Grill >> http://grrrr.org <http://grrrr.org/> > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> > http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev> > > > > > -- > Antoine Rousseau > http://www.metalu.net <http://metalu.net/> __ http://www.metaluachahuter.com/<http://www.metaluachahuter.com/compagnies/al1-ant1/> __ http://al1ant1.free.fr <http://al1ant1.free.fr/> > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > http://lists.puredata.info/listinfo/pd-dev

1 0

Compiling objects with gnu++14
by Arshia Cont 03 Jun '15

03 Jun '15

Dear dev-list, I believe this is my first post to this list so excuse my ignorance if any of this looks obvious to you! We have recently moved to C++11 for compilation of several of our Pd objects. And since, we have weird behaviour problems and we suspect it’s due to under-the-hood optimisations… . Has anybody had any experience with this?! My second question would be on double-precision audio externals.. I see discussions on class_new64 but can’t seem to find any trace of it in 0.46-6.. I dig into the archives to figure this one out first! Cheers, Arshia Cont

7 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev June 2015