Now that I have done some coding on the new Tcl side of things, I have some questions to pose here. (crossing fingers, hoping to avoid bike shed issues :D )
- first, does anyone object to making the Tcl files use 90 or 100 character widths? Tcl lines tend to be long and 80 char width tends to cause a lot of really ugly lines.
- second, I think we should use a similar tab format as the C side, but cleaner: 4 char tabs, all spaces or maybe all tabs.
- third, I am thinking that the Tcl should be broken up into single- file packages where the package name and the file name are the same. For example:
pd.tk menus.tcl menucommands.tcl bindings.tcl preferences.tcl ...
or maybe:
pd.tk pdmenus.tcl pdmenucommands.tcl pdbindings.tcl pdpreferences.tcl ...
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Hans-Christoph Steiner said :
Now that I have done some coding on the new Tcl side of things, I have some questions to pose here. (crossing fingers, hoping to avoid bike shed issues :D )
- first, does anyone object to making the Tcl files use 90 or 100
character widths? Tcl lines tend to be long and 80 char width tends to cause a lot of really ugly lines.
I prefer longer lines, so i would pick 100:)
- second, I think we should use a similar tab format as the C side,
but cleaner: 4 char tabs, all spaces or maybe all tabs.
4 char tabs sounds good.
- third, I am thinking that the Tcl should be broken up into single-
file packages where the package name and the file name are the same. For example:
i perfer the second naming convention. i am not sure how finely splitted these tcl files should be, menus and menucommands could be in one instead of two, for example.
cheers
chun
pd.tk menus.tcl menucommands.tcl bindings.tcl preferences.tcl ...
or maybe:
pd.tk pdmenus.tcl pdmenucommands.tcl pdbindings.tcl pdpreferences.tcl ...
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I forgot to add, I found this website has useful advice on organizing and using Tcl packages:
http://www.wjduquette.com/tcl/namespaces.html
.hc
On Dec 24, 2008, at 6:29 PM, Hans-Christoph Steiner wrote:
Now that I have done some coding on the new Tcl side of things, I have some questions to pose here. (crossing fingers, hoping to avoid bike shed issues :D )
- first, does anyone object to making the Tcl files use 90 or 100
character widths? Tcl lines tend to be long and 80 char width tends to cause a lot of really ugly lines.
- second, I think we should use a similar tab format as the C side,
but cleaner: 4 char tabs, all spaces or maybe all tabs.
- third, I am thinking that the Tcl should be broken up into single-
file packages where the package name and the file name are the same. For example:
pd.tk menus.tcl menucommands.tcl bindings.tcl preferences.tcl ...
or maybe:
pd.tk pdmenus.tcl pdmenucommands.tcl pdbindings.tcl pdpreferences.tcl ...
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Sorry for the slow response on this one...
- first, does anyone object to making the Tcl files use 90 or 100
character widths? Tcl lines tend to be long and 80 char width tends to cause a lot of really ugly lines.
This would cause me much misery since I often depend on 'terminal' editors that can't be conveniently reformatted by file. Plus, it's hard to know where to draw the line.
- second, I think we should use a similar tab format as the C side,
but cleaner: 4 char tabs, all spaces or maybe all tabs.
I've "always" used 4-character indents, no tabs (except for makefile.in :) Various contributed code deviates from that, and when I have to actually look at it I feel at liberty to thrash it into the pd "standard". There are some bits I'm afraid to touch, such as the ALSA MIDI code, since I don't have any setup on which to test it.
I think it causes great confusion to use hard tabs in the code. If they're absolutely unavoidable let's keep them to 8 spaces (the most standard value even if it doesn't agree with the indentation style.)
- third, I am thinking that the Tcl should be broken up into single-
file packages where the package name and the file name are the same. For example:
pd.tk menus.tcl menucommands.tcl bindings.tcl preferences.tcl ...
or maybe:
pd.tk pdmenus.tcl pdmenucommands.tcl pdbindings.tcl pdpreferences.tcl ...
but 'pd' is understood - it's the name of the program. On the other hand, "u" is opaque as a prefix. "g" is taken. Maybe "t", as in "t_pd.tk", etc. Also, unless there's a reason to have some named ".tk" and others ".tcl" they should share the same suffix to make globbing easier.
Historical note: the reason the makefile copies the tk script is so that all the source could live in the same directory, but so that the runtime wouldn't look in the source directory in case someone wants to install the two in separate places (as in redhat's "rpm" and "srpm" setup).
cheers Miller
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Jan 3, 2009, at 1:48 PM, Miller Puckette wrote:
Sorry for the slow response on this one...
- first, does anyone object to making the Tcl files use 90 or 100
character widths? Tcl lines tend to be long and 80 char width tends to cause a lot of really ugly lines.
This would cause me much misery since I often depend on 'terminal' editors that can't be conveniently reformatted by file. Plus, it's hard to know where to draw the line.
I also regularly edit files with emacs and vi in the terminal, and 90 chars has never caused me any trouble. xterm, rxvt, etc. etc. all handle it very well. Or are you talking about using computers in 80x25 character display mode? Are you on a VT100? ;-)
There are some really unreadable sections of u_main.tk that would be more readable with a bit more room, like 90 chars. I am fine with leaving the C code at 80 chars, but Tcl tends to have a lot of long lines, and often doesn't wrap cleanly.
- second, I think we should use a similar tab format as the C side,
but cleaner: 4 char tabs, all spaces or maybe all tabs.
I've "always" used 4-character indents, no tabs (except for makefile.in :) Various contributed code deviates from that, and when I have to actually look at it I feel at liberty to thrash it into the pd "standard". There are some bits I'm afraid to touch, such as the ALSA MIDI code, since I don't have any setup on which to test it.
I think it causes great confusion to use hard tabs in the code. If they're absolutely unavoidable let's keep them to 8 spaces (the most standard value even if it doesn't agree with the indentation style.)
All spaces then? 4 char indent?
- third, I am thinking that the Tcl should be broken up into single-
file packages where the package name and the file name are the same. For example:
pd.tk menus.tcl menucommands.tcl bindings.tcl preferences.tcl ...
or maybe:
pd.tk pdmenus.tcl pdmenucommands.tcl pdbindings.tcl pdpreferences.tcl ...
but 'pd' is understood - it's the name of the program. On the other hand, "u" is opaque as a prefix. "g" is taken. Maybe "t", as in "t_pd.tk", etc. Also, unless there's a reason to have some named ".tk" and others ".tcl" they should share the same suffix to make globbing easier.
The "pd_" is not understood in Tcl. If you have a package/namespace called "menus", that is very vague and has a very high potential for causing name conflicts. "pd_menus" is much clearer in meaning and much less likely to cause name conflicts. "t_" seems pretty much meaningless to me, especially since the files end with ".tcl".
.tk is for wish shell, and .tcl is for tclsh and packages, so those different endings have meaning. pd.tk is run with the Wish shell. It could be pd.tcl, as long as there is a "package require Tk", which will then launch the Wish shell stuff. I don't know if that would play nice with the Wish.app on Mac OS X.
.hc
Historical note: the reason the makefile copies the tk script is so that all the source could live in the same directory, but so that the runtime wouldn't look in the source directory in case someone wants to install the two in separate places (as in redhat's "rpm" and "srpm" setup).
cheers Miller
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hans-Christoph Steiner wrote:
On Jan 3, 2009, at 1:48 PM, Miller Puckette wrote:
The "pd_" is not understood in Tcl. If you have a package/namespace called "menus", that is very vague and has a very high potential for causing name conflicts. "pd_menus" is much clearer in meaning and much less likely to cause name conflicts. "t_" seems pretty much meaningless to me, especially since the files end with ".tcl".
.tk is for wish shell, and .tcl is for tclsh and packages, so those different endings have meaning. pd.tk is run with the Wish shell. It could be pd.tcl, as long as there is a "package require Tk", which will then launch the Wish shell stuff. I don't know if that would play nice with the Wish.app on Mac OS X.
two remarks: - as i understand it, u_main.tk is deprecated and replaced by pd.tk. can we then delete u_main.tk?
- for the sake of clarity: wouldn't it be nicer to have a separate directory for all the tcl/tk files?
and a question: - is there any documentation? how do I start getting into this (apart from reading all the code)?
mfga.sdr IOhannes
IOhannes m zmoelnig wrote:
two remarks:
- as i understand it, u_main.tk is deprecated and replaced by pd.tk.
can we then delete u_main.tk?
- for the sake of clarity: wouldn't it be nicer to have a separate
directory for all the tcl/tk files?
and a question:
- is there any documentation? how do I start getting into this (apart
from reading all the code)?
and finally: how do i start Pd with the new tk-code? i only get: "tcl: ../bin/pd.tk: can't open script"
m,fgads IOhannes
Hi list,
I recently start to work with Pd (I was a Max guy only before) and I'm a little confuse about the 'scale' and range objects.
Apparently there are two scale object, one in maxlib/ and one in Gem/, and when I try to create a scale object I get the one from Gem/ . last moth it was cool because that was the one I was needing , but today it is not :-).
I see that there is also a range object (deprecated), and I looked at the code of it and of the maxlib/scale and there are apparently the same object (by the way when I create a 'range' and ask for the help it is not found). So for now I'm using range.
I was wondering how it could be possible to deal with this...
'scale' is the name of this object in max too, so it may be nice to have the same name maybe (or maybe not???)...
I thought that maybe a kind of solution could be to force to create the maxlib/scale when there is 5 arguments (Gem/scale need 4 only), I'm curious to know if it is possible....
someone know this?
loic ---
Hallo, Loic Kessous hat gesagt: // Loic Kessous wrote:
I recently start to work with Pd (I was a Max guy only before) and I'm a little confuse about the 'scale' and range objects.
Both [scale]s, and [range] are externals, so they don't ship with a standard Pd and one has to chose which one to use. Gem is one of the oldest collections of externals and its [scale] is a very important object, so I'd reserve the name "scale" for the one in Gem.
If you think so, too, then every other [scale] has to get a different name. You can use the maxlib "scale" by refering to it as [maxlib/scale] in Pd-extended.
Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj
Ciao
On Jan 8, 2009, at 12:51 PM, Frank Barknecht wrote:
Hallo, Loic Kessous hat gesagt: // Loic Kessous wrote:
I recently start to work with Pd (I was a Max guy only before) and I'm a little confuse about the 'scale' and range objects.
Both [scale]s, and [range] are externals, so they don't ship with a standard Pd and one has to chose which one to use. Gem is one of the oldest collections of externals and its [scale] is a very important object, so I'd reserve the name "scale" for the one in Gem.
If you think so, too, then every other [scale] has to get a different name. You can use the maxlib "scale" by refering to it as [maxlib/ scale] in Pd-extended.
Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj
There are others as well, like [mapping/autoscale] aka [autoscale]. I thought there was something in 'cyclone' too...
.hc
Ciao
Frank Barknecht
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jan 8, 2009, at 12:51 PM, Frank Barknecht wrote:
Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj
There are others as well, like [mapping/autoscale] aka [autoscale]. I thought there was something in 'cyclone' too...
There's also [+ ] and [* ]. ;)
Ciao
yes, thanks [+], [*] and expr too! to make the exponential mapping ;-) ..., that can be done in an abstraction , that I may have somewhere in max before scale has been ported to os X, but for me the real question was to know what can I use from Pd-extended, so if i work on a another computer and even another platform I can just take my patch and not taking care about other things to add (because I'm always forgotting them...) so the [maxlib/scale] is the good solution for me.
thanks for your help.
but I noticed that when I call the 'help', I get in the help from maxlib but the the 'scale' of the gem ... so maybe the help coulb be changed to replace [scale] by [maxlib/ scale] too, like I did for myself, I mean: ---------
#N canvas 381 126 552 355 12; #X floatatom 27 277 8 0 0 0 - - -; #X floatatom 27 73 5 0 0 0 - - -; #X text 213 48 written by olaf.matthes@gmx.de; #X text 37 306 creation:; #X text 141 11 scale :: scale input from a certain input range; #X text 212 29 to lie between output boundaries; #X floatatom 56 131 5 0 0 0 - - -; #X floatatom 85 152 5 0 0 0 - - -; #X floatatom 115 173 5 0 0 0 - - -; #X floatatom 144 194 5 0 0 0 - - -; #X text 84 71 input value; #X text 106 278 scaled output value; #X text 111 130 in low; #X text 137 151 in high; #X text 171 172 out low; #X text 200 194 out high; #X text 57 104 creation arguments can be changed dynamically:; #X text 53 323 scale <in low> <in high> <out low> <out high> <log coeff> ; #X floatatom 174 220 5 0 0 0 - - -; #X text 227 219 log coefficient; #X text 265 237 0 = linear 1 = log; #X obj 27 249 maxlib/scale 0 9 100 255 0; #X connect 1 0 21 0; #X connect 6 0 21 1; #X connect 7 0 21 2; #X connect 8 0 21 3; #X connect 9 0 21 4; #X connect 18 0 21 5; #X connect 21 0 0 0;
---------- loic
On Jan 9, 2009, at 7:52 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jan 8, 2009, at 12:51 PM, Frank Barknecht wrote:
Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj
There are others as well, like [mapping/autoscale] aka [autoscale]. I thought there was something in 'cyclone' too...
There's also [+ ] and [* ]. ;)
Ciao
Frank Barknecht
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Loic Kessous hat gesagt: // Loic Kessous wrote:
yes, thanks [+], [*] and expr too! to make the exponential mapping ;-) ..., that can be done in an abstraction , that I may have somewhere in max before scale has been ported to os X, but for me the real question was to know what can I use from Pd-extended, so if i work on a another computer and even another platform I can just take my patch and not taking care about other things to add (because I'm always forgotting them...)
The safest thing to do really is to use an abstraction that only relies on Pd vanilla objects (if possible) and copy that into your patch directory. Then every Pd user everywhere will be able to use your work.
maxlib's scale is pretty easy to do as an abstraction, Gem's scale obviously is not.
Ciao
On Jan 8, 2009, at 7:41 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
two remarks:
- as i understand it, u_main.tk is deprecated and replaced by pd.tk.
can we then delete u_main.tk?
- for the sake of clarity: wouldn't it be nicer to have a separate
directory for all the tcl/tk files?
and a question:
- is there any documentation? how do I start getting into this (apart
from reading all the code)?
and finally: how do i start Pd with the new tk-code? i only get: "tcl: ../bin/pd.tk: can't open script"
I use this:
cd ~/code/pure-data/branches/pd-devel/0.41.4/src/ autoconf && ./configure --disable-jack rm ../bin/pd.tk ; make && ../bin/pd -stderr
.hc
On Jan 8, 2009, at 7:36 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Jan 3, 2009, at 1:48 PM, Miller Puckette wrote:
The "pd_" is not understood in Tcl. If you have a package/namespace called "menus", that is very vague and has a very high potential for causing name conflicts. "pd_menus" is much clearer in meaning and much less likely to cause name conflicts. "t_" seems pretty much meaningless to me, especially since the files end with ".tcl".
.tk is for wish shell, and .tcl is for tclsh and packages, so those different endings have meaning. pd.tk is run with the Wish shell. It could be pd.tcl, as long as there is a "package require Tk", which will then launch the Wish shell stuff. I don't know if that would play nice with the Wish.app on Mac OS X.
two remarks:
- as i understand it, u_main.tk is deprecated and replaced by pd.tk.
can we then delete u_main.tk?
Done. I suppose next t_tk.h, t_main.c and t_tkcmd.c should be deleted, since the network and startup stuff is handled in Tcl (pd_connect.tcl for example).
- for the sake of clarity: wouldn't it be nicer to have a separate
directory for all the tcl/tk files?
Perhaps, I don't have a strong feeling either way. I think it is easy enough to separate .tcl from .c.
and a question:
- is there any documentation? how do I start getting into this (apart
from reading all the code)?
First we need to get it working, then organize it, then document it. :) So yeah, the code...
.hc
mfga.sdr IOhannes
On Sat, Jan 03, 2009 at 01:48:11PM -0800, Miller Puckette wrote:
- second, I think we should use a similar tab format as the C side,
but cleaner: 4 char tabs, all spaces or maybe all tabs.
I've "always" used 4-character indents, no tabs (except for makefile.in :) Various contributed code deviates from that, and when I have to actually look at it I feel at liberty to thrash it into the pd "standard". There are some bits I'm afraid to touch, such as the ALSA MIDI code, since I don't have any setup on which to test it.
A bit OT, but if you're using vi, a quick and painless way to reformat between all-tabs or all-spaces is the following:
:0,$s/ /\t/g <- converts 4 spaces to a tab :0,$s/\t/ /g <- converts a tab to 4 spaces
In C code that won't break anything. You could also use the 'rpl' command, or one of those fancy indent re-formatting programs. I am using this all the time now as I belong to the religion of tabs, but the other heathen at RjDj are spaces people. Of course, tabs are the One True Way, and shall reign supreme at the return of the Tab King. You'll see.
Chris.
------------------- http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Sat, Jan 03, 2009 at 01:48:11PM -0800, Miller Puckette wrote: A bit OT, but if you're using vi, a quick and painless way to reformat between all-tabs or all-spaces is the following:
:0,$s/ /\t/g <- converts 4 spaces to a tab :0,$s/\t/ /g <- converts a tab to 4 spaces
In Vim you can also use the :retab command. The manual contains an example for automating things.
Ciao
-
[*~] -
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Loic Kessous -
Miller Puckette