screen_width, screen_height should be options or experimental attributes, not constants

[tjmahr]

Store these constants in supplemental yaml files. Have Session(...) or Task(...) take a specs parameter which can point to a yaml path or a list enumerating these constants. The default values will use the specs for 27 inch Tobii XL60.

[tjmahr]

Here's how a YAML control file might look for the Coartic experiment in "tests/testthat/data/Coartic_WFFArea_2a/001P00XS1/"

---
Task: "Coartic"

Display:
  type: "Tobii60XL"
  frames_per_sec: 60.0
  screen_width: 1920
  screen_height: 1200
  pixels_per_mm: 3.71

AOIs:
  ImageL:
    x_pix: [100, 700]
    y_pix: [300, 900]
    # Name of stimdata column with image filename
    stim_name: "ImageL"
  ImageR:
    x_pix: [1220, 1820]
    y_pix: [300, 900]
    stim_name: "ImageR"

# Names of the stimdata columns that say where each image is
Locations:
  # i.e., the TargetImage column says whether Target is in ImageL or ImageR.
  Target: "TargetImage"
  Distractor: "DistractorImage"
...

Which R would parse as:

> str(yaml.load_file("tests/testthat/data/Coartic_WFFArea_2a/001P00XS1/Coartic.yaml"))
List of 4
 $ Task     : chr "Coartic"
 $ Display  :List of 5
  ..$ type          : chr "Tobii60XL"
  ..$ frames_per_sec: num 60
  ..$ screen_width  : int 1920
  ..$ screen_height : int 1200
  ..$ pixels_per_mm : num 3.71
 $ AOIs     :List of 2
  ..$ ImageL:List of 3
  .. ..$ x_pix    : int [1:2] 100 700
  .. ..$ y_pix    : int [1:2] 300 900
  .. ..$ stim_name: chr "ImageL"
  ..$ ImageR:List of 3
  .. ..$ x_pix    : int [1:2] 1220 1820
  .. ..$ y_pix    : int [1:2] 300 900
  .. ..$ stim_name: chr "ImageR"
 $ Locations:List of 2
  ..$ Target    : chr "TargetImage"
  ..$ Distractor: chr "DistractorImage"

[tjmahr]

Actually... rename screen_width to width_pix so that the unit is part of the key-name?

[tjmahr]

Note that in the example R code, the filename is the generic Coartic.yaml. I'm thinking that the file loading function will look for yaml files that are sub-strings of other experiment files. So Coartic dot yaml would be loaded alongside any stimdata or gazedata files that Coartic in their name. This will let us write very generic files to store these constants for a single experiment.

Also, why yaml? It supports comments. That's all.

[crcox]

I was actually asking myself that question "why yaml?" because I've been using json for this sort of thing. Allowing comments is a big deal. This makes me want to learn more about yaml.

On Fri, Feb 27, 2015 at 8:48 AM, tj mahr notifications@github.com wrote:

Note that in the example R code, the filename is the generic Coartic.yaml. I'm thinking that the file loading function will look for yaml files that are sub-strings of other experiment files. So Coartic dot yaml would be loaded alongside any stimdata or gazedata files that Coartic in their name. This will let us write very generic files to store these constants for a single experiment.

Also, why yaml? It supports comments. That's all.

— Reply to this email directly or view it on GitHub https://github.com/tjmahr/lookr/issues/10#issuecomment-76405395.

[tjmahr]

Yeah, I've started using commented yaml files to hold constants, analysis parameters and other magic numbers for the scripts that I'm using for a paper. Plus, I think JSON has too much syntax for my collaborators.

[crcox]

I agree 100%. YAML is superior in this way and others. I just weaved it into a project under development where I ordinarily would have used JSON and I was rewarded immediately. It's won me over. Not that we should have this convo on your issue thread... but YAML rocks.

On Tue, Mar 3, 2015 at 4:05 PM, tj mahr notifications@github.com wrote:

Yeah, I've started using commented yaml files to hold constants, analysis parameters and other magic numbers for the scripts that I'm using for a paper. Plus, I think JSON has too much syntax for my collaborators.

— Reply to this email directly or view it on GitHub https://github.com/tjmahr/lookr/issues/10#issuecomment-77046659.

[tjmahr]

Nah, it's fine. My issue threads are notes-to-self.

FWIW, YAML is a superset of JSON. Which I think means that YAML parsers should read json files.

[crcox]

Woah... if that is true, that's pretty incredible. I could implement YAML compatibility across the board and maintain backward compatibility with my old config generation routines. I love it.

On Wed, Mar 4, 2015 at 9:02 AM, tj mahr notifications@github.com wrote:

Nah, it's fine. This issue threads are notes-to-self.

FWIW, YAML is a superset of JSON. Which I think means that YAML parser can read json files.

— Reply to this email directly or view it on GitHub https://github.com/tjmahr/lookr/issues/10#issuecomment-77173046.

[tjmahr]

Note that YAML 1.2 from 2009 is the superset. http://en.wikipedia.org/wiki/YAML#JSON

But I just tried an online validator. http://nodeca.github.io/js-yaml/ Plugged some JSON on the left and it parsed.

[tjmahr]

Also, I think I've come up with a philosophy. If a human is going to write the file, YAML is preferred. If a program is outputting the file for data interchange, and if I can't use a csv file, then JSON is preferred.

[crcox]

Sounds reasonable to me. Finicky syntax is great when computers are doing the reading and writing, and vice versa.

On Wed, Mar 4, 2015 at 9:23 AM, tj mahr notifications@github.com wrote:

Also, I think I've come up with a philosophy. If a human is going to write the file, YAML is preferred. It a program is outputting the file for data interchange, and if I can't use a csv file, then JSON is preferred.

— Reply to this email directly or view it on GitHub https://github.com/tjmahr/lookr/issues/10#issuecomment-77177201.

[tjmahr]

Nope. lookr is going into long-term maintenance mode. The next package can be more general.