y-api-users — YAPI users mailing list

[Y-api-users] YAPI Installation

[lina g. <lin...@ya...>]

Hello

 i want to install yapi but i have some problems.
when i make , there are some error messages:
(
 cosynetwork.cc  -fPIC -DPIC -o .libs/cosynetwork.o
cosynetwork.cc: In function 'void handler1(void*)':
cosynetwork.cc:189: error: 'fatal_func' was not declared in this scope
cosynetwork.cc:190: error: 'clean_func' was not declared in this scope
cosynetwork.cc: In function 'void handler2(void*)':
cosynetwork.cc:202: error: 'zero0_func' was not declared in this scope
cosynetwork.cc:205: error: 'fatal_func' was not declared in this scope
cosynetwork.cc:206: error: 'clean_func' was not declared in this scope
cosynetwork.cc: In function 'void zero0_func(void*)':
cosynetwork.cc:231: error: 'zero1_func' was not declared in this scope
cosynetwork.cc:232: error: 'zero2_func' was not declared in this scope
make[4]: *** [cosynetwork.lo] Error 1
make[4]: Leaving directory `/home/dell/Desktop/Thesis/yapi-2.1.1/src/rte/cosy'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/dell/Desktop/Thesis/yapi-2.1.1/src/rte'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dell/Desktop/Thesis/yapi-2.1.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dell/Desktop/Thesis/yapi-2.1.1'
make: *** [all] Error 2
)

i tried 2 versions : yapi-2.1.1 , yapi-2.1.0 
i use opensuse 11.1 .

Thanks.
Lina


      

[Y-api-users] fork on Mercurial

[Pjotr K. <pet...@xs...>]

Dear YAPI people, 
 
Just to let you know, I've created a clone of YAPI SW on my project's
Mercurial repository. I've fixed some bugs that prevented compilation 
on recent Linux/gcc distributions, a.o. 
 
The software is availble via Mercurial (Hg) distributed version
control: 
 
http://sub-lime.sourceforge.net/hg/YAPI
http://sub-lime.sourceforge.net/hg/YAPI-apps

Regards, 
 
Pjotr Kourzanov

[Y-api-users] fork on Mercurial

[Pjotr K. <pet...@xs...>]

Dear PFSPD people, 
 
Just to let you know, I've created a clone of cpfspd & pv SW on my project's
Mercurial repository. I've fixed some bugs that prevented compilation on 
recent Linux/gcc distributions, a.o. 
 
The software is availble via Mercurial (Hg) distributed version
control: 

http://sub-lime.sourceforge.net/hg/cpfspd
http://sub-lime.sourceforge.net/hg/pv

Regards, 
 
Pjotr Kourzanov

[Y-api-users] YAPI 2.1.0 released

[Erwin de K. <erw...@ph...>]

Hi all,

We have just released YAPI 2.1.0 with applications. 
- New YAPI feature is multicast.
- License changed from GPL to LGPL.
- New applications are bytestream frontend and backend, video 
multiplexing, and JPEG decoding.

Here are the release notes:

New features:
* Multicast added. Fifos and input ports can be given as
  arguments to constructors multiple times. See Section
  2.2.4 of the YAPI user's manual.
* License changed from GPL to LGPL.

Applications:
* vya-1.4.0, video yapi data types and coding guidelines.
* util-1.1.0, parse options utilities taken from PFSPD
  tool set. Now LGPL.
* pc-1.1.0, producer-consumer example.
* bytestreamfebe-1.1.0, bytestream frontend and backend.
* pfspdfebe-1.1.0, PFSPD frontend and backend. 
  - Split test environment into frontend and backend.
  - Communicate UVimageWidth and UVimageHeight in RGB mode.
* scaling-1.1.0, 2D video scaling.
  - Upgrade to pfspdfebe-1.1.0. 
* videomux-1.0.0, combining of video streams based on
  image positions and depths.
* jpegdec-1.0.0, JPEG decoding. 
  - Test example includes scaling for sample rate
    conversion to 4:4:4 and color space conversion from
    YCbCr to RGB.

Best regards,
--Erwin

[Y-api-users] YAPI license change

[Erwin de K. <erw...@ph...>]

Dear all,

We decided to change the license for YAPI from GPL to LGPL. This allows 
you to link proprietary applications to the YAPI library, i.e., you do not 
have to make your YAPI applications available under GPL. You can chose 
your own license model.

With respect to my last mail on select en multicast, we did not receive 
any feedback. So we will leave the select operations on multicast output 
ports as they are now. We plan to release this version soon, together with 
modified and additional applications.

Best regards,
--Erwin

[Y-api-users] Multicast support

[Erwin de K. <erw...@ph...>]

Hi all,

I am implementing multicast support for YAPI (yes, finally!). The idea is 
that you can connect a fifo or a input port of a process network to 
multiple consumers. For example:

fifo(     id("fifo")),
producer( id("producer"),  fifo),
consumer0(id("consumer0"), fifo),
consumer1(id("consumer1"), fifo)

The data that the producer writes to the fifo will be delivered to all 
consumers, i.e., all data is seen by all consumers independent of the 
order in which they read.

There are many ways to implement this. For the time being I choose to 
implement with a separate buffer for each consumer, i.e., each consumer 
has its own buffer and separate synchronization with the producer. The 
producer copies its data into each of the buffers. Here is an example of 
the workload table:

Communication Workload:
-------------------------------------------------------------
|           size Tsize Wtokens Wcalls T/W Rtokens Rcalls T/R|
|pc.fifo[0]  128     4    1001   1001   1    1001   1001   1|
|pc.fifo[1]  128     4    1001   1001   1    1001   1001   1|
-------------------------------------------------------------

Each output-input pair behaves as a separate fifo.

Now the question is how a select operation on an output port with multiple 
consumers should behave: OR- or AND-semantics? OR-semantics means that the 
output port can be selected if one of the consumers request enough data. 
AND-semantics means that the output port can be selected if and only if 
all consumers request enough data.

Reasons for OR or against AND are:
If you would replace the single output port with multiple output ports and 
create point-to-point connections again, the semantics of a select 
operation on these outport ports would be OR.
If you would connect an additional consumer, AND-semantics would 
potentially influence the behavior of the original producer-consumer pairs 
in the sense that the producer would send data only if an additional 
condition is satisfied (which may happen later or not at all). This seems 
bad for compositionality.

A reason for AND or against OR is:
The select operation on an output port is sometimes used to signal a 
commitment from its consumer to consume data. OR-semantics would not give 
this commitment from all consumers, so data that is never consumed could 
be left in the fifos.

My own opinion is that the semantics should be OR. This is based on the 
compositionality argument. With respect to the argument for AND, I think 
that the select operation on output ports should not be interpreted as a 
commitment from consumers but as a request for an amount of data from 
consumers. I think the select operation is typically used for reactive 
programming rather than for ensuring that data is not left in fifos (which 
is not guaranteed with write/read operations anyway). In this respect, I 
think OR is a better choice.

I implemented OR-semantics. It is available in the cvs reposity (cvs 
module yapi, cvs tag OR-select). The test example tst/multisel is an 
example of select on output with multicast. Feel free to play with it.

Before we release anything, I would like to know if you have strong 
opinions for AND-semantics or against OR-semantics. Please let me know.

Best regards,
--Erwin

[Y-api-users] Re: YAPI available as open source

[Edward A. L. <ea...@ee...>]

It might be interesting to this group to know that a Java open-source
implementation of Kahn process networks, extended, as in Yapi, with
NondeterministicMerge, is available in Ptolemy II, found
at http://ptolemyII.org

This implementation has a visual interface that may be used to construct
models, and it implements Parks' algorithm for bounded memory scheduling.

Edward Lee
UC Berkeley

At 11:07 AM 1/5/2006 +0100, Erwin de Kock wrote:

>Dear colleagues,
>
>First of all we would like to wish you a happy new year and the best 
>wishes for 2006!
>
>Furthermore, we are happy to announce that YAPI is available as open 
>source at https://sourceforge.net/projects/y-api. YAPI is C++ library for 
>writing (Kahn) Process Networks. Although we are still setting up the 
>site, you can download YAPI 2.0.0, the first open source version, already. 
>In addition, some example applications are available including a PFSPD 
>frontend and backend (Philips File Standard for Pictoral Data). You can 
>download the PFSPD tool set at https://sourceforge.net/projects/pfspd.
>
>If you are interested in using YAPI you may want to subscribe to our 
>mailinglist y-a...@li... through 
>http://lists.sourceforge.net/lists/listinfo/y-api-users. We hope that you 
>consider making your applications available to others. If so, please let 
>us know. We would be happy to maintain links to YAPI applications on our site.
>
>A YAPI-aware C++ parser and source code analysis and transformation 
>environment will soon be available at http://sourceforge.net/projects/scate/.
>
>Best regards,
>Gerben Essink,
>Erwin de Kock
>
>--------------------------------------------------------------
>Erwin de Kock
>Philips Research             Office WDC2-052
>High Tech Campus 31          Phone +31 40 2744372
>5656 AE Eindhoven            Fax +31 40 2744639
>The Netherlands              E-mail: Erw...@ph...

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
ea...@ee..., http://ptolemy.eecs.berkeley.edu/~eal  

[Y-api-users] YAPI available as open source

[Erwin de K. <erw...@ph...>]

Dear colleagues,

First of all we would like to wish you a happy new year and the best 
wishes for 2006!

Furthermore, we are happy to announce that YAPI is available as open 
source at https://sourceforge.net/projects/y-api. YAPI is C++ library for 
writing (Kahn) Process Networks. Although we are still setting up the 
site, you can download YAPI 2.0.0, the first open source version, already. 
In addition, some example applications are available including a PFSPD 
frontend and backend (Philips File Standard for Pictoral Data). You can 
download the PFSPD tool set at https://sourceforge.net/projects/pfspd.

If you are interested in using YAPI you may want to subscribe to our 
mailinglist y-a...@li... through 
http://lists.sourceforge.net/lists/listinfo/y-api-users. We hope that you 
consider making your applications available to others. If so, please let 
us know. We would be happy to maintain links to YAPI applications on our 
site.

A YAPI-aware C++ parser and source code analysis and transformation 
environment will soon be available at 
http://sourceforge.net/projects/scate/.

Best regards,
Gerben Essink,
Erwin de Kock

--------------------------------------------------------------
Erwin de Kock
Philips Research             Office WDC2-052
High Tech Campus 31          Phone +31 40 2744372
5656 AE Eindhoven            Fax +31 40 2744639
The Netherlands              E-mail: Erw...@ph...