Anders Melander

TL;DR Someone has been able to circumvent a protection mechanism which was designed to prevent a particular category of attacks. The internet: The sky is falling! Apple: Pfft. Chill dudes.

@roynielsen2000@gmail.com The nn/nn-NO TMX issue has been resolved. I have not yet done anything with regards to handling Sisulizer's XLIFF files. New version uploaded.

Yes, to a degree. Bar(42) is ambiguous but resolves to byte. An int64 is demoted silently and resolves to Bar(integer). It could at least produce a warning. My point was that I think it's possible to get rid of the ambiguity without breaking everything. IMO a little (compile time) breakage would be okay as long as there's a benefit.

Resolve to the overload that best match the parameter? function Bar(Foo: byte): byte; overload; function Bar(Foo: integer): integer; overload; ... begin var b: byte := 1; var i: integer := 2; Bar(b); // Use Bar(byte) Bar(i); // Use Bar(integer) Bar(byte(3)); // Use Bar(byte) Bar(word(3)); // Promote word to integer and use Bar(integer) Bar(42); // Should probably fail with ambiguity error even though 42 fits in a byte end;

@roynielsen2000@gmail.com I've reproduced the problem with your file. For now you can work around the problem by editing the TMX file and replacing all lang="nn" with lang="nn-NO".

Yes please. I'd like to first reproduce and then verify the solution with your actual data.

Found it. The Windows LCID for nn-NO is LANG_NORWEGIAN,SUBLANG_NORWEGIAN_NYNORSK and for nb-NO it's LANG_NORWEGIAN, SUBLANG_NORWEGIAN_BOKMAL so the LCID considers them two dialects of the same language. I guess I should stop using LCIDs as a the primary identifier for locales.

I think I've found the cause of this. This is actually a "funny" bug. Funny because I've done much of my testing with Norwegian, Bokmål which, it turns out, is one of the only locales that doesn't make the bug obvious. When identifying the languages I first search my locale database for the RFC 4646 language-region code. The RFC 4646 code for Nynorsk is nn-NO and for Bokmål it is nb-NO. If I fail to locate the locale based on the RFC 4646 code then I delete the last part of the RFC 4646 language-region which leaves me with the ISO639-1 language code. I then search for the ISO639-1 code. The ISO639-1 code for Nynorsk is nn and for Bokmål it is nb. There's also a code for the Norsk macro language: no... Since an ISO639-1 code can map to many different locales (e.g. en -> en-US, en-GB, en-AU) I then find the "primary" locale for the language and use that. What can possibly go wrong... Well, the bug is that instead of deleting the last part of the RFC 4646 I deleted the first part so nn-NO becomes NO and the primary locale for NO is nb-NO = Bokmål. I'll fix that but the question is why I failed to find nn-NO in the first place. Hmm. Maybe there's another bug I haven't spotted...

Can you mail me the TMX file (zipped)?

That's certainly one way to do it but since TMX files are meant for translation memory and what you really want to transfer is the actual translations it would be better to use the XLIFF format if you can make that work. Like everything else the OASIS organization has produced the XLIFF format is a bit fragile. The variant I have implemented support for is the one produced by Delphi's ETM export. In Sisulizer export a language to XLIFF. As far as I know it can only export the translations for a single language at a time. In BTM make sure the language being imported is among the target languages. Edit: It seems the importer takes care of this automatically. Import the XLIFF file. Because the XLIFF importer is tailored to handle the XLIFF files produced by ETM it has some some restrictions which may cause it to barf on other sources. For example it requires text strings to be quoted and it doesn't handle text with attributes (encoded in the XLIFF as sub XML-nodes). If it can't handle the XLIFF produced by Sisulizer then you can either try TMX or you can mail me one of the XLIFF files and I can see if I can tweak the importer to handle them. If you do go the TMX way I suggest you start each import with an empty translation memory (just delete/move the TranslationMemory.dat).

You can't - at least not without writing some code to open the icon and select from the images within. Here are some links: https://stackoverflow.com/a/4286601/2249664 https://stackoverflow.com/questions/8112953/how-do-i-load-icons-from-a-resource-without-suffering-from-aliasing An icon is actually a container format which contains several sub-icons, in different sizes and color depths. If you for example load an icon into a TImage then one of the sub-images within will be selected based on a static rule. I believe it will select one of the 32x32 variants and I think it's Windows doing the selection.

tcp/ip works on pretty much everything.

Here you go. Version 1.3.8185.25123: https://bitbucket.org/anders_melander/better-translation-manager/downloads/

my kbd just died so im typing w the on-screen kbd :-( I'll get on it when that's resolved

Yes, that was a bug. I've just pushed a fix. Do you need me to upload a new build or can make one yourself? P.S. Say hi to Arne for me.

Umm... You mean to say you haven't profiled it?

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-gradientfill ...or since you're using DevExpress anyway, use one of their gradient functions.

Fork the project and commit the changes there. SourceForge has become an OpenSource graveyard. Last I heard of Lars was this: https://www.sn.dk/halsnaes-kommune/lars-har-aabnet-sit-hjem-for-to-ukrainere/ (It's about him hosting some Ukranian refugees). His personal domain is no longer functional so I'm guessing he's too busy for hobby projects these days.

How many do you need?

I just remembered that Graphics32 has two examples which demonstrates interpolation: https://github.com/graphics32/graphics32/tree/master/Examples/Drawing/CubicSpline https://github.com/graphics32/graphics32/tree/master/Examples/Drawing/Curves Both of these just uses Graphics32 for output. The curve generation is independent. Built into Graphics32 there's also the TCanvas32.CurveTo method which does cubic Bézier interpolation (4 control points) and the TCanvas32.ConicTo method which does quadratic Bézier interpolation (3 control points).

I counted one photo of a Chinese paper lamp, two irrelevant meme pics, two general conceptual illustrations and 10 pages of math with no illustrations 😕

A cop out from Julian Bucknall: https://supportcenter.devexpress.com/ticket/details/t1072425/vcl-roadmap-2022#c488df20-f902-4a5e-862d-6e39d11da2f2 TL;DR: Roadmaps are not promises and some of the items in them might not get implemented. Duh! DevExpress wasted a lot of resource on a failed Grid for FMX because reasons. DevExpress then used a lot of resource on a charting suite for VCL which they apparently have now decided was a mistake because they don't believe they can compete. Instead they will now focus on polishing existing VCL controls based on their .NET counterparts. Apparently there's no plans for this because they can't produce a roadmap for it. We'll know what we're getting when they deliver it. Personally, at this point in time, more than a roadmap, I believe I need a statement from DevExpress on how they plan to resolve the problem that their owners and developers are Russian, given that Russia in all likelihood soon will be joining Iran and North Korea in the technological stone age. I will be recommending my clients that they not renew their subscriptions until this has been resolved.

A perfectly valid solution. You could also do it like this: TPackageItem = record WorkPackage: TWorkPackage; Padding: array[0..256-SizeOf(WorkPackage)-1) of byte; end; I don't know how you distribute the rows being processed by each thread but another thing to try is to ensure that each thread will be working on a contiguous set of rows. For example for 10 rows and 3 threads the rows should be divided something like this: AAAAAAAAAA AAAAAAAAAA AAAAAAAAAA BBBBBBBBBBB BBBBBBBBBBB BBBBBBBBBBB CCCCCCCCCC CCCCCCCCCC CCCCCCCCCC CCCCCCCCCC and not like this: AAAAAAAAAA BBBBBBBBBBB CCCCCCCCCC AAAAAAAAAA BBBBBBBBBBB CCCCCCCCCC AAAAAAAAAA BBBBBBBBBBB CCCCCCCCCC CCCCCCCCCC This will improver cache locality. Another thing that will improve cache locality is only working on one row at a time. For example if you are averaging 3x3 pixels then I'm guessing that you are reading pixels from 3 different rows for each pixel. If the size of a row (or even 2 rows) is greater than the cache then this will trash the cache. To avoid this you can first process the bitmap horizontally, transpose the bitmap and then process it horizontally again. One might think that a transpose is too expensive but it's actually fairly cheap (if you use a good blocked transpose algorithm) and the gain from not thrashing the cache makes it worth it.

It's a good thing we have Google then. There are lots of (relatively) easy to understand explanations these topics. The data being manipulated just needs to be in different cache lines. The size of a cache line depends on the processor. Again: Google.

Yes but it doesn't do anything because supposedly FData=nil. Instead it terminates the thread (I'm guessing). This isn't how I would design a work queue but I don't think the queue's the problem. @dummzeuch Are threads reading from memory in the same cache line as other threads are writing to - or are the threads writing to memory in the same cache line. If so you are probably suffering from false sharing and/or cache-line ping pong.