Fix that (setf *print-case* :downcase) breaks the server and that no webpages are accessible

[Dima-369]

Fix that (setf *print-case* :downcase) breaks the server and that no webpages are accessible

[aykaramba]

Aha! You are correct and great point. My apologies for the assumption.

[aykaramba]

Just for reference, I just setup CLOG on my Macbook to test this, and it works. Git cloned clog into my quicklisp folder, ran (clog:run-tutorial 1) and http://127.0.0.1:8080 came up in Firefox.

Do all the tutorials result in you not being able to see the localhost instance?
How about if you try to run any of the 4 demos with (clog:run-demo 1)?

[Dima-369]

How about if you try to run any of the 4 demos with (clog:run-demo 1)?

Same error on any tutorial or demo, I also tried chmod -R 777 local-projects/ since the files are located there. Firefox opens up automatically for me, but then throws the 404 error. I tried a different port like 8090 and same error. Oh well... Must be my configuration somewhere, maybe even unrelated to CLOG 😅

[aykaramba]

That is so interesting. It looks like the web server is listening but you cannot access it. That looks like your macOS firewall might be preventing all access to localhost? Have you been able to run other local web based interfaces before?

That might be one thing to look into.

The other thing you might want to look into is using virtualization to run a Linux vm on your Mac and install CLOG / CL on that as well.

[Dima-369]

That looks like your macOS firewall might be preventing all access to localhost? Have you been able to run other local web based interfaces before?

The Firewall is deactivated. I have no issue running PHP Apache on any port, even 80 or 8080. I suppose I need to check hunchentoot's logs.

The other thing you might want to look into is using virtualization to run a Linux vm on your Mac and install CLOG / CL on that as well.

Apparently this is not an option right now.

[aykaramba]

Huh. That is really weird. I don't know how that makes any sense. I am curious if the server is still running after the last bit of your error message or if it dies. Can you load up any of the tutorials and see if you can see either SBCL or whatever environment you are using to start up the tutorial (the Lem editor will show up as a Lem process as opposed to SBCL/Slime for example)?

Link to list of commands that can help you see if it is listening at all after startup: https://apple.stackexchange.com/questions/117644/how-can-i-list-my-open-network-ports-with-netstat

If CLOG is up and running and you can see the SBCL listening on 8080 (or whatever), can you try and telnet to it and see if it connects?

Example: telnet localhost 8080

Some troubleshooting that I sometimes do to see what is going on in situations like this.

[Dima-369]

Sure, it really seems that the server dies. I validated the ports via sudo lsof -PiTCP -sTCP:LISTEN. If I run (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)), then I can correctly connect and that port is shown as taken in the bash command.

My very first screenshot is actually faulty since I saw that my Emacs web server already uses port 8080, so the error message actually comes from Emacs and not from CLOG. But I tried other ports and they never connect, so telnet just throws http://127.0.0.1:9085: nodename nor servname provided, or not known.

Is there some logging capability in CLOG which gives more info or maybe logs to a file?

---

Oh boy, just after writing this, I tried running this in Lem. And behold, it actually worked (although the output is the same when I run it in SBCL with Sly):

Which makes me every more curious why it exactly fails in my Emacs Sly startup :D

[aykaramba]

Aha, so when you run it with Lem the server starts up and you can connect to it? Is that correct?

If that is the case, one of the things that I have as part of my troubleshooting routine is to clear out my ./cache/commonlisp directory if a problem like this comes up. I am on Linux and I don't know where macOS stores the common lisp cache files, however, whenever you are running a lisp image the system will cache all of that there. Check your system and consider removing your commonlisp cached files and trying again.

I am in the process of moving over to Lem and as it is currently still under heavy / early development sometimes the cache files get "corrupted" (not sure if they are actually corrupted really ...) and I just delete the common lisp cache files and restart and everything works again.

If Lem is working, try clearing out the common lisp cache and try Emacs/Sly once again. Be careful not to nuke your other .cache files, I don't know what macOS likes to do these days as I am purely Linux.

[aykaramba]

Oh, as for log files, I'm pretty much a noob at Lisp and Hunchentoot and don't know how that is handled. The Hunchentoot docs that you obviously already looked at have some info on logging facilities but I don't know how to turn them on: http://edicl.github.io/hunchentoot/#logging

I have not had to use logging my self yet, I am in the process of learning Common Lisp and getting my head wrapped around the debugger messages and how it all fits together. I was going to look into logging once I had my todo app in some usable shape though.

If you manage to get logging working, would you mind posting to the discussion forum so that I / others can check it out?

[Dima-369]

Thank you for your help, even though are inexperienced :)

I figured out the issue why it works in Lem and why it doesn't in SBCL.

My .sbclrc contains this: (setf *print-case* :downcase) which breaks Clog somehow. If I remove it, all is well and I can access the demos and tutorials properly in the browser. Renaming the issue title...

[aykaramba]

Oh interesting. I will keep that in mind. Thx.

If the issue is resolved, we should be closing tickets. Our friendly neighbourhood Rabbi is quite busy and the less unnecessary noise for him the better we can make his experience, I feel.

[Dima-369]

If the issue is resolved, we should be closing tickets.

Well, in a way the issue is not resolved. I reported the (setf *print-case* :downcase) issue to another Common Lisp library on Github some time ago and it had to be fixed in the sources.

Changing the *print-case* should not affect behavior negatively and I definitely would like to see this resolved. It's not high priority at all, since we know of a hotfix but someone else can and will stumble upon this when he runs CLOG with a non default *print-case*, so I would like to keep this open (and I just really like using (setf *print-case* :downcase)).