[PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
Hi Mathieu,
i have been following the latst cvs changes and it seems, you are
again beautifying the codebase.
Please identify the parts that you consider that I'm just
beautifying, apart from the files that don't belong to your part of
devel_0_39.
Actually, you should know what you changed. Only from the latest cvs digest:
Message: 6
Date: Tue, 28 Nov 2006 15:36:07 +
From: Mathieu Bouchard [EMAIL PROTECTED]
Subject: [PD-cvs] pd/src x_list.c,1.2.2.7,1.2.2.8
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Update of /cvsroot/pure-data/pd/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19418
Modified Files:
Tag: devel_0_39
x_list.c
Log Message:
removed useless reference to global var newest.
Index: x_list.c
===
RCS file: /cvsroot/pure-data/pd/src/x_list.c,v
retrieving revision 1.2.2.7
retrieving revision 1.2.2.8
diff -C2 -d -r1.2.2.7 -r1.2.2.8
*** x_list.c30 Nov 2005 13:36:58 -1.2.2.7
--- x_list.c28 Nov 2006 15:36:03 -1.2.2.8
***
*** 21,27
#endif
- extern t_pd *newest;
-
-
/* the list object family.
--- 21,24
***
*** 397,419
{
if (!argc || argv[0].a_type != A_SYMBOL)
! newest = list_append_new(s, argc, argv);
else
{
t_symbol *s2 = argv[0].a_w.w_symbol;
! if (s2 == gensym(append))
! newest = list_append_new(s, argc-1, argv+1);
! else if (s2 == gensym(prepend))
! newest = list_prepend_new(s, argc-1, argv+1);
! else if (s2 == gensym(split))
! newest = list_split_new(atom_getfloatarg(1, argc, argv));
! else if (s2 == gensym(trim))
! newest = list_trim_new();
! else
! {
! error(list %s: unknown function, s2-s_name);
! newest = 0;
! }
}
- return (newest);
}
--- 394,408
{
if (!argc || argv[0].a_type != A_SYMBOL)
! return list_append_new(s, argc, argv);
else
{
t_symbol *s2 = argv[0].a_w.w_symbol;
! if (s2 == gensym(append)) return list_append_new(s,
argc-1, argv+1);
! if (s2 == gensym(prepend)) return list_prepend_new(s,
argc-1, argv+1);
! if (s2 == gensym(split)) return
list_split_new(atom_getfloatarg(1, argc, argv));
! if (s2 == gensym(trim))return list_trim_new();
! error(list %s: unknown function, s2-s_name);
! return 0;
}
}
--
Message: 7
Date: Tue, 28 Nov 2006 15:46:11 +
From: Mathieu Bouchard [EMAIL PROTECTED]
Subject: [PD-cvs] pd/src x_connective.c,1.3.4.1.2.8,1.3.4.1.2.9
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Update of /cvsroot/pure-data/pd/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23183
Modified Files:
Tag: devel_0_39
x_connective.c
Log Message:
removed useless access to newest.
Index: x_connective.c
===
RCS file: /cvsroot/pure-data/pd/src/x_connective.c,v
retrieving revision 1.3.4.1.2.8
retrieving revision 1.3.4.1.2.9
diff -C2 -d -r1.3.4.1.2.8 -r1.3.4.1.2.9
*** x_connective.c30 Nov 2005 13:36:58 -1.3.4.1.2.8
--- x_connective.c28 Nov 2006 15:46:09 -1.3.4.1.2.9
***
*** 9,13
#include string.h
#include stdio.h
- extern t_pd *newest;
/* -- int -- */
--- 9,12
***
*** 67,71
outlet_new(x-x_obj, s_float);
floatinlet_new(x-x_obj, x-x_f);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 66,69
***
*** 110,114
outlet_new(x-x_obj, s_symbol);
symbolinlet_new(x-x_obj, x-x_s);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 108,111
***
*** 166,170
t_bang *x = (t_bang *)pd_new(bang_class);
outlet_new(x-x_obj, s_bang);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 163,166
--
Thomas Grill
http://g.org
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
Hallo you 2 ! How about a desire branch? Well, if you don't identify those specific parts that are a problem to you, and instead just quote the whole 200k digest, there's not much helping me to comply with your wishes, so I wouldn't have a choice, really. please - not one more branch !!! LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
While i don't see what that feature might be in these code excerpts, except the elimination of an unneeded variable and reformatting, i normally don't spend my time proof-reading devel_0_39. Anyway, i hope you know what i mean. Merging in 0.40 could be beneficial for all of us, and i it can be tackled the sooner, the less work it is. greetings, Thomas Am 29.11.2006 um 16:28 schrieb Mathieu Bouchard: On Wed, 29 Nov 2006, Thomas Grill wrote: i have been following the latst cvs changes and it seems, you are again beautifying the codebase. Please identify the parts that you consider that I'm just beautifying, apart from the files that don't belong to your part of devel_0_39. Actually, you should know what you changed. Only from the latest cvs digest: Actually, I still wanted you to identify it because I wanted to make sure that we agree on what it might be, and because the code you point out is part of the implementation of a feature. While you were writing the above mail, I was writing a mail about that feature, because that's something I _broke_ in devel_0_39 yesterday. _ _ __ ___ _ _ _ ... | 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] bug I introduced in devel_0_39
On Wed, 29 Nov 2006, Mathieu Bouchard wrote: [...] because they're patching a bug somewhere else in the code, the part where the variable called newest is assigned the result of a t_newmethod, _except_ for the builtin selectors. I'm fixing the problem today. I fixed the problem; we're back to normal for x_list.c and x_connective.c. I reimplemented my change in another way. _ _ __ ___ _ _ _ ... | 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] Fwd: PD-cvs Digest, Vol 21, Issue 29
On Wed, 2006-11-29 at 17:24 +0100, IOhannes m zmölnig wrote: Tim Blechmann wrote: On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote: Hi all, would it be possible to exclude the autobuild results from this digest, like e.g. by making a separate mailing for that. It's has become absolutely impossible to track the cvs changes. it's possible to switch off the digest mode for pd-cvs and forward the autobuild mails to the trash. ähm, if you choose to receive pd-cvs in non-digest mode, you should also be possible to select the cvs topic (and not no-topic (which is equivalent to ALL topics) or the autobuild topic). in this case you should not receive autobuild emails. ah, cool ... thanks ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 29 Nov 2006, Georg Holzmann wrote: Hallo you 2 ! Mathieu Bouchard wrote: Well, if you don't identify those specific parts that are a problem to you, and instead just quote the whole 200k digest, there's not much helping me to comply with your wishes, so I wouldn't have a choice, really. please - not one more branch !!! We already have two devel_0_39, separated not by cvs but by #ifdef and makefiles. Now it's getting somewhat cumbersome for me, but it seems that in addition to that, it's getting somewhat cumbersome for the only person (?) who still works on devel_0_39 outside of DesireData. Well, what do you want us to do, I don't think that you really want us to stay in that uncomfortable position forever? :) _ _ __ ___ _ _ _ ... | 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] ChangeLogs
ive found the file src/ChangeLog on the devel_0_39 branch, which contains some information on ImPd 0.37 through DesireData 0.39. are the changes from the devel branch documented somewhere? things like the scheduler, audio interfaces, SIMD/vectorization/memory-alignment, whatever else may be different.. likewise, is there a changelog for monsieur poquette's version? ive heard that its 1.manual/x5.htm, but that file doesn't exist in the devel branch.. - cdr ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 29 Nov 2006, Mathieu Bouchard wrote: Most CVS branches ever made are not meant to be merged back in. (Which CVS repositories have you used apart from CVS's ?) typo. should've been: Most CVS branches ever made are not meant to be merged back in. (Which CVS repositories have you used apart from PureData'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
[PD-dev] [ pure-data-Bugs-1601850 ] [vcf_filter~] without arguments crashes Pd
Bugs item #1601850, was opened at 2006-11-23 17:17 Message generated for change (Comment added) made by zmoelnig 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: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: musil (tmusil) Summary: [vcf_filter~] without arguments crashes Pd 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: IOhannes m zm�lnig (zmoelnig) Date: 2006-11-29 19: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
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
Hallo! We already have two devel_0_39, separated not by cvs but by #ifdef and makefiles. Now it's getting somewhat cumbersome for me, but it seems that in addition to that, it's getting somewhat cumbersome for the only person (?) who still works on devel_0_39 outside of DesireData. Well, what do you want us to do, I don't think that you really want us to stay in that uncomfortable position forever? :) No, but you said it yourself: you joined (after impure data) the pd_devel branch so that you can also benefit from those improvements ... Now there is already the main and devel/desire_data branch and I think such a marginal problem as you have (the beautification ...) should not be the reason for one more branch ... LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
First, i would be extremely cautious about making strange assumptions about other people's problems. Second, i think the whole case will solve itself shortly, because after the merge a devel branch will probably not be called devel_0_39 any more. It may also be a move back to more compatibility to Miller's branch, or not. all the best, Thomas Mathieu Bouchard schrieb: On Wed, 29 Nov 2006, Georg Holzmann wrote: No, but you said it yourself: you joined (after impure data) the pd_devel branch so that you can also benefit from those improvements ... Yes, but that was conditional to having such improvements. I think that I was somewhat mistaken when I first joined devel_0_39, I thought that it was going to be somewhat more dynamic than that. Turns out that: 1. I had the delusion that there were more developers working on devel_0_39, but I hadn't counted. Turned out that it wasn't true. 2. Tim is basically on the way out: keeps using pd for backwards-compatibility reasons. 3. Thomas has a hidden branch because devel_0_39 is too dangerous because I could be committing files in it. 4. At this point (these months...), the only other regular contributors to devel_0_39 are Chun Lee and myself. Now there is already the main and devel/desire_data branch and I think such a marginal problem as you have (the beautification ...) should not be the reason for one more branch ... Well, you shouldn't confuse the actual with problem, with something that is just a trigger (a catalyser) for change. Thomas's problem is just an occasion for taking the time for a reality check about the issue, and summarise all the issues that have accumulated during the 16 months of having devel_0_39 and desiredata two-in-one. I don't see the branching as being a big change, nor as a surprise, nor as being weird or out-of-place or bad manners. That said, I don't want to switch to another repository as of now; I don't see its advantages as being greater than its inconvenients. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pool files: UTF-8 encoding
Hi all, trying to fix loading/saving of non-ASCII characters in pool files. In the future, text files will still be saved in the native encoding, but XML will be UTF-8. Since i'm not very linux-savvy: I guess the default code table used for PD patchers is the same as being used for the X-server, right? Is there an API function to query this encoding and/or is there a system function to convert from/to UTF-8? best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
Hallo! Mathieu Bouchard schrieb: [...] 1. I had the delusion that there were more developers working on devel_0_39, but I hadn't counted. Turned out that it wasn't true. yes, but when there are more and more branches every developer will have it's own one and it's much more difficult for new one to join (where?) ... 3. Thomas has a hidden branch because devel_0_39 is too dangerous because I could be committing files in it. well, if more people are working on the same then it's also clear that sometimes there are clashes ... and it's also logical that Thomas doesn't take the latest cvs and maintains a more stable version for his product ... I don't see the branching as being a big change, nor as a surprise, nor as being weird or out-of-place or bad manners. of course it's not a big change and it's easy because you don't have to communicate ... and in the end you will give up desiredata and thomas will give up devel because of the lack of man power ... (I know, for me as a outsider it's easy to say that ... ;) Thomas Grill schrieb: [...] Second, i think the whole case will solve itself shortly, because after the merge a devel branch will probably not be called devel_0_39 any more. It may also be a move back to more compatibility to Miller's branch, or not. would be great ! Mathieu Bouchard schrieb: [...] The case was already solved before you wrote that mail: I've already branched DesireData off of devel_0_39, and I'm currently wiping #ifdef DESIRE off of devel_0_39 so that you don't have to clean after us. please wait at least some days till everyone is calmed down and you can speak about the actual problems before you make such a work ... The whole situation is a little bit similar to the current political situation here in austria: On 1. October there were elections and someone has to form a coalition, but till now the parties didn't discuss the actual problems, they were only angry against each other and said that they don't want to speak with the other one ... nobody wants to make a compromise ... :=) LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
wonderful ... matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ... that makes 5 devs for 3 branches and one rewrite ... what a wonderful waste of resources ... no please cool down ... one thing, that you people need to realize: open source software development doesn't work, if you don't care, what other people are doing. and how i see the current situation no one really cares about the other ones ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as most people. These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 29 Nov 2006, Georg Holzmann wrote: yes, but when there are more and more branches every developer will have it's own one and it's much more difficult for new one to join (where?) Right, right, but then, how do we get out of that situation? we can't. So let's concentrate on things that we can change. well, if more people are working on the same then it's also clear that sometimes there are clashes ... well, yes, when I work with Chun there are clashes and we resolve them. and it's also logical that Thomas doesn't take the latest cvs and maintains a more stable version for his product ... I understand that too; however, I haven't seen much action in the devel_0_39 branch lately. It doesn't disturb me that Thomas has a private branch, it's just that I reassessed the advantage of being in one CVS branch when the number of #ifdef DESIRE just raised suddenly in the last week, due to my new changes, and was going to continue raising steadily over the next months. (I know, for me as a outsider it's easy to say that ... ;) yes. come hang around on the #desiredata channel some day... please wait at least some days till everyone is calmed down and you can speak about the actual problems before you make such a work ... Hey, I've been calm all day. Just because the decision was sudden, doesn't mean that there hasn't been any reflection on it. I don't necessarily post all of my thoughts on pd-dev. _ _ __ ___ _ _ _ ... | 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Thu, 30 Nov 2006, Tim Blechmann wrote: matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ... that makes 5 devs for 3 branches and one rewrite ... You forgot to name MAX/MSP. what a wonderful waste of resources ... I don't feel guilty. no please cool down ... I don't feel angry. one thing, that you people need to realize: open source software development doesn't work, if you don't care, what other people are doing. Why did you start pnpd? and how i see the current situation no one really cares about the other ones ... And you still see this as a problem? _ _ __ ___ _ _ _ ... | 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] ChangeLogs
Here's Miller's ChangeLog: http://crca.ucsd.edu/~msp/Pd_documentation/x5.htm#s1 You can also generate ChangeLogs from CVS using this handy script: http://www.red-bean.com/cvs2cl/ .hc On Nov 29, 2006, at 1:16 PM, carmen wrote: ive found the file src/ChangeLog on the devel_0_39 branch, which contains some information on ImPd 0.37 through DesireData 0.39. are the changes from the devel branch documented somewhere? things like the scheduler, audio interfaces, SIMD/vectorization/memory- alignment, whatever else may be different.. likewise, is there a changelog for monsieur poquette's version? ive heard that its 1.manual/x5.htm, but that file doesn't exist in the devel branch.. - cdr ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Access to computers should be unlimited and total. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pool files: UTF-8 encoding
locales is the library and tool that handles that stuff, IIRC. You'll want to look into the env vars LANG, LC_ALL, etc. I think that's supposed to be system-wide, but with all those grabbag distros based on the Linux kernel, you never know who implemented what and how in their bit. .hc On Nov 29, 2006, at 4:37 PM, Thomas Grill wrote: Hi all, trying to fix loading/saving of non-ASCII characters in pool files. In the future, text files will still be saved in the native encoding, but XML will be UTF-8. Since i'm not very linux-savvy: I guess the default code table used for PD patchers is the same as being used for the X-server, right? Is there an API function to query this encoding and/or is there a system function to convert from/to UTF-8? best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 29 Nov 2006, Hans-Christoph Steiner wrote: A CVS branch is just a tool to manage code. I don't think we need to take it as any kind of social or political statement. We should use the tools to reduce friction as much as possible. You understand this. _ _ __ ___ _ _ _ ... | 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Thu, 30 Nov 2006, Thomas Grill wrote: So far, it was perfectly possible to coexist in the devel branch, at least for my perception. What I have in head is also future developments; my decision can seem hasty and/or hotheaded if only looking at the past. The last days i was wondering why suddenly a lot of changes happen in many parts of the devel branch, There are many reasons for that, but especially, we need to take care of distributing the software ourselves, because DesireData has been too long a hard-to-reach piece of software; so I added some more portability and turned the buildsystem in something that I can manage myself because I need to take care of a buildsystem for our testers. I think cleaning up the codebase makes much more sense once the merge has taken place, No, it *never* makes any sense, because there's always one more upcoming release... just wait one more year... and one more... and yet one more...! Right now there are a few important changes to the audio system pending, to make callback driven audio really smooth and reliable. Well, I'll pick those changes from your branch eventually, after they become public. You won't have to submit it in our bugtracker ;) _ _ __ ___ _ _ _ ... | 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] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 29 Nov 2006, Mathieu Bouchard wrote: On Thu, 30 Nov 2006, Thomas Grill wrote: The last days i was wondering why suddenly a lot of changes happen in many parts of the devel branch, There are many reasons for that, but especially, Oh, and the feature that started this thread, is the wrapping of newest, so that the client can manage object creations without race-conditions. This is an essential feature that I was supposed to add one year ago already, and which is necessary to make DesireData stable and to prevent it from becoming a big ball of hacks. Chun had been asking me this feature for several months! You can't expect GUI changes to have no impact on the base of the software if the base of the software isn't ready to accept such a kind of GUI. _ _ __ ___ _ _ _ ... | 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
