pyscripter

np_array.SetItem(0) should work. From VarPyth source code: // here we handle a special case: COM (or Delphi?) doesn't allow you to have index properties // on a variant except from a true array variant! So if myVar is a Python variant that holds // a Python list, I can't write something like: myVar[0]! But if the list is a member of a // Python instance, it will work fine! Like: myInst.myList[0] // So, to handle this problem we detect some special names: GetItem, SetItem and Length // that will do the same as: // myList[0] <-> myList.GetItem(0) // myDict['Hello'] := 1 <-> myDict.SetItem('Hello', 1) // len(myList) <-> myList.Length() // we get some bonus with the slices and in operators also: // myList = [0, 1, 2, 3]; myList.GetSlice(1, 2) --> [1, 2] // myList.Contains(2) <-> 2 in myList

Have you seen python4delphi/Tutorials/Webinar II at master · pyscripter/python4delphi (github.com)? The VarPyth demo shows how to work with numpy arrays (two way link).

indeed.

Study demo 33 on how to interrupt a running python thread. (TSortThread.Stop).

Yes.

SynEdit has been updated since these demos have been created. I am not sure what version of SynEdit you are using, but the solution to such problems is to open the unit with the form in the IDE ignoring all errors and then save the unit again.

Getit has not been updated. To use the latest version use the Github repo instead.

@balabuevThis appears to be fixed in Delphi 11.1, and I cannot reproduce it anymore. But I cannot see any change that could have fixed that. Any ideas,

A new Word-like spell checking has been added to SynEdit.

I always thought class vars are supposed to be initialized. See also this Stackoverflow question. However in Alexandria 11.1 I got bitten by this: type TMyComponent = class(TComponent) public class var GlobalInstance: TMyComponent ; constructor Create(AOwner: TComponent); override; end constructor TMyComponent .Create(AOwner: TComponent); begin inherited Create(AOwner); if Assigned(GlobalInstance) then raise Exception.Create('TMyComponent is a singleton. You can only have one!'); GlobalInstance := Self; end; When I added such a component to a data module in the 11.1 IDE an exception was raised. It was working fine with 11.0. Was I making a wrong assumption or is this an Alexandria 11.1 bug? Update: My stupid fault. Actually the error has occurred when I closed one project and opened another one with the same component. I should set the GlobalInstance to nil in the desctructor, which I did not. Even then the above approach is problematic if for instance you have have two projects in the same project group using this component. I think this would create a problem. Any better way of having a singleton component without causing issues in the IDE?

The master branch of https://github.com/TurboPack/SynEdit contains the latest version of SynEdit. Apparently, the compiler directive should be {$IF CompilerVersion <= 33} and this has now been fixed. SynEdit strives to be compatible with Delphi Berlin and later. If you find incompatibilities please report them to the issue tracker so that they can be fixed. There were many new properties introduced and some removed, so forms with SynEdit need to be loaded and saved again after installing the new version. Just ignore the errors you get opening the files.

A new feature has been added: Scintilla like indicators.

In d2d1svg.h (Direct2D) there is the following declaration of the ID2D1SvgElement interface: /// <summary> /// Sets an attribute of this element using a POD type. Returns an error if the /// attribute name is not valid on this element. Returns an error if the attribute /// cannot be expressed as the specified type. /// </summary> STDMETHOD(SetAttributeValue)( _In_ PCWSTR name, D2D1_SVG_ATTRIBUTE_POD_TYPE type, _In_reads_bytes_(valueSizeInBytes) CONST void *value, UINT32 valueSizeInBytes ) PURE; D2D1_SVG_ATTRIBUTE_POD_TYPE = DWord; I am translating this as function SetAttributeValue(name: LPWSTR; _type: D2D1_SVG_ATTRIBUTE_POD_TYPE; value: Pointer; valueSizeInBytes: UINT32): HResult; overload; stdcall; But it crashes when it is used. The assembly prolog of SetAttributeValue is 564711F0 6690 nop 564711F2 55 push ebp 564711F3 8BEC mov ebp,esp 564711F5 83EC14 sub esp,$14 564711F8 8B4508 mov eax,[ebp+$08] 564711FB 33C9 xor ecx,ecx 564711FD 53 push ebx 564711FE 56 push esi 564711FF 57 push edi 56471200 8D5808 lea ebx,[eax+$08] 56471203 85DB test ebx,ebx 56471205 6A08 push $08 56471207 0F44C1 cmovz eax,ecx 5647120A 8945F8 mov [ebp-$08],eax 5647120D 5A pop edx Any idea what I am doing wrong? Thanks!

I was trying to improve the performance of SynEdit in handling files with super long lines (e.g. 50K characters). In doing so I came across an unexpected optimization that had a spectacular impact on performance. See this innocent looking function probably written two decades ago (fCasedLine is a PChar): function TSynCustomHighlighter.GetToken: string; var Len: Integer; begin Len := Run - fTokenPos; SetLength(Result, Len); if Len > 0 then StrLCopy(@Result[1], fCasedLine + fTokenPos, Len); end; By measuring I found that this function (called zillions of times) was a bottleneck and replaced it with: function TSynCustomHighlighter.GetToken: string; var Len: Integer; begin Len := Run - fTokenPos; SetString(Result, fCasedLine + fTokenPos, Len); end; The impact was massive. Both SetString and StrLCopy in x64 are implemented in pascal (not assembly) using Move. So initially I was puzzled. However here is the reason. Look at StrLCopy: function StrLCopy(Dest: PWideChar; const Source: PWideChar; MaxLen: Cardinal): PWideChar; var Len: Cardinal; begin Result := Dest; Len := StrLen(Source); if Len > MaxLen then Len := MaxLen; Move(Source^, Dest^, Len * SizeOf(WideChar)); Dest[Len] := #0; end; Can you see the problem? It is the call to StrLen(Source)! In my case the Source was very very long strings, the length of which was unnecessarily calculated the hard way. The lesson here is that you need to identify the bottlenecks by measuring. You may be in for surprises, sometimes pleasant ones,

TStopwatch and occasionally VTune.

I think var SList := Shared<TMyStringList>.Make(TMyStringList.Create(dupIgnore, True, False)); should work.

I asked you to submit an issue at Embarcadero/DelphiVCL4Python: Delphi's VCL library as a Python module for building Windows GUI (github.com), but you did not bother... The modules are built from this directory: python4delphi/Modules at master · Embarcadero/python4delphi (github.com)

Look at the tutorials python4delphi/Tutorials at master · pyscripter/python4delphi (github.com) and demos python4delphi/Demos at master · pyscripter/python4delphi (github.com). You will also find a lot of stuff in python | Embarcadero RAD Studio, Delphi, & C++Builder Blogs

I tried to do something like class Test protected class function GetValue: string; virtual; public class property Value: string read GetValue; end; and I got a compiler error message stating the class property read specifier has to be either a class var or a static class method. Any idea about the reason for this restriction?

This looks like an inconsistency in the language with regard to class methods and class properties. And I don't think it is documented.

You access class properties through a class or an instance reference. That reference could be passed to a virtual class getter. Why do they have to be static? This is my question. A related question. How do virtual class methods work? Is there an equivalent to VMT for classes? By the way this works correctly: class Test protected class function GetValue: string; virtual; public property Value: string read GetValue; end; i.e. a normal property with a virtual class getter

Good suggestion. Go to Next/Previous modification Editor commands · Issue #165 · TurboPack/SynEdit (github.com)

This is correct, but this is the reason GPU support is disabled by default: D2D1RenderTargetProperties( {$IFDEF GPUSupport} D2D1_RENDER_TARGET_TYPE_DEFAULT, {$ELSE} D2D1_RENDER_TARGET_TYPE_SOFTWARE, // much faster in my desktop with a slow GPU {$ENDIF} As far as CPU utilization goes, I have tried with a 10K lines pascal file with highlighting, code folding and indentation lines. Scrolling by pressing continuously the Page Down key results in CPU utiliization around 5% (I7 12700). With GPUSupport enabled (currently incompatible with Gutter.ShowLineNumbers - will be fixed), CPU utilization remains close to 0% but GPU utilization rises to 5% (Intel UHD 770).

I will ask Embarcadero to update the Getit packages once the current versions is thoroughly tested and optimized, probably in a few weeks time. But the latency you mentioned is always going to be there, since the development is currently very active. So if you want the latest fixes and improvements do use the Github version.

This is not the experience here and in the other testers. Performance with highlighted 10000s of lines is very good. Could you please submit an issue at the Issue Tracker with sample project and text file?