Open_Intro, Module1, mod line 55, mpg.midsize not loaded

[WilCrofter]

Question 55, Open_Intro, Module1

---

I have stored the values of the 'mpgCity' variable for ONLY midsize vehicles in a new variable called 'mpg.midsize', which you can view by typing 'mpg.midsize' below. Try it now.

ANSWER: mpg.midsize

Not a valid input!

An error was detected. Please notify the administator.

> exists("mpg.midsize") [1] FALSE

> data("mpg.midsize") Warning message: In data("mpg.midsize") : data set ‘mpg.midsize’ not found

---

Looks like the subset of cars is not in the package or dta files. Nor is it referred to in mod.info:

> mod.info Instructor.name. Nicholas.Carchedi 1 Course name: Open Intro 2 Module name: Introduction to Data 3 Packages required for this module (separated by commas): openintro, plotrix 4 Data sets required for this module (separated by commas): cars

---

If you resume after the abort, mpg.midsize exists. The reason appears to be that mod[23, "Correct.Answer"], which defines mpg.midsize was executed upon resumption along with other Correct.Answer code involving assignment. This entry was the "correct answer" to a "text" type Output which did not require an answer, hence was not executed when first encountered.

[ncarchedi]

Thank you very much for letting us know. We are working on repairing a few bugs and this is one of them. I hope to have it resolved in the next few days.

Sincerely, Nick

On Mon, Sep 30, 2013 at 8:07 PM, WilCrofter notifications@github.comwrote:

Question 55, Open_Intro, Module1

I have stored the values of the 'mpgCity' variable for ONLY midsize vehicles in a new variable called 'mpg.midsize', which you can view by typing 'mpg.midsize' below. Try it now.

ANSWER: mpg.midsize

Not a valid input!

An error was detected. Please notify the administator.

exists("mpg.midsize") [1] FALSE

data("mpg.midsize") Warning message: In data("mpg.midsize") : data set ‘mpg.midsize’ not found

---

Looks like the subset of cars is not in the package or dta files. Nor is it referred to in mod.info:

mod.info Instructor.name. Nicholas.Carchedi 1 Course name: Open Intro 2 Module name: Introduction to Data 3 Packages required for this module (separated by commas): openintro, plotrix 4 Data sets required for this module (separated by commas): cars

— Reply to this email directly or view it on GitHubhttps://github.com/ncarchedi/swirl/issues/5 .

Nicholas A. Carchedi ScM Student, Biostatistics Johns Hopkins Bloomberg School of Public Health 301.802.0573 | nick.carchedi@gmail.com

[ncarchedi]

You are absolutely correct in your assessment of the problem above. What I meant to do is this: Have swirl pre-define variables for the user according the instructor's wishes. It seems that the best place to do this would be the mod.info data frame where the rest of the "meta-data" regarding the module is stored. This is where we tell swirl what packages and data sets are required for each module.

We could simply add another entry for variable definitions that would be parsed and executed upon beginning the module. This would not be hard to do, but I'd have to make a few adjustments. Let me know if you agree this is a good (at least temporary) solution.

Nick

[WilCrofter]

I agree. Least chance of side effects,
  etc.
  As it is, the mod contains code to define mpg.midsize at line 28:

mod$Correct.Answer[28] [1] "mpg.midsize <- cars$mpgCity[cars$type==\"midsize\"]"

  but this code is not executed the first time it's encountered, I
  think because line 28's Output.Type is text. The entry might be
  left over from an earlier version of the mod.
  Anyway, the entry is parsed and eval'd if you resume after
  aborting first time through. I'm guessing, but that might be
  because, upon resuming, all correct answers containing '<-'
  which the user has already covered are executed. Maybe execution
  should be limited to correct answers with output type question for
  consistency.
  Cheers,
  Bill
  On 10/1/2013 10:38 PM, Nick Carchedi wrote:

  You are absolutely correct in your assessment of the problem
    above. What I meant to do is this: Have swirl pre-define
    variables for the user according the instructor's wishes. It
    seems that the best place to do this would be the mod.info
    data frame where the rest of the "meta-data" regarding the
    module is stored. This is where we tell swirl what packages and
    data sets are required for each module. 
  We could simply add another entry for variable definitions that
    would be parsed and executed upon beginning the module. This
    would not be hard to do, but I'd have to make a few adjustments.
    Let me know if you agree this is a good (at least temporary)
    solution.
  Nick
  —
    Reply to this email directly or view
      it on GitHub.

[ncarchedi]

Noted. Give me a few days on this and I will implement a solution.

Thanks again, Nick On Oct 2, 2013 8:47 AM, "WilCrofter" notifications@github.com wrote:

I agree. Least chance of side effects, etc. As it is, the mod contains code to define mpg.midsize at line 28:

mod$Correct.Answer[28] [1] "mpg.midsize <- cars$mpgCity[cars$type==\"midsize\"]"

but this code is not executed the first time it's encountered, I think because line 28's Output.Type is text. The entry might be left over from an earlier version of the mod. Anyway, the entry is parsed and eval'd if you resume after aborting first time through. I'm guessing, but that might be because, upon resuming, all correct answers containing '<-' which the user has already covered are executed. Maybe execution should be limited to correct answers with output type question for consistency. Cheers, Bill On 10/1/2013 10:38 PM, Nick Carchedi wrote:

You are absolutely correct in your assessment of the problem above. What I meant to do is this: Have swirl pre-define variables for the user according the instructor's wishes. It seems that the best place to do this would be the mod.info data frame where the rest of the "meta-data" regarding the module is stored. This is where we tell swirl what packages and data sets are required for each module. We could simply add another entry for variable definitions that would be parsed and executed upon beginning the module. This would not be hard to do, but I'd have to make a few adjustments. Let me know if you agree this is a good (at least temporary) solution. Nick — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/ncarchedi/swirl/issues/5#issuecomment-25535314 .

[WilCrofter]

Nick,
  Sorry for this afterthought. I know you are swamped, 5th week of
  semester or so.
  But what do you think of adding another type, 'source', which
  worked a bit like 'figure' but merely sourced a R file? That way
  the timing of its execution could be controlled, as it is with
  figure. 
  Bill
  On 10/2/2013 11:22 AM, Nick Carchedi wrote:
Noted. Give me a few days on this and I will implement
  a solution.

  Thanks again,

  Nick

  On Oct 2, 2013 8:47 AM, "WilCrofter"
  <notifications@github.com> wrote:

  >

  > I agree. Least chance of side effects,

  > etc.

  > As it is, the mod contains code to define mpg.midsize at line
  28:

  >

  > > mod$Correct.Answer[28]

  > [1] "mpg.midsize <- cars$mpgCity[cars$type==\"midsize\"]"

  >

  > but this code is not executed the first time it's
  encountered, I

  > think because line 28's Output.Type is text. The entry might
  be

  > left over from an earlier version of the mod.

  > Anyway, the entry is parsed and eval'd if you resume after

  > aborting first time through. I'm guessing, but that might be

  > because, upon resuming, all correct answers containing
  '<-'

  > which the user has already covered are executed. Maybe
  execution

  > should be limited to correct answers with output type
  question for

  > consistency.

  > Cheers,

  > Bill

  > On 10/1/2013 10:38 PM, Nick Carchedi wrote:

  >

  > You are absolutely correct in your assessment of the problem

  > above. What I meant to do is this: Have swirl pre-define

  > variables for the user according the instructor's wishes. It

  > seems that the best place to do this would be the mod.info

  > data frame where the rest of the "meta-data" regarding the

  > module is stored. This is where we tell swirl what packages
  and

  > data sets are required for each module.

  > We could simply add another entry for variable definitions
  that

  > would be parsed and executed upon beginning the module. This

  > would not be hard to do, but I'd have to make a few
  adjustments.

  > Let me know if you agree this is a good (at least temporary)

  > solution.

  > Nick

  > —

  > Reply to this email directly or view

  > it on GitHub.

  >

  > —

  > Reply to this email directly or view it on

GitHubhttps://github.com/ncarchedi/swirl/issues/5#issuecomment-25535314

.

  >
  —
    Reply to this email directly or view
      it on GitHub.

[ncarchedi]

I think this is a great idea. I'll have to deal with this one on my own, since I'll modify the excel templates sent to instructors in the first place. I don't include the templates in the package, just the .rda files that are derived from them.

Thanks again, Nick

On Wed, Oct 2, 2013 at 1:08 PM, William R Bauer notifications@github.comwrote:

Nick, Sorry for this afterthought. I know you are swamped, 5th week of semester or so. But what do you think of adding another type, 'source', which worked a bit like 'figure' but merely sourced a R file? That way the timing of its execution could be controlled, as it is with figure. Bill

On 10/2/2013 11:22 AM, Nick Carchedi wrote: Noted. Give me a few days on this and I will implement a solution.

Thanks again,

Nick

On Oct 2, 2013 8:47 AM, "WilCrofter" notifications@github.com wrote:

I agree. Least chance of side effects,

etc.

As it is, the mod contains code to define mpg.midsize at line 28:

mod$Correct.Answer[28]

[1] "mpg.midsize <- cars$mpgCity[cars$type==\"midsize\"]"

but this code is not executed the first time it's encountered, I

think because line 28's Output.Type is text. The entry might be

left over from an earlier version of the mod.

Anyway, the entry is parsed and eval'd if you resume after

aborting first time through. I'm guessing, but that might be

because, upon resuming, all correct answers containing '<-'

which the user has already covered are executed. Maybe execution

should be limited to correct answers with output type question for

consistency.

Cheers,

Bill

On 10/1/2013 10:38 PM, Nick Carchedi wrote:

You are absolutely correct in your assessment of the problem

above. What I meant to do is this: Have swirl pre-define

variables for the user according the instructor's wishes. It

seems that the best place to do this would be the mod.info

data frame where the rest of the "meta-data" regarding the

module is stored. This is where we tell swirl what packages and

data sets are required for each module.

We could simply add another entry for variable definitions that

would be parsed and executed upon beginning the module. This

would not be hard to do, but I'd have to make a few adjustments.

Let me know if you agree this is a good (at least temporary)

solution.

Nick

—

Reply to this email directly or view

it on GitHub.

—

Reply to this email directly or view it on GitHubhttps://github.com/ncarchedi/swirl/issues/5#issuecomment-25535314

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/ncarchedi/swirl/issues/5#issuecomment-25557004 .

Nicholas A. Carchedi ScM Student, Biostatistics Johns Hopkins Bloomberg School of Public Health 301.802.0573 | nick.carchedi@gmail.com

[ncarchedi]

This should no longer be a problem. I just pushed a temporary patch that will have to do until we find a more elegant solution.