hi everybody,
is there a reason why t_tkcmd.c exists, instead of merging that code into u_main.tk and then running the command "wish u_main.tk" ?
is there a reason why the global pd_nt exists, instead of using the global tcl_platform() that is built into tcl?
what does rtext mean? if it means "text responder", then, in turn, what does _that_ mean?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hi Mathieu,
Mathieu Bouchard wrote: ...
is there a reason why t_tkcmd.c exists, instead of merging that code into u_main.tk and then running the command "wish u_main.tk" ?
no idea, but mixing C and Tcl is usually quite natural -- does converting the socket code from C to Tcl buy anything?
...
is there a reason why the global pd_nt exists, instead of using the global tcl_platform() that is built into tcl?
this variable was introduced in tcl 8.4, mspd still uses 8.3...
Krzysztof
On Thursday, Apr 8, 2004, at 04:02 America/New_York, Mathieu Bouchard wrote:
hi everybody,
is there a reason why t_tkcmd.c exists, instead of merging that code into u_main.tk and then running the command "wish u_main.tk" ?
Being able to run "wish u_main.tk" would actually be really helpful to app to make a proper MacOS X .app. So unless it breaks things, I am for it.
With all of these changes that you are making, its going to be hard to get them merged into the core. Do you have any plans to break out the changes into individual patches, maybe, to make it more palettable? It would be a shame to see your code turn into a permanent fork or not get used.
.hc
is there a reason why the global pd_nt exists, instead of using the global tcl_platform() that is built into tcl?
what does rtext mean? if it means "text responder", then, in turn, what does _that_ mean?
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it."
- Thomas Jefferson
is there a reason why t_tkcmd.c exists, instead of merging that code into u_main.tk and then running the command "wish u_main.tk" ?
Being able to run "wish u_main.tk" would actually be really helpful to app to make a proper MacOS X .app. So unless it breaks things, I am for it.
it would help to decouple the gui from the dsp code as well. no idea how far it is, but some day they should run separately right ?
On Fri, 9 Apr 2004, 0001 wrote:
is there a reason why t_tkcmd.c exists, instead of merging that code into u_main.tk and then running the command "wish u_main.tk" ?
Being able to run "wish u_main.tk" would actually be really helpful to app to make a proper MacOS X .app. So unless it breaks things, I am for it.
it would help to decouple the gui from the dsp code as well. no idea how far it is, but some day they should run separately right ?
What do you think I've been working on since over a month? Surely it ain't just adding colours and bevels and fluff. ;-) I'm trying to turn Pd's GUI into a Model/View kind of design, where the View part is all in the pd-gui (TCL) process, so effectively that would make the GUI rendering/event-handling in a different thread than the message/dsp systems. The communication between the two parts would eventually become rather minimal, instead of the current situation of having the TCL process be a dumb, passive slave.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Thu, 8 Apr 2004, Hans-Christoph Steiner wrote:
Being able to run "wish u_main.tk" would actually be really helpful to app to make a proper MacOS X .app. So unless it breaks things, I am for it.
Cool, I may attempt that eventually.
With all of these changes that you are making, its going to be hard to get them merged into the core.
I know that.
Do you have any plans to break out the changes into individual patches, maybe, to make it more palettable?
I am afraid I can't make it more palatable for most of the changes. The main reason is that the GUI changes are actually a gradual rewrite of the whole of IEMGUI, and then I'm also changing the base Pd GUI as well, and turning it into something quite completely different code-wise that just will happen to be 99% compatible with the old one. Look at pd_upload() and sys_mgui() and u_object.tk for examples of what I'm going towards...
It would be a shame to see your code turn into a permanent fork
I won't personally do the big work on the devel<->impd merging, but I am certainly not against it, whenever impd gets back to stable enough.
or not get used.
And according to you, why wouldn't a lot of people switch to the impd branch? especially if it gets to beta and gets exported and released and binaries are available...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Friday, Apr 9, 2004, at 16:06 America/New_York, Mathieu Bouchard wrote:
On Thu, 8 Apr 2004, Hans-Christoph Steiner wrote:
Being able to run "wish u_main.tk" would actually be really helpful to app to make a proper MacOS X .app. So unless it breaks things, I am for it.
Cool, I may attempt that eventually.
With all of these changes that you are making, its going to be hard to get them merged into the core.
I know that.
Do you have any plans to break out the changes into individual patches, maybe, to make it more palettable?
I am afraid I can't make it more palatable for most of the changes. The main reason is that the GUI changes are actually a gradual rewrite of the whole of IEMGUI, and then I'm also changing the base Pd GUI as well, and turning it into something quite completely different code-wise that just will happen to be 99% compatible with the old one. Look at pd_upload() and sys_mgui() and u_object.tk for examples of what I'm going towards...
It would be a shame to see your code turn into a permanent fork
I won't personally do the big work on the devel<->impd merging, but I am certainly not against it, whenever impd gets back to stable enough.
or not get used.
And according to you, why wouldn't a lot of people switch to the impd branch? especially if it gets to beta and gets exported and released and binaries are available...
For me, a some key things don't work with impd, like [tot] IIRC. And if Miller's changes aren't maintained in impd, then there would be a fork. Already, a bunch of useful stuff has been forgotten in the devel_0_36 branch, for whatever reason.
.hc
________________________________________________________________________ ____
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
On Fri, 9 Apr 2004, Hans-Christoph Steiner wrote:
For me, a some key things don't work with impd, like [tot] IIRC.
Well, impd is currently very much unstable anyway, so when I actually decide to make a release, then why not report that [tot] doesn't work and actually tell me how to test for the problem and then maybe i'll know what to fix.
And if Miller's changes aren't maintained in impd, then there would be a fork.
That's a pretty strange definition of fork. Maybe that's the slashdot definition of fork, I mean with the "bad, evil" connotations. To me, a branch and a fork are the same thing. Whether there is collaboration/osmosis between the branches is a separate issue.
That said, I'm not going to put the burden of merging Miller's/devel's changes into impd, as it's already enough job to just get my changes working. I mean essentially I am rewriting pretty much all of the gui code and it's long enough that I can't afford to further slow myself down. Given the interest that impd generates, why wouldn't another developer actually handle that task?
Already, a bunch of useful stuff has been forgotten in the devel_0_36 branch, for whatever reason.
Well, if this is so much of an issue, then why don't you post the ChangeLog of the forgotten features ? and then developers would either patch devel/impd using old diffs, or reimplement the features in terms of the new codebase.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Thursday, Apr 15, 2004, at 10:03 America/New_York, Mathieu Bouchard wrote:
On Fri, 9 Apr 2004, Hans-Christoph Steiner wrote:
For me, a some key things don't work with impd, like [tot] IIRC.
Well, impd is currently very much unstable anyway, so when I actually decide to make a release, then why not report that [tot] doesn't work and actually tell me how to test for the problem and then maybe i'll know what to fix.
It would be great to have a bug tracker for this.
And if Miller's changes aren't maintained in impd, then there would be a fork.
That's a pretty strange definition of fork. Maybe that's the slashdot definition of fork, I mean with the "bad, evil" connotations. To me, a branch and a fork are the same thing. Whether there is collaboration/osmosis between the branches is a separate issue.
I think most people consider a fork like emacs vs. xemacs. Any decent sized development project has branches ( i.e. stable, release, devel, etc.), but not necessarily forks.
That said, I'm not going to put the burden of merging Miller's/devel's changes into impd, as it's already enough job to just get my changes working. I mean essentially I am rewriting pretty much all of the gui code and it's long enough that I can't afford to further slow myself down. Given the interest that impd generates, why wouldn't another developer actually handle that task?
Well, we all hope more people step up and work on making Pd better, but that doesn't happen as often as we'd like.
Already, a bunch of useful stuff has been forgotten in the devel_0_36 branch, for whatever reason.
Well, if this is so much of an issue, then why don't you post the ChangeLog of the forgotten features ? and then developers would either patch devel/impd using old diffs, or reimplement the features in terms of the new codebase.
In the world of unlimited time where I did not need to sleep, this would have happened already. Unfortunately, my body fights me when I start sleeping less that 5 hours a night. My guess is that most people are probably in this boat also.
.hc
hi all,
That said, I'm not going to put the burden of merging Miller's/devel's changes into impd, as it's already enough job to just get my changes working. I mean essentially I am rewriting pretty much all of the gui code and it's long enough that I can't afford to further slow myself down. Given the interest that impd generates, why wouldn't another developer actually handle that task?
Well, we all hope more people step up and work on making Pd better, but that doesn't happen as often as we'd like.
i suppose there are a few developers out there, who might be interested in doing something to improve pd, but simply don't know, where to start / what to do / who to address ... that's a problem, because miller is working on his own, not on the cvs, some guys are working on the devel branch and mathieu working on the impd branch ... but shouldn't we be able to solve this by _actively_ using source-forge's feature request / bug tracking system? i mean, we could start with adding miller's todo list (is it up to date?) and try to find a few people to work some of the tasks ... i don't think it's very useful if miller and mathieu are working on their branches on their own (?) and a few guys adding code to the devel branch every time a new stable release comes up ...
And if Miller's changes aren't maintained in impd, then there
would> be a fork.
That's a pretty strange definition of fork. Maybe that's the slashdot definition of fork, I mean with the "bad, evil" connotations. To me, a branch and a fork are the same thing. Whether there is collaboration/osmosis between the branches is a separate issue.
I think most people consider a fork like emacs vs. xemacs. Any decent sized development project has branches ( i.e. stable, release, devel, etc.), but not necessarily forks.
the problem of pd being a work in progress is, that it should be both usable and being developed at the same time ... it's not always necessary to branch between certainain versions, but sometimes it might be better to use compile flags / preprocessor macros to distingush between two different implementations ... mathieu, i don't know if this would work for what you are doing with impd, but for my taste it's better to have twice as much code and to be able to merge some of your changes to future "stable" releases ...
just my 2.5 ¢ ... cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
On Thursday, Apr 15, 2004, at 14:08 America/New_York, Tim Blechmann wrote:
hi all,
That said, I'm not going to put the burden of merging Miller's/devel's changes into impd, as it's already enough job to just get my changes working. I mean essentially I am rewriting pretty much all of the gui code and it's long enough that I can't afford to further slow myself down. Given the interest that impd generates, why wouldn't another developer actually handle that task?
Well, we all hope more people step up and work on making Pd better, but that doesn't happen as often as we'd like.
i suppose there are a few developers out there, who might be interested in doing something to improve pd, but simply don't know, where to start / what to do / who to address ... that's a problem, because miller is working on his own, not on the cvs, some guys are working on the devel branch and mathieu working on the impd branch ... but shouldn't we be able to solve this by _actively_ using source-forge's feature request / bug tracking system? i mean, we could start with adding miller's todo list (is it up to date?) and try to find a few people to work some of the tasks ... i don't think it's very useful if miller and mathieu are working on their branches on their own (?) and a few guys adding code to the devel branch every time a new stable release comes up ...
I wholeheartedly agree. This sounds like an great idea. There is a lack of organization, but that's not necessarily a problem. Currently, the way things work is that people do things that they are motivated to do, and generally make sure they are not stepping on any toes. It seems to have worked pretty well so far. Its kind of like coordinated disorganization.
.hc
And if Miller's changes aren't maintained in impd, then there
would> be a fork.
That's a pretty strange definition of fork. Maybe that's the slashdot definition of fork, I mean with the "bad, evil" connotations. To me, a branch and a fork are the same thing. Whether there is collaboration/osmosis between the branches is a separate issue.
I think most people consider a fork like emacs vs. xemacs. Any decent sized development project has branches ( i.e. stable, release, devel, etc.), but not necessarily forks.
the problem of pd being a work in progress is, that it should be both usable and being developed at the same time ... it's not always necessary to branch between certainain versions, but sometimes it might be better to use compile flags / preprocessor macros to distingush between two different implementations ... mathieu, i don't know if this would work for what you are doing with impd, but for my taste it's better to have twice as much code and to be able to merge some of your changes to future "stable" releases ...
just my 2.5 ¢ ... cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On Thu, 15 Apr 2004, Tim Blechmann wrote:
but shouldn't we be able to solve this by _actively_ using source-forge's feature request / bug tracking system?
agreed. we first get the users to talk and _then_ we figure out who that is addressed to... else it's too much "bureaucracy" for the user.
i don't think it's very useful if miller and mathieu are working on their branches on their own (?) and a few guys adding code to the devel branch every time a new stable release comes up ...
Well, it is useful, but it's just not optimal. That might be a problem firstly with how much activity is going on inside the devel branch, not a problem of communication between devel guys and the community.
the problem of pd being a work in progress is, that it should be both usable and being developed at the same time ...
that's an important principle of Extreme Programming (X-P) methodology... that the work is always in progress and ready to move forward and ready to be used.
mathieu, i don't know if this would work for what you are doing with impd, but for my taste it's better to have twice as much code and to be able to merge some of your changes to future "stable" releases ...
I really value tight code, I mean conceptually tight code, as they do in the X-P methodology, because that's code that is more ready to move forward (OnceAndOnlyOnce principle, aka DontRepeatYourself). And I think that it's not going to be a factor of two in the end, more like a factor of three or four, and that really weighs in the balance, because of increased ability to make quick changes. (but even a factor of two _is_ quite significant; in this case anyway)
Now according to X-P what I'm doing is bad because the code is not ready to use in the middle of my changes (and worse, for several weeks straight), but the way I justify it is that the incremental redesign that X-P mandates (to keep the code more ready to move forward) doesn't seem to have been done quite enough with Pd, so I'm trying to catch up.
Being able to merge some of my changes with future "stable" releases isn't a priority, from the moment people can access the Impd binaries. Of course it would be nice if the devel branch would merge some of my changes, but I'm not waiting for that because I could be waiting till 2006 and then it would slow me down on many of my changes.
To me, patience is a virtue when it actually helps, not when it hinders; maybe some devel folks would like to get my features for free, so my patience would actually help them, but my IMpatience would help pretty much everyone else instead, so... the choice is easy to do.
just my 2.5 ¢ ... cheers...
oh my. that's after the inflation indexing? or is that after tax? times are a-changing...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
but shouldn't we be able to solve this by _actively_ using source-forge's feature request / bug tracking system?
agreed. we first get the users to talk and _then_ we figure out who that is addressed to... else it's too much "bureaucracy" for the user.
it might add some bureaucracy, but it will be easier to follow, what actually is going on ... that's not the case ATM ...
Being able to merge some of my changes with future "stable" releases isn't a priority, from the moment people can access the Impd binaries. Of course it would be nice if the devel branch would merge some of my changes, but I'm not waiting for that because I could be waiting till 2006 and then it would slow me down on many of my changes.
what are your plans for impd? i mean, do you plan a second branch independant from miller's / devel starting with 0.37 or will you try to create a patchset from your changes that will more or less apply to miller's future stable releases?
To me, patience is a virtue when it actually helps, not when it hinders; maybe some devel folks would like to get my features for free, so my patience would actually help them, but my IMpatience would help pretty much everyone else instead, so... the choice is easy to do.
*g* ... but on the other hand if the developers have the patience to talk to each other once about what way pd should go, set up a todo list and distribute the tasks on several developers, we might get pd to 1. develop faster (although there is a small overhead at the beginning) 2. find bugs earlier 3. avoid forks that are difficult / impossible to merge again 4. ???
as hans-christoph pointed out ... right now it worked pretty well with what he called coordinated disorganization ... but organizing it a bit more would probably make the developement of pd much easier and efficient ...
maybe we should change the intention of the branches ... take the devel branch as stable branch with only X-P changes / patches, and impd as developing / unstable branch that might not be usable until it becomes stable and miller's as release branch ...
just my 2.5 ¢ ... cheers...
oh my. that's after the inflation indexing? or is that after tax? times are a-changing...
exchange rate - euro / dollar ;-)
cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
On Sat, 17 Apr 2004, Tim Blechmann wrote:
but shouldn't we be able to solve this by _actively_ using source-forge's feature request / bug tracking system?
agreed. we first get the users to talk and _then_ we figure out who that is addressed to... else it's too much "bureaucracy" for the user.
it might add some bureaucracy, but it will be easier to follow, what actually is going on ... that's not the case ATM ...
What I meant by bureaucracy is not that... I mean that reporting a bug currently exposes the user to having to figure out who's in charge, and it's often not obvious; it's like walking from office to office to get told that you should ask someone else. And then they have to follow up to make sure someone is actually taking care of the issue instead of just letting it slip through the mailinglist archives.
The "paperwork" of the bug tracking system shifts the bureaucracy towards the developers and away from the users, and hopefully shrinking it down a bit.
Maybe that would work better when there is only one branch, instead of three... I dunno, does Sourceforget's support reporting a bug once and solving it separately for three branches?
what are your plans for impd? i mean, do you plan a second branch independant from miller's / devel starting with 0.37 or will you try to create a patchset from your changes that will more or less apply to miller's future stable releases?
I won't do anything relative to Miller's releases. I will only work relative to devel_0_37. Even then, the patchset is looking more and more like just copying my g_*.c over devel's...
but on the other hand if the developers have the patience to talk to each other once about what way pd should go,
My intentions regarding Pd are embodied by my cvs-commits; but for a succinct summary,
* I think the current Pd GUI code should go away completely,
* that the client/server should be properly decoupled,
* that a model/view architecture is the way to achieve that,
* that it ought to be easy for people fluent in C/Tcl/Tk to write Pd GUI externals using a published API.
- develop faster (although there is a small overhead at the beginning)
- find bugs earlier
- avoid forks that are difficult / impossible to merge again
- ???
5. profit!
:-}
maybe we should change the intention of the branches ... take the devel branch as stable branch with only X-P changes / patches, and impd as developing / unstable branch that might not be usable until it becomes stable and miller's as release branch ...
Sounds good, why not...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Thu, 15 Apr 2004, Hans-Christoph Steiner wrote:
On Fri, 9 Apr 2004, Hans-Christoph Steiner wrote:
For me, a some key things don't work with impd, like [tot] IIRC.
Well, impd is currently very much unstable anyway, so when I actually decide to make a release, then why not report that [tot] doesn't work
It would be great to have a bug tracker for this.
Maybe, yeah, but I think it's more of a case of impd changing too fast for the formal reporting process to be worth anything. Bugs are likely to pop up and disappear on a daily basis... especially because 90% of the gui code is changing.
I think most people consider a fork like emacs vs. xemacs. Any decent sized development project has branches ( i.e. stable, release, devel, etc.), but not necessarily forks.
Okay. Well, apart from the pd/src/[gu]_* files, the code remains 99% the same, so Miller's/devel's changes still can be ported easily, as they usually don't involve pd/src/[gu]_* files...
And anyway, if they do, then it's usually easier to implement a GUI feature in Impd than in Pd, so I don't mind rewriting the code.
(Btw: look at the inlet tooltips in Impd... neater-looking than Pd's, eh?)
Well, we all hope more people step up and work on making Pd better, but that doesn't happen as often as we'd like.
Well, given that the merging of diffs can happen later, and that the incentive to do that job will increase as the time goes, I guess I can simply wait and do my GUI stuff and so increase the incentive for someone else to do the merging of diffs.
Well, if this is so much of an issue, then why don't you post the ChangeLog of the forgotten features ? and then developers would either patch devel/impd using old diffs, or reimplement the features in terms of the new codebase.
In the world of unlimited time where I did not need to sleep, this would have happened already. Unfortunately, my body fights me when I start sleeping less that 5 hours a night. My guess is that most people are probably in this boat also.
Oh well. So those changes are not _that_ critical, then? So whenever someone gets the time and incentive, that person digs out that list and we decide what to do with it on Pd and Impd, 0.37.
I don't have unlimited time either, mind you =)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hi,
I think tot goes fine with impd (widgets are also fine, in linux, of course). The only problem are some scriptlets which do indeed confuse impd, if put in message boxes.
This is not a tot problem, but impd problem, which might equally well get confused by someone writing '"toy".' (i.e. a double-quote followed by a dot), into a message box... Perhaps, pd_upload() should protect each atom's text by putting it inside curly braces?
Krzysztof
Btw, tot is just a small hack, which can be rewritten easily, if in need of adjusting it to the core.
Mathieu Bouchard wrote: ...
For me, a some key things don't work with impd, like [tot] IIRC.
...
decide to make a release, then why not report that [tot] doesn't work and actually tell me how to test for the problem and then maybe i'll know what to fix.