moiri / streamix-c Goto Github PK
View Code? Open in Web Editor NEWcompiler for Streamix
License: GNU General Public License v2.0
compiler for Streamix
License: GNU General Public License v2.0
The connection priority in wrappers seems to be messed up:
Wrapper connections seem to outweigh net connections which should not be the case.
Example:
wrapper PlSrc( in trigger_pl, out data_pl(gaze), out data_db(gaze) ) {
Pl = extern box smx_src_rand( decoupled in trigger_pl( trigger ), out gaze(data), out events open )
Sleep = extern box smx_prc_worker( left in gaze(data), right out gaze(data) )
connect Pl.Sleep
} net( left out events, left in trigger_pl, right out gaze )
Pl.gaze
connects to the wrapper instead of Sleep.gaze
.
In order to control a Streamix network, signals need to be potentially broadcast to multiple nets.
Are side-port sufficient to achieve this?
The following example should produce a warning instead of an error:
A = box a(out bypass)
B = box b(out x)
C = box c(in x, in bypass)
connect A:B:C
To fix the warning use an abstract net instead of a composed net:
A = box a(out bypass)
B = box b(out x)
C = box c(in x, in bypass)
N = B:C
connect A.N
If multiple network expressions are used in one wrapper or in the root (scope 0), for each network expression a graph is created.
However, those multiple graphs should be combined on one page in one block.
Check that the identifiers in a connect instruction are unique.
Do it with the symbol table in a new scope of the connect instruction?
add the instance id to the wrapper name in the detailed box
when it comes to the connection check of side ports, we are facing the issue that the instance table uses the instance id as key but this id is not known in the connect node of the AST. There are to possibilities to solve this problem:
Considering the fact that also the key of the symbol table should be changed to the tuple <name, scope>, solution 2 seems more appealing.
-> done: an instance is now keyed by the tuple <name,scope>. The id is used only later to identify multiple instances in one scope (3c38149, b29aa1d).
To check the side port connections, a synchronizer should be added to the instance table, holding the following information:
-> done: however, without the connection information as synchronizers are split up into two parts and created individually for each net depending on the connections to one specific port (ecc8ce8)
A valid connection between two open ports produce an error.
As the programmer explicitly stated that the ports are open this should be accepted and no error should be generated. of course, no connection must take place.
When declaring a wrapper which connects a box with open ports, the open port still needs to be declared in the net prototype of the wrapper. This should not be the case.
Example
wrapper OtSrc( in trigger_ot, out data_ot(head), out data_db(head) ) {
Ot = extern box smx_src_rand( decoupled in trigger_ot( trigger ), out head( data ), out events open )
Sleep = extern box smx_prc_worker( left in head(data), right out head(data) )
connect Ot.Sleep
} net( left out events, left in trigger_ot, right out head )
following configuration (serial2)
box A(out a) on fa
box B(in a) on fb
A.B.A
automatically duplicates port a of instance B and crates a copy synchronizer that is connected wrong.
With box B(up down in a) on fb
no problem occurs (serial3).
The synchronizer is certainly a bug and probably also the automatic duplication but this has to be seen:
Should an omitting of the collections in box B produce an error or a warning and should the port duplication happen automatically (ambiguity check)?
In order to allow a profiler to be connected to every net in a Streamix network a new keywork must be introduced:
The syntax profiler.<custom>
should achieve this. The keyword profiler
serves as an instantiation of a special routing node which connects to all profiler ports of all nets. <costom>
can be an instance of any box implementation which takes the profiler data as input.
A wrapper such as the following produces a segfault:
wrapper Db( left in data, right out data ) {
DbInt = extern box smx_snk_mongo( in data )
connect DbInt
} net( left in data )
The following function returns NULL
. vp_net
is never checked and assumed to be non-null.
vp_net = virt_port_get_equivalent_by_symb_attr( v_net_i, sp_src );
In Streamix side ports play a not well defined role. They provide the possibility to broadcast signals which is a good idea. But it is very annoying to use them as every side-port has to be explicitly forwarded through a wrapper (not through nets, which is good).
A new view of using side-ports could be to see them as a bus
. A bus would be declared in a scope, e.g
bus my_awesome_bus
Which would allow to connect each net to this bus, provided the net as access to the scope the bus is defined in.
Connecting to a bus would happen through side-ports. I.e side-ports would no longer represent a collection (like up and down) but be a separate thing used to connect to a bus.
Separating side-ports in such a manner from normal streams would allow the RTS to use a completely different approach to implement data distribution over a bus:
the placement of the nodes should be strict, depending on whether nodes are grouped with a parallel or a serial combination.
To achieve this the property rank=same has to be used as well as invisible connections tying parallel groupings together.
As the title says. This refers to https://github.com/moiri/streamix-c/releases/tag/v0.1.0
The code
A = box a(out x)
B = box b(in x, in y)
C = box c(out y)
N = A.B
connect (N|N).C
fails with
bug.smx: 0: error: single mode in routing node 'smx_rn'(0)
bug.smx: 5: error: port 'y' in 'B'(3) is not connected
bug.smx: 5: error: port 'y' in 'B'(5) is not connected
Error count: 3
The following code, however, does not fail:
A = box a(out x)
B = box b(in x, in y)
C = box c(out y)
connect (A.B|A.B).C
box box_name( in merge(merge1 merge2), out split1(split), out split2(split))
Unlike with the keyword 'connect' where ports are only in the side port collection, the instruction 'link' can connect to all ports, independent of their collection. Hence, a link connection from the wrapper to a net instance can match with multiple ports.
Atm the function 'connection_check_port_id_get' returns the first hit and does no search for further hits.
when checking the context of a port with the function symrec_get, the collection is not taken into account.
I propose to introduce a separate symbol table for ports and nets respectively and choose keys accordingly (1).
Alternatively, the symrec_get has to distinguish between port and net (2).
Considering that there is already the functionality to distinguish between attributes of records I feel it is easier to follow path (2). Currently the attribute type is propagated through the functions but not used. We can easily use this to distinguish between ports and nets.
In the example such as
A = box a( out y[10] )
B = box b( in y )
connect tt[1ms](A).B
due to the tt
operator, the channel length of y is reduced to 1.
This should produce a warning to make the programmer aware of this.
the code
wrapper Src(out data(data_src, events_src), out events(events_src)) {
Src = box src(out data_src(data), out events_src(events))
connect Src
} net(right out data_src, right out events_src)
Snk1 = box snk1(in data)
Snk2 = box snk1(in events)
connect Src.(Snk1|Snk2)
but it should produce two routing nodes, one combining data_src
and events_src
and sending them to Snk1
and one duplicating events_src
and sending one to Snk2
and one to the other routing node.
The following program
A = box a( out x, out y open )
B = box b( in x, in y open )
connect A.B
produces the errors
open.smx: 4: error: cannot connect open port 'y' in 'B'(1)
open.smx: 4: error: cannot connect open port 'y' in 'A'(0)
However, open ports should be ignored when establishing a connection and thus, no error should be produced.
box A( out p ) on fa
box B( up down in p ) on fb
A.B.A
returns the error "error: no port connection in serial combinition 'B(xx).A(xx)'"
What happens here is the following:
There are two possible solutions for this:
When writing something like
net A {}{
box A() on fa
}
it seems that the scope is messed up and the ports of box A are also checked in net A
Side ports should be decoupled at the output of the routing node, not at the output of the net.
This way only the slow net is loosing data and not every net connected to the side port.
Due to some changes, the AST is now displayed vertically instead of horizontally
There is currently no way to specify channel length or output decoupling on wrapper input ports which spawn routing nodes.
In the following example it is not possible to decouple the output ports trigger1
and trigger2
of the routing node.
wrapper GUsbAmp(
in trigger(trigger1, trigger2),
) {
Box1 = box box1(in trigger1)
Box2 = box box1(in trigger2)
connect Box1 | Box2
} net(
left in trigger
)
In the above example the channel length could be specified in the box signature but this is no longer possible with nested wrappers.
There should be a syntax which allows to address channels of implicit routing nodes (e.g. make change port renaming to fully fledged port specifications)
To avoid having to use the id as a reference it should be possible to rename a net instance. e.g:
A = box a(out x)
B = box b(in x)
connect A.(B{B1}|B{B2})
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.