Create common accessors

[cxbrooks]

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#16
From: @cxbrooks
Reported version: unspecified
CC: [email protected]

[cxbrooks]

Edward wrote:

I think it might be better to not have the subdirectories...
I'm hoping there will be a small number of these...

On May 19, 2017, at 4:13 PM, Christopher Brooks <cxh@ eecs.berkeley.edu> wrote:

Ok, https://www.icyphy.org/accessors/wiki/Main/ToDoList#AccessorManagement now says:

Create subpalettes in Accessors/util that match the Ptolemy II Actors:

Utilities
    Sources
        Spontaneous Sources
            Clock: Generate a periodic output. Make this simpler than the DiscreteClock actor: Two parameters: period and value. (Was: TestSpontaneous)
            SingleEvent (Was: TestSpontaneousOnce)
        Triggered Sources
            Counter: Each time an input arrives, produce an output that is a count of the inputs so far. Simpler than Ramp...
    Sinks
        Display: This should figure out how to best display the input based on the data type. It should pretty print JSON. The CapeCode implementation should pop up a display window.
    Discrete Event
        Merge: Merge some number of input streams into one input stream.

How does the above look?

There would be corresponding directories in accessors/web/utilities.

_C

On 5/19/17 3:32 PM, Edward A. Lee wrote:

How about Utilities?

Edward

On 5/19/17 3:24 PM, Christopher Brooks wrote:

I agree that we need these accessors.

Where should we put them and the other generic non-service/non-thing
accessors?

I outlined a few choices in my original message.

_C

On 5/19/17 3:20 PM, Edward A. Lee wrote:

Yes, I suggest the following:

Clock: Generate a periodic output. I would make this simpler than the
DiscreteClock actor: Two parameters: period and value.

Display: This should figure out how to best display the input based on
the data type. It should pretty print JSON. The CapeCode implementation
should pop up a display window.

Merge: Merge some number of input streams into one input stream.

Counter: Each time an input arrives, produce an output that is a count
of the inputs so far. Simpler than Ramp...

Edward

On 5/19/17 3:11 PM, Christopher Brooks wrote:

Edward,

I think we need a library of common accessors.

The primary reason is to help people get over the blank page problem and
requiring that they implement simple accessors right away.

A second reason is for maintainability. If we have multiple composite
accessors that have individual versions of a common accessor and that
common accessor has a bug, then we have to update the accessors by
hand. For the record, I found 13 copies of the JavaScriptRamp accessor
and 8 copies of JavaScriptTrueToken (which is probably like Const).

Also, it makes it easier for people to browse to the correct accessor.

There are a number of accessors in web/test that should be moved:
TestDisplay, TestSpontaneous, TestSpontaneousOnce, TrainableTest. There
might be others.

I'm part way through an implementation of DiscreteClock that should also
be used.

Are you on board with this?

If so, then we should discuss the structure.

If possible, we should mirror the actor palette for actors in Cape
Code. This means that we would have a more maintainable and scalable
layout. Putting all these accessors in one location like web/util/ will
not scale, though we could have subpalettes under web/util.

The simple accessors could either go in palettes located under
"Accessors", which would give us

*Actors

• Accessors
  ** Sources
  ** Spontanous Sources
  *** Discrete Clock
  *** SingleEvent (BTW - this would be TestSpontaneousOnce)
  *** Spontaneous (not sure about this)
  ** Triggered Sources
  *** Ramp
  ** audio
  ** cameras

Or, we could add a category called ActorAccessors or
PtolemyActorAccessors or SimpleAccessors and put these under that
category.

Or, we could create subpalettes in Accessors -> utilities

What do you think?

_Christopher