<commit_before>How do we incorporate fault tolerance into JAMScript?

IDEA: Use some form of blocks. Use jamX blocks.

IDEA: Use conditions in JAMScript language to conditionally
execute the blocks.
  = REPEAT blocks
  = CONDITIONAL blocks
  = CHECK blocks
  = LOGGING blocks

IDEA: Use Stack traces to specify where in the call stack the error happened.
C would not support this natively. We need JAMScript runtime supporting call stacks
and printing out stack traces. This might add fault locationing to the code.

IDEA: Stick to RPC as the basic paradigm. Can we extend on the "jamdef" signature?
This way the RPC call will be broken into a three stage pipeline. Client-Intermediate-Server.

TODO: What can be done at the intermediate node? This can be programmed in JAMScript.
So the intermediate is going to be solely JAMScript programmed.

Using this model, we can make a C/C++ -> JavaScript or JavaScript -> C/C++ call through
JAMScript. The JAMScript could do the following

= Filtering of calls
= Aggregation of calls
= Transformation of calls or parameters
= Replying to calls preemptively
= Other possibilities

== Can we improve the reliability of RPC using the intermediate model? At first glance,
it seems using an intermediate node decreases the overall reliability. Is this actually true?

TODO: Call stack tracing could be turned on as part of the machine definition. One part
of the call stack tracing might be to log abnormal situations. Can we also use this for
watch dog timer type of exceptions?<commit_msg>A note on the typing differences between C and JavaScript.<commit_after>How do we incorporate fault tolerance into JAMScript?

IDEA: Use some form of blocks. Use jamX blocks.

IDEA: Use conditions in JAMScript language to conditionally
execute the blocks.
  = REPEAT blocks
  = CONDITIONAL blocks
  = CHECK blocks
  = LOGGING blocks

IDEA: Use Stack traces to specify where in the call stack the error happened.
C would not support this natively. We need JAMScript runtime supporting call stacks
and printing out stack traces. This might add fault locationing to the code.

IDEA: Stick to RPC as the basic paradigm. Can we extend on the "jamdef" signature?
This way the RPC call will be broken into a three stage pipeline. Client-Intermediate-Server.

TODO: What can be done at the intermediate node? This can be programmed in JAMScript.
So the intermediate is going to be solely JAMScript programmed.

Using this model, we can make a C/C++ -> JavaScript or JavaScript -> C/C++ call through
JAMScript. The JAMScript could do the following

= Filtering of calls
= Aggregation of calls
= Transformation of calls or parameters
= Replying to calls preemptively
= Other possibilities

== Can we improve the reliability of RPC using the intermediate model? At first glance,
it seems using an intermediate node decreases the overall reliability. Is this actually true?

TODO: Call stack tracing could be turned on as part of the machine definition. One part
of the call stack tracing might be to log abnormal situations. Can we also use this for
watch dog timer type of exceptions?


TODO: Challenge #1
JavaScript is a dynamically typed langauge and C/C++ is statically typed.
Combining these two are bound to bring some very interesting problems which are yet
to be fully investigated here. I guess we will sidestep these issues for now. However,
we need to discuss them and ensure we are not looking at insurmountable problems down
the road.

If you have any thoughts on this challenge, please bring it to the discussion.
{'fraction_non_alphanumeric': 0.036389280677009875, 'fraction_numerical': 0.00028208744710860365, 'mean_word_length': 4.340361445783133, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6291145', 'n_tokens_mistral': 893, 'n_tokens_neox': 863, 'n_words': 552}