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.

TStopwatch and occasionally VTune.

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,

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