EXODUS Knowledge - Revision history

Gregory: /* Processes */

2025-12-30T10:29:51Z

Processes

← Older revision		Revision as of 10:29, 30 December 2025
Line 192:		Line 192:

	==Processes==		==Processes==
	The TEST process for all database use the same object code stored in /root/lib, whereas all LIVE process use the object code in /root/~~neo~~/.		The TEST process for all database use the same object code stored in /root/lib, whereas all LIVE process use the object code in /root/live/lib.

	==Postgres==		==Postgres==

Gregory: /* Debugging EXODUS var type variables */

2025-12-12T08:23:27Z

Debugging EXODUS var type variables

← Older revision		Revision as of 08:23, 12 December 2025
Line 213:		Line 213:
	===Debugging EXODUS var type variables===		===Debugging EXODUS var type variables===

	~~First quick intro of~~ Exodus var ~~type~~		The Exodus var mimics JS var in that you can assign it multiple types.

	var v1 = "hello";		var v1 = "hello";
Line 228:		Line 228:
	(gdb) print v3		(gdb) print v3
	$3 = {var_str = "", var_int = 0, var_dbl = 9.99, var_typ = {flags_ = 3}}		$3 = {var_str = "", var_int = 0, var_dbl = 9.99, var_typ = {flags_ = 3}}

	</pre>		</pre>

	~~The Exodus~~ var ~~mimics JS var in that you can assign it multiple types.~~		=====Internals of a var explained:=====

	var_str is type std::string		var_str is type std::string

	var_int is type int		var_int is type int

	var_dbl is type long double		var_dbl is type long double

	var_type is type int (the var type flag)		var_type is type int (the var type flag)

	~~=====~~ Type flag explained: ~~=====~~
			Type flag explained:

	The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.		The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.
	Examples:		Examples:

Gregory: /* Postgres */

2025-12-12T08:17:34Z

Postgres

← Older revision		Revision as of 08:17, 12 December 2025
Line 199:		Line 199:

	Delete a database:		Delete a database:
			dbdelete <dbcode> #exodus cli program
			OR
	sudo -u postgres dropdb <dbcode>		sudo -u postgres dropdb <dbcode>

Gregory: /* Debugging var values */

2025-12-12T08:14:02Z

Debugging var values

← Older revision		Revision as of 08:14, 12 December 2025
Line 209:		Line 209:
	./run <dbname> - execute test programs on live database.		./run <dbname> - execute test programs on live database.

	===Debugging var ~~values~~===		===Debugging EXODUS var type variables===

	~~Explanation~~ of var ~~flag value in gdb debug mode~~.		First quick intro of Exodus var type

			var v1 = "hello";
			var v2 = 999
			var v3 = 9.99;

	<pre>		<pre>
	(gdb) ~~p varx~~		(gdb) print v1
	$2 = {var_str = "", var_int = 0, var_dbl = 0, var_typ = {flags_ = 2}}		$1 = {var_str = "hello", var_int = 0, var_dbl = 0, var_typ = {flags_ = 1}}

			(gdb) print v2
			$2 = {var_str = "", var_int = 999, var_dbl = 0, var_typ = {flags_ = 2}}

			(gdb) print v3
			$3 = {var_str = "", var_int = 0, var_dbl = 9.99, var_typ = {flags_ = 3}}

	</pre>		</pre>

	~~Each exodus~~ var ~~object contains 4 variables of type std::string (var_str), int (var_int), long double (var_dbl) and another int (var_typ i.e flags)~~.		The Exodus var mimics JS var in that you can assign it multiple types.

	~~The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.~~		var_str is type std::string
			var_int is type int
			var_dbl is type long double

	~~First bit = string~~ is ~~un/assigned. Second bit =~~ int ~~is un/assigned. Third bit = double un/assigned~~ (~~a combination of these bits describes whether var_str/ var_int/ var_dbl are assigned.~~		var_type is type int (the var type flag)

			===== Type flag explained: =====
			The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.
	Examples:		Examples:

	000 (binary) = 0 (~~decimal~~) = ~~non~~ are assigned.		000 (binary) = 0 (flags_) = none are assigned.

	100 (binary) = 1 (~~decimal~~) = var_str is assigned. (~~var_int & var_dbl~~ are not)		100 (binary) = 1 (flags_) = var_str is assigned. (others are not)

	010 (binary) = 2 (~~decimal~~) = var_int is assigned. (~~var_str & var_dbl are not~~)		010 (binary) = 2 (flags_) = var_int is assigned. (ditto)

	001 (binary) = 4 (~~decimal~~) = var_dbl is assigned. (~~var_str var_int are not~~)		001 (binary) = 4 (flags_) = var_dbl is assigned. (ditto)

	Combinations:		Combinations:

	110 (binary) = 3 (~~decimal~~) = var_str & var_int are assigned. (var_dbl is not)		110 (binary) = 3 (flags_) = var_str & var_int are assigned. (var_dbl is not)

			v1 = "10";
			(gdb) p v1
			$1 = {var_str = "10", var_int = "", var_dbl = "", var_typ = {flags_ = 1}}

			v1 = v1 + 0;
			(gdb) n #execute that code
			(gdb) p v1
			$1 = {var_str = "10", var_int = "10", var_dbl = "", var_typ = {flags_ = 2}}

	====To inspect a ~~“common”~~ variable====		What happened during 'v1 = v1 + 0;':
			1. v1's flag was 1, i.e only var_str was assigned.
			2. Numeric operator (+) invoked
			3. Attempt string to numerical type conversion either int or double.
			4. Yes var_str = "10" -> var_int = 10.
			5. Update flag to 2 (both var_str/int now assigned)
			6. var_int = 10, + 0 = 10;


			====To inspect a "common" variable (i.e those found in e.g ba_common.h)====

	e.g. a variable called ba.ledgern		e.g. a variable called ba.ledgern
Line 247:		Line 278:

	OLD METHOD:		OLD METHOD:

	p ((subExodusProgram::<b>ba</b>_common)<b>ba</b>).<b>ledgern</b>		p ((subExodusProgram::<b>ba</b>_common)<b>ba</b>).<b>ledgern</b>

	~~====To inspect a common block====~~

	~~e.g. a common block ba~~

	~~ptype (subExodusProgram::ba_common)ba~~

	====To dump all variables in a common====		====To dump all variables in a common====

Gregory: /* To inspect a “common” variable */

2025-12-12T07:45:01Z

To inspect a “common” variable

← Older revision		Revision as of 07:45, 12 December 2025
Line 242:		Line 242:
	====To inspect a “common” variable====		====To inspect a “common” variable====

	e,g, a variable called ba.ledgern		e.g. a variable called ba.ledgern

			p ba.ledgern

			OLD METHOD:

	p ((subExodusProgram::<b>ba</b>_common)<b>ba</b>).<b>ledgern</b>		p ((subExodusProgram::<b>ba</b>_common)<b>ba</b>).<b>ledgern</b>

Joel: /* Configuring services to autostart during login */

2023-01-13T13:48:13Z

Configuring services to autostart during login

← Older revision		Revision as of 13:48, 13 January 2023
Line 476:		Line 476:

	==Configuring services to autostart during login==		==Configuring services to autostart during login==
	For ~~Ptcy.~~		For PTCY,

	#Create a file 'autostart.cfg' in the data folder		#Create a file 'autostart.cfg' in the data folder

Gregory: /* Debugging var values */

2022-11-21T06:51:54Z

Debugging var values

← Older revision		Revision as of 06:51, 21 November 2022
Line 228:		Line 228:
	000 (binary) = 0 (decimal) = non are assigned.		000 (binary) = 0 (decimal) = non are assigned.

	110 (binary) = 3 (decimal) = var_str & var_int are assigned.		100 (binary) = 1 (decimal) = var_str is assigned. (var_int & var_dbl are not)

			010 (binary) = 2 (decimal) = var_int is assigned. (var_str & var_dbl are not)

			001 (binary) = 4 (decimal) = var_dbl is assigned. (var_str var_int are not)

			Combinations:

			110 (binary) = 3 (decimal) = var_str & var_int are assigned. (var_dbl is not)


	~~001 (binary) = 4 (decimal) = var_dbl is assigned.~~

	====To inspect a “common” variable====		====To inspect a “common” variable====
Line 236:		Line 244:
	e,g, a variable called ba.ledgern		e,g, a variable called ba.ledgern

	p ((subExodusProgram::~~ba_common~~)ba).ledgern		p ((subExodusProgram::<b>ba</b>_common)<b>ba</b>).<b>ledgern</b>

	====To inspect a common block====		====To inspect a common block====

Gregory: Improvement to var description

2022-11-21T06:35:35Z

Improvement to var description

← Older revision		Revision as of 06:35, 21 November 2022
Line 218:		Line 218:
	</pre>		</pre>

	Each exodus var object contains 3 variables of type string, int and ~~double~~.		Each exodus var object contains 4 variables of type std::string (var_str), int (var_int), long double (var_dbl) and another int (var_typ i.e flags).

	~~All~~ 3 ~~may be unassigned or only~~ the ~~string be~~ assigned ~~or just the int and double e.t~~.		The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.

	~~You can tell which variable type~~ of ~~a var object~~ are ~~set based on the var's flag value~~.		First bit = string is un/assigned. Second bit = int is un/assigned. Third bit = double un/assigned (a combination of these bits describes whether var_str/ var_int/ var_dbl are assigned.

	~~1 = Means the string is assigned~~		Examples:
	~~2 = Means the int is assigned~~
	~~4 = Means the double is assigned~~

	~~Example: If the flag is 7~~ (~~1+2+~~4)~~, then all types are~~ assigned.		000 (binary) = 0 (decimal) = non are assigned.

			110 (binary) = 3 (decimal) = var_str & var_int are assigned.

			001 (binary) = 4 (decimal) = var_dbl is assigned.

	====To inspect a “common” variable====		====To inspect a “common” variable====

Gregory: /* Development and deployment using 'dat' files */

2022-10-27T05:26:21Z

Development and deployment using 'dat' files

← Older revision		Revision as of 05:26, 27 October 2022
Line 113:		Line 113:

	The operational versions are stored in ~/dat and ~/live/dat alongside bin and lib dirs and are automatically installed into databases as database files on service startup. Any database functions embedded in the text files (pgsql) are also automatically installed at the same time.		The operational versions are stored in ~/dat and ~/live/dat alongside bin and lib dirs and are automatically installed into databases as database files on service startup. Any database functions embedded in the text files (pgsql) are also automatically installed at the same time.

			===Delete Database dictionary file===

			cli syncdat deletes database files if the dat dir is empty or contains a file 'SYNCDAT_DELETE'

			<pre>
			touch neosys/src/dat/dict.users/SYNC_DELETE
			neosys/src~: syncdat
			</pre>

	====Editing and deploying a 'dat' file====		====Editing and deploying a 'dat' file====
Line 118:		Line 127:
	It is currently a three step process to edit and deploy such 'dat' files.		It is currently a three step process to edit and deploy such 'dat' files.

	=====Edit the 'dat' file=====		=====Edit the 'dat' file (i.e dict.file record)=====

	Note that EXODUS service and NEOSYS service have different src/dat folders.		Note that EXODUS service and NEOSYS service have different src/dat folders.

Gregory: /* Copy all programs and 'dat' files to ~/live/bin|lib|dat */

2022-10-13T05:55:23Z

Copy all programs and 'dat' files to ~/live/bin|lib|dat

← Older revision		Revision as of 05:55, 13 October 2022
Line 159:		Line 159:

	./copyall CONFIRM		./copyall CONFIRM

	=====Delete dat record =====		=====Delete dat record =====