Better support for debugging within C source files

[elfring]

There are some source-level debuggers available for the code analysis of files which were written in the programming language "C". These tools support to manage breakpoints. The breakpoint location is usually specified as a line number from a source file. How many corresponding implementations support also the specification of a column for such source code positions?

I find that there are special consequences to consider if you look at the current software situation. I suggest to put every statement in your own source files on a separate text line. How do you think about to reformat any of your source files by a tool like "Artistic Style"?

[tavmem]

It is unlikely that we would use a tool like "Artistic Style" for this project or put each statement on a separate line.

One of the objectives of the project is to explore and evaluate a particular C-coding style. See https://github.com/kevinlawler/kona/wiki/Coding-Guidelines

It is rumored that an early version of Arthur Whitney's k5 consisted of 5 files of C code, each of which fit on a single screen. When giving a demo of it, he supposedly muttered: "I hate scrolling". (There is a web-accessible account of this demo somewhere, but I can't seem to find it right now.)

[refi64]

This is good enough. You can always just use nexti.

@tavmem If you ever find that, I would love to see it.

[elfring]

If you insist to pack a lot of statements into a single text line, you will have to live with bad granularity for source-level debugging of corresponding C files for a while.

I would prefer a coding style which supports fine-grained software debugging with the available tools today. Would it be nice if an extra code reformatting step could be avoided for this purpose?

[bakul]

Someone asked about the code base. “Currently it’s 247 lines of C.” Some expressions of incredulity. Whitney displayed the source, divided between five text files so each would fit entirely on his monitor. “Hate scrolling,” he mumbled.

http://archive.vector.org.uk/art10501320

On Aug 3, 2015, at 7:00 AM, Ryan Gonzalez notifications@github.com wrote:

This is good enough. You can always just use nexti.

@tavmem If you ever find that, I would love to see it.

— Reply to this email directly or view it on GitHub.

[tavmem]

Oleg and Pierre had heard of Whitney and kdb+. They study computer science in St Petersburg. (Russia, not Florida.) With a great deal of trepidation and some support from a teacher they wrote asking Whitney what he was doing. He replied with some C code he was working on.

It may be just a coincidence that akumuli.org is based in St. Petersburg ... and maybe not. https://github.com/akumuli/Akumuli

[tavmem]

you will have to live with bad granularity for source-level debugging

The style defiinitely has both pros and cons ... Probably more pros in the hands of someone like Arthur, and more cons in my case. :-)

Note that the style is heavily dependent on macros, and probably only works well with C. Bjarne Stroustrup strongly discourages macros in C++

Macros are very important in C but have far fewer uses in C++. The first rule about macros is: Don't use them unless you have to. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer.

[ghost]

gcc -E -P src.c -o out.c

Daniel

[tavmem]

Stroustrup (like @elfring) is a major fan of automated tools. Writing further about macros:

Because they rearrange the program text before the compiler proper sees it, macros are also a major problem for many programming tools. So when you use macros, you should expect inferior service from tools such as debuggers, cross-reference tools, and profilers.

[tavmem]

A stark contrast to the Whitney philosophy:

it’s a simple workplace: a pool table, a desk, a chair and a PC with a single monitor. When I saw it in 2007 it was running Windows XP and had five windows open: two MS-DOS and three Notepad. Brutally simple IDE.

[ghost]

2015-08-03 17:20 GMT+02:00 Tom Szczesny notifications@github.com:

Stroustrup (like @elfring) is a major fan of automated tools. Writing further about macros:

Because they rearrange the program text before the compiler proper sees it, macros are also a major problem for many programming tools. So when you use macros, you should expect inferior service from tools such as debuggers, cross-reference tools, and profilers.

you can clean macros with:

gcc -E -P src.c -o out.c

and then use out.c file in source-level debuggers... and yes, Whitney's coding style is a bit problematic.

[refi64]

Despite rarely ever using this coding style, I don't often use automatic tools (printf is usually my debugger).

But, remember: this is C, not C++. C++11 has several features to help avoid using macros that C doesn't have.

[tavmem]

Arthur on debuggers http://queue.acm.org/detail.cfm?id=1531242

In C I never learned to use the debugger so I used to never make mistakes, but now I make mistakes and I just put in a print statement. K is interpreted, so it's a lot easier. If I'm surprised at the value of some local at some point, I can put in a print, and that's really all I do.

[tavmem]

More from http://archive.vector.org.uk/art10501320

Everyone knows how C programs look: tall and skinny. Whitney’s don’t. Unlike the tall skinny C programs in the textbooks, the code for this interpreter spills sideways across the page. It certainly doesn’t look like C.

[elfring]

Why do you not dare to write the source code from a translation unit on only a single text line (completely without extra whitespaces) then? ;-)

How do you think about to add support for "the K programming style" to the reformatting tool "Artistic Style"?

[refi64]

The only issue is that there is little concrete style to the "K programming style". Usually, each line pertains to one specific task, so it's more of a logical thing than a technical thing.

[bakul]

On Mon, 03 Aug 2015 08:11:25 PDT Tom Szczesny notifications@github.com wrote:

The style defiinitely has both pros and cons ... Probably more pros in the hands of someone like Arthur, and more cons in my case. :-)

The idea is to keep a relentless focus on simplification + have a C code style that roughly corresponds to k/APL.

The conventional wisdom is to factor code out if you're have more than one place with similar code, or if the code becomes longer than a page. k wisdom seems to be to factor things out if at all possible and never mind how many lines! K style uses macros judiciously and once you become familiar with the basic set, code is not hard to read.

There is value in seeing the entire context of something all at once. This is not easy to get used to but pays off once you become good at it :-)

If prinf() for debugging is not enogh, chances are the code is complicated and can do with refactoring or simplification.

What would be nice is someone came up with indent profiles (or asyle) to convert C code to k style and back!

While we are on the subject, it would be nice if the style of new code was kept consistent with the original code style.

[tavmem]

I think that writers of new code for Kona should strive toward the goals you outline above. However, both the original and the current code for Kona are still quite different from Whitney's code. Here is an excerpt of an early version of code from the A+ interpreter written by Arthur (which was ultimately made open source by Morgan Stanley):

Z pw(f,s,n)C *s;{I t;do t=write(f,s,n);while(s+=t,t!=-1&&(n-=t));fsych(f);R t;} /* IBM write fix */
Z mo(s,z)A z;C *s;{I f,t=z->t,c,n;C r[MAXPATHLEN],*p;Q(Ct<t,6)
 s=rindex(s,'.')>rindex(s,'/')?s:fi(s,"m");
 strcpy(r,s),strcat(r,"!@#");
 ERR(s,f=open(r,O_CREAT|O_WRONLY,0666))
 if(c=z->c)z->i=z->r?*z->d:1;
 if(t=pw(f,z,n=AH+T(z->n)+(t==Ct)),c)z->c=c;
 close(f);ERR(s,t)ERR(s,t)ERR(s,rename(r,s))R 1;}
C *cs(a)A a;{I s;R a->t==Ct?(C*)a->p:a->t==Et&&QS(s=*a->p)?XS(*a->p)->n:0;}
H1(bi){R mpi(cs(a),0);}H2(bo){I n;C *s=cs(a);R !s?mpi(cs(w),*a->p):mo(s,w)?nl:0;}
Z fzr(f,n){I j=getpagesize(),k=lseek(f,0,2);n=((n+j-1)/j)*j;
 for(;n<k;n+=j)lseek(f,n,0),write(f,&f,1);}
Z items(n,z){C *s=cs(z);Z struct a a;I f,t,m,j,w=n!=-1;Q(!s,9)
 ERR(s,f=open(fi(s,"m"),w?O_RDWR:O_RDONLY))ERR(s,read(f,&a,AH))Q(!a.r,7)
 m=*a.d;j=a.i;if(m>j)j=m;if(w){t=a.t;if(n==-2)fxr(f,AH+T(a.n)+(t==Ct));else{
  a.i-n,m=n*tr(a.r-1,a.d+1);if(n<*a.d)*a.d=n,a.n=m;lseek(f,0,0);
  ERR(s,write(f,&a,AH))ERR(s,flen(f,AH+T(m)+(t==Ct)))}}R close(f),j;}
Z rd(f,s,n)C *s;{C *t=s+n;I k;for(;s<t;s+=k)PERR("",k=read(f,s,n))R 1;}
H1(ri){I0;{A z;struct a b;I d=*a->p,t;
 Q(AH!=read(d,&b,AH)||b.t>Ct||b.r>MAXR||b.n!=tr(b.r,b.d),9)
 W(gd(t=b.t,&b))R rd(d,z->p,T(b.n))?(I)z:(dc(z),0);}}
Z vf(a,b,i)C *a,*b;{A z;V v;I f,t;FILE g,*h;
 if(!isal(*a)||!b)R H("incorrect\n");v=vi(si(a),Cx);switch(i){
 case 3:if(h=popen(b,"w"))g=*stdout,*stdout=*h,pa(gt(v)),NL,*h=*stdout,pclocse(h),*stdout=g;else peff("pipe?");R;
 case 2:if(!QA(z=(A)v->a)||!z||!mo(b,z))R H("can't write%s\n",a);}dc(v->a),v->a=m1(b,1);}

Another example would be the J incunabulum. http://www.jsoftware.com/jwiki/Essays/Incunabulum

[bakul]

On Mon, 03 Aug 2015 20:45:08 PDT Tom Szczesny notifications@github.com wrote:

However, both the original and the current code for Kona are still quite different from Whitney's code.

That may be but since Kevin started from scratch, he got to choose the style he wanted ;-) His style is close enough.

[tavmem]

Style ... for the sake of preserving a style ... is not the primary objective. Completeness, correctness and speed come first. Hopefully, style helps achieve these 3.

[tavmem]

As an aside: Whitney on K vs Q (http://archive.vector.org.uk/art10501320)

Most programming I do would be in K, but if it was a lot of relational-table stuff, I would use Q because a lot of those words are already defined.

[tavmem]

A somewhat extreme example of differences in coding style. https://github.com/tavmem/buddy/blob/master/a/b.c

This file contains 2 versions of the buddy space management system used in an early version of A+, which Morgan Stanley has graciously made open source under the GNU license.

One version is traditional C with lots of comments and is 740 lines. The Whitney version is 12 lines.