My developer colleague, Fabio di Paola, has done some experimenting with ChatGPT and he successfully used it with LotusScript.
He published an article, in Italian, on our blog, here.
To save you the hassle of translating, here it is in English:
OpenAI.com’s ChatGpt is kind of the main topic of the last few months, we’ve all tried to use it and we’re thinking about how to use it in real cases. Precisely in the light of these considerations, the first question we asked ourselves was “but will I be able to use it within a Domino application?”
The answer is Yes , it can be done : we are investigating it these days and the first results are positive ; It’s true that sometimes, from theory to practice, surprises are always discovered and therefore the last word is never said, but here I feel optimistic. LotusScript can query ChatGpt and receive its response.
OpenAi has released APIs to connect to ChatGpt but, at least for now, they are limited to Python and node.js . In addition several communities have already published code libraries to connect to ChatGpt from other languages. It’s hard to think that something like this will ever be done for LotusScript .
But going to see how the calls are made and trying to experiment on the ChatGpt playground you can understand the mechanisms that underlie the calls to ChatGpt.
The first thing needed, regardless of the code used, is the API key for authentication: this is obtained by registering on the site and then going to the details of your account under ApiKeys It is a string of 51 characters which must then be passed to every call.
At this point I started building a first prototype in LotusScript, the main parts are two:
The NotesHTTPRequest class to send the request and get the response
The construction of the Json to be sent and then the parsing of the return Json
For the NotesHttpRequest there is little to say, just remember that the API key must be managed as a header of the request.
For the Json part there are obviously various possibilities to build it and then to parse it, obviously the important thing is to follow the ChatGpt rules: here too, using the playground you can easily understand how to build it, which parameters to pass and how.
At the end of all what I got is a form in which to enter the question with a button that sends it, parses the answer and writes the answer itself in a field below, all using only LotusScript :
I add a curiosity: among the questions I asked ChatGpt I asked if he knows LotusScript (with an affirmative answer) and then I asked if he could write me the LotusScript code to send requests to ChatGpt. Again the answer was yes but the code he gave me had several errors.
I replied pointing out the various errors and corrections were proposed to me which were equally incorrect. As far as I understand at the moment ChatGpt doesn’t “learn” from its mistakes, so it’s possible that asking it the same questions again will result in the same errors.
I set up the monitoring dashboard in Sametime, using the provided JSON files; in case you don’t know how to do that, you enable it running this command
Today I discovered that my Prometheus container kept crashing, and in the logs I found lines like these:
corrupted block 01GQT2R33ASC29W57NF4WEZKP3: open data/01GQT2R33ASC29W57NF4WEZKP3/chunks: no such file or directory; corrupted block 01GQW0HNMW76WDHNY6T8CMEVQ0: open data/01GQW0HNMW76WDHNY6T8CMEVQ0/chunks: no such file or directory; corrupted block 01GQGDRDRKSS062T1762WACX5H: open data/01GQGDRDRKSS062T1762WACX5H/chunks: no such file or directory; corrupted block 01GQJBHXKJW38754FR7CZGTWZN: open data/01GQJBHXKJW38754FR7CZGTWZN/chunks: no such file or directory; corrupted block 01GQM9BGT78HDQXM2EZ2BP5P8S: open data/01GQM9BGT78HDQXM2EZ2BP5P8S/chunks: no such file or directory; corrupted block 01GQP75073Q7FRW2MEGE1T5869: open data/01GQP75073Q7FRW2MEGE1T5869/chunks: no such file or directory; corrupted block 01GQR4YKN8XJS7FY30VYR24VTG: open data/01GQR4YKN8XJS7FY30VYR24VTG/chunks: no such file or directory"
In fact looking at the directory structure under /tmp/prometheus, the default directory where Prometheus store files I found this:
The solution was to delete the directories that didn’t have a “chunks” subdirectory and restart the Prometheus container. The dashboard started working again.
Also this year, Theo Heselmans made me the honor of accepting my submission 🙂
I will be speaking with my dear friend Marianna Tomasatti, another Italian HCL Business Partner.
Our session is: Ad01. Useful hacks for Domino Administrators
It will be Wednesday, April 26 from 13:30 to 14:30 in room C. – Husly Lounge
You can find all the awesome sessions of Engage 2023 here
It will be a pleasure for me to speak again at this great event. Engage is the new Lotusphere! And it will be great to meet again many friends from all over the world.
After digging a bit into the issue I reported in my previous post, I found out that this is not a bug of Sametime. The problem lies in my customer network topology. As in many other customers I work with, they have some servers on the intranet, and some others on the internet, in this specific case the Domino server that is the LDAP server is on an internal domain ( .lan ) while the Sametime server is on a public domain ( .it ).
This is not a problem for Sametime, all you need to do is use some “extra_host” settings in docker-compose.yml and it works
The problem is that the URL generated by Verse when people upload their pictures is https:// pointing to the Domino server and the Sametime proxy does not like self signed certificates. In fact if I manually change it to use http:// rather than https:// in the person document, then the user picture is displayed correctly
I do not believe I can have the Verse development team change the way they generate the URL and use http:// so with this kind of network topology I have to find a workaround, else the problem will remain.
Thanks to my friend Erik Schwalb from HCL, who got in touch with me and told me that in his setup, where all the servers are in public domains using proper certificates this works fine.
With the customer where I installed Sametime 12 we had an issue with Meetings using an Android device. From a Android phone a user could not join a meeting or create a new one. With iOS devices, this problem did not happen. We tested on Sametime 12.0.FP1 and Sametime 12.0.1
We opened a Case and in the end HCL Support found the solution, you have to add to the file .env this line
I have installed Sametime 12.0.1 integrated with Verse. The users now upload their pictures from the Verse UI but this breaks the display of images in Sametime.
Business card photos must meet the following requirements: Photos must be less than 45K in size. Photos 10K or less are recommended. Photo file types .jpg and .gif are supported. Photos to be used in business card for mobile or web clients they must be in the format of a URL, such as hosted from a web server or HCL Connections Profiles server.
So the users for which I manually define the Photo URL field everything works fine
But for users who upload the picture from Verse the Photo URL is something like this
This type of URL cannot be read correctly by Sametime as an image and the result is that user’s picture are not displayed in Sametime, both in the clients and in the meetings
The only workaround I can think of is to disable the possibility for the users to change the image from Verse and use a proper URL that points to a web server ( I use the same Domino server that does LDAP ). This will cause probably some dissatisfaction for the users and some work for the Admins who have to collect the pictures and put them in a single place, but is the only way to avoid this problem as far as I know.
I have installed ST 12.0.1 for a customer using Docker, and initially I wanted to use MongoDB 6.0; installation was fine but MongoDB would not start.
The error thrown was this: Job for mongod.service failed because a fatal signal was delivered to the control process. See “systemctl status mongod.service” and “journalctl -xe” for details.
A quick search on the web gave me the reason of this:
MongoDB requires the following minimum x86_64 microarchitectures:
For Intel x86_64 , MongoDB requires one of:
a Sandy Bridge or later Core processor, or
a Tiger Lake or later Celeron or Pentium processor.
For AMD x86_64 , MongoDB requires:
a Bulldozer or later processor.
My customer server had a Xeon Gold 5120 which is below the required specs for Mongodb, and that was causing the error.
The only thing I could do was uninstall MongoDB 6.0 and install MongoDB 4.4, which starts without any issue.
So if you plan to use MongoDB 6.0 pay attention to the CPU type you have .
P.S. I never had this before, I run my test servers on a AMD Ryzen 9 3900X 12-Core Processor machine, which is more than enough 🙂