Closed mnsanghvi closed 7 years ago
Hi, I've been unresponsive, sorry. Github does not send me email updates for a reason unknown to me. I've got a couple weeks of uni exams ahead so I'll only have so much time to look into forecast.el, so I'd appreciate a patch or a detailed report. This probably has something to do with the function forecast--get-forecast
though, see the call to apply
in that function. I don't have any proxies at hand that I can use so I can't test, but if that call is fixed (signal needs 2 args, gets 3), the actual problem will become visible.
Focus on the exams and good luck on them. I'll try and see if I can debug it if I have time and document it here as much as possible.
This is what signal
is getting
signal(error http 500)
apply(signal (error http 500))
but it should be doing something like (signal error '(http 500))
(my lisp is bad, I know.) As you can tell from the documentation below, signal
should get two arguments, but as shown by the edebug output above, it is getting 3 arguments.
signal is a built-in function in ‘C source code’.
(signal ERROR-SYMBOL DATA)
Signal an error. Args are ERROR-SYMBOL and associated DATA. This function does not return.
An error symbol is a symbol with an ‘error-conditions’ property that is a list of condition names. A handler for any of those names will get to handle this signal. The symbol ‘error’ should normally be one of them.
DATA should be a list. Its elements are printed as part of the error message. See Info anchor ‘(elisp)Definition of signal’ for some details on how this error message is constructed. If the signal is handled, DATA is made available to the handler. See also the function ‘condition-case’.
Hi @mnsanghvi, could you please try applying the attached patch? It should take us to the next step.
@cadadr, stupid question but where is the patch ? I didn't see any that was attached to your comment, or to the issue.
@mnsanghvi Oh please excuse me, I replied to you via mail, the github comments system has removed the attachment. Didn't know that it behaved that way. Here it is:
--- forecast.el.~1.11.~ 2016-12-19 12:39:43.834369000 +0300
+++ forecast.el 2016-12-30 19:21:21.292727000 +0300
@@ -366,7 +366,7 @@ representation of the returned JSON from
(ignore args)
(let ((err (plist-get status :error)))
(when err
- (apply 'signal err)))
+ (funcall 'signal (car err) (cdr err))))
(save-excursion
(goto-char (point-min))
(re-search-forward "^{")
Just put this in a file in the directory where your copy of forecast.el is located, then run patch < FILENAME
, replacing FILENAME with the name you used, in that same directory.
Applying the patch gives me the following:
peculiar error: 500
I am getting the following from my proxy server:
The SSL handshake could not be performed. Host: api.darksky.net Reason: Can't initialize server context:EnduserException:server state 1:state 8:Application response 500 handshake failed
That is the "data" part of the call to url-http-generic-filter
.
If I paste the following URL:
https://api.darksky.net/forecast/[api-key]/[latitude],[longitude]
in the web browser, which also passes everything to the proxy server, I get a page full of JSON data regarding the weather as expected.
Hi @mnsanghvi,
I just tried this with a test proxy that I set up w/ tiniproxy [1] with a minimal config:
forecast.el worked okay, no errors. Could it have anything to do with your proxy settings?
,----[ tini.conf ]
| User xxx
| Group xxx
| Timeout 600
| Port 8888
| LogFile "/tmp/tinilog"
| SysLog Off
| LogLevel Info
| PidFile "/tmp/tinipid"
| MaxClients 100
| MinSpareServers 5
| MaxSpareServers 10
| StartServers 5
| MaxRequestsPerChild 0
`----
I tried it with tinyproxy
as well and got the following:
Debugger entered--Lisp error: (wrong-number-of-arguments signal 3)
signal(error http 403)
apply(signal (error http 403))
#[513 "\301\302\"\211\203
\303\304\"\210\210\212eb\210\305\306!\210\307 \210\300\310`d{!!)\207" [#[257 "\211\303\304!\210\305\306\307 \"!\300 \207" [#[0 "\300\301!\302!\207" [forecast--make-buffer "*Weather Forecast*" switch-to-buffer] 3] forecast--data forecast--update-time message "Forecast: updated data." seconds-to-time forecast--assoca (currently time)] 5 "\n\n(fn W)"] plist-get :error apply signal re-search-forward "^{" beginning-of-line json-read-from-string] 6 "\n\n(fn STATUS &optional ARGS)"]((:error (error http 403)))
apply(#[513 "\301\302\"\211\203
\303\304\"\210\210\212eb\210\305\306!\210\307 \210\300\310`d{!!)\207" [#[257 "\211\303\304!\210\305\306\307 \"!\300 \207" [#[0 "\300\301!\302!\207" [forecast--make-buffer "*Weather Forecast*" switch-to-buffer] 3] forecast--data forecast--update-time message "Forecast: updated data." seconds-to-time forecast--assoca (currently time)] 5 "\n\n(fn W)"] plist-get :error apply signal re-search-forward "^{" beginning-of-line json-read-from-string] 6 "\n\n(fn STATUS &optional ARGS)"] (:error (error http 403)))
url-http-activate-callback()
url-http-end-of-document-sentinel(#<process 192.168.70.1> "connection broken by remote peer\n")
url-http-async-sentinel(#<process 192.168.70.1> "connection broken by remote peer\n")
read-event(nil t 2)
sit-for(2)
execute-extended-command(nil "forecast" nil)
funcall-interactively(execute-extended-command nil "forecast" nil)
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
I used the default settings for tinyproxy, so they are the same as what you have I believe. But here is the config file I used:
User nobody
Group nogroup
Port 8888
Timeout 600
DefaultErrorFile "/usr/share/tinyproxy/default.html"
StatFile "/usr/share/tinyproxy/stats.html"
Logfile "/var/log/tinyproxy/tinyproxy.log"
LogLevel Info
PidFile "/run/tinyproxy/tinyproxy.pid"
MaxClients 100
MinSpareServers 5
MaxSpareServers 20
StartServers 10
MaxRequestsPerChild 0
Allow 127.0.0.1
ViaProxyName "tinyproxy"
ConnectPort 443
ConnectPort 563
My url-proxy-services
setup is as below:
url-proxy-services is a variable defined in ‘url-vars.el’.
Its value is (("ftp" . "192.168.70.1:8888")
("http" . "192.168.70.1:8888")
("https" . "192.168.70.1:8888"))
I can now reproduce this issue (probably my config was erroneous previously), but I don't know if the URL package itself causes the trouble or is forecast's code is buggy. Though maybe it's to do with the fact that the connection to the API is over HTTPS protocol, as with proxy on, I cannot connect to other HTTPS sites through EWW too (shows a ‘501 Not Implemented’ error page), but can connect to HTTP ones. This happens both when I set the proxy through environment variables and when I set the ‘url-proxy-services’ variable.
I suggest that you try to connect to an HTTPS site (e.g. https://google.com) through the proxy w/ EWW and if you experience the same maybe report the issue to Emacs bug tracker. I really don't know much about proxies, but it seems to me that the trouble is caused elsewhere than forecast.el as EWW suffers from it too.
Please inform me about how you'll proceed so that I'll know whether or not to close this issue.
With proxy enabled, I am unable to reach HTTPS web sites using EWW. So this does not look like a forecast.el issue at the moment.
I am closing the issue for now. If needed, this can be re-opened at a later date.
I'm sorry that I couldn't help solving your issue. Please do give me an update if you get it working, so that I can fix the code / update the docs accordingly. All the best!
I have the following set in my
~/.emacs
and now I am not able to update the
*Weather Forecast*
buffer anymore. Anything else that uses the internet (tramp
,package-list-packages
,magit
, etc.) works just fine.What I see in the
*Messages*
buffer is the followingI'll see if I can get more information.