Adding (==)/2 to component theme: Auto linkify Prolog predicates

I like the new automatic link generation for predicate indicators.
But can it also detect a predicate indicators such as:

 (==)/2
1 Like

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.

1 Like

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.

1 Like

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).

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like
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 :slight_smile:

1 Like

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.

1 Like

It looks like the issue is the OPTIONS request it sends to preflight the POST, that’s returning a 400.

1 Like

@jamesnvc, since we get a summary, maybe that could be shown on hovering over the link? We’ll be the coolest discourse group around :grin:

2 Likes

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

Connecting telegram bot to discourse

1 Like

Should be working fine now. Please try again.

3 Likes

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 :confused:

1 Like

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)

2 Likes

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?

1 Like

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