Leaderboard

Hello everyone, sometimes it's good to have some good news in the forums and not always requests for support (even if these always improve technical skills). With Alexandria Rad Studio 10.3 I tried to enable TLS 1.3 support using a trunk version of Indy "https://github.com/mezen/Indy/tree/NewOpenSSL_PR" already described in issue 299. Uninstalled Indy from RAD STUDIO. Known Issues: - Lost support for FMX LivePreview (which I don't use). - Each time Rad Studio is closed, a runtime error is generated in the RTL library.... It is not recursive and when OK it disappears without a trace. I only close RAD Studio 1 or 2 times a day so it doesn't give me any problems. Care must be taken to remove all references to the original Indy sources in the RAD STUDIO LIBRARY path. To make it faster I saved the Windows registry with REGEDIT, edited with a NOTEPAD removing all references to INDY from the various keys and re-imported again with REGEDIT. I then entered the new paths (Core, Protocols, System, OpenSSL) of the new archive (unzipped in a directory on the disk) again in RAD Studio. Without touching anything, recompiling the old project with native OpenSSL 1.0.2 support worked perfectly. Then I modified the source by inserting a $DEFINE and some $IFDEFs to easily switch from version 1.1.1 to version 1.0.2 and vice versa. Version 1.1.1 actually only needs to specify the security keys (cipher) to use which are different from those of 1.0.2, and obviously have access to the two OpenSSL 1.1.1 DLLs. Everything works, with TLS 1.3 support and automatic downgrade to TLS 1.2 (as already reported in other TOPICs). Changing the $DEFINE and recompiling switches to the old "original" version with TLS 1.2 support with OpenSSL 1.0.2 All third-party components (obviously in source format) that use Indy work perfectly even with the new version once recompiled. I haven't tested all of my projects that use Indy to see if there were any issues, but the last 10 recompiled projects didn't produce any glitches. When I have some time I will try to reinstall RAD STUDIO from scratch and directly upgrade the Indy TRUNK in the original RAD Studio version just to see if by recompiling from there you can avoid LIBRARY PATH updates (except the OPENSSL which you have to add by hand) and above all if you manage to avoid the error when closing RAD Studio. Bye P.S.: the project is an HTTPS server directly derived from an Indy demo. It is online in Internet without any filter, protection or other with no issue at all after more than one years in two systems Windows desktop and Linux server (now the Linux server is not anymore online).

Yellow all, https://github.com/TommiPrami/Delphi.GetProcessReservingFile Made quick and dirty port of code found from here: https://devblogs.microsoft.com/oldnewthing/20120217-00/?p=8283 If find anything to fix or make code better, feel free to send pull request or so... -Tee-

Just to discover the image format? You can use the TSkCodec.MakeFromStream(LStream).EncodedImageFormat

It is fine if you find ChatGPT useful for something. But just because it is useful to you, does not mean it is useful to others.

The problem isn't the source of the information. It's how the information is being used and framed / portrayed. Anybody who has been following what's going on with the defamation suits from Dominion and Smartmatic against Fox, their management team, and their on-air lying sacks of sh*t, can see how the people running Fox are clearly targeting viewers who have such flawed critical thinking skills that they'll fall for anything the talking heads on Fox say as long as it fits a particular pattern of communication or point of view. I have a friend who's retired, and all he watches on TV is Fox. I called him to ask if he'd make me a small loan for a few days and he said "sure, but I need to get cash." I said, "Why? What's wrong with Zelle?" He said, "Haven't you heard? The IRS is coming after anybody who uses payment things like Zelle for sending more than $600 to ANYBODY! I don't want to deal with the IRS over a stupid loan like this!" I thought, "Oh, boy, I guess this is the latest crock of BS that Fox is scaring people about this week..." He's on Social Security and doesn't even file a tax return because he doesn't earn enough, and yet he's worried about getting audited by the IRS because of nonsense Fox is blathering on about this week to make Biden look bad. It's pretty hard to deal with people who can't even break down the most simple things they hear or read in the media as they may or may not apply to them! Now we've got ChatGPT that is, in all likelihood, far more accurate and less biased than Fox, and yet people are up in arms over the mistakes it seems to be making. Sure, I've found several. But Dominion and Smartmatic are very likely to get default judgments against Fox to the tune of nearly $4 billion for the mountain of evidence their lawsuit discovery processes have shown that Fox exec and talking heads have engaged in a steady practice of telling lies to their viewers in order to boost their ratings and profits. Period. And the people who make the most noise about ChatGPTs errors probably don't even realize Fox is FAR less reliable and truthful -- nor will they even accept that as a possibility. There was a book published in 1976 by Joseph Wesienbaum called "Computer Power and Human Reason". He was the founder of MIT's AI Lab. At one point in the book, he said he was asked by a reporter something like this: "What is it that humans can do that judges, psychologists, and other experts can do that computers cannot do?" His response was, "the question is what we as humans should allow or not allow computers to do that humans do." I have not found that particular quote, but here are some others I found onilne: https://www.goodreads.com/author/quotes/496834.Joseph_Weizenbaum

That would be suicide not murder, because wrong answers kill only if the answer is accepted without any critical thought at all. (OK, it would probably kill about 90% of all people. Fair enough.)

That's what I was talking about. AI won't kill us in the way you have seen it in the television. It will kill us with wrong answers.

DDuce does not have a TListDataSet (anymore?) it uses TObjectDataSet from Spring4d

in what respect? I mean ... what kind of use-case are you thinking of? I asked about this because I've got a bunch of JSON data (array of records) that I'm stuffing into objects added to a TList, and it seems the only way to get something I need is to use a DB-aware control to view them. So I need to get them into a dataset so they can be viewed. Then the whole thing gets thrown away. So the choice is to go from JSON --> TDataSet or TList<T> --> TDataSet, both of which are dependent on the same issues: How much time do you want to spend writing code that speeds this up by less than a second? It's a little funny to me that all of this great technology we have at our fingertips is all rooted in stuff designed back in the 90's to support Client/Server database technology while today a large amount of our work centers around data shipped between servers as JSON packets, that's either parsed and used immediately or stuffed into classes, and is mostly transient and never intended to be put into any kind of structured DB. There are even plenty of NO-SQL DBs available today to help manage this data. Yet the most useful visual components are all driven off of TDataSets that are intended to be connected to databases. DevEx grids are incredible, but last I saw, they're totally driven off of TDataSets and are useless for JSON data and lists of objects.

http://www.x-files.pl/components/xdbdata.html

Because there isn't (at least not in the RTL) - ChatGPT is making that up (as so often).

This could be as simple as doing a basic HTTP GET request for the html page. But if there's any javascript in it that generates content, then you need to have it loaded into the browser's DOM and search that, which can be quite a PITA. Similar effort in whatever browser you're using. If you want an example of how convoluted it can be, issue a simple query to Google and see what you get back. You'll see very little HTML code that's visible in the browser, and the stuff in the browser is generated in a variety of different ways, making it really hard to reconstruct what actually appears on the browser's screen. Google has raised the art of obfuscation to another level!

My hard-earned advice Refrain from replicating the database structures in the REST API. Think about the tasks you want to execute, and what data that is needed for these tasks. It doesn't matter how they actually are stored in the database, as it is the REST server's job to sort out what goes where and how. It also enables you to swap out the underlying database without changing the API itself. Use JSON data packages. The good thing about these, is that you can have missing or extra fields in both directions, making the API less fragile. If a value is missing and not critical, simply use a default instead. If an unknown value arrives, just ignore it. This moves the versioning to the API levels, instead of purely on the database. Try https://api.swaggerhub.com for building APIs. Swagger files, now known as OpenAPI definitions, are very useful as there are numerous dev tools that can use them to create both server -and client-side code or configuration. Do not expose primary keys in the APIs - if you need an actual unique key, create a GUID field in the database and use that as the unique id. It is way too easy to do serial breach attempts on queries where the PK is just an integer. Use secure connections - i.e. https. Make sure you use proper authentication. OAuth2 with limited time keys. Remember why it is called RESTful and obey the rules

I would call it a managment of "history" in the data itself, instead of log. The log could be external too and its hard to keep that on track. What I consider is a history management within each table, where for example copies were made before changes and instead deletion its just setting flags with a timestamp. That way the latest version in a table keeps always intact and easy to undo the changes, just by manipulating the flags and timestamps. While you can decide at any point to remove the "garbage" in a table without much side-effects. Of course managing multiple, related tables can always be a headache still, but I think its more clean and easier to understand if tables can handle and encapsule their own, specific undo/redo behaviour, in contrary to a possible external, universal log management which can be very complex and tricky and failure prone.

The point is that the code is plain wrong, the last else in both if trees needs to cast value.x and value.y, respectively, not result.x/y, which has not been set at those points!