libphidget-devel Mailing List for Phidget Library (Page 4)
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel — Mailing list for developers of libphidget
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(134) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jack S. <js...@ja...> - 2002-09-12 00:34:56
|
On Wed, 2002-09-11 at 19:17, Vadim Tkachenko wrote: > According to Jack Strohm: > > > So, when do you think you'll be ready to merge the INDENT branch back > > in? > > Now? did you run "make indent" before you checked it in, or do I need to run it. I checked it out and when I ran "make indent" and then "cvs diff" I got a few differences. Only once, each run of "make indent" after that didn't change it anymore. |
|
From: Jack S. <js...@ja...> - 2002-09-12 00:19:30
|
On Wed, 2002-09-11 at 19:17, Vadim Tkachenko wrote: > According to Jack Strohm: > > > So, when do you think you'll be ready to merge the INDENT branch back > > in? > > Now? I've been playing with the INDENT branch and it seems good to me. So now is fine with me :-) |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 00:18:00
|
According to Jack Strohm: > So, when do you think you'll be ready to merge the INDENT branch back > in? Now? --vt |
|
From: Jack S. <js...@ja...> - 2002-09-12 00:10:09
|
So, when do you think you'll be ready to merge the INDENT branch back in? |
|
From: Jack S. <js...@ja...> - 2002-09-11 05:07:53
|
On Wed, 2002-09-11 at 00:05, fit...@ph... wrote: > > Rough guess 50 - 200ms? Wouldn't want to bet on that, though. Depends on > the PC. The USB device disappears and a new one is enumerated, with your > firmware VID/PID. Ok, so pretty quickly, not like a PC :-) (I assumed it would be under a sec). |
|
From: <fit...@ph...> - 2002-09-11 05:05:07
|
Rough guess 50 - 200ms? Wouldn't want to bet on that, though. Depends on the PC. The USB device disappears and a new one is enumerated, with your firmware VID/PID. Chester > Chester, > > Just read thru the documentation you posted, I was wondering after the > firmware has been loaded into the phidget, how long does it take it to > "reboot" and reattach? > > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel > |
|
From: Jack S. <js...@ja...> - 2002-09-11 05:01:30
|
On Tue, 2002-09-10 at 23:53, Vadim Tkachenko wrote: > According to Jack Strohm: > > > I tested it on my Gentoo box > > What's Gentoo? Distribution? Source based distro, it's pretty cool, compiles exactly want you want. It's pretty slow to install. On my Pentium 266 laptop it took about 24 hours, (I didn't use any binaries, complete source install). Most of that was compiling the compiler. Kernel rebuilds take about 2 hours, but I think I get everything the way I like it Nice thing is that I complete control the configuration. For example if you want vim installed in Mandrake you have to install X also. This is because the vim package also contains the gvim (gui version of VI). Now I told Gento not to compile any X packages so when vim was being configured it took note of that and didn't create gvim, very cool!. Best thing is that on this little box with only 64MB of ram, my apps and OS only take up 14 megs on bootup. This is the box that is going to be used in my robot I'm building. Want it as lightweight as possible. > > > and it configured and compiles without any problems. Haven't actually run > > it yet, have to hook up my phidgets to it. Maybe tomorrow I will. > > Have you tried to 'make rpm' and install the rpm? nope, not yet, I'm about to go to sleep, but I'll try it tomorrow on a box at work running Mandrake, see how it goes |
|
From: Jack S. <js...@ja...> - 2002-09-11 04:57:24
|
Chester, Just read thru the documentation you posted, I was wondering after the firmware has been loaded into the phidget, how long does it take it to "reboot" and reattach? |
|
From: Vadim T. <vt...@fr...> - 2002-09-11 04:53:52
|
According to Jack Strohm: > I tested it on my Gentoo box What's Gentoo? Distribution? > and it configured and compiles without any problems. Haven't actually run > it yet, have to hook up my phidgets to it. Maybe tomorrow I will. Have you tried to 'make rpm' and install the rpm? --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 04:51:03
|
I tested it on my Gentoo box and it configured and compiles without any problems. Haven't actually run it yet, have to hook up my phidgets to it. Maybe tomorrow I will. |
|
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. |
|
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: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: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: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: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: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 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 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: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: Vadim T. <vt...@fr...> - 2002-09-11 01:33:18
|
According to Jack Strohm: > Although, since you don't have doxygen installed you don't notice it, I > would make change it so that to generate documentation you have to do: > > make docs > > or something, right now it makes new documentation every compile (not > that it's slow, but it does print out a bunch of messages I usually > don't care to see). True. I'll fix that. I was thinking about introducing a rule to effect of making doxygen generate the code only if the source files have changed. I have a box with Doxygen installed now - set up RH 7.3 on my old box day before yesterday. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-11 01:30:38
|
Although, since you don't have doxygen installed you don't notice it, I would make change it so that to generate documentation you have to do: make docs or something, right now it makes new documentation every compile (not that it's slow, but it does print out a bunch of messages I usually don't care to see). |
|
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-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: Vadim T. <vt...@fr...> - 2002-09-10 03:30:29
|
According to Jack Strohm:
> I'll see what I come up with
Try to get the INDENT branch, and do this:
while (!bothered enough) {
make indent
make
}
It should compile just once, and never again (at least this is what it does
at my box). Meaning that indent is idempotent.
I'll take a couple hours of timeout now, and upon return will figure out how
does it interfere with 'make indent-local' - if you feel like it, do it and
let me know.
I think the key was increasing the line length to 128 - it stopped being
puzzled by funny <> symbols when trying to break the line...
--vt
|
