Wagner Landgraf

Hi all, I'm getting call stack information using JclDebug.pas, and I can't get information about line number for my own units. In the (cropped) call stack below, you can see that there is line number information for Delphi units (System.pas, for example), but not for the other units. I have set several compiler and linker options, like stack frames, debug information, map debug info, etc. (see screenshot). JclDebug settings is set to raw, but changing those doesn't seem to make any difference (didn't try too hard):. JclStackTrackingOptions := [stStack, stRawMode]; Does anyone have any idea why it can't get line number? (01C9E319){producao.exe} [0214F319] fpdf.TFPDF.GetStringWidth + $E5 (01C9E314){producao.exe} [0214F314] fpdf.TFPDF.GetStringWidth + $E0 (00006566){producao.exe} [004B7566] System.ErrorAt (Line 5914, "System.pas" + 3) + $4 (000065AA){producao.exe} [004B75AA] System.Error (Line 5925, "System.pas" + 1) + $7 (01C9E314){producao.exe} [0214F314] fpdf.TFPDF.GetStringWidth + $E0 (01CB8FBA){producao.exe} [02169FBA] fpdf_ext.TFPDFExt.WordWrap + $15E (01CB9A86){producao.exe} [0216AA86] fpdf_ext.TFPDFExt.TextBox + $1A2 (01CA46AC){producao.exe} [021556AC] fpdf.TFPDF._out + $5C ...

That's the mystery, isn't it? First, thanks a lot for the detailed test. So let me try to summarize what you found out: in Release config, even if you check "Debug Information" option to True (in Project Options, Building | Delphi Compiler | Linking), it doesn't generate line number, unless you explicitly add the `{$D+}` directive in the source code, is that correct? If yes, I think finding out the reason might explain what's happening here. For the record, I'm using *Debug* config, and "Debug Information" is set to True. But still, I can't get line numbers. So maybe what's happening in my Debug config is the same as it's happening in your Release config?

And why it can't retrieve the line number from generated map files from my units, but can from Delphi units?

Sorry, by "DCU" I mean "debug information".

If that would be the case, it would not show line number information for Delphi units, isn't it? It's "modern" DCU. It just looks that Delphi DCUs have some additional information that my DCUs don't have, but I don't know what that would be.

No, there isn't.

Probably that's what is happening here. I had an older VTune version that worked, and now I installed Tuen 2024 which doesn't. (Of course, "working" was very limited, it didn't support any hardware assisted profiling, but at least the Hotspots with no hardware was working, just to profile application logic). The problem is: where the heck to I find old VTune versions to install? I search everywhere, and I can't find any information. Closes I found was to register for Intel account and go to some download/registration center, but nothing is displayed there are it only lists "registered" products. Does anyone happen to have an old offline installer of 2023, maybe 2022 VTune?

Has anybody tried to use VTune inside a VM with M1 (ARM MAC)? I recall I was able to use it, but I rebuilt my VM and now I can't make it work. I get this message: [Instrumentation Engine]: [tid:15552] Failed to allocate Injector, Error = INJECTOR_ERR Pin is exiting due to fatal error I just couldn't find anything relevant about this issue when googling for it. Even the VTune matrix demo doesn't work (so not related to map2pdb).

Do you have reliable sources for this? I don't know those tools specifically, but that's basically what a "no-code" solution is. Otherwise it would be a "code" solution. 🙂

One of the most famous authentication SaaS is Auth0. Never heard about descope before. While those tools are really full-featured, they can get expensive pretty fast if your app grows. TMS Sphinx is our (TMS Software) alternative Delphi library for those solutions, where you build your own "descope-like" or "auth0-like" server yourself: https://doc.tmssoftware.com/biz/sphinx/guide/ Things like "adding custom fields to user profile" would obviously not be an issue, since you have full control your authentication server. TMS Sphinx doesn't have all those enterprise features they offer, of course. But it's still OAuth2 compliant and has many features for an authentication server that servers most purposes, even for multi tenant, public SaaS services.

That is not a "workaround" nor it's a "Sparkle dependency on Windows". Sparkle offers multiple ways to create an HTTP server, using different frameworks/APIs: Indy, Web Broker, http.sys... Of course, http.sys is a Windows kernel/API, so obviously it will only work on Windows. So if you want to create an HTTP server on Linux, you can't use http.sys, neither with XData nor any other framework in the known universe.

The point of the topic is moot, as you’re wrong. TMS XData does support Linux.

I didn't understand your statement. Isn't that the exact original question? This is what I see in original post: " But for other Delphi user's using exactly the same project NaN is displayed ! Why ? Does any Windows language settings can do it ? "

It doesn't work in Windows ARM. In both cases, the output is Nan.

I did. It works - on Safari. After you mentioned I tried in Chrome, and then it doesn't work. But it's not a 404, instead a connection refused. Looks like it's because the link is insecure HTTP, which is rejected by Google but somehow Safari forces it to be HTTPS - which then works.

That link works fine for me.

I've seen such pattern all the time, since many years already (it started right after the Delphi 2005 fiasco). I often agree that "rewrite our software in X" is usually a bad idea. And I've also seen that happen - many companies who tried to migrate to another platform failed, either spending lots of money, either not being able to develop a product as good as they have before in Delphi, and many other failure stories. If you think about it, even TMS history had similarities with that. We were a pre-Delphi 7 component vendor company, and after that period, many component vendors went doing something else of "migrated" to .NET. Of course there are successful stories of migration as well. But I understand the companies: I believe what scare them is Embarcadero behavior and their dependency. If they simply snap their finger and decided "no Delphi for you", many companies will have problems. But "no Delphi for you" I mean shutting down, not fixing bugs, not updating, whatever. It's a dangerous dependency. You might say "well, there are already doing that by not fixing bugs" and I would reply saying that that's the #1 reason I see companies *today* willing to migrate away from Delphi.

Considering the following code: try except on E: Exception do begin DoSomething; raise; end; end; Is it possible, in "real" applications (*), that in the case of something bad happens, DoSomething method does not execute? (*) I know that any object can be raised as an exception, so I understand that in theory, you can have exception objects that do not inherit from Exception class. But my question is more in this way: I know that my code doesn't raise any exception object that does not inherit from Exception. Also consider that third party libraries used do not do that. Is it still possible that DoSomething method doesn't execute? Say, for example, if some really low level error happen, Windows API calls, DLLs, etc.?

That is not needed. The else is implicit in the try..except block, if an exception is not trapped in the "on" clause, it's re-raised. The point here is if you have code that needs to be executed, like a transaction rollback, or a log message that needs to be generated, etc.

Mobile is not the case here. But for all intents and purposes, it's clear, from the responses of some helpful gentlemen here, that "on E: Exception" is not a 100% safe approach.

Thank you very much. That's the kind of situation I was wondering. So it's possible, especially because in the end Delphi apps are calling DLLs often. I just don't know the odds of such situation to happen.

Sure, that is already done. I was just wondering if that was a possible thing to happen. But it looks like that's not the case.

I've detected an odd behavior in an application that I can't explain yet why it happened. I searched for database transaction management as I felt it was related to it. All the transaction-related code has the usually pattern try..except, having a Rollback in the except block followed by a raise. Then I found there was only a single try..except which was constructed the way in my first post. DoSomething would be the rollback. All the other transaction-handling in the application code had the rollback just directly in the except block, not inside the "on E: Exception do". Interestingly enough, the different try..except was in a place that is somehow involved with the error. So I wondered if there might be a remote chance that some error happened, a non Exception object was raised, the rollback was not called, the exception was re-raised and everything continued as usual, but without the call to the rollback.

Assuming this is not sarcasm, as English is not my main language: my question refers to a situation where the application continues executing.

No. You have to be sure your computer is accessible from outside - if you want to access it from outside. This is your config and out of scope for the http config tool.