Re: [Lazarus] Parser
Florian Klämpfl schrieb: Just mail me a login and password to get your own branch in the fpc svn. I got no response on my last mail - any problems? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I guess in Lazarus. Why not use them? It is much easier. And you can write them in whatever language you want. In Linux do you have something similar? Why not use it instead to mix Pascal with C, C++, Java... philosophy? I can not understand one thing: is there a Lazarus project manager like in other open source projects? Why not he/she say will Lazarus support other languages except FP or not and stop this discussion? Оригинално писмо От: Florian Klaempfl Относно: Re: [Lazarus] Parser До: Lazarus mailing list Изпратено на: Четвъртък, 2010, Юли 1 16:20:50 EEST Michael Schnell schrieb: On 07/01/2010 11:15 AM, Florian Klaempfl wrote: ... which does not mean that it fits into the Pascal philosophy. Of course it does not. That exactly was my point. So it's pretty clear that a C front end does not change much. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus - Зрелищни снимки от ЮАР 2010. Вижте най-интересните моменти! http://sportni.bg/worldcup2010/?tid=20oid=1002-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Fri, 02 Jul 2010 07:49:25 +0300 Adem listmem...@letterboxes.org wrote: [...] Well.. the whole point is to *not* maintain any more than *one* parser --and, that includes current n parsers (I am not sure what the value of 'n' is). That is the target. Means? I still don't understand what do you really want to achieve. There are currently several different pascal parsers with different abilities for different purposes. For example the fpc one for compiling, synedit for highlighting, codetools has several for directives, declarations, indentations, fcl has one basic and extendable parser and so forth. Each one has abilities that the others do not have. What do you want to use the fpc parser for? [...] So, could I now ask for some constructive --instead of discouraging-- criticism. The fear of slowing down the compiler and its development without seeing the gain is discouraging. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Fri, 2 Jul 2010 09:21:37 +0300 (EEST) Rigel Rig ri...@gbg.bg wrote: Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I guess in Lazarus. Why not use them? It is much easier. And you can write them in whatever language you want. I'm curious, can Java be used to write a dll? In Linux do you have something similar? Why not use it instead to mix Pascal with C, C++, Java... philosophy? I don't know why not, because lazarus does since the beginning. http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries I can not understand one thing: is there a Lazarus project manager like in other open source projects? Why not he/she say will Lazarus support other languages except FP or not and stop this discussion? The tail of the discussion was about extending FPC to do the job of the existing C compilers. The main thread is - as far as I understand it - about extending the fpc parser. I think it should be moved to fpc-devel or fpc-other. It is not about lazarus. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 09:23, Mattias Gaertner wrote: On Fri, 02 Jul 2010 07:49:25 +0300 Ademlistmem...@letterboxes.org wrote [...] Well.. the whole point is to *not* maintain any more than *one* parser --and, that includes current n parsers (I am not sure what the value of 'n' is). That is the target. Means? I still don't understand what do you really want to achieve. Call it some form of perfectionism, if you like. Or 'unionism', for a slightly better term. (reasons below) There are currently several different pascal parsers with different abilities for different purposes. For example the fpc one for compiling, synedit for highlighting, codetools has several for directives, declarations, indentations, fcl has one basic and extendable parser and so forth. Each one has abilities that the others do not have. That's just it: There are simply too many of them neither one is as complete or up-to-date as the original. And, the reason there are too many simply boils down to the fact that the real/genuine/true one wasn't/isn't available. I mean, it's not as if you need a completely different parser for IDE purposes; the fact that you have to write and maintain one is because you have to do it. And, as expected, each one of those baby-parsers are merely partial emulators of the actual one. I am surprised you (plural) don't see this as waste of resources, but instead tell *me* it would be a waste of time to refactor the fpc-code so that its parser can be used (or extended, as the case may be) as a blackbox module downstream in all those projects which shouldn't have had to write parsers. What do you want to use the fpc parser for? It's not 'fpc parser' in the sense that it cannot be used anywhere else; it is a parser that is currently used solely within free-pascal compiler. I would like it to be available to other people too. Isn't this a good enough reason? Do I have to have an ulterior motive? Shall I invent one :) [...] So, could I now ask for some constructive --instead of discouraging-- criticism. The fear of slowing down the compiler and its development without seeing the gain is discouraging. I do sympathize with those fears; but, as you'll agree, worries about speed degradation can only be meaningfully addressed (put to rest) when the actual code is available --no amount of talk or assurances can help/change that. Now, about 'gain': I think you're overlooking medium/long term benefits. When you turn the parser into a module (for the purposes of usage downstream, in IDE etc.), what you will have actually done is to make that 'parser module' replaceable too. That alone can be worth its weight in gold, in the sense that from then on, you can use other 'parser module's --such as, you name it, 'C module', 'Modula module', 'Java module' etc. etc. And, that expands horizons, brings in more talent. Which cannot be bad for FPC, can it? Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Fri, Jul 2, 2010 at 09:02, Adem listmem...@letterboxes.org wrote: [...] So, could I now ask for some constructive --instead of discouraging-- criticism. The fear of slowing down the compiler and its development without seeing the gain is discouraging. I do sympathize with those fears; but, as you'll agree, worries about speed degradation can only be meaningfully addressed (put to rest) when the actual code is available --no amount of talk or assurances can help/change that. Now, about 'gain': I think you're overlooking medium/long term benefits. And I believe you are overlooking all problems coming with maintenance of such solution. I agree that having one parser for all different kind of usage is solution which would be great to have, but my opinion is that it should be based on fcl parser, not compiler's one. And later, IF (whoever does the job) succeeds in making such a good parser (which gets integrated into, for example, Lazarus and proves to be well implemented), only then it is time to think how to connect that parser with compiler's one. At least, that's how I see this situation. When you turn the parser into a module (for the purposes of usage downstream, in IDE etc.), what you will have actually done is to make that 'parser module' replaceable too. That alone can be worth its weight in gold, in the sense that from then on, you can use other 'parser module's --such as, you name it, 'C module', 'Modula module', 'Java module' etc. etc. And, that expands horizons, brings in more talent. Which cannot be bad for FPC, can it? It all sounds really nice, doesn't it :-) Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hi! Am 02.07.2010 00:49, schrieb Adem: On 2010-07-01 20:14, Michael Van Canneyt wrote: Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler). I just cannot understand this: What is so holy about the 'parser from compiler'? - use it to create a pascal to javascript translator. - Create a .net backend code generator. - Create a java bytecode backend code generator. Aren't all these some form of 'escape route's --from always Pascal to somewhere else? I mean, people --of course-- should be given opportunities to escape; but, what does it say about their concerns about Pascal in the first place :) Cheers, Adem It's not about escaping Pascal, but to grant the language new possibilities. On Android phones you can only use Java to access all subsystems of the device (e.g. GUI). You can access the framebuffer from native code though, but directly drawing to a memory field is not the same as using the available GUI classes. It has yet to be found out whether you can access the JVM from a native application (not a native library which is loaded by JVM). Also the new Windows Phone 7 series relies completly on .Net, so our WinCE cross compiler is completly useless here (the usage of .Net is enforced by the kernel itself). And Microsoft might also try to prepare the way for full .Net desktop operating systems. Now that they've discovered virtualization (Windows 7 XP Mode) the compatibility problems might stop them no more. We might not see this in Windows 8 and maybe not in Windows 9 either. But perhaps Windows 10 might be the big breaker of Win32? Free Pascal should be able to compile for these plattforms. But I don't mind to use a completly different RTL and object model that suits the targeted plattform, I only want to use the language which I believe is superior to C# and Java. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
I'm curious, can Java be used to write a dll? I did not know that Java can not create dll! I am very happy that many years ago when Java must had a special computer to run, unlike Delphi, gave up Java. I think some programmers in C, Java ... can not survive the thought that FPC is so quick and Lazarus is so easy to use! I made a simple test: I opened Lazarus, compile and run an empty project. It took 15. Just launch the Delphi 7 took 18! For Delphi .Net will be longer. For Eclipse there is nothing to talk about. :) Thanks for the links! Оригинално писмо От: Mattias Gaertner Относно: Re: [Lazarus] Parser До: lazarus@lists.lazarus.freepascal.org Изпратено на: Петък, 2010, Юли 2 09:53:50 EEST On Fri, 2 Jul 2010 09:21:37 +0300 (EEST) Rigel Rig wrote: Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I guess in Lazarus. Why not use them? It is much easier. And you can write them in whatever language you want. I'm curious, can Java be used to write a dll? In Linux do you have something similar? Why not use it instead to mix Pascal with C, C++, Java... philosophy? I don't know why not, because lazarus does since the beginning. http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus http://wiki.lazarus.freepascal.org/Lazarus/FPC_Libraries I can not understand one thing: is there a Lazarus project manager like in other open source projects? Why not he/she say will Lazarus support other languages except FP or not and stop this discussion? The tail of the discussion was about extending FPC to do the job of the existing C compilers. The main thread is - as far as I understand it - about extending the fpc parser. I think it should be moved to fpc-devel or fpc-other. It is not about lazarus. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus - Зрелищни снимки от ЮАР 2010. Вижте най-интересните моменти! http://sportni.bg/worldcup2010/?tid=20oid=1002-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 10:37, Aleksa Todorovic wrote: And I believe you are overlooking all problems coming with maintenance of such solution. I agree that having one parser for all different kind of usage is solution which would be great to have, but my opinion is that it should be based on fcl parser, not compiler's one. And later, IF (whoever does the job) succeeds in making such a good parser (which gets integrated into, for example, Lazarus and proves to be well implemented), only then it is time to think how to connect that parser with compiler's one. At least, that's how I see this situation. Why not this: Modularize FPC's parser and test in extensively in a forked FPC. If it passes, then propose it to FPC. Afterwards, FCL --as well as anyone else-- can use it to their hearts content. And, that expands horizons, brings in more talent. Which cannot be bad for FPC, can it? It all sounds really nice, doesn't it :-) Just wait till I tell you my plans for peace in Middle East, hunger in Ethiopia, law and order in Afghanistan etc. :) Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 2010-07-01 at 11:45 +0200,lazarus-requ...@lists.lazarus.freepascal.org wrote: Hi, Message: 6 Date: Thu, 01 Jul 2010 19:30:26 +0200 From: Hans-Peter Diettrich drdiettri...@aol.com Subject: Re: [Lazarus] Parser To: Lazarus mailing list lazarus@lists.lazarus.freepascal.org Message-ID: 4c2cd0b2.7060...@aol.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Florian Klaempfl schrieb: A FP-propriety interface part would be added to the C units to make them create an FP compatible compiled unit, usable in the normal way by Pascal units and by the linker. ... and not fully automatable, so not better than current solutions. Even worse, it does not cover the cases which are really a problem like #define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the UNICODE define in windows headers #include myheader.h Things like this are the really nasty corner cases which make h2pas only semi automatic. This is correct, and also is the most important reason for a tighter integration of C source code into FPC projects. Show me a tool which translates C headers fully automatic in *usable* pascal units (test case e.g. glibc and mysql), then we can continue this discussion. Just an idea: The compiler can create the required (ppu?) files, when compiling a C module. That file then perfectly reflects all the settings, that affected the code generation of that module. Only this header version is important for the use of that module, not any other (mis-configurable) header files. Likewise the compiler can use the information in the ppu file, instead of those found in any #include file. There may exist some technical problems with this solution, because C enforces no correspondence between header and implementation files, neither by name nor content, but I think that solutions can be found on a package base. When a package contains a couple of C files, then a common package header/ppu file could contain the descriptions of *all* items in that package, and a list of related header files. Then the compiler can skip over the listed #include files, and use the precise information in the ppu file instead. This model only requires the construction of packages for all used C files, and a one-time compilation of these packages, for the construction of their ppu files. The compiler or a related tool can create an dummy Pascal library unit for every such package, for easy (human readable) use of the C packages in Pascal code. DoDi I have been trying to follow this discussion but didn't know what part to quote. I was under the possibly mistaken impression that Delphi allowed the user to link in C/C++ code to a Delphi project. I have never done this. I assumed that Lazarus could link in GNU C/C++ code. Is this, or ever will it, be possible. What is stopping us from doing this? I for one would like to open some of the Linux AisleRoit Solitaire C/C++ applications and try to run one or two of it's functions thru' a C/C++ converter then open the original C/C++ project and patch in Lazarus code. I don't want to convert the entire C/C++ code to Lazarus cos this would cause waves with the AisleRoit development team which are very pro C/C++ but it would be nice to say Hey, guys, have a look at this. It's your own code with a Pascal/Lazarus patch which improves and enhances the original game. How about making it your next version. See, you don't even need to change your original C/C++ to Lazarus. All you need do is install Lazarus and Bob's your Aunt Fanny... you've got Lazarus code patched into C/C++ code and the best of both worlds. You never know, this might open a whole new team of Linux developers using and improving the Lazarus compiler. My C/C++ skills are okay but very rusty. There is a good reason why I don't like C/C++ and choose Pascal over it. I have done a few C/C++ to Pascal/Delphi ports of Games; completely rewriting the code. I think that Pascal is more readable than C/C++ but also that the Linux world is full of die-hard C/C++ programmers and it is our duty to show that we can patch in Pascal code elegantly without needing to rewrite all of their work. Peter -- Proudly developing Quality Cross Platform Open Source Games Since 1970 with a Commodore PET 4016 with 16 KRAM http://pews-freeware-games.org (--- brand new -- still under development) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 07:12 PM, Adem wrote: Even though these can come across as nothing to do with Lazarus, they actually are --if you consider the fact that here in Lazarus list people are focused on writing applications, i.e. not compiler develeopment, anything that can expand/help with that purpose belongs to this list's very domain. In fact the Lazarus developers could decide to make the Lazarus IDE C aware and use gcc to compile the stuff. (Not that I would vote for ding so) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 10:55, Sven Barth wrote: It's not about escaping Pascal, but to grant the language new possibilities. On Android phones you can only use Java to access all subsystems of the device (e.g. GUI). You can access the framebuffer from native code though, but directly drawing to a memory field is not the same as using the available GUI classes. It has yet to be found out whether you can access the JVM from a native application (not a native library which is loaded by JVM). Also the new Windows Phone 7 series relies completly on .Net, so our WinCE cross compiler is completly useless here (the usage of .Net is enforced by the kernel itself). And Microsoft might also try to prepare the way for full .Net desktop operating systems. Now that they've discovered virtualization (Windows 7 XP Mode) the compatibility problems might stop them no more. We might not see this in Windows 8 and maybe not in Windows 9 either. But perhaps Windows 10 might be the big breaker of Win32? Free Pascal should be able to compile for these plattforms. But I don't mind to use a completly different RTL and object model that suits the targeted plattform, I only want to use the language which I believe is superior to C# and Java. All good and valid points. I respectfully retract my earlier comments in these very cases. But, the unfortunate thing is, unless someone has already done it, no amount of valid reasons alone can assure that you'll get those capabilities added. Why don't you consider organizing/initating something yourself? Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 11:13, Peter E Williams wrote: I was under the possibly mistaken impression that Delphi allowed the user to link in C/C++ code to a Delphi project. I have never done this. Unless I too am terribly mistaken, Delphi cannot directly use C/C++ source code. You first create .obj files from C/C++ source code using only Borland's C/C++ compiler and then link them to your delphi unit. The above description could be incorrect, though. I vaguely remember doing something like this (a simple compile from other peoples already customized-for-purpose code) a couple of decades ago. I assumed that Lazarus could link in GNU C/C++ code. Is this, or ever will it, be possible. What is stopping us from doing this? I don't know about GNU C/C++, but I came across to this recent post in FPC-devel while doing a search on the Net a couple hours ago. [I have no idea why I didn't receive it from the list] http://www.mail-archive.com/fpc-pas...@lists.freepascal.org/msg20812.html It may or may not be a starting point for that capability. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hi! Am 02.07.2010 10:29, schrieb Adem: But, the unfortunate thing is, unless someone has already done it, no amount of valid reasons alone can assure that you'll get those capabilities added. Yes, that is the problem... :( Why don't you consider organizing/initating something yourself? Don't think that I haven't thought of that already. :P But I have many dreams and a very huge todo-List (alone for FPC: cppclass, Native NT port, Minix port, maybe usage of SEH for Win32) and I'm also studying and have a job (the latter two are the reason I'm currently not much working on said FPC pet projects -.-)... In some time perhaps, but not now (and that might be too late... *sigh*). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 11:37, Sven Barth wrote: But I have many dreams and a very huge todo-List (alone for FPC: cppclass , Native NT port, Minix port, maybe usage of SEH for Win32) and I'm also studying and have a job (the latter two are the reason I'm currently not much working on said FPC pet projects -.-)... Curious: What will cppclass do in FPC? Is it something like this http://packages.python.org/PyBindGen/cppclass.html It says A CppClass object takes care of generating the code for wrapping a C++ class Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hi! Am 02.07.2010 10:43, schrieb Adem: On 2010-07-02 11:37, Sven Barth wrote: But I have many dreams and a very huge todo-List (alone for FPC: cppclass , Native NT port, Minix port, maybe usage of SEH for Win32) and I'm also studying and have a job (the latter two are the reason I'm currently not much working on said FPC pet projects -.-)... Curious: What will cppclass do in FPC? Is it something like this http://packages.python.org/PyBindGen/cppclass.html It says A CppClass object takes care of generating the code for wrapping a C++ class Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus It's an old feature of Free Pascal that was never fully implemented and should allow to link with C++ code/libaries without flattening the interface (like done with QT). It establishes a completly new object hierarchy that is unrelated to TObject like Jonas has done with objcclass to interface with Objective-C. You can search for cppclass site:freepascal.org to find some bug reports and mailing list entries regarding this. It's not yet documented, because I've not yet found the time to do this. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Fri, Jul 02, 2010 at 06:13:06PM +1000, Peter E Williams wrote: I have been trying to follow this discussion but didn't know what part to quote. I was under the possibly mistaken impression that Delphi allowed the user to link in C/C++ code to a Delphi project. I have never done this. I assumed that Lazarus could link in GNU C/C++ code. Is this, or ever will it, be possible. What is stopping us from doing this? Dodi thinks integrating a C compiler will allow him to do away with writing headers for such code in Pascal. I don't. C++ is a different matter. While both Delphi and FPC can link to it, it can not use them. Even Delphi needs specially crafted C++ (pureclass) code to reuse them on a higher level (without VMT hackery). This even though BCB is from the same vendor. The same for the other way around, BCB using Delphi/Pascal code requires a lot of $externalsym in the Pascal code so that a header can be generated for it. Show me a similar product, and I'll show you the compromises they had to make that make this non-trivial. Why? Because there is a fundamental problem, that can't be brushed away that easily. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 30 Jun 2010 21:53:47 +0200 Hans-Peter Diettrich drdiettri...@aol.com wrote: Mattias Gaertner schrieb: Why is this in the lazarus examples? Why not put it to the fpc sources? Because I can commit only to the Lazarus examples :-( [...] You could have asked the fpc team or put it into one of the many free repositories. [...] If the above is the only reason, then you should remove it. Any progress? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Mattias Gaertner schrieb: On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 30 Jun 2010 21:53:47 +0200 Hans-Peter Diettrich drdiettri...@aol.com wrote: Mattias Gaertner schrieb: Why is this in the lazarus examples? Why not put it to the fpc sources? Because I can commit only to the Lazarus examples :-( [...] You could have asked the fpc team or put it into one of the many free repositories. [...] If the above is the only reason, then you should remove it. Any progress? Just mail me a login and password to get your own branch in the fpc svn. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 01:36:56AM +0300, Adem wrote: I think these pie in the sky kind of scenarios are several years if not longer beyond the initial C compiler. It will be a plant that needs a lot of nurturing and care for a very long term, before it becomes an alternative, and faces stiff competition. And there is another problem that the pie in the sky scenarios seem to be the main reasons for the compiler, so it will require quite a pigheaded team. Of course, such stretched scenarios will take time --if they ever materialize. But, we can never know; perhaps there's already someone brilliant enough in the crowd here who's looking for some such feat pull and later use it as part of his/her CV. There is a difference between hope and dreaming. Be careful that you don't get hung up in some scenario where you wait for people to come, or wait till the hordes come and help out in the purest open source spirit. Somehow that never happens. If these rosy C helps Pascal interoperability scenarios are possible at all. Kylix uses Pascal bindings to libc, despite Borland having a (compatible!) C/C++ compiler. And C++ compatible Delphi code is stuffed top till bottom with {$externalsym xx} and similar helper commands I am curious: Since compilers are your domain, allow me to ask: Do you think Borland did that (peppering code with '$externalsym xx ' stuff) because there was not other/better way? And, if you had a truly compatible C/C++ compiler, would you end up doing that too? I fear so. The trouble is that I think that joining two so different languages (I mean as far as interfacing goes, e.g. C's big reliance on preprocessing that is very freeform and has no automated equivalent) totally transparently is very, very difficult. Maybe even not possible. Personally, I would invest more time in this before I went on a wild goose chase, and question why there are no quality automated translators already, after these languages have been side by side for 4 decades. The pie in the sky scenarios might turn out to be attractive on paper only e.g. when only a very small subset of headers might be readily usable without heavily adding finely grained directives. Borland had a commercial C++ compiler, commercial Pascal compilers, knowledge in the company, and they didn't. I think they suspected that something fully automated would never be possible, and keeping it lowtech and transparents makes it doable for more users. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 12:17:47AM +0200, Hans-Peter Diettrich wrote: I've already translated a couple of available C libraries into Pascal, using ToPas. There exist only a few constructs that do not translate into Pascal directly (bitfields...), but their addition to the compiler (code generators) should not be a problem - in the easiest case they can be emulated in pure OPL, not affecting the code generators at all. At statement and procedure level most languages don't differ much, and FPC even has the C operators already implemented. Since the ToPas C parser is written in OPL, its adaptation should be easy. This may become my next project, after the parser... Since accessing header files is repeated as possible advantage files again and again, how much progress have you made in the opposite direction? Automated header translation -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Adem schrieb: On 2010-07-01 00:20, Florian Klämpfl wrote: Same here: What's wrong with considering, say, a new language back-end (or front-end) much like a new CPU-support? As Michael said, it is called Pascal. Supporting a new CPU does not change this. Adding a C/Oberon/Modula whatever front end simply does not fit into this scope besides the fact that there is not the slightest advantage in doing so. I am not sure about the 'slightest advantage' aspect: I thought MS sold the .Net thing mostly on the premise of 'write in the language you're most comfortable yet share with others you/they find useful'; Exactly, sold. It's marketing speech. You could use any language but only to a degree of maybe 95%. So everybody decided to use C#. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: On Wed, Jun 30, 2010 at 10:53:39PM +0200, Michael Van Canneyt wrote: ... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc. Exactly. We can barely cope as it is. If we compiled C as well, we'd get bug reports about glibc or whatever C library fails to compile. no thanks. And, frankly, the project is called Free Pascal for a simple reason: it is a *Pascal* compiler and a *Pascal* project. I'm sorry. Can't agree with that. I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both parsing, modulesystem and language type) that one could regard it as a dialect. Aren't you against a e.g. .Net backend because it requires a completely different runtime :)? I think the same applies to M2 etc. as well? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
2010/6/30 Adem listmem...@letterboxes.org: IOW, this sort of thing should be a precondition to such contributions. Keeping the door ajar (or, at least, not closed) for this sort of thing would be --IMHO-- a good thing as it is likely to bring on (more) commercial (and, hence/hopefully more stable) interest to the FPC flora and fauna. Like Michael said, the project is called Free Pascal for a reason. But you are always welcome to fork the project and frequently merge pascal related changes from the FPC project into your forked project. This way you can choose a more appropriate project name as well. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 06/30/2010 10:23 PM, Adem wrote: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries In fact being able to tightly integrate C code (I can't speak for C++, as I can't speak it) would be really nice to have. To be useful the languages should be mixable at least on a per-unit base (better per-procedure) and the debugger would be necessary to be working properly on that. I don't think this is easy to do, though. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 09:23, Marco van de Voort wrote: There is a difference between hope and dreaming. Be careful that you don't get hung up in some scenario where you wait for people to come, or wait till the hordes come and help out in the purest open source spirit. Somehow that never happens. We're both saying pretty much the same thing, I think: Don't count your chickens before they hatch. And, I am not. It's just that unpredictabilty works both ways --cue in a quote by E. E. Cummings: You shake and shake and shake the bottle, first nothing comes and then the lottle. It took us a few million years to the first prototype of telephone, and more than a century till it became portable/mobile; and then, less than 20 years to be ubiquitous enough that world regions can now simply bypass POTS altogether in favor of GSM. Things like these make me an optimist. Now, will someone please hurry up about that flying car I've been waiting for all this time ;) Borland had a commercial C++ compiler, commercial Pascal compilers, knowledge in the company, and they didn't. I think they suspected that something fully automated would never be possible, and keeping it lowtech and transparents makes it doable for more users. I don't know. Borland, somehow, managed to lose direction, leadership and most of the talent along with it a long time ago. It turned into a bureaucratic geriatric wardful of clockers. With all the knowledge about compilers --supposedly in the company-- they are yet to come up with a 64 compiler, let alone a cross-platform RAD after all these years. Heck, they have managed to misplace the help system so badly that no one has been able to locate any sign of it for years. Having seen all these and more, I am not at all sure they went for anything more than the absolute minimum they could do about multi-(dual-)language compiler. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 06/30/2010 10:31 PM, Florian Klämpfl wrote: This can be done already using compilers supporting these languages As discussed multiple times it's not possible to share classes between FP-Pascal and GNU-C++. I don't know it it's possible at all to share classes between Pascal and C++, even if FP would be enhanced to compile C++ code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: ... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc. Exactly. We can barely cope as it is. If we compiled C as well, we'd get bug reports about glibc or whatever C library fails to compile. I've already translated a couple of available C libraries into Pascal, using ToPas. There exist only a few constructs that do not translate into Pascal directly (bitfields...), but their addition to the compiler (code generators) should not be a problem - in the easiest case they can be emulated in pure OPL, not affecting the code generators at all. At statement and procedure level most languages don't differ much, and FPC even has the C operators already implemented. Since the ToPas C parser is written in OPL, its adaptation should be easy. This may become my next project, after the parser... You are missing the point. The point is not DOING it. the point is the support afterwards. After 15 years of FPC support, I have some experience. Even now, bugs creep up that are seemingly SO basic: W : word; begin w:=0; for i:=0 to pred(w) do // What to do ? end; The compiler's behaviour is different from Delphi. This is a bug, we must deal with it. After 15 years. So, if the compiler produces different code in some C library, then we'll have to deal with it. People will report it. So no, thank you. And frankly, I would not use topas as a reference. I tried it on some - to my taste - simple C code and it failed horribly. I was unable to solve it, also because it lacks all documentation. This is not the kind of standard I would like to see in FPC. So I'd say that you already failed on something more simple than FPC compiling all languages. First get topas to convert all C code out there without a glitch, then we'll talk again. Do not get me wrong: I think topas is a technically nice product. I admire that you can write the code to do it, to make it work (more or less). That is not the point; The point is that writing the code is actually the least of the problems. It's what comes afterwards. And, frankly, the project is called Free Pascal for a simple reason: it is a *Pascal* compiler and a *Pascal* project. Microsoft started with a couple of compilers, until they implemented a common back-end for all Visual languages, and later they invented the CLR. gcc also allows to add FEs for a certain class of languages, so why should FPC not become another Free Portable Compiler? Because Microsoft has 1500 people, GCC has several companies behind it. FPC has 4 people technically savvy in compiler matters. I wonder how somebody can say it's hard to do, without having even tried ;-) I didn't say it is hard. I say that the support for it would kill us and the project. This is the problem of most open source out there: Enthousiasts write it. And then the good is separated from the bad: supporting it for many years. Patiently fixing all bugs. And there will be lots. FPC existed before the term 'Open Source' existed. That means something. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 06/30/2010 10:31 PM, Florian Klämpfl wrote: This can be done already using compilers supporting these languages As discussed multiple times it's not possible to share classes between FP-Pascal and GNU-C++. I don't know it it's possible at all to share classes between Pascal and C++, even if FP would be enhanced to compile C++ code. Only as a cppclass because the Object Pascal class modell is very different from that one of C++. But don't underestimate the work to do so: there is nothing to reuse so far. It needs a C++ front end and a C++ back end. Everybody dreaming of something like this might start with the cppclass support in FPC and create the back end part first. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 08:48:00AM +0200, Florian Klaempfl wrote: And, frankly, the project is called Free Pascal for a simple reason: it is a *Pascal* compiler and a *Pascal* project. I'm sorry. Can't agree with that. I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both parsing, modulesystem and language type) that one could regard it as a dialect. Aren't you against a e.g. .Net backend because it requires a completely different runtime :)? I think the same applies to M2 etc. as well? No, I don't think so. Since they map semantically so much pretty much the same, you can just have a sysm2 unit for some needed M2 extensions, and use the System unit as is. The only standard unit which already exists is process iirc. (for tprocess), but I have to be careful here, having used a not entirely compliant M2 compiler. The compiler is a bigger problem I think, scanner (case sensitive) and parser must be separate. But they probably can share quite some helper routines. Topspeed Pascal and Modula2 could use eachothers modules without headers. It is probably easier to do this than not. A FPC specific change would be to stuff the .DEF into a ppu etc, and not read them on import, as is tradition. The Pascal was more ISO like though, but it had TP compat too. But it also depends on how strict you want to be. I don't necessarily opt for 100% conformance and thus don't have to care about e.g. only export exactly the standarized identifiers from SYSTEM. (though in theory, that could be handled by a preproc symbol that hides it from M2 imports) But there is a reason why I come up with fork-for-a-while schemes. I actually have thought a long time about how I would organize this:-) First show something, then talk about merging. But with M2 I hoped it was sooner because less intrusive. (but my schedule would still be like 2 year after a decent proof of concept for FPC to asorb it. And then even longer to release it as stable.) p.s. I must not forget a lottery ticket this month. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hello, perhaps I'm missing the point but I think it would be a good idea to enhance swig to create fpc-bindings to C++-Classes. Personally I think there is no problem with having another C-Compiler. Regards, Stephan -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 10:17, Graeme Geldenhuys wrote: 2010/6/30 Ademlistmem...@letterboxes.org: IOW, this sort of thing should be a precondition to such contributions. Keeping the door ajar (or, at least, not closed) for this sort of thing would be --IMHO-- a good thing as it is likely to bring on (more) commercial (and, hence/hopefully more stable) interest to the FPC flora and fauna. Like Michael said, the project is called Free Pascal for a reason. But you are always welcome to fork the project and frequently merge pascal related changes from the FPC project into your forked project. This way you can choose a more appropriate project name as well. :) It's not as if I am about to start such a project, let alone dump megabytes of owen-fresh code; we're simply talking about some possible/probable future direction and whether it would be a good idea to make provision for that sort of thing. IOW, nothing concrete; nothing of imminence. At this point, I think I remember the time when you announced fpGUI --Lazarus was around then. But, I can't quite recall whether you were met with such a resistence --that there already existed a project for precisely the same purpose and you should pool in your resources into that. Were you? Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 09:18:06AM +0200, Michael Schnell wrote: On 06/30/2010 10:23 PM, Adem wrote: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries In fact being able to tightly integrate C code (I can't speak for C++, as I can't speak it) would be really nice to have. To be useful the languages should be mixable at least on a per-unit base (better per-procedure) and the debugger would be necessary to be working properly on that. I don't think this is easy to do, though. I'm less afraid of difficulty and work, but more afraid that the results, and the inevitable compromises would render it useless. People think now it would be nice and think of a solution that operates as a button compile all this pascal and C source from various origins magically together, and don't see the real picture. The real picture will probably that both the pascal and the C/C++ side need to be specially crafted. Think of Delphi's $externalsym, pureclass etc hacks. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 08:26 AM, Marco van de Voort wrote: Since accessing header files is repeated as possible advantage files again and again, In fact I already missed sadly a fully working preprocessor (to be activated optionally). Even if FPC supported such a mess, this won't solve the fundamental problem with C headers: they work only properly if every used header is compiled for each source file again so the whole unit concept of object pascal has to be thrown away. So using a fully automated always working approach you've go back to {$I ...}-style imports. Even ignoring the fact that the real value of a half automated translated header is that someone spent some brain into the translation and how it can be done in a pascal styled way. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 09:37, Adem listmem...@letterboxes.org wrote: of owen-fresh code; we're simply talking about some possible/probable future direction and whether it would be a good idea to make provision for that Fair enough. Civilised discussions would be nice to see for a change. :-) But, I can't quite recall whether you were met with such a resistence --that there already existed a project for precisely the same purpose and you should pool in your resources into that. Were you? fpGUI and LCL have very different goals, even though, from a distance, they look like the same thing. And yes, I have received many mails (more than I care to remember) saying that I should pool my efforts with LCL. LCL doesn't allow for what we [our company] need, that is why I limit my efforts to the Lazarus IDE only. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:00 AM, Florian Klaempfl wrote: Even if FPC supported such a mess, this won't solve the fundamental problem with C headers: they work only properly if every used header is compiled for each source file again Yep. Thats a fundamental philosophy of C. In fact there is a compiler flag with gcc to compile all files of a project as if there were a single source: simulated includes instead of linking.In fact there are C compilers that don't support linking at all and just compile a source file (with includes) directly to an executable. Using headers is strictly optional (and of course the .h extension is not forced), but the _convention_ is to move commonly usable external typedef etc stuff into header files. There is no dedicated syntax for this. (Free )Pascal, OTOH, provides syntax for doing units with an interface and provide using the precompiled interface definitions. Less flexible but more structured and faster than the C way. so the whole unit concept of object pascal has to be thrown away. That its why a per unit base could be more suitable and easier to do. The C units would use C header files and a GNU compatible preprocessor. A FP-propriety interface part would be added to the C units to make them create an FP compatible compiled unit, usable in the normal way by Pascal units and by the linker. So using a fully automated always working approach you've go back to {$I ...}-style imports. Even ignoring the fact that the real value of a half automated translated header is that someone spent some brain into the translation and how it can be done in a pascal styled way. Yep. (Still considering that on top of enabling FP to compile C sources enabling the IDE including the debugger is an additional challenge.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 09:34:12AM +0200, Michael Schnell wrote: On 07/01/2010 08:26 AM, Marco van de Voort wrote: Since accessing header files is repeated as possible advantage files again and again, In fact I already missed sadly a fully working preprocessor (to be activated optionally). This does help with Pascal sources from time to time (in fact I do like macros better than generics :) ). Preprocessor is very attractive, because it fits the edit and change metaphore. Technically they are disaster though. I don't see why simply calling the gcc preprocessor is not a viable option (at least with Lazarus on Linux). Supposedly for a better integration a Pascal based workalike preprocessor might be better. Ask yourself why GCC doesn't have preprocessed headers, and you'll find the answer. YOu would need to ensure that the preprocessed state is entirely the same before using a precompiled unit. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 10:21:30AM +0200, Michael Schnell wrote: On 07/01/2010 10:00 AM, Florian Klaempfl wrote: Even if FPC supported such a mess, this won't solve the fundamental problem with C headers: they work only properly if every used header is compiled for each source file again Yep. Thats a fundamental philosophy of C. You make it sound like it is some deep philosophical decision, while in fact they did this because their PDP-8 was short on memory, and they separated the compilation stages as much as possible to maximize the program that could be compiled. However I haven't really seen a compilation unit that exhausts my 4GB memory (and then I'm not even speaking about 64-bit) In fact there is a compiler flag with gcc to compile all files of a project as if there were a single source: simulated includes instead of linking.In fact there are C compilers that don't support linking at all and just compile a source file (with includes) directly to an executable. Yes, and this is why gcc and most other C compilers have a totally manual build systems, where you have to manually specify depedancies, so the compiler can figure out what to recompile. It would be an enormous step back. (Free )Pascal, OTOH, provides syntax for doing units with an interface and provide using the precompiled interface definitions. Less flexible but more structured and faster than the C way. FPC also provides $I which is exactly the same as #include in C. so the whole unit concept of object pascal has to be thrown away. That its why a per unit base could be more suitable and easier to do. The C units would use C header files and a GNU compatible preprocessor. A FP-propriety interface part would be added to the C units to make them create an FP compatible compiled unit, usable in the normal way by Pascal units and by the linker. And no other C compiler would be compatible with it, voiding the only positive aspect of C. Useless. (Still considering that on top of enabling FP to compile C sources enabling the IDE including the debugger is an additional challenge.) The IDE already includes a debugger. Lazarus just chose to not go that route. It has nothing to do with C compilers. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:57 AM, Marco van de Voort wrote: And no other C compiler would be compatible with it, voiding the only positive aspect of C. As this is a pure addition to make the code integrate with FP, only necessary if other FP units are supposed to use this interface (the linker can do without it) the code can be included in C-style comments ( /* ... */ ) and only be interpreted by the FP parser. No harm done. The IDE already includes a debugger. Lazarus just chose to not go that route. It has nothing to do with C compilers. Exactly. Thus, IMHO, If Lazarus does not follow, it does not make much sense to enhance the compiler to be able to decently cope with C code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 01/07/10 09:57, Marco van de Voort wrote: Yes, and this is why gcc and most other C compilers have a totally manual build systems, where you have to manually specify depedancies, so the compiler can figure out what to recompile. I just use gcc -MMD in my Makefiles, which generates the dependencies for me. Henry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 10:51 AM, Marco van de Voort wrote: Ask yourself why GCC doesn't have preprocessed headers, I supposed you mean precompiled headers and not headers that are passed through the preprocessor. This is according to what I called the C philosophy in the other mail. Even if this philosophy is simplistic and introduced by need rather than by science, it _is_ consistent and workable. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertner nc-gaert...@netcologne.de wrote: You could have asked the fpc team or put it into one of the many free repositories. If you put something into lazarus examples then lazarus users expect a reason for downloading 650KB extra. If the above is the only reason, then you should remove it. +1 And the whole thread has nothing to do with lazarus at all. Is it possible to continue the discussion somewhere else, please? R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Henry Vermaak schrieb: On 01/07/10 09:57, Marco van de Voort wrote: Yes, and this is why gcc and most other C compilers have a totally manual build systems, where you have to manually specify depedancies, so the compiler can figure out what to recompile. I just use gcc -MMD in my Makefiles, which generates the dependencies for me. This works for your headers if you take care of them and it already breaks if you mess with conditional #includes (which must be covered by a fully automated solution). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 10:51 AM, Marco van de Voort wrote: Ask yourself why GCC doesn't have preprocessed headers, I supposed you mean precompiled headers and not headers that are passed through the preprocessor. This is according to what I called the C philosophy in the other mail. Even if this philosophy is simplistic and introduced by need rather than by science, it _is_ consistent and workable. ... which does not mean that it fits into the Pascal philosophy. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 11:08:49AM +0200, Michael Schnell wrote: Ask yourself why GCC doesn't have preprocessed headers, I supposed you mean precompiled headers and not headers that are passed through the preprocessor. This is according to what I called the C philosophy in the other mail. Even if this philosophy is simplistic and introduced by need rather than by science, it _is_ consistent and workable. I don't hate C. I use it daily. But I still think it shows that it was never meant for applications programming(*). For that I think workable doesn't apply. Survivable maybe, but IMHO not something one would choose if you could avoid it. For systems usage, I think it is still not ideal, but it matters less. (*) not entirely true historically. C was also meant for making the unix utils, but in their time they were much, much smaller than they are nowadays. I think ls nowadays is bigger than the C compiler (the biggest *nix app) in the old days -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 10:00 AM, Florian Klaempfl wrote: Even if FPC supported such a mess, this won't solve the fundamental problem with C headers: they work only properly if every used header is compiled for each source file again Yep. Thats a fundamental philosophy of C. In fact there is a compiler flag with gcc to compile all files of a project as if there were a single source: simulated includes instead of linking.In fact there are C compilers that don't support linking at all and just compile a source file (with includes) directly to an executable. Using headers is strictly optional (and of course the .h extension is not forced), but the _convention_ is to move commonly usable external typedef etc stuff into header files. There is no dedicated syntax for this. (Free )Pascal, OTOH, provides syntax for doing units with an interface and provide using the precompiled interface definitions. Less flexible but more structured and faster than the C way. so the whole unit concept of object pascal has to be thrown away. That its why a per unit base could be more suitable and easier to do. The C units would use C header files and a GNU compatible preprocessor. A FP-propriety interface part would be added to the C units to make them create an FP compatible compiled unit, usable in the normal way by Pascal units and by the linker. ... and not fully automatable, so not better than current solutions. Even worse, it does not cover the cases which are really a problem like #define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the UNICODE define in windows headers #include myheader.h Things like this are the really nasty corner cases which make h2pas only semi automatic. Show me a tool which translates C headers fully automatic in *usable* pascal units (test case e.g. glibc and mysql), then we can continue this discussion. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 11:22 AM, Marco van de Voort wrote: I don't hate C. I use it daily. But I still think it shows that it was never meant for applications programming(*). For that I think workable doesn't apply. Survivable maybe, but IMHO not something one would choose if you could avoid it. Yep. This is why we (company) use C for deeply embedded stuff, while for application programming and not-so-deeply-embedded (PC-based right now, ARM-based to come) projects, we use Pascal. (Never touching C++ :) ) But exactly this sometimes asks for using C code in Pascal projects to avoid duplicating of code snippets. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 07/01/2010 11:15 AM, Florian Klaempfl wrote: ... which does not mean that it fits into the Pascal philosophy. Of course it does not. That exactly was my point. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 07/01/2010 11:15 AM, Florian Klaempfl wrote: ... which does not mean that it fits into the Pascal philosophy. Of course it does not. That exactly was my point. So it's pretty clear that a C front end does not change much. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: I am curious: Since compilers are your domain, allow me to ask: Do you think Borland did that (peppering code with '$externalsym xx ' stuff) because there was not other/better way? And, if you had a truly compatible C/C++ compiler, would you end up doing that too? I fear so. The trouble is that I think that joining two so different languages (I mean as far as interfacing goes, e.g. C's big reliance on preprocessing that is very freeform and has no automated equivalent) totally transparently is very, very difficult. Maybe even not possible. Personally, I would invest more time in this before I went on a wild goose chase, and question why there are no quality automated translators already, after these languages have been side by side for 4 decades. IMO we should separate C from C++ in this debate. C++ has a very different object model form the Delphi one, as have other languages as well (Java, Oberon et al. - which also use GC allover). That's why a restriction to only C will result in much simpler solutions, as I demonstrated in my ToPas converter. An only-C front-end for an Pascal compiler would be sufficient to me, allowing to use existing C library code immediately in Pascal programs. The problem, that lead to the stall of the ToPas project, is the separation of the C #defines into true constants, functions and macros. When the user has to classify each of the #defines in e.g. Windows.h (about 900) himself, this makes the entire project unusable. But when instead the C code is preprocessed automatically, and fed directly into the tree generation of the compiler, such user decisions are no more required. The pie in the sky scenarios might turn out to be attractive on paper only e.g. when only a very small subset of headers might be readily usable without heavily adding finely grained directives. Borland had a commercial C++ compiler, commercial Pascal compilers, knowledge in the company, and they didn't. I think they suspected that something fully automated would never be possible, and keeping it lowtech and transparents makes it doable for more users. The BCB was a nice try, aimed at the C++ coder community, but Borland only could establish it as a serious MSC competitor, that forced Microsoft to upgrade their crappy MSC (and other) tool suites into the up-to-date MSVC development system. Since that time the development of the VCL and IDE was the only thing Borland could do, and its low market acceptance lead to the sale of that division, that ended up in Embarcadero. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Marco van de Voort schrieb: On Thu, Jul 01, 2010 at 12:17:47AM +0200, Hans-Peter Diettrich wrote: I've already translated a couple of available C libraries into Pascal, using ToPas. There exist only a few constructs that do not translate into Pascal directly (bitfields...), but their addition to the compiler (code generators) should not be a problem - in the easiest case they can be emulated in pure OPL, not affecting the code generators at all. At statement and procedure level most languages don't differ much, and FPC even has the C operators already implemented. Since the ToPas C parser is written in OPL, its adaptation should be easy. This may become my next project, after the parser... Since accessing header files is repeated as possible advantage files again and again, how much progress have you made in the opposite direction? Automated header translation Sorry, I don't understand your point :-( I found it inevitable to process existing C code at the source level, so that every update can be reflected immediately and automatically by the compiler. Any source code transformation, from C to Pascal, has to be repeated after every such update, leading to much manual intervention, and all modifications in the previously translated Pascal code are lost. A maintenance nightmare :-( About the opposite direction, Detlef Meyer-Eltz has made big progress in providing translators from Delphi/OPL and Java into C++, see e.g. http://www.texttransformer.com/Delphi2Cpp_en.html. While these tools are not perfect, what IMO is impossible to achieve, they have been used in the conversion of a couple of big commercial projects into C++. This one-time transformation is *not* what I want to achieve, for the beforementioned (maintenance) reasons. It may be a goodie for making people move from C/C++ background to Pascal, when they can transform all their legacy projects to the new language, but this can be achieved independently from any concrete Pascal compiler. As long as we live in a C dominated world (Linux...), every compiler should be able to process C code, so that at least the existing C libraries can be used immediately. Sometimes it's sufficient to only have a header conversion tool, for external libraries, but sometimes it's more desireable to incorporate such libraries more directly into an application, like Delphi and Lazarus allow with their package system. Such packages could be made usable more easily, when e.g. a more pascally interface can be added to the original source code, by e.g. patches, so that the use of such libraries is no more restricted to their original C interface. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: I am not sure about the 'slightest advantage' aspect: I thought MS sold the .Net thing mostly on the premise of 'write in the language you're most comfortable yet share with others you/they find useful'; Exactly, sold. It's marketing speech. You could use any language but only to a degree of maybe 95%. So everybody decided to use C#. Diabolic hint: why should Free Pascal users be bound to the Delphi OPL syntax, even with mode FPC extensions? When the use of another language or dialect could eliminate a couple of problems, like the never ending discussion about the proper formatting of the source code, or the export of any number of basically unit-specific declarations, required by the uses and interface/implementation model. The occurence of circular unit references IMO can be reduced a lot, when only the really exported declarations can be reduced by more fine-grained syntactical means (Oberon * attribute). What were so bad when the users, coming from e.g. Delphi, will find out that the Modula or Oberon language will fit their expectations much better than the crappy Delphi or derived FPC syntax? And what about an Objective-C front-end, that will perfectly match the Sun requirements for iPad etc. applications? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both parsing, modulesystem and language type) that one could regard it as a dialect. Aren't you against a e.g. .Net backend because it requires a completely different runtime :)? I think the same applies to M2 etc. as well? IMO we could separate the language itself (syntax) from the RTL (semantics). At least I can imagine the use of a different syntax at the procedure body (block, statement...) level, like already implemented for assembly language blocks. The requirement of *full* M2, Oberon or P# g compatibility IMO is very low, due to the few existing (public/commercial) projects in these languages. We also could make FPC an playground for language designers, which could implement their own languages in dedicated front-ends, as long as they use the existing FPC system library, tree nodes and other data structures, as far as these are hard-coded in the compiler, optimizer and code generators. In contrast the implementation of parallel RTLs may be a bad idea, we already have enough problems with platforms and widgetsets... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: In fact I already missed sadly a fully working preprocessor (to be activated optionally). This does help with Pascal sources from time to time (in fact I do like macros better than generics :) ). You could use the scanner/preprocessor part of ToPas, if you want an fully conforming C preprocessor. I think that I dropped this project from ToPas, but it could be added again without problems. IIRC Skalogryz currently is porting all that stuff from Delphi to Lazarus... I don't see why simply calling the gcc preprocessor is not a viable option (at least with Lazarus on Linux). Supposedly for a better integration a Pascal based workalike preprocessor might be better. The C preprocessor most probably depends on C syntax (strings and other literals...), so its use may be restricted to such source code. AFAIR the C90 standard (C98 for sure) already required that the preprocessor is an integral part of the compiler, so that up-to-date stand-alone preprocessors may be rare. And not all of them comply to the standard, with regards to proper macro expansion. I know about two extreme cases, where the Sinix(?) preprocessor insisted in expanding #defined symbols even in string literals, and the Microsoft preprocessor has other incompatible ideas about macro expansion and comments; you'll find more details in the ToPas documentation... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Van Canneyt schrieb: You are missing the point. The point is not DOING it. the point is the support afterwards. After 15 years of FPC support, I have some experience. Even now, bugs creep up that are seemingly SO basic: W : word; begin w:=0; for i:=0 to pred(w) do // What to do ? end; The compiler's behaviour is different from Delphi. This is a bug, we must deal with it. After 15 years. So, if the compiler produces different code in some C library, then we'll have to deal with it. People will report it. So no, thank you. Thanks for the concrete example. I also remember a discussion about Inc/Dec, where every improvment (taking into account the signedness of the operand) was rejected, in favor of the translate into a single machine instruction - where not every CPU supports such an instruction. With regards to subtle OPL/C differences I don't expect that these are handled by the FPC team. Additional front-ends are not a concrete subject right now, they only came up as another chance to extend the compiler. Furthermore the C language specification is quite vague in many details, while an OPL specification does not exist at all, so that code like the above most probably will behave differently, depending on the used compiler (both as C and Pascal code). And frankly, I would not use topas as a reference. I tried it on some - to my taste - simple C code and it failed horribly. I was unable to solve it, also because it lacks all documentation. This is not the kind of standard I would like to see in FPC. Do you seriously expect that things will change, without any feedback? :-( Perhaps you missed the ToPas documentation, available in a separate download? I know that this project is very hard to use, due to the dependency on external resources (header files, compiler specifications), so that I can understand when people have problems to use it as-is. That's why I abandoned further work on this project, many years ago, after I could make it work with the header files and libraries of several compilers. And there was no reason to put my hands on it at any later time, due to zero feedback. In detail I missed feedback with ideas to make it easier usable. So I'd say that you already failed on something more simple than FPC compiling all languages. First get topas to convert all C code out there without a glitch, then we'll talk again. The base of the ToPas project was the C preprocessor and parser, previously implemented as the CScan project. ToPas effectively is a test application for that project, and there I found no way to make it an *easily* usable tool. In so far an FPC front-end would be just another test case for CScan, where it could be made usable much easier, and possibly with more helpful feedback. Do not get me wrong: I think topas is a technically nice product. I admire that you can write the code to do it, to make it work (more or less). That is not the point; The point is that writing the code is actually the least of the problems. It's what comes afterwards. I'm still waiting for such problems, and I'm willing to fix all known bugs myself :-) Because Microsoft has 1500 people, GCC has several companies behind it. FPC has 4 people technically savvy in compiler matters. So the addition of only one person (me) would add 25% percent to the staff - which other compiler manufacturer can afford such an increase? ;-) I wonder how somebody can say it's hard to do, without having even tried ;-) I didn't say it is hard. I say that the support for it would kill us and the project. That's why I intend to make the (eventual) C front-end a non-breaking add-on to FPC, that relies on nothing but the existing compiler infrastructure and back-ends. Then we can find out more about the hidden capabilities of the compiler, and the chance and problems of integrating (very) different languages. In case that project fails to work sufficiently, due to unforeseen language incompatibilities, I've spent some time at least with learning more about concrete compilers :-) This is the problem of most open source out there: Enthousiasts write it. And then the good is separated from the bad: supporting it for many years. Patiently fixing all bugs. And there will be lots. I've already been spending much time in the Lazarus docking managers, so that now the IDE offers docking support, after years of preparations. But since this project is almost finished now, I'm looking for further projects, that may be useful to others. I can spend all my time in such projects, the only limitation is increasing age and consequential health problems. FPC existed before the term 'Open Source' existed. That means something. My discompilers (borrow'd from disassemblers) also worked a long time before the term decompiler was even born ;-) I only didn't publish them, except for the VB3 decompiler, because I wanted to control their use myself. Many
Re: [Lazarus] Parser
Florian Klaempfl schrieb: In fact I already missed sadly a fully working preprocessor (to be activated optionally). Even if FPC supported such a mess, this won't solve the fundamental problem with C headers: they work only properly if every used header is compiled for each source file again so the whole unit concept of object pascal has to be thrown away. This is only partly true. gcc already supports (non-standard) extensions, like #include_next and #include_once - don't beat me for the exact wording ;-) Other compilers use other mechanisms (heuristics, pragmas...), in order to reduce the number of passes over the same header files. Only the standard-conforming guards require to scan and preprocess all #included files on every occurence, because the terminating #endif could reside anywhere in the file, not only at its end. And finally, a Pascal compiler works different from a C compiler, with regards to the interfaces of other source modules (see below) So using a fully automated always working approach you've go back to {$I ...}-style imports. Even ignoring the fact that the real value of a half automated translated header is that someone spent some brain into the translation and how it can be done in a pascal styled way. The Pascal style suffers from essentially the same problems, when {$I ...} is found in the source code - I just came across the {$I fpcdefs.inc} in the FPC compiler. The major advantage of the OPL unit and project concept (or .NET assemblies...) is the combination of interface and implementation in an single file, that must be parsed only once in order to extract its exports. This means that #/$include in a Pascal source file has a different meaning to the compilation, because that file *must* become part of the source. If C/C++ had an equivalent to the OPL uses, the *compiler* could determine whether those files have to be included literally, or whether they could be parsed once for exported symbols and macro definitions (precompiled headers...). Also a Pascal compiler can compile multiple units in one go, whereas a C/C++ compiler has no idea of related files, and must compile every single source file independently, #including all the used header files literally. In so far $I and #include are fully equivalent, it's only the *usage* of $I, that is not required for used units. The (currently) only difference between C and FPC preprocessors is the macro definition and expansion, that allows for much trickier constructs in an C preprocessor (macro arguments, recursive expansion, # and ## substitution...). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: On 06/30/2010 10:23 PM, Adem wrote: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries In fact being able to tightly integrate C code (I can't speak for C++, as I can't speak it) would be really nice to have. To be useful the languages should be mixable at least on a per-unit base (better per-procedure) and the debugger would be necessary to be working properly on that. I don't think this is easy to do, though. IMO we should not go into such details right now, like the debugger. Instead we should find out about useful applications of the parser and additional front-ends, to give motivation to the FPC developers to implement some basic (non-breaking) prerequisites. Then we can find out more about further chances and problems, in concrete projects that use the FPC compiler and related code as-is. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 01 Jul 2010 00:54:21 +0200 Hans-Peter Diettrich drdiettri...@aol.com wrote: For now it's sufficient to discuss the possibilities from the user VP, that's why I started this thread in the Lazarus list. Epic fail. This is the Lazarus users list and not the FPC users list. Why not discuss it in the correct place? Yes, some Lazarus users might be interested in this topic, but that does not change the fact that this is the wrong list to discuss this, as the thread clearly shows. Nearly no mention of Lazarus at all. And only because it is vaguely related does not mean it is the correct list. Thx, for not listening. A not amused R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Since accessing header files is repeated as possible advantage files again and again, how much progress have you made in the opposite direction? Automated header translation Sorry, I don't understand your point :-( The point is: if an additional C front end for fpc could do fully automatically the job, it must be also possible to do this with an external tool which translates C to pascal. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
It's a trap! - Admiral Ackbar What MS really wants is that you write code in whatever-language-you-please as long as you run it at THEIR operating system. Forget Mono and other silly attempts to clone .NET Framework -- they are doomed to always lag behind MS implementation. That's the opposite of interpreted Java or compiled Free Pascal, where the goal is to write once, run anywhere. Adem escreveu: I am not sure about the 'slightest advantage' aspect: I thought MS sold the .Net thing mostly on the premise of 'write in the language you're most comfortable yet share with others you/they find useful'; and it seems --if it was properly licensed-- it could catch on on other platforms too. -- Alexsander da Rosa Twitter: @alexrosa -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 11:19, Graeme Geldenhuys wrote: fpGUI and LCL have very different goals, even though, from a distance, they look like the same thing. And, I am sure people get to appreciate their differences once they spend a little time to understand what they are. Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other similar projects are a richness for the whole community --not resource consumers-- serving different needs. And yes, I have received many mails (more than I care to remember) saying that I should pool my efforts with LCL. I could ask whether these emails came from the core of LCL team, but that wouldn't contribute to our discussion here. I will, however, ask whether you thought they were *fair*. LCL doesn't allow for what we [our company] need, that is why I limit my efforts to the Lazarus IDE only. IOW, your work on/with fpGUI has all but helped LCL too. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other Cui honorem, honorem ;-) His name is Martin Schreiber (MSEide+MSEgui) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 12:10, Reimar Grabowski wrote: On Thu, 1 Jul 2010 00:19:34 +0200 Mattias Gaertnernc-gaert...@netcologne.de wrote You could have asked the fpc team or put it into one of the many free repositories. If you put something into lazarus examples then lazarus users expect a reason for downloading 650KB extra. If the above is the only reason, then you should remove it. +1 And the whole thread has nothing to do with lazarus at all. Actually, it does --quite a bit. It all started off with how we could come up with a code formatter (plus refactoring tools etc.) that uses a parser codebase that did not have to be written/maintained separately. It turned out that, in its current shape, FPC wasn't suitable for such use due to its monolithic nature, so we discussed --briefly-- what could be done about that (i.e. ways to refactor FPC code in such a way that downstream projects could re-use its modules). Now, the discussion has moved on to whether --while doing all that-- it would be a good idea to provide infrastructure for other expansion (such as other lang back-ends). Even though these can come across as nothing to do with Lazarus, they actually are --if you consider the fact that here in Lazarus list people are focused on writing applications, i.e. not compiler develeopment, anything that can expand/help with that purpose belongs to this list's very domain. Is it possible to continue the discussion somewhere else, please? Personally, I'd think it'd be mistake to do that. I would, OTOH, very much appreciate if you could spare some time and contribute towards future direction. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote: Do you seriously expect that things will change, without any feedback? :-( Perhaps you missed the ToPas documentation, available in a separate download? I know that this project is very hard to use, due to the dependency on external resources (header files, compiler specifications), so that I can understand when people have problems to use it as-is. That's why I abandoned further work on this project, many years ago, after I could make it work with the header files and libraries of several compilers. And there was no reason to put my hands on it at any later time, due to zero feedback. In detail I missed feedback with ideas to make it easier usable. First idea: make it a lazarus project. I rarely have windows available. After a trivial test, I wanted to translate libsee. It's heavily unix based, so of course the whole windows side of the - now discovered, thank you - docu is useless. BTW. The reference to Templates.htm in index.html is wrong. I've already been spending much time in the Lazarus docking managers, so that now the IDE offers docking support, after years of preparations. But since this project is almost finished now, I'm looking for further projects, that may be useful to others. I can spend all my time in such projects, the only limitation is increasing age and consequential health problems. Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler). - use it to create a pascal to javascript translator. - Create a .net backend code generator. - Create a java bytecode backend code generator. The latter 2 are much asked for by users, and while none of the core maintainers has any desire to work on them, patches implementing them will definitely be accepted (within certain limits the team will set) if you also accept maintenance. Since you seem well versed in pascal, parsing and whatnot, I think you should be up to the task. And contrary to a new front-end, I think there will be little to no discussion about their acceptance, as long as the pascal language is respected. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:10, theo wrote: Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other Cui honorem, honorem ;-) His name is Martin Schreiber (MSEide+MSEgui) Thank you for the correction. I apologize for the typo. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 01 Jul 2010 20:12:52 +0300 Adem listmem...@letterboxes.org wrote: Even though these can come across as nothing to do with Lazarus, they actually are --if you consider the fact that here in Lazarus list people are focused on writing applications, i.e. not compiler develeopment, anything that can expand/help with that purpose belongs to this list's very domain. http://techbuddha.files.wordpress.com/2009/12/double-facepalm.jpg Is it possible to continue the discussion somewhere else, please? Personally, I'd think it'd be mistake to do that. The FPC lists are the correct place to discuss FPC topics. Enough of them there, user/devel/other choose one. I would, OTOH, very much appreciate if you could spare some time and contribute towards future direction. No problem. Keep the compiler/parser as it is (this means fast and working). Enhance the parser fpdoc uses = win Enhace h2pas for better automatic header translation = double win R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 19:51, Alexsander Rosa wrote: It's a trap! - Admiral Ackbar What MS really wants is that you write code in whatever-language-you-please as long as you run it at THEIR operating system. Forget Mono and other silly attempts to clone .NET Framework -- they are doomed to always lag behind MS implementation. That's the opposite of interpreted Java or compiled Free Pascal, where the goal is to write once, run anywhere. We all know MS's intentions --and they made it obvious by the way went about licensing that stuff. Apart from that, it --IMO-- wasn't a bad idea at all. Shame it was doomed to failure due to licensing. Adem escreveu: I am not sure about the 'slightest advantage' aspect: I thought MS sold the .Net thing mostly on the premise of 'write in the language you're most comfortable yet share with others you/they find useful'; and it seems --if it was properly licensed-- it could catch on on other platforms too. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, 1 Jul 2010 19:14:40 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler). +1 R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 7/1/2010 1:14 PM, Michael Van Canneyt wrote: - Make fcl-passrc complete. (*NOT* extract parser from compiler). +1 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Michael Schnell schrieb: Ask yourself why GCC doesn't have preprocessed headers, I supposed you mean precompiled headers and not headers that are passed through the preprocessor. This is according to what I called the C philosophy in the other mail. Even if this philosophy is simplistic and introduced by need rather than by science, it _is_ consistent and workable. There is one problem with the independent header files: what if modules are compiled with #defines or an #include stack, that differ from those used to compile another (used) module itself? FPC overcomes this problem with the .ppu files (I assume), C++ with mangled names, reflecting the precise attributes of every compiled item. This problem also should make clear that (standard) header files *must* be compiled with the same settings, or better must be insensitive to all external #defines or previously #included files, so that a project uses the same compilation parameters for all referenced modules. In so far it's perfectly acceptable to use precompiled header files, that match the compiled version of every module in a project or library. The compiler only should place and search for such precompiled headers in the object directory, into which a module (to be linked) has been compiled. But this in turn would require to pass the path to every single library folder to the compiler... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klaempfl schrieb: A FP-propriety interface part would be added to the C units to make them create an FP compatible compiled unit, usable in the normal way by Pascal units and by the linker. ... and not fully automatable, so not better than current solutions. Even worse, it does not cover the cases which are really a problem like #define CONFIGURE_THE_HEADER_IN_A_CERTAIN_WAY // simple example are the UNICODE define in windows headers #include myheader.h Things like this are the really nasty corner cases which make h2pas only semi automatic. This is correct, and also is the most important reason for a tighter integration of C source code into FPC projects. Show me a tool which translates C headers fully automatic in *usable* pascal units (test case e.g. glibc and mysql), then we can continue this discussion. Just an idea: The compiler can create the required (ppu?) files, when compiling a C module. That file then perfectly reflects all the settings, that affected the code generation of that module. Only this header version is important for the use of that module, not any other (mis-configurable) header files. Likewise the compiler can use the information in the ppu file, instead of those found in any #include file. There may exist some technical problems with this solution, because C enforces no correspondence between header and implementation files, neither by name nor content, but I think that solutions can be found on a package base. When a package contains a couple of C files, then a common package header/ppu file could contain the descriptions of *all* items in that package, and a list of related header files. Then the compiler can skip over the listed #include files, and use the precise information in the ppu file instead. This model only requires the construction of packages for all used C files, and a one-time compilation of these packages, for the construction of their ppu files. The compiler or a related tool can create an dummy Pascal library unit for every such package, for easy (human readable) use of the C packages in Pascal code. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 18:18, Reimar Grabowski wrote: Yes, some Lazarus users might be interested in this topic, but that does not change the fact that this is the wrong list to discuss this, as the thread clearly shows. Nearly no mention of Lazarus at all. Lazarus users use FPC! Lazarus doesn't support another compiler - period. Some of you guys should really lighten up a bit and stop being so anal about what is discussed in what mailing list. I already think there is way to many mailing lists between FPC and Lazarus. Information just gets fragmented! Regarding you not liking this message thread... Like I told somebody else learn to use your software. eg: If you are not interested in the message thread... First don't read it! Secondly, if you are using Mozilla Thunderbird, simply press the R key and it marks the whole thread as READ (I'm pretty sure other email clients can do the same, if not your loss). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
I love you Graeme. Ever have, ever will. Life would be so empty without you. Kisses R. p.s.: Real men don't use Thunderbird -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hans-Peter Diettrich schrieb: This is correct, and also is the most important reason for a tighter integration of C source code into FPC projects. I cannot see how a tighter integration would solve this. The compiler can create the required (ppu?) files, when compiling a C module. That file then perfectly reflects all the settings, that affected the code generation of that module. Only this header version is important for the use of that module, not any other (mis-configurable) header files. But this solution is not universal. It simply cannot cope with all situations which might appear in C headers so it's not better than any other tool available currently. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 1 July 2010 18:58, Adem wrote: I will, however, ask whether you thought they were *fair*. Those suggesting it, did not understand our companies needs. I think I have explained myself already to a few of the core LCL developers (and a few others too) so they might have a better understanding of why our company don't use LCL. LCL doesn't allow for what we [our company] need, that is why I limit my efforts to the Lazarus IDE only. IOW, your work on/with fpGUI has all but helped LCL too. Unfortunately not everybody sees it that clearly. Contributions come in all shapes and sizes. I contribute features driven by need, or fix minor issues I could easily find a solution for. But most of my contributions come from bug reports and helping to pinpoint the location of the issue. Unfortunately many here in the Lazarus mailing list consider the last point as nagging or always trying to talk Lazarus down. I stopped caring about those misguided few that don't understand my point of view - I have much more important things to worry about these days. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 23:22, Florian Klämpfl wrote: Hans-Peter Diettrich schrieb: The compiler can create the required (ppu?) files, when compiling a C module. That file then perfectly reflects all the settings, that affected the code generation of that module. Only this header version is important for the use of that module, not any other (mis-configurable) header files. But this solution is not universal. Personally, I too would like solutions that cover every nook and cranny; but, life rarely grants such luxuries.. When confronted with nothing at all, I have been known to settle for much less than 50 percent. If that solution is not universal, what percentile do you think it would cover? It simply cannot cope with all situations which might appear in C headers so it's not better than any other tool available currently. What other tools are there that can create (ppu?) files directly usable with FPC? Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On 1 July 2010 22:06, Reimar Grabowski wrote: I love you Graeme. Ever have, ever will. Life would be so empty without you. Kisses R. p.s.: Real men don't use Thunderbird PS: Real men (or any men for that matter) shouldn't send me emails like the above. My wife doesn't like competition. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:26, Reimar Grabowski wrote: On Thu, 01 Jul 2010 20:12:52 +0300 Ademlistmem...@letterboxes.org wrote: Even though these can come across as nothing to do with Lazarus, they actually are --if you consider the fact that here in Lazarus list people are focused on writing applications, i.e. not compiler develeopment, anything that can expand/help with that purpose belongs to this list's very domain. http://techbuddha.files.wordpress.com/2009/12/double-facepalm.jpg I am sorry, I didn't think that paragraph would be that unparseable --can I have a copy of the error log. :) Is it possible to continue the discussion somewhere else, please? Personally, I'd think it'd be mistake to do that. The FPC lists are the correct place to discuss FPC topics. Enough of them there, user/devel/other choose one. Thank you for displaying just the the kind of community spirit I like whereby each and every member thinks the whole belongs to him/her as his/her personal lawn. By that token, you --just as anybody else-- can tell me off your personal lawn; can't you? Of course, you can. After all, you own this place. ;) I would, OTOH, very much appreciate if you could spare some time and contribute towards future direction. No problem. Keep the compiler/parser as it is (this means fast and working). Order Contribution. Enhance the parser fpdoc uses = win Enhace h2pas for better automatic header translation = double win And, do those all over every time some little thing changes --for ever and ever. I see. How about this as a more sensible approach: Refactor the FPC code so that its relevant modules are usable in the above applications (and more). Further: While doing that, refactor it so that ordinary mortals too could comprehend it better to off-load some of the immense burdens on the shoulders of the Core team. Add to that: In the process, rearrange a few things so that future expansion --such as multilanguage compilation etc.-- becomes a tangible possibility. Such an awful idea, isn't it? What I find interesting and yet dismaying is this: You choose not to have any input (like how about doing XXX also, while you're at it?) other than get off my lawn!.. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-01 20:14, Michael Van Canneyt wrote: Well, if you need things to do: - Make fcl-passrc complete. (*NOT* extract parser from compiler). I just cannot understand this: What is so holy about the 'parser from compiler'? - use it to create a pascal to javascript translator. - Create a .net backend code generator. - Create a java bytecode backend code generator. Aren't all these some form of 'escape route's --from always Pascal to somewhere else? I mean, people --of course-- should be given opportunities to escape; but, what does it say about their concerns about Pascal in the first place :) Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Fri, 02 Jul 2010 00:55:27 +0300 Adem listmem...@letterboxes.org wrote: First of all I apologize for hurting your feelings. Second, please calm down. This is only a technical mailing list and in my opinion the wrong one for this discussion. Further: While doing that, refactor it so that ordinary mortals too could comprehend it better to off-load some of the immense burdens on the shoulders of the Core team. Did you actually read Michaels and Florians mails? Does not look like. Add to that: In the process, rearrange a few things so that future expansion --such as multilanguage compilation etc.-- becomes a tangible possibility. See above. Such an awful idea, isn't it? Yes, it is an awful idea. Kind regards R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Thu, 1 Jul 2010 23:27:43 +0200 Graeme Geldenhuys graemeg.li...@gmail.com wrote: PS: Real men (or any men for that matter) shouldn't send me emails like the above. My wife doesn't like competition. :-) Africa is so far away, I have no fear. Regarding the thread: No bad feelings, just different opinions. Have a nice day R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On 2010-07-02 02:10, Reimar Grabowski wrote: On Fri, 02 Jul 2010 00:55:27 +0300 Ademlistmem...@letterboxes.org wrote: First of all I apologize for hurting your feelings. No problem. Except for mild disappointment, no harm done. Second, please calm down. This is only a technical mailing list and in my opinion the wrong one for this discussion. Thank you for kindly consoling me. I am feeling a lot better now. :) Further: While doing that, refactor it so that ordinary mortals too could comprehend it better to off-load some of the immense burdens on the shoulders of the Core team. Did you actually read Michaels and Florians mails? Does not look like. I did. As far as I can tell, they both think it will be a tough one (due to complex and intertwined code) to pull off --especially from POV of speed. Other than that, I haven't seen anyone putting forward why it would be wrong. Have you? Have I missed something? Such an awful idea, isn't it? Yes, it is an awful idea. In what way do you think it may harm you or your beloved ones? :) Would it help you feel safer if we all stopped talking about these awful ideas? ;) Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser [OT]
On Fri, 02 Jul 2010 03:22:34 +0300 Adem listmem...@letterboxes.org wrote: As far as I can tell, they both think it will be a tough one (due to complex and intertwined code) to pull off --especially from POV of speed. Exactly and it sounds like they think the time and manpower is better spent on other things. much work + little gain = bad idea My point was that I wanted to read this thread on an FPC list. Other than that I am not really interested as long as the compiler stays fast (one of the main reasons to use it). Would it help you feel safer if we all stopped talking about these awful ideas? ;) No, but less smileys would help alot. This is my last mail in this thread. Enough spam here (my own mails included). I apologize in advance but I just could not resist. Yes, I know, I am an evil person. http://images.cheezburger.com/completestore/2010/1/29/129092786498235257.jpg R. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 08:12:52PM +0300, Adem wrote: You could have asked the fpc team or put it into one of the many free repositories. If you put something into lazarus examples then lazarus users expect a reason for downloading 650KB extra. If the above is the only reason, then you should remove it. +1 And the whole thread has nothing to do with lazarus at all. Actually, it does --quite a bit. It all started off with how we could come up with a code formatter (plus refactoring tools etc.) that uses a parser codebase that did not have to be written/maintained separately. It turned out that, in its current shape, FPC wasn't suitable for such use due to its monolithic nature, so we discussed --briefly-- what could be done about that (i.e. ways to refactor FPC code in such a way that downstream projects could re-use its modules). Besides that, many people (including several that worked on the FPC parser) have warned you that such a beast, while more elegant on paper, might actually be harder to maintain than two parsers. You chose to ignore that. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 02:27:22PM +0200, Hans-Peter Diettrich wrote: Aren't you against a e.g. .Net backend because it requires a completely different runtime :)? I think the same applies to M2 etc. as well? IMO we could separate the language itself (syntax) from the RTL (semantics). Hmm, what do you think RTL is in FPC context ? :-) Note that the M2 port is so small is because it can use Pascal compiled libraries. This means that dialect extensions etc to Pascal do not necessarily have to be implemented for M2, making it mostly a parser thing. .NET leaves the parser but requires a codegenerator change. So far so good. With regards to libraries I have some doubts though. Will e.g. most code in RTL/INC work for .NET without modification? (assuming we add a OS and arch dir for .NET) Moreover, if compromises are made, will they set well with the future .NET port users, and won't this turn into a debate for more native .NET functionality later ? ( Think Delphi.NET here) At least I can imagine the use of a different syntax at the procedure body (block, statement...) level, like already implemented for assembly language blocks. The requirement of *full* M2, Oberon or P# g compatibility IMO is very low, due to the few existing (public/commercial) projects in these languages. It's the libraries that I fear. Now that Delphi.NET is gone, even Indy is happy to remove all the TidBytes workarounds and allow pointers again. For exactly the same reason, I don't think .NET and native in one project will be a happy marriage. We also could make FPC an playground for language designers, which could implement their own languages in dedicated front-ends, as long as they use the existing FPC system library, tree nodes and other data structures, as far as these are hard-coded in the compiler, optimizer and code generators. If it is just a playground, fork a playground. I don't want to see FPC as it is carved up by continuous rewrites as a playground. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-07-02 07:33, Marco van de Voort wrote: Besides that, many people (including several that worked on the FPC parser) have warned you that such a beast, while more elegant on paper, might actually be harder to maintain than two parsers. You chose to ignore that. No. I did not ignore that. In fact, I did make a very bold note of it. But, it's not as if this is a 'suicide mission' --no one is going to commit suicide or intend to harm anyone in the process. Far from it. If indeed it turns out to be an impossible task, it's not as if we have staked our lives on it, we can abort the 'mission' g anytime we run out of steam. And, about having to maintain 2 parsers. Well.. the whole point is to *not* maintain any more than *one* parser --and, that includes current n parsers (I am not sure what the value of 'n' is). That is the target. If we get there? Great. Something good will have come out of it. If not? Well.. We'll have at least tried. So, could I now ask for some constructive --instead of discouraging-- criticism. Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 01:55:43PM +0200, Hans-Peter Diettrich wrote: the .Net thing mostly on the premise of 'write in the language you're most comfortable yet share with others you/they find useful'; Exactly, sold. It's marketing speech. You could use any language but only to a degree of maybe 95%. So everybody decided to use C#. Diabolic hint: why should Free Pascal users be bound to the Delphi OPL syntax, even with mode FPC extensions? When the use of another language or dialect could eliminate a couple of problems, like the never ending discussion about the proper formatting of the source code, or the export of any number of basically unit-specific declarations, required by the uses and interface/implementation model. The occurence of circular unit references IMO can be reduced a lot, when only the really exported declarations can be reduced by more fine-grained syntactical means (Oberon * attribute). What were so bad when the users, coming from e.g. Delphi, will find out that the Modula or Oberon language will fit their expectations much better than the crappy Delphi or derived FPC syntax? Because it will never happen. Just like the grand plans for the FPC dialect extensions. People coming from Delphi mostly care for Delphi, not language expermentalism. And, I mean this in the nicest possible way, and I don't like it myself either. Pascal shouldn't exist anymore and should have succeeded by one of Wirths later languages. But it hasn't happened, and it won't happen. Being basically a M2er, I learned this hard lesson already long ago, and it was one of the reasons why I switched to Pascal. And what about an Objective-C front-end, that will perfectly match the Sun requirements for iPad etc. applications? Till Apple changes the rules again, and changes it from language to our tools. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Thu, Jul 01, 2010 at 06:56:26PM +0200, Hans-Peter Diettrich wrote: FPC overcomes this problem with the .ppu files (I assume) No. That is an optimalization. The core feature is defining the unit concept, and clearing (reinitializing from cmdline params) preprocessor state C++ with mangled names, reflecting the precise attributes of every compiled item. which is why to my best knowledge, C++ doesn't solve this at all. Mangled names solve name clashes between same named symbols in different modules. They say nothing about this. But you are right that the preprocessor state _IS_ the problem. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Wed, 30 Jun 2010 12:04:38 +0200 Hans-Peter Diettrich drdiettri...@aol.com wrote: In examples/parser/no_cpu you find a new project, that can be used as a Pascal parser, or as a compiler template for a new CPU. Nice work. Why is this in the lazarus examples? Why not put it to the fpc sources? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Wed, Jun 30, 2010 at 2:44 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Why is this in the lazarus examples? Why not put it to the fpc sources? +1, as FPC sources branch or even trunk. thanks, dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
3) The compiler builds an parse tree for every procedure, but I found no way yet to make this tree accessible. It is no parse tree but some intermediate represensation. There should exist a method/procedure in the CPU specific code, that is called to create the binary code for a procedure, but I could not yet locate it. psub.pas: tcgprocinfo.generate_code, it is generic. 4) It's not yet known how the rest of a unit (declarations...) is represented internally. It is processed directly. In detail the last item [5] suggests an more flexible parser, that can do with the scanned tokens whatever is appropriate in the scope of a specific application. The general solution is a separation of the syntactical and semantical procedures in the parser. For fastest processing the semantical code can be made selectable just as for the CPU, by placing this code into a dedicated directory. I hope that this solution is acceptable to the FPC maintainers, and I'm willing to refactor all the parser units accordingly. I see two problems: - speed - reduced readability of the parser code because the code for handling something will be spread over different locations resulting also in reduced maintainability: just look at the code generator code, to support different architectures fpc the code generator is split at several levels making it very hard to get an overview on it and even more get into it. One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler, Is this really desired? The advantages of fpc are that it is written in its native language but its code generator is not sophisticated enough so it's imo not worth to add another front end. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hi! Wouldn't it be better to also include the fpc-devel list in this discussion (with CC)? Although (most of) the FPC-Devs might be reading the Lazarus list as well, you might find a better and perhaps more experienced audience there (it's nothing against the Lazarus developers, but not everyone likes to mess around in the compiler ^^). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Hi Diettrich, I see a complex work... very intelligent! I have only one comment below: On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler... No sense for me. IMHO, we chose the FPC much more by language than by the great compiler. If we have more languages, Pascal loses your glamour! Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-06-30 15:00, Marcos Douglas wrote: On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler... No sense for me. IMHO, we chose the FPC much more by language than by the great compiler. If we have more languages, Pascal loses your glamour! Why do you think Pascal would lose its glamor when (or if) FPC can compile other languages? I would have thought it would be just the opposite: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries etc which you could directly incorporate into your applications, or even do automatic source code translation (provided someone writes this capability); all these and more could add plenty more glamor to FPC --that is, if it needs that. I know these things are mostly pie-in-the-sky at the moment, but I don't understand why it would be undesirable to lay the groundwork for future expansion. Is this a new form of racism? ;) [I couldn't help ending it with a troll g] Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Adem schrieb: On 2010-06-30 15:00, Marcos Douglas wrote: On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler... No sense for me. IMHO, we chose the FPC much more by language than by the great compiler. If we have more languages, Pascal loses your glamour! Why do you think Pascal would lose its glamor when (or if) FPC can compile other languages? ... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc. I would have thought it would be just the opposite: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries etc which you could directly incorporate into your applications, This can be done already using compilers supporting these languages or even do automatic source code translation -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On Wed, 30 Jun 2010, Florian Klämpfl wrote: Adem schrieb: On 2010-06-30 15:00, Marcos Douglas wrote: On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler... No sense for me. IMHO, we chose the FPC much more by language than by the great compiler. If we have more languages, Pascal loses your glamour! Why do you think Pascal would lose its glamor when (or if) FPC can compile other languages? ... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc. Exactly. We can barely cope as it is. If we compiled C as well, we'd get bug reports about glibc or whatever C library fails to compile. no thanks. And, frankly, the project is called Free Pascal for a simple reason: it is a *Pascal* compiler and a *Pascal* project. Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
On 2010-06-30 23:31, Florian Klämpfl wrote: Adem schrieb: Why do you think Pascal would lose its glamor when (or if) FPC can compile other languages? ... because it increases the maintainance work on fpc. Even with one front end only we are almost unable to keep the issue count under control. I'am pretty sure that more front ends will be rejected without more people working on bug fixing in fpc. My assumption was this: Anyone who's going to add such capabilities would do it in a way that he/she/they would make sure there's enough of momentum/community to undertake not only the maintenance of their own (different lang compilation or whatever) contribution, but also help with relevant issue count in FPC. IOW, this sort of thing should be a precondition to such contributions. Keeping the door ajar (or, at least, not closed) for this sort of thing would be --IMHO-- a good thing as it is likely to bring on (more) commercial (and, hence/hopefully more stable) interest to the FPC flora and fauna. Frankly, I am not terribly fixated on getting 'commercial interest', but I am old enough to know that 'love' alone isn't always enough to guarantee continuity. I would have thought it would be just the opposite: If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries etc which you could directly incorporate into your applications, This can be done already using compilers supporting these languages True. But, wouln't it be nice if people could use, say, libc (as recently mentioned in FPC list) in FPC too? Cheers, Adem -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
If you could compile, say, Modula (or C/C++) with FPC, you would have direct access to a huge time-tested resource of libraries etc which you could directly incorporate into your applications, This can be done already using compilers supporting these languages True. But, wouln't it be nice if people could use, say, libc (as recently mentioned in FPC list) in FPC too? I don't see the point? This is already possible? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Florian Klämpfl schrieb: 3) The compiler builds an parse tree for every procedure, but I found no way yet to make this tree accessible. It is no parse tree but some intermediate represensation. Yes, it's an AST, but I didn't want to put too much into the advertisement ;-) There should exist a method/procedure in the CPU specific code, that is called to create the binary code for a procedure, but I could not yet locate it. psub.pas: tcgprocinfo.generate_code, it is generic. I couldn't find out how the code generator is involved. Most methods are non-virtual... 4) It's not yet known how the rest of a unit (declarations...) is represented internally. It is processed directly. This means that the parser must be patched. In detail the last item [5] suggests an more flexible parser, that can do with the scanned tokens whatever is appropriate in the scope of a specific application. The general solution is a separation of the syntactical and semantical procedures in the parser. For fastest processing the semantical code can be made selectable just as for the CPU, by placing this code into a dedicated directory. I hope that this solution is acceptable to the FPC maintainers, and I'm willing to refactor all the parser units accordingly. I see two problems: - speed Not really. The semantic actions are so complex, that another call (to them) should not matter. - reduced readability of the parser code because the code for handling something will be spread over different locations resulting also in reduced maintainability: just look at the code generator code, to support different architectures fpc the code generator is split at several levels making it very hard to get an overview on it and even more get into it. Yes and no. A good separation will help to clarify much. One big advantage of the separation into syntactical and semantical parts is the chance for adding further languages to the compiler, Is this really desired? The advantages of fpc are that it is written in its native language but its code generator is not sophisticated enough so it's imo not worth to add another front end. We'll see ;-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parser
Mattias Gaertner schrieb: Why is this in the lazarus examples? Why not put it to the fpc sources? Because I can commit only to the Lazarus examples :-( Now I have to adopt the sample to the FPC trunk version, which is somewhat incompatible with 2.4. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus