hi, my last mail got nuked by the server, did you change config? it never used to have a prob with a faked 'from' field to match the subscribed address...
anyways my vote is do away with the numbers. ive made a lot of minor tweaks to devel, which ive already made to impd as well, and definitely don't want to make them a 3rd time (that would be 3 strikes..). to fix/add stuff like:
/ .pdrc not being read on windows (pd.ini) / not being able to select 2 outs and 6 ins with portaudio / not being able to put tcl in your system path on win32 / no ASIO with non-MSVC on win32. / a few linux64 fixes / merge jsarlo's VST io sppt / almost everything from impd that wasnt in g_* files
nonetheless in the actual code theyre too trivial for anyone else to notice, and an order of magnitude smaller than the contributions Tim has made, but i wouldnt want them to get lost..so in order of preference from most to least
1: do away with numbering, and just have a 'devel'. every month or so, make sure it compiles on all 3 platforms and dump into MAIN..theres few enough developers and i dont think theyre stepping on toes and generally work on difft things.. 2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's stuff isnt lost, and so he doesnt have to bug miller or guenter or whoever and possibly paste a bunch of stuff in again and get grey hairs.. 3: crazy all-night frankenstein hack/merge fest with version # change that might lose features and add new bugs..
i mean the same reason i'd vote for 'devel' as rather using debian 'sid' than 'sarge' or something thats doomed (like win32)...
On Fri, 22 Oct 2004, cr wrote:
hi, my last mail got nuked by the server, did you change config? it never used to have a prob with a faked 'from' field to match the subscribed address...
anyways my vote is do away with the numbers. ive made a lot of minor tweaks to devel, which ive already made to impd as well, and definitely don't want to make them a 3rd time (that would be 3 strikes..). to fix/add stuff like:
/ .pdrc not being read on windows (pd.ini) / not being able to select 2 outs and 6 ins with portaudio / not being able to put tcl in your system path on win32 / no ASIO with non-MSVC on win32. / a few linux64 fixes / merge jsarlo's VST io sppt / almost everything from impd that wasnt in g_* files
nonetheless in the actual code theyre too trivial for anyone else to notice, and an order of magnitude smaller than the contributions Tim has made, but i wouldnt want them to get lost..so in order of preference from most to least
1: do away with numbering, and just have a 'devel'. every month or so, make sure it compiles on all 3 platforms and dump into MAIN..theres few enough developers and i dont think theyre stepping on toes and generally work on difft things.. 2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's stuff isnt lost, and so he doesnt have to bug miller or guenter or whoever and possibly paste a bunch of stuff in again and get grey hairs.. 3: crazy all-night frankenstein hack/merge fest with version # change that might lose features and add new bugs..
One thing that is pretty clear is that it won't be done through a unconditional merge of devel into main. That is something that Miller doesn't want, and I fully understand that.
Your proposal 2 is how it is done currently.
Your proposal 3 is probably how it is done in the future, because the person who has done the merges up to now has stepped back from these boring duties.
There is one additional "feature" which comes into play, and that is the patches tracker. If you want your changes to be included in the main version you have to submit a patch against the latest MAIN branch.
This is a test to ease the inclusion of new features und bug fixes in the main branch. Don't know if this succeeds, because it depends if it will be accepted by the developers *and* by Miller. Sorting out the "good" changes from the "bad" changes in the devel branch is a lot of work. Having the different changes split up in manageable patches will make this a lot easier. Bug fixes can be applied almost immediatly, without having to sort out what belongs to the bug fix and what not. The single patches can easily be reviewed by other developers. They can be applied in isolation and be tested without the influence of other changes.
Guenter
i mean the same reason i'd vote for 'devel' as rather using debian 'sid' than 'sarge' or something thats doomed (like win32)...
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
1: do away with numbering, and just have a 'devel'. every month or so, make sure it compiles on all 3 platforms and dump into MAIN..theres few enough developers and i dont think theyre stepping on toes and generally work on difft things..
i don't approve with your opinion ... if miller solved something and other guys solved something ... e.g. yves threaded gui vs. miller's improved gui ... which to take? since pd is miller's project, we should try to follow his branch in the devel branch ... at the pd-conf i did a diff between devel_0_37 and 0.37-2 ... there is not so many stuff, that has changed there ... but looking at the diff, i found a few thinks, that are not needed any more (e.g. console stuff added by matju) ...
2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's stuff isnt lost, and so he doesnt have to bug miller or guenter or whoever and possibly paste a bunch of stuff in again and get grey hairs..
... so merging the devel changes to the new msp branch is a better approach ... since the changes will be reviewed from time to time ... by guenter, by me, by miller or whoever does the merge ...
3: crazy all-night frankenstein hack/merge fest with version # change that might lose features and add new bugs..
... and review code ... maybe find bugs in devel_x_xx's additions that haven't been found before ...
tim (approves with guenter, although having to learn a lot about cvs and diff)
On Fri, 22 Oct 2004, Tim Blechmann wrote:
at the pd-conf i did a diff between devel_0_37 and 0.37-2 ... there is not so many stuff, that has changed there ... but looking at the diff, i found a few thinks, that are not needed any more (e.g. console stuff added by matju) ...
the console stuff was added by accident and should be removed because it's been committed by accident. iirc, only 1/4 of the code is present, and i didn't even know it was there.
I'd gladly introduce the full-blown console code into devel_0_37 but if you are going to drop it soon in favour of Miller's then what's the point... I haven't tried it but I heard it was missing features. Is it an optional console? what's the amount of scrollback it allows, and is that configurable?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
I'd gladly introduce the full-blown console code into devel_0_37 but if you are going to drop it soon in favour of Miller's then what's the point... I haven't tried it but I heard it was missing features. Is it an optional console? what's the amount of scrollback it allows, and is that configurable?
i'd suggest to leave the devel_0_37 branch more or less, as it is ... and if you miss some features, it's probably better to build these features on top of miller's console ...
we should try to follow a single line of development ... especially not removing any code by miller, but add useful code to it ... so if there is a console in the msp release, use his code and extend it ...
cheers ... tim
On Sat, 23 Oct 2004, Tim Blechmann wrote:
I'd gladly introduce the full-blown console code into devel_0_37 but if you are going to drop it soon in favour of Miller's then what's the point... I haven't tried it but I heard it was missing features. Is it an optional console? what's the amount of scrollback it allows, and is that configurable?
i'd suggest to leave the devel_0_37 branch more or less, as it is ... and if you miss some features, it's probably better to build these features on top of miller's console ... we should try to follow a single line of development ... especially not removing any code by miller, but add useful code to it ... so if there is a console in the msp release, use his code and extend it ...
Alright. But for the other features I don't want to wait an undetermined amount of time so I began changing devel_0_37. I will try to keep the changes pretty much contained so that they are not too hard to merge. In particular I added src/u_matju.tk. It may seem strange to have a file named by an author and not a functionality, but then many files have "iem" written all over them, and I think that in the modularisation of Pd we should take into account the fact that there are several people contributing that try not to step on each other's toes while getting new functionality in.
So a lot of my new code should be in u_matju.tk for now, and more in additional u_*.tk files i will add later on. However I cannot avoid modifying the C code to introduce the features I want to introduce.
I will state all of my changes on this list (even though there is already the pd-cvs list for that).
src: cvs tag devel_0_37_A
src/t_tkcmd.c: tcl_vmess(): fixed buffer overflow pdgui_doevalfile(): print loadtime tcl error messages
src/s_path.c: glob_update_path(): added (for use by class browser)
src/m_class.c: added class browser thingies: t_class_list, class_list, class_find(), glob_update_class_info()
src/m_glob.c: added ";pd" methods: update-class-list update-class-info update-path help
src/u_matju.tk: (new file) added class browser code
src/makefile.in: installing u_matju.tk
src/u_main.tk: added class browser in Help menu pdtk_pd_startup now has 3rd arg optional (bugfix) reads u_matju.tk
src/m_class.c: class_new(): now records in class_list
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
So a lot of my new code should be in u_matju.tk for now, and more in additional u_*.tk files i will add later on. However I cannot avoid modifying the C code to introduce the features I want to introduce.
if so, please add a command line flag like --enable-impd to enable your changes ... especially if they are additional features and not bugfixes ... if they are bug fixes (tcl_vmess()), please also fix them in 0.38-testX, and send a patch to miller ...
I will state all of my changes on this list (even though there is already the pd-cvs list for that).
since you are changing a lot in the gui, maybe it's a good idea to write your code for 0.38 ... i'm not that familiar with miller's changes to the gui code ... but since 0.38 will (hopefully) be released soon, we should abandon devel_0_37 in the near future ...
cheers ... tim
On Mon, 25 Oct 2004, Tim Blechmann wrote:
So a lot of my new code should be in u_matju.tk for now, and more in additional u_*.tk files i will add later on. However I cannot avoid modifying the C code to introduce the features I want to introduce.
if so, please add a command line flag like --enable-impd to enable your changes ... especially if they are additional features and not bugfixes
My policy is that, if they don't interfere with the usual behaviour, I just add them directly; but if they do then I have either a compile-time option or a load-time option, preferably the latter. I hope to introduce the GUI overhaul as a load-time option (-modelview) and to make as little use as possible of the compile-time (configure-time) options, even though it's more work (like making sure there is no conflict during linking). This way, when devel binaries are published, the new gui will be a command-line option away.
if they are bug fixes (tcl_vmess()), please also fix them in 0.38-testX, and send a patch to miller ...
Whoever really wants those fixes in 0.38 should take that initiative. Personally I am satisfied with just having them in devel_0_37 for now. I don't intend to use plain 0.38 because I am interested in actually using the improvements I make, so devel_0_37 is currently my only concern (I think this is rather natural).
since you are changing a lot in the gui, maybe it's a good idea to write your code for 0.38 ... i'm not that familiar with miller's changes to the gui code ...
I'm carefully avoiding committing code from the console and the pdrc editor because of that. Those are the only interferences that I am aware of. If Miller wants to have a look at IMPD's ChangeLog (and tell me whether anything else may conflict), here it is:
Impd 0.37.A (-r impd_0_37_A) : * forked from devel_0_37, 2004.02.21 * added console for post() * .pdrc: -console <number_of_lines> * added button bar (that does like Ctrl+E & Put menu) * .pdrc: -look <directory_of_icons> (remember you can't use ~ nor $HOME in .pdrc) * includes a selectable windowid (for those who know how to use it) * class list dialog * scans for loaded classes, abstractions/externs dirs * help button fetches help file without needing to instantiate first * filter box helps finding classes quickly * displays some info on the class, like a list of defined methods and such. * statusbar shows cursor position (enable with -statusbar)
Impd 0.37.A.2 (-r impd_0_37_A_2) : * merged GG's reverting of "quote hack"
Impd 0.37.B : * moving rendering to the TCL side * moving event-handling to the TCL side too * new file u_object.tk * added pd_scanargs(), pd_upload(), sys_mgui(). * added color schemes (modifiable in u_main.tk) * switched to a jmaxish look * merged g_vdial.c into g_hdial.c * merged g_vslider.c into g_hslider.c * added Patcher->View->Redraw * added proc populate_menu, proc property_dialog * added ~/.pd.tk loading * inlet tooltips have new look * rewrote all of the property dialogs * added object class name completion (the <Tab> key) * mouse scrollwheel works in patchers * plus/minus button on tcl listener * changed default font and borderwidth * if conf not found in ~ ($HOME), looks in Pd's install directory (eg. /usr/local/lib/pd) * looks for .impdrc before .pdrc * pdrc editor * -help lists unavailable options with note "not compiled in" * sys_vgui() message size limit removed * new peak meters (thanks Carmen) * dropper object outputs symbols of filenames (requires tkdnd) * joe sarlo's VST-plugin i/o scheduler available on windows * error() merged into pd_error() and using strerror() to get meaningful error messages for failed I/O * completely breaking compatibility with Pd's GUI externals (for a good reason)
Note that not all of those changes are going to be in devel_0_37, and many of them will be modified significantly before they enter devel_0_37 or devel_0_38, especially the areas covered by that "-modelview" option.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Mon, 25 Oct 2004, Matju wrote:
linking). This way, when devel binaries are published, the new gui will be a command-line option away.
Hi,
Although I might sound a bit repetitive, the devel branch is not meant to be published. It is for development only. Everyone should try to get the changes into Pd's main distribution. There is a webpage on sourceforge where you can submit patches (check out http://pure-data.sf.net/bug-report.php).
This will make it a lot easier to integrate changes in the main distribution, because they can be split into several manageable chunks and reviewed individually.
Its really easy. Submitting a patch is just one click away.
Guenter
if they are bug fixes (tcl_vmess()), please also fix them in 0.38-testX, and send a patch to miller ...
Whoever really wants those fixes in 0.38 should take that initiative. Personally I am satisfied with just having them in devel_0_37 for now. I don't intend to use plain 0.38 because I am interested in actually using the improvements I make, so devel_0_37 is currently my only concern (I think this is rather natural).
since you are changing a lot in the gui, maybe it's a good idea to write your code for 0.38 ... i'm not that familiar with miller's changes to the gui code ...
I'm carefully avoiding committing code from the console and the pdrc editor because of that. Those are the only interferences that I am aware of. If Miller wants to have a look at IMPD's ChangeLog (and tell me whether anything else may conflict), here it is:
Impd 0.37.A (-r impd_0_37_A) :
- forked from devel_0_37, 2004.02.21
- added console for post()
- .pdrc: -console <number_of_lines>
- added button bar (that does like Ctrl+E & Put menu)
- .pdrc: -look <directory_of_icons> (remember you can't use ~ nor $HOME in .pdrc)
- includes a selectable windowid (for those who know how to use it)
- class list dialog
- scans for loaded classes, abstractions/externs dirs
- help button fetches help file without needing to instantiate first
- filter box helps finding classes quickly
- displays some info on the class, like a list of defined methods and such.
- statusbar shows cursor position (enable with -statusbar)
Impd 0.37.A.2 (-r impd_0_37_A_2) :
- merged GG's reverting of "quote hack"
Impd 0.37.B :
- moving rendering to the TCL side
- moving event-handling to the TCL side too
- new file u_object.tk
- added pd_scanargs(), pd_upload(), sys_mgui().
- added color schemes (modifiable in u_main.tk)
- switched to a jmaxish look
- merged g_vdial.c into g_hdial.c
- merged g_vslider.c into g_hslider.c
- added Patcher->View->Redraw
- added proc populate_menu, proc property_dialog
- added ~/.pd.tk loading
- inlet tooltips have new look
- rewrote all of the property dialogs
- added object class name completion (the <Tab> key)
- mouse scrollwheel works in patchers
- plus/minus button on tcl listener
- changed default font and borderwidth
- if conf not found in ~ ($HOME), looks in Pd's install directory (eg. /usr/local/lib/pd)
- looks for .impdrc before .pdrc
- pdrc editor
- -help lists unavailable options with note "not compiled in"
- sys_vgui() message size limit removed
- new peak meters (thanks Carmen)
- dropper object outputs symbols of filenames (requires tkdnd)
- joe sarlo's VST-plugin i/o scheduler available on windows
- error() merged into pd_error() and using strerror() to get meaningful error messages for failed I/O
- completely breaking compatibility with Pd's GUI externals (for a good reason)
Note that not all of those changes are going to be in devel_0_37, and many of them will be modified significantly before they enter devel_0_37 or devel_0_38, especially the areas covered by that "-modelview" option.
Mathieu Bouchard -=- Montr�al QC Canada -=- http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Its really easy. Submitting a patch is just one click away.
since i'm trying to split my changes to small pieces ... are the diffs supposed to contain only the changes to the source code or also to the build system (configure, makefile) ...
cheers ... tim
On Wed, 27 Oct 2004, Tim Blechmann wrote:
Its really easy. Submitting a patch is just one click away.
since i'm trying to split my changes to small pieces ... are the diffs supposed to contain only the changes to the source code or also to the build system (configure, makefile) ...
It's up to you. I would not bother too much about the build system. If the patches get accepted then this should not be the biggest problem. So maybe its better to make them separate.
Guenter
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Sorry for the delay.
On Tue, 26 Oct 2004, guenter geiger wrote:
On Mon, 25 Oct 2004, Matju wrote:
linking). This way, when devel binaries are published, the new gui will be a command-line option away.
Hi, Although I might sound a bit repetitive, the devel branch is not meant to be published.
One question... what's "pd extended" ?
Besides, Pd was also not intended to be a clone of MAX, and yet people use it a lot like that, and then Pd was also not meant to do video processing, and yet people use it for that. (and so on)
What I mean is that if ever there's a significant incentive to publish binaries of the devel branch, then it will happen. (it may also happen if one mistakenly believe that there is an incentive, but, whatever.) Maybe everything will go well, but if some of my patches are rejected for whatever reason, be it for lack of time, lack of understanding, or lack of agreement, I don't see why I'd have to wait in line forever.
That said, I will attempt to collaborate, but I'm not completely sure that submitting patches and applying them in scrambled order is a system that will survive long. The chance of interpatch conflict increases as the number of patches increase and that their spread factor is big (some patches modify 5 files or more, and not necessarily because the fix is lousy and made without care for diffing: sometimes you just _have_ to modify 5 files)
There is a webpage on sourceforge where you can submit patches (check out http://pure-data.sf.net/bug-report.php).
I don't know why features should be added on a page called bug-report.php; it's not a showstopper, but frankly, the name of the page is counter-intuitive. I wouldn't have looked there. The menu says "Bugs, Patches, FR", but seriously, "Patches" already has a strong, different meaning in the Pd world, which is confusing, and then FR doesn't look like a familiar abbreviation at all.
BTW, how normal is it to call "bug fix" what is really an added feature? And then how arrogant is it?
Its really easy. Submitting a patch is just one click away.
No, it's more of a matter of duplicating the work done by CVS, but a bit more manually, and then figuring out dependencies and conflicts with all other patches that have been applied since the beginning of the branch (or of the last major checkpoint). The "click away" is just the last easy step.
Btw, if I'm supposed to keep a few dozen .diff files around for submission and also the .diff's of other people to check for potential conflicts, how is CVS supposed to be useful to us at all?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Mon, 15 Nov 2004, Matju wrote:
Sorry for the delay.
No problem, we have time.
On Tue, 26 Oct 2004, guenter geiger wrote:
On Mon, 25 Oct 2004, Matju wrote: Hi, Although I might sound a bit repetitive, the devel branch is not meant to be published.
One question... what's "pd extended" ?
right, but still, the CVS devel branch was not meant to be published. The fact that it was doesn't change the intention it was created for, or does it ?
Besides, Pd was also not intended to be a clone of MAX, and yet people use it a lot like that, and then Pd was also not meant to do video processing, and yet people use it for that. (and so on)
What I mean is that if ever there's a significant incentive to publish binaries of the devel branch, then it will happen. (it may also happen if one mistakenly believe that there is an incentive, but, whatever.) Maybe everything will go well, but if some of my patches are rejected for whatever reason, be it for lack of time, lack of understanding, or lack of agreement, I don't see why I'd have to wait in line forever.
That said, I will attempt to collaborate, but I'm not completely sure that submitting patches and applying them in scrambled order is a system that will survive long. The chance of interpatch conflict increases as the number of patches increase and that their spread factor is big (some patches modify 5 files or more, and not necessarily because the fix is lousy and made without care for diffing: sometimes you just _have_ to modify 5 files)
Actually patches that will not get accepted should be rejected and closed. This way I hope that there won't be too many patches lying around.
There is a webpage on sourceforge where you can submit patches (check out http://pure-data.sf.net/bug-report.php).
I don't know why features should be added on a page called bug-report.php; it's not a showstopper, but frankly, the name of the page is counter-intuitive. I wouldn't have looked there. The menu says "Bugs, Patches, FR", but seriously, "Patches" already has a strong, different meaning in the Pd world, which is confusing, and then FR doesn't look like a familiar abbreviation at all.
Yes, you are right. What if I change bug-report.php to trackers.php ? I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
BTW, how normal is it to call "bug fix" what is really an added feature? And then how arrogant is it?
That was not my intention. I am trying to rephrase the section on patches in order not to sound arrogant. I just sort of mixed up the two purposes of patches, which is bug fixes and new features. Thanks for pointing it out.
Its really easy. Submitting a patch is just one click away.
No, it's more of a matter of duplicating the work done by CVS, but a bit more manually, and then figuring out dependencies and conflicts with all other patches that have been applied since the beginning of the branch (or of the last major checkpoint). The "click away" is just the last easy step.
You are right, I wrote that as a buzz word, so that people accept the system. Submitting a patch is actually easy, creating it not.
The question now is, who is responsible for creating the patch. I think that it is not a lot harder to create the patch than to merge back the changes in CVS.
Of course your case is a special one, because you have changes that are going deeper into the core of Pd than others. I don't know really how to solve this, it is likely that the system we have is not up to this task. What would be your proposal ? Lets talk about it.
Btw, if I'm supposed to keep a few dozen .diff files around for submission and also the .diff's of other people to check for potential conflicts, how is CVS supposed to be useful to us at all?
The same, probably it doesn't work. I would be more than happy to drop all this patches stuff and go over to a more open development model, where people can change the Pd code directly, but it is not up to me to decide this.
Guenter
On Mon, 15 Nov 2004, guenter geiger wrote:
On Mon, 15 Nov 2004, Matju wrote:
On Tue, 26 Oct 2004, guenter geiger wrote: One question... what's "pd extended" ?
right, but still, the CVS devel branch was not meant to be published. The fact that it was doesn't change the intention it was created for, or does it ?
Well, depends who was involved in the process of publishing "pd extended". It may tell something about the seriousness of the original intent. And then there are intents that are platonician as in "well, if the world were as perfect as i'd like it to be, then X" and there are others that are positivist as in "given the current state of the world, then X". So I'd like to know what is the reasoning that led to that intent.
Actually patches that will not get accepted should be rejected and closed. This way I hope that there won't be too many patches lying around.
Ok, so any submitted patches should be sufficiently short-term to remain conflict-free, and any conflicting patch has to be resubmitted in a better form. Already sounds better.
Yes, you are right. What if I change bug-report.php to trackers.php ?
I don't know, "trackers" is also an overloaded word in computer-music circles :-( but then, one name has to be picked at one point and it won't necessarily be ideal...
I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
Maybe something like "Change Request" sounds like it'd encompass both "Bug Report" and "Feature Request" while sounding neutral/generic enough. What do you think?
That was not my intention. I am trying to rephrase the section on patches in order not to sound arrogant.
It's also a matter of culture. For example, in Extreme Programming circles, it's consider normal to consider a missing feature to be a bug as soon as "make test" can figure out whether the feature is there or not, and that even if no line of implementation code has ever been written. But then it's not like Pd users can be expected to have any clue about that culture (especially given how the phrase Extreme Programming is used around here) so I'm not too sure it's relevant.
However the practice of using a bug-tracker with the partial intention of tracking feature-requests is apparently more widespread than just Extreme Programming... (?)
I just sort of mixed up the two purposes of patches, which is bug fixes and new features. Thanks for pointing it out.
Well, there's a simple, nice reason for that: it's that those two purposes are very alike in the way that those development processes happen to be formalized (which is why i mentioned "change request" as a common name)
You are right, I wrote that as a buzz word, so that people accept the system.
I didn't know you have leanings towards marketing... ;-)
The question now is, who is responsible for creating the patch. I think that it is not a lot harder to create the patch than to merge back the changes in CVS.
Well, the way I thought about it in the last mail, is that a change merged back to CVS only has to be compatible with the head of the branch, whereas a free-floating patch is usually expected to work at least with a large enough range of revisions of a given branch. Now if you say that the patches are short-term then the difference between the two is less important, but I wonder how many short-term patches will slip into the long-term domain.
Of course your case is a special one, because you have changes that are going deeper into the core of Pd than others. I don't know really how to solve this, it is likely that the system we have is not up to this task. What would be your proposal ? Lets talk about it.
My proposal could be to honestly try the system for a while and see how much trouble I get in practice... (not all troubles can be realistically avoided upfront and I feel I'm attempting to forecast a bit too much already)
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Matju hat gesagt: // Matju wrote:
On Mon, 15 Nov 2004, guenter geiger wrote:
I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
Maybe something like "Change Request" sounds like it'd encompass both "Bug Report" and "Feature Request" while sounding neutral/generic enough. What do you think?
Well, in some regards we are bound by what Sourceforge offers, so "Feature Request" and "Bug Report" are rather fixed, at least on the Project Page. Personally I think "Request" more problematic than "Feature", because it's not like I'm *requesting* that some feature must be added, it's just a cool idea I had, and I'd like to discuss it, when submitting it to the FR page.
My proposal could be to honestly try the system for a while and see how much trouble I get in practice... (not all troubles can be realistically avoided upfront and I feel I'm attempting to forecast a bit too much already)
There already are a number of feature wishes, bug reports and even patches in the Trackers. I think, it had a good start already, and I do hope, this will get more use in the future.
Ciao
On Mon, 15 Nov 2004, Matju wrote:
Well, depends who was involved in the process of publishing "pd extended". It may tell something about the seriousness of the original intent. And then there are intents that are platonician as in "well, if the world were as perfect as i'd like it to be, then X" and there are others that are positivist as in "given the current state of the world, then X". So I'd like to know what is the reasoning that led to that intent.
I think it is more platonician then. I am trying to avoid a branch. This might be a very conservative approach and I would probably (surely?) act differently there would be a feature that I want to have in Pd. A good example is the alsa sequencer support, which is built in in the experimental debian package. I did not do a split of Pd though, it is just a patched version.
Let me rephrase the whole question. If someone would ask me if I created the CVS for developers in order to publish an improved version of Pd, I would say "no". I created it in order to help the development on the Pd core and to make it possible to work together on new ideas, ideas that are then eventually incorporated into the official version.
Actually patches that will not get accepted should be rejected and closed. This way I hope that there won't be too many patches lying around.
Ok, so any submitted patches should be sufficiently short-term to remain conflict-free, and any conflicting patch has to be resubmitted in a better form. Already sounds better.
Yes, you are right. What if I change bug-report.php to trackers.php ?
I don't know, "trackers" is also an overloaded word in computer-music circles :-( but then, one name has to be picked at one point and it won't necessarily be ideal...
Already called it like that without thinking :(
I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
Maybe something like "Change Request" sounds like it'd encompass both "Bug Report" and "Feature Request" while sounding neutral/generic enough. What do you think?
Well, but it lacks the clearness of "Patches". The Patches tracker is meant to put source code. "Change Request" is too similar to feature request I think.
I just sort of mixed up the two purposes of patches, which is bug fixes and new features. Thanks for pointing it out.
Well, there's a simple, nice reason for that: it's that those two purposes are very alike in the way that those development processes happen to be formalized (which is why i mentioned "change request" as a common name)
Well, I am not fully conviced that a name change of the tracker would currently be a good idea. Lets just look how many pd patches (in the sense of abstractions) get uploaded. The name conincidence is really unfortunate ...
You are right, I wrote that as a buzz word, so that people accept the system.
I didn't know you have leanings towards marketing... ;-)
I had to learn to do this, otherwise people won't listen.
The question now is, who is responsible for creating the patch. I think that it is not a lot harder to create the patch than to merge back the changes in CVS.
Well, the way I thought about it in the last mail, is that a change merged back to CVS only has to be compatible with the head of the branch, whereas a free-floating patch is usually expected to work at least with a large enough range of revisions of a given branch. Now if you say that the patches are short-term then the difference between the two is less important, but I wonder how many short-term patches will slip into the long-term domain.
Has to be seen. I am not against changing the system if there is a need for it. Currently we are in the test phase.
Of course your case is a special one, because you have changes that are going deeper into the core of Pd than others. I don't know really how to solve this, it is likely that the system we have is not up to this task. What would be your proposal ? Lets talk about it.
My proposal could be to honestly try the system for a while and see how much trouble I get in practice... (not all troubles can be realistically avoided upfront and I feel I'm attempting to forecast a bit too much already)
Ok. It is a good thing to expect the worst things to happen, this way it is possible to deal with possible problems in advance. We just have to remember that the system is here for helping us to collaborate. If it fails in that, we have to change it.
Guenter
On Nov 16, 2004, at 5:55 AM, guenter geiger wrote:
On Mon, 15 Nov 2004, Matju wrote:
Well, depends who was involved in the process of publishing "pd extended". It may tell something about the seriousness of the original intent. And then there are intents that are platonician as in "well, if the world were as perfect as i'd like it to be, then X" and there are others that are positivist as in "given the current state of the world, then X". So I'd like to know what is the reasoning that led to that intent.
I think it is more platonician then. I am trying to avoid a branch. This might be a very conservative approach and I would probably (surely?) act differently there would be a feature that I want to have in Pd. A good example is the alsa sequencer support, which is built in in the experimental debian package. I did not do a split of Pd though, it is just a patched version.
Let me rephrase the whole question. If someone would ask me if I created the CVS for developers in order to publish an improved version of Pd, I would say "no". I created it in order to help the development on the Pd core and to make it possible to work together on new ideas, ideas that are then eventually incorporated into the official version.
I also think that its very important that we avoid splitting the Pd devs, but I don't think that distributing binaries of devel would necessarily be a bad thing, or lead to a fork. The real key here is communication. And I think we agree that the goal of our work is to have one unified Pd. I think that we should be distributing binaries of major branches like devel and impd so that the ideas and code in those branches can get thoroughly tested by a broad range of people. Then it should become apparent what works and what does.
I think we can see examples of this being done in a friendly manner, and I think it will make a fork less likely because there will be an outlet for trying new things. An example I recently came upon is the gaim-vv fork. They are developing voice and video support in a friendly fork, and once its done, they will fold everything into libgaim.
.hc
Actually patches that will not get accepted should be rejected and closed. This way I hope that there won't be too many patches lying around.
Ok, so any submitted patches should be sufficiently short-term to remain conflict-free, and any conflicting patch has to be resubmitted in a better form. Already sounds better.
Yes, you are right. What if I change bug-report.php to trackers.php ?
I don't know, "trackers" is also an overloaded word in computer-music circles :-( but then, one name has to be picked at one point and it won't necessarily be ideal...
Already called it like that without thinking :(
I can also call the menu entry "Trackers", or just write "feature requests" instead of FR, but it makes the menu entry quit lengthy. The reason for concentrating on the bug reporting aspect was that I thought that is what most of the users would do.
Maybe something like "Change Request" sounds like it'd encompass both "Bug Report" and "Feature Request" while sounding neutral/generic enough. What do you think?
Well, but it lacks the clearness of "Patches". The Patches tracker is meant to put source code. "Change Request" is too similar to feature request I think.
I just sort of mixed up the two purposes of patches, which is bug fixes and new features. Thanks for pointing it out.
Well, there's a simple, nice reason for that: it's that those two purposes are very alike in the way that those development processes happen to be formalized (which is why i mentioned "change request" as a common name)
Well, I am not fully conviced that a name change of the tracker would currently be a good idea. Lets just look how many pd patches (in the sense of abstractions) get uploaded. The name conincidence is really unfortunate ...
You are right, I wrote that as a buzz word, so that people accept the system.
I didn't know you have leanings towards marketing... ;-)
I had to learn to do this, otherwise people won't listen.
The question now is, who is responsible for creating the patch. I think that it is not a lot harder to create the patch than to merge back the changes in CVS.
Well, the way I thought about it in the last mail, is that a change merged back to CVS only has to be compatible with the head of the branch, whereas a free-floating patch is usually expected to work at least with a large enough range of revisions of a given branch. Now if you say that the patches are short-term then the difference between the two is less important, but I wonder how many short-term patches will slip into the long-term domain.
Has to be seen. I am not against changing the system if there is a need for it. Currently we are in the test phase.
Of course your case is a special one, because you have changes that are going deeper into the core of Pd than others. I don't know really how to solve this, it is likely that the system we have is not up to this task. What would be your proposal ? Lets talk about it.
My proposal could be to honestly try the system for a while and see how much trouble I get in practice... (not all troubles can be realistically avoided upfront and I feel I'm attempting to forecast a bit too much already)
Ok. It is a good thing to expect the worst things to happen, this way it is possible to deal with possible problems in advance. We just have to remember that the system is here for helping us to collaborate. If it fails in that, we have to change it.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
I also think that its very important that we avoid splitting the Pd devs, but I don't think that distributing binaries of devel would necessarily be a bad thing, or lead to a fork. The real key here is communication. And I think we agree that the goal of our work is to have one unified Pd. I think that we should be distributing binaries
i can only second it ... communication sometimes does real magic ...
of major branches like devel and impd so that the ideas and code in those branches can get thoroughly tested by a broad range of people. Then it should become apparent what works and what does.
distributing binaries of devel will definitely improve bug reports for the devel branch ... there were some bugs in the devel branch that i introduced and for a long time, i wasn't aware of them, since no one actually used the specific functions. e.g. there was a problem with overcommiting memory that was in devel for about 4 monthes ... and i don't know, how many bugs are in my asio implementation, since i only got feedback from thomas and carmen ...
cheers ... tim
On Thu, 18 Nov 2004, Tim Blechmann wrote:
distributing binaries of devel will definitely improve bug reports for the devel branch ... there were some bugs in the devel branch that i ...
I agree, but it should be done in a way so that people are aware that they are using an unstable version of Pd.
Actually it would be a good opportunity to try to setup an autocompiler. This would be useful for the externals too.
Guenter
introduced and for a long time, i wasn't aware of them, since no one actually used the specific functions. e.g. there was a problem with overcommiting memory that was in devel for about 4 monthes ... and i don't know, how many bugs are in my asio implementation, since i only got feedback from thomas and carmen ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Mon, 15 Nov 2004, Matju wrote:
Btw, if I'm supposed to keep a few dozen .diff files around for submission and also the .diff's of other people to check for potential conflicts, how is CVS supposed to be useful to us at all?
The same, probably it doesn't work. I would be more than happy to drop all this patches stuff and go over to a more open development model, where people can change the Pd code directly, but it is not up to me to decide this.
I think, patches should be done to specific versions. When 0.38 is stable, patches should be done only against the latest released 0.38 version. The goal of patches is to make it easier to get them into main Pd. Really experimental stuff doesn't need to have a patch against stable, I think. Of course, a patch would be nice, but it's not so urgent. Bugfixes need a patch. However before some new features are submitted to inclusion into main Pd, there must be a patch, IMO.
It will make it easier for everyone in the end, not only for Miller as maintainer of Pd stable. For example: I might need to run a stable Pd for performing, but I'd like to use the ALSA sequencer support. I can apply this patch on my own and I don't need to run devel_XX, which can be unstable, and I don't need to run Miller's test versions, which also normally have more bugs in it, than the last released version. I only apply the aseq patch and only risk bugs there. The same applies to packagers. ALSA sequencer support is very, very useful for e.g. A/Demudi, so they can (Guenther did) include it in the package.
That, IMO, is the main advantage of having a patch tracker. And other projects work like this, too, for example the Linux kernel. Without a patch, nothing gets into the kernel. OTOH distributions like Suse supply heavily patched kernel versions, even Debian delivers some patches for kernels, which add support for hardware etc.
Ciao
On Tue, 26 Oct 2004, guenter geiger wrote:
On Mon, 25 Oct 2004, Matju wrote: Hi, Although I might sound a bit repetitive, the devel branch is not meant to be published.
One question... what's "pd extended" ?
right, but still, the CVS devel branch was not meant to be published. The fact that it was doesn't change the intention it was created for, or does it ?
the problem is still ... what if a useful patch will be rejected? as miller pointed out at the convention, he won't add the simd stuff, because he feels, he can't maintain it. but still the simd instructions are very useful, since they provide a speedup of about 100% ... the intention is very good, but still, it doesn't bring us further ...
although i don't like the idea, but in this case a "pd extended" might be some way to publish the devel branch at a point, we consider as stable ... (at a certain point earlier this year, devel_0_37 has been more stable than 0.37 in terms of denormal handling)
another way would be the possibility of having maintainers for certain parts of pd ... so if someone submits a patch, he should be say that he will maintain that piece of code in future ...
cheers ... tim
On Tue, 16 Nov 2004, Tim Blechmann wrote:
the problem is still ... what if a useful patch will be rejected? as miller pointed out at the convention, he won't add the simd stuff, because he feels, he can't maintain it. but still the simd instructions are very useful, since they provide a speedup of about 100% ... the intention is very good, but still, it doesn't bring us further ...
although i don't like the idea, but in this case a "pd extended" might be some way to publish the devel branch at a point, we consider as stable ... (at a certain point earlier this year, devel_0_37 has been more stable than 0.37 in terms of denormal handling)
another way would be the possibility of having maintainers for certain parts of pd ... so if someone submits a patch, he should be say that he will maintain that piece of code in future ...
I think the situation is somehow comparable to the patches that exist against the linux kernel. Some of then live a life of their own during several kernel releases, then at some point the get included (well, or not). There are people who distribute patched kernels too. I, for example might be tempted to distribute a version with simd within Debian. But I would prefer to do that with a patch that gives me simd, instead of using the complete devel branch.
Maintaing the simd improvements apart is a viable solution too, if you can separate them enough that they can be activated by a configuration setting they should not get into the way of normal operation.
Guenter
Maintaing the simd improvements apart is a viable solution too, if you can separate them enough that they can be activated by a configuration setting they should not get into the way of normal operation.
hmm ... it should be possible to do that ... i mean ... i should be able to add a runtime flag to the runtime cpu detection ...
on the other hand, the code simd instructions, the vectoralignment and the threadlock for garrays it hard to split appart...
cheers ... tim
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in "scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
cheers Miller
On Tue, Nov 16, 2004 at 02:52:00PM +0100, Tim Blechmann wrote:
Maintaing the simd improvements apart is a viable solution too, if you can separate them enough that they can be activated by a configuration setting they should not get into the way of normal operation.
hmm ... it should be possible to do that ... i mean ... i should be able to add a runtime flag to the runtime cpu detection ...
on the other hand, the code simd instructions, the vectoralignment and the threadlock for garrays it hard to split appart...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
well, if you do so, it would be nice if you could think of some way of locking (possibly with a similar api like the current devel, so that i don't have to rewrite the threaded soundfiler several times) ...
and please keep the other devs informed, what you are working on, since there are few things that are worse than doing the same work 200 times to stay compatible with the current pd version ...
cheers ... tim
In general, data structures and functions from g_canvas.h are still not finalized; I think the base in m_pd.h is pretty cast in stone now.
One reason I've been resisting putting locks and stuff in g_array.c and places like that, is that I think there might still be some radical design changes needed before the thing is stable and consistent. So even if array-thread-locking went in now, all teh code that used it would have to keep changing all the time.
cheers Miller
On Tue, Nov 16, 2004 at 10:19:13PM +0100, Tim Blechmann wrote:
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
well, if you do so, it would be nice if you could think of some way of locking (possibly with a similar api like the current devel, so that i don't have to rewrite the threaded soundfiler several times) ...
and please keep the other devs informed, what you are working on, since there are few things that are worse than doing the same work 200 times to stay compatible with the current pd version ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
One reason I've been resisting putting locks and stuff in g_array.c and places like that, is that I think there might still be some radical design changes needed before the thing is stable and consistent. So even if array-thread-locking went in now, all teh code that used it would have to keep changing all the time.
as long as the api wouldn't change, it's shouldn't be a problem... and the locks are only a few lines of code ...
cheers ... tim
hi miller, hi devs
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
working on the threaded soundfiler again, i'm investigating possibilities to update pointers to g_arrays that are ->usedindsp ...
since the current implementation using canvas_update_dsp() possibly recompiles the dsp chain (is this correct?), i thought of a way to store the pointers to the pointers to the array in garray_getfloatarray() in struct t_array ... after the position of the array in memory changed, it's possible to update all these pointers ...
miller ... since you are also planing to work on arrays in dsp, i'm curious if you already thought of a different solution for such a problem ...
cheers ... tim
Hi all,
Well, it might be simpler to store a pointer to the t_array instead of one to the actual vector (a_vec) in the DSP routines. That way, resizing or swapping vectors could happen without re-sorting DSP, but you'd still have to re-sort ig a "t_garray" got deleted or renamed. The cost would be one additional pointer chase in each of the tabread~, tabwrite~, etc., operations.
I've almost finished my work of redesigning the garray/array business (to unify it with arrays in "structs") and hope to check it in today...
cheers Miller
On Fri, Nov 26, 2004 at 02:46:11PM +0100, Tim Blechmann wrote:
hi miller, hi devs
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
working on the threaded soundfiler again, i'm investigating possibilities to update pointers to g_arrays that are ->usedindsp ...
since the current implementation using canvas_update_dsp() possibly recompiles the dsp chain (is this correct?), i thought of a way to store the pointers to the pointers to the array in garray_getfloatarray() in struct t_array ... after the position of the array in memory changed, it's possible to update all these pointers ...
miller ... since you are also planing to work on arrays in dsp, i'm curious if you already thought of a different solution for such a problem ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Well, it might be simpler to store a pointer to the t_array instead of one to the actual vector (a_vec) in the DSP routines. That way,
yes, but it would break the compatibility with garray_getfloatarray
resizing or swapping vectors could happen without re-sorting DSP, but you'd still have to re-sort ig a "t_garray" got deleted or renamed.
hm ... i haven't checked, what happens if a t_garray will be renamed ... deleting will possibly have the same behaviour as deleting a dsp object ...
I've almost finished my work of redesigning the garray/array business (to unify it with arrays in "structs") and hope to check it in today...
i'm curious to see it ...
cheers ... tim
hi miller, hi devs ...
miller, have you been thinking about his? before introducing something to devel that breaks compatibility with stable, i'd suggest to find a common solution...
On Sun, 28 Nov 2004 11:37:34 -0800 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
Hi all,
Well, it might be simpler to store a pointer to the t_array instead of one to the actual vector (a_vec) in the DSP routines. That way, resizing or swapping vectors could happen without re-sorting DSP, but you'd still have to re-sort ig a "t_garray" got deleted or renamed. The cost would be one additional pointer chase in each of the tabread~, tabwrite~, etc., operations.
I've almost finished my work of redesigning the garray/array business (to unify it with arrays in "structs") and hope to check it in today...
cheers Miller
On Fri, Nov 26, 2004 at 02:46:11PM +0100, Tim Blechmann wrote:
hi miller, hi devs
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
working on the threaded soundfiler again, i'm investigating possibilities to update pointers to g_arrays that are ->usedindsp ...
since the current implementation using canvas_update_dsp() possibly recompiles the dsp chain (is this correct?), i thought of a way to store the pointers to the pointers to the array in garray_getfloatarray() in struct t_array ... after the position of the array in memory changed, it's possible to update all these pointers ...
miller ... since you are also planing to work on arrays in dsp, i'm curious if you already thought of a different solution for such a problem ...
cheers ... tim
i think we could declare renaming / deleting arrays as bad coding style and store the pointer to the t_array instead of t_array.a_vec in the tabX objects ... this would also mean, we should declare garray_getfloatarray deprecated...
just my 1.4142135623730951 ¢
cheers ... tim
I think this change could wait until the more urgent issues (e.g., graphics updates) get resolved, since there are perfectly adequate workarounds for people wanting to load arrays live from disk and swap them into tabx~ objects...
cheers Miller
On Thu, Jun 30, 2005 at 12:28:49PM +0200, Tim Blechmann wrote:
hi miller, hi devs ...
miller, have you been thinking about his? before introducing something to devel that breaks compatibility with stable, i'd suggest to find a common solution...
On Sun, 28 Nov 2004 11:37:34 -0800 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
Hi all,
Well, it might be simpler to store a pointer to the t_array instead of one to the actual vector (a_vec) in the DSP routines. That way, resizing or swapping vectors could happen without re-sorting DSP, but you'd still have to re-sort ig a "t_garray" got deleted or renamed. The cost would be one additional pointer chase in each of the tabread~, tabwrite~, etc., operations.
I've almost finished my work of redesigning the garray/array business (to unify it with arrays in "structs") and hope to check it in today...
cheers Miller
On Fri, Nov 26, 2004 at 02:46:11PM +0100, Tim Blechmann wrote:
hi miller, hi devs
Hmm, and on that subject, I'm making changes in garray for 0.39 that might point to a different approach to using arrays in DSP, not sure yet. I'm trying to unify "regular" (named) arrays with the ones that can appear in"scalars"... which is in turn necessary for me to make any more progress on the "data" aspect of Pd...
working on the threaded soundfiler again, i'm investigating possibilities to update pointers to g_arrays that are ->usedindsp ...
since the current implementation using canvas_update_dsp() possibly recompiles the dsp chain (is this correct?), i thought of a way to store the pointers to the pointers to the array in garray_getfloatarray() in struct t_array ... after the position of the array in memory changed, it's possible to update all these pointers ...
miller ... since you are also planing to work on arrays in dsp, i'm curious if you already thought of a different solution for such a problem ...
cheers ... tim
i think we could declare renaming / deleting arrays as bad coding style and store the pointer to the t_array instead of t_array.a_vec in the tabX objects ... this would also mean, we should declare garray_getfloatarray deprecated...
just my 1.4142135623730951 ¢
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
I think this change could wait until the more urgent issues (e.g., graphics updates) get resolved, since there are perfectly adequate workarounds for people wanting to load arrays live from disk and swap them into tabx~ objects...
well, i don't think the workaround is really elegant ... i mean we try to make pd a professional software and we are in the 21st century ...
i'd like to have a clean solution ... preferable in stable, but i on the other hand i'm not going to wait for another year, since i'd like to have a fully working system by the end of this decade, no matter if it's called pure data or pure devil ;-)
cheers ... tim
On Mon, 25 Oct 2004, Matju wrote:
I will state all of my changes on this list (even though there is already the pd-cvs list for that).
more.
s_inter.c: sys_vgui(): fixed buffer overflow
u_matju.tk: reading $(HOME)/.pd.tk
that was a few days ago. I didn't add anything after that. If devel_0_38 is going to be created this weekend then I'll wait till that is done.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
hi mathieu ....
On Mon, 25 Oct 2004, Matju wrote:
I will state all of my changes on this list (even though there is already the pd-cvs list for that).
i didn't add any of your changes to my first version of devel_0_38, since i'm not familiar with the gui code and miller changed a lot ...
s_inter.c: sys_vgui(): fixed buffer overflow
this patch for example is obsolete in 0.38 ... since miller rewrote the gui communication ...
cheers ... tim
one question ... what's the reason that you changed to font from courier-bold to tahoma- in devel_0_37?
cheers ... t
On Fri, Oct 22, 2004 at 10:27:15PM +0200, Tim Blechmann wrote:
one question ... what's the reason that you changed to font from courier-bold to tahoma- in devel_0_37?
i didnt...i had changed it in my local copy. and somehow guenter checked it in for me, to get a fix in another file. i guess when you do a cvs update or diff the server stores some data on your local revisions that the administrator can use via secret commands on sourceforge? im kind of curious myself..
cheers ... t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Hallo, carmen hat gesagt: // carmen wrote:
On Fri, Oct 22, 2004 at 10:27:15PM +0200, Tim Blechmann wrote:
one question ... what's the reason that you changed to font from courier-bold to tahoma- in devel_0_37?
i didnt...i had changed it in my local copy. and somehow guenter checked it in for me, to get a fix in another file. i guess when you do a cvs update or diff the server stores some data on your local revisions that the administrator can use via secret commands on sourceforge? im kind of curious myself..
Well, it happened in a checkin by "ix9": See http://tinyurl.com/6r6ml and http://tinyurl.com/65ahc
Probably some greedy "cvs update".
Ciao
On Oct 22, 2004, at 9:38 PM, Frank Barknecht wrote:
Hallo, carmen hat gesagt: // carmen wrote:
On Fri, Oct 22, 2004 at 10:27:15PM +0200, Tim Blechmann wrote:
one question ... what's the reason that you changed to font from courier-bold to tahoma- in devel_0_37?
i didnt...i had changed it in my local copy. and somehow guenter checked it in for me, to get a fix in another file. i guess when you do a cvs update or diff the server stores some data on your local revisions that the administrator can use via secret commands on sourceforge? im kind of curious myself..
Well, it happened in a checkin by "ix9": See http://tinyurl.com/6r6ml and http://tinyurl.com/65ahc
Probably some greedy "cvs update".
"cvs update" does nothing to the files on server, it only modifies files locally, merging if the file changed on the server and locally; or updates locally unchanged files from the server. So this was most likely a mistaken commit... shit happens...
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Oct 22, 2004, at 9:38 PM, Frank Barknecht wrote:
Probably some greedy "cvs update".
"cvs update" does nothing to the files on server, it only modifies files locally, merging if the file changed on the server and locally; or updates locally unchanged files from the server. So this was most likely a mistaken commit... shit happens...
Yes, I was intending to say: "cvs commit" actually...
Ciao
i didnt...i had changed it in my local copy. and somehow guenter checked it in for me, to get a fix in another file. i guess when you do a cvs update or diff the server stores some data on your local revisions that the administrator can use via secret commands on sourceforge? im kind of curious myself..
from the cvs change log:
From: carmen rocco ix9@users.sourceforge.net To: pd-cvs@iem.at Date: Thu, 12 Aug 2004 06:45:40 +0000 Subject: [PD-cvs] pd/src m_atom.c,1.1.1.2.2.3,1.1.1.2.2.4 u_main.tk,1.1.1.4.2.12,1.1.1.4.2.13 Reply-To: pd-list@iem.at
Update of /cvsroot/pure-data/pd/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7217
Modified Files: Tag: devel_0_37 m_atom.c u_main.tk Log Message: fixed_bug_in_shell
Index: u_main.tk
RCS file: /cvsroot/pure-data/pd/src/u_main.tk,v retrieving revision 1.1.1.4.2.12 retrieving revision 1.1.1.4.2.13 diff -C2 -d -r1.1.1.4.2.12 -r1.1.1.4.2.13 *** u_main.tk 23 Jul 2004 08:46:40 -0000 1.1.1.4.2.12 --- u_main.tk 12 Aug 2004 06:45:36 -0000 1.1.1.4.2.13
*** 268,272 **** set name [format ".help%d" $doc_number] toplevel $name ! text $name.text -relief raised -bd 2 -font -*-courier-bold--normal--12-* \ -yscrollcommand "$name.scroll set" -background white scrollbar $name.scroll -command "$name.text yview" --- 268,272 ---- set name [format ".help%d" $doc_number] toplevel $name ! text $name.text -relief raised -bd 2 -font -*-tahoma---normal--12-* \ -yscrollcommand "$name.scroll set" -background white scrollbar $name.scroll -command "$name.text yview"
this is a great example, why we should have a new devel branch for every msp release ;-)
... if no one objects, i'd go back to revision 1.1.1.4.2.12 of u_main.tk
tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
... if no one objects, i'd go back to revision 1.1.1.4.2.12 of u_main.tk
Yes, please. Tahoma is not available on standard Linux systems and no good replacement for Courier anyways (proportional vs. non-proportional...)
Ciao
-
carmen -
cr
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Matju -
Miller Puckette -
Tim Blechmann