Updated cmp files and couple other minor modifications

This commit is contained in:
Darren Gehring 2021-03-09 16:38:02 -08:00
Родитель 1b4b77336a
Коммит e4362e7db5
25 изменённых файлов: 469 добавлений и 158 удалений

Просмотреть файл

@ -52,7 +52,8 @@ export namespace Test
export enum Letters { A = 0, B = 3, C = 4, D = 9 }
/**
* Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Example of a [post] method that uses custom types.
*/
export function makeName_PostFork(callContextData: any, firstName?: string, lastName?: string): void
@ -63,7 +64,8 @@ export namespace Test
}
/**
* Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Example of a [post] method that uses custom types.
*/
export function makeName_PostImpulse(callContextData: any, firstName?: string, lastName?: string): void

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -192,6 +206,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/ASTTest.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/ASTTest.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -9,22 +9,27 @@ import Utils = Ambrosia.Utils;
let DESTINATION_INSTANCE_NAME: string = "server";
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
/**
Test File to test all the the ways that the ambrosia tag can be set and still work
*/
export namespace Test
{
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function OneLineNoComment_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "OneLineNoComment", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function OneLineNoComment_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "OneLineNoComment", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Multi Line with Comment before Tag
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Multi Line with Comment before Tag
* but still before tag
*/
export function MultiLineCommentBeforeTag_PostFork(callContextData: any): void
@ -32,8 +37,10 @@ export namespace Test
IC.postFork(DESTINATION_INSTANCE_NAME, "MultiLineCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Multi Line with Comment before Tag
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Multi Line with Comment before Tag
* but still before tag
*/
export function MultiLineCommentBeforeTag_PostImpulse(callContextData: any): void
@ -41,60 +48,72 @@ export namespace Test
IC.postImpulse(DESTINATION_INSTANCE_NAME, "MultiLineCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function MultiSeparateLinesCommentBeforeTag_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "MultiSeparateLinesCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function MultiSeparateLinesCommentBeforeTag_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "MultiSeparateLinesCommentBeforeTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/************** Have a space after the tag before function declaration
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ************ Have a space after the tag before function declaration
*/
export function EmptyLineBetweenTagAndFctn_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "EmptyLineBetweenTagAndFctn", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/************** Have a space after the tag before function declaration
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ************ Have a space after the tag before function declaration
*/
export function EmptyLineBetweenTagAndFctn_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "EmptyLineBetweenTagAndFctn", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/****** Spacing around the tag
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* **** Spacing around the tag
*/
export function SpacingAroundTag_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "SpacingAroundTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/****** Spacing around the tag
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* **** Spacing around the tag
*/
export function SpacingAroundTag_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "SpacingAroundTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** JS Doc
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* JS Doc
*/
export function JSDOcTag_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "JSDOcTag", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** JS Doc
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* JS Doc
*/
export function JSDOcTag_PostImpulse(callContextData: any): void
{
@ -102,7 +121,8 @@ export namespace Test
}
/**
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* The ambrosia tag must be on the implementation of an overloaded function
*/
export function fnOverload_PostFork(callContextData: any, name?: string): void
@ -111,7 +131,8 @@ export namespace Test
}
/**
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* The ambrosia tag must be on the implementation of an overloaded function
*/
export function fnOverload_PostImpulse(callContextData: any, name?: string): void

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -212,6 +226,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_AmbrosiaTag.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_AmbrosiaTag.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -9,6 +9,9 @@ import Utils = Ambrosia.Utils;
let DESTINATION_INSTANCE_NAME: string = "server";
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
/**
Test when missing @param rawParams
*/
export namespace Test
{
/**

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParamNoRawParam.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParamNoRawParam.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParam.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_CustomSerialParam.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -9,13 +9,13 @@ import Utils = Ambrosia.Utils;
let DESTINATION_INSTANCE_NAME: string = "server";
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function unused_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "unused", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function unused_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "unused", 1, POST_TIMEOUT_IN_MS, callContextData);

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -179,6 +193,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_EventHandlerWarnings.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_EventHandlerWarnings.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -11,16 +11,20 @@ let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
export namespace Test
{
/** Fake Event Handler due to case in the name so this will be generated
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Fake Event Handler due to case in the name so this will be generated
*/
export function onbecomingprimary_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "onbecomingprimary", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/** Fake Event Handler due to case in the name so this will be generated
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Fake Event Handler due to case in the name so this will be generated
*/
export function onbecomingprimary_PostImpulse(callContextData: any): void
{

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -180,6 +194,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
PTM.Test.onBecomingPrimary();
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_EventHandlers.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -177,6 +191,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_GenType1.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_GenType1.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -178,6 +192,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_GenType2.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_GenType2.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -177,6 +191,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_LitObjArray.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_LitObjArray.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -9,10 +9,14 @@ import Utils = Ambrosia.Utils;
let DESTINATION_INSTANCE_NAME: string = "server";
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
/**
Test File of misc tests. If find a theme or grouping then move out of this file into separate file
*/
export namespace Test
{
/**
* Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Correctly handle line-breaks and comments
*/
export function myComplexReturnFunction_PostFork(callContextData: any): void
@ -21,7 +25,8 @@ export namespace Test
}
/**
* Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().
* *Note: The result ({ r1: string, r2: string }) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* Correctly handle line-breaks and comments
*/
export function myComplexReturnFunction_PostImpulse(callContextData: any): void

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -179,6 +193,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_MiscTests.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_MiscTests.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -11,13 +11,13 @@ let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
export namespace StaticStuff
{
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function hello_PostFork(callContextData: any, name: string): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "hello", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("name", name));
}
/** Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start(). */
/** *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().* */
export function hello_PostImpulse(callContextData: any, name: string): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "hello", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("name", name));

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -182,6 +196,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_StaticMethod.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_StaticMethod.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -9,6 +9,10 @@ import Utils = Ambrosia.Utils;
let DESTINATION_INSTANCE_NAME: string = "server";
let POST_TIMEOUT_IN_MS: number = 8000; // -1 = Infinite
/**
Test File to test all the Types for typescripts
Has the basic types
*/
export namespace Test
{
/*********** Enum type (numeric enum - strings as number) as return */
@ -67,7 +71,11 @@ export namespace Test
}
}
/************* Primitives - bool, string, number, array */
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* *********** Primitives - bool, string, number, array
*/
export function BasicTypes_PostFork(callContextData: any, isFalse: boolean, height: number, mystring?: string, mystring2?: string, my_array?: number[], notSure?: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "BasicTypes", 1, POST_TIMEOUT_IN_MS, callContextData,
@ -79,7 +87,11 @@ export namespace Test
IC.arg("notSure?", notSure));
}
/************* Primitives - bool, string, number, array */
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* *********** Primitives - bool, string, number, array
*/
export function BasicTypes_PostImpulse(callContextData: any, isFalse: boolean, height: number, mystring?: string, mystring2?: string, my_array?: number[], notSure?: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "BasicTypes", 1, POST_TIMEOUT_IN_MS, callContextData,
@ -91,31 +103,51 @@ export namespace Test
IC.arg("notSure?", notSure));
}
/********* Function using / returning Numeric Enum */
/**
* *Note: The result (PrintMedia) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function using / returning Numeric Enum
*/
export function getMedia_PostFork(callContextData: any, mediaName: string): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "getMedia", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("mediaName", mediaName));
}
/********* Function using / returning Numeric Enum */
/**
* *Note: The result (PrintMedia) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function using / returning Numeric Enum
*/
export function getMedia_PostImpulse(callContextData: any, mediaName: string): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "getMedia", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("mediaName", mediaName));
}
/************* Void type */
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* *********** Void type
*/
export function warnUser_PostFork(callContextData: any): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "warnUser", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/************* Void type */
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* *********** Void type
*/
export function warnUser_PostImpulse(callContextData: any): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "warnUser", 1, POST_TIMEOUT_IN_MS, callContextData);
}
/************** Example of a [post] method that uses custom types. */
/**
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ************ Example of a [post] method that uses custom types.
*/
export function makeName_PostFork(callContextData: any, firstName?: string, lastName?: string): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "makeName", 1, POST_TIMEOUT_IN_MS, callContextData,
@ -123,7 +155,11 @@ export namespace Test
IC.arg("lastName?", lastName));
}
/************** Example of a [post] method that uses custom types. */
/**
* *Note: The result (Names) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ************ Example of a [post] method that uses custom types.
*/
export function makeName_PostImpulse(callContextData: any, firstName?: string, lastName?: string): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "makeName", 1, POST_TIMEOUT_IN_MS, callContextData,
@ -131,32 +167,50 @@ export namespace Test
IC.arg("lastName?", lastName));
}
/********* Function returning number */
/**
* *Note: The result (number) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function returning number
*/
export function return_number_PostFork(callContextData: any, strvalue: string): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "return_number", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("strvalue", strvalue));
}
/********* Function returning number */
/**
* *Note: The result (number) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function returning number
*/
export function return_number_PostImpulse(callContextData: any, strvalue: string): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "return_number", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("strvalue", strvalue));
}
/********* Function returning string */
/**
* *Note: The result (string) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function returning string
*/
export function returnstring_PostFork(callContextData: any, numvalue: number): void
{
IC.postFork(DESTINATION_INSTANCE_NAME, "returnstring", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("numvalue", numvalue));
}
/********* Function returning string */
/**
* *Note: The result (string) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function returning string
*/
export function returnstring_PostImpulse(callContextData: any, numvalue: number): void
{
IC.postImpulse(DESTINATION_INSTANCE_NAME, "returnstring", 1, POST_TIMEOUT_IN_MS, callContextData, IC.arg("numvalue", numvalue));
}
/********* Function with missing types ****
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function with missing types ****
* Function with missing type information
*/
export function fnWithMissingType_PostFork(callContextData: any, p1: any, p2: number): void
@ -166,8 +220,10 @@ export namespace Test
IC.arg("p2", p2));
}
/********* Function with missing types ****
* Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().
/**
* *Note: The result (void) produced by this post method is received via the PostResultDispatcher provided to IC.start().*
*
* ******* Function with missing types ****
* Function with missing type information
*/
export function fnWithMissingType_PostImpulse(callContextData: any, p1: any, p2: number): void

Просмотреть файл

@ -16,12 +16,25 @@ export namespace State
{
// TODO: Define your application state here
/**
* @param restoredAppState Supplied only when loading (restoring) a checkpoint.\
* **WARNING:** restoredAppState will be an object literal, so you must use this to reinstantiate any members that are (or contain) class references.
*/
constructor(restoredAppState?: AppState)
{
super(restoredAppState);
if (restoredAppState)
{
// TODO: Re-initialize your application state from restoredAppState here
// WARNING: You MUST reinstantiate all members that are (or contain) class references because restoredAppState is data-only
}
else
{
// TODO: Initialize your application state here
}
}
}
/** Only assign this using the return value of IC.start(), and [if not using the generated checkpointConsumer()] in the 'onFinished' callback of an IncomingCheckpoint object. */
export let _appState: AppState = null;
@ -72,13 +85,14 @@ export function messageDispatcher(message: Messages.DispatchedMessage): void
// Reason: Because a message handler always has to run to completion (see Rule #1), if it runs for too long it can monopolize the system leading to performance issues.
// Further, this becomes a very costly message to have to replay during recovery. So instead, when an message handler needs to send a large sequence (series)
// of independent messages, it should be designed to be restartable so that the sequence can pick up where it left off (rather than starting over) when resuming
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). To avoid a single message handler having to send
// the entire sequence, large sequences should be sent in smaller batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches
// (IC.callFork / IC.postFork) inside a setImmediate() callback. This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable
// exceptions to the "always only use asynchronous code" dictate in Rule #1. Restartability is achieved by sending a 'sequence continuation' message at the end of
// each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation' message only ever sends the next batch plus the
// 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive (by allowing interleaving I/O) while also complying
// with Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
// execution (ie. after loading a checkpoint that occurred during the long-running - but incomplete - sequence). Restartability is achieved by sending a
// 'sequence continuation' message at the end of each batch, which describes the remaining work to be done. Because the handler for the 'sequence continuation'
// message only ever sends the next batch plus the 'sequence continuation' message, it can run to completion quickly, which both keeps the system responsive
// (by allowing interleaving I/O) while also complying with Rule #1.
// In addition to this "contination messasage" technique for sending a series, if any single message handler has to send a large number of mesages it should be
// sent in batches using either explicit batches (IC.enqueueFork + IC.flushQueue) or implicit batches (IC.callFork / IC.postFork) inside a setImmediate() callback.
// This asynchrony is necessary to allow I/O with the IC to interleave, and is one of the few allowable exceptions to the "always only use asynchronous code"
// dictate in Rule #1. Interleaving I/O allows the instance to service self-calls, and allows checkpoints to be taken between batches.
dispatcher(message);
}
@ -241,6 +255,10 @@ function dispatcher(message: Messages.DispatchedMessage): void
case Messages.AppEventType.BecomingPrimary:
// TODO: Add an exported [non-async] function 'onBecomingPrimary(): void' to ./JS_CodeGen_TestFiles/TS_Types.ts, then (after the next code-gen) a call to it will be generated here
break;
case Messages.AppEventType.CheckpointLoaded:
// TODO: Add an exported [non-async] function 'onCheckpointLoaded(checkpointSizeInBytes: number): void' to ./JS_CodeGen_TestFiles/TS_Types.ts, then (after the next code-gen) a call to it will be generated here
break;
}
break;
}

Просмотреть файл

@ -154,7 +154,7 @@ namespace AmbrosiaTest
}
catch (Exception e)
{
Assert.Fail("<BuildTSApp> Failure! Exception:" + e.Message);
Assert.Fail("<BuildJSTestApp> Failure! " + e.Message);
}
}

Просмотреть файл

@ -24,8 +24,6 @@ async function main()
{
await Ambrosia.initializeAsync(Ambrosia.LBInitMode.CodeGen);
let sourceFile: string = Utils.getCommandLineArg("sourceFile");
let codeGenKind: Meta.GeneratedFileKind = Meta.GeneratedFileKind[Utils.getCommandLineArg("codeGenKind", "All")] ?? Meta.GeneratedFileKind.All;
let mergeType: Meta.FileMergeType = Meta.FileMergeType[Utils.getCommandLineArg("mergeType", "None")] ?? Meta.FileMergeType.None;
let generatedFileName: string = Utils.getCommandLineArg("generatedFileName", "TestOutput") ?? "TestOutput";
Meta.emitTypeScriptFileFromSource(sourceFile, { fileKind: Meta.GeneratedFileKind.Consumer, mergeType: Meta.FileMergeType.None, emitGeneratedTime: false, generatedFileName: generatedFileName+"_Consumer" });

Просмотреть файл

@ -50,7 +50,7 @@
},
"debugStartCheckpoint": {
"type": "number",
"description": "The checkpoint number to start \"time-travel debugging\" from."
"description": "The checkpoint number to start \"time-travel debugging\" from. Defaults to 0 (which means don't debug)."
},
"debugTestUpgrade": {
"type": "boolean",
@ -147,6 +147,12 @@
"type": "number",
"description": "Set this to a positive integer to generate a warning whenever the number of in-flight post methods reaches this threshold. Defaults to -1 (no limit).",
"default": -1
},
"messageBytePoolSizeInMB":
{
"type": "number",
"description": "The size (in MB) of the message byte pool used for optimizing message construction. Defaults to 2MB.",
"default": 2
}
}
}

14
AmbrosiaTest/JSCodeGen/package-lock.json сгенерированный
Просмотреть файл

@ -5,9 +5,9 @@
"requires": true,
"dependencies": {
"@types/node": {
"version": "14.14.31",
"resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.31.tgz",
"integrity": "sha512-vFHy/ezP5qI0rFgJ7aQnjDXwAMrG0KqqIH7tQG5PPv3BWBayOPIQNBjVc/P6hhdZfMx51REc6tfDNXHUio893g=="
"version": "14.14.33",
"resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.33.tgz",
"integrity": "sha512-oJqcTrgPUF29oUP8AsUqbXGJNuPutsetaa9kTQAQce5Lx5dTYWV02ScBiT/k1BX/Z7pKeqedmvp39Wu4zR7N7g=="
},
"ajv": {
"version": "6.12.6",
@ -22,7 +22,7 @@
},
"ambrosia-node": {
"version": "file:ambrosia-node-0.0.77.tgz",
"integrity": "sha512-FpR2b2UckCVIrWQj6yKNlhw2xtgSbnStUe+NO+xkvWdp6Aa2ShQsnRXkGWVccsYshTa5gREdDIsMvrXtmEJv9g==",
"integrity": "sha512-d2Z3RFTEftbvzVxwjBzpm2gV/eRUK9/qK0CvU8Atx3T/QTP5+0Pit1XbpXW84oyBf+wTcnxYA7wUKuBZhtOkmA==",
"requires": {
"@types/node": "^14.14.25",
"azure-storage": "^2.10.3",
@ -461,9 +461,9 @@
"integrity": "sha1-WuaBd/GS1EViadEIr6k/+HQ/T2Q="
},
"typescript": {
"version": "4.1.5",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-4.1.5.tgz",
"integrity": "sha512-6OSu9PTIzmn9TCDiovULTnET6BgXtDYL4Gg4szY+cGsc3JP1dQL8qvE8kShTRx1NIw4Q9IBHlwODjkjWEtMUyA=="
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-4.2.3.tgz",
"integrity": "sha512-qOcYwxaByStAWrBf4x0fibwZvMRG+r4cQoTjbPtUlrWjBHbmCAww1i448U0GJ+3cNNEtebDteo/cHOR3xJ4wEw=="
},
"underscore": {
"version": "1.8.3",

Просмотреть файл

@ -8,6 +8,6 @@
},
"dependencies": {
"ambrosia-node": "file:ambrosia-node-0.0.77.tgz",
"typescript": "^4.1.5"
"typescript": "^4.2.3"
}
}