كيفية طلب خروج مبكر عند الحياكة وثيقة Rmd؟



markdown knitr (2)

IMHO ، صعوبة تصحيح مستند Rmd هو تحذير من وجود خطأ ما. لدي قاعدة من الإبهام: هل رفع الأحمال الثقيلة خارج Rmd. هل التقديم داخل Rmd ، والتقديم فقط . التي تبقي رمز Rmd بسيطة.

تبدو برامج R الكبيرة الخاصة بي هكذا.

data <- loadData()
analytics <- doAnalytics(data)
rmarkdown::render("theDoc.Rmd", envir=analytics)

(هنا ، تقوم doAnalytics بإرجاع قائمة أو بيئة. يتم تمرير هذه القائمة أو البيئة إلى مستند Rmd عبر معلمة envir ، مما يجعل نتائج حسابات التحليلات متاحة داخل المستند.)

تقوم الدالة doAnalytics بإجراء العمليات الحسابية المعقدة. يمكنني تصحيحها باستخدام الأدوات العادية ، ويمكنني بسهولة التحقق من مخرجاتها. بحلول الوقت الذي أتصل به rmarkdown :: render ، أعرف أن الأشياء الثابتة تعمل بشكل صحيح. رمز Rmd هو مجرد "طباعة هذا" و "تنسيق ذلك" ، من السهل تصحيحه.

هذا التقسيم للمسؤولية قد خدمني جيدًا ، ويمكنني أن أوصي به. مقارنةً بشكل خاص بمهمة الانحناء الذهني المتمثلة في تصحيح الحسابات المعقدة المدفونة داخل مستند تم عرضه ديناميكيًا.

دعنا نفترض أن لديك مستند تخفيض السعر R لن يتم تقديمه بشكل نظيف.

أعلم أنه يمكنك تعيين error خيار knitr على TRUE لطلب مواصلة التقييم ، حتى في حالة وجود أخطاء. يمكنك القيام بذلك لمجموعة knitr::opts_chunk$set(error = TRUE) عبر error = TRUE أو بطريقة أكثر عالمية عبر knitr::opts_chunk$set(error = TRUE) .

ولكن في بعض الأحيان هناك أخطاء لا تزال قاتلة لعملية الحياكة. مثالان rstudioapi::getVersion() مؤخرًا: محاولة unlink() دليل العمل الحالي (عفوا!) واستدعاء rstudioapi::getVersion() من كود R المضمّن في حالة عدم توفر RStudio. هل هناك وصف عام لأنواع الأخطاء هذه ، أي الأخطاء الخارجة عن نطاق error = TRUE ؟ هل هناك طريقة للتسامح مع الأخطاء في مضمنة R code vs في القطع؟

أيضًا ، هل هناك طرق أكثر رسمية لإيقاف الحياكة مبكرًا أو لأتمتة تصحيح الأخطاء في هذا الموقف؟


Answer #1

للخروج مبكرًا من عملية الحياكة ، يمكنك استخدام دالة knitr::knit_exit() في أي مكان في المستند المصدر (في مقطع رمز أو تعبير مضمّن). بمجرد knit_exit() ، سيتجاهل knitr بقية المستند ويكتب النتائج التي جمعها حتى الآن.

لا توجد طريقة لتحمل الأخطاء في كود R المضمّن في الوقت الحالي. تحتاج إلى التأكد من تشغيل رمز R المضمن دائمًا دون أخطاء 1 . في حالة حدوث أخطاء ، يجب أن تشاهد نطاق الخطوط التي أنتجت الخطأ من سجل knitr في وحدة التحكم ، من النموذج " Quitting from lines x1-x2 (filename.Rmd) . Rmd Quitting from lines x1-x2 (filename.Rmd) . بعد ذلك يمكنك الذهاب إلى ملف filename.Rmd ومعرفة الخطأ في الأسطر من x1 إلى x2 . نفس الشيء ينطبق على أجزاء الكود التي بها error = FALSE الخيار chunk error = FALSE .

بالإضافة إلى أنواع الأخطاء المذكورة أعلاه ، قد يكون من الصعب العثور على مصدر المشكلة. على سبيل المثال ، عندما تقوم بإلغاء unlink() الدليل الحالي عن غير قصد ، يجب ألا تتوقف عملية الحياكة ، لأن نجاح unlink() نجح على أي حال. قد تواجه مشكلات بعد عملية الحياكة ، على سبيل المثال ، لا يمكن لـ LaTeX / HTML العثور على ملفات أرقام المخرجات. في هذه الحالة ، يمكنك محاولة تطبيق knit_exit() على جميع أجزاء التعليمات البرمجية في المستند واحدة تلو الأخرى. إحدى الطرق لتحقيق ذلك هي إعداد ربط قطعة لتشغيل knit_exit() بعد قطعة معينة. فيما يلي مثال لاستخدام البحث الخطي (يمكنك تحسينه باستخدام التنصيص بدلاً من ذلك):

#' Render an input document chunk by chunk until an error occurs
#' 
#' @param input the input filename (an Rmd file in this example)
#' @param compile a function to compile the input file, e.g. knitr::knit, or
#'   rmarkdown::render
knit_debug = function(input, compile = knitr::knit) {
  library(knitr)
  lines = readLines(input)
  chunk = grep(all_patterns$md$chunk.begin, lines)  # line number of chunk headers

  knit_hooks$set(debug = function(before) {
    if (!before) {
      chunk_current <<- chunk_current + 1
      if (chunk_current >= chunk_num) knit_exit()
    }
  })

  opts_chunk$set(debug = TRUE)

  # try to exit after the i-th chunk and see which chunk introduced the error
  for (chunk_num in seq_along(chunk)) {
    chunk_current = 0  # a chunk counter, incremented after each chunk
    res = try(compile(input))
    if (inherits(res, 'try-error')) {
      message('The first error came from line ', chunk[chunk_num])
      break
    }
  }
}
  1. هذا حسب التصميم. أعتقد أنه من الجيد وجود error = TRUE لقطع الكود ، لأننا نريد أحيانًا إظهار الأخطاء ، على سبيل المثال ، لأغراض التدريس. ومع ذلك ، إذا سمحت بوجود أخطاء في الكود المضمن أيضًا ، فقد يفشل المؤلفون في التعرف على الأخطاء القاتلة في الكود المضمن. عادةً ما يتم استخدام التعليمات البرمجية المضمنة لتضمين القيم في السطر ، ولا أعتقد أنه من المنطقي إذا كانت القيمة المضمنة خطأ. تخيل جملة في تقرير مثل The P-value of my test is ERROR باختباري The P-value of my test is ERROR ، وإذا لم يشير knitr إلى الخطأ ، فسيتطلب من المؤلفين قراءة إخراج التقرير بعناية شديدة لتحديد هذه المشكلة. أعتقد أنها فكرة سيئة أن تضطر إلى الاعتماد على عيون البشر لإيجاد مثل هذه الأخطاء.




knitr