[QUOTE=Prime95;299744]Submit the successful triple-check first.

If you submit the bad double-check first, then there is a window where the server will make the exponent available to some poor unsuspecting user for a triple-check.[/QUOTE]

Indeed. If you submit, nothing happens -- if I submit, I lose the assignment for the exponent.

Hmm, I only just now read that I was wrong. I guess the lesson is don't upgrade drivers during a test... first mismatch I've had with 2.00. (Out of 8-10 or so. I'm not on 2.01 yet, though I will be soon.)

[QUOTE=Dubslow;299659]Could someone help me understand what this code does?

[/QUOTE]

[QUOTE=Batalov;299660]Looks like it checks if a key was pressed, and if so, put it back in the queue but signal the caller that a character can now be retrieved.


P.S. A copy of the normal term i/o handler is created except it is now non-blocking. If you ask for a char from normal code, it will sit doing nothing _until_ you press the key. Here, this routine will report to the caller - "there was no activity, carry on".[/QUOTE]

[QUOTE=LaurV;299670]Because in that case (your code) the computer is locked until you decide to press the dammit key. The monkey bar joke. When I was child I did a lot of quarters with "I bet you a quarter you can't hang on it until I count to 10". Many of my friends took the bet, then I was counting very fast to 9, and going away living them hanging on the bar. Eventually they felt down and lost the bet, because they could not hold on it [U]until[/U] I counted to [U]10[/U].

The original code does a lot of work to modify the behavior of the getchar() routine to return immediately in case no key was already pressed, without waiting for the key, and if a key was pressed, to get its [U]scan code[/U], (accepting key combinations, like CTRL+ALT+F12), and terminate if ctrl+c was pressed. After the key is read, the old behavior (waiting for the key) is restored.

Se for details [URL="http://www.daniweb.com/software-development/c/threads/147540/how-can-we-get-scan-code-in-c-using-gcc-compiler"]here[/URL] and [URL="http://www.daniweb.com/software-development/cpp/threads/331393/to-generate-keystrokes-using-c-linux-os"]here[/URL] (follow the fork link in that post).[/QUOTE]

If I only cared about the first character, could I do something like this?
[code]char
_kbhit (void)
{
struct termios oldt, newt;
int ch;
int oldf;

tcgetattr (STDIN_FILENO, &oldt);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO);
tcsetattr (STDIN_FILENO, TCSANOW, &newt);
oldf = fcntl (STDIN_FILENO, F_GETFL, 0);
fcntl (STDIN_FILENO, F_SETFL, oldf | O_NONBLOCK);

ch = getchar ();

tcsetattr (STDIN_FILENO, TCSANOW, &oldt);
fcntl (STDIN_FILENO, F_SETFL, oldf);

if (ch != EOF)
{
[strike]ungetc (ch, stdin);
return 1;[/strike]

[U]return ch;[/U]
}

return 0;
}[/code]
And then instead of: [code]
if( _kbhit() ) { char c = getchar(); /* do something */ } [/code]
we could just do [code]if( char c=_khbit() ) { /* do something */ } [/code]

You then may need to process all the characters, and return back to the OS the characters which are not yours. Otherwise you just hooked the kbd for yourself for as long as the program is running... In single task your modification would work perfect. Now imagine you have multitasking and some process in the background is calling kbhit in a loop (therefore discarding all the characters that enters the buffer of the peripheral). There will be no way for you to input something, in your foreground process (calculator, text editor, cmd line, whatever). Returning the character (instead of 1) is ok, and maybe useful, but "not putting it back in the buffer" is a bad practice. Some other guys in the system may need it.

edit: :threadhijacked:

[QUOTE=LaurV;299788]You then may need to process all the characters, and return back to the OS the characters which are not yours. Otherwise you just hooked the kbd for yourself for as long as the program is running... In single task your modification would work perfect. Now imagine you have multitasking and some process in the background is calling kbhit in a loop (therefore discarding all the characters that enters the buffer of the peripheral). There will be no way for you to input something, in your foreground process (calculator, text editor, cmd line, whatever). Returning the character (instead of 1) is ok, and maybe useful, but "not putting it back in the buffer" is a bad practice. Some other guys in the system may need it.

edit: :threadhijacked:[/QUOTE]

Well, we're talking about a terminal which is controlled by the program running. Even the first option, the guy calling kbhit() just re-gets the char anyways. (Perhaps a supermod could move these posts to the programming forum?)

[QUOTE=Dubslow;299790]Well, we're talking about a terminal which is controlled by the program running. Even the first option, the guy calling kbhit() just re-gets the char anyways. (Perhaps a supermod could move these posts to the programming forum?)[/QUOTE]
There is only ONE kbd buffer. Your terminal uses it, as the text editor uses it, as the OS itself uses it. Same idea is used by programs like "snagit" or whatever, which defines "hotkeys". You press alt+f11 in any window you are, snagit pops up and copy the window content in a gif. Now assume snagit will read all the keys, and if it is not his key, just discard it. You won't be able to use the kbd anymore.

[QUOTE=LaurV;299794]There is only ONE kbd buffer. Your terminal uses it, as the text editor uses it, as the OS itself uses it. Same idea is used by programs like "snagit" or whatever, which defines "hotkeys". You press alt+f11 in any window you are, snagit pops up and copy the window content in a gif. Now assume snagit will read all the keys, and if it is not his key, just discard it. You won't be able to use the kbd anymore.[/QUOTE]

What text-editor? I'm talking about the -k switch from CUDALucas, hence why I don't care about the characters after the first one. (or at least, how to port that code to MPrime).

I was talking "generally". Put the char back into the buffer. Why this bothers you? Let the OS do whatever he likes with it (for example printing it on screen, otherwise you have even to print it by yourself). I don't know what you wanna do "particularly". Try experimenting. This is how you learn :D
Keep the version that works as you like.

Now really a mod should move these posts...

[QUOTE=Dubslow;299748]I guess the lesson is don't upgrade drivers during a test... first mismatch I've had with 2.00. (Out of 8-10 or so. I'm not on 2.01 yet, though I will be soon.)[/QUOTE]
Well, I accidentally installed another update during the next test and that [URL="http://mersenne.org/report_exponent/?exp_lo=25853563"]matched[/URL], so... cosmic ray?

[QUOTE=Dubslow;299815]Well, I accidentally installed another update during the next test and that [URL="http://mersenne.org/report_exponent/?exp_lo=25853563"]matched[/URL], so... cosmic ray?[/QUOTE]
I had really bad luck with 2.00. 2.01 seems better for me, but I haven't done DC in a while since I moved all my cards to TF for a while.

I've got a mismatch with 2.0 for 29668031.

Could someone run it with P95?

Thanks,
Andriy

[QUOTE=apsen;299971]I've got a mismatch with 2.0 for 29668031.

Could someone run it with P95?

Thanks,
Andriy[/QUOTE]


M29668031, Lucas-Lehmer test, Fri May 25 23:00 2012