Menu
▾
▴
clisp-devel
|
From: Bruno H. <br...@cl...> - 2017-08-22 00:47:33
|
As a consequence of the move from http://clisp.sourceforge.net/ to https://clisp.sourceforge.io/ the function DESCRIBE is now broken: [1]> (describe nil) NIL is the empty list, the symbol NIL, lies in #<PACKAGE COMMON-LISP>, is accessible in 11 packages CLOS, COMMON-LISP, COMMON-LISP-USER, EXPORTING, EXT, FFI, POSIX, READLINE, REGEXP, SCREEN, SYSTEM, a constant, value: NIL, names a type, names a built-in foreign type, has 2 properties SYSTEM::INSTRUCTION, SYSTEM::TYPE-SYMBOL ;; connecting to "http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Data/Map_Sym.txt"...connected...HTTP/1.1 404 Not Found ;; "Date: Tue, 22 Aug 2017 00:39:06 GMT" ;; "Server: Apache/2.4.7 (Ubuntu)" ;; "Content-Length: 253" ;; "Connection: close" ;; "Content-Type: text/html; charset=iso-8859-1" ;; "" ;; "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">" ;; "<html><head>" ;; "<title>404 Not Found</title>" ;; "</head><body>" ;; "<h1>Not Found</h1>" ;; "<p>The requested URL /projects/iiip/doc/CommonLISP/HyperSpec/Data/Map_Sym.txt was not found on this server.</p>" ;; "</body></html>" ;; connecting to "http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Data/Symbol-Table.text"...connected...HTTP/1.1 200 OK...45,322 bytes ;; SYSTEM::GET-CLHS-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER www.ai.mit.edu:80>)...978/978 symbols . ANSI-CL Documentation is at "http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/any_nil.html" ;; connecting to "http://clisp.org/impnotes/id-href.map"...connected...HTTP/1.1 301 Moved Permanently --> "https://clisp.sourceforge.io/impnotes/id-href.map" ;; connecting to "http://clisp.orghttps://clisp.sourceforge.io/impnotes/id-href.map"... *** - PARSE-INTEGER: substring "" does not have integer syntax at position 0 The following restarts are available: ABORT :R1 Abort main loop It looks like an invalid URL "http://clisp.orghttps://clisp.sourceforge.io/impnotes/id-href.map" was constructed (maybe in clhs.lisp?). Bruno |
|
From: Lucas B. <luc...@gm...> - 2017-08-22 14:13:21
|
On Mon, Aug 21, 2017 at 9:47 PM, Bruno Haible <br...@cl...> wrote: > As a consequence of the move from http://clisp.sourceforge.net/ > to https://clisp.sourceforge.io/ the function DESCRIBE is now broken: Hello. I'm newbie in Lisp, but this error looked interesting, so I went to take a look at src/clhs.lisp. I wonder if there's some problem in the function open-http, around line 198: https://sourceforge.net/p/clisp/clisp/ci/default/tree/src/clhs.lisp#l198 It seems to expect an URL with prefix "http://" but a secure URL with prefix "https://" is found in the "Location:" header instead, so it ends up concatenating the strings: (unless (string-equal #1# new-url :end2 (min (length new-url) #2#)) (setq new-url (string-concat #1# host new-url))) |
|
From: Pascal B. <pj...@in...> - 2017-08-22 14:43:41
|
> On 22 Aug 2017, at 16:13, Lucas Buchala <luc...@gm...> wrote: > > On Mon, Aug 21, 2017 at 9:47 PM, Bruno Haible <br...@cl...> wrote: >> As a consequence of the move from http://clisp.sourceforge.net/ >> to https://clisp.sourceforge.io/ the function DESCRIBE is now broken: > > Hello. I'm newbie in Lisp, but this error looked interesting, so I > went to take a look at src/clhs.lisp. > > I wonder if there's some problem in the function open-http, around line 198: > https://sourceforge.net/p/clisp/clisp/ci/default/tree/src/clhs.lisp#l198 > > It seems to expect an URL with prefix "http://" but a secure URL with > prefix "https://" is found in the "Location:" header instead, so it > ends up concatenating the strings: > > (unless (string-equal #1# new-url > :end2 (min (length new-url) #2#)) > (setq new-url (string-concat #1# host new-url))) Indeed, instead it should test for urls with a scheme prefix! (Any scheme!) Schemes are [A-Za-z][-+.A-Za-z0-9]* followed by a colon. So if the string matches ^[A-Za-z][-+.A-Za-z0-9]*: then it contains a scheme and it should not be considered a path, but a whole URI. https://en.wikipedia.org/wiki/Uniform_Resource_Identifier -- __Pascal J. Bourguignon__ |
|
From: Bruno H. <br...@cl...> - 2017-08-22 20:05:41
|
Lucas Buchala wrote: > It seems to expect an URL with prefix "http://" but a secure URL with > prefix "https://" is found in the "Location:" header instead, so it > ends up concatenating the strings: And clisp does not yet have a https client. More and more of the web switches over from http to https. It was easy to write an http client in a couple of lines of code (like in clhs.lisp). But for https, one needs SSL support with all its intricacies (TLS protocol versions, certificate checking etc.). Anyone wants to contribute a clisp module that implements a http/https client? It's not needed to write the code from scratch; such code already exists (under usable licenses). According to [1], the most compelling choices would be: * drakma * drakma-async, based on cl-async, itself based on libuv. Any takers? Bruno [1] http://www.cliki.net/HTTP%20client |
|
From: Bruno H. <br...@cl...> - 2017-09-20 23:15:44
|
We have three problems. Here's what I plan to do about them. 1) The DESCRIBE function makes accesses to https://clisp.org/. This has drawbacks: - The user cannot do DESCRIBE when an internet connection is not available. - The documentation that the user accesses does not match the version of clisp she is using. - https access is currently not implemented in clisp. - It violates the user's privacy if other parties can infer by sniffing what documentation she is accessing. Proposed solution: Let clisp use the *installed* documentation (packaged with clisp). => No network accesses in this case. For "make check" to work before clisp is installed, add a command-line option that specifies the location of the doc. (Like option '-N'.) 2) https access is currently not implemented in clisp. But the web consists of more and more https. For https, one needs SSL support with all its intricacies (TLS protocol versions, certificate checking etc.). I'm no longer in favour of including something like Drakma in clisp. Instead, I believe we need to distinguish the bottom layer (SSL) and the layer sitting on top of it (https). Given SSL, https can well be done in Lisp. However, the SSL support ought to use a system-wide standard facility and the system-wide certificates (/usr/share/ca-certificates/mozilla/ on some systems) - otherwise revocations won't be handled right. This leaves us with three options: - GNUTLS, - openssl, - CL+SSL, which is based on openssl. I'll go with GNUTLS in the first place, and openssl as fallback (for portability). Since SSL cannot be applied to random streams, pipe streams, etc., but only to socket streams, the result will be a variant of SOCKET-STREAMs in clisp. 3) The DESCRIBE function makes accesses to the CLHS on the web. This has drawbacks: - The user cannot do DESCRIBE when an internet connection is not available. - It violates the user's privacy if other parties can infer by sniffing what documentation she is accessing. Proposed solution: Add a facility through which the user can download and install the complete CLHS on their system once; this requires acknowledging a license. Cf. [1] Comments? Bruno [1] https://stackoverflow.com/questions/23676164/viewing-the-common-lisp-hyperspec-offline-via-emacs |
|
From: <don...@is...> - 2017-09-21 01:33:07
|
Bruno Haible writes: > We have three problems. Here's what I plan to do about them. > > 1) The DESCRIBE function makes accesses to https://clisp.org/. This > has drawbacks: > - The user cannot do DESCRIBE when an internet connection is not > available. He can, but currently gets an error - perhaps that should be caught. > - The documentation that the user accesses does not match the version > of clisp she is using. That could be fixed just by including the version in the url and keeping multiple versions on the server. > - https access is currently not implemented in clisp. (discussed below) > - It violates the user's privacy if other parties can infer by sniffing > what documentation she is accessing. I don't think describe should be accessing the net without the user explicitly asking it to, and if the user does choose to then he can also choose whether to use http or https. > Proposed solution: > Let clisp use the *installed* documentation (packaged with clisp). I don't see why it is necessary for describe to show documentation that is not part of the run time environment. You could supply extra functions for looking up doc and possibly even mention them in describe output, for instance if you're describing an external symbol in ext or lisp packages. > => No network accesses in this case. > For "make check" to work before clisp is installed, add a command-line > option that specifies the location of the doc. (Like option '-N'.) > > 2) https access is currently not implemented in clisp. But the web consists > of more and more https. > For https, one needs SSL support with all its intricacies (TLS protocol > versions, certificate checking etc.). I've used stunnel to solve this problem for a long time. It seems perfectly adequate and also reasonable. I don't know whether it's supported on all clisp platforms. There are millions of things that you MIGHT want to do that are not built into clisp. (Some of them are even not built into java.) I don't see anything wrong with using some external software to do them from clisp. > I'm no longer in favour of including something like Drakma in clisp. > Instead, I believe we need to distinguish the bottom layer (SSL) and the > layer sitting on top of it (https). Given SSL, https can well be done in > Lisp. However, the SSL support ought to use a system-wide standard facility > and the system-wide certificates (/usr/share/ca-certificates/mozilla/ on > some systems) - otherwise revocations won't be handled right. This leaves us > with three options: > - GNUTLS, > - openssl, > - CL+SSL, which is based on openssl. > > I'll go with GNUTLS in the first place, and openssl as fallback (for > portability). > > Since SSL cannot be applied to random streams, pipe streams, etc., but > only to socket streams, the result will be a variant of SOCKET-STREAMs > in clisp. > > 3) The DESCRIBE function makes accesses to the CLHS on the web. This has > drawbacks: > - The user cannot do DESCRIBE when an internet connection is not > available. > - It violates the user's privacy if other parties can infer by sniffing > what documentation she is accessing. > > Proposed solution: > Add a facility through which the user can download and install the > complete CLHS on their system once; this requires acknowledging a license. > Cf. [1] Actually I do like that idea. I've long kept local copies of both clhs and impnotes to view while developing lisp code. I've always viewed them in browsers, though, not emacs. > Bruno > > [1] https://stackoverflow.com/questions/23676164/viewing-the-common-lisp-hyperspec-offline-via-emacs |
|
From: Bruno H. <br...@cl...> - 2017-09-21 02:00:26
|
Don Cohen wrote: > > 2) https access is currently not implemented in clisp. But the web consists > > of more and more https. > > For https, one needs SSL support with all its intricacies (TLS protocol > > versions, certificate checking etc.). > > I've used stunnel to solve this problem for a long time. > It seems perfectly adequate and also reasonable. stunnel is a daemon, right? What is the point of having a separate process, for something that most programs do through library code? Daemons are a hassle: if they are owned by the system, it requires privileges to start them; if not, the functionality breaks when the daemon happens to have crashed. Bruno |
|
From: <don...@is...> - 2017-09-21 04:09:47
|
Bruno Haible writes: > Don Cohen wrote: > > > 2) https access is currently not implemented in clisp. But the web consists > > > of more and more https. > > > For https, one needs SSL support with all its intricacies (TLS protocol > > > versions, certificate checking etc.). > > > > I've used stunnel to solve this problem for a long time. > > It seems perfectly adequate and also reasonable. > > stunnel is a daemon, right? What is the point of having a separate process, > for something that most programs do through library code? Most programs do this? By using calls to the openssl library? I have no idea what's involved. If it's easy, go ahead. > Daemons are a hassle: if they are owned by the system, it requires privileges > to start them; if not, the functionality breaks when the daemon happens to > have crashed. I'd guess that a user can run stunnel if it only has to allocate user ports. If you want to listen on port 443 you're going to need the same privileges to do that in clisp as you would need to start stunnel listening there. I don't remember off hand ever seeing stunnel crash. |
|
From: Jean L. <bu...@gn...> - 2017-09-21 04:54:30
|
On Thu, Sep 21, 2017 at 01:15:32AM +0200, Bruno Haible wrote: > We have three problems. Here's what I plan to do about them. > > 1) The DESCRIBE function makes accesses to https://clisp.org/. This > has drawbacks: > - The user cannot do DESCRIBE when an internet connection is not > available. > - The documentation that the user accesses does not match the version > of clisp she is using. > - https access is currently not implemented in clisp. > - It violates the user's privacy if other parties can infer by sniffing > what documentation she is accessing. > > Proposed solution: > Let clisp use the *installed* documentation (packaged with clisp). > => No network accesses in this case. > For "make check" to work before clisp is installed, add a command-line > option that specifies the location of the > doc. (Like option '-N'.) That is good idea. It also does not need to access HTML files with http:// as one can simply use the file:// facility instead. The local documentation gives references to the version that user is using. I also think that using a browser is overburden, maybe documentation could be made in similar fashion various Emacs documentation, maybe something as Texinfo so that specific sections may be accessed much easier, either through Emacs or info program. > 2) https access is currently not implemented in clisp. But the web consists > of more and more https. > For https, one needs SSL support with all its intricacies (TLS protocol > versions, certificate checking etc.). > > I'm no longer in favour of including something like Drakma in clisp. > Instead, I believe we need to distinguish the bottom layer (SSL) and the > layer sitting on top of it (https). Given SSL, https can well be done in > Lisp. However, the SSL support ought to use a system-wide standard facility > and the system-wide certificates (/usr/share/ca-certificates/mozilla/ on > some systems) - otherwise revocations won't be handled right. This leaves us > with three options: > - GNUTLS, > - openssl, > - CL+SSL, which is based on openssl. > > I'll go with GNUTLS in the first place, and openssl as fallback (for > portability). > > Since SSL cannot be applied to random streams, pipe streams, etc., but > only to socket streams, the result will be a variant of SOCKET-STREAMs > in clisp. With local documentation there is no need for any HTTP connection, as file:// facility would simply be enough. It also works with HTML anchors. > 3) The DESCRIBE function makes accesses to the CLHS on the web. This has > drawbacks: > - The user cannot do DESCRIBE when an internet connection is not > available. > - It violates the user's privacy if other parties can infer by sniffing > what documentation she is accessing. > > Proposed solution: > Add a facility through which the user can download and install the > complete CLHS on their system once; this requires acknowledging a license. > Cf. [1] > > Comments? GNU software or free software shall not drive the users to non-free documentation in my opinion, it shall not drive users to accept non-free license and download the HTML that is non-free. I think there is free version being made and other sources for documentation. Maybe something like http://clqr.boundp.org/source.html Something like this maybe: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/0.html Or like this http://jtra.cz/stuff/lisp/sclr/index.html It is better putting effort to make a free documentation for Common Lisp and provide such to users. Jean |
|
From: Bruno H. <br...@cl...> - 2017-09-21 14:05:27
|
Jean Louis wrote: > I think there is free version being made and other > sources for documentation. > > Maybe something like > http://clqr.boundp.org/source.html This text covers between 5% and 10% of CL. Development stopped 2 years ago. > Something like this maybe: > http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/0.html This text is not a good basis for free documentation. It was taken (stolen, you might say) from the ANSI standardization without permission by the ANSI bodies. Maybe it is not legal to distribute it at all. Later, Kent Pitman negotiated the license of what would become the CLHS with ANSI. > Or like this > http://jtra.cz/stuff/lisp/sclr/index.html This text covers between 1% and 3% of CL. > It is better putting effort to make a free > documentation for Common Lisp and provide such to > users. > ... > GNU software or free software shall not drive the > users to non-free documentation in my opinion I disagree. Of course, it would be better if ANSI CL would have been distributed as free documentation; this would have made it possible for the clisp documentation to be distributed as a single coherent body - rather than as an "implementation notes" part that refers to a standard in hundreds of places. But the fact is: * The unity of Common Lisp (i.e. the similarity of behaviour of Common Lisp implementations, which translates to portability of Lisp code) is caused by the fact that people (especially the users) *can* and *do* look at the CLHS frequently. Therefore you do NOT serve the users if you tell them not to look at the CLHS. * Through the pointers that you have given above, you have shown that creating a free Common Lisp documentation is a multi- person*year effort, that none of the existing projects are going to achieve in the next 10 years. Bruno |
|
From: Jean L. <bu...@gn...> - 2017-09-21 14:10:44
|
I understand that users are looking into documentation. I am too. There is some free reference but I could not yet find it. It shall be starting point for future even if it cannot be done right now. It is GNU software, it shall not download the non free stuff. Reading and browsing fine, but no need to ask them to accept the non free license. On September 21, 2017 5:05:16 PM GMT+03:00, Bruno Haible <br...@cl...> wrote: >Jean Louis wrote: >> I think there is free version being made and other >> sources for documentation. >> >> Maybe something like >> http://clqr.boundp.org/source.html > >This text covers between 5% and 10% of CL. Development stopped 2 years >ago. > >> Something like this maybe: >> >http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/0.html > >This text is not a good basis for free documentation. It was taken >(stolen, >you might say) from the ANSI standardization without permission by the >ANSI bodies. Maybe it is not legal to distribute it at all. Later, Kent >Pitman negotiated the license of what would become the CLHS with ANSI. > >> Or like this >> http://jtra.cz/stuff/lisp/sclr/index.html > >This text covers between 1% and 3% of CL. > >> It is better putting effort to make a free >> documentation for Common Lisp and provide such to >> users. >> ... >> GNU software or free software shall not drive the >> users to non-free documentation in my opinion > >I disagree. Of course, it would be better if ANSI CL would have been >distributed as free documentation; this would have made it possible >for the clisp documentation to be distributed as a single coherent >body - rather than as an "implementation notes" part that refers to >a standard in hundreds of places. > >But the fact is: > * The unity of Common Lisp (i.e. the similarity of behaviour of > Common Lisp implementations, which translates to portability of > Lisp code) is caused by the fact that people (especially the > users) *can* and *do* look at the CLHS frequently. > Therefore you do NOT serve the users if you tell them not to > look at the CLHS. > * Through the pointers that you have given above, you have shown > that creating a free Common Lisp documentation is a multi- > person*year effort, that none of the existing projects are > going to achieve in the next 10 years. > >Bruno |
|
From: Sam S. <sd...@gn...> - 2017-09-25 19:44:44
|
> * Bruno Haible <oe...@py...t> [2017-09-21 01:15:32 +0200]: > > 1) The DESCRIBE function makes accesses to https://clisp.org/. > 3) The DESCRIBE function makes accesses to the CLHS on the web. Both are easily overridable by user variables, either at ./configure time or in ~/.clisp.lisp or on the fly. They are supposed to be set in config.lisp by the distributor, who is supposed to be packaging the docs and clisp. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://jij.org http://camera.org http://iris.org.il https://ffii.org http://no2bds.org Let us remember that ours is a nation of lawyers and order. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X