| 5 Sep 2024 |
 outfoxxed |
All .qml, .js, and .mjs files added to the module via the QML_FILES argument will be compiled to bytecode and cached directly in the backing target. This improves load-time performance of the module. The original uncompiled files are also stored in the backing target's resources, as these may still be needed in certain situations by the QML engine.
| 08:05:42 |
| outfoxxed | *
All .qml, .js, and .mjs files added to the module via the QML_FILES argument will be compiled to bytecode and cached directly in the backing target. This improves load-time performance of the module. The original uncompiled files are also stored in the backing target's resources, as these may still be needed in certain situations by the QML engine.
| 08:05:48 |
| outfoxxed | this might be whats happening | 08:06:05 |
 K900 | Certain situations my ass | 08:06:11 |
| K900 | Very helpful | 08:06:15 |
| outfoxxed | it sounds like the resource path only, but when I compiled a module from my own application it copied the source as well | 08:06:35 |
| outfoxxed | * it sounds like the resource path only, but when I compiled a module from my own application it copied the source to the module dir as well | 08:06:43 |
| K900 | Here's a crazy idea | 08:07:27 |
| K900 | Just make it log very loudly when it's trying to cache bare QML | 08:07:41 |
| K900 | Along with the file path | 08:07:44 |
| K900 | And run that for a bit | 08:07:50 |
| K900 | And see when it actually gets hit, if ever | 08:07:57 |
| outfoxxed | doesn't even need to be loudly | 08:07:58 |
| outfoxxed | just needs a category | 08:08:01 |
| K900 | Well very loudly is helpful for finding it in the journal later | 08:08:09 |
| K900 | But otherwise yes | 08:08:14 |
| outfoxxed | I don't run many qml applications or plasma so I can't really test that | 08:08:23 |
| outfoxxed | someone with plasma would be the best choice | 08:08:29 |
| K900 | I can volunteer myself but probably not today | 08:09:35 |
| outfoxxed | my own application exclusively uses fs paths but they're all running through a url interceptor which makes them impossible to cache and test | 08:10:09 |
| outfoxxed | What route do you think we should take the general validation storage though? I'm thinking libraryVersionHash, and I'll implement that probably tomorrow if you don't have any objections to that part | 08:18:32 |
| K900 | You mean hash application build-id into the timestamp field? | 08:19:14 |
| outfoxxed | no, i mean the store path into libraryVersionHash | 08:22:02 |
| outfoxxed | if any of this goes upstream they can just allocate fields for it | 08:22:15 |
| outfoxxed | we can't do that without increasing the maintenance burden of the patch | 08:22:44 |
| outfoxxed | In reply to @k900:0upti.me
I can volunteer myself but probably not today and by the way if you want to log disk cache loads, ExecutableCompilationUnit::loadCacheFilePath | 08:23:56 |
| outfoxxed | Redacted or Malformed Event | 08:24:03 |
| outfoxxed | you probably want to give it a custom logging category so its easy to search for in logs | 08:24:21 |
| outfoxxed | that function will only be called for disk stores and lookups | 08:24:52 |
| K900 | In reply to@outfoxxed:outfoxxed.me
no, i mean the store path into libraryVersionHash Like, the application store path? | 08:26:41 |
