bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in


From: Thomas Fitzsimmons
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

Alex Harsanyi <alexharsanyi@gmail.com> writes:

> On Fri, Jun 8, 2018 at 10:18 PM, Thomas Fitzsimmons <fitzsim@fitzsim.org> 
> wrote:
>> (CCing Alex Harsanyi.)
>>
>> Noam Postavsky <npostavs@gmail.com> writes:
>>
>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>>>
>>>> Noam Postavsky <npostavs@gmail.com> writes:
>>>>
>>>>> Thomas Fitzsimmons <fitzsim@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@cisco. [...]
  fsm-update(fsm-exco--fsm-47 :retrieving-data (:identifier 
("fitzsim@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]