Hi all, as i am new to TCL/TK, i encounter problems with it all the time.
Here is a simple example, the creation of two rectangles (please don't mind the strange specifiers... they are generated from pointer values)
-----------------
.x8ff8c8.c create rectangle 69 64 169 164 -tags ec0858GUI -width 2 -fill #00ff00 -outline #00ff00 .x8ff8c8.c create rectangle 89 84 139 134 -tags ec08c8GUI -fill #0000ff
that's just ok... the second (slightly smaller one) is displayed on top of the first one.
-------------------
Now, i'd like to add an additional tag (ec0728GRP) to each of them, to e.g. move them with a single command
.x8ff8c8.c create rectangle 69 64 169 164 -tags ec0858GUI -width 2 -fill #00ff00 -outline #00ff00 .x8ff8c8.c addtag ec0728GRP withtag ec0858GUI .x8ff8c8.c create rectangle 89 84 139 134 -tags ec08c8GUI -fill #0000ff .x8ff8c8.c addtag ec0728GRP withtag ec08c8GUI
Now, only the first (larger) one is visible... why?
------------------------------
many thanks, Thomas
Hi all, here's a self reply: that was some trivial error, but it's not visible in the mail, though. I forgot the "\n" at the end of the tag commands.....
grüßsie Thomas
----- Original Message ----- From: "Thomas Grill" t.grill@gmx.net To: "pd-dev" pd-dev@iem.kug.ac.at Sent: Thursday, August 22, 2002 1:13 AM Subject: [PD-dev] TCL/TK tags
Hi all, as i am new to TCL/TK, i encounter problems with it all the time.
Here is a simple example, the creation of two rectangles (please don't mind the strange specifiers... they are generated from
pointer
values)
.x8ff8c8.c create rectangle 69 64 169 164 -tags ec0858GUI -width 2 -fill #00ff00 -outline #00ff00 .x8ff8c8.c create rectangle 89 84 139 134 -tags ec08c8GUI -fill #0000ff
that's just ok... the second (slightly smaller one) is displayed on top of the first one.
Now, i'd like to add an additional tag (ec0728GRP) to each of them, to
e.g.
move them with a single command
.x8ff8c8.c create rectangle 69 64 169 164 -tags ec0858GUI -width 2 -fill #00ff00 -outline #00ff00 .x8ff8c8.c addtag ec0728GRP withtag ec0858GUI .x8ff8c8.c create rectangle 89 84 139 134 -tags ec08c8GUI -fill #0000ff .x8ff8c8.c addtag ec0728GRP withtag ec08c8GUI
Now, only the first (larger) one is visible... why?
many thanks, Thomas
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi all,
The tarball snapshot at pure-data.souceforge.net is a bit strange. All the file-names have an additional ",v" suffix, and there is CVS info in the files themselves. That is not very useful. Can something be done, so that the tarball has just the normal files?
Gerard
hmm, the tarball is a service from sourceforge, so I think that can not be changed, sorry. (I didn't know that this is actually a tarball of the CVS tree).
It is not very useful to download the tarball anyhow, it would be much more useful to checkout from the CVS directly (at least in the state the CVS is in currently).
Guenter
On Tue, 5 Nov 2002, vanDongen-Gilcher wrote:
Hi all,
The tarball snapshot at pure-data.souceforge.net is a bit strange. All the file-names have an additional ",v" suffix, and there is CVS info in the files themselves. That is not very useful. Can something be done, so that the tarball has just the normal files?
Gerard
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
but you can extract it with winCVS ( I can't exactely remember how, but something like you have to set the cvsroot to the local directory you expanded the files to) Michael
At 14:05 05.11.02, you wrote:
hmm, the tarball is a service from sourceforge, so I think that can not be changed, sorry. (I didn't know that this is actually a tarball of the CVS tree).
It is not very useful to download the tarball anyhow, it would be much more useful to checkout from the CVS directly (at least in the state the CVS is in currently).
Guenter
On Tue, 5 Nov 2002, vanDongen-Gilcher wrote:
Hi all,
The tarball snapshot at pure-data.souceforge.net is a bit strange. All the file-names have an additional ",v" suffix, and there is CVS info in the files themselves. That is not very useful. Can something be done, so that the tarball has just the normal files?
Gerard
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Michael Iber
http://www.iberspace.de mailto://mail@iber-online.de
On Tue, 5 Nov 2002, Michael Iber wrote:
but you can extract it with winCVS ( I can't exactely remember how, but something like you have to set the cvsroot to the local directory you expanded the files to) Michael
Thats true, but still there is the question why someone wants to do this. I can imagine two reasons:
- you want to download and install all the externals in one go. (This is actually one goal of the CVS, to have everything together). The problem is that this should be done based on releases, and not using the tarball. (It was a bd idea to put the link there).
- there is a feature in CVS that is missing in the current release of the external (THis means we shoudl hurry up to make a release as soon as possible)
We, (the developers that put the code into CVS), have still to find a way to work on this together. If we are not able to do this in the long run, the CVS is pretty useless.
Also, it would be really great if those who are working on OSX, or those who encounter problems with compiling/using the externals could participate actively, by either becoming a developer, or by asking at the list to add there changes.
Greeting,
GUenter
At 14:05 05.11.02, you wrote:
hmm, the tarball is a service from sourceforge, so I think that can not be changed, sorry. (I didn't know that this is actually a tarball of the CVS tree).
It is not very useful to download the tarball anyhow, it would be much more useful to checkout from the CVS directly (at least in the state the CVS is in currently).
Guenter
On Tue, 5 Nov 2002, vanDongen-Gilcher wrote:
Hi all,
The tarball snapshot at pure-data.souceforge.net is a bit strange. All the file-names have an additional ",v" suffix, and there is CVS info in the files themselves. That is not very useful. Can something be done, so that the tarball has just the normal files?
Gerard
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Michael Iber
http://www.iberspace.de mailto://mail@iber-online.de
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 6 Nov 2002, guenter geiger wrote:
Also, it would be really great if those who are working on OSX, or those who encounter problems with compiling/using the externals could participate actively, by either becoming a developer, or by asking at the list to add there changes.
I will be working on Linux-PowerPC and OS X so I would love to contribute fixes for things. My hesitation comes from not wanting to step on people's toes or make changes to someone's externals without them approving.
So this led me to look into access control for CVS. I think it could be helpful, especially during this transistion period, to set up access lists on various parts of pure-data.sf.net. That way, for example, MSP could use the SF CVS before he is prepared to have multiple developers working on that code. Also, it might make some developers more willing to put their code up on CVS if they know that they don't lose control of it when they do so.
.hc
zen \ \ \[D[D[D[D
|On Wed, 6 Nov 2002, guenter geiger wrote: |> |> Also, it would be really great if those who are working on OSX, or |> those who encounter problems with compiling/using the externals could |> participate actively, by either becoming a developer, or by asking |> at the list to add there changes. |> | |I will be working on Linux-PowerPC and OS X so I would love to contribute |fixes for things. My hesitation comes from not wanting to step on |people's toes or make changes to someone's externals without them approving.
these considerations are polite but have to be put aside when you want to actually change something (like a file). ;)
some changes (like adding ifdefs ) can be done i think without the original authors approval?
if you re going to completey change what a given function does, maybe this should be negotiated.
if things break, you can resurrect earlier versions, another handy feature of versioning systems..
it is about _making changes_ ..
|So this led me to look into access control for CVS. I think it could be |helpful, especially during this transistion period, to set up access lists |on various parts of pure-data.sf.net. That way, for example, MSP could |use the SF CVS before he is prepared to have multiple developers working |on that code. Also, it might make some developers more willing to put |their code up on CVS if they know that they don't lose control of it when |they do so.
whats this fear of losing control? why is everyone publishing under gpl or something similar then?
the cvs is not the only place to store things, people also have private harddisks etc. if i m not happy with the way something works, clone it, rename it, hide it or re-publish it, whatever .. the whole point of open source licensing, again?
bst, x_j
whats this fear of losing control? why is everyone publishing under gpl or something similar then?
the cvs is not the only place to store things, people also have private harddisks etc. if i m not happy with the way something works, clone it, rename it, hide it or re-publish it, whatever .. the whole point of open source licensing, again?
Sure, anyone can edit the sources to the linux kernel. But there is only one person who actually says yes or no to what goes into the official kernel. (OK, probably more than one these days). This is the control that I am speaking of. Most open source projects have such overseers. We want to encourage people to keep the 'official' version of their code on the pure-data.sf.net CVS, that is why I think this option is important.
Plus if we just have a free-for-all development, there is a danger of chaos and the need to constantly rollback changes that people made to software they didn't really know enough about. Permissions/access controls are excellent tools for preventing mistakes.
.hc
zen \ \ \[D[D[D[D
i just want to reinforce hans' point here, if you look into big projects like GNOME, every little module in the CVS has a maintainer, if you want to make a change to the module they own, you need to ask for explicit permission, if a coder is spending a lot of time on one module, the owner usually grants them permission to commit at their own will. this works really well at keeping the CVS tree in a sane state at any one time.
-joschi
On Wed, 2002-11-06 at 13:37, Hans-Christoph Steiner wrote:
whats this fear of losing control? why is everyone publishing under gpl or something similar then?
the cvs is not the only place to store things, people also have private harddisks etc. if i m not happy with the way something works, clone it, rename it, hide it or re-publish it, whatever .. the whole point of open source licensing, again?
Sure, anyone can edit the sources to the linux kernel. But there is only one person who actually says yes or no to what goes into the official kernel. (OK, probably more than one these days). This is the control that I am speaking of. Most open source projects have such overseers. We want to encourage people to keep the 'official' version of their code on the pure-data.sf.net CVS, that is why I think this option is important.
Plus if we just have a free-for-all development, there is a danger of chaos and the need to constantly rollback changes that people made to software they didn't really know enough about. Permissions/access controls are excellent tools for preventing mistakes.
.hc
zen \ \ \[D[D[D[D
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
good morning,
my two cents, see below...
On 6 November 2002 at 21:13:28, _-¯-_ wrote:
|On Wed, 6 Nov 2002, guenter geiger wrote: |> |> Also, it would be really great if those who are working on OSX, or |> those who encounter problems with compiling/using the externals could |> participate actively, by either becoming a developer, or by asking |> at the list to add there changes. |> | |I will be working on Linux-PowerPC and OS X so I would love to contribute |fixes for things. My hesitation comes from not wanting to step on |people's toes or make changes to someone's externals without them approving.
these considerations are polite but have to be put aside when you want to actually change something (like a file). ;)
some changes (like adding ifdefs ) can be done i think without the original authors approval?
if you re going to completey change what a given function does, maybe this should be negotiated.
yup, yup, and also yup -- provided the external is being actively maintained, which assumedly it is, if someone put it into cvs in the first place...
i haven't yet heard of any "malicious" (undeclared) changes to anyone's code in the cvs tree -- (the only thing that comes close is my own oops in creating a badly-named external, and the resultant dead directory); in short, i think we can rely on convention and consideration on the part of external developers that no one will actually go and alter someone else's code without at least first asking...
marmosets, Bryan
On Thu, Nov 07, 2002 at 01:07:39AM +0100, Bryan Jurish wrote:
good morning,
my two cents, see below...
On 6 November 2002 at 21:13:28, _-?-_ wrote:
|On Wed, 6 Nov 2002, guenter geiger wrote: |> |> Also, it would be really great if those who are working on OSX, or |> those who encounter problems with compiling/using the externals could |> participate actively, by either becoming a developer, or by asking |> at the list to add there changes. |> | |I will be working on Linux-PowerPC and OS X so I would love to contribute |fixes for things. My hesitation comes from not wanting to step on |people's toes or make changes to someone's externals without them approving.
these considerations are polite but have to be put aside when you want to actually change something (like a file). ;)
some changes (like adding ifdefs ) can be done i think without the original authors approval?
if you re going to completey change what a given function does, maybe this should be negotiated.
yup, yup, and also yup -- provided the external is being actively maintained, which assumedly it is, if someone put it into cvs in the first place...
i haven't yet heard of any "malicious" (undeclared) changes to anyone's code in the cvs tree -- (the only thing that comes close is my own oops in creating a badly-named external, and the resultant dead directory); in short, i think we can rely on convention and consideration on the part of external developers that no one will actually go and alter someone else's code without at least first asking...
[perhaps stating the obvious] Infact, I'd say that the whole basis of open source development is about social protocols rather than programatic protocols. Anyone could take the sources to the Linux kernel or Pd and rename it to "McCormix" or "unpure-data" a lot like what happened with Xemacs. But as long as the project has good maintainership like Miller or Linus provide, people will continue to follow correct social protocol and defer their additions/modifications of the source to that central maintainer. In a way this is the perfect blend of democracy and socialism. If only we could design the code of governance and law in the same way maybe we'd live in a utopia. That or total anarchy, which might be just as fun. [/perhaps]
Regards,
Chris.
_________________________________ chris@mccormick.cx http://www.mccormick.cx http://www.sciencegirlrecords.com
On Thu, 7 Nov 2002, Chris McCormick wrote:
[perhaps stating the obvious] Infact, I'd say that the whole basis of open source development is about social protocols rather than programatic protocols. Anyone could take the sources to the Linux kernel or Pd and rename it to "McCormix" or "unpure-data" a lot like what happened with Xemacs. But as long as the project has good maintainership like Miller or Linus provide, people will continue to follow correct social protocol and defer their additions/modifications of the source to that central maintainer. In a way this is the perfect blend of democracy and socialism. If only we could design the code of governance and law in the same way maybe we'd live in a utopia. That or total anarchy, which might be just as fun. [/perhaps]
hola,
this is very similar to what I wanted to say. I am pretty sure we have a social control system already in place so we do not need additional control.
On the other hand I think it is better to have as many externals in place as possible, so if someone really feels a need for more control, go ahead and implement it for your externals (or .. ask me for permissions, tell me how to do it etc ...)
I will not have time for this before next tuesday though ...
Greetings
Guenter
Hello.
Currently I'm not a real PD developer but I would be happy if the owners of modules on the CVS PD repository would state clearly what is the procedure for working on their code or submit patches or whatever policy they like and feel confortable with.
They could write a message here and copy it on a file in the main directory of their modules.
It's sort of description of your toes, so to speak.
Thanks.
Maurizio Umberto Puxeddu.
On Thu, 7 Nov 2002, guenter geiger wrote:
On Thu, 7 Nov 2002, Chris McCormick wrote:
[perhaps stating the obvious] Infact, I'd say that the whole basis of open source development is about social protocols rather than programatic protocols. Anyone could take the sources to the Linux kernel or Pd and rename it to "McCormix" or "unpure-data" a lot like what happened with Xemacs. But as long as the project has good maintainership like Miller or Linus provide, people will continue to follow correct social protocol and defer their additions/modifications of the source to that central maintainer. In a way this is the perfect blend of democracy and socialism. If only we could design the code of governance and law in the same way maybe we'd live in a utopia. That or total anarchy, which might be just as fun. [/perhaps]
hola,
this is very similar to what I wanted to say. I am pretty sure we have a social control system already in place so we do not need additional control.
On the other hand I think it is better to have as many externals in place as possible, so if someone really feels a need for more control, go ahead and implement it for your externals (or .. ask me for permissions, tell me how to do it etc ...)
I will not have time for this before next tuesday though ...
Greetings
Guenter
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Great idea. This could also serve as a central place to look up maintainers/creators of various parts of pd, externs, docs, etc.
.hc
On Thu, 7 Nov 2002, Maurizio Umberto Puxeddu wrote:
Hello.
Currently I'm not a real PD developer but I would be happy if the owners of modules on the CVS PD repository would state clearly what is the procedure for working on their code or submit patches or whatever policy they like and feel confortable with.
They could write a message here and copy it on a file in the main directory of their modules.
It's sort of description of your toes, so to speak.
Thanks.
Maurizio Umberto Puxeddu.
On Thu, 7 Nov 2002, guenter geiger wrote:
On Thu, 7 Nov 2002, Chris McCormick wrote:
[perhaps stating the obvious] Infact, I'd say that the whole basis of open source development is about social protocols rather than programatic protocols. Anyone could take the sources to the Linux kernel or Pd and rename it to "McCormix" or "unpure-data" a lot like what happened with Xemacs. But as long as the project has good maintainership like Miller or Linus provide, people will continue to follow correct social protocol and defer their additions/modifications of the source to that central maintainer. In a way this is the perfect blend of democracy and socialism. If only we could design the code of governance and law in the same way maybe we'd live in a utopia. That or total anarchy, which might be just as fun. [/perhaps]
hola,
this is very similar to what I wanted to say. I am pretty sure we have a social control system already in place so we do not need additional control.
On the other hand I think it is better to have as many externals in place as possible, so if someone really feels a need for more control, go ahead and implement it for your externals (or .. ask me for permissions, tell me how to do it etc ...)
I will not have time for this before next tuesday though ...
Greetings
Guenter
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
zen \ \ \[D[D[D[D
On Thu, 7 Nov 2002, Chris McCormick wrote:
Infact, I'd say that the whole basis of open source development is about social protocols rather than programatic protocols. Anyone could take the sources to the Linux kernel or Pd and rename it to "McCormix" or "unpure-data" a lot like what happened with Xemacs. But as long as the project has good maintainership like Miller or Linus provide, people will continue to follow correct social protocol and defer their additions/modifications of the source to that central maintainer. In a way this is the perfect blend of democracy and socialism. If only we could design the code of governance and law in the same way maybe we'd live in a utopia. That or total anarchy, which might be just as fun. [/perhaps]
Sure, but on the large, successful projects, those social protocols are enforced by maintainers. Look at how Linux, Debian, GNOME, KDE, GNUstep, etc. etc. ad nasuem work. They are all broken up into sections with maintainers controling each section and permissions to enforce that.
If you don't have permissions to edit a file, then you submit a diff to the maintainter. If you start doing a lot of work on a section, then the maintainer gives you access. Alan Cox is the perfect example of this. But I think that even Alan Cox doesn't have full access to the linux sources (I could be wrong).
I am not advocating this because I want to see pure-data carved up into little fiefdoms. This is a tried and true structure for developing software with many developers contributing. Plus it could help MSP to get the pd code into CVS sooner, since he could work off of CVS alone, without having to develop the test suite needed to allow multiple developers.
.hc
zen \ \ \[D[D[D[D
On Wed, 6 Nov 2002, guenter geiger wrote:
Hi all,
We, (the developers that put the code into CVS), have still to find a way to work on this together. If we are not able to do this in the long run, the CVS is pretty useless.
I realise I've said this before and it might be unhelpful, but to resolve this problem, wouldn't you consider migrating to something like PRCS, or Aegis?
caveat: aegis turned out to be *too* huge and compilcated (though it protects versioning beatifully, no broken releases there), but prcs is much easier and provides better (if you're looking for that) tools than CVS.
my 2p
d
david casal --0+ --- d.casal@uea.ac.uk --9+ --- www.ariada.uea.ac.uk/~dcasal --)+
-
_-¯-_ -
Bryan Jurish -
Chris McCormick -
david casal -
guenter geiger -
Hans-Christoph Steiner -
Josh Steiner -
Maurizio Umberto Puxeddu -
Michael Iber -
Thomas Grill -
vanDongen-Gilcher