Documentation ¶
Index ¶
- Variables
- func Erlang_program_exec(prg ProgramWideStateVariable)
- func LogError(err error, msg string)
- func LogInfo(msg string)
- func LogWarning(msg string)
- type Char
- type Chars
- type ErlExpression
- type ErlExpressions
- type ErlToken
- type ErlTokens
- type ProgramWideStateVariable
- type SettingsTable
- type SourceTokensExecutables
- type SourcesTokensExecutables_map
- type TokenOrExpression
- type TokensOrExpressions
Constants ¶
This section is empty.
Variables ¶
View Source
var ExpressionName_from_num map[int]string = map[int]string{ // contains filtered or unexported fields }
reverse conversion: from the code, know, what is the type
Functions ¶
func Erlang_program_exec ¶
func Erlang_program_exec(prg ProgramWideStateVariable)
func LogWarning ¶
func LogWarning(msg string)
Types ¶
type Char ¶
type Char struct { PositionInFile int // Nth char in the whole file Value rune WhereTheCharIsStored string ErlangSourceWithoutFilePath bool TokenDetected bool TokenId int TokenFirstCharPositionInFile int // the Token's first char's position in file LineNum int PositionInLine int // Nth char in the line }
type ErlExpression ¶
type ErlExpression struct { /* This is the heart of the interpreter */ ExpressionType int // expression_atom, expression_num... (BOOKMARK-labeled in source code) TokensOrExpressions TokensOrExpressions }
type ErlExpressions ¶
type ErlExpressions []ErlExpression
func Expression_detection_for_tests ¶
func Expression_detection_for_tests(erlSrc string, wantedExpressionDetectionTypesCommaSeparated string) ErlExpressions
type ErlToken ¶
type ErlToken struct { TokenType string TokenId int DebugStringRepresentation string // the string representation can be asked with a function, but in the debugger it is easier if it is stored in an attribute // one char can have a meaning alone, for example: ( // but sometime more than one few char can form a token, for example: '->' which has his own meaning, but represented by 2 chars SourceCodeChars Chars TokenIsDetectedAsPartOfExpression bool }
use minimal set of types. Don't overcomplicate the parser.
func ErlToken_empty_obj ¶
############# PARSER ELEMS #############################
type ProgramWideStateVariable ¶
type ProgramWideStateVariable struct {
ArgumentsErlangoCliStart SettingsTable
}
very rarely modified, and often read program-wide data structure.
Stored infos:
- erlango command line call parameters (good to know everywhere)
in program start arguments, there can be strings, ints, bools
type SettingsTable ¶
type SettingsTable struct { SettingStr map[string][]string SettingInt map[string][]int SettingBool map[string]bool }
general storage for settings - strings, ints, bools are typical config elems
type SourceTokensExecutables ¶
type SourceTokensExecutables struct { ModuleName string // TODO: in source code loading, detect this, and set this attribute ModuleVersion string // same module's different versions can be compiled and loaded same time WhereTheCodeIsStored string CharsFromErlFile Chars Tokens ErlTokens // this section is filled by token detection part (step_01_tokens_from_source_code_of_files) Expressions ErlExpressions // this section is filled by expression detection (step_02_expressions_from_tokens_from_lot_of_sources) Errors errorsDetected ErlangSourceWithoutFilePath bool // if this is true, the source was not coming from a file }
A lot of different versions of a module can be loaded and prepared to be executed same time.
example situation: we have a 'database', 'financial' and 'logging' modules. # the module version attrib is a string, totally free, how do you define them. The teams can find out their own versioning # in the example, different teams are working with different modules, # and they are unable to use the same version naming convention, to represent an unperfect situation in the filesystem, the next versioned source codes are availabe (version name is a comment in the file) 'database' module available source code versions: "1.0.0 init", "1.1.0 connection fixes", "1.2.0 new db version" 'financial' module available source code versions: "1.0a draft", "1.0b first working" 'logging' module available source code versions: "2023_10_22_a original", "2023_10_25_b", "2023_12_01_a", "2023_12_01_c" The architect defines the next executable version groups, where the 3 modules are able to work together: in the example you can see, that the 'financial' module is same in both release, but the database '1.0.0 init' can work only with 'logging' module's "2023_10_22_a original", So you can load/define more, than 2 different executable version sets, for your modules. FIXME: DEFINE EXACTLY WHERE the groups can be defined, and how is it handled Basically Erlango works like Erlang: you can load your source codes, and exec them. But if you define more version groups, more versions can be compiled/loaded/ready in the memmory, and in your incoming requests you can define which version group can execute them. With this solution, you can keep a lot of versions in the memory, and if you need, you can revert your changes. This versioning is different from hot code loading, because in that situation you modify an 'Executable_version_group' in a running system, and you change one element, which means that at the next func usage a new version will be executed. Executable_version_groups = #{ "1_freely_defined_group_name" => [ ['database', "1.0.0 init"], ['financial', "1.0b first working"], ['logging', "2023_10_22_a original"] ], "2_release_with_db_fixes" => [ ['database', "1.1.0 connection fixes"], ['financial', "1.0b first working"], ['logging', "2023_12_01_a"] ] }
type SourcesTokensExecutables_map ¶
type SourcesTokensExecutables_map map[string]SourceTokensExecutables
type TokenOrExpression ¶
type TokenOrExpression struct {
// contains filtered or unexported fields
}
type TokensOrExpressions ¶
type TokensOrExpressions []TokenOrExpression
Source Files ¶
- erlango.go
- erlango_01_token_detection_from_src.go
- erlango_01a_comments_textblocks.go
- erlango_02_language_elems_detection.go
- erlango_02b_variableNames.go
- erlango_02c_numbers.go
- erlango_02d_brackets.go
- erlango_02e_operators.go
- erlango_cli_args.go
- erlango_config.go
- erlango_types_cli.go
- erlango_types_parser.go
- tools.go
- tools_tests.go
Click to show internal directories.
Click to hide internal directories.