Continued Development - KidneyThief/TinScript1.0 GitHub Wiki

Development of TinScript is an ongoing effort. The current implementation is complete in its feature set - in that there is nothing it does that is only partially implemented. However, there are features missing - mostly C++ related concept - that will be implemented as time permits:

Table of Contents Syntax Strings Hash Algorithm Internal Implementation Multithreading Debugger

• 'do - while()' statements have not yet been added to the syntax.
• 'switch' statements have also not yet been added.
• 'enum' as a type will be added - including registration from C++.
• Arrays... this is a hugely important feature to be addressed soon.
  • We have global associative arrays, CObjectGroup and CObjectSet implementations that can be used to solve many problems requiring the use of normal arrays - but the language will not be complete until regular arrays are supported.

• The one type registered with TinScript that does not have a defined size, further development supporting strings is a priority.
• Currently, strings are registered as a const char*, and the string table allocates a large buffer to store all literals, then provides a hash table of refcounted entries to manage their assignment. Cleanup of unused strings only happens when a function has finished executing. In the spirit of "garbage collection", all unassigned string literals are removed.
• I intend to implemented an actual String class to resolve three issues:
  • First, to provide better support for when the string table is "full"
  • Second, to protect code from memory stomping the values of a const char* that has been registered. (Currently the interface TinScript::SetGlobalVar() is 100% safe for manipulating registered string variables, but it isn't enforced.)
  • Third, unassigned strings are only cleaned up from the end of the string table, as a const char* isn't a handle. A String class that resolves a handle would allow *all* unassigned strings to be removed.

• What happens when there's a collision in the Hash() of two different strings?
  • An assert is generated, so this should never happen silently.
  • If the collision involves an identifier (variable/namespace/function name), there's no choice but to rename one of the colliding identifiers, as compiled code doesn't have the benefit of resolving collisions.
  • Once a project's scripts are complete and there are no collisions, their execution is assured.
  • If the collision is a string literal... it's a data issue, so there may be no way to protect against the randomness of a users string usage.
  • At the very least, exposing the Hash() implementation, allowing it to be customized will help resolve issues on a "per project" basis.

• Conditional expressions are fully evaluated and not preempted.
• Infinite loops are possible in TinScript, just as in C++. However, adding detection to the virtual machine, and asserting cleanly would be a benefit.
• Stack limitations - not unlike infinite loops, being detected and cleanly asserting will be a worthwhile improvement.

• As of right now, the multi-threaded verification of TinScript exists in the functional test BeginMultiThreadTest(). Verification that each has its own separate context, that objects can be instantiated, and they have their own dictionaries of variables / functions / members / methods, etc... has been established.
• Each thread is required to be created separately, non-concurrently, as the process of initializing a script context is not thread safe. However, once the contexts are created, they operate independently and are as thread safe as any other piece of code (as far as they've been tested, that is).
• Providing an interface to customize exactly which classes and functions are registered to each thread, as well as minimizing the duplication of the string table would be a benefit to the language.

• I've actually written a full debugger, implemented in QT. Unfortunately, this requires a separate installation of QT, as well as updating the solution to resolve dependencies and include directories. (Understandably, since QT uses .dll's, and not .lib's.)
• In the near future, I'll be working on converting the existing debugger to be remote, allowing it to connect to an IP address that is running an application with TinScript integrated.
• From there, the debugger features will continue to be developed (data breakpoints, conditional breakpoints, a more flexible watch window)...
• I plan to add a view of the object list (including the hierarchical organization of CObjectGroups, the same output as ListObjects())
• I will also be adding an object inspector (an editable display of the hierarchy of dictionaries of registered members).
• If I add an object creator - a list of instantiable classes and namespaces, I'd almost have an IDE!