Getting rebar3

There are various ways for obtaining rebar3; we prefer:

$ cd ~/Software && git clone https://github.com/erlang/rebar3.git
   && cd rebar3 && ./bootstrap

Alternatively, should you just want to update a (pre-existing) rebar3 install, first get the current version (rebar3 -v) to check it afterwards, then issue rebar3 local upgrade; however this would involve running rebar from .cache/rebar3/bin, so instead we prefer using (typically from ~/Software/rebar3):

$ git pull && ./bootstrap

Another option is to download a prebuilt version of rebar3.

Finally, one may prefer using the install-rebar3.sh script that we devised, which automates and enforces our conventions while letting the choice between an installation from sources or from a prebuilt version thereof (just un install-rebar3.sh --help for guidance).

Generating Ceylan-Myriad

Then, from the root of a Myriad clone, to obtain the Ceylan-Myriad library application, one just has to enter:

$ make rebar3-application

It will trigger rebar3, resulting in a full, OTP-compliant build tree created in _build (including a properly-generated _build/default/lib/myriad/ebin/myriad.app file), and more generally in a proper OTP application [9].

A full, autonomous, functional by design build procedure can be also found in Myriad's continuous integration script.

Testing Ceylan-Myriad

As a result, the OTP application support can be tested from the root of an (already-built, with make rebar3-application) Myriad source tree:

$ cd src/utils
$ make myriad_otp_application_run
       Running unitary test myriad_otp_application_run (third form) from
          myriad_otp_application_test

--> Testing module myriad_otp_application_test.

Starting the Myriad application.
Myriad version: {1,0,11}.
Current user name: 'stallone'.
Stopping the Myriad application.
Successful end of test of the Myriad application.
=INFO REPORT==== 18-Jul-2019::22:37:24.779037 ===
   application: myriad
   exited: stopped
   type: temporary

--> Successful end of test.

(test finished, interpreter halted)

This support can be also tested manually, directly through the build tree used by rebar3; from the root of Myriad, after having run make rebar3-application:

$ erl -pz _build/default/lib/myriad/ebin/
Erlang/OTP 22 [erts-10.4] [source] [64-bit] [smp:8:8] [...]

Eshell V10.4  (abort with ^G)
1> application:start(myriad).
ok
2> text_utils:format( "Hello ~s", [ world ] ).
"Hello world"
3> application:stop(myriad).
=INFO REPORT==== 18-Jul-2019::22:47:36.429804 ===
   application: myriad
   exited: stopped
   type: temporary

When needing to include a Myriad header file (taking spawn_utils.hrl as an example) in one's code, OTP conventions mandate using:

-include_lib("myriad/include/spawn_utils.hrl").

rather than:

-include("spawn_utils.hrl").

Table Types

A set of types for associative tables is available, each offering a rather complete interface (to create, update, enrich, search, query, list, map, fold, merge, display, etc. a table - or entries thereof) and a different trade-off.

Various implementations are defined (with tests and benchmarks), in:

{hash,lazy_hash,list_,tracked_hash,map_hash}table.erl

A table pseudo-module is additionally provided, in order to abstract out these various options: the user may then rely exclusively on table, regardless of the actual table type this pseudo-module will be translated at compilation-time.

Indeed the table module is a fully virtual one, in the sense that neither table.erl nor table.beam exists, and that the Myriad parse transform is to automatically replace a call to this table pseudo-module by a call to one of the aforementioned table types (and it will do the same replacement in type specifications as well).

By default, such table calls will be translated to corresponding calls to our map_hashtable module, which is generally the most efficient one (it relies on the more recently-introduced Erlang maps built-in datatype, which table now favors).

As a result, in order to consult the table API, please refer to map_hashtable.erl.

Such a default implementation may be overridden on a per-module basis, thanks to a table_type define.

For example, specifying -table_type(list_table). will result in the current module to translate table to list_table, instead of the default map_hashtable.

Another type of table is the bijective_table, which allows efficient (runtime) bidirectional conversions between two sets, each having unique elements (no duplicates).

As a mere convention, when one set is dealing with internal identifiers and the other on third-party ones, we recommend that the internal identifiers are selected as the first elements, and the third party as second elements.

Finally, a way of generating read-only associative tables whose key/value pairs can be read very efficiently from any number (potentially extremely large) of readers (processes) is provided with const_table.erl (refer to const_table_test.erl for a test thereof).

No ETS table, replication (e.g. per-process table copy) or message sending is involved: thanks to meta-programming, a module is generated on-the-fly, exporting as many functions as there are different keys in the table of interest. Calling a function corresponding to a key returns its associated value.

More precisely, a module name (e.g. foobar) and a list of {atom(), type_utils:permanent_term()} [10] entries shall be provided to const_table:generate_in_{memory,file}/2; then, for each key/value pair in the specified table (e.g. {baz, 42.0}), a 0-arity function is generated and exported in that module, as if we had:

-module(foobar).

[...]

-export([baz/0]).

-spec baz() -> term().
baz() ->
  42.0.

Then third-party code can call for example foobar:foo() and have 42.0 returned. This is presumably the most efficient way of sharing constants in Erlang between many processes (supposedly at least on par with persistent_term).

Note that with generate_in_memory/2 no actual module file is created (e.g. no foobar.beam file is ever written in the filesystem): the operation remains fully in-memory (RAM). With generate_in_file/{2,3} a suitable module file is written on disk, so that the corresponding module can be loaded in the future like any other module.

Keys must be atoms, and the table of interest shall be immutable (const), even if, thanks to hot code upgrade, one may imagine updating the table at will, having any number of successive versions of it.

Generating a table of the same name more than once should be done with care, as if a given table is generated thrice (hence updated twice), the initial table would first switch from "current" to "old", and then would be removed. Any process that would linger in a function of this module would then be terminated (see code replacement). However, due to the nature of these tables (just one-shot fully-qualified calls, no recursion or message-waiting construct), this is not expected to happen.

Finally, two extra table types exist:

• const_bijective_table, like a crossbreeding of const_table and bijective_table, to rely on module-supported const, bijective tables: a list of {type_utils:permanent_term(), type_utils:permanent_term()} entries can then provided so that a corresponding module (e.g. foobar) is generated (either in-memory or as a file) that allows to resolve any element of a pair into the other one, thanks to two functions, foobar:get_first_for/1 and foobar:get_second_for/1, automatically defined in that module; this is especially useful as soon as having non-small, const, bijective tables (since typing all information twice, one in a first direction and one in the other, is time-consuming and error-prone); refer to const_bijective_table_test.erl for an example and a test thereof
• const_bijective_topics is the same as the previous type, except that it allows multiple of such (const, bijective) tables (named "topics" here) to be defined in the same module (e.g. foobar); for that, each of such tables is designated by a topic (an atom, like: colour, bar_identifier or font_style) that is associated to a declared list of corresponding entries (here also each with no duplicate); then, for each of these topics (e.g. colour), two functions are automatically defined: foobar:get_first_for_colour/1 and foobar:get_second_for_colour/1, returning respective elements of the specified pair, for the specified topic; extra options can be set, in order to generate strict conversions or ones returning a maybe-type (typically so that they cannot be crashed), or to generate only one-way conversions (should either collection of elements have duplicates); refer to const_bijective_topics_test.erl for an example and a test thereof; the ability of defining multiple const, bijective tables in a single generated module can be useful typically when developping a binding (e.g. for a GUI, see gui_constants.erl) or when translating protocols (e.g. between a third-party library and internal conventions); refer to Ceylan-Oceanic for an example thereof, including about its build integration (based on the EXTRA_BEAM_FILES make variable)

Other Datatypes

They include pair.erl, option_list.erl, preferences.erl, tree.erl.

One may also refer for operations on:

• sets: set_utils.erl
• lists: list_utils.erl
• rings (i.e. circular buffers): ring_utils.erl
• binaries (i.e. raw binary information): bin_utils.erl

Pseudo-Builtin Types

Such types, as void/0 (for functions only useful for their side-effects - this happens!), maybe/1 (maybe(T) is either T or undefined), safe_maybe/1 (either {just,T} or nothing) and fallible/{1,2} (an operation either is successful and returns a result, or returns an error) are supported, thanks to the Myriad parse-transform.

Environments & Preferences

{my_first_color, red}.
{myHeight, 1.80}.
{'My name', "Sylvester the cat"}.

environment:get(my_first_color, my_foobar_env_server).

Resource Management

Basic File Formats

A built-in very basic support for the CSV, for Comma-Separated Values (see csv_utils) and RDF (see rdf_utils) conventions is provided.

Most Usual, Standard File Formats

Besides the support for XML, an optional support (as it depends on third-party prerequisites) is proposed for:

• JSON
• HDF5
• SQLite

Some useful information for XML use:

• Myriad's XML support is implemented by the xml_utils module (so one shall refer to xml_utils.{e,h}rl and xml_utils_test.erl), which relies on the built-in xmerl modules
• XML documents can be parsed from strings (see string_to_xml/1) or files (see parse_xml_file/1), and conversely can be serialised to strings (see xml_to_string/{1,2})
• an XML document is made from a list of XML elements, that can exist as three different forms that can be freely mixed: as "simple-form", as IOLists and/or as XML (xmerl) records
• we recommend the use of the "simple-form", which should be sufficient for at least most cases

This last form is based on simple tags, used in order to easily have (Erlang) terms that are direct counterparts of XML tags.

For example the following two elements (respectively in simple-form and as an XML document) are equivalent (if using the default XML prolog):

XMLSimpleContent = [
  myFirstTag,
  {mySecondTag, [myNestedTag]},
  {myThirdTag, [{color, "red"}, {age, 71}], ["This is a text!"]}].

and:

<?xml version="1.0" encoding="utf-8" ?>
<myFirstTag/>
<mySecondTag><myNestedTag/></mySecondTag>
<myThirdTag color="red" age="71">This is a text!</myThirdTag>

Refer to the xml_utils module for further details.

Some useful information for JSON use:

• the nesting of elements shall be done thanks to (Erlang) maps, whose keys are binary strings (text_utils:bin_string/0); their order should not matter
• it may thus be convenient to add -define(table_type, map_hashtable). in a user module, so that the table pseudo-module can be relied upon when building a json_term, while being sure that the JSON parser at hand will be fed afterwards with the relevant datastructure
• no comments shall be specified (even though some parsers may be configured to support them)
• strings shall be specified as binary ones
• the actual JSON backend used are either jsx or jiffy; to better understand their (mostly common) mapping between Erlang and JSON, one may refer to the this section of the jsx documentation and to this one regarding jiffy

Example:

MyJSONTerm = table:add_entries([
  {<<"asset">>, #{<<"generator">> => <<"My Generator">>,
                  <<"version">> => <<"2.0">>}},
  {<<"other">>, 42}
                               ], table:new()),

JSONString = json_utils:to_json(MyJSONTerm)

shall result in a JSON document like:

{
  "asset": {
    "generator": "My Generator",
    "version": "2.0"
  },
  "other": 42
}

Hint: the jq command-line tool may be very convenient in JSON contexts.

Refer to the Myriad-level Third-Party Dependencies section for further information.

For Pure Erlang uses: the ETF File Format

For many needs in terms of Erlang internal data storage (e.g. regarding configuration settings), we recommend the use of the file format that file:consult/1 can directly read, that we named, for reference purpose, ETF (for Erlang Term Format [11]). We recommend that ETF files have for extension .etf, like in: ~/.ceylan-settings.etf (see also our support for user preferences).

ETF is just a text format for which:

• a line starting with a % character is considered to be a comment, and is thus ignored
• other lines are terminated by a dot, and correspond each to an Erlang term (e.g. {base_log_dir, "/var/log"}.)

Note that no mute variable can be used there (e.g. _Name="James Bond" cannot be specified in such a file; only terms like "James Bond" can be parsed); so, in order to add any information of interest, one shall use comment lines instead.

Records are not known either; however they can be specified as tagged tuples (e.g. instead of specifying #foo{ bar=7, ...}, use {foo, 7, ...}).

See this example of a full ETF file.

A basic support for these ETF files is available in file_utils:{read,write}_etf_file/*.

If expecting to read UTF-8 content from such a file, it should:

• have been then opened for writing typically while including the {encoding,utf8} option, or have been written with content already properly encoded (maybe more reliable that way)
• start with a %% -*- coding: utf-8 -*- header

ETF files are notably used as configuration files. In this case following extra conventions apply:

• their extension is preferably changed from .etf to .config
• before each entry, a comment describing it in general terms shall be available, with typing information
• entries are pairs:
  • whose first element is an atom
  • their second element can be any value, typically of algebraic types; if a string value is included, for readability purpose it shall preferably be specified as a plain one (e.g. "James Bond") rather than a binary one (e.g. <<"James Bond">>); it is up to the reading logic to accommodate both forms; it is tolerated to reference, in the comments of these configuration files, types that actually include binary strings (not plain ones, even though plain ones are used in the configuration files)

To Export 3D Scenes

A basic support of glTF (Graphics Language Transmission Format) version 2.0 has been implemented in gltf_support.{hrl,erl}.

The various elements associated to that model (scenes, nodes, meshes, primitives, materials, lights, cameras, buffers, buffer-views, accessors) can be handled from Erlang, in an already integrated way to Myriad's spatial services and conventions.

See the glTF 2.0 Reference Guide and the glTF 2.0 Specification for more information. See also our HOW-TO about 3D for both more general and practical considerations.

Serialisation: Marshalling / Demarshalling

$ cd ~/Software/gpb
$ git clone git@github.com:tomas-abrahamsson/gpb.git
$ ln -s gpb gpb-current-install
$ cd gpb && make all

# Erlang protobuf gpb support:
export GPB_ROOT="${HOME}/Software/gpb/gpb-current-install"
export PATH="${GPB_ROOT}/bin:${PATH}"

For Basic, Old-School Ciphering

The spirit here is to go another route than modern public-key cryptography: the classic, basic, chained, symmetric cryptography techniques used in this section apply to contexts where a preliminary, safe exchange can happen between peers (e.g. based on a real-life communication).

Then any number of passes of low-key, unfashioned algorithms (including one based on a Mealy machine) are applied to the data that is to cypher or decypher.

We believe that, should the corresponding shared "key" (the combination of parameterised transformations to apply on the data) remain uncompromised, the encrypted data is at least as safe as if cyphered with the current, modern algorithms (which may be, intentionally or not, flawed, or may be specifically threatened by potential progresses for example in terms of quantum computing).

So this is surely an instance of "security by obscurity", a pragmatic strategy (which may be used in conjunction with the "security by design" and "open security" ones) discouraged by standards bodies, yet in our opinion likely - for data of lesser importance - to resist well (as we do not expect then attackers to specifically target our very own set of measures, since the specific efforts incurred would not be outweighed by the expected gains).

We thus see such old-school ciphering as a complementary measure to the standard, ubiquitous measures whose effectiveness is difficult to assess for individuals and thus require some level of trust.

Refer to cipher_utils and its associated test for more details, and also to our mini-HOWTO regarding cybersecurity.

For Classical 2D Applications

Purpose of gui

The goal is to provide a small, lightweight API (including message types) that are higher-level than wx and OpenGL (more integrated, more typed, possibly clearer, having more runtime checks - that can be toggled at build time), and do not depend on any particular GUI backend (such as wx, gs, etc.; so none of their includes, records, types or functions leak in the user realm), to avoid that user programs become obsolete too quickly because of the UI backend they rely on.

So for example the messages received by the user programs do not mention wx, and respect only MyriadGUI conventions. These conventions are in line with the WOOPER ones, enabling (in a fully optional manner) the user code to rely on WOOPER if wanted [19].

[19]

Inspired from MyriadGUI, one could consider creating WOOPERGUI, which would provide basically the same services, yet relying on inheritance on the Erlang side as well. That way for example a frame would be a special case (hence a child class) of window, and frames would automatically inherit all window operations; so the user would have just to handle a frame by itself, without having to take into account the fact that some operations of interest are actually defined at the window level instead.

The usual mode of operation is the following:

1. From a user process (a test, an application, etc.), the GUI support is first started, with gui:start/{0,1}
2. Then the various widgets (windows, frames, panels, buttons, etc.) are created (e.g. thanks to MainFrame = gui:create_frame(...) and the user process subscribes to the events it is interested in (as a combination of an event type and a widget-as-an-event-emitter; for example:

gui:subscribe_to_events({onWindowClosed, MainFrame})

3. The user process also triggers any relevant operation (e.g. clearing widgets, setting various parameters), generally shows at least a main frame and records the GUI state that it needs for future use (typically containing at least the MyriadGUI references of the widgets that it created)
4. Then the user process enters its own (GUI-specific) main loop, from which it will receive the events that it subscribed to, and to which it will react by performing application-specific operations and/or GUI-related operations (creating, modifying, deleting widgets). Generally at least one condition is defined in order to leave that main loop and stop the GUI (gui:stop/0)

Such a scheme based on a "man-in-the-middle" (the MyriadGUI process) is necessary to abstract out for example the types of messages induced by a given GUI backend. If performances should not be an issue for user interaction, the integration must be carefully designed, notably because a 3-actor cooperation (user code, MyriadGUI one, backend one) opens the possibility of race conditions to occur (notably some operations, like event subscribing, must then be made synchronous, as the user process may trigger direct interactions with the backend; see implementation notes for more details).

Refer to the gui_overall_test.erl and lorenz_test.erl test full, executable usage examples thereof.

Here is a screenshot of the former test, where a random polygon (in green) is generated, for which are determined both the convex hull (in blue) and the MEC (Minimum Enclosing Circle, in purple):

Defining gui as an interface between the user code and a backend also allows to enrich said backend [20].

[20]

For example, we needed to operate on a plain canvas, whereas wx (as we understand it) offers only panels with bitmaps (with wxDC, wxWindowDC, wxMemoryDC, etc.), with no possibility to subclass them in order to add them features. So MyriadGUI transparently introduced gui_canvas to offer extended canvas services.

These services are located in {src,test}/user-interface/graphical (see gui.erl, gui_color.erl, gui_text.erl, gui_canvas.erl, etc.), with a few tests (gui_test.erl, lorenz_test.erl) and will be enriched over time, on a per-need basis.

This last lorenz_test.erl offers another complete example:

For 3D Applications

3D Services

User API

The Myriad OpenGL utilities are defined in the gui_opengl module.

Shaders can be defined, in GLSL (see this page for more information).

Myriad recommends using the vertex.glsl extension for vertex shaders, the .tess-ctrl.glsl one for tessellation control shaders and .tess-eval.glsl for tessellation evaluation ones, .geometry.glsl for geometry shaders, fragment.glsl for fragment shaders and finally .compute.glsl for compute shaders.

The many OpenGL defines are available when having included gui_opengl.hrl (e.g. as ?GL_QUAD_STRIP).

Quite many higher-level primitives are provided, like gui_shader:assign_new_vbo_from_attribute_series/2, which in one operation merges automatically an arbitrary number of vertex attribute series (vertices, normals, texture coordinates, etc.) of arbitrary component types and counts in a suitable VBO, and declares appropriately and enables the corresponding vertex attributes.

These utilities directly relate to Myriad's spatial services and conventions and to its support of the glTF file format.

To manage larger 3D scenes, a basic support of octrees is also available (see octree.erl); following conventions apply:

Various tests offer usage examples of the MyriadGUI API for 3D rendering:

• gui_opengl_minimal_test.erl runs a minimal test showcasing the proper local OpenGL support, based on normalised coordinates (in [0.0,1.0])
• gui_opengl_2D_test.erl is a 2D test operating with absolute (non-normalised) coordinates
• gui_opengl_integration_test.erl demonstrates more features (quadrics, textures, etc.)
• gui_opengl_mvc_test.erl proposes a MVC architecture (Model-View-Controller) where these three elements are uncoupled in separate processes yet are properly interlinked, the view relying on the MyriadGUI OpenGL support
• gui_opengl_minimal_shader_test.erl showcases the use of more recent OpenGL APIs (3.3 core [21]), with GLSL shaders defined in gui_opengl_minimal_shader.{vertex,fragment}.glsl

[21]	Not compatible with all GPUs; notably Intel ones may only support older versions (e.g. 2.1).

Note

Almost all OpenGL operations require that an OpenGL context already exists. When it is done, all GL/GLU operations can be done as usual.

So the point of MyriadGUI here is mostly to create a suitable OpenGL context, to offer a few additional, higher-level, stricter constructs to ease the integration and use (e.g. for the compilation of the various types of shaders and the linking of GLSL programs), and to connect this rendering capability to the rest of the GUI (e.g. regarding event management).

Modern OpenGL is supported (e.g. version 4.6), even though the compatibility context allows to use the API of OpenGL version 1.1.

See the HOWTO section about OpenGL for more explanations.

Actual Use

The MyriadGUI modules can be readily used.

The recommended way of, if needed, using the MyriadGUI includes is:

% The sole include that MyriadGUI user code shall reference:
-include_lib("myriad/include/myriad_gui.hrl").

Configuration

In terms of error management, extensive verifications will apply iff the myriad_check_opengl_support flag is set.

Setting the myriad_debug_opengl_support flag will result in more runtime information to be reported.

Checking GLSL Shaders

One's shader can be checked thanks to glslangValidator, the OpenGL / OpenGL ES Reference Compiler.

For example, in order to check a vertex shader named foo.vertex.glsl, just run make check-foo.vertex.glsl; the GLSL reference compiler does not return output if it detects no error.

Refer to our HOWTO section for more information.

Troubleshooting

Your textures include strange pure green areas? Most probably that your texture coordinates are wrong, as pure green is the default padding color that MyriadGUI uses (see the padding_color define in the gui_texture module) so that the dimensions of textures are powers of two.

Internal Implementation

MyriadGUI is a wrapper on top of wx. What are the main differences between MyriadGUI and wx?

• preferred namings introduced (e.g. onWindowClosed events found clearer than close_window ones)
• widget identifiers are user-defined atoms in MyriadGUI (e.g. my_widget_id) rather than numerical constants (e.g. -define(MY_WIDGET_ID, 2051)) that have, with wx, to be defined, shared, uniquified accross user modules
• by default, events will propagate or be trapped by user-defined handlers depending on the type of these events (most of them being propagated by default; of course the user is able to override these defaults, either at subscription-time - using the propagate_event or trap_event option, or in one's handler - using the gui:propagate_event/1 or gui:trap_event/1 function); this contrasts with wx, in which by default all subscribed events are trapped, regardless of their type (then forgetting to propagate them explicitly may result in built-in mechanisms of wx to be disabled, like when resizing)
• code using MyriadGUI will not depend on wx, opening the possibility that, should the main Erlang GUI backend change, user code is nevertheless preserved

See also our little Using wx HOWTO.

Regarding hardware acceleration, the MyriadGUI 2D/3D services rely on the related Erlang-native modules, namely gl and glu, which are NIF-based bindings to the local OpenGL library.

As for the wx module (see the wx availability section), it provides a convenient solution in order to create a suitable OpenGL context.

esdl used to be another solution to obtain an OpenGL context; it may be revived some day, as SDL - i.e. Simple DirectMedia Layer - is still striving, and offers a full (yet low-level) access to multimedia and input devices; not all applications may have use of the rest of wx.

These Erlang-native services can be easily tested by running wx:demo() from any Erlang shell and selecting then gl in the left example menu.

These platform-specific / backend-specific (e.g. wx or not, and which version thereof, e.g. wxWidget 2.8 vs 3.0 API) services shall remain fully invisible from MyriadGUI user code, so that it remains sheltered for good from any change at their level.

The goal is to wrap only the dependencies that may change in the future (e.g. wx); doing so for the ones considered (for good reasons) stable (such as gl or glu) would have no specific interest.

For Multimedia Applications

Currently we provide only very preliminary support thereof with audio_utils; for sound and music playback, refer to the audio section for more details.

Speech synthesis (TTS, Text-to-Speech) is available thanks to speech_utils.erl. In practice, for best results, the actual speech generation is delegated to cloud-based providers making use of AI (neural voices) for best fluidity.

The input text shall preferably comply with SSML, typically so that it can be enriched with phonemes and prosody hints.

One can listen to this French speech and this English one (most browsers are now able to playback Opus content), that have been both generated by speech_utils_test.erl.

Facilities to manage logical speeches (i.e. speeches designated by a base name such as hello and declined in as many locales as needed) are available (see speech_support:logical_speech/0), as well as for related containers (see speech_support:speech_referential/0).

For Interactive Applications

Beyond the rendering of multimedia content, user interfaces have to collect inputs from the user, typically through mice, keyboards and joysticks.

Formerly, a port of SDL, esdl, was the best option, now using wx for that is recommended, as, through this port, the various input devices can be managed (at least to a large extent).

Searching for Erlang elements

ergrep

To search for a text pattern through an Erlang source tree.

Usage: ergrep [-v|--verbose] [-q|--quiet] [-f|--filenames-only] [-i|--insensitive] <Expression to be found in sources> [TARGET_BASE_DIR]: recursive grep in Erlang source files, either from the TARGET_BASE_DIR directory, if specified, otherwise from the current directory.

Options:

-v or --verbose: be specifically verbose

-q or --quiet: be specifically quiet, just listing matches

-f or --filenames-only: display only filenames, not also the matched patterns, and if there are multiple matches in the same file, its filename will be output only once (implies quiet); useful for scripts

-i or --insensitive: perform case-insensitive searches in the content of files, and also in the searched Erlang filenames

Example: ergrep -i 'list_to_form(' /tmp

find-type-definition.sh

To search for the definition of a type of interest.

Usage: find-type-definition.sh [-h|--help] A_TYPE [A_DIR]: attempts to find the definition of the specified Erlang type from the specified directory (if any), otherwise from the current one.

find-function-specification.sh

To search for a function spec of interest.

Usage: find-function-specification.sh [-h|--help] A_FUNCTION_NAME [A_DIR]: attempts to find the type specification for the specified Erlang function (even if the name is partial and/or includes an arity) from the specified directory (if any), otherwise from the current one.

find-record-definition.sh

To search for the definition of a record of interest.

Usage: find-record-definition.sh [-h|--help] A_RECORD_NAME [A_DIR]: attempts to find the definition of the specified Erlang record from the specified directory (if any), otherwise from the current one.

kill-beam.sh

To kill carefully-selected Erlang VM instance(s).

Usage: kill-beam.sh [-h|--help]: interactively terminates otherwise kills the user-selected Erlang (BEAM) virtual machines that were launched thanks to '-eval'.

Regarding Typing

list-available-types.sh

Lists all Erlang types found in specified tree.

Usage: list-available-types.sh [-h|--help] [ROOT_DIR]: lists all types (according to Erlang type specifications) defined from the ROOT_DIR directory (if specified) or from the current directory.

add-deduced-type-specs.escript

Generates and adds the type specification of all functions in specified module(s).

Usage: add-deduced-type-specs.escript FS_ELEMENT

Adds, for each selected BEAM file (either specified directly as a file, or found recursively from a specified directory), in the corresponding source file(s), for each function, the type specification that could be deduced from its current implementation.

FS_ELEMENT is either the path of a BEAM file or a directory that will be scanned recursively for BEAM files.

Note that BEAM files must be already compiled, and with debug information (see the '+debug_info' compile flag).

Note also that generating type specs this way may not a good practice.

Regarding Basic Performance Measurement

etop.sh

Monitors on the console the busiest Erlang processes of a VM.

Usage: etop.sh [-node NODE_NAME] [-setcookie COOKIE]: shows on the console the activity of the Erlang processes on specified Erlang node (enter CTRL-C twice to exit).

Example: etop.sh -node foobar@baz.org -setcookie 'my cookie'

benchmark-command.escript

Returns a mean resource consumption for the specified shell command (one may prefer relying on benchmark-command.sh).

Usage: benchmark-command.escript COMMAND: returns a mean resource consumption for the specified shell command.

Example: benchmark-command.escript "my_script.sh 1 2"

Miscellaneous

make-code-stats.sh

Outputs basic statistics about an Erlang code base.

Usage: make-code-stats.sh [-h|--help] [SOURCE_DIRECTORY]: evaluates various simple metrics of the Erlang code found from any specified root directory, otherwise from the current one.

launch-erl.sh

The only shell script on which we rely in order to launch an Erlang VM.

Usage: launch-erl.sh [-v] [-c a_cookie] [--sn a_short_node_name | --ln a_long_node_name | --nn an_ignored_node_name ] [--tcp-range min_port max_port] [--epmd-port new_port] [--fqdn a_fqdn] [--max-process-count max_count] [--busy-limit kb_size] [--async-thread-count thread_count] [--background] [--non-interactive] [--eval an_expression] [--no-auto-start] [-h|--help] [--beam-dir a_path] [--beam-paths path_1 path_2] [-start-verbatim-options [...]]: launches the Erlang interpreter with specified settings.

Detailed options:

-v: be verbose

-c a_cookie: specify a cookie, otherwise no cookie will be specifically set

--sn a_short_node_name: distributed node using specified short name (e.g. 'my_short_name')

--ln a_long_node_name: distributed node using specified long name (e.g. 'my_long_name')

--nn an_ignored_node_name: non-distributed node, specified name ignored (useful to just switch the naming options)

--tcp-range min_port max_port: specify a TCP port range for inter-node communication (useful for firewalling issues)

--epmd-port new_port: specify a specific EPMD port (default: 4369); only relevant if the VM is to be distributed (using short or long names), initially or at runtime

--fqdn a_fqdn: specify the FQDN to be used

--max-process-count max_count: specify the maximum number of processes per VM (default: 400000)

--busy-limit size: specify the distribution buffer busy limit, in kB (default: 1024)

--async-thread-count thread_count: specify the number of asynchronous threads for driver calls (default: 128)

--background: run the launched interpreter in the background (ideal to run as a daemon, e.g. on a server)

--daemon: run the node as a daemon (relies on run_erl and implies --background)

--non-interactive: run the launched interpreter with no shell nor input reading (ideal to run through a job manager, e.g. on a cluster)

--eval 'an Erlang expression': start by evaluating this expression

--no-auto-start: disable the automatic execution at VM start-up

-h or --help: display this help

--beam-dir a_path: adds specified directory to the path searched for beam files (multiple --beam-dir options can be specified)

--beam-paths first_path second_path ...: adds specified directories to the path searched for beam files (multiple paths can be specified; must be the last option)

--log-dir: specify the directory in which the VM logs (if using run_erl) shall be written

Other options will be passed 'as are' to the interpreter with a warning, except if they are listed after a '-start-verbatim-options' option, in which case they will passed with no warning.

If neither '--sn' nor '--ln' is specified, then the node will not be a distributed one.

Example: launch-erl.sh -v --ln ceylan --eval 'foobar_test:run()'

show-xml-file.escript

Displays the content of the specified XML file.

Usage: show_xml_file.escript XML_FILE_PATH

Displays sequentially in a {name,Value} tree the structure of specified XML file (XML elements along with their XML attributes).

To generate documentation

These scripts are mostly unrelated to Erlang, yet are useful to be available from our most basic layer (Myriad).

generate-docutils.sh

Generates a proper PDF and/or HTML file from specified RST (reStructuredText) one (main, standalone script).

Usage: generate-docutils.sh <target rst file> [--pdf|--all|<comma-separated path(s) to CSS file to be used, e.g. common/css/XXX.css,other.css>] [--icon-file ICON_FILENAME]

Generates a final document from specified docutils source file (*.rst).

If '--pdf' is specified, a PDF will be created, if '--all' is specified, all output formats (i.e. HTML and PDF) will be created, otherwise HTML files only will be generated, using any specified CSS file.

generate-pdf-from-rst.sh

Generates a proper PDF and/or HTML file from specified RST (reStructuredText) one; the previous generate-docutils.sh script is often preferred to this one, which depends on Myriad.

Usage: generate-pdf-from-rst.sh RST_FILE: generates a PDF file from the specified RST file, overwriting any past file with that name.

For instance 'generate-pdf-from-rst.sh my_file.rst' will attempt to generate a new 'my_file.pdf' file.

Linear Conventions

Dimensions are non-null (a zero dimension has little interest). Dimension 1 corresponds to scalar and is not special-cased (hence one shall preferably use directly scalars if able to determine that being in a single dimension context).

A linear-related index (e.g. of a coordinate of a point, a vector or a matrix) starts at 1 (not 0), as by default all indices in Myriad.

Points are to be specified by the user as tuples (preferably to lists) whose coordinates are either integer ones (for example P =  10   45 translating to P={10,45}, typically for GUI-related processing of on-screen coordinates) or floating-point ones ({0.0, -1.0, 0.0} for a point in 3D space). This is the most natural term mapping, and their internal representation is an homogeneous tuple (i.e. whose elements are all of the corresponding type): either integer_point/0 or point/0.

The vast majority of the linear operations can be carried by modules operating either on:

• arbitrary dimensions (as high as needed, and freely chosen by the user, at compile-time or runtime)
• specialised dimensions, namely 2D, 3D or 4D; their interest lies in efficiency (these specialised constructs are designed to induce less computing and smaller memory footprints) and in the definition of dimension-specific operators (e.g. the cross-products in 3D)

Points can therefore be of arbitrary dimension (then they are taken in charge by the point module), or can be specialised for 2D, 3D or 4D (then they are taken in charge by the point{2,3,4} modules).

As for vectors, they are to be specified by the user as lists of floating-point coordinates (e.g. V⃗ =  0.0    − 7.3   3.22 translating to V=[0.0, -7.3, 3.22]); this directly corresponds to their internal representation, in order to better accommodate linear operations (being a special case of matrices).

So vectors also can be of arbitrary dimension (then they are taken in charge by the vector module), or can be specialised for 2D, 3D or 4D (then they are taken in charge by the vector{2,3,4} modules).

Points and vectors (of arbitrary dimension, or specialised) can be converted both ways, see point*:{to,from}_vector/1 and vector*:{to,from}_point/1. As their types differ (tuple versus list), they can be unambiguously discriminated, which is useful for some operations [23].

The matrices handled here can be of any dimensions (they are often square), and their elements are floating-point coordinates as well.

Let's consider a m × n matrix (m rows, n columns):

With Myriad, such a matrix may be expressed:

• as one of arbitrary dimension (designated from now on as an "arbitrary matrix"), corresponding to the matrix:matrix/0 type; internally such matrices are nested lists: a list of m rows, each being a list of n elements, hence defined in row-major order (not column-major one)
• if being square and of a well-known dimension among 2, 3 or 4 (special cases defined for convenience and performance), as a value belonging to the matrix{2,3,4}/0 types (which are records like #matrix4{}, whose fields are named according to the matrix elements, such as m41); they are designated hereafter as "specialised matrices"
• in a symbolic way, such as identity_4 (meaning the identity 4x4 matrix)
• for some dimensions (e.g. 3D or 4D), extra representations exist (compact 4x4 matrices, made of a 3x3 matrix and a vector3, in the context of homogeneous operations)

Taking as an example a 2x2 matrix like:

it can be created as an arbitrary matrix/0 with:

M1 = matrix:new([ [A11,A12], [A21,A22] ])

Alternatively it can be directly created as a specialised (presumably more efficient) 2x2 matrix matrix2 with:

M2 = matrix2:new([ [A11,A12], [A21,A22] ])
% Or:
M3 = matrix2:from_coordinates(A11, A12, A21, A22)
% Or even:
M4 = matrix2:from_arbitrary(M1)
M5 = matrix:specialise(M1)

There is a priori little interest in "unspecialising" (i.e. going from specialised to arbitrary matrix) by having:

M6 = matrix:unspecialise(M2)

In practice the actual, internal terms corresponding to all these matrices would be:

% For arbitrary ones:
% (supposing that all Axy coordinates are already floats):
M1 = M6 = [ [A11,A12],
            [A21,A22] ]

% For specialised ones:
M2 = M3 = M4 = M5 = #matrix2{ m11=A11, m12=A12,
                              m21=A21, m22=A22 }

Finally, quaternions are also supported (see quaternion.erl). They can be defined from 4 numbers, or as a 3D rotation. They are stored as quadruplets of floats, and can be added, multiplied, negated, scaled, normalised, conjugated, inversed, etc., and may be represented either as

or as:

They notably provide a higher-level, more convenient counterpart to 3x3 rotation matrices (see matrix3:rot_matrix3()); both can be computed from a unit axis and an angle.

Note that:

• we call a container type-homogeneous iff all the coordinates that it gathers are all either integer or floating-point ones
• new instances (e.g. of points, matrices, vectors, quaternions) may be:
  • either literally specified, with a term directly corresponding to their internal form
  • or based on a new operator (e.g. matrix:new/1), in which case with a higher-level user-term (e.g. a matrix with integer coordinates, in which case they will be automatically converted to floats)
• for clarity and in order to provide them with specified operations (like dot product), we preferred defining vectors as a separate type from the matrix one (even if a vector can be seen as a 1-column matrix)
• by default, for least surprise, coordinates are displayed in full, i.e. not rounded (refer to the printout_{width,precision} defines in linear.hrl)
• the procedure to check the validity of computations is the following:
  • first implement the arbitrary version
  • validate it, by composing internal operations and by comparison with a tool like Scilab/Octave
  • implement the specialised versions
  • validate them against the arbitrary version
• the most common operations are defined for each datatype: creating, modifying, comparing, displaying and, whenever appropriate: adding, subtracting, scaling, multiplying, rotating, measuring, transposing, reversing, etc.
• operations are not implemented defensively, in the sense that a base runtime error will be triggered if a type or a size does not match, rather than being tested explicitly (anyway generally no useful extra context could then be specifically reported)
• additional runtime checks (e.g. to check whether parameters expected to be unit vectors are normalised indeed) can nevertheless be enabled by setting the myriad_check_linear flag (refer to GNUmakevars.inc)
• for homogeneous coordinates: any implicit homogeneous w coordinate is 1.0
• most operations here involve floating-point coordinates, rather than integer ones; as an Erlang's float() is a double-precision one, it requires more resources (CPU and memory footprint) than a basic, single-precision one; for applications not requiring extra precision, maybe the Erlang VM could be compiled in order to rely on single-precision floats instead

Geometric Conventions

For space coordinates, three axes are defined for a global referential:

• abscissa: X axis (in red, #FF0000)
• ordinate: Y axis (in green, #008000)
• depth: Z axis (in blue, #0000FF)

By default, we consider right-handed Cartesian coordinate systems (like OpenGL; unlike DirectX or Vulkan), and we rely on "Z-up" conventions (the Z axis being vertical and designating altitudes), like modelling software such as Blender [24].

In 2D, typically for on-screen coordinates (e.g. when drawing in a canvas), the corresponding projected referential applies, based on the X and Y axes, the origin being in the top-left corner, and all Z coordinates being zero [25]:

For each of the spatial dimensions of interest, generally 1.0 corresponds to 1 meter, otherwise to 1 light-second (i.e. roughly 300 000 km [26]).

For all angles, the default unit is the radian (2π radians is equal to 360 degrees), and the positive rotation is counterclockwise.

By default (see gui_opengl_transformation_shader_test.erl for an example thereof):

• the viewpoint ("camera") is pointing down the Z axis, its vertical ("up" on its screen) vector being +Y; so an horizontal line on the screen drawn from left to right goes along the +X axis, whereas a vertical, bottom to top (vertical) line goes along the +Y axis
• in terms of projections:
  • with an orthographic one: the viewing volume is a cube within [-1.0, 1.0] in all dimensions; so for example a square whose edge length is 1.0, centered at the origin and pertaining to the X-Y plane will disappear as soon as its Z > 1.0 or Z < -1.0
  • with a perspective one: the same square will appear as soon as it is sufficiently far from the camera; more precisely, in the aforementioned test, the square starts at Z=0.0, whereas for the camera the minimum viewable distance along the -Z axis is ZNear=0.1; so the square shall move further down the Z axis so that the camera starts to see it (first at full size when its Z=ZNear), until, as its Z still decreases, the square shrinks progressively in the distance

For face culling, front-facing is determined by relying on a counter-clockwise order winding order of triangles (like default OpenGL's GL_CCW):

Indeed a triangle enumerating its vertices in counter-clockwise order (A->B->C) would define a normal vector N⃗ = ⟶AB × ⟶BC pointing towards the outside of a body comprising that triangle.

If V⃗⋅N⃗ (i.e. the dot-product of the view direction vector and of this outward vector product) is:

• strictly negative: then the face is front-facing
• positive: then the face is rear-facing

Said otherwise, front-facing polygons are the ones whose signed area (determinant) is strictly positive; see also: polygon:{get_area,get_signed_area}/1.

A fourth coordinate besides X, Y and Z could be used, as an extra axis (in yellow, #F6DE2D):

• either for homogeneous coordinates, in which case it will be considered to be spatial as well, with the same unit as the three first ones, and preferably designated as W
• or for time coordinates, with a single axis defined for a global referential: the T one, for which 1.0 corresponds to 1 second

We consider that clip space ranges in [-1.0, 1.0] (like OpenGL conventions; rather than for example [0.0, 1.0], which are the D3D ones).

Related Services

Elements of interest can be:

• some support of polygons, in polygon.erl - a basic support for (2D) bounding surfaces (including rectangles, "lazy" circles and Minimal Enclosing Circles based on convex hulls; see bounding_surface.{hrl,erl}) and corresponding (3D) bounding volumes (including right cuboids and spheres; see bounding_volume.{hrl,erl})
• elements in order to import/export 3D scenes thanks to the glTF file format

Possible Enhancements

In the future, the most usual spatial types such as matrix and vector may be shortened in Myriad-based code as respectively m and v, the Myriad parse transform being then in charge of expanding accordingly (e.g. a in-code shorthand m3:new/0 becoming matrix3:new/0 to the eyes of the compiler).

Aliases

For convenience, aliases of units can be defined, i.e. alternate names for a given canonical unit. For example the Hertz unit (Hz) is an alias of the s^-1 (per-second) canonical unit.

Built-in Units

So one may use the following built-in units, whose symbol [27] is specified here between brackets, like in "[N.m]" (an alternate notation is to prefix a unit with U:, like in "U: N.m"):

• the seven SI base units, namely:
  • meter, for length [m]
  • gram, for mass [g] [28] (note: this is a footnote, not an exponent!)
  • second, for time [s]
  • ampere, for electric current [A]
  • kelvin, for thermodynamic temperature [K]
  • mole, for the amount of substance [mol]
  • candela, for luminous intensity [cd]
• the usual derived units, notably:
  • hertz, for frequency [Hz]
  • degree, for degree of arc [°] (not supported yet)
  • radian, for angle [rad] (not supported yet)
  • steradian, for solid angle [sr] (not supported yet)
  • newton, for force, weight [N]
  • pascal, for pressure, stress [Pa]
  • joule, for energy, work, heat [J]
  • watt, for power, radiant flux [W]
  • coulomb, for electric charge, quantity of electricity [C]
  • volt, for voltage, electrical potential difference, electromotive force [V]
  • farad, for electrical capacitance [F]
  • ohm, for electrical resistance, impedance, reactance [Ohm]
  • siemens, for electrical conductance [S]
  • weber, for magnetic flux [Wb]
  • tesla, for magnetic field strength, magnetic flux density [T]
  • henry, for inductance [H]
  • lumen, for luminous flux [lm]
  • lux, for illuminance [lx]
  • becquerel, for radioactive decays per unit time [Bq]
  • gray, for absorbed dose of ionizing radiation [Gy]
  • sievert, for equivalent dose of ionizing radiation [Sv]
  • katal, for catalytic activity [kat]
• the units widely used in conjunction with SI units (note that they may not respect the principle of being a product of integer powers of one or more of the base units):
  • litre, for 10^-3m³volumes [L]
  • tonne, for 1,000 kilogram masses [t]
  • electronvolt, for 1.602176565(35).10-19 joule energies [eV]
  • minute, for 60-second durations [min]
  • hour, for 60-minute durations [h]
  • day, for 24-hour durations [day]
  • week, for 7-day durations [week]
• the special units (they generally cannot map directly to any SI unit, yet can be handled separately), designating:
  • month [month] (correspondence to base time units unspecified, as this duration is not constant; e.g. a month can be 29, 30 or 31 days)
  • year [year] (correspondence to base time units unspecified, as this duration is not constant; e.g. a year can be 365, 366 or 365.25 days, etc.)
  • degree Celsius, for temperature relative to 273.15 K [°C] (see note below)
  • dimension-less quantities (e.g. an index) [dimensionless] (most probably clearer than m/m)
  • a count, i.e. a dimensionless number, generally a positive integer [count] (e.g. 14), considered as an alias of dimensionless
  • a ratio, i.e. a dimensionless floating-point value, generally displayed as a percentage [ratio] (e.g. -12.9%); another alias of dimensionless
  • currencies, either [$] (US Dollar) or [euros] (Euro), whose exchange rates of course vary
  • values whose unit has not been specified [unspecified_unit]
• metric prefixes thereof, i.e. multiples and sub-multiples of the units previously mentioned; currently the supported prefixes are:
  • yotta, i.e. 10²⁴ [Y]
  • zetta, i.e. 10²¹ [Z]
  • exa, i.e. 10¹⁸ [E]
  • peta, i.e. 10¹⁵ [P]
  • tera, i.e. 10¹² [T]
  • giga, i.e. 10⁹ [G]
  • mega, i.e. 10⁶ [M]
  • kilo, i.e. 10³ [k]
  • hecto, i.e. 10² [h]
  • deca, i.e. 10 [da]
  • deci, i.e. 10^-1 [d]
  • centi, i.e. 10^-2 [c]
  • milli, i.e. 10^-3 [m]
  • micro, i.e. 10^-6 [µ]
  • nano, i.e. 10^-9 [n]
  • pico, i.e. 10^-12 [p]
  • femto, i.e. 10^-15 [f]
  • atto, i.e. 10^-18 [a]
  • zepto, i.e. 10^-21 [z]
  • yocto, i.e. 10^-24 [y]

Composing One's Units

So an actual unit can be composed from the aforementioned built-in units (be they base, derived, widely used, special units; prefixed or not) [29], using two built-in operators, which are "." (multiply, represented by the dot character - not "*") and "/" (divide, represented by the forward slash character).

The resulting type shall be specified as a string, containing a series of built-in units (potentially prefixed) alternating with built-in operators, like in: "kW.s/m".

Finally, exponents can be used as a shorthand for both operators (e.g. kg.m^2.s^-1, instead of kg.m.m/s). They should be specified explicitly, thanks to the caret character ("^"); for example "m^2/s", not "m²/s".

If deemed both safe and useful, we may consider in the future performing:

• symbolic unit checking (i.e. determining that a derived unit such as N.s (newton.second) is actually, in canonical SI units, m^2.kg.s^-1), and thus that values of these two types can safely be used indifferently in computations
• automatic value conversions (e.g. converting km/hour into m/s), provided that the overall computational precision is not significantly deteriorated

The corresponding mechanisms (type information, conversion functions, unit checking and transformation, etc.) are defined in unit_utils.erl and tested in unit_utils_test.erl, in the myriad/src/utils directory.

Checking Units

A typical example:

1> MyInputValue="-24 mS.m^-1".
2> {Value,Unit}=unit_utils:parse_value_with_unit(MyInputValue).
3> io:format("Corresponding value: ~f.~n", [ Value ] ).
Corresponding value: -24.0.
4> io:format("Corresponding unit: ~s.~n",
   [unit_utils:unit_to_string(Unit)]).
"s^3.A^2.g^-1.m^-3, of order -6"
5> unit_utils:value_with_unit_to_string(Value,Unit).
"-2.4e-5 s^3.A^2.g^-1.m^-3"

SQLite 3

$ sqlite3 my_test

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
sqlite> create table tblone(one varchar(10), two smallint);
sqlite> insert into tblone values('helloworld',20);
sqlite> insert into tblone values('my_myriad', 30);
sqlite> select * from tblone;
helloworld|20
my_myriad|30
sqlite> .quit

$ mkdir ~/Software
$ cd ~/Software
$ git clone https://github.com/alexeyr/erlang-sqlite3.git
Cloning into 'erlang-sqlite3'...
remote: Counting objects: 1786, done.
remote: Total 1786 (delta 0), reused 0 (delta 0), pack-reused 1786
Receiving objects: 100% (1786/1786), 3.24 MiB | 570.00 KiB/s, done.
Resolving deltas: 100% (865/865), done.
Checking connectivity... done.
$ cd erlang-sqlite3/
$ make
rm -rf deps ebin priv/*.so doc/* .eunit/* c_src/*.o config.tmp
rm -f config.tmp
echo "normal" > config.tmp
./rebar get-deps compile
==> erlang-sqlite3 (get-deps)
==> erlang-sqlite3 (compile)
Compiled src/sqlite3_lib.erl
Compiled src/sqlite3.erl
Compiling c_src/sqlite3_drv.c
[...]

make test
./rebar get-deps compile eunit
==> erlang-sqlite3 (get-deps)
==> erlang-sqlite3 (compile)
==> erlang-sqlite3 (eunit)
Compiled src/sqlite3.erl
Compiled src/sqlite3_lib.erl
Compiled test/sqlite3_test.erl
======================== EUnit ========================
module 'sqlite3_test'
  sqlite3_test: all_test_ (basic_functionality)...[0.002 s] ok
  sqlite3_test: all_test_ (table_info)...ok
  [...]
  sqlite3_lib: delete_sql_test...ok
  sqlite3_lib: drop_table_sql_test...ok
  [done in 0.024 s]
  module 'sqlite3'
=======================================================
All 30 tests passed.
Cover analysis: ~/Software/erlang-sqlite3/.eunit/index.html

PostgreSQL

$ mkdir -p ~/Software && cd $_
$ git clone https://github.com/epgsql/epgsql.git
$ cd epgsql && make all && ln -s ./_build/default/lib/epgsql/ebin

Compiling module sql_support.erl : can't find include file "sqlite3.hrl"

• USE_SQLITE not set to true in myriad/GNUmakevars.inc
• erlang-sqlite3 backend not correctly installed (e.g. SQLITE3_BASE not pointing to a right path in myriad/GNUmakevars.inc)