revamped | ️ my blog , migrated to gatsby | Blog library

QtConcurrent doesn't deal with any of it, unfortunately.

In a most general approach, you only need some worker machines on the network, and a way to connect to them via ssh (if they are Unix), or via Windows credentials (on a Windows network). At that point you can send a binary to the worker and execute it. Doing this in Qt is of course possible, but you'd need to wrap some other libraries (e.g. Samba for RPC calls, or openssh) to do that.

No matter whether the software can "distribute itself" or is otherwise installed on the workers, you got it running on multiple machines. Now they have to communicate, with one being a master, and the other being slaves. Master selection could be done via command line arguments, or even by having two binaries: workers that include only the back-end functionality, and a front end that includes both (and has some sort of UI).

At that point you can leverage Qt Remote Objects, the idea being what you'd "distribute" is QObjects that do work in the slots, and return results either via return value of the slot, by sending a signal. It's not as convenient as using QtConcurrent directly, but in general there's no way to distribute work transparently without some introspection that C++ doesn't quite provide yet.

I know that OpenMPI is not a Qt-based solution, it certainly works and makes life easy, and for sure it can interoperate with Qt code - you can even distribute methods and lambdas that way (with some tricks).

If you manage worker objects encapsulated as QObjects, it's not too hard to distribute the work in e.g. round-robin fashion. You could then have a front-end QObject that acts as a proxy: you submit all the work to it, and it signals all the results, but internally it invokes the slots on the remote QObjects.

Would you be interested in a demo? I could write one up if there was enough demand :)

I managed to add a http server as a corutine. First I tried to use aiohttp, but eventually I found Quart (same as Flask but it uses Asyncio). Sample code to run http server on Quart:

As per google developer's article:

Easier publishing We've renamed Timed Publishing to Managed Publishing. Use it to see a summary of your changes that are in review and control when to publish on Google Play. Managed Publishing also helps you understand all the changes that have been submitted across your releases, store listings, and more. For those of you with larger teams, you can now review and coordinate all your changes in one place so everything is published at the same time.

For reference: https://android-developers.googleblog.com/2020/06/introducing-new-google-play-console-beta.html

Your issue with this line:

It seems that the different column types have an issue. One option is to first change the column types to a single one and then do the rowwise

From django docs on admin:

The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.

It's possible to change templates to do what you want, but that will be very complex - you have to basically rewrite most of the templates, get to know how it is working internally and probably change that too to your own design (after all, you are going to show specific details, like charts, data and so).

You will faster to achieve results if you going to build your own app, that will work exactly like you need without multiple fixes. Does it have to use js frameworks depends entirely on your requirements. Usually they are much more simple for admin backends, that are going to be used by owners, not clients. Anyway, if you don't have experience or knowledge in this, you will probably better off with just plain static django templates.

Django admin is just a same app as the ones you build, so limitations will be the same. Security wise, it doesn't offer much that you can't do yourself - make sure you have permissions set in models/views. Read more about security in django.
From functionality point of view, django admin just comes with CRUD access to your models, which can be done quite quickly. Once you past that, you will have much easier time adding functionality to your own app instead of overriding django admin.

Overall, I advise you to build your app for CMS-like admin panel. JS frameworks is neat, but that require burden of multiple additional tests (with api mocks), constant swapping between adding api / writing a component and much higher time consumption overall.

New themes are probably not (yet?) part of the Material Icons font. Link.

The key difference between 'synchronized' and 'volatile', is that 'synchronized' can make threads pause, whereas volatile can't.

'caches and registers' isn't a thing. The book says that because in practice that's usually how things are implemented, and it makes it easier (or perhaps not, given these questions) to understand the how & why of the JMM (java memory model).

The JMM doesn't name them, however. All it says is that the VM is free to give each thread its own local copy of any variable, or not, to be synchronized at some arbitrary time with some or all other threads, or not... unless there is a happens-before relationship anywhere, in which case the VM must ensure that at the point of execution between the two threads where a happens before relationship has been established, they observe all variables in the same state.

In practice that would presumably mean to flush caches. Or not; it might mean the other thread overwrites its local copy.

The VM is free to implement this stuff however it wants, and differently on every architecture out there. As long as the VM sticks to the guaranteed that the JMM makes, it's a good implementation, and as a consequence, your software must work given solely those guarantees and no other assumptions; because what works on your machine might not work on another if you rely on assumptions that aren't guaranteed by the JMM.

Reordering is also not in the VM spec, at all. What IS in the VM spec are the following two concepts:

1. Within the confines of a single thread, all you can observe from inside it is consistent with an ordered view. That is, if you write 'x = 5; y = 10;' it is not possible to observe, from within the same thread, y being 10 but x being its old value. Regardless of synchronized or volatile. So, anytime it can reorder things without that being observable, then the VM is free to. Will it? Up to the VM. Some do, some don't.

2. When observing effects caused by other threads, and you have not established a happens-before relationship, you may see some, all, or none of these effects, in any order. Really, anything can happen here. In practice, then: Do NOT attempt to observe effects caused by other threads without establishing a happens-before, because the results are arbitrary and untestable.

Happens-before relationships are established by all sorts of things; synchronized blocks obviously do it (if your thread is frozen trying to acquire a lock, and it then runs, any synchronized blocks on that object that finished 'happened before', and anything they did you can now observe, with the guarantee that what you observe is consistent with those things having run in order, and where all data they wrote you can see (as in, you won't get an older 'cache' or whatnot). Volatile accesses do as well.

Yes, your interpretation of why x++ is not atomic even if x is volatile, is correct.

I'm not sure what your Q4 is trying to ask.

In general, if you want to atomically increment an integer, or do any of many other concurrent-esque operations, look at the java.util.concurrent package. These contain efficient and useful implementations of various concepts. AtomicInteger, for example, can be used to atomically increment something, in a way that is visible from other threads, while still being quite efficient (for example, if your CPU supports Compare-And-Set (CAS) operations, Atomicinteger will use it; not something you can do from general java without resorting to Unsafe).

global item.rect.x does not make any sense at all. Remove this line and read about the global statement.

The Target objects do not move, because you didn't add them to target_sprites. You missed add the pygame.sprite.Sprite objects to the pygame.sprite.Group():