Project

General

Profile

Bug #2344

Duplicate Actors that read directories

Added by Christopher Brooks over 13 years ago. Updated about 13 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
actors
Target version:
Start date:
01/26/2006
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2344

Description

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.

History

#1 Updated by Dan Higgins about 13 years ago

This bug has been fixed by removing the FileArrayPrinter from the Kepler actor
tree, although the base java code has been left in the source (so that Wibke's
existing workflows will continue to execute)
Dan Higgins - March 22, 206

#2 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 2344

Also available in: Atom PDF