Anders Melander

I don't think so. The Turing test is pointless unless your only goal is to create something that can fool a human and what good is that? We don't need a computer to do that. Trying to define intelligence with too narrow parameters like "it talks like a human" or "it is self-aware" is also not helpful. Intelligence, as observed in most humans and many animals, is many different things the sum of which is what we think of as "intelligence". The ability to talk like a human, using a database of human knowledge, is really just a party trick and largely irrelevant with regard to Strong AI. I wonder what will happen when the AI chatbots have generated so much output that they predominantly use their own, not necessarily correct, answers as training data...

People quoting ChatGPT, in the style of "according to Wikipedia", is getting really tiresome. And as could be expected, some people have also begun using it in discussions to pretend knowledge about topics. Just like they do with Wikipedia. Ask a follow-up question that requires actual knowledge and their arguments fall apart. ChatGPT "knows" language and that's it. It has zero "understanding" of the topics. It has no awareness. It doesn't understand logic or philosophy, nor even know what that is. This isn't a science fiction movie.

https://regex101.com/r/1RVJ8h/1

I can't tell if you're being serious but just in case: AI is not intelligence. It's just a clever simulacrum - an emulation. It's not self-aware and it's completely incapable of independent thought. Unless you teach it exactly how to "rebel" against you, and then tell it to do so, it cannot do it.

and here's the answer to the question, supposedly in the style of Rudy Velthuis (I don't think it quite got it here): or in the style of Donald or freestyling

I'm sure a bit of Googling can answer that for you. If that fails, I know someone something that can answer it.

Optimal? How do you define similarity optimally? In fact, how can you even define similarity=0? I would say that similarity very much depends on what you need it for. A picture of a red apple and a yellow banana is "similar" because they are both pictures of fruits.

Only published members (properties, methods) have their names stored in the exe since that is required for DFM streaming to work. There's no reason have private/protected/public member names stored there, so they're not. It would just waste space in the exe file. The reason the test case in the OP works is that the classes omit the scope specifier (private/protected/public/published) from the class declaration which means that all members use the default scope = published. Look them up in the map file. This is what stack tracers do. Search for that.

Yes, I guessed that much 🙂 It's almost the same in Danish: Poesi

Poesie? Well, that explains a lot.

I would agree but he said that he: Doesn't closing the connection also close all open cursors associated with the connection?

Cross post from: https://stackoverflow.com/questions/74759895/calculation-of-the-illumination-of-a-point-for-png-image-taking-into-account-tr I don't think your handling of COLOR_PALETTE is correct. AImage.TransparentColor specifies a color that should be considered fully transparent (i.e. alpha = 0). It does not contain the alpha of the RGB channels. For performance, I would do the Alpha/255 once instead of 3 times: alpha := LDstAlpha[AX] / 255; r := Byte(Round(r * alpha)); g := Byte(Round(g * alpha)); b := Byte(Round(b * alpha)); or for much better precision and even better performance: alpha := LDstAlpha[AX]; ... Result := Round(0.3 / 255 * r * alpha + 0.59 / 255 * g * alpha + 0.11 / 255 * b * alpha); Apart from that, I don't see how comparing the YUV luminance of colors would help you determine if the colors are the same. Two (subjectively) different colors can have the exact same luminance. For example, here's a red circle in grayscale: here's a green one: and here's a rainbow-colored one: That only makes sense for fully transparent pixels. For alpha transparency, which is what most PNGs use, alpha premultiplying the RGB makes a little more sense. Not a lot of sense, because there's no "right way" to compare an opaque and a semitransparent color. It's really a question of how one chooses to define equality here.

Well, that sucks. I think you can use management studio to determine if your connection has an active query. Maybe that can provide some clues.

Are you using asynchronous query execution (ResourceOptions.CmdExecMode <> amBlocking) anywhere?

Forget about that. It will never work in a multi-user environment. You cannot "check for locks" without acquiring a lock. See race condition. Yes, there is. All statements are executed in a transaction. Your DevArt connection settings are probably set to use implicit auto transaction so this is hidden from you but I'm positive that you can configure it so transactions must be made explicitly. It's actually not that hard once you understand the different transaction isolation levels. I suggest you start there: https://mariadb.com/kb/en/mariadb-transactions-and-isolation-levels-for-sql-server-users/

This whole thread is a big waste of everyone's time, including the OP. There's no point in trying to come up with alternate solutions when it seems no real attempt has been made to locate and isolate the cause of the problem. Run your application in the debugger. When the out-of-memory occurs, look at the call stack and place a breakpoint somewhere up the call stack before the call to the lower level method. Reset the debug session and run again. When the breakpoint is hit, single-step into the methods below, watch the memory consumption and try to understand what's going on in the code. At some point, you will likely arrive at the location where too much memory is allocated and the cause and/or solution will present itself. I do have a hunch about what the problem is, but it's no better than all the other guesses when the basic troubleshooting hasn't been done.

How is that different from the way the standard Delphi RTL translation system works? Resourcestring and form translations are stored in external language modules, one per language, and at run-time forms and strings are loaded either from the exe or from a language module depending on the desired language.

I see. Well, assembler is used with many different languages: Delphi, C, C++, etc, so that sounds perfectly reasonable to me. I would actually expect it to have a higher ranking than twice that of Delphi. FWIW, I just tried searching github for "eax" in the Pascal, C and C++ file types: pas: 41,053 files, inc: 61,659 files c: 5,930,801 files, h: 3,686,546 files cpp: 499,900 files, hpp: 74,991 files According to the search, there are a total of 2,245,735 pas files on Github, so 1.8% of the Pascal files (.pas) contain assembler. There are 1,098,004,054 c files, so 0.5% of those contain assembler. If the file count is representative of the TIOBE ranking (it's not), then the above suggests that assembler is approximately 5 times more used than Pascal. All these stats are of course completely bogus because the numbers don't take file/repo duplicates, abandoned, or archived content into account.

People who write low-level code where performance is important. If by "widely used" you mean "used by most" then no. But then it never was. "Most people" wouldn't know how to create the tools or write the libraries that they use, but someone has to do it. Even if you don't have a need to write assembler, knowledge of it makes you a better developer because it gives you a deeper understanding of what's going on and why. The same goes for hardware.

Instead of all this guesswork why not simply use the debugger to determine where the out-of-memory occurs?

And where is this written? Whoever made the change obviously did it to handle lists with duplicates, so it's pointless to argue that lists are usually without duplicates. It's fine that there are corner cases that performs worse than optimal, like with quick sort, but the worst case here is a bit extreme considering that it could have been avoided with a bit of effort - or they could have just Googled the solution. There's just no excuse for the current implementation.

Once again I'm struggling with the fact that the compilers Return Value Optimization of interfaces produces code that keeps interfaces alive beyond the scope of the block in which they are referenced. For example let's say that I have a function CreateFoo that creates a reference counted object and returns an interface to this object: begin var Foo := CreateFoo; ... Foo := nil; ... end; One would think it was reasonable to assume that, given no other references to the object besides the Foo variable, once I nill the Foo reference then the reference count goes to zero and the object is destroyed. Right?... Nope. It seems that what the compiler actually produces is something like this: var Gotcha: IUnknown; begin Gotcha := nil; try begin Gotcha := CreateFoo; var Foo := Gotcha as IUnknown; ... Foo := nil; ... end; finally Cotcha := nil; end; end; Since this is an old, known problem I wonder if anyone has been able to come up with a work around. I have mostly been able to work around it in my own code by simply not relying on reference counted objects being destroyed inside local blocks but I have a few places where I simply either have to make this work properly or abandon reference counting. FWIW, the following reproduces the problem: program FooFail; {$APPTYPE CONSOLE} {$R *.res} uses Classes; type TFoo = class(TInterfacedObject) public constructor Create; destructor Destroy; override; end; constructor TFoo.Create; begin inherited Create; WriteLn(' Create'); end; destructor TFoo.Destroy; begin WriteLn(' Destroy'); inherited; end; function CreateFoo: IUnknown; begin Result := TFoo.Create; end; begin WriteLn('Begin'); begin var Foo1: IUnknown := TFoo.Create; Foo1 := nil; // Foo1 destroyed here end; begin var Foo2: IUnknown := CreateFoo; Foo2 := nil; end; WriteLn('End'); end. // Foo2 destroyed here The expected desired output is: Begin Create Destroy Create Destroy End The actual output is: Begin Create Destroy Create End Destroy

P.S. Good luck with the writing

Actually, I didn't - until now. Same problem, I'm afraid. I haven't QP'd it and will probably not have time to do so anytime soon; We've just updated our main product suite to Delphi 11.2 (from 10.3) and there's plenty of other stuff that needs my attention. Here's the original test case updated to exhibit the observed behavior: program FooFailMore; {$APPTYPE CONSOLE} {$R *.res} uses Classes; type IFoo = interface ['{28036C58-4E0E-422C-AAE1-7DDEFF51C75D}'] procedure DoFoo; end; TFoo = class(TInterfacedObject, IFoo) private procedure DoFoo; public constructor Create; destructor Destroy; override; end; constructor TFoo.Create; begin inherited Create; WriteLn('Create'); end; destructor TFoo.Destroy; begin WriteLn('Destroy'); inherited; end; procedure TFoo.DoFoo; begin WriteLn('Foo'); end; function CreateFoo: IUnknown; begin Result := TFoo.Create; end; procedure Test; begin WriteLn('Begin'); begin var Foo1 := TFoo.Create as IFoo; Foo1.DoFoo; Foo1 := nil; // Foo1 destroyed here end; begin var Foo2 := CreateFoo as IFoo; Foo2.DoFoo; Foo2 := nil; end; WriteLn('End'); end; // Foo2 destroyed here begin Test; ReadLn; end. Expected output: Actual output:

Wikipedia (even though it references the almighty Knuth) isn't the definition". It's a definition.