I like the new automatic link generation for predicate indicators.
But can it also detect a predicate indicators such as:
(==)/2
I like the new automatic link generation for predicate indicators.
But can it also detect a predicate indicators such as:
(==)/2
I would not expect that at present. The code is public and while I forgot to note it in earlier post there is Theme Creator - a place where anyone can hack on themes without installing Discourse.
You should check with @jamesnvc if you desire to make changes since his code is what is currently running.
I tried making a change that should allow that, but I think it will require a change on @janās end as well for the endpoint to check if a predicate exists ā currently it seems that a GET to āhttps://www.swi-prolog.org/doc_link?for=(%3D%3D)/2ā gives 404.
This works fine: https://www.swi-prolog.org/doc_link?for===/2 (you can also use %3D for the latter two =s). The parsing simple breaks over / / or /, demanding the remainder to be an integer. Possibly I should first try parsing as a Prolog term?
As for performance, I can add a POST, so you can post a list of predicates. I see too sensible interfaces: POST JSON as an array of strings or post an plain text document with one candidate per line. Guess JSON is preferred? Note that the compute time at the server is way below 1ms and almost all time goes to round trip networking and a bit HTTP processing (get about 7ms response time locally).
Ah, okay. I can change my script thing to remove the parentheses then, easy enough change on my end.
That seems reasonable. A JSON array would work, but either way is fine. Ideally, Iād be able to tell the component that the theme needs to block, but I donāt know if thatās possible. I will look into that though.
If the theme blocks would it suspend the ui? If so, Iād prefer the asynchronous way, so that I can continue looking at the preview and editing the post.
Okay, that should work now. It might take a little bit to show up, for the weird async reasons, but (==)/2, (<)/2, etc should show as links now.
curl --header "Content-Type: application/json" \
--request POST \
--data '["member/2", "==/2", "unknown/27"]' \
https://www.swi-prolog.org/doc_link
Now replies
{
"==/2": {
"class":"iso",
"summary":"True if Term1 is equivalent to Term2.",
"url":"https://www.swi-prolog.org/pldoc/doc_for?object===/2"
},
"member/2": {
"class":"autoload",
"library":"lists",
"summary":"True if Elem is a member of List.",
"url":"https://www.swi-prolog.org/pldoc/doc_for?object=member/2"
},
"unknown/27":null
}
I think this is way better scalable
Ah, issue now is that with a POST, it requires CORS headers. @jan, would you be able to make it send the access-control-allow-origin & -method headers?
It sends access-control-allow-origin: *
. Guess they also want the method? Afraid I have to cook first. Probably tomorrow. Sorry ā¦
No problem! Iāll look into it more on my end too, see if thereās anything else I can do.
It looks like the issue is the OPTIONS request it sends to preflight the POST, thatās returning a 400.
@jamesnvc, since we get a summary
, maybe that could be shown on hovering over the link? Weāll be the coolest discourse group around
There are some pretty cool groups out there already. I havenāt checked out the gamer Discourse sites, but they tend to push the limits of Discourse as far as layout and skins, the health ones are heaving into categories, many like combing WordPress, the photography ones donāt even look like Discourse with all the pictures and there are some related to programming languages, https://forums.swift.org/ and https://users.rust-lang.org/.
I think once we achieve self-hosting and get the docs, SWISH and this Discourse forum all working in harmony, and possibly even starting to replace Ruby-on-Rails with SWI-Prolog then we can achieve greatness and even nerdiness.
EDIT
Here is a user who created a bot using PHP and the Discourse API webhooks. Once we self-host the same could be done using SWI-Prolog and Discourse API webhooks
Should be working fine now. Please try again.
Hm, it looks like the OPTIONS is succeeding, but now the POST doesnāt have CORS headers set? As far as I can tell, it needs both do work
Might work now. Note that the CDN caches for 1 hour, so you may need to check with one of the backends (eu.swi-prolog.org or us.swi-prolog.org)
Okay! Seems to be working now. I have it pointed directly to eu.swi-prolog.org
for now, as it seems like the OPTIONS request to us.swi-prolog.org
doesnāt give the CORS headers (which made going directly through www.swi-prolog.org very confusing, as it would sometimes work & sometimes fail). I assume the āusā server just needs a bit of time to get the new code?
Should be ok now.
Hm, I still see different responses from eu. & us.:
EU:
curl -X OPTIONS --verbose https://eu.swi-prolog.org/doc_link
...
< HTTP/1.1 200 OK
< Server: nginx/1.14.0 (Ubuntu)
< Date: Sun, 31 May 2020 14:41:28 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< Set-Cookie: swipl_session=5d43-02e7-ef3b-28ac.swipl; path=/; version=1; samesite=lax
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST
<
* Connection #0 to host eu.swi-prolog.org left intact
US:
curl -X OPTIONS --verbose https://us.swi-prolog.org/doc_link
< HTTP/1.1 200 OK
< Date: Sun, 31 May 2020 14:42:52 GMT
< Content-Type: text/plain; charset=UTF-8
< Connection: Keep-Alive
< Set-Cookie: swipl_session=86e5-0e9a-3225-6a42.swi-prolog; path=/; version=1; samesite=lax
< Content-Length: 0
<
* Connection #0 to host us.swi-prolog.org left intact