t3d programming
t3d executable program is a multi-purpose program which can:
t3d programming environment is a combination of user defined resources and the resources provided by the t3d programming system.
All t3d programming system parts must be written into a t3d.ini file, which must be put to its default location. Standard ini file position makes tasks easier for the web server and system administrators.
t3d sources are compiled into a excutables using typical (modern) C compilers. The default (preprocessor, compiler & linker) is GCC.
t3d programming language specialties are inserted into sources by a dedicated pre-pre-processor, which prepares the sources ready for the (GCC) compiler.
if the (GCC) compiling is successful, a ready to use executable file is produced - if the compiling / linking failed, the t3d executable commands the post-processor into in interpreting the GCC error output.
GUI (graphical user interface) is good and modern. C programs do not have a build in GUI system and the Java(TM) currently has the best most portable GUI system.
If possible the t3d graphical display system will be borrowed (*) from Java(TM), but used using the t3d programming language!
Two executables are needed GCC-compiled (compare brain) and a GUI.exe, which is the 'brainless' one (compare face).
GUI.exe will not have more than logic than what is required for simple 'if - elses' AND doing commanded showing (of the told GUI objects and the told GUI table parts) AND receive input (user/socket) AND give output (to user/socket).
Thus all the intelligence within the t3d programs must be build into GCC compiled executables.
Socket communication is the default communication method, but if it is not always possible there are other options for interprocess communication (files, shared access memory ect.).
The principle is simple and it works (has worked before).
t3d programming Language
t3d programs can be run as a standalone programs, shell scripts or as web scripts. t3d is C99 based and should be compilable with GCC or other C compilers of similar quality.
It is possible to do t3d programming even using other programming languages (Perl, Pascal, COBOL, Ada,...) those t3d dialects go under a common name x3d languages. Basically each x3d- function/ x3d-gene should have an almost identical prototype structure as a similarly working t3d function prototypes has.
t3d is a massive project but ultimately there should be an easy to use tools for pretty much every task. Meaning that once someone provides a useful tool, it is distributed into tool bags of others; among the million other easy-to-use & if-I-need-it-I-know-how-to-use-it tools .
All t3d tools together form a structure called "t3d-genome" and each tool is a "t3d-gene". t3d-genes can call for individual functions, libraries or even such external utilities which a particular t3d-gene is able to use. Typically each t3d function/ gene has many alias names. Any alias name, which the users like, is a good one; including computer slang and expressions using foreign languages.
With t3d almost nothing computer related is off- topic, because each t3d- gene just doesn't have to be supported within each computer environment. A valid t3d-gene which could be for example be used for opening a roof from a Toyota Lexus with a following commands:
So, the programming environment for the t3d programming does not need to be too limited, of cause that example is pretty extreme. However the idea is that any developer with two brain cells or more should be able to correctly call any t3d-gene independently whether the coder knew that such t3d-gene existed or not.
discussion starters:
Because the t3d genes may be called / used with simple shell commands e.g.
It is possible that one day such script tool would be popular office tool for non-programmers, and then it would mean that the charity organizations would be able to sell a significant amount ChOS license usage permissions for commercial users, because the t3d is licensed under the Charity Open Source license.
(click to enlarge images)
In the nutshell the GUI-system is as follows:
** There even funny / practical side effects with the arrangement e.g. the two exes can also monitor each others conditions.
Thus it is possible for one executable to crash / halt while another executable can try to revitalize the 'dead' one.
Thus if the revitalization succeeds the revitalized exe can always get a (potentially valuable) error report of the last before death instructions.
Read the last two pages of the ChOS license draft!
or just the two language pages!
then continue...
if(t3d_environment_IS_TOYOTA_n_LEXUS())
{
t3d_open_ROOF_WINDOW();
}
else
{
t3d_write_CONSOLE("Not a Toyota LEXUS");
}
c:\lectures\t3d 't3d_convert_file_Rfile_SOUND2TEXT(\"lecture7.wav\",\"lec.txt\") ;'
c:\lectures\t3d 't3d_convert_file_Rfile_TEXT2HTML(\"lec.txt\",\"lecture7.html\") ;'