1. extract Component signatures
2. generate stub code
3. include code into program that binds components (intellisense enabled)
4. compile and run emitting XML or directly launching CoCo

We implement it in C++ but could be implemented with any typed language

Pros: faster editing, support for arguments
Cons: little slower

We could limit the Cons as follows:

1. let launcher support this file at command line with -x automatically compiling and executing and passing the correct includes
2. perform step 1 with some form of caching

Hi,

Hope you are all well !

I found your interesting repos as I am searching some project helping to build up an augmented/mixed reality pipeline POC using any web camera input (iOS,Android or Desktop) and to distribute requests

I wanted to create some kind of flow orchestration where u can pre-process x pictures per seconds (eg every 5 frames) and check if the picture is blurry or dark, and prevent them to be sent either to a local processes or remote micro-services for face detection, markerless tracking, wikipedia-search.

The key idea is to define some input validity checks fro the input, before doing some distributed requests. And to use a shared/efficient strategy for sharing the input with several respondents.

I think that creating such recursive tree of services, tagged by specific topologies of services/processes, would help to complete the visual semantic extraction.

eg: face detected: facial landmarks , eye detection, openface, face reconstruction checked in paralel every x frames or once for some processes

or

eg: planar marker detected: markerless tracking,  instance matching service, wikipedia search about the author checked in paralel every x frames or once 

** Distributed Detections on mobile devices:**

• Distributed pipelines, with nanomsg or libmill, for video multi-processing (to re-iterate the idea with those 2 libs: parallel slam+markerless+facial landmarks with performance optimizations like sharing the same input matrix from the webcam to request several recognition services with IPC, RPC or TCP protocols): https://github.com/daniel-j-h/DistributedSearch, https://daniel-j-h.github.io/post/distributed-search-nanomsg-bond/

• Image pre-processing pipeline: https://github.com/halide/Halide

• GPGPU Acceleration https://github.com/hunter-packages/ogles_gpgpu/tree/hunter.develop

• Cross-platform C++ Camera with Qt5 https://github.com/headupinclouds/gatherer

Goals:

• adds a visual discovery feature to wikipedia based on category or instance matching
• save energy on mobile devices, allow smart service requests by a cascade or pre-processing with a small memory-footprint/cost.

Have a good week !

Cheers,
Richard

This is a feature that is useful for SRG

1. the content of the tag is sent to the component via an operator (content) passing the name and the value in the XML tag.

2. allows to extend a previously defined component with content tags. Decide if we can replace attributes, probably yes

Export MD from the components during build, or embed in source, or something!

coco_launcher should support multiple -x occurrences and compose the resulting structure. This is in-line with the addition of .

• specify arguments on coco launcher
• (optional) declare arguments in the XML
• use arguments for: values, if/unless a-la ros launcher

Removing the need of the library => easier

• load all (slows down)
• pre-scan (boring only in dev)

• If port of src endswith OUT then use same name for IN
• otherwise just match the name

This would allow a Python/any command line editing of the system:

• new instance
• new activity
• new connection
• execute operations
• get/set attrib

1. define API
2. implement in web_server
3. make Python command line tool

Use pointers to variable members instead of dynamic ones.

Sketch in this gist: https://gist.github.com/eruffaldi/5070833dbf23f9f843b6859b266b7a4f

Leaves window open

CoCo and SRGViz use extensively mutexes and in particular we employ boost::shared_mutex (now in C++17) for supporting in particular lock upgrades. Unfortunately these mutexes are quite heavyweight as shown from tests online (https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/).

We should evaluate to introduce the use of RWLocks, available in pthread and also in modern Windows, to speed-up lock acquisition in core CoCo/SRGViz structures.

1. Find spots for improvements
2. Pick library providing lightweight mutexes
3. Replace!
4. Profile

A-la ROS

This will allow the tooling discussed in another Issue

Use package a-la catking for improved discovery of resources

1 - align to next pow2: useful for the little variable blocks of x264 compressors. Hint from user
2 - skip for smaller then size K: probably makes not necessary previous one
3 - per-task memory pool with lightweight deleter: the concept is that we want to reduce the cost of multithreaded allocation so we employ:
3.1 - per-task or per-activity pool (reasonable given the usage patterns)
3.2 - deletion can be lock-less

Simplify the generation of CoCo XML files using more default, more semantic structure and easy launch from Python:

• Compositing Scenes
• Classes wrapping CoCoMR blocks
• Virtual Pub/Sub, while waiting for Pub/Sub
• Launch CoCo or ROS CoCo

We'll recreate the demos

Add support for expressing a single file with multiple components/activities/connections blocks

Not issuing spinOnce

COCO_REGISTER_ALIAS(ImageSourceTask,image_source)

Under OSX only the main thread can create windows. This is solved with a sequential GLManager so far.