dummzeuch

7 minutes ago, Sherlock said:

I feel you got a typo in your code, @dummzeuch 

	type
	  TNullableDateTime = record
	  private
	    FIsValid: INullableTypesFlagInterface;
	    FValue: TDateTime;
	  public
	    function Dump: string;
	    // other methods and operators
	  end;
	 
	// ...
	implementation
	// ...
	 
	function TNullableDateTime.Dump: string;
	begin
	  if IsValid then
	    Result := DateTimeToStr(Value)  // <- should be FValue?
	  else
	    Result := '<invalid>';
	end;

Should the Dump function not refer to FValue?

Value is a property which I have left out in the shortened type declaration. The same goes for the function IsValid, that checks if the field FIsValid is assigned. So, strictly speaking you are right, the example code won't compile. But the point was to show how to implement a Dump method in principle.

If you want to have a look at the actual imlementation of TNullableDateTime, see the unit u_dzNullableDateTime in the dzlib svn repositiory on SourceForge.

16 minutes ago, dormky said:

Does delphi output other intermediate files that I could check ?

Hm, maybe the map file?

Do you build dcu files containing debug information? If yes, the debug information contains a line number, so the size might change if the number of lines containing code changes. There might be other kinds of information in the dcu which are similarly affected. The dcu format isn't documented, but I remember a project on GitHub that could read them - at least get identifiers out of them - so maybe that project also contains some kind of documentation or at least parsing code that might shed some light on this.

51 minutes ago, A.M. Hoornweg said:

Can't you make a read-only property out of it instead of a plain method? That way you could make it show up in the watch list of the debugger.

The same would work with explicitly adding the method call to the watch window and allowing side effects. But the point is to show the values in all debugger windows and hints not just in the watch window.

You just gave me an additional idea though: The display value could be cached in a string field which gets updated when the record's value changes, and the visualizer would then just read the field. This would be much faster in the visualizer as no code in the debugged program needs to be executed. But it could significantly slow down the executable in debug mode, depending on how often the value changes.

After playing around with debug visualizers, I found that there is a very simple way to provide a visualiser for many record types: Just add a special method (I called it Dump) to those records that returns a string that you can then evaluate in the debugger and display in the debug windows.
There are two caveats though:

read on in the blog post...

Closing the main form of an application terminates that application and thereby also frees that form and all other forms. The main form of an application is defined as the first form it creates and that cannot be changed easily. So, creating a login form as the first form, has the side effect of terminating the application as soon as it gets closed. which is usually not desirable. Therefore such a login form should never be the first form an application creates.

(Unless something has been changed over the years and my experience is outdated (again).)

I have seen that happen even without using GetIt. I think it is related to converting the files from LF to CR/LF style line ends. But I never actualy verified this, so I might be wrong.

10 hours ago, Anders Melander said:

This one maybe: https://blog.synopse.info/?post/2011/04/14/Enhanced-logging-in-SynCommons

via: https://stackoverflow.com/a/7216537/2249664

No, at least if I remember correctly that the generated format was compatible to jcldebug.

But thanks for the link anyway. I have wanted to look into synopse logging since I read about it in that blog post ... OMG: 2011? > 10 years ago!

On 3/15/2024 at 9:52 PM, Ian Branch said:

LineByLevel - Whilst I could use it in my code by adding JCLDebug, I wanted to have it as a function in my library.  If I used it from my library I got the line number in the library, not the Apps code.

You should get the line number of the original function if you pass 1 as the parameter to LineByLevel instead of the default 0.

Just keep in mind that calling GetLocationInfo is rather costly. It's not meant to be called all over the place.

If I remember correctly somebody claimed to have improved the jcldebug file format to make it much smaller and lookups faster. Unfortunately I don't remember who it was and where I read about it. It's quite possible that he donated the code to the jcl in the mean time

1 hour ago, Ian Branch said:

I had a look at that previously.  I may be missreading its use but it seems that JCLDebug relies on an Exception for something like this to work:

function GetCurrentLineNumber: Integer;
var
  ModInfo: TJclLocationInfo;
begin
  ModInfo := GetLocationInfo(ExceptAddr);

  Result := ModInfo.LineNumber;
end;

 

It does indeed. It should also be possible to write a function that reads its own return address from the stack and then returns this value as the result. This then could be passed to GetLocationInfo. I'm not sure how to implement this, but it shouldn't be rocket science.

Edit: There is System.ReturnAddress, introduced with Delphi XE2, which gives you just that, so

function GetCurrentLineNumber: Integer;
var
  ModInfo: TJclLocationInfo;
begin
  ModInfo := GetLocationInfo(ReturnAddress);

  Result := ModInfo.LineNumber;
end;

Should do the trick (untested)

Edit: Just tried it. It works, at least in Delphi 10.2.

Edit: JclDebug already contains such a function called LineByLevel.

No idea. I currently don't find the time to do anything on it.

I know that GExperts can cause this. Unfortunately I so far was unable to find the actual problem. It seems to be connected with using the formatter very frequently.

dxgettext can translate ressource strings. It does so by hooking several RTL functions, one of them being LoadResString.

Last time I looked it only worked for 32 bit Delphi, unless somebody has ported it to 64 bit by now.

25 minutes ago, Gustavo 'Gus' Carreno said:

Writing 5 paragraphs with a conjecture of how to do it ... Instead of just resting on your thought experiment, why don't you put your money where your mouth is and prove what you claim?

I can't be bothered, sorry. I was only "thinking aloud". Maybe I shouldn't have written it as a comment, though.

I wonder how much of the time depends on where the file is read from: RAM Disk, SSD, HDD and for the latter whether it's already in the cache or not.

2 (American billion) = 2.000.000.000 lines of about 15 characters makes it about 30.000.000.000 bytes, that's 30 Gig of data to read, split into lines, then split into name and value and then aggregate by name.

32 bit Delphi won't be able to handle that with Stringlist because it won't fit into memroy, I wonder whether there are any bugs in the RTL that would prevent that with a 64 bit Delphi program. But anyway: Using a StringList is probably not the most efficient way of reading the data. Plain old ReadLn would likely do the trick faster. Some kind of buffering might speed it up and maybe parsing based on a PChar pointer rather than strings.

Then selecting a suitable datastructure, probably some hash based dictionary.

The rest is not much of a challenge.

There is also Delphi Custom Containers Pack. For some types of components I prefer that over frames.

Delphi 12 creates an entry in the (Open Shell) start menu directly under programs.

I don't want that entry that so I deleted it.

But every time I start the Delphi 12 IDE that entry is added again.

This is really annoying. Is there a setting somewhere that controls this?

I was just about to ask the same as @Der schöne Günther: Why did you put those two dots in front of AsString? That might confuse the watch window.

1 hour ago, Brandon Staggs said:

You are not going to get Delphi with Garbage Collection

We already had that: It was called Delphi for dotNET. AFAIK the last Version was Delphi for dotNET 2007. Somehow it didn't catch on.

4 hours ago, Cristian Peța said:

Linux and Windows sources are C, C++, Assembly....

Some parts of the Linux kernel are being converted to Rust. Also, many parts of the Linux distributions are written in Python oder even shell scripts. Some Perl can still be found there too.

Or, if you prefer using the mouse: There are Build Sooner / Build Later entries in the popup menu.

1 hour ago, Uwe Raabe said:

Hard to believe...

On my computer it works exactly that way.

1200 pixels:

960 pixels:

Maybe there is some configuration setting that causes this. I don't remember changing anything though.

2 hours ago, Uwe Raabe said:

Interesting. That isn't visible in my browser:

It depends on how wide your browser window is. Yours is too narrow, so you get the condensed view. I get that too if I move the browser window to half of a HD monitor -> 960 pixels wide. If I make it a bit wider, I get the full path. That's called "responsive design" I think, and I usually hate it. Be we digress.

6 hours ago, eivindbakkestuen said:

Hi, just a heads up... the Open File dialog no longer saves any size or position info, it always pops up too small in this release.

 Please file a bug report on sourceforge.

1 hour ago, Pat Foley said:

Observations 12 Patch vs 11.3

1. 12 eats inifile lines commented out using ;  Unsure if the IDE or program made is doing it. 

 

That has been the case since forever when using TMemIniFile rather than TIniFile (the latter uses the ancient/deprecated WinAPI Get/SetPrivateProfileString). So if that has changed from 11.3 to 12p1, this probably means that somewhere somebody has switched from using TIniFile to TMemIniFile.