Update - All global vars eliminated

[GoogleCodeExporter]

Now *that's* what I'd call modular :) . Wee.

Original issue reported on code.google.com by vanhtu1...@gmail.com on 26 Jan 2008 at 1:40

Attachments:

• whiteboard_20_7.patch

[GoogleCodeExporter]

Sorry, here is the patch without trashes

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 1:42

Attachments:

• whiteboard_20_7.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

compiles & runs no hitches except how do we use left click now?

Original comment by lavac...@gmail.com on 26 Jan 2008 at 4:48

[GoogleCodeExporter]

I have a question: If we call update_cursor in "infrared_data", how do we know 
when
to issue a "buttondown" event? I've observed that in the patched versions (with 
your
code), the mouse button stays down all the time (do you have this issue?). I'm 
trying
it in Debian testing.

This problem doesn't appear if you call update_cursor() in the cwiid callback. I
don't know why.

As for the C/C++ thing... If you want to re-implement all the code in C++, you 
should
do it.

You have done a great job. New Makefile, separation in "auxiliary.c", etc... 
These
are great additions and I want them in my code. I want it to be in C, although. 
And I
want to keep the matrix functions they are now.

Maybe we can branch the development at this point. C and C++ version? can they 
be
hosted in the same repository here in google code?

Original comment by pere.ne...@gmail.com on 26 Jan 2008 at 5:19

[GoogleCodeExporter]

lavacano: Please bear with me. I've proposed a new way to handle multiple 
control
schemes. All these modifications made little sense to normal users. But when 
these
functionalities are implemented, the benefits should be obvious. That's a place
holder for now :) .

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 5:48

[GoogleCodeExporter]

Pere: Don't worry, although I've transformed matrix.c to C++ with templates. 
Most
functions stay the same. You can take a look at the newest patch (I will post 
it in a
moment). Porting it back to C should only require 15 or 20 minutes.

The current version doesn't fake a mouse down event at any point. At most it 
only
moves the cursor. Maybe you used an older patch?.

I can further refactor matrix.c so that the basic functions only works with 
arrays of
numbers. So that they have no idea whether they are being used in a normal C
function, or in a C++ struct. That would require passing 'pointer to array', 
'width'
and 'height' of the matrix instead of a simple reference to a matrix object.

The matrix.c itself is not a problem :s as there are loads of heavy 
implementations
on the 'net. But overall, using C poses much greater danger of bugs and boiler 
plate
code, which I don't prefer to manage once it gets big enough.

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 6:10

[GoogleCodeExporter]

I'm not sure what you mean though. Because if the code gets fully transformed 
to C++,
I will use it extensively. A few of which are: cout whenever printf is needed,
passing references instead of pointers so no NULL pointers go unchecked, or get 
rid of:

matrixGetElem(&m, 0, 1) = matrixGetElem(&n, 1, 2);
matrixGetElem(&m, 0, 2) = matrixGetElem(&n, 1, 3);
matrixGetElem(&m, 0, 3) = matrixGetElem(&n, 1, 4);
matrixGetElem(&m, 0, 4) = matrixGetElem(&n, 1, 5);
...
matrixSetElem(&m, matrixGetElem(&n, 3, 4), 7, 6);

and replace those with:
m[0][1] = n[1][2];
...
m[7][6] = n[3][4];

C is a thing of the past, even when you're dealing with system stuff which 
requires
absolutely perfect performance, since assembly is more suited in which case. 
Remember
when people disgusted C because of "C is so slow, assembly is teh pwz0r!!!1" ?.
Productivity is a good thing.

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 6:22

[GoogleCodeExporter]

We need a buttondown event. The strategy were to issue a buttondown event in 50
microseconds if there had not been any IR event.

With the "sleep" hack, we can no longer to this. I've tried to use "usleep" 
instead
of sleep. The main loop became:

while (!can_exit)
{
  usleep(100);
  update_cursor();
}

But this leads to errors, because we are calling update_cursor without checking 
if we
are already in update_cursor!.

Maybe we can use POSIX semaphores to avoid this condition?

What solution do you propose?

Original comment by pere.ne...@gmail.com on 26 Jan 2008 at 6:30

[GoogleCodeExporter]

s/buttondown/buttonup above.

The buttondown event is simulated when IR activity is detected. Then, the 
buttonup
event is issued in 50 microseconds if there weren't any IR events in that 
interval.

Original comment by pere.ne...@gmail.com on 26 Jan 2008 at 6:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oh, you updated it. Please wait while I sync my new code to yours.

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 7:11

[GoogleCodeExporter]

Here it is :) . The patch still seems huge though.

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 7:17

Attachments:

• whiteboard_21_1.patch

[GoogleCodeExporter]

I'm working to get almost all of your changes to the repository. I've found this
issue and I'm looking for a way to solve it.

In the svn, it's almost the same code as in revision 20. Only the "sleep hack" 
is new.

Your patches are getting their way in. Slowly but surely.

Original comment by pere.ne...@gmail.com on 26 Jan 2008 at 7:18

[GoogleCodeExporter]

I'm sure the newest code handles it properly, since it only 'wakes up' when 
signals
arrive, and you'll not miss any event.

Original comment by vanhtu1...@gmail.com on 26 Jan 2008 at 7:32

[GoogleCodeExporter]

whiteboard_21_1.patch compiles and runs no hitches.

Original comment by lavac...@gmail.com on 26 Jan 2008 at 9:40

[GoogleCodeExporter]

Vahtu, most of your changes made their way into the repository. Check the 
updated
versions.

Nice work. As for the discussion C o C++, like I said earlier, I feel more
comfortable in C.

People begin to ask for a GUI. I don't think it's necessary, but I understand 
that it
would be a great thing to improve the usability of the program. I'm not crazy 
and I
agree that C++'s is a better tool for this job (the GUI).

Since C++ can call C functions, maybe the core program can remain in pure C, 
and the
GUI can be constructed with QT or GTK...

Original comment by pere.ne...@gmail.com on 26 Jan 2008 at 11:31

[GoogleCodeExporter]

Actually I didn't think of any sophisticated GUIs since this program inherently 
runs
in the background, and the only GUI to calibrate the Wii had already been 
written by
you. I thought of making whiteboard calls 'zenity' to bring up some graphical 
dialogs
(informations, questions, error messages) and that's it.

I believe porting it back to C only involves repetitive works (as of now, there 
are
only minor syntactical differences) and it'd better be done in C++ to avoid 
bugs and
helps making the program easier to understand (as you've seen with the matrix 
code). 

All in all, you wouldn't want to put off potential contributors just because 
it's
been riddled with malloc(), free() and global vars everywhere. The reason I 
joined
this project, aside from being interested, is that it was small enough to port 
it to
something simpler. Had it been a complex piece of code which took one days to 
figure
out what it does, I'm sure many people just wouldn't bother.

Anyway, we can always ask someone to port it back to C since it doesn't change 
the
basic structure of the whole, we may even have someone keep an updated C 
version if
necessary. *But* they have to understand it first!. The current version is 
fairly
easy to grasp in my opinion.

Original comment by vanhtu1...@gmail.com on 27 Jan 2008 at 2:04

[GoogleCodeExporter]

Work on multiple control schemes is already in progress, I hope I can release a 
demo
version soon. This one requires an even greater deal of standard C++ library
(vectors, pairs, iterators...) because it involves lots of memory handling code.

Currently my goal is to hard-code one control scheme which many people would 
want in
the source code. After that I can write a parser to let users configure it.

When it comes to parsing configuration files, I don't even want to think in C 
;s . If
anything, I'd like to use an XML parser or a simple text parser library in C. 
NIH
Syndrome is evil!.

Original comment by vanhtu1...@gmail.com on 27 Jan 2008 at 2:10

[GoogleCodeExporter]

This is my latest snapshot, you can take a look if you'd like. It's got a lot of
comment on how the new thing works :) .

Original comment by vanhtu1...@gmail.com on 27 Jan 2008 at 2:17

Attachments:

• whiteboard_23_1.patch

[GoogleCodeExporter]

Here is my latest snapshot, it's got some bugs lurking around so it's not 
usable at
the moment. I'm going to add unit tests tomorrow. Only 3 new functions have been
introduced, but a whole slew of new logic complicated the case.

Original comment by vanhtu1...@gmail.com on 28 Jan 2008 at 1:30

Attachments:

• whiteboard_23_2.patch

[GoogleCodeExporter]

Unit testing sure helped :) In 20 minutes I found 6 bugs that were invisible to 
me
previously. I'm looking forward to a new release before the end of tomorrow.

Original comment by vanhtu1...@gmail.com on 28 Jan 2008 at 2:56

[GoogleCodeExporter]

Here is my latest snapshot. The code 'seems' to work but it looks like I
misunderstood how the Wii sends button and IR events. For example: Pressing 1 
button
translates it to 2 events: BUTTON_DOWN and BUTTON_UP, same goes with IR events.

Original comment by vanhtu1...@gmail.com on 28 Jan 2008 at 11:03

Attachments:

• whiteboard_23_3.patch

[GoogleCodeExporter]

Found it, that was my problem :) .

Original comment by vanhtu1...@gmail.com on 28 Jan 2008 at 11:07

[GoogleCodeExporter]

Original comment by vanhtu1...@gmail.com on 31 Jan 2008 at 9:44

• Changed state: Fixed
• Added labels: Type-Patch
• Removed labels: Type-Defect