Re: [PD-dev] moving iemgui from core to extra
On 16/12/2006, at 23.47, Hans-Christoph Steiner wrote: The IEMGUIs were not originally part of the core, they were added later. Would it be of any value/interest to this discussion to bring up the reason why it was added (when it was added)? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On 2006-12-17 03:09:19, Martin Peach [EMAIL PROTECTED] appears to have written: A string could be considered unused when its length is set to 0. Memory would need to be dynamically allocated in small blocks. The API should return no method for string if the external doesn't implement strings. ... which wouldn't get us true strings in the mathematical sense of a free monoid Alphabet,concat(), since the empty string is the identity element for concat()... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Sun, 17 Dec 2006, Bryan Jurish wrote: ... which wouldn't get us true strings in the mathematical sense of a free monoid Alphabet,concat(), since the empty string is the identity element for concat()... Right, and it may seem like not much, but if one is going to make a lot of abstractions for basic string processing, i'd rather have them use monoid algorithms rather than semigroup algorithms. The monoid algorithms are often nicer... semigroup algorithms can't start with an empty string, so they start with the first character of a string, and then do a foreach-loop that starts on the second character so that the first character isn't counted twice, so you have to decide a way to skip that character... ugly. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
On Sun, 17 Dec 2006, Steffen wrote: On 16/12/2006, at 23.47, Hans-Christoph Steiner wrote: The IEMGUIs were not originally part of the core, they were added later. Would it be of any value/interest to this discussion to bring up the reason why it was added (when it was added)? As I understood it, PureData was originally supposed to be much more about Data Structures ([struct], [drawpolygon], etc), without much of anything else around, hence the name PureData. However, those new features didn't evolve as quickly as wished and the need for more MAX compatibility was felt, because the world was in need of a free MAX clone (and JAVA-free as well...). I think that it was a good move for Musil/IEM to introduce those (even if I can't agree with the implementation) because cutting-edge artists aren't quite tired of the MAX paradigm yet. However, I started to use PureData only at 0.34, so I haven't witnessed the introduction of IEMGUI into the core, so, I might not be the best person to tell this story. Maybe Miller, T.Musil or even Mark Danks can provide some background on what was PureData in the 90's. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel branch
On Sun, 17 Dec 2006, Mathieu Bouchard wrote: On Sun, 10 Dec 2006, Mathieu Bouchard wrote: On Sun, 3 Dec 2006, Hans-Christoph Steiner wrote: On Dec 2, 2006, at 5:24 PM, Mathieu Bouchard wrote: Well, compatibility would be a lot easier if we had automated tests like most programming languages have. (That's why I had started a project called PureUnity) How about finishing it and adding it to the nightly builds? Oh, and to answer that specific question, I don't want nightly tests. We need them hourly or minutely or secondly if possible. They will also need a running X-Server. We need the tests to be run before we commit broken code, that's it. Nightly is too late. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Mathieu Bouchard wrote: On Sat, 16 Dec 2006, Martin Peach wrote: What if strings could be automatically cast to symbols for externals that would rather have symbols, and vice-versa? I have written an external asc2sym that takes lists of bytes and splits them into symbols based on the argument(s) which are characters. But it seems important to avoid symbols as much as possible to avoid filling up the symbol table with symbols that are referenced only once.. Yes, but my reason for wanting this, is that all externals currently available understand symbols but not strings. So, what if you want to make strings as widely used as possible, as easily as possible, and working with all externals currently available in Pd? You make them work as strings when they can, and You make them work as symbols when they must. There would be two objects, [stringtosymbol] and [symboltostring] that you could put between string and symbol objects. Of course some strings would get impossibly mangled this way but that's because of the way symbols work. A string could be considered unused when its length is set to 0. If you want to use a string as a mutable buffer, then you want to be able to have 0-length strings, as a boundary condition: you start with nothing and then add to it. You don't want to have to start with something just because setting the length to 0 would delete it. Yes, there's no reason not to have 0-length strings. And no reason to trash them when they are unused either, since they don't take up more space than any other object. It seems that you are suggesting that the deallocation would be user-controlled? Then how do you prevent the user from crashing pd? I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed. It's basically a variable-length list of bytes. It would contain methods to allocated and deallocate memory via malloc() or pd's getbytes(), which uses calloc(). If you use a weak-pointer as an intermediate (like t_gpointer or t_gfxstub), then you still have to manage reference counts. Whatever you do for the user, you have to know more about externals' behaviour than what they tell you now, because right now they don't deallocate atoms explicitly. But if strings are going to be deallocated explicitly and there is not going to be any checks, why not instead make something that will allow users to deallocate symbols. It's about as safe as that and you don't need to introduce a string type. Symbols are difficult to work with because their content gets interpreted, for example if I write a comment MP 20061214 it gets converted into MP 2.00612e+007, or if I want a symbol to have spaces or carriage returns in it, it won't get created, which is very annoying when a lot of serial hardware wants to see a CR before it processes a message. Also every time I change a symbol, it gets added to the global symbol table. So adding one character at a time to a string would result in that many symbols being created. A string as I see it is closer to a list, and could be operated on with objects like the list objects -- append, split, etc. Memory would need to be dynamically allocated in small blocks. What do you mean in small blocks ? Whatever is most efficient. If malloc is better at allocating blocks of 256 bytes than blocks of 1 then it's better to work with multiples of 256. It seems inefficient to allocate 65536 bytes for every string at creation time. The API should return no method for string if the external doesn't implement strings. That's aiming low. Why shouldn't there be any automatic casts between the two? Because it would require rewriting more of the pd core, and because a lot of strings can't be made into symbols (strings can contain any integer on [0...255] but symbols cannot). Having the two converter objects [stringtosymbol] and [symboltostring] is easier. The no method for string message would come from pd, not the external, so the external doesn't need to implement any string methods. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Mathieu Bouchard wrote:
On Sat, 16 Dec 2006, Martin Peach wrote:
Yes, and it's also easier to limit strings to word (16-bit) lengths,
while 8-bit is too short. So a t_string would look like:
typedef struct _string /* pointer to a string */
{
unsigned short s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
If you're not compiling in 16-bit mode, then there will be 2 or 6
bytes between the first and second field, so that the second field can
be aligned to a word boundary, supposing that the struct as a whole is
itself aligned to a word boundary. (By word, I strictly mean something
that is the same size as a pointer.)
What I mean is that it's useless to not use the whole a length field
that is not the same size as the pointer field, if you have only those
two fields. If you have more than two fields, then you can put several
short fields in the space of a word (2 or 4).
I suppose we could do like Apple or Microsoft and have something like:
typedef struct _string /* pointer to a string */
{
unsigned short s_length; /* length of string in bytes */
unsigned short s_reserved; /* filler */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
but in the long term it would be best to just use long lengths for when
we all have teraflop laptops:
typedef struct _string /* pointer to a string */
{
unsigned long s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
...but restrict the maximum string length using a #define
MAX_STRING_LENGTH so that pd doesn't bite off more than it can chew...
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-MAIN: d_osc.c:39:2: error: #error No byte order defined
This message is from building pd-MAIN on Mac OS X 10.4/PowerPC: cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno- parentheses -Wno-switch -DDL_OPEN -DMACOSX -DUNISTD -I/usr/X11R6/ include -I../portaudio/pa_common -I../portaudio/pablio -I../ portmidi/pm_common -I../portmidi/pm_mac -I../portmidi/porttime - DUSEAPI_PORTAUDIO -DPA19 -DPA_USE_COREAUDIO -isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc -Wno-error -O2 - DUSEAPI_JACK -DINSTALL_PREFIX=\\ -c -o ../obj/d_osc.o d_osc.c d_osc.c:39:2: error: #error No byte order defined d_osc.c:39:2: error: #error No byte order defined .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
moin Martin, moin list, On 2006-12-17 21:46:50, Martin Peach [EMAIL PROTECTED] appears to have written: Bryan Jurish wrote: On 2006-12-17 03:09:19, Martin Peach [EMAIL PROTECTED] appears to have written: A string could be considered unused when its length is set to 0. Memory would need to be dynamically allocated in small blocks. The API should return no method for string if the external doesn't implement strings. ... which wouldn't get us true strings in the mathematical sense of a free monoid Alphabet,concat(), since the empty string is the identity element for concat()... Yes, I agree there should be no restriction on empty strings. I also think there is no need to destroy strings except when the patcher is closed, so it's not really an issue. if by destroy you mean de-allocation of the string struct itself (i assume you do; your suggestion looks a lot like a glib GString btw, which is im(ns)ho a good general purpose c string struct), and if a string therefore winds up being just something like a symbol with a volatile value (i.e. doesn't get written to the symbol table), then i agree. what i think we need to avoid with strings (i don't think anyone has suggested otherwise, i'm just stating the obvious) is symbol-style permanent allocation for every string *value*. string variables could/should be handled like any other pd atom: the external which creates them is responsible for (de-)allocation, which would wind up doing what you suggest and freeing any allocated memory when the responsible object is destroyed (provided the object doesn't leak memory, but i think we can assume c programmers are used to keeping track of such things -- ymmv). in fact, this is how [any2string] handles things, in its ugly list-of-floats way... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] sys_externlist declared in two places
Correct me if I am wrote, but shouldn't sys_externlist be only declared in one .c file? Its declared like this in s_stuff.h: (line 24) extern t_namelist *sys_externlist; Then like this is s_path.c: (line 33) t_namelist *sys_externlist; And a duplicate in s_main.c: (line 48) t_namelist *sys_externlist; Both s_path.c and s_main.c include s_stuff.h and they are ultimately linked into the same binary, so that means that they are duplicates. I am surprised that the linker only sometimes complains about this. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] first auto-vector test
I made two builds of Pd-0.39-2-extended-test6 on Mac OSX using gcc 4.0.1, with differing CFLAGS. I used the attached patch to measure the CPU usage, I tried to keep the operating circumstances equal, but this is a rough test. But from this, the results look quite promising: These flags are used in the standard build: -Os -funroll-loops -fomit-frame-pointer -mcpu=powerpc -mtune=7450 - mpowerpc-gfxopt The second is optimized for G4+: -fast -fPIC -mcpu=7450 -mtune=7450 -ftree-vectorize -ftree-vectorizer- verbose=3 | filename | G4+ | powerpc | feedback_delay_network.pd [linear 32 100 105( 91165 [linear 65 10 15(228237 [exponential 64 1000 10( 249280 (fdn~ NOT vectorized; d_soundfile.c, d_ctl.c, m_sched.c vectorized) ramping_up_and_down.pd61 64 doc/3.audio.examples/G90.pitchshift.pd95 97 My guess its the [readsf~] that is so much quicker in the feedback patch. .hc feedback_delay_network.pd Description: Binary data load-meter.pd Description: Binary data ramping_up_and_down.pd Description: Binary data Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Dec 17, 2006, at 1:36 AM, Mathieu Bouchard wrote: On Sat, 16 Dec 2006, Martin Peach wrote: What if strings could be automatically cast to symbols for externals that would rather have symbols, and vice-versa? I have written an external asc2sym that takes lists of bytes and splits them into symbols based on the argument(s) which are characters. But it seems important to avoid symbols as much as possible to avoid filling up the symbol table with symbols that are referenced only once.. Yes, but my reason for wanting this, is that all externals currently available understand symbols but not strings. So, what if you want to make strings as widely used as possible, as easily as possible, and working with all externals currently available in Pd? You make them work as strings when they can, and You make them work as symbols when they must. A string could be considered unused when its length is set to 0. If you want to use a string as a mutable buffer, then you want to be able to have 0-length strings, as a boundary condition: you start with nothing and then add to it. You don't want to have to start with something just because setting the length to 0 would delete it. It seems that you are suggesting that the deallocation would be user-controlled? Then how do you prevent the user from crashing pd? If you use a weak-pointer as an intermediate (like t_gpointer or t_gfxstub), then you still have to manage reference counts. Whatever you do for the user, you have to know more about externals' behaviour than what they tell you now, because right now they don't deallocate atoms explicitly. But if strings are going to be deallocated explicitly and there is not going to be any checks, why not instead make something that will allow users to deallocate symbols. It's about as safe as that and you don't need to introduce a string type. Memory would need to be dynamically allocated in small blocks. What do you mean in small blocks ? The API should return no method for string if the external doesn't implement strings. That's aiming low. Why shouldn't there be any automatic casts between the two? Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed, so what Martin says is definitely appropriate. Perl is the opposite, everything can be automatically cast, so there it makes sense. So... anyone want to code up some of these ideas? We could try them out in the next Pd-extended. .hc There is no way to peace, peace is the way. -A.J. Muste ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sys_externlist declared in two places
It's a mistake... I think the one in s_main.c should go. C code since the 70s (at least) has allowed duplicate definitions of uninitialzed data, but everyone knows it's wrong :) M On Sun, Dec 17, 2006 at 07:39:48PM -0500, Hans-Christoph Steiner wrote: Correct me if I am wrote, but shouldn't sys_externlist be only declared in one .c file? Its declared like this in s_stuff.h: (line 24) extern t_namelist *sys_externlist; Then like this is s_path.c: (line 33) t_namelist *sys_externlist; And a duplicate in s_main.c: (line 48) t_namelist *sys_externlist; Both s_path.c and s_main.c include s_stuff.h and they are ultimately linked into the same binary, so that means that they are duplicates. I am surprised that the linker only sometimes complains about this. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed is it? it mainly has numbers that occasionally look like symbols, and symbols that more than occasionally look like lists and/or strings.. , so what Martin says is definitely appropriate. Perl is the opposite, everything can be automatically cast, so there it makes sense. it is definitely a design decision which way to go. could PD flexibly support both at once? or does there need to be an OCaml edition, and a Perl edition? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed do you think the target user base wants to think in terms of casting types? i don't. i have a feeling that was why there are so few types. i think most users wan't to be able to plug anything into anythign and at least get some sort of result, more than expected bang, got '' scrolling 1000 times a second in stderr... my vote would be a nice selection of types, and autocasting (maybe warnings at most for int vs float, string to symbol, etc) of course the only real way to vote for this would be write the code - i think i'll wait for PNPD instead.. :) ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
