Issue when installing gazer on R 3.6.1 and macOS Catalina

[langestroop]

Hi,

first of all many thanks for having created gazer: I've had the chance to try it out in the past and it seemed to be a perfect package for most of the eye-tracking analyses that I'm planning to conduct.

The issue - I've just tried to install the latest version via devtools, but for some reason it gives me this error:

Installing package into ‘/Library/Frameworks/R.framework/Versions/3.6/Resources/library/00LOCK-gazer/00new’ (as ‘lib’ is unspecified) Error in contrib.url(repos, "source") : trying to use CRAN without setting a mirror Error: unable to load R code in package ‘gazer’ Execution halted ERROR: lazy loading failed for package ‘gazer’

• removing ‘/Library/Frameworks/R.framework/Versions/3.6/Resources/library/gazer’ Error: Failed to install 'gazer' from GitHub: (converted from warning) installation of package ‘/var/folders/jm/fh5_148d4rq87wx0lv3zmkgm0000gn/T//Rtmp6IWD6g/file18e61fd22770/gazer_0.1.tar.gz’ had non-zero exit status

What could be the reason? I'm running R 3.6.1 on macOS Catalina.

Many thanks for your time. Best,

Alberto

[SiyuCHEN1102]

Hi,

I had the same problem when I try to install "gazer" package and run it on R 3.6.0. (windows). It failed. And then I use my mac and try it on R 3.5.2 and it worked fine.

P.S. when you install the package, type devtools::install_github("dmirman-zz/gazer") instead of devtools::install_github("dmirman/gazer")

hope this helps :)

Siyu CHEN

[jgeller112]

Alberto — I have heard that Catalina has been causing many problems. I am not sure if this issue is related. Although I’m hesitant, I’ll install Catalina and see if I can replicate this issue.

[jgeller112]

Siyu CHEN is correct, please use

remotes::install_github("dmirman/gazer"), not dmirman-zz/gazer. 

[SiyuCHEN1102]

Thanks jgeller112, it seems that there is a typo in dmirman/gazer/inst/doc/fixation-vignette.R: the function "read_fixation_report" was written as "readFixationReport", which keeps giving error message that 'could not find function "readFixationReport"'. Although the code from dmirman/gazer/vignettes/ is correct (read_fixation_report). Maybe you want to fix that typo as it's really confusing.

thanks again :)

[jgeller112]

Siyu CHEN, thanks for letting me know!

[jgeller112]

@langestroop, the issue has been fixed! I have been updating gazeR as the request of reviewers so I might have broke some things. Please try installing again:

install_github("dmirman/gazer")

Please reach out if some of the functions in the paper do not work. I should have new paper up soon that explains new functions and arguments.

[langestroop]

@SiyuCHEN1102 thanks for the tips, they're really appreciated!

@jgeller112 many thanks for the solution! It works now: I've just managed to install gazer and I'm looking forward to the (second/updated) paper :)

I really like the new function _parseedf but momentarily I got this output/error:

Loading Events (1119 events across 1 trials).... Error in names(output$header) <- c("eyetrial", "starttime", "endtime", : 'names' attribute [4] must be the same length as the vector [1]

I suspect it might be due to the structure of my .edf file (there seem to be a clear error because of the header), but maybe you have a different intuition/solution

[jgeller112]

Is your EDF file straight from SR? I have tested a few EDF files from SR and they work fine. Can you send me your EDF file if problem persists?

Jason Geller, Ph.D. Postdoctoral Scholar The University of Iowa

---

From: Alberto notifications@github.com Sent: Sunday, November 3, 2019 9:52:58 AM To: dmirman-zz/gazer gazer@noreply.github.com Cc: Geller, Jason jason-geller@uiowa.edu; Mention mention@noreply.github.com Subject: [External] Re: [dmirman-zz/gazer] Issue when installing gazer on R 3.6.1 and macOS Catalina (#13)

@SiyuCHEN1102https://github.com/SiyuCHEN1102 thanks for the tips, they're really appreciated!

@jgeller112https://github.com/jgeller112 many thanks for the solution! It works now: I've just managed to install gazer and I'm looking forward to the (second/updated) paper :)

I really like the new function parse_edf but momentarily I got this output/error:

Loading Events (1119 events across 1 trials).... Error in names(output$header) <- c("eyetrial", "starttime", "endtime", : 'names' attribute [4] must be the same length as the vector [1]

I suspect it might be due to the structure of my .edf file (there seem to be a clear error because of the header), but maybe you have a different intuition/solution

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dmirman-zz/gazer/issues/13?email_source=notifications&email_token=AEMTQEAXMOBUDXLKSZNHE63QR3XVVA5CNFSM4JIKVXG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5WAPY#issuecomment-549150783, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEMTQEA2DO6SPSXBOLWOVPLQR3XVVANCNFSM4JIKVXGQ.

[jgeller112]

This concerns me:

Loading Events (1119 events across 1 trials)…

Why is it only loading one trial?

On Nov 3, 2019, at 9:52 AM, Alberto notifications@github.com<mailto:notifications@github.com> wrote:

@SiyuCHEN1102https://github.com/SiyuCHEN1102 thanks for the tips, they're really appreciated!

@jgeller112https://github.com/jgeller112 many thanks for the solution! It works now: I've just managed to install gazer and I'm looking forward to the (second/updated) paper :)

I really like the new function parse_edf but momentarily I got this output/error:

Loading Events (1119 events across 1 trials).... Error in names(output$header) <- c("eyetrial", "starttime", "endtime", : 'names' attribute [4] must be the same length as the vector [1]

I suspect it might be due to the structure of my .edf file (there seem to be a clear error because of the header), but maybe you have a different intuition/solution

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dmirman-zz/gazer/issues/13?email_source=notifications&email_token=AEMTQEAXMOBUDXLKSZNHE63QR3XVVA5CNFSM4JIKVXG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5WAPY#issuecomment-549150783, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEMTQEA2DO6SPSXBOLWOVPLQR3XVVANCNFSM4JIKVXGQ.

[langestroop]

@jgeller112 yes, it's straight from the SR system. I'm also concerned about that. I might have messed up some settings. Here's the file (.edf and also .asc):

et_300.zip

Many thanks for your time :)

[jgeller112]

@langestroop, looking into the file, there seems to be an issue with trial detection. It is only recognizing one trial. I think there might be an issue with the script or settings you used to denote the beginning and end of trials.

[langestroop]

Hi @jgeller112 ,

you're right, sorry about that. It was a stupid mistake: my markers were customized and they were not written with the proper EyeLink syntax (e.g. identifiers like TRIALID, TRIAL_VAR and so on..). I mean, data can still be analyzed since messages/markers with relative samples are stored, but of course they cannot be properly imported via _parseedf and gazer in general I assume.

I'm currently changing my experimental code to match the required EyeLink syntax, but I found another strange error in the parse_edf function.

Loading Events (660 events across 3 trials).... Loading Samples (19598 samples across 3 trials) ... Success! (19598 samples) Done with 33 Done processing all files! Error: object 'event' not found

What do you think? Crucially, this .edf file has been generated with one of the EyelinkToolbox/Psychtoolbox examples. I've attached the experimental code folder that also contains the problematic .edf.

EyelinkPicture.zip

[jgeller112]

I have had issues reading in EDF files from PTB in the past. What I would recommend is getting the Sample Report from SR DataViewer.

[jgeller112]

I read in the edf you zipped over and I was not able to replicate your issue.

[langestroop]

I read in the edf you zipped over and I was not able to replicate your issue.

Many thanks for the info: that's great! I think I've just solved the issue: it's related to the version of the saccades package. The one that I had installed and that R automatically calls when using your package is the CRAN version (2015) that apparently causes that issue, whereas the latest github version installed via devtools (2019) seems to work fine :)

This makes sense since the only time in which "event" is called in _parseedf it's when the function is filtering for blinks via the saccades package

[jgeller112]

In the forthcoming paper, I will make sure to tell folks to download the GitHub version of saccades.

I just pushed some changes to the parse_edf function. For some reason EDF messages record outside the sampling rate so I had to fix it so messages align with the sampling rate. Previously I used a stupid hack that wasn’t very eloquent. Please let me know if you have issues with new version.

Jason Geller, Ph.D. Postdoctoral Scholar Department of Psychological and Brain Sciences The University of Iowa

On Nov 5, 2019, at 6:41 PM, AlbertoI notifications@github.com wrote:



I read in the edf you zipped over and I was not able to replicate your issue.

Many thanks for the info: that's great! I think I've just solved the issue: it's related to the version of the saccades https://github.com/tmalsburg/saccades package. The one that I had installed and that R automatically calls when using your package is the CRAN version (2015) that apparently causes that issue, whereas the latest github version installed via devtools (2019) seems to work fine :)

This makes sense since the only time in which "event" is called in parse_edf it's when the function is filtering for blinks via the saccades package

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dmirman-zz/gazer/issues/13?email_source=notifications&email_token=AEMTQEBBNM7O3IQNYU4AQTLQSIHBZA5CNFSM4JIKVXG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDE27SY#issuecomment-550088651, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEMTQEBSKJNE4BFJKMLSG5LQSIHBZANCNFSM4JIKVXGQ.

[langestroop]

In the forthcoming paper, I will make sure to tell folks to download the GitHub version of saccades. I just pushed some changes to the _parseedf function. For some reason EDF messages record outside the sampling rate so I had to fix it so messages align with the sampling rate. Previously I used a stupid hack that wasn’t very eloquent. Please let me know if you have issues with new version.

Hi, .edf files are imported without issues with the new version :) However, I've noticed that parts of some messages are removed and/or omitted. I've attached two screenshots representing messages imported via itrackr and after having produced the .csv file with _parseedf to show you what I mean:

As you can see, special characters and numbers contained in some messages have been removed by parse_edf (e.g. post_LB_301 becomes postLB). Does it also happen to you?

I'm really sorry to bother you again. Many thanks for your time.

[jgeller112]

@langestroop I really appreciate you testing this function out!

In the parse_edf function I replace negative numbers in my data, but now I am rethinking that. You do not seem to have that problem, and my case is probably a special case.

I have pushed a change which should mirror the exact messages now. Please try it out. Please note that if you do rely on messages, messages need to be consistent across trials to use some of the gazeR functions.

[langestroop]

@langestroop I really appreciate you testing this function out!

In the parse_edf function I replace negative numbers in my data, but now I am rethinking that. You do not seem to have that problem, and my case is probably a special case.

I have pushed a change which should mirror the exact messages now. Please try it out. Please note that if you do rely on messages, messages need to be consistent across trials to use some of the gazeR functions.

Events are perfectly mirrored now, thanks :) Only two little things:

1. TRIALID 1 is deleted from messages whereas TRIALID 2 is retained
2. I think that the functions overwrites messages that are consistent and appear more than once ( for both points see screenshots comparison - itrackr vs gazer - as message above)

Also, a more general question: the dataframe that you're using in this vignette (https://rpubs.com/jgeller1/438015) is generated with SR Research Data Viewer right? If so, I was wondering whether _parseedf could be adapted to generate something similar without the need to pass trough Data Viewer, maybe by allowing to pass additional arguments to the function (?) I know that this might be hard especially because of each specific experiment's extra columns and respective identifiers (blocks, items etc.), however this would be super handy (e.g. automatically generate a column called block via _parseedf similarly to what happens for the trial one instead of having the entry "BLOCK_1" in the message coloumn). I'm asking this because I agree and fully support your preprocessing approach (and its theoretical references: Mathot and Kret & Sjak-Shie) so it would be really cool to be able to apply it right away by just importing data via _parseedf (therefore without the need to use Data Viewer).

As always, sorry for all these questions and many thanks for your time.

[jgeller112]

In order to get events of interest (block, condition, RT) as nice columns you will need to use the parse EDF message function to extract all the message files and then parse the necessary conditions from them. This will then have to be merged to the main sample report. It will be different for each experiment so I can’t really make a generic function. In the paper, I walk through my data and show how you can get all the necessary experimental variables you need for your experiment. This is really the only way you can do it.

As you can see, there are multiple messages occurring at the same time and those messages are not really that important. I only return distinctive time and messages. All the important messages are there.

From my understanding, TRIAL ID 1 doesn’t correspond to a valid trial. As long as the trial column is there, that’s all you need. There is some bug with raw EDF files and it labels trials oddly so please be cognizant of that.

Jason Geller, Ph.D. Postdoctoral Scholar Department of Psychological and Brain Sciences The University of Iowa

On Nov 7, 2019, at 10:02 AM, Alberto notifications@github.com wrote:



@langestroophttps://github.com/langestroop I really appreciate you testing this function out!

In the parse_edf function I replace negative numbers in my data, but now I am rethinking that. You do not seem to have that problem, and my case is probably a special case.

I have pushed a change which should mirror the exact messages now. Please try it out. Please note that if you do rely on messages, messages need to be consistent across trials to use some of the gazeR functions.

Events are perfectly mirrored now, thanks :) Only two little things:

1. TRIALID 1 is deleted from messages whereas TRIALID 2 is retained
2. I think that the functions overwrites messages that are consistent and appear more than once ( for both points see screenshots comparison - itrackr vs gazer - as message above)

[Screenshot 2019-11-07 at 15 30 42]https://user-images.githubusercontent.com/31136567/68402991-2366df80-0174-11ea-9b80-e013a756abd5.png [Screenshot 2019-11-07 at 15 31 27]https://user-images.githubusercontent.com/31136567/68402994-2530a300-0174-11ea-8986-43a65ac315bb.png

Also, a more general question: the dataframe that you're using in this vignette (https://rpubs.com/jgeller1/438015) is generated with SR Research Data Viewer right? If so, I was wondering whether parse_edf could be adapted to generate something similar without the need to pass trough Data Viewer, maybe by allowing to pass additional arguments to the function (?) I know that this might be hard especially because of each specific experiment's extra columns and respective identifiers (blocks, items etc.), however this would be super handy (e.g. automatically generate a column called block via parse_edf similarly to what happens for the trial one instead of having the entry "BLOCK_1" in the message coloumn). I'm asking this because I agree and fully support your preprocessing approach (and its theoretical references: Mathot and Kret & Sjak-Shie) so it would be really cool to be able to apply it right away by just importing data via parse_edf (therefore without the need to use Data Viewer).

As always, sorry for all of these questions and many thanks for your time.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dmirman-zz/gazer/issues/13?email_source=notifications&email_token=AEMTQEGHLYGTFVGSQ7ASLHDQSQ3Y5A5CNFSM4JIKVXG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDM4TUQ#issuecomment-551143890, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEMTQEHRIFR2OXGD6KGRG33QSQ3Y5ANCNFSM4JIKVXGQ.

[jgeller112]

You can do something like this to get Data Viewer like reports.

[jgeller112]

Hi @langestroop!

You will be interested to know I created a function called `find_messages_edfs' that creates a behave report that can be merged into the sample report. I think that is something you said you wanted.

find_messages_edf(file_list= file_list_samp, varnames=c("TRIALID","script", "TRIAL_VAR item", "TRIAL_VAR RT", "ACCURACY", "alteration", "block"), patterns=c("TRIALID","!V TRIAL_VAR script","!V TRIAL_VAR item", "!V TRIAL_VAR RT", "!V TRIAL_VAR ACCURACY","!V TRIAL_VAR alteration", "!V TRIAL_VAR block"), output_dir)