Anders Melander

16 minutes ago, gkobler said:

Connection is busy with results for another hstmt

Did you Google the error message?

As the error message hints at, it's a concurrency issue; Your application attempted to call the DB server with a request while the connection was busy with a prior request. This happens if you are executing statements asynchronously.

If you have MARS enabled I believe that can also cause the problem. Disable it in your connection string.

12 minutes ago, #ifdef said:

Visual Studio 2022 Community Edition 🥲

2022? It's useless!

Your code makes no sense.

Instead of:

value2 := random(500) + 1;
while value2 < 251 do
  value2 := random(500) + 1;

why don't you just:

// Values from 251 to 500
value2 := 251 + random(250);

2 hours ago, Stefan Glienke said:

And fwiw the code that these JIT compilers produce often runs circles around what Delphi does with its ancient instruction set the compiler knows of.

I have a client who wants to use DWScript to do structural load analysis of large models (thousands to millions of nodes). Since DWScript compiles to an AST (Abstract Syntax Tree) and then executes the objects in that tree, he was a bit concerned about performance. He had tried various other scripting systems and they were just too slow.

So we did some benchmarking of a sequence of typical calculations in Delphi vs DWScript. As expected the Delphi compiled code was about 4 times faster than DWScript. The client thought that that was acceptable but I decided to try out the DWScript jitter anyway...

As it turns out there might just be something to David's complaints about Delphi's math performance 😉 because with the jitter enabled DWScript was now more than twice as fast as the native Delphi code. Also, Delphi 64-bit was about 25% slower than 32-bit and 64-bit "optimized" was slower than "unoptimized".

Not to take anything away from Eric Grange's amazing work on DWScript, but I would be embarrassed if my native code compiler was outperformed by a scripting system.

3 hours ago, Rinzwind said:

We only see the same people here. No new and fresh people.

This place isn't representative. Most developers don't participate in communities and don't even know they exist.

I've worked at a lot of different places and with a lot of different developers in my career and I think I've only ever met one other developer IRL that participated in communities.

3 hours ago, Rinzwind said:

Lazarus/FreePascal. Seems there is more progress over there.

Not that I can see. My experience with Lazarus/FPC is limited to using it to make some open-source projects FPC compatible but from my POW they are constantly playing catch up with Delphi. And I think Lazarus sucks as an IDE.

1 hour ago, pcoder said:

It would be useful here (also for end-users) if DirectWrite would offer a parameter to specify a preferred format.

Yes, you probably need to use a custom renderer to get control over the formats used.

https://github.com/microsoft/Windows-universal-samples/blob/main/Samples/DWriteColorGlyph/cpp/CustomTextRenderer.cpp

3 hours ago, pcoder said:

Most common fonts are acceptable, but even "Noto Color Emoji" (2.038) can be very slow on certain systems.

Probably because of its size. Most Noto fonts are huuuge.

Noto Color Emoji contains both COLR and SVG data. The COLR data is ~1Mb while the SVG data is ~18Mb...

3 hours ago, pcoder said:

The file description displays COLRv1, but I don't know if DirectWrite actually uses this format.

I'm not sure what you are saying here.
Microsoft is the primary author of the COLR format and DirectWrite supports all the common color glyph formats:
https://learn.microsoft.com/en-us/windows/win32/directwrite/color-fonts

However, the client has to specify what format to use during Shaping and if the client asks for SVG glyphs then that is what it will use.

https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_glyph_image_formats

You can try subsetting the font to exclude the SVG data and see if that makes a difference (apart from the 18 Mb data saved 🙂)

10 hours ago, Kas Ob. said:

Of course they are dead slow.

SVG color fonts are probably slow. All the other color font types (COLR, SBIX, CBDT) should perform more or less on par with regular OpenType fonts.

6 hours ago, Stano said:

Always before the loop.

Beware of unqualified statements involving always and never. Unless the advice is to never put pineapple on pizza. That one is just a fundamental law of nature.

6 hours ago, Marsil said:

Any differences between declaring an inline variable inside a loop and declaring it before the loop?

As you've discovered it depends on the type of the variable.

Local variables are declared on the stack and such doesn't involve the heap (i.e. the memory manager). Allocating a variable on the stack is basically free of cost.

However, managed types need initialization and that initialization can be costly. TSearchRec contains a string and is therefore a managed type (i.e. slow). Integer is not a managed type (i.e. fast). Additionally, managed types are wrapped in an implicit try..finally block to ensure that they're also finalized. The help probably has more info on this.

If you want to limit the scope just put a begin...end around the whole thing:

begin
  var FileRec : TSearchRec;
  while not StopSearch do
  begin
    ...
    GetData (FileRec);
    UseData;
    ...
  end;
end;

Apart from that, in this particular case, you are touching the file system so the performance of inside vs outside will be dwarfed by that.

4 hours ago, Marsil said:

Yes I'm planning to do that but I thought I may get more useful insights by asking first.

...and so the lesson here is: You don't get more useful insight by asking first.

1 hour ago, Lars Fosdal said:

Who would select to use a closed source backend that doesn't scale, when there are multiple options - of which several have a free tier?

What? Are you saying that this wasn't a good idea?

1 minute ago, corneliusdavid said:

Also on https://blogs.embarcadero.com/, there has not been one single article about DataSnap since 2020 while there have been 15 on RAD Server in that same time-frame.

And how many articles have there been on TForm, TStringList, or TBitmap?

Blog posts are just them doing marketing. It's hardly an indication of anything other than how much they want you to buy the product.

5 hours ago, Carlos Gimenez said:

They suggested I use Datasnap, but with the release of Rad Server I was told that datasnap may be discontinued.

That's nonsense; RAD Server is not a replacement for DataSnap and DataSnap is not being discontinued. Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I miss it every single time I need to install/update.

Apparently, there are no UXers left at Embarcadero.

Left-aligning the button would likely solve the problem but ideally, it should not be placed on the EULA page where one habitually just clicks through.

Looks interesting but then I went to the SonarQube site to see what their commercial terms were like and...

Of course, given that they don't even list prices and that I had to Google for them, I guessed that much.

OpenSource only then, I guess.

On 11/13/2023 at 4:54 PM, FreeDelphiPascal said:

Update: There seems to be a 50MB limit per file in DAV (ha ha that should have been a huuuuge number for 1996). But it seems it can be changed.

Why do you say that?

My guess is that you've been googling and once again have found some information that only applies to a specific product's implementation of WebDAV and once again haven't bothered to try to understand the context of the information.

Maybe read the WebDAV specification instead.

2 hours ago, msd said:

This is my component for LZMA: https://github.com/ccy/delphi-zip. and if someone can check the 64-bit setup, it will be great.

It's a private repository... and why don't you migrate it to 64-bit yourself?

AFAIK the zlib library that TZipFile wraps does not support LZMA compression.

If you google for "delphi lzma" there's plenty of other solutions.

3 hours ago, dummzeuch said:

Hm, in that case the IDE should not be allowed to push itself into the foreground when it hits a breakpoint or catches an exception while debugging a program, when a different program (not the one being debugged) is the foreground window?

It makes better sense when you've read the documentation...

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow

Quote

The system restricts which processes can set the foreground window. A process can set the foreground window by calling SetForegroundWindow only if:

• All of the following conditions are true:
  • The calling process belongs to a desktop application, not a UWP app or a Windows Store app designed for Windows 8 or 8.1.
  • The foreground process has not disabled calls to SetForegroundWindow by a previous call to the LockSetForegroundWindow function.
  • The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
  • No menus are active.
• Additionally, at least one of the following conditions is true:
  • The calling process is the foreground process.
  • The calling process was started by the foreground process.
  • There is currently no foreground window, and thus no foreground process.
  • The calling process received the last input event.
  • Either the foreground process or the calling process is being debugged.

It is possible for a process to be denied the right to set the foreground window even if it meets these conditions.

And as is usually the case with things like this, Raymond Chen has words:
https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19083

1 hour ago, FreeDelphiPascal said:

Sorry. I took only one snippet, but you can find many

Sigh. Did you actually read the posts you highlighted? None of them are relevant to you.

1 hour ago, FreeDelphiPascal said:

I will look anyway if Indy has support for it.

You do not need Indy to support it. You just need to be able to handle HTTP requests on the server and send requests from the client. Your server implementation will be completely custom to your application (like every other WebDAV server (which is also why you won't find a standard WebDAV "component" on any platform)) and since you will not be using a standard WebDAV client application, your client implementation might as well also be completely custom. If there's an Indu client component that can do what you want then sure, use that.

WebDAV is a very simple protocol and would be easy to implement using standard HTTP components.

51 minutes ago, FreeDelphiPascal said:

I have yet to see if WebDev allows this kind of user access.

There's nothing special about those requirements. I would think most WebDAV implementations have similar requirements.

User authentication is handled in another layer (pretty standard http layering). The WebDAV layer gets user info from that layer and decides what the user is allowed to access and do.

1 hour ago, FreeDelphiPascal said:

I also see a problem with the speed if you have thousands of files and folders. I don't know how much is webdev like ftp, but navigating via FTP through a dense structure of files/folders can be quite slow.

I am considering sending the whole folder tree to the clients.

What would a user do with a list of "thousands of files and folders"?

This sounds a bit like one of my current clients who as a requirement specified that "the grid must be able to display and scroll through a million rows without any lag"... I mean I could limit the grid to 10,000 rows and nobody would ever notice.

Regardless, I don't see why sending a list of "thousands of files and folders" would become a performance problem. Regardless of what solution you go for, it's the same information that is going to be sent over the wire.

Anyway, it sounds like you are rubber-ducking a bit here and it would probably be smarter to first figure out what it actually is you want to do before asking about how to do it.

19 minutes ago, FreeDelphiPascal said:

I don't think I need to implement the full protocol in Delphi/Indy. I don't want/need to be compatible with other WebDav programs.

But I can learn from it!
Thanks!

 

 

 

I don't know why you quoted that specific document without specifying the source:

https://support.netdocuments.com/s/article/360044231332

It's just some CMS service provider notifying its users that it no longer supports WebDAV. WebDAV isn't going anywhere; It's just a protocol standard.

It sounds like you are reinventing WebDAV...

40 minutes ago, FreeDelphiPascal said:

the first client that requests the file, gets read-write access. The rest of the clients only get read access.

Bad idea, IMO.

Supposedly a client that has acquired read-access will expect some kind of file stability. It would make more sense to make write locks exclusive and have read locks block the acquisition of write locks.

I have just released version 3.1.2 with the following changes since 3.0.1:

• map2pdb can now consume JEDI jdbg-files.
• A rare overflow bug in the MSF writer has been fixed.
• The map parser can now handle the slightly different files produced by beta versions of Delphi.

The big change here is the ability to create pdb-files from jdbg-files. You can thank Stefan for being so annoying that I finally caved in and implemented it to get him to shut up about it.

This means that it is now possible to profile Delphi's run-time packages by converting the jdbg-files bundled with Delphi and binding the produced pdb-files to the bpl-files.
It's as easy as map2pdb -bind:rtl290.bpl rtl290.jdbg

Because of a bug in the JEDI tool Embarcadero uses to convert from map to jdbg, some symbol names produced from Embarcadero's jdbg-files may look a bit strange. It's a minor issue that has no impact on the functionality and there's nothing I can do about it since the original map files aren't available.

Get it while it's hot:

https://bitbucket.org/anders_melander/map2pdb/downloads/

Here's an example from Stefan showing an application using the rtl290.bpl run-time package being profiled with VTune:

7 minutes ago, dummzeuch said:

Even today there are so many people with superstitions around, that releasing a version containing the number 13 might actually cost them some customers. I even have the impression this part of the population is growing rather than shrinking.

I wish you would change your screen name; If you calculate the Scrabble value of it, using French Scrabble, you get... 26 which, as everyone knows, is twice as unlucky.

If losing customers due to superstition really is that big of a problem they should just give up and go do something else.

7 hours ago, dummzeuch said:

You can bet they will. They always did wherever that number was about to turn up anywhere.

That "joke" is getting a bit old, to say the least. Maybe it's time to evolve and not do that for once.

10 minutes ago, Yaroslav Brovin said:

Discount for English version - 150$.

How do you justify the price difference between the English and the Russian version?

English: USD 550-150= USD 400
Russian: 4*USD 65 = USD 260