New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

more robust module object dependency checking #126

Closed
achubaty opened this Issue Jan 13, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@achubaty
Contributor

achubaty commented Jan 13, 2015

need to be able to identify dependency conflicts in modules:

  1. object names
  2. object classes
  3. object content (e.g., checking values, ranges, etc.)

Provide a function that the user can use to specify module object dependencies. Upon simulation initialization, temporarily store this info for each module in the spades environment, then concatenate into a single dataframe (or similar) that will be stored inside the simList object (will require a new slot).

At a minimum, each module should present simInit with the following info for :

  1. module name;
  2. whether object is used an input or produced as output;
  3. dependency object name;
  4. dependency object class;
  5. spatial extent of the object (if applicable);
  6. spatial projection of the object (if appilcable);
  7. list of available "translator" modules available for this module.

If dependencies aren't met (i.e., there is a conflict in any of the above) produce an error. In the case of object name or class conflict, suggest using a "translator" module which may be available to convert data objects.

Object dependencies should be checked in the global environment AND the outputs of other modules that will be loaded in the simulation.

@achubaty achubaty self-assigned this Jan 13, 2015

@achubaty achubaty added this to the v0.5.0 milestone Jan 13, 2015

@achubaty achubaty changed the title from more robust module dependency checking (with #118) to more robust module object dependency checking (with #118) Jan 13, 2015

@achubaty achubaty changed the title from more robust module object dependency checking (with #118) to more robust module object dependency checking Jan 16, 2015

achubaty added a commit that referenced this issue Feb 5, 2015

started implementing dependency checks (#126)
* new `dependsObj` class
* new `dependsList` class

achubaty added a commit that referenced this issue Feb 5, 2015

revised dependency object (class) definitions
part of #125 & #126

- delineate module vs object properties/metadata
- need to convert s3 `person` class to S4 (*incomplete*)
@achubaty

This comment has been minimized.

Contributor

achubaty commented Mar 4, 2015

  • added version
  • made timestep a numeric instead of character

4b180b4

@achubaty achubaty modified the milestones: v0.6.0, v0.5.0 Mar 4, 2015

@achubaty

This comment has been minimized.

Contributor

achubaty commented Mar 4, 2015

This is being resolved in the module-deps branch (multiple commits). Unfortunately they haven't all been diligently cross-linked. Sorry.

some most recent: 5f6007c, 4b180b4, 3b1b0e7

achubaty added a commit that referenced this issue Mar 5, 2015

achubaty added a commit that referenced this issue Mar 5, 2015

progress(?) on #125 and #126
ISSUE: still grappling with environments

`source()` evaluates the code in the env given by `local`
- `local=TRUE` means parent frame

`eval()` evaluates the code in the given env but it’s not persistent???

achubaty added a commit that referenced this issue Mar 5, 2015

back to basics...
part of #125 and #126

- use two separate files for module metadata & code

    - `metadata.R` sourced to local env.
    - `moduleName.R` code sourced to `.GlobalEnv`

- update module template and sample modules to reflect this
- remove function `prevArgs` and reintegrate code in `.objectNames`
- separate dependency classes and methods into two R files

achubaty added a commit that referenced this issue Mar 18, 2015

passes `R CMD check`
* resolved in this branch: #117, #118, #125, #126
* updated `checkPath` and its test

* however, there are still a few notes to deal with

@achubaty achubaty closed this Mar 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment