Thread: [Libphidget-devel] More on indent
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel
|
From: Vadim T. <vt...@fr...> - 2002-09-10 17:21:37
|
Hello, Indeed, indent is fragile. Some options break the code altogether (--dont-break-procedure-type). Some options cause the results to be different on each run (--braces-on-struct-decl-line). Some options, though, yield a repeatable result. After some fiddling, I've found the set that I can live with: --no-blank-lines-after-declarations --blank-lines-after-procedures --no-blank-lines-after-commas --break-before-boolean-operator --braces-on-if-line --brace-indent4 --braces-after-struct-decl-line --no-comment-delimiters-on-blank-lines --cuddle-else --else-endif-column1 --space-after-cast --declaration-indentation4 -ndj --dont-format-first-column-comments --dont-format-comments --honour-newlines --indent-level4 --parameter-indentation5 --continue-at-parentheses --no-space-after-function-call-names --no-space-after-parentheses --procnames-start-lines --dont-star-comments --leave-optional-blank-lines --line-length128 Cut'n'paste it into ./indent.rules in INDENT branch and see if it is OK with you, and if so, let's stop right there - enough time wasted. It's all my fault ;/ --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 01:28:49
|
On Tue, 2002-09-10 at 12:21, Vadim Tkachenko wrote: > Hello, > > Indeed, indent is fragile. > > Some options break the code altogether (--dont-break-procedure-type). Some > options cause the results to be different on each run > (--braces-on-struct-decl-line). Some options, though, yield a repeatable > result. After some fiddling, I've found the set that I can live with: > > --no-blank-lines-after-declarations > --blank-lines-after-procedures > --no-blank-lines-after-commas > --break-before-boolean-operator > --braces-on-if-line > --brace-indent4 > --braces-after-struct-decl-line > --no-comment-delimiters-on-blank-lines > --cuddle-else > --else-endif-column1 > --space-after-cast > --declaration-indentation4 > -ndj > --dont-format-first-column-comments > --dont-format-comments > --honour-newlines > --indent-level4 > --parameter-indentation5 > --continue-at-parentheses > --no-space-after-function-call-names > --no-space-after-parentheses > --procnames-start-lines > --dont-star-comments > --leave-optional-blank-lines > --line-length128 > > Cut'n'paste it into ./indent.rules in INDENT branch and see if it is OK with > you, and if so, let's stop right there - enough time wasted. It's all my > fault ;/ k I finally got home, I just updated to the INDENT revision. [jstrohm@oishi libphidget]$ make indent indent: unknown option "-blank-lines-after-block-comments" . . . . and then woops! all the source code files were empty :-( no problem, but need to add a something so that if indent dies it doesn't kill the original file. started over again, and set up the configuration like you said above, now if this is the style it's checked in as, and we can run indent-local to get our own preferences it's fine with me, but I personally don't care for it. |
|
From: Vadim T. <vt...@fr...> - 2002-09-11 02:24:53
|
According to Jack Strohm: > > Some options break the code altogether (--dont-break-procedure-type). Some > > options cause the results to be different on each run > > (--braces-on-struct-decl-line). Some options, though, yield a repeatable > > result. After some fiddling, I've found the set that I can live with: > > > > --no-blank-lines-after-declarations > > --blank-lines-after-procedures > > --no-blank-lines-after-commas > > --break-before-boolean-operator > > --braces-on-if-line > > --brace-indent4 > > --braces-after-struct-decl-line > > --no-comment-delimiters-on-blank-lines > > --cuddle-else > > --else-endif-column1 > > --space-after-cast > > --declaration-indentation4 > > -ndj The -ndj option is undocumented in my manual, but I've looked it up on Internet, it can be omitted 'cause it's the default > > --dont-format-first-column-comments > > --dont-format-comments > > --honour-newlines > > --indent-level4 > > --parameter-indentation5 > > --continue-at-parentheses > > --no-space-after-function-call-names > > --no-space-after-parentheses > > --procnames-start-lines > > --dont-star-comments > > --leave-optional-blank-lines > > --line-length128 > > > > Cut'n'paste it into ./indent.rules in INDENT branch and see if it is OK with > > you, and if so, let's stop right there - enough time wasted. It's all my > > fault ;/ > > k I finally got home, > > I just updated to the INDENT revision. > > [jstrohm@oishi libphidget]$ make indent > indent: unknown option "-blank-lines-after-block-comments" Are you sure *that* was the message? There's no such option in the text above... And all the long options start with double dash. > and then woops! all the source code files were empty :-( > > no problem, but need to add a something so that if indent dies it > doesn't kill the original file. Will fix that. > started over again, and set up the configuration like you said above, > now if this is the style it's checked in as, and we can run indent-local > to get our own preferences it's fine with me, but I personally don't > care for it. So, would it be OK if I just commit it as it is with the above options and merge it back to main branch? --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 02:30:12
|
On Tue, 2002-09-10 at 21:24, Vadim Tkachenko wrote: > According to Jack Strohm: > > > > Some options break the code altogether (--dont-break-procedure-type). Some > > > options cause the results to be different on each run > > > (--braces-on-struct-decl-line). Some options, though, yield a repeatable > > > result. After some fiddling, I've found the set that I can live with: > > > > > > --no-blank-lines-after-declarations > > > --blank-lines-after-procedures > > > --no-blank-lines-after-commas > > > --break-before-boolean-operator > > > --braces-on-if-line > > > --brace-indent4 > > > --braces-after-struct-decl-line > > > --no-comment-delimiters-on-blank-lines > > > --cuddle-else > > > --else-endif-column1 > > > --space-after-cast > > > --declaration-indentation4 > > > -ndj > > The -ndj option is undocumented in my manual, but I've looked it up on > Internet, it can be omitted 'cause it's the default > > > > --dont-format-first-column-comments > > > --dont-format-comments > > > --honour-newlines > > > --indent-level4 > > > --parameter-indentation5 > > > --continue-at-parentheses > > > --no-space-after-function-call-names > > > --no-space-after-parentheses > > > --procnames-start-lines > > > --dont-star-comments > > > --leave-optional-blank-lines > > > --line-length128 > > > > > > Cut'n'paste it into ./indent.rules in INDENT branch and see if it is OK with > > > you, and if so, let's stop right there - enough time wasted. It's all my > > > fault ;/ > > > > k I finally got home, > > > > I just updated to the INDENT revision. > > > > [jstrohm@oishi libphidget]$ make indent > > indent: unknown option "-blank-lines-after-block-comments" I cut and paste the error, not sure where the single - came from. > > Are you sure *that* was the message? There's no such option in the text > above... And all the long options start with double dash. > > > and then woops! all the source code files were empty :-( > > > > no problem, but need to add a something so that if indent dies it > > doesn't kill the original file. > > Will fix that. please, be bad to loose all changes before you check in cause you called "make indent" > > > started over again, and set up the configuration like you said above, > > now if this is the style it's checked in as, and we can run indent-local > > to get our own preferences it's fine with me, but I personally don't > > care for it. > > So, would it be OK if I just commit it as it is with the above options and > merge it back to main branch? Yeah, as long as we are sure it won't flip/flop on us like the last style :-) |
|
From: Vadim T. <vt...@fr...> - 2002-09-11 02:38:42
|
According to Jack Strohm: > > > [jstrohm@oishi libphidget]$ make indent > > > indent: unknown option "-blank-lines-after-block-comments" > > I cut and paste the error, not sure where the single - came from. That's funny... > > > and then woops! all the source code files were empty :-( > > > > > > no problem, but need to add a something so that if indent dies it > > > doesn't kill the original file. > > > > Will fix that. Fixed. > please, be bad to loose all changes before you check in cause you called > "make indent" ??? You mean do *not* check in the *.c/cc/h files? Of course not, only Makefile.am change was committed... Did I understand you properly? > > > started over again, and set up the configuration like you said above, > > > now if this is the style it's checked in as, and we can run indent-local > > > to get our own preferences it's fine with me, but I personally don't > > > care for it. > > > > So, would it be OK if I just commit it as it is with the above options and > > merge it back to main branch? > > Yeah, as long as we are sure it won't flip/flop on us like the last > style :-) :( Yes, that's exactly what I was hunting for. The set of options in indent.rules that I've just committed produces the stable code - multiple 'make indent && make' runs recompile the code just once. Please 'cvs commit' and verify. If there's an error, send me an output of script(1)ed run of the problem. It should look like this: Script started on Tue Sep 10 19:36:48 2002 DISABLING LIBSAFE so Jar can work 19:36:48 vt@freehold:~/libphidget$ make indent cd . && automake --gnu Makefile cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile 19:36:58 vt@freehold:~/libphidget$ make Making all in src make[1]: Entering directory /home/vt/libphidget/src' Making all in libphidget make[2]: Entering directory /home/vt/libphidget/src/libphidget' *** Documentation is not created - install Doxygen make[2]: Leaving directory /home/vt/libphidget/src/libphidget' Making all in phidget++ make[2]: Entering directory /home/vt/libphidget/src/phidget++' *** Documentation is not created - install Doxygen make[2]: Leaving directory /home/vt/libphidget/src/phidget++' Making all in examples make[2]: Entering directory /home/vt/libphidget/src/examples' *** Documentation is not created - install Doxygen make[2]: Leaving directory /home/vt/libphidget/src/examples' Making all in rpm make[2]: Entering directory /home/vt/libphidget/src/rpm' make[2]: Nothing to be done for ll'. make[2]: Leaving directory /home/vt/libphidget/src/rpm' make[2]: Entering directory /home/vt/libphidget/src' make[2]: Nothing to be done for ll-am'. make[2]: Leaving directory /home/vt/libphidget/src' make[1]: Leaving directory /home/vt/libphidget/src' make[1]: Entering directory /home/vt/libphidget' make[1]: Nothing to be done for ll-am'. make[1]: Leaving directory /home/vt/libphidget' 19:37:00 vt@freehold:~/libphidget$ Use "exit" to leave the shell. 19:37:01 vt@freehold:~/libphidget$ Script done on Tue Sep 10 19:37:01 2002 --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 03:07:21
|
On Tue, 2002-09-10 at 21:38, Vadim Tkachenko wrote: > According to Jack Strohm: > > > > > [jstrohm@oishi libphidget]$ make indent > > > > indent: unknown option "-blank-lines-after-block-comments" > > > > I cut and paste the error, not sure where the single - came from. > > That's funny... > > > > > and then woops! all the source code files were empty :-( > > > > > > > > no problem, but need to add a something so that if indent dies it > > > > doesn't kill the original file. > > > > > > Will fix that. > > Fixed. > > > please, be bad to loose all changes before you check in cause you called > > "make indent" > > ??? You mean do *not* check in the *.c/cc/h files? Of course not, only > Makefile.am change was committed... > > Did I understand you properly? I was just commenting, that if it would be bad if any developer deleted his copy of the files (see problem you fixed above) right before he checked it in. > > > > > started over again, and set up the configuration like you said above, > > > > now if this is the style it's checked in as, and we can run indent-local > > > > to get our own preferences it's fine with me, but I personally don't > > > > care for it. > > > > > > So, would it be OK if I just commit it as it is with the above options and > > > merge it back to main branch? > > > > Yeah, as long as we are sure it won't flip/flop on us like the last > > style :-) > > :( Yes, that's exactly what I was hunting for. The set of options in > indent.rules that I've just committed produces the stable code - multiple > 'make indent && make' runs recompile the code just once. Looks good. make indent && make only compiles the first time. cool! |
|
From: Vadim T. <vt...@fr...> - 2002-09-11 03:09:16
|
According to Jack Strohm: > > > please, be bad to loose all changes before you check in cause you called > > > "make indent" > > > > ??? You mean do *not* check in the *.c/cc/h files? Of course not, only > > Makefile.am change was committed... > > > > Did I understand you properly? > > I was just commenting, that if it would be bad if any developer deleted > his copy of the files (see problem you fixed above) right before he > checked it in. That's what the CVS rollbacks are for ;) > Looks good. > > make indent && make only compiles the first time. > > cool! Duck! --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 03:13:40
|
On Tue, 2002-09-10 at 22:09, Vadim Tkachenko wrote: > According to Jack Strohm: > > > > > please, be bad to loose all changes before you check in cause you called > > > > "make indent" > > > > > > ??? You mean do *not* check in the *.c/cc/h files? Of course not, only > > > Makefile.am change was committed... > > > > > > Did I understand you properly? > > > > I was just commenting, that if it would be bad if any developer deleted > > his copy of the files (see problem you fixed above) right before he > > checked it in. > > That's what the CVS rollbacks are for ;) What are CVS rollbacks? > > > Looks good. > > > > make indent && make only compiles the first time. > > > > cool! > > Duck! What's with this Duck thing? |
|
From: Vadim T. <vt...@fr...> - 2002-09-11 03:18:25
|
According to Jack Strohm: > > > I was just commenting, that if it would be bad if any developer deleted > > > his copy of the files (see problem you fixed above) right before he > > > checked it in. > > > > That's what the CVS rollbacks are for ;) > > What are CVS rollbacks? If the code was screwed up, it's possible to make a rollback. Moreover, it's possible to roll back not only the last change, but any arbitrary change (or span of changes) in the past. Suppose, you're at revision 1.111, and figure out there was a problem with the change between 1.12 and 1.13. This is what you do then: cvs update -j 1.13 -j 1.12 FileName And the file in the working directory will contain the current file, less changes from 1.12 to 1.13. Of course, this is a simplification - there may be conflicts (as in 'CVS conflicts'), but this is the big picture. > > Duck! > > What's with this Duck thing? "Duck" is the action you're supposed to execute when something heavy is flying your way ;) --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 03:26:28
|
On Tue, 2002-09-10 at 22:18, Vadim Tkachenko wrote:
> According to Jack Strohm:
>
> > > > I was just commenting, that if it would be bad if any developer deleted
> > > > his copy of the files (see problem you fixed above) right before he
> > > > checked it in.
> > >
> > > That's what the CVS rollbacks are for ;)
> >
> > What are CVS rollbacks?
>
> If the code was screwed up, it's possible to make a rollback. Moreover, it's
> possible to roll back not only the last change, but any arbitrary change (or
> span of changes) in the past.
>
> Suppose, you're at revision 1.111, and figure out there was a problem with
> the change between 1.12 and 1.13. This is what you do then:
>
> cvs update -j 1.13 -j 1.12 FileName
>
> And the file in the working directory will contain the current file, less
> changes from 1.12 to 1.13.
>
> Of course, this is a simplification - there may be conflicts (as in 'CVS
> conflicts'), but this is the big picture.
Well, what I was saying was the following scenario . . .
cvs checkout . . .
make indent-local
<edit the code>
<everything works, let's commit our changes>
make indent <----- CRAP a bug delete all the code
hmmm . . . crap, can't commit, got to redo all the previous changes
I just finished writing.
does that make sense?
>
> > > Duck!
> >
> > What's with this Duck thing?
>
> "Duck" is the action you're supposed to execute when something heavy is
> flying your way ;)
ahhhh . . .
|
|
From: Vadim T. <vt...@fr...> - 2002-09-11 03:41:08
|
According to Jack Strohm: > Well, what I was saying was the following scenario . . . > > > cvs checkout . . . > > make indent-local > > <edit the code> > > <everything works, let's commit our changes> > > make indent <----- CRAP a bug delete all the code > > hmmm . . . crap, can't commit, got to redo all the previous changes > I just finished writing. > > does that make sense? Yes, it does. Well, a few things, then: Commit often. Try to follow the code guidelines anyway - I know it's difficult (you may check the Apache JServ archives for my own story of getting used to the code conventions - man, did I get flamed ;) I've fixed the zero size bug, but if indent decides to be funny - there's no weapon against that. Only time will tell. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 03:43:49
|
On Tue, 2002-09-10 at 22:41, Vadim Tkachenko wrote: > According to Jack Strohm: > > > Well, what I was saying was the following scenario . . . > > > > > > cvs checkout . . . > > > > make indent-local > > > > <edit the code> > > > > <everything works, let's commit our changes> > > > > make indent <----- CRAP a bug delete all the code > > > > hmmm . . . crap, can't commit, got to redo all the previous changes > > I just finished writing. > > > > does that make sense? > > Yes, it does. Well, a few things, then: > > Commit often. yep > > Try to follow the code guidelines anyway - I know it's difficult (you may > check the Apache JServ archives for my own story of getting used to the code > conventions - man, did I get flamed ;) ha ha > > I've fixed the zero size bug, but if indent decides to be funny - there's no > weapon against that. Only time will tell. indent bug is understandable, as long as if indent returns error code we read it and handle it properly. |
Thanks for helping keep SourceForge clean.
X