Lull

I thought I should probably post here again, since I haven't in over two weeks.

I have not been programming very much or at all in these last few weeks for several reasons, none of which have anything to do with a lack of ideas or motivation. Mostly, I have been incredibly busy (tis/twas the season) and have been working on several other projects at the same time.

• I have been trying to find uses for old and/or broken computer parts, so I have been tearing them apart down to individual electronic components and bits of circuit board in hopes that I might be able to make them into jewellery or decorations of some sort. 
• I have been cleaning and organizing my own room as well as other parts of my family's house, which is a Sisyphean task.
• I have been driving a lot and running errands, so I am out of the house too often to sit and program for hours on end. 

Generally speaking, I'm afraid to start on anything because I may not be able to finish - and I can't stand leaving things unfinished!

That said, GJSieve 2.5.0 is very much still unfinished. Currently, the "quick run" option is crudely implemented and doesn't really work very well, if at all. The ideas I have to make it better and smoother are:

• Make global variables for determining and reporting the testing range
• Make a wrapper class that is owned by the main window class and is responsible for creating and managing the worker classes, which in turn manage the testing thread(s)
• Have the wrapper class contain variables that are updated via signals from the worker and update statistics on the test
• Have the wrapper class receive signals from the threads in order to update the GUI in real-time
• When a test begins, fill the newly-created (or already-existing) worker class instance with a new candidate number at the chosen k and the current number in the range
• When a test ends, rather than exiting the thread, a signal will be sent to the wrapper class instance to find the next candidate number at the chosen k using the next number in the range
• When the last number in the range is reached, the wrapper class will be responsible for sending signals that exit the threads and printing statistics on the entire sieve run
• Have the wrapper class responsible for clean-up
• Delete the wrapper class instance when safe to do so

This is just for quick runs at the moment. I will eventually have to implement this for all testing types.

I am still debating whether to keep verbose and reverse BFTD testing in this iteration of GJSieve. If it is to be a true "sieve," there is no real reason to factor a candidate number in its entirety! What may end up being the actual available testing options are quick runs, triple-threaded BFTD, and six-threaded BFTD.

The latter two will of course work the same way as verbose and reverse already do, but it would be tricky to write because the threads will need to send signals to the worker almost constantly, which would trigger a slot that signals all threads if a factor has been found. That's just so when one thread finds a factor, they all stop. I know it can be done, but it will be difficult - especially for the reverse testing!

This will all come to fruition in 2013, I can promise you that much.