see:
dorileo@24583a4#commitcomment-11911244

and

#121 (comment)

git bisect pointed to this commit: b37442e

$ sol-fbp-generator -j ./build/soletta_sysroot/usr/share/soletta/flow/descriptions/ ~/tmp/fbp/simple.fbp main.c

==466== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60040000dfb8 at pc 0x7fcb1c8f6a89 bp 0x7fff438ff4c0 sp 0x7fff438ff4b8
READ of size 1 at 0x60040000dfb8 thread T0
#0 0x7fcb1c8f6a88 (/usr/lib/libsoletta.so.0.0.1+0x8ea88)
0x60040000dfb8 is located 0 bytes to the right of 8-byte region [0x60040000dfb0,0x60040000dfb8)
allocated by thread T0 here:
#0 0x7fcb1ccfa55f (/usr/lib/x86_64-linux-gnu/libasan.so.0.0.0+0x1555f)
#1 0x7fcb1c9763c2 (/usr/lib/libsoletta.so.0.0.1+0x10e3c2)
#2 0x7fcb1c8f6008 (/usr/lib/libsoletta.so.0.0.1+0x8e008)
#3 0x7fcb1c8f693f (/usr/lib/libsoletta.so.0.0.1+0x8e93f)
#4 0x7fcb1c8f6a1d (/usr/lib/libsoletta.so.0.0.1+0x8ea1d)
#5 0x7fcb1c95f2ee (/usr/lib/libsoletta.so.0.0.1+0xf72ee)
#6 0x7fcb1c95fed7 (/usr/lib/libsoletta.so.0.0.1+0xf7ed7)
#7 0x7fcb1c96040c (/usr/lib/libsoletta.so.0.0.1+0xf840c)
#8 0x7fcb1c94d7c8 (/usr/lib/libsoletta.so.0.0.1+0xe57c8)
#9 0x7fcb1c960d97 (/usr/lib/libsoletta.so.0.0.1+0xf8d97)
#10 0x7fcb1c94c8ea (/usr/lib/libsoletta.so.0.0.1+0xe48ea)
#11 0x40c7e6 (/usr/bin/sol-fbp-generator+0x40c7e6)
#12 0x7fcb1c2a6ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
Shadow bytes around the buggy address:
0x0c00ffff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c00ffff9bf0: fa fa fa fa fa fa 00[fa]fa fa 00 00 fa fa 00 fa
0x0c00ffff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c00ffff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==466== ABORTING

• min/max option on conf file causing a invalid C file being generated

Using a conf to define the min/max option of a node cause a invalid C file being generated.

conf file:

{
 "$schema": "http://solettaproject.github.io/soletta/schemas/config.schema",
 "nodetypes": [
  {
   "name": "BaseServo",
   "options": {
    "chip": 0,
    "duty_cycle_range": "min:1000|max:2000",
    "period": 20000,
    "pin": 0
   },
   "type": "servo-motor/controller"
  }
 ]
}

fbp file:

base_servo(BaseServo)

invalid block generated:

static const struct sol_flow_node_type *
create_0_root_type(void)
{
    static const struct sol_flow_node_type_servo_motor_controller_options opts0 =
        SOL_FLOW_NODE_TYPE_SERVO_MOTOR_CONTROLLER_OPTIONS_DEFAULTS(
            .chip = {
                .val = 0,
            },
            .duty_cycle_range = {
                ."min=1000,
                .max=2000",
            },
            .period = {
                .val = 20000,
            },
            .pin = {
                .val = 0,
            },
        );
...

• Duplicated include on generated file

Having 2 or mode nodes of the same type on the fbp cause duplicated includes on the generated file.

Steps to reproduce the issue:

1. boot the galileo board from SD card
2. navigate to the path: soletta/samples/flow/galileo-grove-kit/lcd
3. export SOL_FLOW_MODULE_RESOLVER_CONFFILE=../galileo-grove-kit.json
4. execute each of the following examples:

grove-lcd-autoscroll.fbp
grove-lcd-blink.fbp
grove-lcd-cursor.fbp
grove-lcd-display.fbp
grove-lcd-fade.fbp
grove-lcd-hello-world.fbp
grove-lcd-scroll.fbp
grove-lcd-set-cursor.fbp
grove-lcd-text-direction.fbp

For each of the previous fbp listed, I got the following output error:

Couldn't resolve type 'LCDChar' of node 'lcd'

The soletta version used:

• git rev-parse HEAD 217beb8

Our build generates a bunch of artifacts inside the source dir, some of these files shouldn't be there. The current state is

$ make alldefconfig 2>&1 > /dev/null
$ make -j9 2>&1 > /dev/null
$ git clean -dfx
Removing .config
Removing .config-cache
Removing Kconfig.gen
Removing Makefile.gen
Removing build/
Removing data/scripts/sol-flow-node-type-find.py
Removing data/scripts/sol-flow-node-type-gen.py
Removing include/
Removing src/lib/common/sol-pin-mux-builtins-gen.h
Removing src/lib/flow/sol-flow-builtins-gen.h
Removing src/modules/flow/oic/oic.c
Removing src/modules/flow/oic/oic.c~
Removing src/modules/flow/oic/oic.json
Removing tools/kconfig/conf
Removing tools/kconfig/conf.o
Removing tools/kconfig/zconf.hash.c
Removing tools/kconfig/zconf.lex.c
Removing tools/kconfig/zconf.tab.c
Removing tools/kconfig/zconf.tab.o

Except for the directory build/ and the files tools/kconfig/ (which I presume need to be there so we don't change kconfig itself), all the other files should be inside build/ unless there's a compelling reason not to.

Following the README to build Soletta, I get a warning that sticks out like a sore thumb in the otherwise nice-and-clean output - but not indication if it is a problem or what to do about it :

$ make alldefconfig
...
$ make
...
./src/modules/flow/string/string.c:40:2: warning: #warning "You're building the string nodes module without i18n support -- some nodes will only act properly on pure ASCII input, not the intended utf-8 for Soletta" [-Wcpp]
 #warning "You're building the string nodes module without i18n support -- some nodes will only act properly on pure ASCII input, not the intended utf-8 for Soletta"
...

sol-missing.h has:

#define EBADR       53  /* Invalid request descriptor */

This macro is used outside of Linux-specific files.

That value is silly, since it matches ECONNABORTED on the BSDs (including OS X).

• Plattform: Linux kernel 3.13.0-30-generic #55~precise1-Ubuntu SMP Fri Jul 4 21:52:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
• gcc 4:4.6.3-1
• make 3.81-8.1
• Python 3.3.5
• steps to reproduce the issue:

1. git clone https://github.com/solettaproject/soletta.git
2. make alldefconfig
3. make

• the step (3) fails returning the following output:

' ./src/lib/common/sol-worker-thread-impl-glib.c:54:45: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function) '

• complete output here: http://pastebin.intel.com/view/2eb2a875

Whenever linux/i2c-dev.h is provided by i2c-tools, it is incompatible with linux/i2c.h.

Errors:

In file included from src/shared/sol-i2c-linux.c:39:0:
/usr/include/linux/i2c-dev.h:37:8: error: redefinition of ‘struct i2c_msg’
 struct i2c_msg {
        ^
In file included from src/shared/sol-i2c-linux.c:38:0:
/usr/include/linux/i2c.h:68:8: note: originally defined here
 struct i2c_msg {
        ^
In file included from src/shared/sol-i2c-linux.c:39:0:
/usr/include/linux/i2c-dev.h:89:7: error: redefinition of ‘union i2c_smbus_data’
 union i2c_smbus_data {
       ^
In file included from src/shared/sol-i2c-linux.c:38:0:
/usr/include/linux/i2c.h:128:7: note: originally defined here
 union i2c_smbus_data {
       ^

See https://build.opensuse.org/package/view_file/openSUSE:13.2/linux-glibc-devel/linux-glibc-devel.spec line 102

soletta v1_beta2 sha1: 3baae03

The following tests failed to run:

string-compare.fbp
string-lower-upper.fbp
string-concat.fbp
string-regexp-search.fbp
string-length.fbp

A complete list of returned errors is founded in the following link:

http://pastebin.com/hCVRyJZY

Thank you.

Currently we have to always pass CFLAGS="-g" for every make call. If the flag is forgotten, the build might get a mix of objects compiled with different flags.

There should be an easy way (config option maybe?) to declare a build is a debug one, and don't have to worry about passing the right CFLAGS.

$ ./build/stage/samples/flow/misc/random-numbers 
...
src/modules/flow/random/random.c:90:42: runtime error: signed integer overflow: 666 * 1812433253 cannot be represented in type 'int [624]'
src/modules/flow/random/random.c:73:13: runtime error: left shift of 513147066 by 7 places cannot be represented in type 'int'
src/modules/flow/random/random.c:74:13: runtime error: left shift of 395728058 by 15 places cannot be represented in type 'int'
...

This is running on a 32bits machine, but shouldn't matter as the type is just "int" (not long/off_t/size_t).

assigned to @lpereira as he introduced this code as an alternative to missing rand() in libC.

-Plattform: Linux kernel 3.13.0-30-generic #55~precise1-Ubuntu SMP Fri Jul 4 21:52:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
-gcc 4.9.2
-make 3.81-8.1
-Python 3.4
-git 2.5.0

Steps to reproduce this issue:

1. git clone https://github.com/solettaproject/soletta.git
2. make alldefconfig
3. make

complete output: http://pastebin.com/MMEacGXH

We should provide ArchLinux package and repository.

linux-micro will need a special trick to be debugged: we need to check debug is needed (ie: kernel command line sol-debug=1) and in that case we check we're PID1, if so we need to fork() and keep a minimal and safe PID1, doing all the work from the child. We should also check if gdbserver exists and attach it to the child (or spawn the child using gdbserver).

In order to test the SLV feature to export fbp files, I tried to convert a fbp file to .c source code with the following command line:

'/sol-fbp-generator2 -j /usr/share/soletta/flow/descriptions/builtins.json -j /usr/share/soletta/flow/descriptions/calamari.json SLV_Examples/slv_created_calamari_led_lever.fbp slv_calamari-lever.c'

• Output (error) returned by the previous command:

SLV_Examples/slv_created_calamari_led_lever.fbp:1:40 Expected ',' after key-pair meta information. e.g. '(nodetype:key1:val2,keyN:valN)'
Segmentation fault

• below is the content of the file: 'slv_created_calamari_led_lever.fbp' :

node2(calamari/lever:poll_interval=max:"INT32_MAX"|min:"INT32_MIN"|step:1|val:0,range=max:1023|min:0|step:1|val:0,bus=max:"INT32_MAX"|min:"INT32_MIN"|step:1|val:0,chip_select=max:"INT32_MAX"|min:"INT32_MIN"|step:100|val:0) OUT -> INTENSITY node3(calamari/led:period=max:"INT32_MAX"|min:"INT32_MIN"|step:1|val:10000,range=max:10000|min:0|step:5|val:0,address=1)

Thank you!

Compiler error impedes build soletta for Galileo board.

Steps to reproduce the issue:

• The procedure followed is the described in the wiki to compile soletta for Galileo plattform:https://github.com/solettaproject/soletta/wiki/Galileo-and-Galileo-Gen2-Instructions).

Below is error returned by make:
./src/shared/sol-util.c:49:1: error: unknown type name 'locale_t
./src/shared/sol-util.c:63:26: error: 'LC_ALL_MASK' undeclared (first use in this function)

The complete output is in the next link: http://pastebin.com/ZrueV2Nm

Thank you.

From a clean master branch:

make alldefconfig
mane menuconfig
Uncheck "Core Library -> Worker Thread Support" and save
make

What you get:
./build/soletta_sysroot/usr/lib//libsoletta.so: undefined reference to sol_worker_thread_cancel' ./build/soletta_sysroot/usr/lib//libsoletta.so: undefined reference tosol_worker_thread_new'

The definition:

#define SOL_PIN_MUX_DECLARE(_NAME, decl ...) \
    SOL_API const struct sol_pin_mux SOL_PIN_MUX = { .api_version = SOL_PIN_MUX_API_VERSION, decl }

Will never work in C++ since designated initialisers are not supported.

Please clarify the situation by either:

• making it an error to #include this file in C++ mode or making it an error to use SOL_PIN_MUX_DECLARE in C++ mode (such as defining it to static_assert(false, "This is not supported in C++))
• fixing the macro so that it works in C++

WRN:sol-pwm ./src/lib/io/sol-pwm-linux.c:214 _pwm_config() pwm #0,5: could not change polarity

is where it stops on the grove-led-accumulator.fbp sample.

Also, it seems that building for that board with networking enabled, seems to be crashing on the sol_init() -- I guess we should check the deps, if curl is being properly detected, etc.

We should provide Ubuntu package and a PPA.

Functions like sol_util_load_file_raw() and sol_util_fill_buffer()should be using sol_buffer instead of own buffer manipulation functions.

This also have nice side-effects like allowing sol_util_load_file_string() getting the sol_util_load_file_raw() buffer and being able to ensure the trailing \0 without the need of a `realloc()``

Also report on functions that would help this task, I already envision sol_buffer_trim() that calls sol_buffer_resize(buf, buf->used) that could be used at the string version before it returns. Maybe sol_buffer_steal(buf) to take buf->data and reset buf->used = 0; buf->capacity = 0;?

While building, if we provide a custom CFLAGS such as -march=i586 it will be used for both cross compiling and compilation of kbuild, that will make configure targets to fail.

Of course the same applies to LDFLAGS.

When you try to configure out-of-source, you get:

$ $srcdir/autogen.sh
python3: can't open file 'autogen.sh/data/oic/oicgen.py': [Errno 2] No such file or directory

Error was:

src/shared/sol-network-linux.c: In function ‘sol_network_link_up’:
src/shared/sol-network-linux.c:479:20: error: ‘IN6_ADDR_GEN_MODE_EUI64’ undeclared (first use in this function)
     uint8_t mode = IN6_ADDR_GEN_MODE_EUI64;
                    ^
src/shared/sol-network-linux.c:479:20: note: each undeclared identifier is reported only once for each function it appears in
src/shared/sol-network-linux.c:515:65: error: ‘IFLA_INET6_ADDR_GEN_MODE’ undeclared (first use in this function)
     ADD_RTATTR(addr_gen_container, RTA_LENGTH(sizeof(uint8_t)), IFLA_INET6_ADDR_GEN_MODE);
                                                                 ^
src/shared/sol-network-linux.c:508:27: note: in definition of macro ‘ADD_RTATTR’
         _attr->rta_type = _type;                                              \
                           ^

OpenSUSE 13.2 comes with kernel 3.16. This is the latest version.

SHA1: ece20c7

Error messages like the following:

'Couldn't resolve type 'test/result' of node 'test_compare_red_byte' '

are returned on the execution of the fbp tests located in soletta/src/test-fbp.

The complete list of error messages is listed in the link below:

http://pastebin.intel.com/view/46e6ddf4 are executed in a Galileoboard Gen2.

Thank you.

Currently we map "int" to "irange", "float" to "drange" and sometimes these are too-much. Take GPIO pins, for instance, we're interested in a single integer to represent that as the other 3 (min, max, step) are meaningless in such context.

Then we should introduce new mappings for "irange_spec"/"irange" and "drange_spec"/"drange" and use them where a range specification is needed (but not the value) or the whole set of members are needed (ie: constants).

The workaround for Linux Kernel version >= 3.18 proposed in /soletta/src/samples/flow/minnow-calamari/README doesn't set the GPIO pins properly.

Path to the fbp files: /soletta/src/samples/flow/minnow-calamari/

fpb files tested:

1. calamari-rgb-led.fbp
2. calamari-lever.fbp
3. calamari-led.fbp
4. calamari-buttons-rgb-led.fbp
5. calamari-7seg.fbp

Errors returned:

1. calamari-rgb-led.fbp:42:28 Couldn't resolve type name 'RGBLed'
2. calamari-lever.fbp:35:1 Couldn't resolve type name 'SegmentsLever'
3. calamari-led.fbp:36:1 Couldn't resolve type name 'LedLever'
4. calamari-buttons-rgb-led.fbp:38:1 Couldn't resolve type name 'Button1'
5. calamari-7seg.fbp:38:26 Couldn't resolve type name 'SevenSegments'

During the compilation this file ends up being included from two different places. I've found curious that during compilation we include headers from sysroot instead of staging / src.

      CC   build/stage/lib/flow/sol-flow-resolver.o
In file included from ./src/lib/flow/sol-flow-resolver.c:37:0:
./src/lib/flow/sol-flow-buildopts.h:44:40: warning: redundant redeclaration of ‘sol_flow_resolver_conffile’ [-Wredundant-decls]
 extern const struct sol_flow_resolver *sol_flow_resolver_conffile;
                                        ^
In file included from ./build/soletta_sysroot/usr/include/soletta/sol-flow.h:228:0,
                 from ./build/soletta_sysroot/usr/include/soletta/sol-flow-resolver.h:37,
                 from ./src/lib/flow/sol-flow-resolver.c:35:
./build/soletta_sysroot/usr/include/soletta/sol-flow-buildopts.h:44:40: note: previous declaration of ‘sol_flow_resolver_conffile’ was here
 extern const struct sol_flow_resolver *sol_flow_resolver_conffile;
                                        ^
      CC   build/stage/lib/flow/sol-flow-builder.o

We should provide RPM package for fedora. If possible make the binaries available at some existing repository such as rpmfusion.

Soletta sha1: 605718d

fbp tests contained in /src/samples/flow/unix-socket failed to run and returned the following type of output:

ERR:sol-flow-test ./src/modules/flow/test/result.c:74 fail() test/result node 'full_and_upper_are_equal_if_ignore_case' failed

A complete list of returned errors is below:

http://pastebin.com/pwJw5B9v

Thank you.

Soletta sha1: 605718d

fbp tests contained in /src/samples/flow/unix-socket failed to run and returned the following output:

WRN:sol-flow-unix-socket-impl ./src/modules/flow/unix-socket/unix-socket-impl.c:223 unix_socket_client_new() Could not connect: No such file or directory
WRN: ./src/modules/flow/unix-socket/unix-socket.c:364 byte_reader_open() mdata->un_socket== NULL
WRN:sol-flow ./src/lib/flow/sol-flow.c:137 sol_flow_node_init() failed to create node of type=0xb76a6620: Operation not permitted
WRN:sol-flow ./src/lib/flow/sol-flow-static.c:473 flow_node_open() failed to init node #0, type=0xb76a6620, opts=0x92f8c30: Operation not permitted
WRN:sol-flow ./src/lib/flow/sol-flow.c:137 sol_flow_node_init() failed to create node of type=0x92f8d40: Operation not permitted
ERR: ./src/bin/sol-fbp-runner/main.c:134 startup() Failed to run

The complete list of output error messages for is listed in the link below:

http://pastebin.com/f5vfCm57

Thank you.

sol-flow-static.c:flow_node_open() is always calling sol_flow_node_get_options() for each children options, this effectively allocates memory and copies the options, then need to call sol_flow_node_free_options() right after that -- already bad per se.

However, if the type doesn't specify new_options() callback, an empty_defaults is used. This is bad, since the original options was available and were not used.

I got to this when creating a type manually and not specifying the new_options() callback, as it's not required for my use case (simplectype -- to be sent as PR soon).

I'm not changing this as it's not clear to me why options needed to be duplicated at all. Even in the case of a builder, where you create new options from a textual description, those should be stored in the builder-generated type itself when such type is created.

I also see but do not understand the purpose of child_opts_set() callback that is called per-instance of flow, but stores the information per-type (class). It looks wrong, it should be pushing that information to node and should only be used if we're getting an option on a parent flow/node that should be redirected to a children node -- not my case, where I have no exported options in my parent.

To support exporting options, that will result in options being sent/propagated to children, I believe that the most efficient and clear way is making exported options a separate vector we have as options for static flows (ie: struct sol_flow_static_node_options) that we iterate in a way similar to what we do for ports:

sol-flow-static.h defines

struct sol_flow_static_node_options {
   const struct sol_flow_node_options base;
#define SOL_FLOW_STATIC_NODE_OPTIONS_API_VERSION 1
  const struct sol_flow_node_options {
     uint16_t node;
     const struct sol_flow_node_options *opts;
  } children_options;
};

struct sol_flow_static_option_spec {
   uint16_t node;
   /* some stuff to define how to export, like members or the whole struct
   * using whole struct here, so only taking the node index.
   * we could take the member index within the options description.
   */   
};

sol-flow-static.c uses

struct sol_flow_node_options *
get_exported_options(const struct flow_static_type *type, uint16_t node_idx, struct sol_flow_static_node_options *flow_opts) {
   if (type->exported_options && flow_opts && flow_opts->children_options) {
      uint16_t i;
      /* ensure node option is exported */
      for (i = 0; type->exported_options[i]->node != UINT16_MAX; i++) {
          if (type->exported_options[i]->node == node_idx) {
             uint16_t j;
             for (j = 0; flow_opts->children_options[j].node != UINT16_MAX; i++) {
                if (flow_opts->children_options[j].node == node_idx)
                   return flow_opts->childre_options[j].opts;
          }
      }
   }
   return NULL;
}

flow_node_open(...) {
   for (spec = type->node_specs, i = 0; spec->type != NULL; spec++, i++) {
       struct sol_flow_node *child_node = fsd->nodes[i];
       const struct sol_flow_node_options *def_child_opts = spec->opts;
       const struct sol_flow_node_options *exported_child_opts = get_exported_options(type, i, flow_opts);
       const struct sol_flow_node_options *child_opts = exported_child_opts || def_child_opts;
       /* this way, if exported_child_opts is something we allocate, we could free it later
        * by checking exported_child_opts.
        * it would be the case if we want to export not the full set of options from a child node,
        * but only parts of it. Like exposing the GPIO pin, but not the edge_mode.
        */
       r = sol_flow_node_init(child_node, node, spec->name, spec->type, child_opts);
   }
}

application (ie: lowlevel.c)

struct sol_flow_static_node_spec nodes[] = {
   {SOL_FLOW_NODE_TYPE_GPIO_READER, "reader", &def_gpio_reader_opts.base},
   {SOL_FLOW_NODE_TYPE_GPIO_WRITER, "writer", &def_gpio_writer_opts.base},
   SOL_FLOW_STATIC_NODE_SPEC_GUARD
};

struct sol_flow_static_conn_spec conns[] = {
    { 0 /* reader */, 0, 1/* writer */, 0},
    SOL_FLOW_STATIC_CONN_SPEC_GUARD
};

struct sol_flow_static_option_spec options[] = {
   {0, /* other spec would come here */},
   {1, /* other spec would come here */},
   SOL_FLOW_STATIC_OPTION_SPEC_GUARD
};

struct sol_flow_static_spec spec = {
   ...
   .nodes = nodes,
   .conns = conns,
   .exported_options = options,
   ...
};

type = sol_flow_static_new_type(&spec);

struct sol_flow_static_node_options myflow_opts = {
   .base = {
      .api_version = ..., .sub_api = SOL_FLOW_STATIC_NODE_OPTIONS_API_VERSION,
   },
  .children_options = {
     {0, &gpio_reader_opts.base},
     {1, &gpio_writer_opts.base},
     {UINT16_MAX, NULL}
  }
};
flow = sol_flow_node_new(parent, type, &myflow_opts.base);

I'm assigning this to @ibriano as I remember he did the exported options, but maybe @cmarcelo may take a look.

Would you like to add the configuration script "AX_PTHREAD" to your build specification?

Confusing error message.

FBP files that have nodes containing unexpected metadata cause the Soletta fbp runner to fail with a misleading error message. For example, nodes contain metadata defining a label :

node9(constant/string:label=node9) OUT -> IN node10(console:label=node10)

Causes the runner to output :

...:1:1 Couldn't resolve type name 'constant/string'

which makes me think there is something wrong with the type name, but that's not the problem at all. The actual problem is the runner doesn't accept the 'label=' metadata.

Please consider changing the error message to something more representative of the actual error, eg:

Error parsing node: node9 - unexpected metadata 'label'

Unexpected metadata

FBP files containing unexpected metadata also cause the fbp runner to fail. Please consider changing this behaviour so that users can embed information that is useful for purposes that haven't been considered. Specifically, allowing label="node9" should be allowed, but a better solution would be to simply ignore metadata that is unexpected, else you'd be forcing developers of other tools to maintain input and output processors to make it so the file is acceptable as input to Soletta.

Thanks.

Error messages like the following:

'Couldn't resolve type 'test/result' of node 'test_compare_red_byte' '

are returned on the execution of the fbp tests located in soletta/src/test-fbp.

The complete list of error messages is listed in the link below:

http://pastebin.intel.com/view/46e6ddf4 are executed in a Galileoboard Gen2.

Thank you.

We should use newly introduced sol_bufferAPIs to manipulate growing buffers used in our string nodes.

See dorileo@d556d82#commitcomment-11894119

sha1:c63851b3d79dd89cf421874fc826494b1e886618

fbp tests contained in soletta/src/test-fbp failed to run and returned the following type of output:

'Couldn't resolve type name'

The complete list of error messages is listed in the link below:

http://pastebin.intel.com/view/6b4c1888

Thank you.

Would you like to add more error handling for return values from functions like the following?

• pthread_mutex_unlock ⇒ sol_worker_thread_unlock
• strdup ⇒ runner_new

Implement a kmod service for linux-micro, it should follow systemd's modules-load.d(5) specification and use libkmod to do the actual work. The existing module sysctl loads in a similar fashion and should be used as base. Locations:

       /etc/modules-load.d/*.conf
       /run/modules-load.d/*.conf
       /usr/lib/modules-load.d/*.conf

It would be nice to listen for netlink messages saying new devices were added and use libkmod to check aliases (ie: load module for pci:v00008086d00000958sv*sd*bc*sc*i* will load iosf_mbi)

soletta sha1: 69f00c9
Plattform: Minnowboard

FAILED running /home/root/soletta/src/test-fbp/javascript.fbp

output returned:

Output:
WRN:sol-flow ./src/lib/flow/sol-flow-resolver-conffile.c:189 _resolver_conffile_get_module() failed to get rootdir for module test
bitwise-byte.fbp:43:32 Couldn't resolve type 'test/result' of node 'test_byte_bitwise_and'

Thank you.

We should have a standard lookup paths to load configuration files from, such as the name of the current application (binary or the FBP name if using sol-fbp-runner or sol-fbp-generator), as well as use the board name as in sol_platform_get_board_name().

An idea is the following (from highest to lowest priority):

• envvar $SOL_FLOW_MODULE_RESOLVER_CONFFILE
• ./sol-flow-$APPNAME-$BOARD_NAME.json
• $PKGSYSCONFDIR/sol-flow-$APPNAME-$BOARD_NAME.json
• ./sol-flow-$APPNAME.json
• $PKGSYSCONFDIR/sol-flow-$APPNAME.json
• ./sol-flow.json
• $PKGSYSCONFDIR/sol-flow.json

Please add proper SOL_DBG() before trying to load each component so it's easy to debug which file is being used and those that failed (didn't exist or failed to load).

c63851b

We should provide OpenSuse package and repository.

fbp tests contained in soletta/src/test-fbp failed to run and returned the following type of output:

'Couldn't resolve type name'

The complete list of error messages is listed in the link below:

http://pastebin.intel.com/view/6b4c1888

Thank you.

After the move to kbuild we don't have any warning enabled anymore

We should provide example for the most common http request (client) usages. Please base the examples on those available for other technologies, trying to be as simple as possible in comparison.

Suggested references:

• https://docs.python.org/3/library/urllib.request.html#module-urllib.request
• http://requests.readthedocs.org/en/latest/
• https://nodejs.org/api/http.html

Please document the src/lib/comms/include/sol-http-client.h using doxygen and take care to add examples snippets in the sol_http_client_request doc. Add a wiki page with walk through, these may include snippets from the actual sources in the tree.