Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
I would like to bring to your attention this project: http://sourceforge.net/forum/forum.php?forum_id=365095 DWPL... it was quite impressive... it had a text gui which was compatible with Delphi... not sure if it's still compatible with Delphi 2007... probably not... maybe it has the same issue's as Lazarus now has... maybe Lazarus was even based on it... (?) Yes, this is really what we need. Ditch DOS filenames and switch to a DOS based text GUI. I think you missed the point here. The point was: DWPL simply replaced some unit aliases, and implemented a compatible text-based VCL (probably using CLX). This ment the application could be compiled for windows with a graphical gui. This ment the application could be compiled for dos with a text gui which looked graphical. Delphi uses: WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE; DWPL would change it to: messages=sysutils;controls=qcontrols;dialogs=qdialogs;extctrls=qextctrls;forms=qforms;graphics=qgraphics;menus=qmenus;stdctrls=qstdctrls;WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE; Then use tool to convert windows exe to wdosx32 exe. By using only the supported gui components at least the gui code would simply compile without any changes necessary. Probably same for RTL... for threading I am not sure ;) it was being implemented at the time. Something like that for Lazarus would be nice ! :) Bye, Skybuck. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
- Original Message - From: Florian Klaempfl flor...@freepascal.org To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Thursday, December 18, 2008 12:10 PM Subject: Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi. Skybuck Flying schrieb: Hello, To make it easy for Delphi programmers to write code in Delphi and then switch to free pascal/lazarus the following could be done: Delphi's IDE is still more stable than Lazarus IDE. Why should I/we spent time into improving other people's software (making a delphi plugin) instead of improving our own software (debugging lazarus)? Let's go back in time a bit to find out the answer. Turbo Pascal/Borland Pascal came first, then Delphi came, and then probably free pascal, give and take a little. The first three mentioned products were and maybe are still much more populair than free pascal. Therefore I bet a lot of code has been written in turbo pascal, borland pascal and Delphi. Therefore making sure that your free pascal compiler and lazarus can compile all that code that has ever been written doesn't actually make Delphi a better product since Delphi can already compile all that with minimum effort. No... it makes *your* free pascal product a better product ! So you're wrong when you say you would be improving other people's product... especially if you ment Delphi... if you ment my own products then again you might be mistaken since lazarus doesn't seem that super yet, also for me personally I haven't made any big free pascal projects yet so that remains to be proven as well ;) I tried compiling the free pascal compiler in Delphi and noticed how free pascal had some language features which were not supported by Delphi, which scares me a bit... I would like to have the ability to go back and forth between compilers because that's in my own best interest ;) and actually all pascal users. So I hope all pascal compiler writers, free pascal, delphi, maybe even delphi prism/oxygen whatever work together to make sure the pascal community is not fragmented across different pascal language extensions because ultimately that would hurt all of us pascal programmers. Therefore compiler writers that want to compete with each other should not compete with each other at the language extensions front... they should work together to make the language better that is in the interest of all. Thus the pascal compiler writes should make sure there is one pascal language and not a zillion different ones. Competition between pascal compiler writers could focus on: 1. Higher quality of compiler in the sense of: 1.1 Less crashes of compiler. 1.2 Less bugs of compiler. 1.3 Better code generation of compiler for higher performing code. 1.4 Faster compiler. 1.5 Cross compiling to different platforms. Now a word about the plugin concept and the reasons behind it. At least for Lazarus I wonder how much time it would make to create a plugin for Delphi. If the lazarus code is compatible with Delphi then at least it won't have language porting issue's, so scratch one issue. Then it depends on the widgets/gui components... do they have their own code to draw things ? or do they simple wrap some gui library ? Are they wrappers or true components themselfes ? Or maybe a mix of things ? Whatever the case may be... the Delphi VCL is worked out well and has been around for a long time... maybe it has a bug here and there... but nothing too serious... therefore supporting the Delphi VCL is a good investment of time ! This will make Lazarus more valuable as well to Delphi programmers, so then can switch more easily. Other benefits might include: Lazarus wrappers around the VCL might still contain bugs and can be debugged by Delphi programmers themselfes. Maybe these could even highlight design errors or bugs in the lazarus wrappers. Also if Delphi programmers start switching to Lazarus then maybe on the long run they will start using Lazarus more often... and when they run into bugs in Lazarus itself they might become interested in helping out... finding Lazarus bugs and maybe even trying to fix them. When it comes to debugging Lazarus this seems difficult. How does one debug Lazarus with Lazarus ? Very strange really... If lazarus crashes... then how could I possible debug it ? Since it already crashed ? Pretty strange... Maybe an idea would be to use two Lazarus instances... one which will be debugged with the other Lazarus instance... but then it's hoping that not both will crash... ;) These kind of debugging technique's should be documented somewhere... maybe even on the frontpage for maximum exposure ;) However now the question becomes the opposite: Why would we Delphi programmers invest time in trying to make Lazarus better ? Why would we Delphi programmers invest time in trying to make Free Pascal better ? So far these two tools do little for us Delphi
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
Hi, On Thu, Dec 18, 2008 at 6:47 PM, Skybuck Flying skybuck2...@hotmail.com wrote: I tried compiling the free pascal compiler in Delphi and noticed how free pascal had some language features which were not supported by Delphi, which scares me a bit... I would like to have the ability to go back and forth between compilers because that's in my own best interest ;) and actually all pascal users. AFAIK, it's impossible to compile FPC in Delphi since FPC's 1.0x versions. If FPC compiles itself (wich it does), I don't see the point in twisting FPC source in to compiling in Delphi, especially spending efforts to overcome Delphi's limits. As long as FPC compiles my Delphi code, I'm happy. So I hope all pascal compiler writers, free pascal, delphi, maybe even delphi prism/oxygen whatever work together to make sure the pascal community is not fragmented across different pascal language extensions because ultimately that would hurt all of us pascal programmers. Therefore compiler writers that want to compete with each other should not compete with each other at the language extensions front... they should work together to make the language better that is in the interest of all. You forget that FPC source is available, thus you are preaching to the choir, here. Borland/Inprise/Codegear/Embarcadero are the ones that have a closed source compiler and go their way without caring about the others (a legitimate policy, by the way) Thus the pascal compiler writes should make sure there is one pascal language and not a zillion different ones. As I explained above, the only way they have to do this is running after the other compilers to catch up with the changes. This is what is being done, but asking for a specific change or a different pace will only get you one answer: The source is here, do it yourself. It may sound rude, but that's the basic contract between FPC's developers and you. Competition between pascal compiler writers could focus on: 1. Higher quality of compiler in the sense of: 1.1 Less crashes of compiler. 1.2 Less bugs of compiler. 1.3 Better code generation of compiler for higher performing code. 1.4 Faster compiler. 1.5 Cross compiling to different platforms. I think this has been taken care of, at least on th FPC side. ;-) Now a word about the plugin concept and the reasons behind it. At least for Lazarus I wonder how much time it would make to create a plugin for Delphi. There was one attempt from the CrossKylix author, that seems to be abandonned. Again you would be chasing a moving target, with no cooperation from Codegear. When it comes to debugging Lazarus this seems difficult. How does one debug Lazarus with Lazarus ? Very strange really... With patience. Welcome the world of IDE development. If lazarus crashes... then how could I possible debug it ? Since it already crashed ? Pretty strange... A) with an external debugger. B) With another instance of LAzarus. Maybe an idea would be to use two Lazarus instances... one which will be debugged with the other Lazarus instance... but then it's hoping that not both will crash... ;) Could happen. These kind of debugging technique's should be documented somewhere... maybe even on the frontpage for maximum exposure ;) However now the question becomes the opposite: Why would we Delphi programmers invest time in trying to make Lazarus better ? To have a spare solution, and in some cases a better solution. After seeing the erratic behaviour and policies of Borland/Inprise/Codegear/Embarcadero, do you feel safe with Delphi? Why would we Delphi programmers invest time in trying to make Free Pascal better ? See above. So far these two tools do little for us Delphi programmers: I don't think it's everybody's case. Lazarus is still buggy, and kinda annoying ;) :) True, but the solution is partially in your hands. I would like to bring to your attention this project: http://sourceforge.net/forum/forum.php?forum_id=365095 DWPL... it was quite impressive... it had a text gui which was compatible with Delphi... not sure if it's still compatible with Delphi 2007... probably not... maybe it has the same issue's as Lazarus now has... maybe Lazarus was even based on it... (?) Yes, this is really what we need. Ditch DOS filenames and switch to a DOS based text GUI. Now finally the question is... why or why not keep compatibility with Delphi. Delphi has this VCL... it's code is maybe protected by copyrights by CodeGear. You guys want to distribute your own products... but you cannot include the VCL from CodeGear because of copyright reasons. These are legal questions. There is such a thing as a derivative work which then maybe becomes a work in itself if it's modified enough... not that many modifications are needed to become a derivative work. I am not a legal expert... but it's worth looking into this to see if somehow the VCL code can still be used. If this is
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
Op donderdag 18-12-2008 om 18:47 uur [tijdzone +0100], schreef Skybuck Flying: - Original Message - From: Florian Klaempfl flor...@freepascal.org To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Thursday, December 18, 2008 12:10 PM Subject: Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi. Skybuck Flying schrieb: Hello, To make it easy for Delphi programmers to write code in Delphi and then switch to free pascal/lazarus the following could be done: Delphi's IDE is still more stable than Lazarus IDE. Why should I/we spent time into improving other people's software (making a delphi plugin) instead of improving our own software (debugging lazarus)? Let's go back in time a bit to find out the answer. Maybe you should read somewhat more about freepascal, re-think what you wrote and then come here again. And in that case, post al your ideas in a seperate mails. The fpc-compiler can compile Delphi-code, in it's Delhi-mode, and code written for fpc in Delphi-mode can be compiled by Delphi. As long as you don't use any of the extensions of fpc on Delphi. So that is already done. There also is a improved version of the VCL available, namely the LCL. Only the LCL is better because it can be used-cross platform. You can not do that with the VCL, because it's design does not allow that. The problem you are pointing at is more that the Codegear people don't cooperate with us, not that we don't try to cooperate with them. We can't force Codegear to change it's policies. Maybe you should write some essays to them. (But that has been done before) There is none usefull idea in your essay which isn't already implemented, tried or be proven wrong. Just search this list, google and our website. Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
I think all efforts should the concentrated on providing mainstream features that are common in newer development platforms (Java/C#) . I feel that spending time on making Delphi code more readable is a waste since there are SO many other issues that need to be dealt with. C# has a lot of ideas FPC can take on. I say contributors should think about bringing in new functionality and Expanding FPC to include such features rather than deal with Delphi issues. The benefits of using FPC (write 1 compile X OSs) far outweigh any issues an individual will have at learning which Library replaces Win32 or what not. FPC/Lazarus has come a long way in the 2 years I've been following the project. Keep up the good work and push forward... Don't get side tracked by all these compatibility issues. Infact, add more features that are currently not present in Pascal - Lamda Expressions etc... A.I. in Code Insight... There are hundreds of new issues to pioneer - let's not get caught up in a quagmire. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
Free Pascal compiler can do 64 bit but no performance benefits so far ?! I am developing a GA (genetical algorithm) that needs a large amount of data to work with. My development machine has 64 GB RAM and 4 cores. In that space, I can run simultaneously 4 processes that each use 16 GB of data (Intraday stock market of all ticker symbols of years of data). This would have been impossible with Delphi. It's not even a performance issue in my case. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
Skybuck Flying schrieb: Hello, To make it easy for Delphi programmers to write code in Delphi and then switch to free pascal/lazarus the following could be done: Delphi's IDE is still more stable than Lazarus IDE. Why should I/we spent time into improving other people's software (making a delphi plugin) instead of improving our own software (debugging lazarus)? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
On Thu, Dec 18, 2008 at 01:18:09AM +0100, Skybuck Flying wrote: To make it easy for Delphi programmers to write code in Delphi and then switch to free pascal/lazarus the following could be done: 1. Export code from Free Pascal into Delphi packages so they can be installed in Delphi. 2. Export code from Lazarus into Delphi packages so they can be installed in Delphi. This way Delphi users can make applications inside the Delphi IDE, using libraries/code from Free Pascal and Lazarus. The whole point of FPC/Lazarus is not needing Delphi. Efforts should go directly towards this goal. Also, in general, the feasability and amount of work is heavily underestimated. It is technically next to undoable, and magnitudes more difficult to get it working then to do the same in lazarus. In theory, all problems can be worked around, and heaps of developers have stressed that. However none of them that tried came up with even halfworking code, they all stumble on the complexity, magnitude of the task. For starters, because you don't have Delphi in source. Otherwise I don't see any benefit to switching to free pascal. Well, above lists another example, you have total system control. This gets important if you have massive applications that you want to maintain indefinitely. The Kylix history clearly illustrates this. Delphi's IDE is still more stable than Lazarus IDE. Personally, debugging annoys me more than that. Delphi dies daily on me too. Delphi's compiler still works pretty good. But to get it up to par with FPC, I have to buy the most recent one. Free Pascal compiler can do 64 bit but no performance benefits so far ?! There were never supposed to be any. I would be interested in learning about any Lazarus/GUI Packages available for Delphi ?!? If these already exist... please point me towards them ;) It's not clear what you mean here. Several packages can be used both with Lazarus and Delphi, like Indy. However currently I am interested in cross compiling to darwin/os x which seems not included :( so that sux. Because it is hard, and limited. Advanced topics need advanced skills. Create a filedisk image containing all necessary tools and code and batch files or scripts to make the compiling automatic. This is not possible, some files needed for OS X crosscompilation are copyrighted. Still, the situation could be made easier. I hope that some of the people that need it urgently start working on making that happen. (hint, hint) batch file and voila... everything gets compiled automatically without having to follow a zillion tutorials and a zillion downloads and installs ;) And I hope that some users will pull their own weight, and invest some time too. The team already invests enough. I would also be interested in helping out with creating such a file disk image... but then I still need more instructions... People have succeeded crosscompiling to OS X by reading the buildfaq. Try harder. For example how to build the free pascal runtime library units... something like that. I am probably not the best candidate to do this because I understand very little about all these files which seem like a zillion files ! ;) The library situation is complex and unfinished. Specially the portable situation I am not sure but I think currently *.o is always the default extension... maybe this should be changed to something like: No. This info is already in the .o, and can be read using various tools like objdump. This causes only more trouble in calling the linker (workarounds with renaming removed. Computers are easier confused than users, so no point in that) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
Free Pascal compiler can do 64 bit but no performance benefits so far ?! There were never supposed to be any. 64-bit code can, in some specialist cases, be made to execute in about double the speed of 32-bit code due to the wider registers. The availability of more registers is another speed-boon to 64-bit code. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.
On 18 Dec 2008, at 14:07, Frank de Groot (Rent-a-Geek) wrote: Free Pascal compiler can do 64 bit but no performance benefits so far ?! There were never supposed to be any. 64-bit code can, in some specialist cases, be made to execute in about double the speed of 32-bit code due to the wider registers. These are indeed really specialist cases, as it requires to consist of almost nothing but 64 bit math and almost no pointers (since every pointer is twice as wide, reducing cache effectivity by half). The availability of more registers is another speed-boon to 64-bit code. On x86_64, to be precise (on other architectures, 32 bit mode already has plentiful registers). However, register variables are not enabled in FPC 2.2.x for x86_64, but only in in 2.3.x (and this will not be merged). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
