[kepler-dev] [Bug 2344] New: - Duplicate Actors that read directories

[bugzilla-daemon@ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2344

           Summary: Duplicate Actors that read directories
           Product: Kepler
           Version: 1.0.0alpha7
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: actors
        AssignedTo: berkley at nceas.ucsb.edu
        ReportedBy: cxh at eecs.berkeley.edu
         QAContact: kepler-dev at ecoinformatics.org


Dan wrote:
> Does anyone out there know if there is a difference in the basic
> functionality of the DirectoryListing actor (author  Christopher
> Hylands, Edward A. Lee) and the FileArrayPrinter actor (author Wibke
> Sudholt). Both seem to do the same thing (extract file lists from a
> directory); the DirectoryListing actor seems more full featured (works
> with URLs). Does the FileArrayPrinter do anything the Directory Listing
> actors does not?

Ilkay then wrote:
>   AFAIK, they are the same in functionality. There might be some
>   differences between  the datatypes/structures they output, and it needs
>   to be consolidated.

Christopher wrote:
> Ptolemy II uses the DirectoryListing actor as part of the run all
> demos demo that runs in the display case.
>
> This demo is ptolemy/demo/RunDemos.xml
> The actor is used in ptolemy/demo/RunDemosInNewProcess.xml
> It is also used in ptolemy/actor/lib/io/demo/FilePortParamter.xml
> and ptolemy/actor/lib/test/auto/ExecRunDemos.xml
> and ptolemy/domains/sdf/test/auto/filePortParameter.xml
>
> I'm not particularly wedded to the DirectoryListing actor, we could
> modify it to better meet Kepler's needs and then either discard
> FileArrayPrinter or have it call DirectoryListing but not be listed in
> Kepler's ui.  I'd prefer to discard FileArrayPrinter and move on.
>
> It looks like FileArrayPrinter is used in the following models:
> /home/eecs/cxh/src/kepler/src/org/resurgence/moml/FileListSequencer.xml:
> <entity name="File Array Printer"
> class="org.resurgence.actor.FileArrayPrinter">
> /home/eecs/cxh/src/kepler/src/org/resurgence/moml/MoleculeSelector.xml:
> <entity name="File Array Printer"
> class="org.resurgence.actor.FileArrayPrinter">
>
> Perhaps the authors of these models could use DirectoryListing or
> else tell me how DirectoryListing should change?
>
> Seems like a bug should be filed for this one.  I'm tempted
> to take it, but I'm slightly over committed.

Wibke wrote:
> Sorry for not answering earlier, since I am the author.
>
> I assume DirectoryListing and FileArrayPrinter probably do similar things (I
> think I came across their similarity earlier), though I would need to test
> in detail. There were, however, some reasons I had for doing a "duplicate"
> here:
>
> * This was one of my very first actors in Kepler :-) and so I potentially
> overlooked the other one (I am a domain scientist by training).
>
> * In the workflows where FileArrayPrinter is used, actually I do not need
> the URL, but the path. The reason for this is that later there is a lot of
> command-line calls and processing. And I did not want to always do String
> processing before.
>
> * For the Resurgence workflows it is very important to be able to transform
> arrays into sequences of tokens and vice-versa. If that is possible with
> DirectoryListing, there is probably not much sense to keep FileArrayPrinter.
> However, I remember another discussion about a Resurgence actor (it might
> have been about file copying/writing or similar) where it actually turned
> out that two actors do something similarly, but not identically. The reason
> for this has been that I always have to make sure that the Resurgence actors
> work in very particular ways with sequences of tokens.
>
> Unfortunately, I am heavily loaded by a different project at the moment, so
> I will need a bit time to check this. But polishing the Resurgence work is
> anyhow somewhere on my personal to-do list ...


I propose that FileArrayPrinter not be available in the Kepler UI, but
that the source code remain in the tree so that these models can continue
to run.

If someone wants to modify DirectoryListing in a backward compatibile manner,
I'm all for it.