Expecco API/en - Versionsgeschichte

Cg: /* Reading Numbers from a String */

2026-05-18T13:53:38Z

Reading Numbers from a String

@@ Zeile 5.250: / Zeile 5.250: @@
     Float '''readFrom:''' ''aStringOrStream''
 which returns the float "1234.0", even when given the string "1234".
 ===== Error handling =====

Cg: /* Stream Handling */

2026-05-18T13:47:50Z

Stream Handling

← Nächstältere Version		Version vom 18. Mai 2026, 13:47 Uhr
Zeile 5.052:		Zeile 5.052:
	Streams can be both internal streams (streaming out-of or into a collection) or external streams.		Streams can be both internal streams (streaming out-of or into a collection) or external streams.
	External streams are always byte- or character-oriented and operate on files, sockets, pipes or i/o devices.		External streams are always byte- or character-oriented and operate on files, sockets, pipes or i/o devices.
	An internal stream's element type depends on the underlying collection.		An internal stream's element type depends on the underlying collection, but String-streams are most common.

	The following presents only a very small excerpt of the full stream protocol.		The following presents only a very small excerpt of the full stream protocol.

Cg: /* Reading */

2026-05-18T13:46:44Z

Reading

← Nächstältere Version		Version vom 18. Mai 2026, 13:46 Uhr
Zeile 5.133:		Zeile 5.133:

	retrieve elements up-to and including an element which is equal to "element"		retrieve elements up-to and including an element which is equal to "element"

			''rs'' peek

			retrieve the next element from the stream but does not advance the read pointer. Nil if there are no more elements. The next call to any of the above will see this character (again).

	==== Writing ====		==== Writing ====

Cg: /* Bulk Data */

2026-05-18T13:42:19Z

Bulk Data

← Nächstältere Version		Version vom 18. Mai 2026, 13:42 Uhr
Zeile 4.157:		Zeile 4.157:
	:It is much faster to send the whole vector data sent as one array via putDoublesN(), putFloatsN() or putIntsN(). This still does introduce some additional cost due to JSON-encoding (on the cBridge side) and JSON-decoding on the expecco side, but the effective transmission time is dramatically reduced.		:It is much faster to send the whole vector data sent as one array via putDoublesN(), putFloatsN() or putIntsN(). This still does introduce some additional cost due to JSON-encoding (on the cBridge side) and JSON-decoding on the expecco side, but the effective transmission time is dramatically reduced.
	* Passing Bulk Data as a ByteArray		* Passing Bulk Data as a ByteArray
	:Further speedup is possible by not sending the data as a number vector, but instead as a byte vector, actually sending the raw ended bytes from the bridge to expecco. For this, use a putBytesN() call and case your bulk data to a "char *" <sup>1)</sup>.		:Further speedup is possible by not sending the data as a number vector, but instead as a byte vector, actually sending the raw ended bytes from the bridge to expecco. For this, use a putBytesN() call and case your bulk data to a "char *" <small><sup>1)</sup></small>.
	:However (big warning): expecco will receive a byte-vector and you will have to add code to extract the relevant elements from this. If the cBridge CPU and the expecco-CPU use a different byte order or a different floating-point-number representations, you will have to deal with that in that extraction code. Be aware, that it may even depend on the compiler: Microsoft VisualC compilers for x86_64 interpret "long" as a 32bit integer, whereas most other compilers/systems treat them as 64bit integers.<br>		:However (big warning): expecco will receive a byte-vector and you will have to add code to extract the relevant elements from this. If the cBridge CPU and the expecco-CPU use a different byte order or a different floating-point-number representations, you will have to deal with that in that extraction code. Be aware, that it may even depend on the compiler: Microsoft VisualC compilers for x86_64 interpret "long" as a 32bit integer, whereas most other compilers/systems treat them as 64bit integers.<br>
	:This is probably the fastest method to transmit bytes, but comes with those possible pitfalls. We therefore recommend to try the "Bulk Data as Vector" method first. In most situations that is either within the acceptable timing constraints, or too far off, such that the ByteArray transmission will also not be fast enough, and you should use the pointer passing method anyway.		:This is probably the fastest method to transmit bytes, but comes with those possible pitfalls. We therefore recommend to try the "Bulk Data as Vector" method first. In most situations that is either within the acceptable timing constraints, or too far off, such that the ByteArray transmission will also not be fast enough, and you should use the pointer passing method anyway.
Zeile 4.163:		Zeile 4.163:
	If the cBridge runs on the same machine as expecco, shared memory will be used to exchange bulk data. This may reduce the transmission times drastically, depending on the amount of data (there are still other messages exchanged via the socket communication).		If the cBridge runs on the same machine as expecco, shared memory will be used to exchange bulk data. This may reduce the transmission times drastically, depending on the amount of data (there are still other messages exchanged via the socket communication).

	<sup>1)</sup>~~This~~ is no longer required ~~with~~ ~~expecco 26.2. There~~ are now additional fast bulk transfer entries: <code>putFloatsN</code>, <code>putDoublesN</code> etc.		<small><sup>1)</sup></small>Starting with expecco 26.2, this is no longer required - there are now additional fast bulk transfer entries named: <code>putFloatsN</code>, <code>putDoublesN</code> etc.

	=== Example1: Writing and Calling C Code in Expecco ===		=== Example1: Writing and Calling C Code in Expecco ===

Cg: /* Bulk Data */

2026-05-18T13:40:48Z

Bulk Data

← Nächstältere Version		Version vom 18. Mai 2026, 13:40 Uhr
Zeile 4.154:		Zeile 4.154:
	:This mechanism is the fastest because only a small handle (typically 32/64 bits) has to be transmitted to expecco. However, it degrades to become very very slow if you access individual elements of the vector from expecco, as this will result in one IPC roundtrip per accessed element.		:This mechanism is the fastest because only a small handle (typically 32/64 bits) has to be transmitted to expecco. However, it degrades to become very very slow if you access individual elements of the vector from expecco, as this will result in one IPC roundtrip per accessed element.
	* Passing Bulk Data as a Vector		* Passing Bulk Data as a Vector
	:If each vector element is sent individually to an output pin (~~i.e~~. in a loop with putFloat()/putDouble()), one IPC roundtrip will be performed per element.		:If each vector element is sent individually to an output pin (eg. in a loop with <code>putFloat</code> or <code>putDouble</code>), one IPC roundtrip will be performed per element.
	:It is much faster to send the whole vector data sent as one array via putDoublesN(), putFloatsN() or putIntsN(). This still does introduce some additional cost due to JSON-encoding (on the cBridge side) and JSON-decoding on the expecco side, but the effective transmission time is dramatically reduced.		:It is much faster to send the whole vector data sent as one array via putDoublesN(), putFloatsN() or putIntsN(). This still does introduce some additional cost due to JSON-encoding (on the cBridge side) and JSON-decoding on the expecco side, but the effective transmission time is dramatically reduced.
	* Passing Bulk Data as a ByteArray		* Passing Bulk Data as a ByteArray
	:Further speedup is possible by not sending the data as a number vector, but instead as a byte vector, actually sending the raw ended bytes from the bridge to expecco. For this, use a putBytesN() call and case your bulk data to a "char *".		:Further speedup is possible by not sending the data as a number vector, but instead as a byte vector, actually sending the raw ended bytes from the bridge to expecco. For this, use a putBytesN() call and case your bulk data to a "char *" <sup>1)</sup>.
	:However (big warning): expecco will receive a byte-vector and you will have to add code to extract the relevant elements from this. If the cBridge CPU and the expecco-CPU use a different byte order or a different floating-point-number representations, you will have to deal with that in that extraction code. Be aware, that it may even depend on the compiler: Microsoft VisualC compilers for x86_64 interpret "long" as a 32bit integer, whereas most other compilers/systems treat them as 64bit integers.<br>		:However (big warning): expecco will receive a byte-vector and you will have to add code to extract the relevant elements from this. If the cBridge CPU and the expecco-CPU use a different byte order or a different floating-point-number representations, you will have to deal with that in that extraction code. Be aware, that it may even depend on the compiler: Microsoft VisualC compilers for x86_64 interpret "long" as a 32bit integer, whereas most other compilers/systems treat them as 64bit integers.<br>
	:This is probably the fastest method to transmit bytes, but comes with those possible pitfalls. We therefore recommend to try the "Bulk Data as Vector" method first. In most situations that is either within the acceptable timing constraints, or too far off, such that the ByteArray transmission will also not be fast enough, and you should use the pointer passing method anyway.		:This is probably the fastest method to transmit bytes, but comes with those possible pitfalls. We therefore recommend to try the "Bulk Data as Vector" method first. In most situations that is either within the acceptable timing constraints, or too far off, such that the ByteArray transmission will also not be fast enough, and you should use the pointer passing method anyway.

	If the cBridge runs on the same machine as expecco, shared memory will be used to exchange bulk data. This may reduce the transmission times drastically, depending on the amount of data (there are still other messages exchanged via the socket communication).		If the cBridge runs on the same machine as expecco, shared memory will be used to exchange bulk data. This may reduce the transmission times drastically, depending on the amount of data (there are still other messages exchanged via the socket communication).

			<sup>1)</sup>This is no longer required with expecco 26.2. There are now additional fast bulk transfer entries: <code>putFloatsN</code>, <code>putDoublesN</code> etc.

	=== Example1: Writing and Calling C Code in Expecco ===		=== Example1: Writing and Calling C Code in Expecco ===

Cg: /* Bulk Data */

2026-05-18T13:36:17Z

Bulk Data

← Nächstältere Version		Version vom 18. Mai 2026, 13:36 Uhr
Zeile 4.151:		Zeile 4.151:

	* Passing a Pointer to expecco		* Passing a Pointer to expecco
	:if you can leave the data inside the bridge (eg. as malloc'd data vector), '''and''' expecco does not need to access the elements of the vector, you can leave the data inside the cBridge and only pass a handle to expecco. This handle may later be sent to another C-action to process the data at non-critical times (eg. at the end of the test).		:if you can leave the data inside the bridge (eg. as malloc'd data vector), '''and''' expecco does not need to access the elements of the vector, you can leave the data inside the cBridge and only pass a handle to expecco. This handle may later be sent to another C-action (on the same bridge) to process the data at non-critical times (eg. at the end of the test).
	:This mechanism is the fastest because only a small handle (typically 32/64 bits) has to be transmitted to expecco. However, it degrades to become very very slow if you access individual elements of the vector from expecco, as this will result in one IPC roundtrip per accessed element.		:This mechanism is the fastest because only a small handle (typically 32/64 bits) has to be transmitted to expecco. However, it degrades to become very very slow if you access individual elements of the vector from expecco, as this will result in one IPC roundtrip per accessed element.
	* Passing Bulk Data as a Vector		* Passing Bulk Data as a Vector

Cg: /* Running Bridged C-Code on a Remote Computer */

2026-05-18T13:33:24Z

Running Bridged C-Code on a Remote Computer

← Nächstältere Version		Version vom 18. Mai 2026, 13:33 Uhr
Zeile 4.118:		Zeile 4.118:
	# specify that the bridge is already running in the settings; then all cBridge actions which have not been explicitly given a bridge to execute in will be executed there		# specify that the bridge is already running in the settings; then all cBridge actions which have not been explicitly given a bridge to execute in will be executed there
	# explicitly connect to a running bridge via the "''Connect to Running Bridge''" action block, and passing the resulting bridge handle to the C-action.		# explicitly connect to a running bridge via the "''Connect to Running Bridge''" action block, and passing the resulting bridge handle to the C-action.
	The handle can be passed either explicitly via the step's cBridge input pin, or implicitly by declaring a variable named "CBRIDGE" and storing the handle there. The cBridge input pin is generated via the step's ''Special Pins'' menu.		The handle can be passed either explicitly via the step's cBridge input pin, or implicitly by declaring a variable named "<code>CBRIDGE</code>" and storing the handle there. <br>The cBridge input pin is generated via the step's ''Special Pins'' menu.
			<br>If the CBRIDGE variable is declared in a compound action, it will be valid by all actions executed from that and below that action. This makes it possible to run actions on multiple bridges without explicitly passing the bridge handles around via input pins.

	Bridges can be started either by one of the bridge start actions in the standard library or by a batch-, shell- or powershell script. Type "<code>cBridge --help</code>" for command line options.		Bridges can be started either by one of the bridge start actions in the standard library or by a batch-, shell- or powershell script. Type "<code>cBridge --help</code>" for command line options.

Cg: /* Referring to Functions in Shared Libraries */

2026-05-18T13:26:50Z

Referring to Functions in Shared Libraries

← Nächstältere Version		Version vom 18. Mai 2026, 13:26 Uhr
Zeile 4.066:		Zeile 4.066:
	The details depend on the OperatingSystem; Windows searches along the PATH setting, linux along LD_LIBRARY_PATH. If in doubt, consult your OS documentation.		The details depend on the OperatingSystem; Windows searches along the PATH setting, linux along LD_LIBRARY_PATH. If in doubt, consult your OS documentation.

	Navigate to "''Extras''" → "''Settings''" &#rarr; "''Execution''" &#rarr; "''External Script Interpreters''" &#rarr; "''CBridge''" and add the path to the "DLL Path" field.		Navigate to "''Extras''" → "''Settings''" → "''Execution''" → "''External Script Interpreters''" → "''CBridge''" and add the path to the "DLL Path" field.

	As an alternative, edit the CC-Script and add appropriate command line arguments to the linker command near the end (it is recommended to keep the original, and make an edited copy).		As an alternative, edit the CC-Script and add appropriate command line arguments to the linker command near the end (it is recommended to keep the original, and make an edited copy).

Cg: /* Output Pins (C) */

2026-05-18T13:26:14Z

Output Pins (C)

← Nächstältere Version		Version vom 18. Mai 2026, 13:26 Uhr
Zeile 4.013:		Zeile 4.013:
	* void '''putPointer''' (''outPin'', void* ''dataPtr'') <br>Writes a reference for dataPtr to the output pin. This value can be passed to another cBridge action (executed on the same bridge), where it can be read from the input with <code>pointerValue()</code> (this is similar to the makeRef mechanism of other bridged languages).		* void '''putPointer''' (''outPin'', void* ''dataPtr'') <br>Writes a reference for dataPtr to the output pin. This value can be passed to another cBridge action (executed on the same bridge), where it can be read from the input with <code>pointerValue()</code> (this is similar to the makeRef mechanism of other bridged languages).

	The following API ~~will be~~ available ~~with~~ the 21.2 release:		The following API is available since the 21.2 release:

	* void '''putDoublesN''' (''outPin'', double* ''doubles'', int ''count'') <br>Writes count double values as a vector to the output pin. expecco will receive these values as a collection of double precision floating point values.		* void '''putDoublesN''' (''outPin'', double* ''doubles'', int ''count'') <br>Writes count double values as a vector to the output pin. expecco will receive these values as a collection of double precision floating point values.
Zeile 4.025:		Zeile 4.025:
	These vectors will appear at the output pin as a collection; the type of collection is given by the pin's datatype. For most space efficient representation, we recommend the use of the bulk data types (FloatArray, DoubleArray, etc.)		These vectors will appear at the output pin as a collection; the type of collection is given by the pin's datatype. For most space efficient representation, we recommend the use of the bulk data types (FloatArray, DoubleArray, etc.)

	The following API ~~will be~~ available ~~with~~ the 21.2.1 update release:		The following API is available since the 21.2.1 update release:

	* void '''putShortsN''' (''outPin'', short* ''longs'', int ''count'') <br>Writes count (signed) short values as a vector to the output pin. expecco will receive these values as a collection of integer values.		* void '''putShortsN''' (''outPin'', short* ''longs'', int ''count'') <br>Writes count (signed) short values as a vector to the output pin. expecco will receive these values as a collection of integer values.

Cg: /* Example 1: Using the "overpy" Python Package (open street map access) in Expecco */

2026-05-18T12:31:04Z

Example 1: Using the "overpy" Python Package (open street map access) in Expecco

← Nächstältere Version		Version vom 18. Mai 2026, 12:31 Uhr
Zeile 3.586:		Zeile 3.586:
	Open the expecco console (aka "Transcript" via the "''Extras''" → "''Tools''" → "''Transcript''" menu item) and run the test.		Open the expecco console (aka "Transcript" via the "''Extras''" → "''Tools''" → "''Transcript''" menu item) and run the test.
	A list of street nodes should be displayed on the Transcript.		A list of street nodes should be displayed on the Transcript.
			<br>Of course, the above can be changed to send the latitude and longitude values to output pins for further processing in your test suite.

	=== Example 2: Accessing other Python Packages or Individual Script Files ===		=== Example 2: Accessing other Python Packages or Individual Script Files ===