Re: [fpc-pascal] Problems with Dynlibs.UnloadLibrary on Linux
Andrew Brunner schrieb: Thanks for that tip! So running under GDB I get the following info... This GDB was configured as x86_64-linux-gnu... (gdb) run shared library problem and linux 64 bit - maybe this problem is related to FPC bug reports 11931 / 12265 (jump table problem). Werner ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc 2.2.2 in fink for Mac OS X
Hi Karl-Michael, what is Fink? where can I look about it?. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Fri, 12/19/08, Schindler Karl-Michael karl-michael.schind...@physik.uni-halle.de wrote: From: Schindler Karl-Michael karl-michael.schind...@physik.uni-halle.de Subject: [fpc-pascal] fpc 2.2.2 in fink for Mac OS X To: fpc-pascal@lists.freepascal.org Date: Friday, December 19, 2008, 6:24 AM Hi A revised version of fpc 2.2.2 has been added to the unstable tree of fink. Main new features are IntelMac crosscompilers for Win32 and linux-i386. The i386 crosscompiler for PowerPC should be added within days. I would welcome test reports. As soon as there is sufficient positive feedback, I could ask for promoting the packages from the unstable tree to the stable tree of fink. Merry Christmay and and a happy New Year - Karl-Michael Schindler aka mischi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ 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] Problems with Dynlibs.UnloadLibrary on Linux
On 19 Dec 2008, at 09:48, Werner Bochtler wrote: Andrew Brunner schrieb: Thanks for that tip! So running under GDB I get the following info... This GDB was configured as x86_64-linux-gnu... (gdb) run shared library problem and linux 64 bit - maybe this problem is related to FPC bug reports 11931 / 12265 (jump table problem). In that case, using the fixes branch or the previous release is probably a better idea. Jonas ___ 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.
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
[fpc-pascal] Procedure types
I've got a few thousand lines of Pascal which I'm converting to FPC. It's actually the Meta-2 compiler-compiler which despite its age I still find useful for embedded script processing, I hope eventually to get it running on SPARC and possibly ARM as well as x86. Linux will not be the first OS this code has run on, by any means. This code was originally written using MT+86, but compatibility with that has been sacrificed and it now works with TopSpeed Pascal, TP5.5 and Delphi. Because it is still compilable with TopSpeed which doesn't use the standard directive and conditional-compilation format I'm having to be very careful with the source. In one place I am checking a number of procedure variables which are actually callbacks for reading input etc., if they're NIL then default procedures are used instead. For portability I have defined myself a function FUNCTION AddressOf(VAR x): POINTER; Hence IF AddressOf(source) NIL THEN state.source:= source ELSE state.source:= dummyRead; That works OK with the other compilers but when compiling with FPC it reports Wrong number of parameters specified for call to Procedure Variable. If instead I use IF @source NIL THEN state.source:= source ELSE state.source:= dummyRead; that works with FPC and probably other Borland-style compilers, but not with TopSpeed. Is there a directive or mode that will allow a procedure variable to be compatible with AddressOf() as defined? Alternatively is there a type which is compatible with any procedure variable (i.e. like Modula-2's PROC, if my memory is correct), and can I overload AddressOf() to handle the specific case of a procedure passed as parameter while leaving it tolerant of other types? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] [OT] syntax diagrams in the reference guide
Hi, I'd like to ask: Is there any tool for creating the syntax diagrams shown in the reference guide? If yes, which one and where can I get it? TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Procedure types
FPC treats procedural types a little different from Delphi / TP, see
http://www.freepascal.org/docs-html/ref/refse17.html this . You can
therefore write your AddressOf function as:
FUNCTION AddressOf(VAR x): POINTER;
... // variables (if you ever need)
begin
{$ifdef fpc}
AddressOf:=...@x;
{$else}
... // for other compilers
{$endif}
end;
--
View this message in context:
http://www.nabble.com/Procedure-types-tp21096634p21102287.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
