Create common accessors

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

cxbrooks / test

Create common accessors #5