Lars Fosdal

We've been waiting until Update 1 for every release for the last decade. Call me pessimist, but when things don't get better within a decade - will they ever?

You should raise this with EMBT. We are doing a thorough investigation to close all the log4j holes we can find, and there have been a few surprises. I don't do much Java related stuff, but if you use SmartBear ReadyAPI, there is an update out with a fix. If you have a lot of .jar files, have a look at https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html and the Syft and Grype tools. Onsite Jira and Confluence can be exposed if custom logging has been turned on: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

Hey, we work with computers and software. What could possibly go wron2c0+23423\09csxsz\+09r2123...

In addition to all the work required to move to a broken DPI aware solution, the state of the debuggers makes me frustrated. As usual, the release of 11 was premature. We are waiting for Update 1.

Bad news: It appears that Markus Kreisel, who wrote Sisulizer, has died. https://web.archive.org/web/20210121010025/https://www.sisulizer.net/forum7/4079.html Posted Thu Dec 24th, 2020 11:54 pm by Harald Krause The link leads to an obituary written by Renate Reinartz, his wife and co-owner of Sisulizer. I can't find any activity online from her since then. Not on her LinkedIn account either.

No tweets since 2016. What about Facebook updates? Forums appear to be dead: https://www.sisulizer.net/

The observations appears to be accurate. @Daniel found a huge queue of approvals waiting - mostly spam accounts - but probably also actual users. Somehow, the system had queued the accounts for approval - but no notice of waiting approvals were given to the admins/mods. I would suggest that new users try registering again?

When you compare the MS VS CE to the EMBT RAD CE, the latter looks ridiculous.

Or - check the current folder for db files and use those if they exist, otherwise create a new under appdata? FYI - There appears to be some delay for updates through GetIt - 1.1.2 installer is still not available. Ref. signing - this is perhaps not that big of a deal for the average user, but it does add another layer of security. It can come into play on corporate networks, where - depending on the policies in play - installers not properly signed simply won't be allowed to run.

Downloaded Setup.exe from karmobile.net and had a look. Good news - The ARM problem is solved in the 1.1.2 installer. The unknown publisher is related to Setup.exe being signed with a self-signed certificate. Unfortunately, proper certificates are expensive. https://www.ssldragon.com/product/sectigo-code-signing-ssl/ When running the installer standalone, it seems something goes amiss? Note that I installed it under C:\Program Files\Launch Gen - which means the current directory of the application is read-only. Preferably, working files should be placed under User specific app data %AppData%\Launch Gen = C:\Users\<username>\AppData\Roaming\Launch Gen This pops up when starting Launch Gen. On closing it, without having made any changes or operations, Also, the app is not DPI aware - but then again - neither are mine 😛

Well, something is amiss, it seems?

Looks like your latest versions has not yet propagated through to us GetIt users. Still seeing 1.1.1 and the same x64 error. Another little nitpick - Your installer should be signed.

Well... it still denies me to install under Windows for ARM.

Excellent news, @KenR, but the installer is not friends with me. It denies me installing x64 .exe files under Windows 11 for ARM. All the .x64 that I have tried on WfA, run without problems. What is the reason for blocking installation?

This is probably the best example I've seen on proper use of the parallel libs and how to keep the UI responsive and updated (on multiple platforms). It doesn't cover all the corners of the parallel lib - but it is an excellent example of how beautifully simple multithreading can be.

https://s3.amazonaws.com/heysummit-production/media/uploads/events/delphicon/MonienThreading-Intel-vs-M1.zip and you need a unit from here: https://github.com/omonien/sieve-of-eratosthenes-delphi

I disagree. I'd still use work threads queues and a wait for a result queue to properly handle timeout situations. Divide and Conquer.

Windows 11 - Intel 32 bit on 1 of 4 cores (under Windows 11 for ARM under Parallels) Single thread: 00:00:15,325s 1.02M primes/sec Multi-thread : 00:00:05,097s 3.08M primes/sec Windows 11 - Intel 64 bit on 4 cores (under Windows 11 for ARM under Parallels) Single thread: 00:00:09,831s 1.6M primes/sec Multi-thread : 00:00:03,234s 4.85M primes/sec Windows 10 - Intel 32 bit on 1 of 12 cores (6 physical on a Lenovo P52) Single thread: 00:00:04,969s 3,16M primes/sec Multi-thread : 00:00:00,903s 17,39M primes/sec Windows 10 - Intel 64 bit on 12 cores (6 physical on a Lenovo P52) Single thread: 00:00:05,971s 2,63M primes/sec Multi-thread : 00:00:00,843s 18,62M primes/sec macOS - Intel 64 bit on 10 cores on MBP M1 Pro Single thread: 00:00:03,712s 4,23M primes/sec Multi-thread : 00:00:00,491s 31,97M primes/sec macOS - ARM 64 bit on 10 cores on MBP M1 Pro Single thread: 00:00:03,711s 4,23M primes/sec Multi-thread : 00:00:00,483s 32,5M primes/sec

Does the response depend on the result of the processing? I.e. Does the response need to contain data from the processing. or return a different status if the processing failed?

@Ann Lynnworth - that video link looks like a miss. Including a link to your site would be nice: https://www.href.com/rubicon Or is this just a clever spam bot? Fortunately, she's legit 🙂

@David Schwartz - I think that he means that the server sends individual REST posts. @Andre Capelli - Just to be sure: The Backend (which uses the Horse libs) is where your Delphi code is. The Server is someone's server or service that place REST calls to your Backend. How is the connection established? Do you make a request, and then your Backend is subscribing to individual, asynchronous updates from the Server? IMO, if the Backend keeps receiving REST calls after connecting to the Server, a workable solution would be to queue the incoming JSON to a work queue, and then have a worker thread pool consuming from that queue. You do typically not want to do all the processing in the response handling, but hand it off to workers. It gets more complex if you must validate the results of handling the JSON to decide on the result code for the REST request, but if there is a Horse community, that would be the place to ask for how to deal with it. It sounds odd that the current processing is interrupted when a new REST request arrives. When you get multiple requests in Indy, each of them gets a thread of their own - and I use the above approach and have the response thread idle wait for a completion from the processing queue - or - after the specified time, return a timeout stat. My solution is not typical REST, but JSONRPC - which sort of is synchronous RPC in JSON format, but the challenge is the same. Worker threads save a lot of time when you need setting up the connections, lookup tables, and other forms of data that can be cached.

Opening and closing the databaseconnection is expensive. You need a worker thread pool that where each worker thread keeps a connection to the database. I am still not sure that I understand your architecture and dataflow. Your example shows a single element: {"leads": [{json}]} - is that the typical REST request that you receive multiple times, or do you get {"leads": [{json1}], {json2}, ..., {json1000}]} ? That doesn't sound right? I don't know the Horse backend lib - so I don't know how to advise you on that.

I'd be curious to see the resource requirements of a Miletus app. /off-topic Still a double use in the title.

The RD runs as a UI-less service, right? So it doesn't have a Window of its own and probably have special rights to capture the display activities and send events.

/off-topic Your post title needs a little tweaking, me thinks. It is Miletus, not Melitus (which is diabetes). /on-topic Many industrial units have web interfaces built in - but these are one more attack vector - and if you are rolling your own - there is the issue of maintenance and even more stuff to deploy to the devices. Personally, I would not want to spend limited resources on an IoT unit on hosting a complex UI. Yes, it can be done this way - but - should it be done this way?