Attila Kovacs

ofc some of the const's I had to declare as it did not compile at the beginning, Berlin U2. svg.7z

yippiii, it works. nice one @Mahdi Safsafi

As I first mentioned the in the AV reading address 0x00000001, the "1" is the parameter D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR. Change it to D2D1_SVG_ATTRIBUTE_POD_TYPE_FILL_MODE and you will get AV reading address 0x00000002. So I thought that the wrong "SetAttributeValue" is called, so I changed the order of the "SetAttributeValue"'s => swapped the last two. But as I can't see any changes in the image and @Mahdi Safsafi showed in IDA that this is a completely different call, I'm not sure what is going on. But it's a good start for you to sort it out.

looks like I'm being ignored here. change the order of the last 2 SetAttributeValue()'s in the interface, no AV but I can't see any changes, maybe you would know why and see if it helps.

why don't you debug into the dll? "read of address 0x000000001" where "0x000000001" is D2D1_SVG_ATTRIBUTE_POD_TYPE_COLOR so just my 2 cent's the overloads are mixed up

The first time I saw your idea I did not see the benefits but after adding some useful information to the form it could be a great extension though. However, I'm not the OTA guy, so my version is using heavily the IDE itself, but the most could be achieved through the official way. (Assumed you will get the plugin API sources for Parnassus, which is not anymore available since emba purchased it....) or a bit more info:

yes, less, and slower, the rest is the same codegen -> less asm, slower exec, how's that? OoOE? Aligning?

by the way, if you look at the last code pasted by me, if you remove if len = 0 then exit(S); at the beginning, it's the same codegen and will be ~4% slower. Of course testing with non-empty input. Early triggering of OoOE?

same here, "Sorry, an error occurred trying to log you in - please try again." however I'm fine with it

if you don't have "Plan B", you should not try to catch exceptions

Like Delphi?

And you can fire up a new project having everything needed in just seconds. Regardless if for testing/new feature/completely new app etc...

Turn this to an advantage. It will pay off.

I don't.

I've got tired restarting the IDE because of the recurring AV when I was adding a new unit/form etc.. to the current project. Looks like it was fixed in 10.3 https://quality.embarcadero.com/browse/RSP-15471 I don't know, because I'm still on 10.1 U2, and there will be never an official patch for that. The problem is crystal clear: 2203A97A E861C7E6FF call $21ea70e0 ; FindTopEditView 2203A97F 8B4044 mov eax,[eax+$44] not checking against "nil" in EAX. (Why this returning nil after an amount of time is a different question and it's not something we could ever fix in the binaries) the fix is almost as easy as spotting the problem, detouring the call, and do some check: procedure PatchStructuralHighlighterCode; asm call FindTopEditView TEST EAX, EAX JNE @ok call PErrorProc // debug logging jmp ReturnNil @ok: jmp Return end; Now, @FindTopEditView, @ReturnNil and @Return are version specific values, obviously, I have the addresses only for my IDE version. As I don't feel the urge for maintaining and supporting fixes for Delphi but I would share the details if anybody is interested.

The Oracle: What’s really going to bake your noodle later on is, would you still have broken it if I hadn’t said anything.

I'm wondering if you are also getting a big fat AV for ctrl-b on the welcome page if parnassus is installed. 10.1U2

@Mike Torrettinni And the same code can perform differently on different CPU's. Because the "integer iterator" does nothing else just calculates the pointer + i over and over. So basically it's a shortcut.

@Stefan Glienke thx, updated. Strange, with 10.1U2 it's definitely much faster if not storing it. O+ W- asm: ec4.txt

Slightly modified Stefan's beautiful routine. If I did not screw it up, it's faster because of comparing against the stack (parameters aChar1, aChar2), (I can't explain that), and omitting "sr" leaves more register for the compiler, which was a speed boost again. Also, the initial "while" became a "repeat until", and instead of "P^ = #0" there is a " P = ep". function ExtractContent4(const S: string; const aChar1, aChar2: Char): string; var P, ep, r: PChar; len: integer; begin len := S.Length; if len = 0 then exit(S); SetLength(Result, len); r := Pointer(Result); P := Pointer(S); ep := P + len; repeat r^ := P^; if P^ = aChar1 then begin repeat inc(P); until (P^ = aChar2) or (P = ep); end else inc(r); inc(P); until P > ep; SetLength(Result, r - Pointer(Result)); end;

no-no, the compiler runs out of registers if do so, always testing separately Nice routine. I don't know why but if you use parameters instead if consts it performs even better. (Despite comparing against the stack) ExtractContent(const S: string; const aChar1, aChar2: Char); this boost it even further: var zero: Char; zero := #0; until (P^ = aChar2) or (P^ = zero); or even better: until (P^ = aChar2) or (P = ep);

Looking into the Move() implementation, wth is happened to rep movs*? Is it too slow nowadays?

You are right, even around the Move() was some string magic. With passing PChar is even faster. As for the result type, I'll let it for Mike to tune it.

@Mike Torrettinni Slightly modified, wasn't round everything.

Player 3 entered the game (edited) function RemoveTextBetweenChars(const aString: string; const aChar1, aChar2: Char): string; label exit; var c: integer; P, start, res: PChar; begin if aString <> '' then begin SetLength(Result, aString.Length); res := Pointer(Result); P := Pointer(aString); c := 0; while True do begin start := P; while P^ <> aChar1 do begin inc(P); if P^ = #0 then begin Move(start^, res[c], (P - start) * SizeOf(Char)); inc(c, P - start); goto exit; end; end; Move(start^, res[c], (P - start) * SizeOf(Char)); inc(c, P - start); while P^ <> aChar2 do begin inc(P); if P^ = #0 then goto exit; end; inc(P); if P^ = #0 then goto exit; end; exit: SetLength(Result, c); end; end;