headers
Miller Puckette | 3 Jan 2009 22:48

Re: Tcl/Tk code formatting and file organization

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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Hans-Christoph Steiner | 4 Jan 2009 02:39
Gravatar

Re: Tcl/Tk code formatting and file organization


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
(Continue reading)

Permalink | Reply | 10 comments |
headers
Chris McCormick | 4 Jan 2009 12:19
Gravatar

Re: Tcl/Tk code formatting and file organization

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
Permalink | Reply | 1 comment |
headers
SourceForge.net | 4 Jan 2009 13:13
Picon
Favicon

[ pure-data-Bugs-2485339 ] pd~ crash pd when sending a big message to sub-process

Bugs item #2485339, was opened at 2009-01-04 12:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2485339&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Miller Puckette (millerpuckette)
Summary: pd~ crash pd when sending a big message to sub-process

Initial Comment:
When a big message is send via pd~ to a sub process, pd exit with this message in the consol :

*** stack smashing detected ***: pd terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7d6c138]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7d6c0f0]
/usr/local/lib/pd/extra/pd~/pd~.pd_linux[0xb7ee5334]
/usr/local/lib/pd/extra/pd~/pd~.pd_linux[0xb7ee34ee]
[0x32203120]
======= Memory map: ========
...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Barknecht | 5 Jan 2009 11:57
Favicon

Re: Tcl/Tk code formatting and file organization

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
--

-- 
 Frank Barknecht            Do You RjDj.me?          _ ______footils.org__
Permalink | Reply | 0 comments |
headers
SourceForge.net | 5 Jan 2009 18:38
Picon
Favicon

[ pure-data-Patches-1944415 ] plugin~ help crashes Pd-extended on Mac OS X

Patches item #1944415, was opened at 2008-04-17 00:07
Message generated for change (Comment added) made by zoomzoomzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1944415&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: plugin~ help crashes Pd-extended on Mac OS X

Initial Comment:
In the process of trying the help patch from #1944380, I just foudn another bug:  the plugin~ help patch
crashes Pd on Mac OS X 10.4.11/Intel using Pd-0.40.3-extended-20080403.  I am guessing that this is
related to the plugin files it is trying to load

----------------------------------------------------------------------

Comment By: zoom zoomzen (zoomzoomzen)
Date: 2009-01-05 18:38

Message:
hi,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans-Christoph Steiner | 5 Jan 2009 22:33
Gravatar

locales and iemgui


Hey Chun, all,

I am thinking that for adding locales to pd-devel, we should leave  
iemgui out of it.  It is very messy code that has a lot of legacy use,  
so that the iemgui stuff would need to have full backwards  
compatibility.  Instead, I think we should build a new GUI library  
that includes locale support.  In the process we could make a locale  
API for people who want to write their own GUI objects and include  
translations.  I have almost the whole framework for such a library  
finished, its called 'tkwidgets'.

Perhaps it makes sense to use the standard .po file format for  
locales, its pretty simple and would be easy to parse in Tcl.  I  
imagine there are tools for working with .po files, so then we could  
use those.  Then init_locale() could read the .po into a hashtable,  
i.e. $hashtable($key).  My guess is that a big hashtable would be  
faster than the current say() procedure, but I could be wrong.

Or maybe a locale namespace makes more sense, it would just be lots of  
variable names, something like:

namespace eval ::pd_locale:: {
	variable file_new
	variable file_open
	variable file_save
	variable file_saveas
...
	variable edit_undo
	variable edit_redo
(Continue reading)

Permalink | Reply | 13 comments |
headers
Hans-Christoph Steiner | 6 Jan 2009 01:18
Gravatar

Re: locales and iemgui


Actually, I just found out that the GNU gettext utils for .po files  
are included in Tcl/Tk in a package called "msgcat".  Here's a little  
bit more on the topic:

http://www.gnu.org/software/automake/manual/gettext/Tcl.html

.hc

On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:

>
> Hey Chun, all,
>
> I am thinking that for adding locales to pd-devel, we should leave  
> iemgui out of it.  It is very messy code that has a lot of legacy  
> use, so that the iemgui stuff would need to have full backwards  
> compatibility.  Instead, I think we should build a new GUI library  
> that includes locale support.  In the process we could make a locale  
> API for people who want to write their own GUI objects and include  
> translations.  I have almost the whole framework for such a library  
> finished, its called 'tkwidgets'.
>
> Perhaps it makes sense to use the standard .po file format for  
> locales, its pretty simple and would be easy to parse in Tcl.  I  
> imagine there are tools for working with .po files, so then we could  
> use those.  Then init_locale() could read the .po into a hashtable,  
> i.e. $hashtable($key).  My guess is that a big hashtable would be  
> faster than the current say() procedure, but I could be wrong.
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Hans-Christoph Steiner | 6 Jan 2009 01:27
Gravatar

Re: locales and iemgui


Ok, responding to myself again :D  It turns out that msgcat has been  
part of Tcl since 8.1:

http://tcl.tk/man/tcl8.4/TclCmd/msgcat.htm

It looks like this is definitely the way to handle locales.

.hc

On Jan 5, 2009, at 7:18 PM, Hans-Christoph Steiner wrote:

>
> Actually, I just found out that the GNU gettext utils for .po files  
> are included in Tcl/Tk in a package called "msgcat".  Here's a  
> little bit more on the topic:
>
> http://www.gnu.org/software/automake/manual/gettext/Tcl.html
>
> .hc
>
> On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
>
>>
>> Hey Chun, all,
>>
>> I am thinking that for adding locales to pd-devel, we should leave  
>> iemgui out of it.  It is very messy code that has a lot of legacy  
>> use, so that the iemgui stuff would need to have full backwards  
>> compatibility.  Instead, I think we should build a new GUI library
(Continue reading)

Permalink | Reply | 0 comments |
headers
mescalinum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org | 6 Jan 2009 01:43
Picon

Re: locales and iemgui

Hans-Christoph Steiner wrote:
> Hey Chun, all,
>
> I am thinking that for adding locales to pd-devel, we should leave  
> iemgui out of it.  It is very messy code that has a lot of legacy use,  
> so that the iemgui stuff would need to have full backwards  
>   

I agree they are very messy.

I am totally for a remake of gui objects, with cleaner code, better
functionality, and all the best.
I believe much time must be spent on design of this, creating a common
codebase for such objects, an API, a set of user requirements, and so on....

which collaborative tool could help in this phase? wiki?

just to throw in some ideas:
* powerful sliders which allow to select range (i.e. a second handle
comes in)
* sliders and radio are basically the same type of object, just that a
radio only would allow integer values
* a bitmap object is missing (a seqence of bits.... just another
representation of an integer)
   also, that could be 2-dimensional, allowing grid of bits... but that
falls out of generality with the radio/slider objects
* preferences dialogs as pd patches? (this may be too ambitious)

my 0.02
(Continue reading)

Permalink | Reply | 1 comment |

Gmane