GNU bug report logs - #31742
26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31742 in the body.
You can then email your comments to 31742 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Wed, 06 Jun 2018 21:07:21 -0400

[Message part 1 (text/plain, inline)]

Hi,

An Excorporate user reported an issue when running on Emacs 26.1 that
didn't happen in Emacs 25.3.

The error message, when trying to retrieve calendar items on a given day
is:

soap-find-operation: Wrong type argument: soap-binding, ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")

The simplest workaround is:

   M-x package-reinstall RET excorporate RET

I narrowed the cause down to what seems to be an incompatibility between
25.x bytecode and 26.1.  This issue only happens when excorporate.elc
has been byte compiled in Emacs 25.x (the .x doesn't seem to matter; I
replicated it on Emacs 25.1) and is then run in Emacs 26.1.  It doesn't
happen with a fresh package install on 25.x or 26.1.

When in the failure state, if I re-eval this function:

(defun exco--bind-wsdl (wsdl service-url port-name target-namespace
                             binding-name)
  "Create a WSDL binding.
Create a binding port for WSDL from SERVICE-URL, PORT-NAME,
TARGET-NAMESPACE and BINDING-NAME."
  (let* ((namespace (soap-wsdl-find-namespace target-namespace wsdl))
         (port (make-soap-port
                :name port-name
                :binding (cons target-namespace binding-name)
                :service-url service-url)))
    (soap-namespace-put port namespace)
    (push port (soap-wsdl-ports wsdl))
    (soap-resolve-references port wsdl)
    wsdl))

everything works.

In terms higher level functionality, it seems like the call to
soap-resolve-references has no effect.

I'm attaching the 25.1 and 26.1 bytecode for this function,
disassembled.  Maybe someone can identify what's wrong or suggest next
steps?

Thank you,
Thomas

[exco--bind-wsdl-dump-25.1.txt (text/plain, attachment)]

[exco--bind-wsdl-dump-26.1.txt (text/plain, attachment)]

Message #8 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Wed, 06 Jun 2018 21:14:47 -0400

Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> soap-find-operation: Wrong type argument: soap-binding, ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")

> byte code for exco--bind-wsdl:
>   doc:  Create a WSDL binding. ...
>   args: (arg1 arg2 arg3 arg4 arg5)
> 0	constant  soap-wsdl-find-namespace
> 1	stack-ref 2
> 2	stack-ref 6
> 4	call	  2
> 5	constant  vector
> 6	constant  cl-struct-soap-port

> byte code for exco--bind-wsdl:
>   doc:  Create a WSDL binding. ...
>   args: (arg1 arg2 arg3 arg4 arg5)
> 0	constant  soap-wsdl-find-namespace
> 1	stack-ref 2
> 2	stack-ref 6
> 4	call	  2
> 5	constant  record
> 6	constant  soap-port

Looks like it's due to the change in how cl-struct works.  Does enabling
cl-old-struct-compat-mode help?

    cl-old-struct-compat-mode is an interactive autoloaded compiled Lisp
    function in ‘cl-lib.el’.

    (cl-old-struct-compat-mode &optional ARG)

    Enable backward compatibility with old-style structs.
    This can be needed when using code byte-compiled using the old
    macro-expansion of ‘cl-defstruct’ that used vectors objects instead
    of record objects.

Message #11 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Wed, 06 Jun 2018 22:01:42 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> soap-find-operation: Wrong type argument: soap-binding, ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")
>
>> byte code for exco--bind-wsdl:
>>   doc:  Create a WSDL binding. ...
>>   args: (arg1 arg2 arg3 arg4 arg5)
>> 0	constant  soap-wsdl-find-namespace
>> 1	stack-ref 2
>> 2	stack-ref 6
>> 4	call	  2
>> 5	constant  vector
>> 6	constant  cl-struct-soap-port
>
>> byte code for exco--bind-wsdl:
>>   doc:  Create a WSDL binding. ...
>>   args: (arg1 arg2 arg3 arg4 arg5)
>> 0	constant  soap-wsdl-find-namespace
>> 1	stack-ref 2
>> 2	stack-ref 6
>> 4	call	  2
>> 5	constant  record
>> 6	constant  soap-port
>
> Looks like it's due to the change in how cl-struct works.  Does enabling
> cl-old-struct-compat-mode help?
>
>     cl-old-struct-compat-mode is an interactive autoloaded compiled Lisp
>     function in ‘cl-lib.el’.
>
>     (cl-old-struct-compat-mode &optional ARG)
>
>     Enable backward compatibility with old-style structs.
>     This can be needed when using code byte-compiled using the old
>     macro-expansion of ‘cl-defstruct’ that used vectors objects instead
>     of record objects.

Hmm, that does look related, however I just retried with and without it.
That mode was already enabled when the failure happened (when I ran M-x
cl-old-struct-compat-mode, it output "Cl-Old-Struct-Compat mode
disabled").

If I disable the mode, then I get a different failure earlier:

(wrong-type-argument soap-element [cl-struct-soap-port "ExchangeServicePort" nil "https://mail.cisco.com/ews/exchange.asmx" ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")])

So it seems like cl-old-struct-compat-mode being enabled is having a
positive effect, but maybe it does not handle the specific
incompatibility I'm running into.

Thomas

Message #14 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 08:21:27 -0400

Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> So it seems like cl-old-struct-compat-mode being enabled is having a
> positive effect, but maybe it does not handle the specific
> incompatibility I'm running into.

Hmm, can't see anything else in the bytecode.  Can you post the full
backtrace from the failure?

Message #17 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 10:06:03 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> So it seems like cl-old-struct-compat-mode being enabled is having a
>> positive effect, but maybe it does not handle the specific
>> incompatibility I'm running into.
>
> Hmm, can't see anything else in the bytecode.  Can you post the full
> backtrace from the failure?

Yes, but the error that produces the backtrace happens much later
via a different entry point, M-x exco-calendar-show-day:

Debugger entered--Lisp error: (wrong-type-argument soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding"))
  signal(wrong-type-argument (soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")))
  soap-find-operation(#s(soap-port :name "ExchangeServicePort" :namespace-tag nil :service-url "https://redacted/ews/exchange.asmx" :binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")) "FindItem")
  soap-operation-arity(#s(soap-wsdl :origin "https://redacted/ews/exchange.asmx" :current-file nil :xmlschema-imports nil :ports (#s(soap-port :name "ExchangeServicePort" :namespace-tag nil :service-url "https://redacted/ews/exchange.asmx" :binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding"))) :alias-table (("ns3" . "http://schemas.microsoft.com/exchange/services/2006/messages") ("ns2" . "http://schemas.microsoft.com/exchange/services/2006/types") ("ns1" . "urn:ExchangeServicePortType") ("soapenc" . "http://schemas.xmlsoap.org/soap/encoding/") ("xsd" . "http://www.w3.org/2001/XMLSchema")) :namespaces (#s(soap-namespace :name "urn:ExchangeServicePortType" :elements #<hash-table equal 294/325 0x9cf7109>) #s(soap-namespace :name "http://schemas.microsoft.com/exchange/services/2006/types" :elements #<hash-table equal 683/730 0x7b5ea85>) #s(soap-namespace :name "http://schemas.microsoft.com/exchange/services/2006/messages" :elements #<hash-table equal 745/1095 0x61383d9>) #s(soap-namespace :name "http://schemas.xmlsoap.org/soap/encoding/" :elements #<hash-table equal 33/65 0x6805be1>) #s(soap-namespace :name "http://www.w3.org/2001/XMLSchema" :elements #<hash-table equal 33/65 0x6eb5cfd>))) "ExchangeServicePort" "FindItem")
  exco-get-meetings-for-day(("fitzsim <at> cisco.com" . "https://redacted/ews/exchange.asmx") 6 7 2018 #f(compiled-function (&rest arguments) #<bytecode 0x6b449ed>))
  #f(compiled-function (identifier callback) #<bytecode 0x6b44bfd>)(("fitzsim <at> cisco.com" . "https://redacted/ews/exchange.asmx") #f(compiled-function (&rest arguments) #<bytecode 0x6b449ed>))
  exco-connection-iterate(exco-org-initialize-buffer #f(compiled-function (identifier callback) #<bytecode 0x6b44bfd>) exco-org-insert-meetings exco-org-finalize-buffer)
  exco-org-show-day(6 7 2018)
  apply(exco-org-show-day (6 7 2018))
  exco-calendar-show-day()
  funcall-interactively(exco-calendar-show-day)
  call-interactively(exco-calendar-show-day nil nil)
  command-execute(exco-calendar-show-day)

The initial problem in exco--bind-wsdl (via the M-x excorporate entry
point) does not throw an error.  Basically, in the failure case, parsing
of the WSDL XML is incomplete, and the later error is due to that.

I printed the value of port from 26.1; with 25.1 bytecode it is:

[cl-struct-soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding)]

and with 26.1 bytecode it is:

#s(soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding))

Thomas

Message #20 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x
 fails in Emacs 26.1
Date: Thu, 7 Jun 2018 13:36:15 -0400

On 7 June 2018 at 10:06, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:

> Yes, but the error that produces the backtrace happens much later
> via a different entry point, M-x exco-calendar-show-day:
>
> Debugger entered--Lisp error: (wrong-type-argument soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding"))
>   signal(wrong-type-argument (soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")))
>   soap-find-operation(#s(soap-port :name "ExchangeServicePort" :namespace-tag nil :service-url "https://redacted/ews/exchange.asmx" :binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")) "FindItem")

> The initial problem in exco--bind-wsdl (via the M-x excorporate entry
> point) does not throw an error.  Basically, in the failure case, parsing
> of the WSDL XML is incomplete, and the later error is due to that.

Right, if I just evaluate the following in 26.1 without any 25.1
bytecode I get a similar error:

(let ((port (make-soap-port
         :name "ExchangeServicePort"
         :namespace-tag nil
         :service-url "https://redacted/ews/exchange.asmx"
         :binding
'("http://schemas.microsoft.com/exchange/services/2006/messages"
            . "ExchangeServiceBinding"))))
  (soap-find-operation port "FindItem"))

I don't quite understand how it's supposed to work successfully
though. Is there a way to see it working without having to run a
server on the other end (i.e., can you give some elisp forms to
evaluate that make the above work)?

I'm guessing the problem is with some old and new structs not matching
according to `equal' and/or `sxhash', which cl-old-struct-compat-mode
doesn't do anything about.

Message #23 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 21:13:34 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> On 7 June 2018 at 10:06, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>
>> Yes, but the error that produces the backtrace happens much later
>> via a different entry point, M-x exco-calendar-show-day:
>>
>> Debugger entered--Lisp error: (wrong-type-argument soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding"))
>>   signal(wrong-type-argument (soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")))
>>   soap-find-operation(#s(soap-port :name "ExchangeServicePort" :namespace-tag nil :service-url "https://redacted/ews/exchange.asmx" :binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")) "FindItem")
>
>> The initial problem in exco--bind-wsdl (via the M-x excorporate entry
>> point) does not throw an error.  Basically, in the failure case, parsing
>> of the WSDL XML is incomplete, and the later error is due to that.
>
> Right, if I just evaluate the following in 26.1 without any 25.1
> bytecode I get a similar error:
>
> (let ((port (make-soap-port
>          :name "ExchangeServicePort"
>          :namespace-tag nil
>          :service-url "https://redacted/ews/exchange.asmx"
>          :binding
> '("http://schemas.microsoft.com/exchange/services/2006/messages"
>             . "ExchangeServiceBinding"))))
>   (soap-find-operation port "FindItem"))
>
> I don't quite understand how it's supposed to work successfully
> though. Is there a way to see it working without having to run a
> server on the other end (i.e., can you give some elisp forms to
> evaluate that make the above work)?
>
> I'm guessing the problem is with some old and new structs not matching
> according to `equal' and/or `sxhash', which cl-old-struct-compat-mode
> doesn't do anything about.

I did some more narrowing and found that the issue is with the use of
symbol properties in soap-resolve-references.  I added debugging:

(defun soap-resolve-references (element wsdl)
  "Replace names in ELEMENT with the referenced objects in the WSDL.
This is a generic function which invokes a specific resolver
function depending on the type of the ELEMENT.

If ELEMENT has no resolver function, it is silently ignored."
  (when (equal (soap-element-name element) "ExchangeServicePort")
    (message "1: %s" element)
    (message "2: %s" (aref element 0))
    (message "3: %s" (get (aref element 0) 'soap-resolve-references)))
  (let ((resolver (get (aref element 0) 'soap-resolve-references)))
    (when resolver
      (funcall resolver element wsdl))))

In the working case, I get:

1: #s(soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding))
2: soap-port
3: soap-resolve-references-for-port

while in the failing case, I get:

1: [cl-struct-soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding)]
2: cl-struct-soap-port
3: nil

This means the resolver fails to run and the ExchangeServicePort element
is not expanded, which results in exco-calendar-show-day's subsequent
failure.

It seems like soap-client's use of symbol properties is not safe across
major Emacs versions.

Thomas

Message #26 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 21:57:37 -0400

Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> (defun soap-resolve-references (element wsdl)

>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))

Ah, then it should work to replace the (aref element 0) with (type-of
element) as long as cl-old-struct-compat-mode is enabled.

Message #29 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 22:17:15 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> (defun soap-resolve-references (element wsdl)
>
>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>
> Ah, then it should work to replace the (aref element 0) with (type-of
> element) as long as cl-old-struct-compat-mode is enabled.

Yes, I retested with that change and it does work.  I guess I should
submit a patch to change all those occurrences in soap-client.  I'm
hoping cl-old-struct-compat-mode will continue to be enabled by default
for a long time.  Thanks for looking into this.

Thomas

Message #32 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Fri, 08 Jun 2018 08:19:45 -0400

Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> Noam Postavsky <npostavs <at> gmail.com> writes:
>
>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>
>>> (defun soap-resolve-references (element wsdl)
>>
>>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>>
>> Ah, then it should work to replace the (aref element 0) with (type-of
>> element) as long as cl-old-struct-compat-mode is enabled.
>
> Yes, I retested with that change and it does work.  I guess I should
> submit a patch to change all those occurrences in soap-client.

I just noticed soap-client is also an ELPA package; then there is the
additional complication that type-of will give the wrong answer in Emacs
versions 25 and older.  So you would need something like

    (let ((type (type-of element)))
      (if (eq type 'vector)
          (aref element 0) ; For Emacs 25 and earlier.
        type))

> I'm hoping cl-old-struct-compat-mode will continue to be enabled by
> default for a long time.

I was going to say, it's currently not enabled by default, but it looks
like it gets enabled automagically when you load code from the old
cl-defstruct:

    (defun cl-struct-define (name docstring parent type named slots children-sym
                                  tag print)
      (unless type
        ;; Legacy defstruct, using tagged vectors.  Enable backward compatibility.
        (cl-old-struct-compat-mode 1))

Message #35 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Alexandru Harsanyi <AlexHarsanyi <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Fri, 08 Jun 2018 10:18:18 -0400

(CCing Alex Harsanyi.)

Noam Postavsky <npostavs <at> gmail.com> writes:

> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>
>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>
>>>> (defun soap-resolve-references (element wsdl)
>>>
>>>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>>>
>>> Ah, then it should work to replace the (aref element 0) with (type-of
>>> element) as long as cl-old-struct-compat-mode is enabled.
>>
>> Yes, I retested with that change and it does work.  I guess I should
>> submit a patch to change all those occurrences in soap-client.
>
> I just noticed soap-client is also an ELPA package; then there is the
> additional complication that type-of will give the wrong answer in Emacs
> versions 25 and older.  So you would need something like
>
>     (let ((type (type-of element)))
>       (if (eq type 'vector)
>           (aref element 0) ; For Emacs 25 and earlier.
>         type))

OK, I had that on my list to investigate before patching soap-client,
the compatibility range of type-of, but you've done it for me, thanks.
A soap-type-of compatibility function probably makes sense to replace
the (aref ... 0) occurrences in soap-client and soap-inspect.

>> I'm hoping cl-old-struct-compat-mode will continue to be enabled by
>> default for a long time.
>
> I was going to say, it's currently not enabled by default, but it looks
> like it gets enabled automagically when you load code from the old
> cl-defstruct:
>
>     (defun cl-struct-define (name docstring parent type named slots children-sym
>                                   tag print)
>       (unless type
>         ;; Legacy defstruct, using tagged vectors.  Enable backward compatibility.
>         (cl-old-struct-compat-mode 1))

Ah, great, so that logic can stay in Emacs indefinitely without
negatively affecting sessions that don't load old byte-code.

Thomas

Message #38 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Fri, 08 Jun 2018 22:54:17 -0400

[Message part 1 (text/plain, inline)]

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> On Fri, Jun 8, 2018 at 10:18 PM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>> (CCing Alex Harsanyi.)
>>
>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>
>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>
>>>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>>>
>>>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>>>
>>>>>> (defun soap-resolve-references (element wsdl)
>>>>>
>>>>>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>>>>>
>>>>> Ah, then it should work to replace the (aref element 0) with (type-of
>>>>> element) as long as cl-old-struct-compat-mode is enabled.
>>>>
>>>> Yes, I retested with that change and it does work.  I guess I should
>>>> submit a patch to change all those occurrences in soap-client.
>>>
>>> I just noticed soap-client is also an ELPA package; then there is the
>>> additional complication that type-of will give the wrong answer in Emacs
>>> versions 25 and older.  So you would need something like
>>>
>>>     (let ((type (type-of element)))
>>>       (if (eq type 'vector)
>>>           (aref element 0) ; For Emacs 25 and earlier.
>>>         type))
>>
>> OK, I had that on my list to investigate before patching soap-client,
>> the compatibility range of type-of, but you've done it for me, thanks.
>> A soap-type-of compatibility function probably makes sense to replace
>> the (aref ... 0) occurrences in soap-client and soap-inspect.
>>
>>>> I'm hoping cl-old-struct-compat-mode will continue to be enabled by
>>>> default for a long time.
>>>
>
> The `(aref element 0)` trick is the only one that `soap-client` uses.  All
> other struct usage is via accessor functions, the rest of the code does not
> assume they are vectors.  It seems to me that `cl-old-struct-compat-mode` is
> not needed.

OK.

> Thomas, will you prepare the patch for soap-client?

How about the attached?  I tested it in 26.1 with 25.1 excorporate.elc
byte-code, as well as with our test suite against 24.1, 25.1 and 26.1,
so it should be OK for GNU ELPA as well.

If this looks OK, I'll bump the soap-client.el version to 3.1.4 when I
push.

Thomas

[0001-soap-client-Add-byte-code-compatibility-function.patch (text/x-patch, attachment)]

Message #41 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Alex Harsanyi <alexharsanyi <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x
 fails in Emacs 26.1
Date: Sat, 9 Jun 2018 08:01:31 +0800

On Fri, Jun 8, 2018 at 10:18 PM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
> (CCing Alex Harsanyi.)
>
> Noam Postavsky <npostavs <at> gmail.com> writes:
>
>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>
>>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>>
>>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>>
>>>>> (defun soap-resolve-references (element wsdl)
>>>>
>>>>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>>>>
>>>> Ah, then it should work to replace the (aref element 0) with (type-of
>>>> element) as long as cl-old-struct-compat-mode is enabled.
>>>
>>> Yes, I retested with that change and it does work.  I guess I should
>>> submit a patch to change all those occurrences in soap-client.
>>
>> I just noticed soap-client is also an ELPA package; then there is the
>> additional complication that type-of will give the wrong answer in Emacs
>> versions 25 and older.  So you would need something like
>>
>>     (let ((type (type-of element)))
>>       (if (eq type 'vector)
>>           (aref element 0) ; For Emacs 25 and earlier.
>>         type))
>
> OK, I had that on my list to investigate before patching soap-client,
> the compatibility range of type-of, but you've done it for me, thanks.
> A soap-type-of compatibility function probably makes sense to replace
> the (aref ... 0) occurrences in soap-client and soap-inspect.
>
>>> I'm hoping cl-old-struct-compat-mode will continue to be enabled by
>>> default for a long time.
>>

The `(aref element 0)` trick is the only one that `soap-client` uses.  All
other struct usage is via accessor functions, the rest of the code does not
assume they are vectors.  It seems to me that `cl-old-struct-compat-mode` is
not needed.

Thomas, will you prepare the patch for soap-client?

Thanks,
Alex.

Message #44 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Alex Harsanyi <alexharsanyi <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x
 fails in Emacs 26.1
Date: Sat, 9 Jun 2018 17:13:28 +0800

On Sat, Jun 9, 2018 at 10:54 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:

>
> How about the attached?  I tested it in 26.1 with 25.1 excorporate.elc
> byte-code, as well as with our test suite against 24.1, 25.1 and 26.1,
> so it should be OK for GNU ELPA as well.
>
> If this looks OK, I'll bump the soap-client.el version to 3.1.4 when I
> push.

Can you please add a comment referencing this bug to the definition of
`soap-type-of`.  Other than that, it looks good to me.

Alex.

>
> Thomas
>

Message #47 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sat, 09 Jun 2018 06:30:21 -0400

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> On Fri, Jun 8, 2018 at 10:18 PM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>> (CCing Alex Harsanyi.)
>>
>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>
>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>
>>>> Noam Postavsky <npostavs <at> gmail.com> writes:
>>>>
>>>>> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>>>>>
>>>>>> (defun soap-resolve-references (element wsdl)
>>>>>
>>>>>>   (let ((resolver (get (aref element 0) 'soap-resolve-references)))
>>>>>
>>>>> Ah, then it should work to replace the (aref element 0) with (type-of
>>>>> element) as long as cl-old-struct-compat-mode is enabled.
>>>>
>>>> Yes, I retested with that change and it does work.  I guess I should
>>>> submit a patch to change all those occurrences in soap-client.
>>>
>>> I just noticed soap-client is also an ELPA package; then there is the
>>> additional complication that type-of will give the wrong answer in Emacs
>>> versions 25 and older.  So you would need something like
>>>
>>>     (let ((type (type-of element)))
>>>       (if (eq type 'vector)
>>>           (aref element 0) ; For Emacs 25 and earlier.
>>>         type))
>>
>> OK, I had that on my list to investigate before patching soap-client,
>> the compatibility range of type-of, but you've done it for me, thanks.
>> A soap-type-of compatibility function probably makes sense to replace
>> the (aref ... 0) occurrences in soap-client and soap-inspect.
>>
>>>> I'm hoping cl-old-struct-compat-mode will continue to be enabled by
>>>> default for a long time.
>>>
>
> The `(aref element 0)` trick is the only one that `soap-client` uses.  All
> other struct usage is via accessor functions, the rest of the code does not
> assume they are vectors.  It seems to me that `cl-old-struct-compat-mode` is
> not needed.

I went back and tested with cl-old-struct-compat-mode disabled, with the
soap-type-of patch, and I get an earlier failure, via M-x excorporate:

Debugger entered--Lisp error: (wrong-type-argument soap-element [cl-struct-soap-port "ExchangeServicePort" [...]
  signal(wrong-type-argument (soap-element [cl-struct-soap-port "ExchangeServicePort" nil [...]
  (or (and (memq (type-of element) cl-struct-soap-element-tags) t) (signal 'wrong-type-argument (list 'soap-ele [...]
  (progn (or (and (memq (type-of element) cl-struct-soap-element-tags) t) (signal 'wrong-type-argument (list 's [...]
  (let ((name (progn (or (and (memq (type-of element) cl-struct-soap-element-tags) t) (signal 'wrong-type-argum [...]
  soap-namespace-put([cl-struct-soap-port "ExchangeServicePort" nil "https://[redacted]/ews/exchange.asmx" [...]
  exco--bind-wsdl(#s(soap-wsdl :origin "https://[redacted]/ews/exchange.asmx" :current-file nil :xmlschema- [...]
  #f(compiled-function (fsm state-data) #<bytecode 0x105c08f9>)(fsm-exco--fsm-47 (:identifier ("fitzsim <at> cisco. [...]
  fsm-update(fsm-exco--fsm-47 :retrieving-data (:identifier ("fitzsim <at> cisco.com" . "https://[redacted]/ews [...]
  fsm-send-sync(fsm-exco--fsm-47 t nil)
  apply(fsm-send-sync (fsm-exco--fsm-47 t nil))
  timer-event-handler([t 23323 41935 594437 nil fsm-send-sync (fsm-exco--fsm-47 t nil) nil 155000])

The old/new cl-struct mixing happens because excorporate.elc (25.1
byte-code) calls make-soap-port, and passes the result to soap-client
(26.1).  So at least for Excorporate, cl-old-struct-compat-mode is
needed (in addition to the (aref ... 0) -> (soap-type-of ...)
soap-client change).

Thomas

Message #50 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sat, 09 Jun 2018 06:32:23 -0400

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> On Sat, Jun 9, 2018 at 10:54 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>
>>
>> How about the attached?  I tested it in 26.1 with 25.1 excorporate.elc
>> byte-code, as well as with our test suite against 24.1, 25.1 and 26.1,
>> so it should be OK for GNU ELPA as well.
>>
>> If this looks OK, I'll bump the soap-client.el version to 3.1.4 when I
>> push.
>
> Can you please add a comment referencing this bug to the definition of
> `soap-type-of`.  Other than that, it looks good to me.

OK, will do.  I think I should put this on the emacs-26 branch, and also
on master so that it'll automatically get updated in GNU ELPA.

Thomas

Message #53 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Alex Harsanyi <alexharsanyi <at> gmail.com>, 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sat, 09 Jun 2018 08:13:03 -0400

>> The `(aref element 0)` trick is the only one that `soap-client` uses.  All
>> other struct usage is via accessor functions, the rest of the code does not
>> assume they are vectors.  It seems to me that `cl-old-struct-compat-mode` is
>> not needed.

> I went back and tested with cl-old-struct-compat-mode disabled, with the
> soap-type-of patch, and I get an earlier failure, via M-x excorporate:

>  So at least for Excorporate, cl-old-struct-compat-mode is
> needed (in addition to the (aref ... 0) -> (soap-type-of ...)
> soap-client change).

Yeah, and for (type-of element) to properly substitute for (aref element
0) without cl-old-struct-compat-mode you would need

(defun soap-type-of (element)
  "Return the type of ELEMENT."
  (let ((type (type-of element)))
    (unless (eq type 'vector)           ; For Emacs 25 and earlier.
      (setq type (aref element 0)))
    (if (string-match "\\`cl-struct-" (symbol-name type)) ; Old-style struct.
        (intern (substring (symbol-name type) (match-end 0)))
      type)))

But since cl-old-struct-compat-mode activates automagically, may as well
take advantage of it.

Message #58 received at 31742-done <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Mon, 11 Jun 2018 21:55:48 -0400

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> On Sat, Jun 9, 2018 at 10:54 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>
>>
>> How about the attached?  I tested it in 26.1 with 25.1 excorporate.elc
>> byte-code, as well as with our test suite against 24.1, 25.1 and 26.1,
>> so it should be OK for GNU ELPA as well.
>>
>> If this looks OK, I'll bump the soap-client.el version to 3.1.4 when I
>> push.
>
> Can you please add a comment referencing this bug to the definition of
> `soap-type-of`.  Other than that, it looks good to me.

I added the comment, bumped the soap-client version to 3.1.4 and pushed
the patch to master so that GNU ELPA will be regenerated tonight.  I
also backported the patch to the emacs-26 branch since it fixes a
functional regression.

Thomas

Message #61 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Tue, 12 Jun 2018 20:11:49 +0300

> From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
> Date: Mon, 11 Jun 2018 21:55:48 -0400
> Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
> 
> I added the comment, bumped the soap-client version to 3.1.4 and pushed
> the patch to master so that GNU ELPA will be regenerated tonight.  I
> also backported the patch to the emacs-26 branch since it fixes a
> functional regression.

Thanks, but please in the future always ask before pushing stuff to
the release branch.  Not every regression fix should go to emacs-26,
only those which we consider "safe enough".

Also, if a change should be both on master and on emacs-26, push only
to the latter, and it will be later merged to master together with
other changes in emacs-26.  We only backport from master if initially
we didn't intend for a change to be on emacs-26; otherwise we merge in
the other direction.  (This is all explained in CONTRIBUTE under
"Branches".)

Message #64 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Tue, 12 Jun 2018 21:39:37 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
>> Date: Mon, 11 Jun 2018 21:55:48 -0400
>> Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
>> 
>> I added the comment, bumped the soap-client version to 3.1.4 and pushed
>> the patch to master so that GNU ELPA will be regenerated tonight.  I
>> also backported the patch to the emacs-26 branch since it fixes a
>> functional regression.
>
> Thanks, but please in the future always ask before pushing stuff to
> the release branch.  Not every regression fix should go to emacs-26,
> only those which we consider "safe enough".

OK, will do, sorry about that.

> Also, if a change should be both on master and on emacs-26, push only
> to the latter, and it will be later merged to master together with
> other changes in emacs-26.  We only backport from master if initially
> we didn't intend for a change to be on emacs-26; otherwise we merge in
> the other direction.  (This is all explained in CONTRIBUTE under
> "Branches".)

Yes, I knew about the preferred emacs-26 -> master merge direction, but
in this case I wanted to get the soap-client change out to GNU ELPA ASAP
so that users could unbreak their Emacs 25 byte-code.  A GNU ELPA
rebuild of soap-client requires a push to master.

I guess I should have undertaken a full gitmerge run myself after having
had the patch reviewed for emacs-26 on emacs-devel; I considered doing
so, but I thought the master -> emacs-26-backport approach would be less
risky.  But in the future I'll attempt the gitmerge route in cases like
this.

Thomas

Message #67 received at 31742-done <at> debbugs.gnu.org (full text, mbox):

From: Alex Harsanyi <alexharsanyi <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x
 fails in Emacs 26.1
Date: Sun, 17 Jun 2018 08:12:19 +0800

On Tue, Jun 12, 2018 at 9:55 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:

> I added the comment, bumped the soap-client version to 3.1.4 and pushed
> the patch to master so that GNU ELPA will be regenerated tonight.  I
> also backported the patch to the emacs-26 branch since it fixes a
> functional regression.

Hi Thomas,

Can you let me know where did you push the soap-client changes?

I can see that the package was released at gnu.elpa.org, but the
changes were not pushed either to the elpa.git repository at
https://git.savannah.gnu.org/git/emacs/elpa.git, or to my own copy of
it at https://github.com/alex-hhh/emacs-soap-client.

Thanks,
Alex.

>
> Thomas

Message #70 received at 31742-done <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sat, 16 Jun 2018 20:36:23 -0400

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> On Tue, Jun 12, 2018 at 9:55 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>
>> I added the comment, bumped the soap-client version to 3.1.4 and pushed
>> the patch to master so that GNU ELPA will be regenerated tonight.  I
>> also backported the patch to the emacs-26 branch since it fixes a
>> functional regression.
>
> Hi Thomas,
>
> Can you let me know where did you push the soap-client changes?
>
> I can see that the package was released at gnu.elpa.org, but the
> changes were not pushed either to the elpa.git repository at
> https://git.savannah.gnu.org/git/emacs/elpa.git, or to my own copy of
> it at https://github.com/alex-hhh/emacs-soap-client.

I pushed it to the emacs.git master and emacs-26 branches:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1feb2e221349f26ec26bc684e0cce2acecbed3ca

GNU ELPA pulls soap-client.el and soap-inspect.el from emacs.git's
master branch.

Let me know if you also want me to push the patch to
https://github.com/alex-hhh/emacs-soap-client.

Thomas

Message #73 received at 31742-done <at> debbugs.gnu.org (full text, mbox):

From: Alex Harsanyi <alexharsanyi <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x
 fails in Emacs 26.1
Date: Sun, 17 Jun 2018 09:31:35 +0800

Hi Thomas,

I was not aware that the soap-client.el in the GNU Emacs source has been
updated -- the maintainers at the time wanted a version that just worked with
debbugs, and put the most recent version in ELPA.

There are two inconsistencies with the current system, which can cause some
confusion:

* the soap-client web page on elpa.gnu.org has a link to the elpa.git
  repository, but there is nothing there (the CGit and Gitweb links):
  http://elpa.gnu.org/packages/soap-client.html

* in the GNU Emacs source code, soap-client.el has a "Homepage" link that
  points back to my GitHub repository, which is now out of date.

I think we need to decide on where to keep the "official" development history
for this package.  As I see it, there are a few options:

* Keep it on GitHub, where it is now.  In this case, I think you should push
  the patch and the 3.1.4 tag there, and the ELPA links need to be fixed.

* Import it into elpa.git, as a separate branch (I see other packages are
  maintained like that).  In this case, the "Homepage" link should be updated
  to point to this source.

* Keep it in the GNU Emacs source tree (this will loose the git history, but
  maybe it is not important).  In this case the, both the "Homepage" link and
  the ELPA web page should be updated.

I have no strong preference for either option, apart for making it easier for
people to know where to go for the package source.  If the GitHub repository
is no longer the latest source code, I can archive it and point to the new
location.


Alex.

On Sun, Jun 17, 2018 at 8:36 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
> Alex Harsanyi <alexharsanyi <at> gmail.com> writes:
>
>> On Tue, Jun 12, 2018 at 9:55 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>>
>>> I added the comment, bumped the soap-client version to 3.1.4 and pushed
>>> the patch to master so that GNU ELPA will be regenerated tonight.  I
>>> also backported the patch to the emacs-26 branch since it fixes a
>>> functional regression.
>>
>> Hi Thomas,
>>
>> Can you let me know where did you push the soap-client changes?
>>
>> I can see that the package was released at gnu.elpa.org, but the
>> changes were not pushed either to the elpa.git repository at
>> https://git.savannah.gnu.org/git/emacs/elpa.git, or to my own copy of
>> it at https://github.com/alex-hhh/emacs-soap-client.
>
> I pushed it to the emacs.git master and emacs-26 branches:
>
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1feb2e221349f26ec26bc684e0cce2acecbed3ca
>
> GNU ELPA pulls soap-client.el and soap-inspect.el from emacs.git's
> master branch.
>
> Let me know if you also want me to push the patch to
> https://github.com/alex-hhh/emacs-soap-client.
>
> Thomas

Message #76 received at 31742 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>, 31742-done <at> debbugs.gnu.org,
 31742 <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sat, 16 Jun 2018 21:36:58 -0400

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> * the soap-client web page on elpa.gnu.org has a link to the elpa.git
>   repository, but there is nothing there (the CGit and Gitweb links):
>   http://elpa.gnu.org/packages/soap-client.html

To clarify, the version served from elpa.gnu.org is from the emacs.git
repository.  See externals-list in the elpa.git repository:

;; List of packages that are maintained externally.
;; The list is made of elements of the form (NAME KIND URL OPTS...).
[...]
;; KIND can be one of:
[...]
;;  :core     = part of GNU Emacs repository.
[...]
("soap-client"		:core ("lisp/net/soap-client.el" "lisp/net/soap-inspect.el"))

Message #82 received at 31742-done <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alex Harsanyi <alexharsanyi <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 31742-done <at> debbugs.gnu.org
Subject: Re: bug#31742: 26.1.50;
 excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Sun, 17 Jun 2018 09:02:41 -0400

Hi Alex,

I pushed the patch and the 3.1.4 tag to
https://github.com/alex-hhh/emacs-soap-client.git so at least everything
is consistent again, except that the ELPA page doesn't point to
"Homepage".  I think that's a bug in GNU ELPA's generation scripts
though -- can you file a bug report for this?

As for repository organization, I'm fine with things as-is, I just have
to remember to push to GitHub anytime I push to emacs.git.

Right now the history is almost the same between emacs.git and
emacs-soap-client.git, and the files on the master branches are
identical.

Maybe in the future when elpa.git and emacs.git integration is better we
can use the elpa.git-separate-branch approach, and emacs.git will
automatically clone elpa.git as a submodule and everything will work in
core and for GNU ELPA updates.

In fact, soap-client is probably a good non-trivial package to
experiment with different Git organization approaches for such
core-and-GNU-ELPA packages.  There was a thread on emacs-devel about
this recently, in the context of adding BBDB to core.  I'm not working
on this Git integration effort directly right now, but I think some
people are from time to time.

Thomas

Alex Harsanyi <alexharsanyi <at> gmail.com> writes:

> Hi Thomas,
>
> I was not aware that the soap-client.el in the GNU Emacs source has been
> updated -- the maintainers at the time wanted a version that just worked with
> debbugs, and put the most recent version in ELPA.
>
> There are two inconsistencies with the current system, which can cause some
> confusion:
>
> * the soap-client web page on elpa.gnu.org has a link to the elpa.git
>   repository, but there is nothing there (the CGit and Gitweb links):
>   http://elpa.gnu.org/packages/soap-client.html
>
> * in the GNU Emacs source code, soap-client.el has a "Homepage" link that
>   points back to my GitHub repository, which is now out of date.
>
> I think we need to decide on where to keep the "official" development history
> for this package.  As I see it, there are a few options:
>
> * Keep it on GitHub, where it is now.  In this case, I think you should push
>   the patch and the 3.1.4 tag there, and the ELPA links need to be fixed.
>
> * Import it into elpa.git, as a separate branch (I see other packages are
>   maintained like that).  In this case, the "Homepage" link should be updated
>   to point to this source.
>
> * Keep it in the GNU Emacs source tree (this will loose the git history, but
>   maybe it is not important).  In this case the, both the "Homepage" link and
>   the ELPA web page should be updated.
>
> I have no strong preference for either option, apart for making it easier for
> people to know where to go for the package source.  If the GitHub repository
> is no longer the latest source code, I can archive it and point to the new
> location.
>
>
> Alex.
>
> On Sun, Jun 17, 2018 at 8:36 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>> Alex Harsanyi <alexharsanyi <at> gmail.com> writes:
>>
>>> On Tue, Jun 12, 2018 at 9:55 AM, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>>>
>>>> I added the comment, bumped the soap-client version to 3.1.4 and pushed
>>>> the patch to master so that GNU ELPA will be regenerated tonight.  I
>>>> also backported the patch to the emacs-26 branch since it fixes a
>>>> functional regression.
>>>
>>> Hi Thomas,
>>>
>>> Can you let me know where did you push the soap-client changes?
>>>
>>> I can see that the package was released at gnu.elpa.org, but the
>>> changes were not pushed either to the elpa.git repository at
>>> https://git.savannah.gnu.org/git/emacs/elpa.git, or to my own copy of
>>> it at https://github.com/alex-hhh/emacs-soap-client.
>>
>> I pushed it to the emacs.git master and emacs-26 branches:
>>
>> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1feb2e221349f26ec26bc684e0cce2acecbed3ca
>>
>> GNU ELPA pulls soap-client.el and soap-inspect.el from emacs.git's
>> master branch.
>>
>> Let me know if you also want me to push the patch to
>> https://github.com/alex-hhh/emacs-soap-client.
>>
>> Thomas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.