#include "stdafx.h"
//#include <mbctype.h>

/*	Any code here can be deleted at will without impact on the
	functioning of the program.

This routine gets called during every unit test, and can log its results
	to the log window.  It should normally do absolutely nothing,
	because useful working code should be moved the appropriate
	files, and broken code should be thrown away

Anything here is a residue of forgotten experiments, and can safely
	be thrown away.  If any experiments have value, they will be
	have been recorded in git.  Nothing here is needed.  If it was
	needed, would have been moved.

Namespace testbed is only defined in this cpp file, hence nothing within
	this namespace can be accessed from anywhere else.
	except the routine testbed

If it needs to interact with the outside world, should post a message
	analogously to  queue_error_message, which then calls back to a
	routine in this file.*/
void ascii2test();
extern const uint8_t* const ascii2six;

namespace testbed {
	using ristretto255::hash, ristretto255::hsh, ristretto255::scalar,
		ristretto255::point, ro::serialize, ro::bin2hex, ro::hex2bin,
		ro::bin2hex, ro::fasthash,ro::CompileSizedString ;
	static constexpr char SrcFilename[]{ "src/testbed.cpp" };

/*	experimental code called during unit test
	Anything here is a residue of forgotten experiments,
	and can safely be thrown away

This is a playground, where you can do stuff without worrying you might
	inadvertently break something that matters

Output goes to the unit test log.

No mechanism for input is available.  You generally do not need it 
	because you	hard code the testing data, and detect errors with
	asserts, rather than exceptions	but, of course, it can post a
	dialog using postmessage, and the dialog can then call anything.  

Uncaught exceptions result in unit test failure, and an error message
	at the end of the unit test, but not in an error message in the
	main program UI.

If using postmessage, execution of the code waits for the dialog to
	return, data from the dialog can be used in the testbed code, and 
	uncaught exceptions in the dialog will result unit test failure
	and be reported in the unit test log.

If using queumessage, the testbed code will complete while the dialog
	is waiting, data cannot be returned for use in the testbed code,
	and uncaught exceptions will appear in the main UI.
	*/

	void testbed() {
	//	queue_error_message("hello world");
	//	throw MyException("hello world exception", __LINE__, __func__, SrcFilename);
	}
}