Lars Fosdal

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?

Are you receiving multiple individual json packages (1), or is it one large package with an array of multiple json elements (2)? 1. {json}{json}{json} 2. {"list":[{json},{json},{json}]} How complex is each json element? Can you show us an example? Is it the insert to the DB that is time consuming or the decoding of the json? Are you opening and closing the DB connection for each json element?

You need to give us a little more to work with. How complex are the json structures? Is it the backend or the client that will be written in Delphi? Is it the backend or the client that will receive 1000 jsons ? If the backend uses 1-2 seconds and it is not written in Delphi - that is not a Delphi problem.

I was signed up but didn't have time to watch it - when I tried some of the interesting replays, they were not working. Why don't they do a blog post about it and indicate a timeframe for availability? In a way, it is good that they have HighDPI issues since that means proper dogfooding, but I fear that we will be talking about update 1, and not a December hotfix. Judging from all the HighDPI issues I've seen discussed, the right thing to do would be to break the mold and do it right. The current approach with kludges and workarounds = tech debt++.

The dice example doesn't look well at the smaller sizes as particularly the lower right corner is not as round as it should be. Offering multiple downsampling algorithm options is a good idea.

Not sure that is possible as such functionality could violate security.

Although VCL apps need 16x16 too.

I would think that you could increase the potential number of users with quite a bit if you added VCL support as well 🙂 Edit: or even add it as a pro feature at a reasonable price.

It's still there.

I use the good old IcoFX 1.6.4 Portable Edition. KenR - how well does it resample for 32x32 and below? Most of the time, the smallest sizes need some TLC to look decent.

When there are reasons, there should be public information - but there is just silence.

It is not that we don't see its importance, we just don't have any faith in EMBT's ability to pull it off.