elephants, openssl and clsql
My son has told us he wants to be an elephant when he grows up. It doesn't take much imagination to guess what he was for halloween.
Thankfully, we have finally burned through the three bags of halloween candy at work. I can go through a bag of candy like, well... like something that can eat an entire bag of candy in a couple days. There is NO MORE to eat.
Dustin added a monitor for the backend server this evening, so I can now get paged in the middle of the night when it goes down. If you haven't used it before, the openssl command-line tool comes in handy when you need to test ssl code. you can use the s_client and s_server options to make connections.
$ openssl s_client -connect 10.0.0.10:7777
In our case, Dustin just wrapped a call to openssl s_client and checked to make sure the server responds with an identification query as it should.
I frittered away the day it seems otherwise. I am still trying to work out what is wrong with our clsql code. Version 3.6.3 worked fine for us, but we are now getting a bunch of errors with 3.7.7 about [= being an unknown variable. Apparently there has been a change in the way that enable-sql-reader-syntax works, and our code is no longer doing the right thing to enable the use of the [ and ] macros.
While something changed to break our code with clsql, Marcus Pearce was kind enough to send along some pointers on how to get it working again. It may be that we were simply using the ENABLE-SQL-READER-SYNTAX incorrectly, and were lucky enough to have it working. We were able to reduce our issue down to a simple test-case, so we might hear back more on that front. In the mean time, I have used #.(clsql:locally-enable-sql-reader-syntax) and #.(clsql:restore-sql-reader-syntax-state) as suggested by Marcus at the beginning and end of all the files that use the brackets. It is not nearly as convenient as defining it in one location and having it work everywhere, but it works, and is backward compatible with the 3.6.3 version of clsql.