What versions of systemd and npm does the soletta-dev-app use?

[rraallvv]

When I try npm install systemd I get the following

WARN engine systemd@0.2.6: wanted: {"node":">=0.6.11 <0.11.0"} (current: {"node":"4.2.6","npm":"2.14.12"})
systemd@0.2.6 node_modules/systemd

Since it's a warning and not an error I tried ./install.sh but it says

Dependency not found: systemd

[brunobottazzini]

@rraallvv, The systemd should not be installed via npm and it usually comes with the Distro you are using.

What distro do you use ?

[rraallvv]

@brunobottazzini, My bad, I was mistakenly thinking that I could install systemd on OS X via npm.

No idea if it’s possible to use launchd instead though.

Closing this issue then, thanks for your reply, I really appreciate it.

[brunobottazzini]

@rraallvv, you can install manually Dev-App but you won't be able to run the FBP files you created using the Devapp's interface.

If you've got Soletta install you will be able to run it manually like: sol-fbp-runner FBP_PATH

I would advise you to do this becuase dev-app contains a good interface that helps newcomers to start using Soletta's Project.

If you've got any device such as Galileo, Edison, Minnow etc. You can also install devapp there and use it from your OS X in a Web-browser.

If this is your case see here

[barbieri]

Hi @rraallvv, there is no port of Soletta to MacOSX at the moment. We do have an initial attempt to get the posix interfaces generic enough so it would run there (still not merged), but that contains no specific MacOS bits, such as launchd.

I'm still unsure on how to prioritize this for Soletta given that MacOSX and iOS:

• don't allow any direct I/O manipulation, so things like GPIO, I2C... would not exist;
• MacOS provide nicely integrated ObjC/Swift apis for comms, so our would not add much (maybe just OIC?)

Then with our port, we could have the "FBP" and "C API" to work on MacOS allowing people to port existing applications to such system. This is like running Gtk and Qt applications on windows. A more interesting use, if all we have to add is OIC, is to create some "OICKit" in ObjC and provide it as an OSX Framework. It wouldn't expose Soletta at all, just allow access to OIC by using the embedded/hidden soletta underneath. At the end both cases are valid and interesting, the problem is how to prioritize them in order to better use our human resources.

As for DevApp, its main goal is to run the soletta applications on the device, so the first option above would make sense, however as said none of the I/O primitives would work.

Then it makes more sense for you to run the DevApp on a Linux board and access that from your MacOS browser.

[rraallvv]

@brunobottazzini, @barbieri, Thanks, lots of interesting stuff to read.

@brunobottazzini, I still need to digest some information but based on what you posted I’ll try a manual instalation. Also, since I don’t have any real device with me, I’m going to try getting an Ostro pre-built image running in QEMU, then I’ll try a cross-compilation with meta-soletta.

@barbieri, I don’t know yet the workflow when developing with Soletta so please correct me if I’m wrong, I’m picturing the whole thing for desktop FBP applications like programming with a desktop specific set of nodes available in the visual editor. In that case the nodes would map to a C API that in turn would use the native frameworks depending on the target platform, like for instance Cocoa for OS X or Cocoa Touch on iOS, I’m I right? Regarding the framework OICKit, I guess there would be some parts of the application that the developer need to expose to the embedded Soletta runtime so that they can be programed via OIC.

Again I don’t have the full picture on how to work with Soletta, what I’ve tried so far with FBP is NoFlo and Microflo via app.Flowhub.io, but theirs is a different approach, I think. They have different runtimes specific for each target platform, and bindings in the form of a library of nodes specific for the platform. They also have the option of different runtimes taking to each other, in principle, allowing an FBP program to run like a distributed application.

[barbieri]

Yes, you're right this is one use case: to write in FBP and run "everywhere [tm]". However, on the reality part of this, much of the IoT use cases wouldn't be covered on MacOS-X due no sensors access. Then what would be left are accessing comms (OIC, MQTT, HTTP...) from flow. Not sure how many people use want to use that, what are your plans about it? This is similar to what NoFlo/Microflo and the likes offer (we investigated them before doing Soletta).

As for OICKit, the idea is that it would not expose any of soletta, would behave like other frameworks, like MQTTKit that embeds libmosquitto but does not expose it, just a ObjC API. Then your native MacOS app would include that framework and use it alongside with Cocoa and the likes.

Still about NoFlo and other FBP, we have a series of extensions to FBP, so while concepts apply, the formats will not be compatible. For instance we allow node options with the syntax:

instance(nodetype:option1=value1)

While others opt to use initial packets. We also support the concept of "metatypes", that are ways to dynamically create a node type, be from another FBP (ie: modular), a JS file using duktape engine or even based on some parameters, such as composed packet split or http client/server with composed packets.

Also, given our goal to run smoothly on small OSes with constrained memory, we use fixed types in the ports, this changes what NoFlo offers since for them it's all about "JS objects".

For distributed systems, you can use the series of node types offering communication, like OIC or HTTP, see https://github.com/solettaproject/soletta/blob/master/doc/tutorials/ostro-oic-tutorial/step0/tutorial.md

[rraallvv]

@barbieri I’m planning to start developing games that run across multiple mobile platforms and also the web using visual programming tools. Currently there are no free open source tools available for that. The FBP runtime designed to run in embedded systems and the FBP editor built on top of web technologies might be the way to go. Since there is this game development environment, Cocos Creator, that I’ve been using. After making myself proficient with those tools I want to create a plug-in with the visual editor to program the runtime directly from the game editor and to wrap the game API in a library of nodes for FBP.

[barbieri]

wow! nice :-)