AlekXL

Forgive my ignorance, but whether Python function can have typed arguments? Can a callee be sure that it's argument is TypeA, not TypeB, every time you want it, without extra checking? If answer is no , then everything else is just semantics, call it dynamic typing, whatever. And so on. Scripts, scripts, and more scripting. Should Delphi be like that? We have Pascal Script, DWScript, we had even PAX Compiler, for morgana's sake, which could allegedly produce x86 dll plugins. I guess one may want to incorporate python into a Delphi app, as scripting language (though, it's not always a best option, since a plethora of packages go with a caveat, that no all those would easily install on Windows, and the infrastructure(run-time) seems neither very portable nor small. Question is whether Delphi should aim towards same goal, and is it able to. People made their choices already. Admittedly, Use a variable, without declaring and thinking, what is actually is, have some appeal for novices. I opine that Delphi/Pascal could be a second choice, once a user gets tired of dynamic typing, and situations when their python script would go bonkers just because of misplaced or missing tab character. At run-time. Surely a lot of work should be done with pascal infrastructure for that to happen. Every time I do something worth mentioning. This is valid point, I must concede. We need to have an option to reference count just for explicitly designated object types and variables. And a first-class one, without need to build an interface wrapper. Which means not some crappy wrappers like shared_ptr, no, lets introduce compiler magic and (non-breaking) language changes. like FObject: auto TObject; // compiler, just manage the lifetime automacally type TMyRefObject = class auto (TObject) // all instances are automatic var manualRef := unsafe(RefCountedObject); // Compiler, I understand the risk, just give me raw pointer var autoInline := auto TObject.Create;// compiler, manage it automatically Few remember that, but perhaps main reason why VCL shines, still mostly uncontested, is support to message dynamic dispatch methods. Just remember that ugly MFC MESSAGE_MAP macros! Or sorry mocking mocks of QT -- those are just workaround about C++ deficiency. And Delphi was bold enough to introduce such magic

Ok, I've just checked. And must say, this is officially a lie (were you a rookie, I would call it mistake, but you're prominent, trusted member of the community, so take it) Swig fork of Delphi is able to import C++ class -> Delphi class wrapped, through dll import. Swig generates c++ proxy *.cxx from a header, and even able to specialize C++ template class (you need to write something like TEMPLATE_WRAP0(vector ,vecint, int ); Swig flattens said class members to in the *.cxx and export this through __declspec(dllexport) (or statically, but delphi-swig cannot handle static linking) Then, Swig generates pas stub , which imports flattened methods(stupidly, it does not add underscores to names, but this is easy fixed by __DLLNAME name ' ==> __DLLNAME name '_ "replace all" Additionally (default, but optional), Swig adds Delphi class wrapper, for the C++ class/specialized template class. I've just regenerated, and compiled template example, from example.h example.i , with C++Builder and Delphi.. This example is simplistic, so I don't know how it would work it with complex c++ classes, but considering SWIG is serious tool, we can hope.

Yet another reinventing the wheel? We already have Oxygene for that. I hate fragmentation (burn the heretics!).. We already have our resources stretched thin. And under viral license, so you can't even borrow code from it, without being infected. With FPC we have our plate full. So that guy can shove it..

Delphi mostly. C/C++ And I know how to build an LR-parser, from Grammar to PDA, including classic Knuth LR(1) algorithm implementation. I wrote some labs "Languages and translation methods" for students (for pay), LR grammar, simple codegen, optimizing expression tree for register allocation, including commutative ops reordering. Not much, I know, but I have some glimpse of compiler design. But did edwinyzh just proved that you are partially wrong? I asked you to be factual, and now ask it again -- you named Edwards curves, and here we have some implemented. Now please clarify further, what "Edwards curves" Delphi lacking, and why those lacking are important (where they used)? Because they are thin wrappers around C/C++ FFMpeg or some other C/C++ library or web browser runtime. All dirty work is hidden.. Delphi isn't meant to build thin wrappers, apparently. And many of those who write .NET and Js -- are barely aware what is memory leak, how to prevent it, or investigate .. that's beyond their mindset, thanks to learning managed languages from youth.

You edited your post, did you? Quoting myself, but addressing to edwinyzh Chinese guy? Freudian slip? You like his post barely better, than mine? I hope you will act politically correct, not just claim you do. "Truth is born in disputes", and there are a few people worth debating, just not all, you know.

I would disagree to #1. I love inline variables, it's small miracle to use, especially with Generics. Declare, use, and forget I love Lambdas they make me more productive. I love attributes, this is next word to develop more modular, less bloated, and elegant code. So no, I'd rather go option #3

please clarify, those tools edwinyzh mentioned is unable bind to C++ class?

And yes, #5, and here we have best conversation among those recently occurred on this thinly populated, boringly politically correct forum. So giving devil his due, lets recall, that

To get bugs fixed? Code generation improved? I dont dream that Delphi compiler will soon be completely free, I just want it to be better Did you mean https://github.com/FMXExpress/swig-delphi ? But this helpful anyway. Oh, that's nice.. Looks like Joseph Mitzen exaggerated poor condition of C++/Delphi linkage? All those 5 pages of discussion worth that single post..

Tell that to a reverse engineer, who fixed a bug -- namely "license verification" in RAD Studio, despite being thoroughly hidden, or the author of IDEFixPack They would approve bugfixes, wouldn't they? GetIt and Torry is not representative nowadays. Use google with (github OR bitbucket OR gitlab OR sourcefourge) clause, Luke Well, deep-learning probably not Delphi forte, but how often one needs this? Surely you wouldn't write a media player on python, would you? Even .Net is bad option? And java? On Android, yes, maybe, but what's the point writing yet another crappy player on Java. If you are going to be serious, you would end up with C++. And albeit it maybe harder to link C++ libs to Delphi app, once it's done, it will work faster, and can be integrated tighter since managed-unmanaged transition is costly. Well, numerical calculs and deep learning maybe python forte (if backed by C++ libs, of cause), but are you sure, that we comparing apples to apples? Delphi has its strong points, UI and Database, to name two.. And your choice for python as example is bad : I will never believe that a weak-typed language, is actually good for anything except quick-and-dirty scripts. Scientists would love it. Hobbyist would too. But how it usable Pros, comparing to Java or C#? Actually Python is known to be slow in serious workloads.

People don't sell software that much, anymore.. Paid apps market shrunk dramatically, and web services is a way to go. Not sure whether Delphi would fit on the back-end market. How it works? Like IDispatch? Have no idea how to bind C++ object, let alone lambda, to python, or even Delphi code. There should be a catch somewhere.

Good to know. Yes, SWIG is a way to go, then, clearly He's hopeless, isn't he? Delphi still have better ecosystem, when it comes to desktop UI, I believe. Never heard about something like "HTML components" developed in C#, Java, let alone Python

better be mean, than dishonest, that's my way to go. But you are right here, just saying 'A', say 'B', too Say, some developer Alek wants to fix those issues in FPC -- Delphi incompatibility, and slow math, on x86-64 Win/Lin. This is major effort, which requires months of full-time development, I presume. Finally he gets jobs done, and what to do now? He cannot sell FPC, since GPL requirement will force him to open the source just first who asks this, and then sales are over. He only can use the software in-house, but this is not viable option, unless he's part of big company. However, companies are not interested in pascal, it's not trendy. And we have vicious circle -- to kick some momentum we need some major effort, for a free.. That's the catchs of GPL, and why its actually not so popular as before.

Linux is important, I believe, but I'm just frustrated some useful libraries treat windows targets as 2-class citizens at best. I'm not very interested in linux currently, so I just don't want to support it myself. If Linux has many pascal developers, who'd wish to contribute to FPC, let them. I just don't want their innovations would cripple the compiler and libraries on Windows. No, I realized that he was the author after posting the comment But does Pascal even fit that ecosystem? I mean those scientists like python for its "simplicity".. Do they adopt pascal, however free and approachable it may be? I don't understand python appeal really. How weakly typed language may be so popular? And I don't believe any software > 50K lines could be robust under those circumstances. Is't python is a script language on steroids? In pure math, yes, but this is memory management, Delphi/FPC is faster just because manual management is way faster than any GC. If you work with large amount of inter-related data objects, Java would not shine as bright, let alone python. The key word here is small. But when Python software grows big, not sure it will happen.

So, are you suggesting to start a new topic on FPC/Newpascal fork? For me, those topics are closely related, since actually some closed-sourced apps were open-sourced due to threat from already free competitors. And surely, FPC can't be off-topic in Delphi community.

Please, supply a proof of that, because someone says it's just a rumor. Citation and where you get this would be helpful. Meanwhile, we are on page 4, and this topic about opensourcing Delphi compiler, please vote on QP , if you didn't already Additionally consider supporting Delphi-compatibility issue on Newpascal https://github.com/newpascal/newpascal/issues/6

probably problem is linking OBJ to a unit and getting unresolved symbols, which is from depths of C/C++ RTL.. Then you need to un-archive libraries/lib to a object files, and try to feed those needed to Delphi/FPC making it happy. Tedious, but not impossible.. If one getting paid for development, he just should brace himself get job done. Otherwise let him play with toys like python.

Well, honestly I can't claim I am expert in linking C libraries to Delphi or FPC on non-Win platforms, but surely it's not that bad? I mean, yes, you need some effort to do this, but considering this is one-time thing, why this is trouble? I honestly don't understand the effort implementing such heavy task on python, javascript or even Java. Probably the very reason such libraries is paid in Delphi is the practical approach. Try to sell python software, or javascript.. Delphi app can be sold.. And perhaps we need to create a C-to-Delphi conversion tool, just to make such import easier.

https://github.com/Xor-el/CryptoLib4Pascal rings any bells? isn't it your project?

Bite me! Do it better, if you can.

Unfortunately, last time I checked CT intentionally broke basic compatibility with Lazarus. For what end, need I ask?

Which algorithm or hash Delphi is lacking? well C/C++ libs (cross)compilation is the pain, but unlike python or java, you'll get fastest solution in the end of the day.

Well, I need to repeat myself again, need I? It never gets old. Lars, just please don't sabotage the discussion and the cause, will you? Besides, we are already considering other options , it's part of the plan. Well, FMX already proved it's weakness -- huge executable, slow, buggy, and not compatible with VCL, even there compatibility was possible

They should buy it, probably.

Do I need to repeat myself? "One must try"... It's not what we believe in, it's what we do. Yes, there are some hardcore developers here, we need to build up a team, and we need to figure out practical steps to do. Those who are prominent should pledge that they will contribute.. As for plan.. Let me suggest one, for discussion. [0. take newpascal and merge with latest trunk] 1. merge (3-way) with attributes patch, it's most recent 2. merge either with [blaise/closures] or Kevroletin patch 3. figure out about inline vars and type inference Do we need to take step 0? Share your opinion, guys Go senile, probably. Excactly, we must explicitly drop bizzaire platforms. Lets not stretch thin. 0. Delphi compatibility is paramount 1. In fact, at start we should focus only on two- WIntel, and AndroArm. 2. Those who need linux, must do it themself and test their patches not on linux, but ensure also, that those won't break 2 major platforms. Or they full-refund pay. 3. Those who need an Apple platforms, need to contibute [and pay]. Obviously those minor platforms are targeted for gain 4. We need to redistribute binaries for pre-build Lazarus+NewPascal. Newest beta-releases need to be adopted easily. Lazy developers are good substitution for lab rats. Yes, the LCL is the way to go, until we figure out if there are any better ways.