Re: [PD-dev] sys_externlist declared in two places
On Sun, 17 Dec 2006, Miller Puckette wrote: 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 :) It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec. (ok, I'm not 100% sure on that) _ _ __ ___ _ _ _ ... | 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
of course the only real way to vote for this would be write the code - i think i'll wait for PNPD instead.. :) pnpd is currently supporting both hashed symbols and full-featured string ;) however, there are no objects for handling strings, yet t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Sun, 17 Dec 2006, Martin Peach wrote: but in the long term it would be best to just use long lengths for when we all have teraflop laptops: People have been using strings bigger than 64k for many years in almost any other language. It doesn't have anything to do with the teraflops, really. _ _ __ ___ _ _ _ ... | 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
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 17, 2006, at 1:36 AM, Mathieu Bouchard wrote: 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. If that's the case then pd is a really bad idea. It's not possible to typecast any value of a type to any value of another type, all of the time. That's even true in the most typecast-frenzy languages ever. There's no such requirement that implicit casts have to be impossibly well supported in order to be a good idea. You're just dismissing all forms of implicit casts as being bad ideas. Pd is strongly typed, so what Martin says is definitely appropriate. Non-sequitur, there are languages that have quite strict and elaborate type checking and yet which support implicit casts. For example, C++. And then, in many cases, languages can become less strictly checked without any problems, as long as nothing actually relies on type violations. Because pd doesn't have any error handling (in the sense of pd patches being able to figure out their own problems), if any patch doesn't spit out any error messages, it would run the same if there were more implicit casts made, because the patches would never trigger those implicit casts anyway. Perl is the opposite, everything can be automatically cast, so there it makes sense. No, in Perl there's no way that you can cast something to a pointer. You can use the backslash operator to make a pointer to anything, but that's not a cast-to-pointer, because if you use it on a pointer, you don't get the same pointer, you get a new pointer. So... anyone want to code up some of these ideas? We could try them out in the next Pd-extended. Martin's solution, my solution, or your solution? _ _ __ ___ _ _ _ ... | 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
On Dec 18, 2006, at 1:23 AM, carmen wrote: 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.. There are set rules which defined what is a float, symbol, or pointer. You cannot change that type, often even with a special method. Ever tried to turn a float into a symbol? Doesn't really work, only partially. .hc , 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 Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
On Mon, 18 Dec 2006, [EMAIL PROTECTED] wrote: Mathieu Bouchard [EMAIL PROTECTED] wrote: I have no clue what you're talking about: how mangled would they be? i don't plan any mangling to happen, except for the presence of \0 characters. Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance? Do you realise that the quoting problem can be solved independently of the allocation problem? In that case, you would be able to save any symbol and read it back. This would solve the problem about CR LF and spaces; only the problem with \0 (NUL) would remain. Do you also realise that symbols can be made to support NUL while being backwards-compatible? Then what happens when a non-NUL-supporting external tries to read a symbol that contains a NUL, it will appear truncated at that point and that's all. So basically there are three problems that can be dealt with independently. I'd rather not suppose that all three have to come together, monolithically. For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom. Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that. I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed. Ok, that's certainly the string feature that I want. It's too much trouble for the benefit. Whatever. Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings. Man, that's not n atom type. No it's not n atoms, It's a typo. It was supposed to be that's not an atom type, but that isn't so more true. I would've like to say something more like: it would be easier, if strings are more similar to symbols and floats, than to (g)pointers. Symbols are difficult to work with because their content gets interpreted, You say that in answer to my questions on allocation? (That's not an allocation issue and not even any kind of memory layout issue.) I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired. It was just below two paragraphs that I had written about allocation. for example if I write a comment MP 20061214 it gets converted into MP 2.00612e+007 the contents of a comment box is not a symbol. It's a list of atoms. However, Pd has the same problem you describe when trying to save some I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols... That some of the components are symbols, has nothing to do with the reason 20061214 gets converted to float32. There is never a big symbol containing all of the contents of a comment: it's broken down into atoms (into a t_binbuf) as soon as you click outside of the box, it's just the t_rtext that keeps holding the original string; but the t_savefn only saves the t_binbuf, it doesn't look at the t_rtext, which is why the floats get mangled at save time only. _ _ __ ___ _ _ _ ... | 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: Re: [PD-dev] strings
On Mon, 18 Dec 2006, [EMAIL PROTECTED] wrote: If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names? Do it the way most languages have borrowed from C : use backslash followed by an octal or hex code, like \033 or \0x1b. It's easy to make it compatible with C/C++/Java/Perl/Python/Tcl/Ruby/PHP, all at the same time. Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that. You still have the problem of the symbol table that grows by one each time the symbol changes. Well, you can solve that problem separately. There's no point to clump all issues into one ball. Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings. A string library could have functions similar to getbytes(), resizebytes() and freebytes() Yes, that's putting the burden of memory management on the emitter. I mean, what I call the burden of memory management isn't about writing your own malloc() from scratch, no, I'm not talking about that, I'm talking about having to decide when to copy and when to deallocate. _ _ __ ___ _ _ _ ... | 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] sys_externlist declared in two places
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 18, 2006, at 8:09 AM, Mathieu Bouchard wrote: It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec. I think that -fstrict-aliasing disallows that. Or at least something that is enabled when turning on all the optimization options. I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step. _ _ __ ___ _ _ _ ... | 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: Re: [PD-dev] strings
Mathieu Bouchard [EMAIL PROTECTED] wrote: Do you realise that the quoting problem can be solved independently of the allocation problem? In that case, you would be able to save any symbol and read it back. This would solve the problem about CR LF and spaces; only the problem with \0 (NUL) would remain. If ascii values from 0 - 31 can be part of symbols that would be nice. How do you specify a symbol containing ascii values 1 2 and 3? Do they have names? Symbols could be usable, if the problems that can be fixed in symbol without changing the nature of symbols, are fixed. You don't need strings for that. You still have the problem of the symbol table that grows by one each time the symbol changes. If I want to parse a book one word at a time, for example, it would only take one string for the input buffer, but it would take as many symbols as there are different words in the book. Wouldn't you want objects to be able to emit strings in a way as carefree as they are with symbols? I'm talking about not putting the burden of memory management on the emitter of strings. A string library could have functions similar to getbytes(), resizebytes() and freebytes() for changing the length of strings that could be called by any other external in the library. Or pd could have the same functions that could be called by any external. Either way... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Hans-Christoph Steiner [EMAIL PROTECTED] Date: 2006/12/18 lun. AM 09:45:26 GMT-05:00 À: carmen [EMAIL PROTECTED] Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings On Dec 18, 2006, at 1:23 AM, carmen wrote: 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.. There are set rules which defined what is a float, symbol, or pointer. You cannot change that type, often even with a special method. Ever tried to turn a float into a symbol? Doesn't really work, only partially. Along the lines of pd_defaultlist() in m_class.c, which handles list messages for objects that don't have list methods, one could add a pd_defaultstring(), which attempts to convert strings into symbols/floats/lists, instead of calling pd_defaultanything(), which would print no method for string. But it needs to be understood that it might not do it correctly, which is Not A Good Thing, but no worse than comments getting mangled. Maybe a [string unpack] object would be better: it could attempt to unpack a string into specified types, so the user could decide if a string like 123 is meant to represent a float or a symbol. Martin .hc , 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 Mistrust authority - promote decentralization. - the hacker ethic ___ 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] sys_externlist declared in two places
On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote: On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 18, 2006, at 8:09 AM, Mathieu Bouchard wrote: It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec. I think that -fstrict-aliasing disallows that. Or at least something that is enabled when turning on all the optimization options. I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step. FWIW, using these flags, the linker complains: -ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC -mcpu=7450 - mtune=7450 .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: Re: [PD-dev] strings
De: Mathieu Bouchard [EMAIL PROTECTED] Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00 À: Martin Peach [EMAIL PROTECTED] Cc: pd-dev@iem.at Objet: Re: [PD-dev] strings On Sun, 17 Dec 2006, Martin Peach wrote: 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. I have no clue what you're talking about: how mangled would they be? i don't plan any mangling to happen, except for the presence of \0 characters. Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance? 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. They take the space it takes to tell their size and the pointer to the buffer. That's significant, and nearly as much as in the case of a t_symbol, supposing that those t_strings can live independently of the objects that produce them. Like any other object strings have that overhead, but unlike lists they only have one atom per string. They would be created by string objects and last as long as the string objects. One string per string object. String messages are passed between string manipulator objects. For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom. I'm suggesting that a [string] be like any other object and be deallocated when the patcher is closed. Ok, that's certainly the string feature that I want. It's too much trouble for the benefit. Whatever. Man, that's not n atom type. No it's not n atoms, it's a single atom that contains a pointer to a list of bytes. That's the main advantage of string over list. Symbols are difficult to work with because their content gets interpreted, You say that in answer to my questions on allocation? (That's not an allocation issue and not even any kind of memory layout issue.) I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired. for example if I write a comment MP 20061214 it gets converted into MP 2.00612e+007 the contents of a comment box is not a symbol. It's a list of atoms. However, Pd has the same problem you describe when trying to save some symbols. e.g. say you have a symbol with a space in it and you pass it to a messagebox set $1 which passes it to an empty messagebox, and then you save the patch: then you have that problem with symbols. But the contents of the comment box has that problem while never storing its contents as a symbol. I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sys_externlist declared in two places
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote: I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step. FWIW, using these flags, the linker complains: -ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC -mcpu=7450 -mtune=7450 neither -fast nor the 7450 cpu are supported in the GCC I have, an Ubuntu i386 that comes with GCC 4.0.3. With the rest of the options, it doesn't complain. But then, if you're on OSX... OSX doesn't use ELF. It can very well be not the same as Linux in that situation. _ _ __ ___ _ _ _ ... | 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
On Dec 18, 2006, at 12:42 PM, Mathieu Bouchard wrote: On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 17, 2006, at 1:36 AM, Mathieu Bouchard wrote: 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. If that's the case then pd is a really bad idea. It's not possible to typecast any value of a type to any value of another type, all of the time. That's even true in the most typecast-frenzy languages ever. There's no such requirement that implicit casts have to be impossibly well supported in order to be a good idea. You're just dismissing all forms of implicit casts as being bad ideas. Pd is strongly typed, so what Martin says is definitely appropriate. Non-sequitur, there are languages that have quite strict and elaborate type checking and yet which support implicit casts. For example, C++. And then, in many cases, languages can become less strictly checked without any problems, as long as nothing actually relies on type violations. Because pd doesn't have any error handling (in the sense of pd patches being able to figure out their own problems), if any patch doesn't spit out any error messages, it would run the same if there were more implicit casts made, because the patches would never trigger those implicit casts anyway. C/C++ is not very strict. It allows you to just change what you call a chunk of memory without complaint. Try Pascal, that is strict. Or Pd's floats and symbols. There is no way to make a float into symbol or vice versa without trickery. For example, these doesn't work: [123([symbol 123( [symbol 123( | | | [symbol] [ \ -- (symbol box) [float] .hc Perl is the opposite, everything can be automatically cast, so there it makes sense. No, in Perl there's no way that you can cast something to a pointer. You can use the backslash operator to make a pointer to anything, but that's not a cast-to-pointer, because if you use it on a pointer, you don't get the same pointer, you get a new pointer. So... anyone want to code up some of these ideas? We could try them out in the next Pd-extended. Martin's solution, my solution, or your solution? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada 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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Dec 18, 2006, at 12:42 PM, Mathieu Bouchard wrote: On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 17, 2006, at 1:36 AM, Mathieu Bouchard wrote: 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. If that's the case then pd is a really bad idea. It's not possible to typecast any value of a type to any value of another type, all of the time. That's even true in the most typecast-frenzy languages ever. There's no such requirement that implicit casts have to be impossibly well supported in order to be a good idea. You're just dismissing all forms of implicit casts as being bad ideas. Pd is strongly typed, so what Martin says is definitely appropriate. Non-sequitur, there are languages that have quite strict and elaborate type checking and yet which support implicit casts. For example, C++. And then, in many cases, languages can become less strictly checked without any problems, as long as nothing actually relies on type violations. Because pd doesn't have any error handling (in the sense of pd patches being able to figure out their own problems), if any patch doesn't spit out any error messages, it would run the same if there were more implicit casts made, because the patches would never trigger those implicit casts anyway. C/C++ is not very strict. It allows you to just change what you call a chunk of memory without complaint. Try Pascal, that is strict. Or Pd's floats and symbols. There is no way to make a float into symbol or vice versa without trickery. For example, these doesn't work: [123([symbol 123( [symbol 123( | | | [symbol] [ \ -- (symbol box) [float] .hc Perl is the opposite, everything can be automatically cast, so there it makes sense. No, in Perl there's no way that you can cast something to a pointer. You can use the backslash operator to make a pointer to anything, but that's not a cast-to-pointer, because if you use it on a pointer, you don't get the same pointer, you get a new pointer. So... anyone want to code up some of these ideas? We could try them out in the next Pd-extended. Martin's solution, my solution, or your solution? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada 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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sys_externlist declared in two places
On Dec 18, 2006, at 6:43 PM, Mathieu Bouchard wrote: On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote: I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step. FWIW, using these flags, the linker complains: -ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC - mcpu=7450 -mtune=7450 neither -fast nor the 7450 cpu are supported in the GCC I have, an Ubuntu i386 that comes with GCC 4.0.3. With the rest of the options, it doesn't complain. But then, if you're on OSX... OSX doesn't use ELF. It can very well be not the same as Linux in that situation. -fast is a shortcut for: -O3 -falign-loops-max-skip=15 -falign-jumps-max-skip=15 -falign-loops=16 -falign-jumps=16 -falign-functions=16 - malign-nat- ural (except when -fastf is specified) -ffast-math - funroll-loops -ftree-loop-linear -ftree-loop-memset -mcpu=G5 -mpowerpc- gpopt -mtune=G5 (unless -mtune=G4 is specified). -fsched- interblock -fgcse-sm -mpowerpc64 .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada 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] strings
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote: On Dec 18, 2006, at 12:42 PM, Mathieu Bouchard wrote: Non-sequitur, there are languages that have quite strict and elaborate type checking and yet which support implicit casts. For example, C++. C/C++ is not very strict. It allows you to just change what you call a chunk of memory without complaint. Ok, I spoke too quick. I didn't want to say strict. I shouldn't have said strict. Instead of strict I wanted to say that the type checking happens all of the time. I thought up some kind of classification of type systems, avoiding to call them strong/weak or static/dynamic because those words are confusing. 1. Typed expressions: each piece of code that can give a value, has a type that can be figured out at compile-time. 2. Typed variables/parameters: declarations allow runtime checks but not compile-time checks. 3. Typed values: variables don't have types, they can contain any value, but every value has a type. 4. Typed uses: values don't have types, a type is a way of using a value. Strictness, in the sense of forbidding things to the user, is not on that scale, it's another aspect. A well-balanced strictness allows one to bypass the system whenever needed, but without being too error-prone. However it's difficult to say what it means to bypass the system for all four typing categories at once, or even within one category. _ _ __ ___ _ _ _ ... | 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, 3 Dec 2006, Thomas Grill wrote: Hi Miller, clearly for a new devel branch, MAIN would be the right to start from. The diff -u between pd 0.39-2 and 0.40-2 is 272k. The diff -u between pd 0.39-2 and devel_0_39 is 600k. Without the -u, the ratio between diff sizes becomes slightly steeper. I merged 80% of the 0.39-2 0.40-2 diff into DesireData in one night (just after pre4). The rest of 0.40 will be coming before pre6. _ _ __ ___ _ _ _ ... | 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
[PD-dev] [ pure-data-Bugs-1607921 ] IntelMac Autobuild, Don't start: Segmentation fault
Bugs item #1607921, was opened at 2006-12-03 11:43 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1607921group_id=55736 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: pd-extended Group: v0.39.2 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: stffn (stffn) Assigned to: Hans-Christoph Steiner (eighthave) Summary: IntelMac Autobuild, Don't start: Segmentation fault Initial Comment: The autobuilds of Pd-extended 0.39.2 for intel mac from 30th of Nov. to 3rd of Dec all dont start but return Segmentation fault (on Macbook). This might make the tracker item #1595768 obsolete, since a new error ocurs. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-19 00:13 Message: Logged In: YES user_id=27104 Originator: NO Looks like its all fixed. It was a combination of first, the Tcl/Tk stuff not being properly assembled into the .app wrapper, then bugs in the Apple-supplied Tcl/Tk Frameworks. Using 8.4.15-pre from CVS seems to have fixed everything. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-05 19:27 Message: Logged In: YES user_id=27104 Originator: NO I think I fixed this bug, please check the autobuilds for tomorrow 2006-12-06. -- Comment By: stffn (stffn) Date: 2006-12-04 04:41 Message: Logged In: YES user_id=1658640 Originator: YES I'd like to provide more info. But I don't know what you mean by 'crash dump'. I tested them by running ./path/to/Contents/MacOS/pd-date-info from the terminal which just returned Segmentation fault. gdb was no help, sine there were no porcess to attach - i think thats the reason, it didn't give any usefull output anyways. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-03 20:47 Message: Logged In: YES user_id=27104 Originator: NO Can you give more info? Like a crash dump? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1607921group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1602617 ] some small issues in doc/3.audio.examples/
Bugs item #1602617, was opened at 2006-11-25 01:56 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1602617group_id=55736 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: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Miller Puckette (millerpuckette) Summary: some small issues in doc/3.audio.examples/ Initial Comment: Tested with pd-0.40-2 from Miller's site. D10.sampler.notes.pd error: ($4: argument number out of range error: tabread4~: sample0: no such array error: tabwrite~: sample: no such array E07.evenodd.pd error: array1: no such object error: array1: no such object error: array1: no such object E10.complex.FM.pd error: tabwrite~: E10-signal: no such array H04.filter.sweep.pd error: tabread4~: mtof: no such array H05.filter.floyd.pd error: 1280-metro: no such object H15.phaser.pd error: 1337-pole: no such object I07.phase.vocoder.pd error: detune: no such object J01.even.odd.pd pd: unknown message DSP 1 -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-19 00:33 Message: Logged In: YES user_id=27104 Originator: NO fixed in Pd-0.39.2-extended-test7 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1602617group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1601850 ] [vcf_filter~] does not instantiate without arguments
Bugs item #1601850, was opened at 2006-11-23 11:17 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1601850group_id=55736 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: externals Group: v0.39.2 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: musil (tmusil) Summary: [vcf_filter~] does not instantiate without arguments Initial Comment: Running Pd-0.39.2-extended-2006-11-23 on Mac OS X 10.4, when I instantiate [vcf_filter~] without any arguments, it crashes Pd. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-19 00:37 Message: Logged In: YES user_id=27104 Originator: YES changed to reflect the updated situation -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-11-29 20:55 Message: Logged In: YES user_id=27104 Originator: YES any chance of fixing it by setting a default value instead? Or maybe have it instatiate but do nothing without an argument. I think it can be quite confusing and annoying if you need an argument to instantiate. For example, I often create an object to open the hlep patch. That wouldn't work here. -- Comment By: IOhannes m zm�lnig (zmoelnig) Date: 2006-11-29 13:40 Message: Logged In: YES user_id=564396 Originator: NO i have fixed this in CVS by replacing A_DEFSYM by A_SYMBOL in vcf_filter~:323 this makes [vcf_filter~] refuse to create when no argument is given instead of crashing pd -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1601850group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1595768 ] IntelMac Autobuild don't start due to not matching arch
Bugs item #1595768, was opened at 2006-11-13 12:37
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1595768group_id=55736
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: pd-extended
Group: v0.39.2
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: IntelMac Autobuild don't start due to not matching arch
Initial Comment:
The IntelMac auto build from the 12th of nov '06 didn't
start, proberly due to the fact that the arch is
PowerPC and not i386:
file
Pd-0.39.2-extended-2006-11-12.app/Contents/MacOS/Pd-0.39.2-extended-2006-11-12
Pd-0.39.2-extended-2006-11-12.app/Contents/MacOS/Pd-0.39.2-extended-2006-11-12:
Mach-O executable ppc
When run it gives this error:
./Pd-0.39.2-extended-2006-11-12.app/Contents/MacOS/Pd-0.39.2-extended-2006-11-12
Error in startup script: no suitable image found. Did
find:
/path/to/app/Pd-0.39.2-extended-2006-11-12.app/Contents/Resources/bin/libPdTcl.dylib:
mach-o, but wrong architecture
while executing
load $pd_guidir/bin/libPdTcl.dylib
invoked from within
if {$pd_nt == 2} {
# turn on James Tittle II's fast drawing
set tk::mac::useCGDrawing 1
# set minimum line size for anti-aliasing. If set
to ...
(file
/path/to/app/Pd-0.39.2-extended-2006-11-12.app/Contents/Resources/Scripts/AppMain.tcl
line 44)
--
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-12-19 00:38
Message:
Logged In: YES
user_id=27104
Originator: NO
works now
--
Comment By: Nobody/Anonymous (nobody)
Date: 2006-11-27 10:35
Message:
Logged In: NO
The same error occurs while running the build from the 21 of november.
These are the only intel mac builds in the build farm.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1595768group_id=55736
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1427520 ] Link broken in Help patch for netsend
Bugs item #1427520, was opened at 2006-02-08 08:34 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1427520group_id=55736 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: abstractions Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piotr Majdak (piotrmajdak) Assigned to: Miller Puckette (millerpuckette) Summary: Link broken in Help patch for netsend Initial Comment: In netsend-help.pd is a link given, which seems to be broken: ftp://fals.ch/pub/pdnets -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-19 00:43 Message: Logged In: YES user_id=27104 Originator: NO fixed in Pd-0.39.2-extended-test6 -- Comment By: IOhannes m zm�lnig (zmoelnig) Date: 2006-10-10 09:21 Message: Logged In: YES user_id=564396 for intercommunication with max, i suggest to use OSC. nevertheless, the link is really broken (fals.ch does not exist anymore), and should therefore be removed from the help-patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=1427520group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1618554 ] remove extra sys_externlist from s_main.c
Patches item #1618554, was opened at 2006-12-19 01:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1618554group_id=55736 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: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: remove extra sys_externlist from s_main.c Initial Comment: Apparently this never mattered before, but turning on the full compiler optimization flags causes the linker to complain about this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1618554group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
