Mike Torrettinni

2 minutes ago, Stefan Glienke said:

Indeed broken since after 10.2.3, can repro the F2084 in the evaluator in 10.3.3, 10.4.2 and 11.1

Hm, quite disappointing, but maybe this is very rarely used the way I use MidStr, or perhaps MidStr is on the way to be deprecated and they don't want to waste time on it.

Delphi 11.1, no patch 1 installed, yet.

Can someone confirm they get same/similar debugger bug in this example code:

uses System.StrUtils;

procedure TForm1.Button2Click(Sender: TObject);
var
  vPos1, vPos2: Integer;
  vLine, s: string;
begin
  vLine :='testingcompiler';
  vPos1 := 5;
  vPos2 := 7;
  s := MidStr(vLine, vPos1 + 1, vPos2 - vPos1 - 1);  <-- Park cursor here and copp MidStr call to debugger
end;

Run and park on MidStr() call and copy the expression to debugger. I get an error F2084 Internal error... instead of 'n' in watch value:

I really hope is just my copy and perhaps reinstall or patch 1 solves this.

No problems with this code in 10.2.3

On 4/27/2022 at 5:46 PM, Ian Branch said:

Obviously respondents would need to be able to tick multiple versions.

If you decide to go ahead with the survey, try to give us more options, for example I use D2006 every few years for a few weeks. So, when I use it, I use it 75%-100% of the time, the rest is split between D10.2 and now D11. D11 is the only one that I compile for 64bit, and Linux.

Perhaps you can frame the purpose of the survey, like if you are you planning to develop something and sell to Delphi developers, in that case I would select D11 as the only version I would be interested in any new component/tool to use with.

On 11/12/2021 at 7:57 AM, Tom F said:

Do you think we should we just give up on ever getting an updated Bookmarks plugin (formerly from Parnassus) that works in Alexandria?

It seems very likely this is the case.

You would think David would remember all past projects acquired by bigger companies with promises of 'gold' and in reality they got used for marketing, then pushed aside and lost in space, in very short time.

Did you try this component? I would be interested if it has faster implementation of search and highlight - faster than current TRichEdit.

9 minutes ago, Edwin Yip said:

Thanks for the heads up, Mike. I removed the fb details from the link in my post, however, it seems that your quoted reply still contains the details 😄

OK, fixed too 🙂

1 hour ago, Edwin Yip said:

 

https://github.com/59079096/HCView-Pascal 

The link has some facebook details... if you wanna remove it.

2 hours ago, Stefan Glienke said:

1. When you assign the string result to a local variable the compiler directly passes the local variable as that hidden result var parameter - hence you will see the output 'hellohellohello' 

Thank you, very clear example.

I was trying to see if compiler will make mistake or get confused if I put a 'surprise!' in there, like:

procedure Main2;
var
  s,s2: string;
begin
  s := Test;
  s := Test;
  s2 := s;
  s2 := Test;
  Writeln('s  = ' + s);
  Writeln('s2 = ' + s2);
end;

but still works as expected:

1 hour ago, PeterBelow said:

The compiler initializes the string variable passed for Result at the point of call, so it will always be valid. It is not guaranteed to be nil (string.empty), though. The compiler may reuse another hidden local variable used previously in the calling method.

 

Such things are documented in the Delphi Language guide, see https://docwiki.embarcadero.com/RADStudio/Sydney/en/Program_Control_(Delphi)

Thanks, I did read the link, but didn't get to the same conclusion as you describe it:

1 hour ago, PeterBelow said:

The compiler initializes the string variable passed for Result at the point of call, so it will always be valid. It is not guaranteed to be nil (string.empty), though. The compiler may reuse another hidden local variable used previously in the calling method.

I think I understand a bit better now, the difference of compiler initialization and our initialization of vars in the function.

Is my understanding correct, if I say it like this (in non-expert language):

the 'the compiler initializes' is not the same as we initialize local vars with localtIntVar := 0; or Result:= '';. The compiler initializes variables (including Result) (like assigns registers or memory pointers, or whatever, to each var) and we initialize the value of these variables.

Strings local vars are managed, so compiler initializes variable and the value to ''.

Integer local vars are not manage, so compiler only initializes variables and we need to initialize the value to 0 or whatever we need, manually.

And in case of function Result, the initialization doesn't really just point to a random/undefined memory space, but it might keep a list of previously ready-to-be-reused hidden variables or it uses some other location, but never actual valid data. (as Frost pointed out this would be fundamental flaw if it changed the valid data)

Right?

It's quite common to initialize Result of string function with SetLength(Result, len) and then work with the Result, like:

// Switch Upper to lower and lower to Upper case
function SwitchCase(const aStr: string): string;
var i: integer;
begin
  SetLength(Result, Length(aStr)); // without Result := '';
  for i := 1 to aStr.Length do
    if CharInSet(aStr[i], ['a'..'z']) then
      Result[i] := UpCase(aStr[i])
    else
      Result[i] := LoCase(aStr[i]);
end;

And looking at debugger:

the Result holds some data, which is overwritten with the code after SetLength. Of course if we initialize Result := ''; before SetLength, then Result is a new string.

Before Result is initialized with SetLength, it is undefined, so it points to a random memory location, I guess.

Is that always unused memory location or is there a danger that we are actually overwriting valid memory block (part of other string, or long array.,..) and can cause issues in the running code?

I only use Indy for software update check, so very minimal. And I was looking into Indy status the other day and it seems pretty active, with recent bug fixes:

https://github.com/IndySockets/Indy/issues?q=is%3Aissue+is%3Aclosed

Didn't know about any new features implemented, but recent bug fixes are definitely a sign this is an active project.

But I guess if I needed TLS 1.3 support, would probably be more worried about when and if it will be available.

@Pat Foley and @pmcgee thanks for the solution using a Set, but I can't really use them because the list of controls exceeds 256 items.  But very good timings, will see if I can use the logic for some smaller pool of data. I have many that are definitely less than 100 count.

2 hours ago, pmcgee said:

I can't seem to get rid of this extra image ...

If it helps: when you add images they are listed below the post as Uploaded images and you can delete them by clicking on delete icon, if you can't delete them within the post:

55 minutes ago, Bill Meyer said:

Specifically, what is shown by a profiler?

I pasted 2 profiler results in first post and you can see replacing IN with OR shaves off 0.5s. It's part of a search feature and verification of data type is significant portion of search runtime. 

1 hour ago, PeterBelow said:

Are you also aware of the legal repercussions that may have? It's of course OK if you only use the program on your own computers, but if you sell it to clients it opens you up to litigation. If the program is infected on the client's computer and then causes damage there the client could sue you, since the program does not follow accepted safety standards for software. Depends on your countries legislation, of course.

That's interesting. From all the stuff that you can sue/get sued in US, also usually about the software the issue is late/non delivery, extra charges, quality... but, I've never heard of a case like this. Do you have any links about such case? What was the actual lawsuit about, what kind of the damage was caused? What country was that?

On 3/21/2022 at 1:32 PM, Stefan Glienke said:

then look at instruction timings, read up on macro-operation fusion and data dependency

Thanks and after trying to grasp the content of the links I realized I shouldn't be using micro optimization phrase at all! Will drop it from next topics, as I'm interested in whats faster but definitely I'm out of my comfort zone and not ready to dive into this topic the way it was expected because of the title.

31 minutes ago, Lars Fosdal said:

Typed consts are not consts unless you type them on the right side of the expression.

I knew there is a difference between them, more for strings - in one of my benchmarks using string typed consts resulted in faster runtime vs non-typed consts.

But still don't know to what extent it affects every case that uses typed conts.

Re-reading this thread, but still trying to process all the info there:

Well, even with a real const in a record, I still get @SetElem:

type
    TCtrls = record
    const
      ButtonID: integer = 2;
      FormID: integer = 4;
      ListBoxID: integer = 6;
      TabControlID: integer = 8;
      ComboBoxID: integer = 10;
    end;

I tried with a var of TCtrls type, just in case if it makes a diff, still the same:

var xCtrls: TCtrls;

Just now, Lars Fosdal said:

type
  xConst = record
  const
    ButtonId = 1;
  end;

procedure Test;
var 
  bId: Integer;
begin
  bId := xConst.ButtonId;
end;

 

OK, I think I see it now, const in a record vs const record.

8 hours ago, Stefan Glienke said:

No, that is a const record - which is not really const but just a write protected variable. You know how to declare integer consts, do you?

OK, const record is not the same as const, wasn't aware of that - then how did you manage to get a integer const prefixed with xControlsRec, like xControlsRec.ButtonID? If I try a const with a dot in the name, it doesn't compile:

const xCtrls.EditID: integer = 1;

it complains:

[dcc32 Error] Project1.dpr(93): E2029 '=' expected but '.' found

If I set integer consts like this:

const
  xButtonID: integer = 2; xFormID: integer = 4; xListBoxID: integer = 6; xTabControlID: integer = 8; xComboBoxID: integer = 10;

the runtime is similar as before, still uses @SetElem:

This is D10.2.3.

When trying this in D11.1 in VM, it generates the same asm, so not sure how you got your completely different asm code:

13 hours ago, Stefan Glienke said:

when using consts

Something like this, right?:

const
    cControlsRec: TControlsRec = (EditID: 1; ButtonID:2; CheckID: 3; FormID:4; FrameID:5; ListBoxID:6; PageControlID:7; TabControlID:8; RadioBtnID:9; ComboBoxID:10 );

When I use const cControlsRec, the difference is not that big and @SetElem is called anyway

non-const:

const:

You can see my asm code is quite different than yours. Is it possible because of Delphi versions? I still use 10.2.3.

@Stefan Glienke I got a little 'nudge' that my reply above was rude and seems inconsiderate to your help in the past. I hope you didn't read it that way. I took your comment as if my benchmark was waste of time, but re-reading it, I see what you meant.

Anyway, I think I was always appreciative to your help and expressed it in past topics. Don't feel like you need to help me in every topic, I have no problem getting no comments on my benchmarks, I take it as "nothing big is wrong with it" or "it's so wrong, it would take me too long to explain", I welcome both options, because they mean either I did something right or I'm slowly getting there.

The 64bit projects will go through a lot of benchmarks, so I will probably post more observations like this one, so be on the lookout for something that peeks your interest, I will not be offended if you skip the rest.

Also, come on, you can't say that Moe, Larry and Curly's reprisal of 'First!' comment wasn't worth at least a little chuckle at my expense... I know I did, he he.

20 minutes ago, Stefan Glienke said:

I am usually happy to help people improve in that subject but seeing that you simply ignored half the advice given to you before in countless similar threads I consider this a waste of time.

I recently reached the age bracket that many would probably consider 'unteachable', so it's not on purpose.

I was away from Delphi for a couple of months and now preparing projects for 64bit, so it's fun to do some benchmarking again.

If I can make some good progress, like in this case reducing some process runtime by half a second, even better. This process is part of search feature, so user interaction feature, and any speed improvement is very useful because users notice them very quickly.

Interesting to know other compilers can parallelize a simple loop. I thought you need to split and parallelize manually, like Delphi.

Can you imagine Delphi had a flag:

parallel=True

and does everything for you. I guess Numba developers saw TTask, TThread, OmniThreadLibrary... and just decided to implement a simple flag. Nice!

Why Tokyo? Alexandria's been out for months.