From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wJqXNZtvBWU8yQAA9RJhRA:P1 (envelope-from ) for ; Sat, 16 Sep 2023 11:04:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id wJqXNZtvBWU8yQAA9RJhRA (envelope-from ) for ; Sat, 16 Sep 2023 11:04:27 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 947C742035 for ; Sat, 16 Sep 2023 11:04:27 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=mHXQHDAT; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694855067; a=rsa-sha256; cv=none; b=jKwHyiYFFDbKhd7BgUk+TksZhutprAiMrCfL1rKAdTxQClaYqXpp4OBqog+9cSYMOZiYVX TBo5+mCCN1jmH1+jGTxJGdqfRkoxuGBiGUKICBOlKMk+qXdEJuqh3BYiqql8XQjLOpYwvR T9wlPK2jNkCeX4pkaESxVNKHY69FMbhng8syj+lNKH9zY6wdUomZanGMJsnVEPCYd3JnuD kacH5OAipGEhpxk07OPCGGmSF8n3miAlSZPd17xhc35CcUWOWhQGjeomVxxjHsPou1hinY mu1XLmPCAl3pR6J8HA8GRBDV/iNDU4CTIJljNJ68fJHMXRFb32PMWZL46rkNlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694855067; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=0u4F98mP8DyCeqSEghZSm5crtOKNtd+wRsS/QJgVlrY=; b=E3tZrpjSplTdqWRso1aeCdi2e80bHG7wpOERHecilUoUWahPMXLOHW1RJe/HwOz0l2jO3H fWpmHg49uHfpt5CbbiTcDExP3ROBuwgxGC8TALhrgz0JBaikjO6zaLf9AWd0z7u828svIy YjTFrlFkG6gJDyTbj+3CE70ezOs8ENUNNojkHhqsdDcEOec2EjaUsL8321JoepiBf2WDco 0flc7b/i++vx4fTQ8WLF3IWmpY6XXkXzudHyiF2+cF9MYKmdbRdrpz2Tr7og6rkw7Ll/Zg qlq7lnt3UVWs9B/84wto9BcwZEBC8lFV5pLY6cywtGkiwPJh1GMc69Bp1/G42g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=mHXQHDAT; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhRD7-0005fw-Ij; Sat, 16 Sep 2023 05:03:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhRD1-0005fW-EC for emacs-orgmode@gnu.org; Sat, 16 Sep 2023 05:03:23 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhRCy-0001XE-Cs for emacs-orgmode@gnu.org; Sat, 16 Sep 2023 05:03:23 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3406D240028 for ; Sat, 16 Sep 2023 11:03:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1694854998; bh=4y7vMja3ruxwPbjW8KEjYubC0sX1FxIWCy/eTF4Ni1o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=mHXQHDATzstPq5uVgGGk2prqWpJdVMWwgRnB2+aHgw7C0KyNadUWFqFaXsOGX7y2F rkTv72eMkR9kM1syBHGz/m1K10Pxb51FK+ef7TahmJ80DcuiRqRLK7XcjTr8rC9c5P 0ydl07O1IaJ5sPfsUF5MOXP47OMChg4U2y+zzFWrouVgEJGG7WmtrZtrfXx1RTPTCR d6szrkPFbuyrQCnTA1S63OYBTrH1CKkEYBysHlLG2FrBtJo/5zIMFwFYKZs9cihl28 nPPtU02axWA/mc+YQKtAQTAPNX+6QJ10tOJ0zPWAMVO85NWghqwqY3i4f3m0goECKs HLfTtu+djwEEg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RnlTK1sr8z6twv; Sat, 16 Sep 2023 11:03:17 +0200 (CEST) From: Ihor Radchenko To: Leo Butler Cc: Bastien , Lockywolf , "emacs-orgmode@gnu.org" Subject: Re: [PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom) In-Reply-To: <87ediz4ggm.fsf@t14.reltub.ca> References: <874jkemrk2.fsf@laptop.lockywolf.net> <87cyz1ivzw.fsf@t14.reltub.ca> <874jkdhwix.fsf@localhost> <87wmx8h2b0.fsf@t14.reltub.ca> <87il8ovqeg.fsf@localhost> <87cyyvdraz.fsf@t14.reltub.ca> <87ledinrl5.fsf@localhost> <87y1hb5cb4.fsf_-_@t14.reltub.ca> <87jzsrai3x.fsf@localhost> <87ediz4ggm.fsf@t14.reltub.ca> Date: Sat, 16 Sep 2023 09:04:24 +0000 Message-ID: <87ediypjzb.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.40 X-Spam-Score: -9.40 X-Migadu-Queue-Id: 947C742035 X-Migadu-Scanner: mx2.migadu.com X-TUID: PHX4shyePhLv Leo Butler writes: >> Also, non-standard arguments should be defined in `org-babel-header-args:maxima'. >> > > Ok. I see that some packages (e.g. ob-gnuplot.el) use a `defvar' form, > while others (e.g. ob-R.el) use a `defconst' form. Is there a preference? defconst I think. The value is not supposed to be changed. >>> I have also moved two defaults, that were embedded in the code, to >>> `defvar' forms. >> >> This is fine, although I would prefer to keep these variables private for >> now. > > My understanding is that a special variable defined via `defvar' is one > that is intended to be "private", i.e. users should not change it unless > they really know what they are doing. Is that accurate? Users are indeed not supposed to change defvar unless they know what they are doing. But it is not considered private - there is a guarantee that the meaning or type of the variable is not going to change. > Do you mean the names should be something like > > org-babel-maxima--command-arguments > > ? Yes. Having "--" means - if you use this variable, do it at your own risk; we can re-purpose it or change or rename or do whatever at any time. >>> - (format "batchload(%S)$" in-file)) >>> + (format "(linenum:0, %s(%S))$" batch/load in-file)) >> >> May you clarify the purpose of "linenum"? > > Maxima keeps track of input/output line numbers via the variable > `linenum'. I set the linenum to 0 so that the line numbering of the > input in `in-file' starts at 1 not 2. > > This idiom has been used in other Maxima front-ends, such as > `imaxima.el', too (although imaxima now uses the lisp reader, instead). > > See https://sourceforge.net/p/maxima/code/ci/76105d9ee231679eccac888a04c98e6ef66df087/ Do I understand correctly that the above will simply affect debug output when maxima references where a problematic line is located in the source? >>> (unless (or (string-match "batch" line) >>> (string-match "^rat: replaced .*$" line) >>> (string-match "^;;; Loading #P" line) >>> + (string-match "^read and interpret" line) >>> + (string-match "^(%\\([io]-?[0-9]+\\))[ ]+$" line) >> >> May you explain why you added these two conditions? > > When `batch' starts, it emits the line starting with 'read and > interpret' and including the name of the file being read. This is > extraneous output, and should be filtered out. > > The second addition filters out empty input/output lines. Without that > filter, the block > > #+name: ob-maxima/batch+verbatim+quiet > #+begin_src maxima :exports both :results verbatim :batch batch :cmdline --quiet > (assume(z>0), > integrate(exp(-t)*t^z, t, 0, inf)); > #+end_src > > produces an output with a pair of empty lines: > > #+RESULTS: ob-maxima/batch+verbatim+quiet > : (%i1) (assume(z > 0),integrate(exp(-t)*t^z,t,0,inf)) > : (%o1) gamma(z + 1) > : (%i2) > : (%i4) > > > I don't understand why those extra lines appear. It looks to me like a > bug in Maxima, but, because of that, they need to be filtered out. May empty lines be intentional in some maxima code? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at