Isolar ambiente de pré-correção

[andrechalom]

Na versão atual, o comando rm(list=ls()) pode apagar todos os objetos construidos pelas precondições. Como fazer para contornar isso?

[diogro]

Acho que é relativamente simples criar um env exclusivo pros objetos de correção e um para dos objetos criados pelos alunos. Uma opção boa é rodar todo o codigo do aluno dentro de uma função com um env novo, e ai vc tem um env com os objetos que ele criou e pode corrigir usando esse env vazio exclusivo do aluno. Algo assim:

studentCodeRunner <- function(file, envir = new.env()) {
  stopifnot(file.exists(file))
  stopifnot(is.environment(envir))
  
  lines <- readLines(file, warn = FALSE)
  exprs <- parse(text = lines)
  
  n <- length(exprs)
  if (n == 0L) return(invisible())
  
  for (i in seq_len(n - 1)) {
    eval(exprs[i], envir)
  }
  invisible(eval(exprs[n], envir))
}
e = new.env()
studentCodeRunner(file = "notar.1.4.r", envir = e)
ls(e)

[diogro]

Acho que isso resolve o issue #5 tb, é só comparar os objetos gabarito com tudo que tiver no env do aluno.

[andrechalom]

O código antigo do notaR faz isso com um único env, no qual são rodadas as "precondições" e o script do aluno. Em um único env, ocorre o problema do aluno sobreescrever os objetos de precondição. Rodando as precondições sem env, corre o risco do exercício sobreescrever funções importantes, como a própria funcionalidade do corretor. E fazendo simplesmente dois envs, não dá pra rodar os códigos de teste.

O que eu estou pensando em fazer é manter um env com o código do aluno e extrair desse env os objetos que o aluno criar (vide #5) para um env de correção, no qual estariam criados os objetos das precondições.

[adalardo]

Acho a ideia dos env legal. Uma sugestão é criar o environment para as precondições do notaR e não para o aluno. Algo como o notar ser um pacote com seu próprio NAMESPACE e colocar os objetos de precondições nele. Assim o script do aluno fica no GlobalEnv e não sobrepoem o notaR. Para chamar os objetos de precondições usar a localização do namespace "notaR::aves". Não sei se entendi o problema de usar env apontado pelo Chalom... Alexandre Adalardo de Oliveira Professor Doutor Universidade de São Paulo IB-Depto Ecologia http://labtrop.ib.usp.br <http://ecologia.ib.usp.br/labtrop> [email protected]

…

____________________ [email protected] http://scholar.google.com.br/citations?user=O1gcrwIAAAAJ&hl=pt-BR Em 30 de abril de 2018 20:46, Andre Chalom <[email protected]> escreveu:

O código antigo do notaR faz isso com um único env, no qual são rodadas as "precondições" e o script do aluno. Em um único env, ocorre o problema do aluno sobreescrever os objetos de precondição. Rodando as precondições sem env, corre o risco do exercício sobreescrever funções importantes, como a própria funcionalidade do corretor. E fazendo simplesmente dois envs, não dá pra rodar os códigos de teste. O que eu estou pensando em fazer é manter um env com o código do aluno e extrair desse env os objetos que o aluno criar (vide #5 <#5>) para um env de correção, no qual estariam criados os objetos das precondições. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHRIdbZD8PABfTWrN5mA6X_ZUplY6i5Vks5tt6JMgaJpZM4TilRB> .