[PATCH] may we focus on readability?

[PATCH] may we focus on readability?

[Mario Frasca]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

I'm rewriting a complicated construction where there's an equality
test on the length of the list of non matching elements, with a
simpler cl-some invocation.  The replacing code is self explanatory.


[-- Attachment #2: 0001-lisp-org-plot.el-reducing-complexity-of-test.patch --]
[-- Type: text/x-patch, Size: 1826 bytes --]

From 918b0e7ba2db438cc9b81131317501b93a45b1d8 Mon Sep 17 00:00:00 2001
From: mfrasca <mario@anche.no>
Date: Sun, 14 Jun 2020 10:52:41 -0500
Subject: [PATCH] lisp/org-plot.el: reducing complexity of test.

* lisp/org-plot.el (org-plot/gnuplot): readability of test, looking
for some non satisfying elements.

I'm rewriting a complicated construction where there's an equality
test on the length of the list of non matching elements, with a
simpler cl-some invocation.  The replacing code is self explanatory.
---
 lisp/org-plot.el | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..f50ad09a9 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -312,22 +312,15 @@ line directly before or after the table."
       ;; Check for timestamp ind column.
       (let ((ind (1- (plist-get params :ind))))
 	(when (and (>= ind 0) (eq '2d (plist-get params :plot-type)))
-	  (if (= (length
-		  (delq 0 (mapcar
-			   (lambda (el)
-			     (if (string-match org-ts-regexp3 el) 0 1))
-			   (mapcar (lambda (row) (nth ind row)) table))))
-		 0)
+	  (if (cl-some (lambda (el)
+			 (not (string-match org-ts-regexp3 el)))
+		       (mapcar (lambda (row) (nth ind row)) table))
 	      (plist-put params :timeind t)
 	    ;; Check for text ind column.
 	    (if (or (string= (plist-get params :with) "hist")
-		    (> (length
-			(delq 0 (mapcar
-				 (lambda (el)
-				   (if (string-match org-table-number-regexp el)
-				       0 1))
-				 (mapcar (lambda (row) (nth ind row)) table))))
-		       0))
+		    (cl-some (lambda (el)
+			       (not (string-match org-table-number-regexp el)))
+			     (mapcar (lambda (row) (nth ind row)) table))))
 		(plist-put params :textind t)))))
       ;; Write script.
       (with-temp-buffer
-- 
2.20.1

Re: [PATCH] may we focus on readability?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Sun, Jun 14, 2020 at 11:47:31AM -0500, Mario Frasca wrote:
> I'm rewriting a complicated construction where there's an equality
> test on the length of the list of non matching elements, with a
> simpler cl-some invocation.  The replacing code is self explanatory.

Isn't `seq-some' equivalent? (in this case, at least; cl-some is
willing to take more than one sequence).

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

<tomas@tuxteam.de> writes:

> Isn't `seq-some' equivalent? (in this case, at least; cl-some is
> willing to take more than one sequence).

This is only tangential to your question, but, unfortunately, we cannot
use `seq-some' as Org still supports Emacs 24.3.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] may we focus on readability?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

On Sun, Jun 14, 2020 at 09:28:54PM +0200, Nicolas Goaziou wrote:
> Hello,

> > [seq-some?]

> This is only tangential to your question, but, unfortunately, we cannot
> use `seq-some' as Org still supports Emacs 24.3.

Thanks

-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

Mario Frasca <mario@anche.no> writes:

> I'm rewriting a complicated construction where there's an equality
> test on the length of the list of non matching elements, with a
> simpler cl-some invocation.  The replacing code is self explanatory.
>
> Subject: [PATCH] lisp/org-plot.el: reducing complexity of test.
>
> * lisp/org-plot.el (org-plot/gnuplot): readability of test, looking
> for some non satisfying elements.
>
> I'm rewriting a complicated construction where there's an equality
> test on the length of the list of non matching elements, with a
> simpler cl-some invocation.  The replacing code is self explanatory.
> ---
>  lisp/org-plot.el | 19 ++++++-------------
>  1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/lisp/org-plot.el b/lisp/org-plot.el
> index a23195d2a..f50ad09a9 100644
> --- a/lisp/org-plot.el
> +++ b/lisp/org-plot.el
> @@ -312,22 +312,15 @@ line directly before or after the table."
>        ;; Check for timestamp ind column.
>        (let ((ind (1- (plist-get params :ind))))
>  	(when (and (>= ind 0) (eq '2d (plist-get params :plot-type)))
> -	  (if (= (length
> -		  (delq 0 (mapcar
> -			   (lambda (el)
> -			     (if (string-match org-ts-regexp3 el) 0 1))
> -			   (mapcar (lambda (row) (nth ind row)) table))))
> -		 0)
> +	  (if (cl-some (lambda (el)
> +			 (not (string-match org-ts-regexp3 el)))
> +		       (mapcar (lambda (row) (nth ind row)) table))
>  	      (plist-put params :timeind t)
>  	    ;; Check for text ind column.
>  	    (if (or (string= (plist-get params :with) "hist")
> -		    (> (length
> -			(delq 0 (mapcar
> -				 (lambda (el)
> -				   (if (string-match org-table-number-regexp el)
> -				       0 1))
> -				 (mapcar (lambda (row) (nth ind row)) table))))
> -		       0))
> +		    (cl-some (lambda (el)
> +			       (not (string-match org-table-number-regexp el)))
> +			     (mapcar (lambda (row) (nth ind row)) table))))
>  		(plist-put params :textind t)))))
>        ;; Write script.
>        (with-temp-buffer

OK. Note you can go even further: nested `if' should be replaced with
a `cond'.

Also, further nit: (not (cl-every ...)) will apply `not' only once.

In any case, it would be better if refactoring happens while introducing
unit tests *hint*.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] may we focus on readability?

[Mario Frasca]

Hi Nicolas, I think that the hint on testing is very correct, I'm afraid 
I changed the semantics of one of the original tests, and I found that 
there's other cl functions other than just cl-some, also cl-every, 
cl-notevery, and cl-notany.  I'll have a closer look at this.  and write 
some tests before changing the code.

I also looked for the strange idiom used here, and these two are the 
only two locations I found.

how do I run tests from the command line (I'm using make test) but then 
limited to one lisp file?  or one specific test?

ciao,

Mario

On 14/06/2020 14:32, Nicolas Goaziou wrote:
> […]
> Also, further nit: (not (cl-every ...)) will apply `not' only once.
>
> In any case, it would be better if refactoring happens while introducing
> unit tests *hint*.
>
> Regards,

Re: [PATCH] may we focus on readability?

[Mario Frasca]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

second thought about testing:

if I did that, it would become longer than 15 lines, I would need 
refactoring quite a bit of stuff, and both things would require time, 
bureaucratic time, and programming time.

I had a closer look at my changes, re-read it, and used it a bit, and I 
think this is o.k.

see it yourself, when we have the agreement allowing you accept changes 
longer than 15 lines, I'll consider the needed refactoring and test-writing.

ciao,

Mario

On 15/06/2020 09:49, Mario Frasca wrote:
> Hi Nicolas, I think that the hint on testing is very correct, I'm 
> afraid I changed the semantics of one of the original tests, and I 
> found that there's other cl functions other than just cl-some, also 
> cl-every, cl-notevery, and cl-notany.  I'll have a closer look at 
> this.  and write some tests before changing the code.
>
> I also looked for the strange idiom used here, and these two are the 
> only two locations I found.
>
> how do I run tests from the command line (I'm using make test) but 
> then limited to one lisp file?  or one specific test?
>
> ciao,
>
> Mario
>
> On 14/06/2020 14:32, Nicolas Goaziou wrote:
>> […]
>> Also, further nit: (not (cl-every ...)) will apply `not' only once.
>>
>> In any case, it would be better if refactoring happens while introducing
>> unit tests *hint*.
>>
>> Regards,

[-- Attachment #2: 0001-lisp-org-plot.el-reducing-complexity-of-test.patch --]
[-- Type: text/x-patch, Size: 2380 bytes --]

From 49f1cfbb80a3d5ffdbac4eea60bb3d45991c4423 Mon Sep 17 00:00:00 2001
From: mfrasca <mario@anche.no>
Date: Sun, 14 Jun 2020 10:52:41 -0500
Subject: [PATCH] lisp/org-plot.el: reducing complexity of test.

* lisp/org-plot.el (org-plot/gnuplot): readability of test, looking
for some non satisfying elements.

I'm rewriting a complicated construction where there's an equality
test on the length of the list of non matching elements, with a
simpler cl-some invocation.  The replacing code is self explanatory.
---
 lisp/org-plot.el | 34 ++++++++++++++--------------------
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..bf81d3c37 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -309,26 +309,20 @@ line directly before or after the table."
 	(`grid (let ((y-labels (org-plot/gnuplot-to-grid-data
 				table data-file params)))
 		 (when y-labels (plist-put params :ylabels y-labels)))))
-      ;; Check for timestamp ind column.
-      (let ((ind (1- (plist-get params :ind))))
-	(when (and (>= ind 0) (eq '2d (plist-get params :plot-type)))
-	  (if (= (length
-		  (delq 0 (mapcar
-			   (lambda (el)
-			     (if (string-match org-ts-regexp3 el) 0 1))
-			   (mapcar (lambda (row) (nth ind row)) table))))
-		 0)
-	      (plist-put params :timeind t)
-	    ;; Check for text ind column.
-	    (if (or (string= (plist-get params :with) "hist")
-		    (> (length
-			(delq 0 (mapcar
-				 (lambda (el)
-				   (if (string-match org-table-number-regexp el)
-				       0 1))
-				 (mapcar (lambda (row) (nth ind row)) table))))
-		       0))
-		(plist-put params :textind t)))))
+      ;; Check type of ind column (timestamp? text?)
+      (when (eq `2d (plist-get params :plot-type))
+	(let* ((ind (1- (plist-get params :ind)))
+	       (ind-column (mapcar (lambda (row) (nth ind row)) table)))
+	  (cond ((< ind 0) nil) ; ind is implicit
+		((cl-every (lambda (el)
+			     (string-match org-ts-regexp3 el))
+			   ind-column)
+		 (plist-put params :timeind t)) ; ind holds timestamps
+		((or (string= (plist-get params :with) "hist")
+		     (cl-notevery (lambda (el)
+				    (string-match org-table-number-regexp el))
+				  ind-column))
+		 (plist-put params :textind t))))) ; ind holds text
       ;; Write script.
       (with-temp-buffer
 	(if (plist-get params :script)	; user script
-- 
2.20.1

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

Mario Frasca <mario@anche.no> writes:

> how do I run tests from the command line (I'm using make test) but
> then limited to one lisp file?  or one specific test?

Use BTEST_RE="regexp" prefix, e.g.,


  BTEST_RE="table" make test

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

Mario Frasca <mario@anche.no> writes:

> I had a closer look at my changes, re-read it, and used it a bit, and
> I think this is o.k.

It looks fine, indeed.

> see it yourself, when we have the agreement allowing you accept
> changes longer than 15 lines, I'll consider the needed refactoring and
> test-writing.

I didn't know you hadn't signed FSF papers. Since we are in feature
freeze, and this is not a bug-fix, what about waiting until bureaucracy
is over? 

Of course, this assumes you're planning to sign FSF papers.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] may we focus on readability?

[Mario Frasca]

On 16/06/2020 11:56, Nicolas Goaziou wrote:
> what about waiting until bureaucracy
> is over?

I'm fine with it, but I'm accumulating several adjustments, and it's 
being difficult to keep track of each of them separately.

> Of course, this assumes you're planning to sign FSF papers.
I have signed and sent them in, 5th of June.

like … I'm adding a way to collect #+PLOT lines depending on which set 
of settings I want, to produce the graph.

#+PLOT[1]: set:"yrange [0:4200]"
#+PLOT[1]: set:"key at 33,4100 top left spacing 1.4"
#+PLOT[1]: set:"arrow from 59.5,0 rto 0,4200 nohead ls 1"
#+PLOT[2]: set:"yrange [50:10000]" set:"logscale y 10"
#+PLOT[2]: set:"key at 35,9000 top left spacing 1.4"
#+plot[2]: set:"arrow from 59.5,50 rto 0,200 nohead ls 1"
#+PLOT: set:"xtics rotate by 90" set:"mouse mouseformat ' '"
#+PLOT: ind:1 deps:(6 3 7 4 10) xticdep:15
#+plot: use:2
|  n |  data | prove, |  casi, | ratio |   prove, |    casi, | 7run | 
casi*6 |  casi, | cum-p | cum-c | cum-r |   ++% | lunes |
|    |       | valore | valore |       |    media |    media |      
|        | m.c.*5 |       |       |       |       | |

the #+plot: use:2 tells the program to collect PLOT[2] lines and to skip 
plot[1] definitions.

it needs be the first one met by the program, or at least precede any 
such lines.

oh, and the xticdep is an other addition

both I haven't shared yet, because it's a bit complicated doing so while 
the code doesn't contain the previous changes.

ciao, Mario

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

Mario Frasca <mario@anche.no> writes:

> second thought about testing:
>
> if I did that, it would become longer than 15 lines, I would need
> refactoring quite a bit of stuff, and both things would require time,
> bureaucratic time, and programming time.
>
> I had a closer look at my changes, re-read it, and used it a bit, and
> I think this is o.k.
>
> see it yourself, when we have the agreement allowing you accept
> changes longer than 15 lines, I'll consider the needed refactoring and
> test-writing.

I slightly changed the commit message and applied these changes.

Thank you.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] may we focus on readability?

[Nicolas Goaziou]

Hello,

Mario Frasca <mario@anche.no> writes:

> like … I'm adding a way to collect #+PLOT lines depending on which set 
> of settings I want, to produce the graph.
>
> #+PLOT[1]: set:"yrange [0:4200]"
> #+PLOT[1]: set:"key at 33,4100 top left spacing 1.4"
> #+PLOT[1]: set:"arrow from 59.5,0 rto 0,4200 nohead ls 1"
> #+PLOT[2]: set:"yrange [50:10000]" set:"logscale y 10"
> #+PLOT[2]: set:"key at 35,9000 top left spacing 1.4"
> #+plot[2]: set:"arrow from 59.5,50 rto 0,200 nohead ls 1"

I don't think this is a good idea, really. For this kind of complexity,
I suggest to consider using gnuplot source code blocks, with the table
as input.

Regards,
-- 
Nicolas Goaziou