Leaderboard

PyScripter, an Open Source, freely available Python IDE written in Delphi, has reached 1 million downloads from Sourceforge. This is in addition to many millions of downloads from its earlier home at the now defunct Google Code and an unknown number of downloads from other distribution channels. Historic note: The initial motivation was to build a good scripting solution for Delphi applications. About 20 years ago Microsoft was still promoting ActiveX scripting and Windows Script Engines (such as vbScript and jScript) as the way of building scripting solutions for Windows applications (one of many Microsoft technologies that was all but abandoned). At that time Python was relatively unknown, but it so happened that it was available as a Windows Script Engine and I looked into it. I loved the clean syntax, the expressiveness and conciseness of the language. Other things I liked were duck typing, batteries included, strong object orientation (everything is an object) etc.. The first iteration was an IDE (editor/debugger) for ActiveX Script Engines. But there were many bugs and limitations of Active Scripting both on the Microsoft/Windows side and the Python side. I then came across Python4Delphi which at the time was maintained by a Canadian developer Morgan Martinet. I started contributing to that project and later become its main maintainer, when Morgan's interested shifted to other things. I also developed a simple Python IDE which was named PyScripter and was originally distributed alongside Python4Delphi. There was very few Python IDEs available at the time and somehow the project became known in the Python community and instantly popular. For me, developing PyScripter was just a hobby, but I received a lot of encouragement and kept on improving it. I was also making some income from donations and Google AdSense. Both PyScripter and Python4Delphi were later moved to Google Code. Python popularity was steadily increasing and at the peak of PyScripter's popularity around 2010, there were hundreds of thousands of downloads the days following each new release. More recently as we all know Python became one of the most popular programming languages, but at the same time there was strong competition to PyScripter from freely available commercial grade IDE's such as Jetbrains PyCharm and Microsoft's Visual Studio and Visual Studio Code. PyScripter was almost abandoned when Google Code closed down due to my frustration, but after a couple of years of inactivity the project was moved to Github and development resumed. Downloads are available through Sourceforge, since 2016. Through the years PyScripter has kept a large and loyal group of followers. I get many comments along the lines "I have tried VSCode, I have tried PyCharm, but I keep going back to PyScripter". PyScripter is also quite widely used in many Universities for introducing Python to students. And almost 20 years after its first release, PyScripter is still going strong...

It refers to the intention to promote Python4Delphi as a means of bringing Python and Delphi closer together: Python for Delphi (P4D) is a set of free components that wrap up the Python dll into Delphi and Lazarus (FPC). They let you easily execute Python scripts, create new Python modules and new Python types. You can create Python extensions as dlls and much more. P4D provides different levels of functionality: Low-level access to the python API High-level bi-directional interaction with Python Access to Python objects using Delphi custom variants (VarPyth.pas) Wrapping of Delphi objects for use in python scripts using RTTI (WrapDelphi.pas) Creating python extension modules with Delphi classes and functions P4D makes it very easy to use python as a scripting language for Delphi applications. It comes with an extensive range of demos and tutorials.

Guy is beating a dead horse with a stick. Another guy comes along "Hey, your horse is dead, you need a new one" "Nah... I am probably holding the stick wrong"

... well - if this is really what you want, you should rethink your discussion-style. For me your last post is quite offensive. It is not the first time we (have to) talk about this.

If the memory pages are swapped on disk, then indeed it will be slow to dereference the pointer. But in this case, the application is very badly designed: paging on disk should be avoided in all cases, and direct disk API calls should be made instead to flush the data. The problem is not the use of the MM. The problem is the whole memory allocation design in the application. Less memory should be allocated. This is what @David Heffernan wrote, and you didn't get his point about swapping. If the memory page is not on disk - then you may have a cache miss when the pointer is dereferenced. For big memory blocks, it won't hurt. Calling VirtualFree will take definitively much more CPU than a cache miss. So I still don't find the relevance of your argumentation. Last but not least, the article you quoted (without any benchmark and code to prove the point) is very specific to the memory use of a database engine, which claims to be the fastest on the embedded market. I doubt everytime I read such claim, and I don't see actual code. More like technical marketing arguments than real data. Raima DB features "needing 350KB of RAM" and "optimized to run on resource-constrained IoT edge devices that require real-time response". So what is the point of benchmarking handling of GB of RAM? The whole https://raima.com/sqlite-vs-rdm/ is full of FUD. The graphs are a joke. Since they don't even show the benchmark code, I guess they didn't even use a fair comparison and use SQLite in default mode - whereas with exclusive mode and in-memory journal, SQLite3 can be really fast. We have benchmark and code to show that with mORMot - https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_60 and https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITLE_140 (current numbers are even higher). You may have to find better references.

Recent versions of Delphi (for a suitable definition of “recent”) come with a TZipFile class implemented in the unit System.Zip. This class has the really neat feature that it can not only read the contents of a ZIP file directly from a stream but also extract a file from that stream to a TBytes array, thus it does not require any file system access. E.g. imagine you have got a memory stream containing the contents of a ZIP archive. [read on in the blog post]

LOL, That's how working with FireMonkey sometimes feels yes. Silly simple things that should be in the framework, but that are not there. As a result you have to go back to those techniques of the 90's unless you want to spent the time to do it properly. The problem with doing it properly is that you'll be sad once they become part of the framework as you could have spent that time on something else.

Surely there are better characters in Unicode that you can use? ↑ / ↓ #$2191 / #$2193 ˄ / ˅ #$02C4 / #$02C5 ▲ ▼ #$25B2 / #$25BC Optimal solution could be a custom draw, but... is it worth the effort?

ARPACK is recommended for extracting a small number of eigen vectors from a huge problem. LAPACK has effective methods for extracting all solutions using a direct method. Neither are easy to use from Delphi. I have done so but it isn't for the faint of heart. Especially ARPACK. The famous C++ Eigen library is very capable though and easy to use. I'd suggest you wrap that in a DLL. Start in Matlab to prove that it can do the calculation sufficiently quickly for a typical matrix that you will work with. Then write a C++ program in Eigen to solve the same problems. Does that work effectively? Then, and only then, try to wrap it up to be called from Delphi.

And what exactly is wrong or not understandable in a week with using {B+} and a simple one liner?

Yes, I just would change it a little, so that it can work a bit faster: function CompleteEval(const aBooleanValues: array of Boolean): Boolean; var i: Integer; begin for i := Low(aBooleanValues) to High(aBooleanValues) do if aBooleanValues[i] then begin Result := True; exit; end; Result := false; end;

@pyscripter Sometimes Im wondering what made Python so popular in the first place. Now I know, it was PyScripter IDE

function CompleteEval(const Values: array of Boolean): Boolean;

Your first two solutions are fine. Why try to be "clever"?

Why does anybody think that all this guessing would be useful? Does anybody have much experience of success when guessing? Solving eigen problems is a very challenging numerical problem. Does anybody really believe that good solutions arise from guesswork? I am frankly embarrassed by this thread.

@Arnaud Bouchez @David Heffernan I'm really sorry guys. I didn't meant to be offensive by any way. I just got some external things that subjectively influenced the way I express. @Daniel I just discarded my last post.

@Kas Ob.It's pointless trying to argue about making the wrong solution work.

@Kas Ob. - The 32-bit IDE is running on WoW. My IDE crashes too. Out of memory or it simply hangs in an internal deadlock. Several times per day. But - it has never crashed or trashed my Windows 10 Enterprise 1909 system. My uptime is typically about a month, i.e. until the next security patches. RAD Studio, Visual Studio, VS Code, PowerShell 7, MS SQL Server Manager, MS SQL Server, a large number of remote desktops, Excel, Outlook, OneNote, Teams, Discord, Chrome with too many tabs, Apex SQL Diff, Beyond Compare, VirtualBox, and the invaluable Process Hacker. I was thinking of the software you write - if it has page file issues - you either have HW spec issues, or you have allocation strategy issues.

If you want to discuss then forum is the right place, if you have specific question then SO is the right place to go. I would not say it is about preferences, but what you need at particular moment. Besides Delphi I am using other tools for development, most notably Android Studio and Xcode. I never needed forums to solve my problems... I could find all the answers on SO and official documentation. Hanging out with other developers and discussing all kinds of things... well, Delphi forums and communities were more than enough for me.

Well not necessarily. Typically you let exceptions float upwards to be handled by some high level exception handler.

Not obvious at all. Usually you allocated memory because you wanted to use it. If you've swapped the entire block to disk then bringing a couple of pages back is the least of your worries. Solve your problem by avoiding swapping in the first place. Nothing you have said, in my view, supports your claim that all allocation of huge blocks should be done using VirtualAlloc.

Maybe you shouldn't have let that guy with the strange English accent from "Microsoft Support" help you with you "PC problem" Speaking of sleeping right at night; This thread was actually the topic on my dreams (yes, it was a nightmare) last night: I watched in horror as all my systems were being encrypted before my eyes. Somehow the hacker had so much control over my system that it kept on running even after I pulled the plug. Completely unrelated , but the first thing I did this morning was to run a compete scan on my system.

I didn't mean to show you any disrespect. I'm sorry that it came across that way. All I meant was that I thought the argument that compilation speed was important was bogus. I really did not mean to upset you. I try hard never to make anything I write personal. To me it's always about the technical details.