GNU bug report logs -
#29489
Obsolete gnus-remove-if and gnus-remove-if-not
Previous Next
Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Date: Tue, 28 Nov 2017 17:03:05 UTC
Severity: normal
Tags: patch
Found in version 5.13
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29489 in the body.
You can then email your comments to 29489 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Tue, 28 Nov 2017 17:03:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org.
(Tue, 28 Nov 2017 17:03:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here's another one of these.
I've replaced these with `seq-remove' and `seq-filter', and I suppose
someone might object to that -- the other option would be `cl-remove-if'
and `cl-remove-if-not'. I don't believe there's much practical difference.
Gnus v5.13
GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2017-11-27
[0001-Obsolete-gnus-remove-if-and-gnus-remove-if-not.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Tue, 28 Nov 2017 17:24:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 29489 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EA" == Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
EA> I've replaced these with `seq-remove' and `seq-filter', and I suppose
EA> someone might object to that -- the other option would be `cl-remove-if'
EA> and `cl-remove-if-not'. I don't believe there's much practical difference.
I have no objection to using seq over its cl- equivalents.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Added tag(s) patch.
Request was from
Eric Abrahamsen <eric <at> ericabrahamsen.net>
to
control <at> debbugs.gnu.org.
(Tue, 28 Nov 2017 17:29:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Tue, 28 Nov 2017 18:03:01 GMT)
Full text and
rfc822 format available.
Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):
"John Wiegley" <johnw <at> gnu.org> writes:
>>>>>> "EA" == Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
> EA> I've replaced these with `seq-remove' and `seq-filter', and I suppose
> EA> someone might object to that -- the other option would be `cl-remove-if'
> EA> and `cl-remove-if-not'. I don't believe there's much practical difference.
>
> I have no objection to using seq over its cl- equivalents.
Cool. I'll run this patch a while longer, then push.
Thanks,
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Tue, 28 Nov 2017 23:45:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Here's another one of these.
>
> I've replaced these with `seq-remove' and `seq-filter', and I suppose
> someone might object to that -- the other option would be `cl-remove-if'
> and `cl-remove-if-not'. I don't believe there's much practical difference.
Neither the seq nor cl functions handle hash tables right?
> - (gnus-remove-if-not 'gnus-valid-move-group-p gnus-active-hashtb t)
> + (seq-filter 'gnus-valid-move-group-p gnus-active-hashtb)
> nil prefix nil default))
> ((= 1 (length split-name))
> (gnus-group-completing-read
> prom
> - (gnus-remove-if-not 'gnus-valid-move-group-p gnus-active-hashtb t)
> + (seq-filter 'gnus-valid-move-group-p gnus-active-hashtb)
> nil prefix 'gnus-group-history (car split-name)))
> -(defun gnus-remove-if (predicate sequence &optional hash-table-p)
> - "Return a copy of SEQUENCE with all items satisfying PREDICATE removed.
> -SEQUENCE should be a list, a vector, or a string. Returns always a list.
> -If HASH-TABLE-P is non-nil, regards SEQUENCE as a hash table."
Although the docstring claims "hash table", while the code says...
> - (if hash-table-p
> - (mapatoms (lambda (symbol)
> - (unless (funcall predicate symbol)
> - (push symbol out)))
> - sequence)
obarray?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Wed, 29 Nov 2017 00:08:01 GMT)
Full text and
rfc822 format available.
Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Here's another one of these.
>>
>> I've replaced these with `seq-remove' and `seq-filter', and I suppose
>> someone might object to that -- the other option would be `cl-remove-if'
>> and `cl-remove-if-not'. I don't believe there's much practical difference.
>
> Neither the seq nor cl functions handle hash tables right?
>
>> - (gnus-remove-if-not 'gnus-valid-move-group-p gnus-active-hashtb t)
>> + (seq-filter 'gnus-valid-move-group-p gnus-active-hashtb)
>> nil prefix nil default))
>> ((= 1 (length split-name))
>> (gnus-group-completing-read
>> prom
>> - (gnus-remove-if-not 'gnus-valid-move-group-p gnus-active-hashtb t)
>> + (seq-filter 'gnus-valid-move-group-p gnus-active-hashtb)
>> nil prefix 'gnus-group-history (car split-name)))
>
>> -(defun gnus-remove-if (predicate sequence &optional hash-table-p)
>> - "Return a copy of SEQUENCE with all items satisfying PREDICATE removed.
>> -SEQUENCE should be a list, a vector, or a string. Returns always a list.
>> -If HASH-TABLE-P is non-nil, regards SEQUENCE as a hash table."
>
> Although the docstring claims "hash table", while the code says...
>
>> - (if hash-table-p
>> - (mapatoms (lambda (symbol)
>> - (unless (funcall predicate symbol)
>> - (push symbol out)))
>> - sequence)
>
> obarray?
Shhh, that's my next patch to Gnus! Turning its "hash tables" into
actual hash tables. The obarrays are an impressive and horrible hack.
For this version of the patch, `seq-filter' works on vectors. In the
next patch, it's replaced by seq-filter->map-keys.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Wed, 29 Nov 2017 00:41:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>> Although the docstring claims "hash table", while the code says...
>>
>>> - (if hash-table-p
>>> - (mapatoms (lambda (symbol)
>>> - (unless (funcall predicate symbol)
>>> - (push symbol out)))
>>> - sequence)
>>
>> obarray?
>
> Shhh, that's my next patch to Gnus! Turning its "hash tables" into
> actual hash tables. The obarrays are an impressive and horrible hack.
>
> For this version of the patch, `seq-filter' works on vectors. In the
> next patch, it's replaced by seq-filter->map-keys.
Hmm, seq-filter works on vectors, but it's not reliable for obarrays:
(let ((list nil)
(ob (make-vector 3 0)))
(intern "foo" ob)
(intern "bar" ob)
(intern "xxx" ob)
(seq-filter (lambda (_) t) ob)) ;=> (xxx 0 0)
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Wed, 29 Nov 2017 01:43:01 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>>> Although the docstring claims "hash table", while the code says...
>>>
>>>> - (if hash-table-p
>>>> - (mapatoms (lambda (symbol)
>>>> - (unless (funcall predicate symbol)
>>>> - (push symbol out)))
>>>> - sequence)
>>>
>>> obarray?
>>
>> Shhh, that's my next patch to Gnus! Turning its "hash tables" into
>> actual hash tables. The obarrays are an impressive and horrible hack.
>>
>> For this version of the patch, `seq-filter' works on vectors. In the
>> next patch, it's replaced by seq-filter->map-keys.
>
> Hmm, seq-filter works on vectors, but it's not reliable for obarrays:
>
> (let ((list nil)
> (ob (make-vector 3 0)))
> (intern "foo" ob)
> (intern "bar" ob)
> (intern "xxx" ob)
> (seq-filter (lambda (_) t) ob)) ;=> (xxx 0 0)
For the interim, all that matters is consistency:
(let ((list nil)
(ob (make-vector 3 0)))
(intern "foo" ob)
(intern "bar" ob)
(intern "xxx" ob)
(gnus-remove-if-not (lambda (_) t) ob)) ;=> (xxx 0 0)
The goal of this patch series is to get Gnus into a state where behavior
is at-a-glance comprehensible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Wed, 29 Nov 2017 02:37:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> For the interim, all that matters is consistency:
>
> (let ((list nil)
> (ob (make-vector 3 0)))
> (intern "foo" ob)
> (intern "bar" ob)
> (intern "xxx" ob)
> (gnus-remove-if-not (lambda (_) t) ob)) ;=> (xxx 0 0)
But:
(let ((list nil)
(ob (make-vector 3 0)))
(intern "foo" ob)
(intern "bar" ob)
(intern "xxx" ob)
(gnus-remove-if-not (lambda (_) t)
ob t)) ;=> (xxx bar foo)
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Wed, 29 Nov 2017 03:32:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> For the interim, all that matters is consistency:
>>
>> (let ((list nil)
>> (ob (make-vector 3 0)))
>> (intern "foo" ob)
>> (intern "bar" ob)
>> (intern "xxx" ob)
>> (gnus-remove-if-not (lambda (_) t) ob)) ;=> (xxx 0 0)
>
> But:
>
> (let ((list nil)
> (ob (make-vector 3 0)))
> (intern "foo" ob)
> (intern "bar" ob)
> (intern "xxx" ob)
> (gnus-remove-if-not (lambda (_) t)
> ob t)) ;=> (xxx bar foo)
Good catch! Thanks for that. I was too hasty, and had already moved on
to running the next patch.
There are only two places in the code where that third argument is
passed. I can rework those two locations so that they work properly,
until the next step is taken.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Fri, 01 Dec 2017 17:18:01 GMT)
Full text and
rfc822 format available.
Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>>> For the interim, all that matters is consistency:
>>>
>>> (let ((list nil)
>>> (ob (make-vector 3 0)))
>>> (intern "foo" ob)
>>> (intern "bar" ob)
>>> (intern "xxx" ob)
>>> (gnus-remove-if-not (lambda (_) t) ob)) ;=> (xxx 0 0)
>>
>> But:
>>
>> (let ((list nil)
>> (ob (make-vector 3 0)))
>> (intern "foo" ob)
>> (intern "bar" ob)
>> (intern "xxx" ob)
>> (gnus-remove-if-not (lambda (_) t)
>> ob t)) ;=> (xxx bar foo)
>
> Good catch! Thanks for that. I was too hasty, and had already moved on
> to running the next patch.
>
> There are only two places in the code where that third argument is
> passed. I can rework those two locations so that they work properly,
> until the next step is taken.
For a brief, amusing moment, I thought I could write a seq-filter method
that specialized on obarrays, but unfortunately there's no specializer
for obarrays. Oh well. Here's another version of the patch. It's not
pretty, but I do hope it's temporary.
[0001-Obsolete-gnus-remove-if-and-gnus-remove-if-not.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Sat, 02 Dec 2017 02:39:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> - (gnus-gethash group gnus-killed-hashtb)))
> + (gethash group gnus-killed-hashtb)))
Is this from a future patch? As far as I can tell, you haven't changed
gnus-killed-hashtb to a hashtable yet, it's still an obarray.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Sat, 02 Dec 2017 18:53:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 29489 <at> debbugs.gnu.org (full text, mbox):
On 12/01/17 21:38 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> - (gnus-gethash group gnus-killed-hashtb)))
>> + (gethash group gnus-killed-hashtb)))
>
> Is this from a future patch? As far as I can tell, you haven't changed
> gnus-killed-hashtb to a hashtable yet, it's still an obarray.
Bah! I'm sorry you've had to wade through my dumb mistakes. I'll make
better use of branches to keep these things separated cleanly.
Do you see anything else obviously wrong with this? I'll spend some more
time testing it, as well.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Sat, 02 Dec 2017 18:55:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 29489 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Do you see anything else obviously wrong with this? I'll spend some more
> time testing it, as well.
No, it all looks fine apart from that (though I've only eyeballed the
code, not tried to run anything).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#29489; Package
emacs,gnus.
(Sat, 02 Dec 2017 18:56:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 29489 <at> debbugs.gnu.org (full text, mbox):
On 12/02/17 13:54 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Do you see anything else obviously wrong with this? I'll spend some more
>> time testing it, as well.
>
> No, it all looks fine apart from that (though I've only eyeballed the
> code, not tried to run anything).
Okay good. I'll test more.
bug closed, send any further explanations to
29489 <at> debbugs.gnu.org and Eric Abrahamsen <eric <at> ericabrahamsen.net>
Request was from
Eric Abrahamsen <eric <at> ericabrahamsen.net>
to
control <at> debbugs.gnu.org.
(Sun, 10 Dec 2017 18:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 08 Jan 2018 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.