Re: [fpc-devel] Alternative parsers
Op 2010-10-20 02:04, Hans-Peter Diettrich het geskryf: > to that list. I hope that such a fork can be kept in sync with the SVN > trunk, at least for the compiler back-ends, somehow - Graeme? Yes, an easy task. Add a new remote repository (current github mirror of FPC's SubVersion repository). Then cherry-pick/merge whatever you want from there into your repository. A straight forward task. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 18:38, Alexander Klenin het geskryf: > > Ok, I went ahead and have taken look at the code. > I assume you speak about TFPHashList vs TFPCustomHashTable. > The classes are not really comparable, because they use quite > different internal data structures. I did the same thing last night and came to the same conclusion. Those two classes cannot be compared as-is. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 18:22, Michael Van Canneyt het geskryf: > > Sorry, I was talking about classes. I don't use objects from TP; > I consider them deprecated. I still use objects instead of classes in certain parts of my code. They definitely have their uses. They're like records with methods (which by the way is a recent addition to Delphi - though objects does that already, so not sure why they extended the record structure for that). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 20.10.2010 01:09, schrieb Hans-Peter Diettrich: It sounds like you give us little credit. Sorry for that and thanks you for your work. But, by the same token, don't you think that you also give a little credit to Hans' work? Maybe his reasons are also good? As I explained in another mail, I think he tries too much too soon. I only tried to contribute the best of my education and knowledge, resulting from decades of code analysis and redesign. I admit that my coding style, that evolved in that time, is partially incompatible with certain "standards" - but only for good reasons. But as long as FPC is in the hands of the current team (and I hope that this will last for a long time ^^) we have to obey their coding style if we want our code in the compiler. I'm not a fan of the style either, but I adhere to it. Look at it as a sign of good will: you show that you really mean it by acknowledging the standards and then you might be treated better. :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Michael Van Canneyt schrieb: Sorry, I was talking about classes. I don't use objects from TP; I consider them deprecated. I use Object in the semantic stuff, just to avoid try-finally blocks. As long as Class objects must reside on the heap, Object still has advantages. Besides my personal opinion, the compiler already uses classes for some other things, and it's not very desirable to mix the two concepts. It sounds like you give us little credit. Sorry for that and thanks you for your work. But, by the same token, don't you think that you also give a little credit to Hans' work? Maybe his reasons are also good? As I explained in another mail, I think he tries too much too soon. I only tried to contribute the best of my education and knowledge, resulting from decades of code analysis and redesign. I admit that my coding style, that evolved in that time, is partially incompatible with certain "standards" - but only for good reasons. First do some small and desired things, to build up credibility. Check the bugtracker for things to do. You'll be invited on the core team by itself if you do a good job. Then take on the big tasks. That's a very dangerous proposition. I've encountered several projects where the maintainers could not fix certain bugs, and left these to others. When such a fix required restructuring of the code, it typically is rejected, because the maintainers don't understand it. A plenty of such bugs will typically disappear as a sideeffect of a general refactoring. Please note that I do *not* say that FPC already is in such a state... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Alexander Klenin schrieb: Actually, I certainly think (and hope) that DoDi's goal is _not_ a "C frontend", but to find _any_ possible venue to upgrade the code structure of FPC code. Well - both ;-) I would like to see my C parser working as an FPC front-end, instead of producing intermediate Pascal code (in the SF ToPas project). Such a front-end would allow to compare both code compilation and execution speed of FPC with existing C compilers, and I wouldn't be surprised if FPC shows up quite good in such a comparison. But that's only a hobby task, a proof of concept, and a chance to learn (and document) more about the compiler internals. I admire his persistence and productivity and my suggestion for a fork was not a trolling attempt (although it did start a flame, for which I am sorry). To get going, a fork needs some momentum and dedication and maybe he is the person able to pull it off. I'll start an according discussion in fpc-other, as soon as I get access to that list. I hope that such a fork can be kept in sync with the SVN trunk, at least for the compiler back-ends, somehow - Graeme? BTW, the "Overview of all lists.freepascal.org mailing lists" link seems to be broken, in all web pages? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Florian Klaempfl schrieb: Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): First Pascal-like languages and later C. FPC's main developer doesn't see a need for it. Indeed. Please tell what a C front end to FPC helps? FPC has no advantage over existing C compilers except being a pascal compiler ;). Do you think any C developer will work on a C compiler written in pascal? It won't make interfacing C headers easier as explained multiple times. So what do you expect from a C front end? E.g. the elimination of the translation of C headers or entire libraries (bzip...), quick evaluation of sample code (usually in and for C libraries or APIs)... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Florian Klämpfl schrieb: Well, DoDi is not willing to fix the flaws of his patches so they were rejected, see e.g.: http://bugs.freepascal.org/view.php?id=17584 You're kidding. The same result in a branch, with intermediate steps, would be rejected as well (NoGlobal branch). Why break one patch into smaller patches, that do not compile until all have been applied? And now I shall apply patches which turn the compiler upside down and then I shall trust that he fixes the bugs the code potentially introduces? Show the bugs and give me a chance... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Florian Klaempfl schrieb: and refactorings are not welcome. Who says this? Usefull refactoring *is* welcome. Umm, please specify what you understand by "refactoring". Something that does not move code around, or into new subroutines? Something that can be achieved in a sequence of only small local changes? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Martin Schreiber schrieb: This is a typical showcase for the premature micro-optimization -- for a few percentages of speed in the short term, you pay in reduced code maintainability, which precludes high-level optimizations in the long term. IIRC one of the goals are to enable muti threaded compiling. According to the preceding discussion. I have a horror from that scenario. It is difficult enough to produce a stable single threaded compiler. Well, it's a matter of models, patterns and structure. Something not found in the current compiler sources :-( I can't believe that it is possible to make a good multi core aware compiler without a team of highest skilled fulltime developers working several years... I could have done it alone, in about half a year. Once the evitable global variables have been removed, most of the job is done. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tuesday 19 October 2010 14:44:38 Florian Klaempfl wrote: > Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): > > First Pascal-like languages and later C. > > FPC's main developer doesn't see a need for it. > > Indeed. Please tell what a C front end to FPC helps? FPC has no > advantage over existing C compilers except being a pascal compiler ;). > Do you think any C developer will work on a C compiler written in > pascal? It won't make interfacing C headers easier as explained multiple > times. So what do you expect from a C front end? C may be difficult but there could be more pascal-like languages like Modula and ADA. My idea is that they can use the same libraries and can work together even inside one project. I don't know how far the compiler modes in FPC can take you for supporting other languages. It would be a similar concept that .NET and Java VM's are for typed, garbage collected languages and Parrot is for dynamic languages. Every language under those VMs can call the same libraries. The FPC supported languages would do the same (use common libs and variables defined in those libs). IIRC there is no such thing now for compiled languages. GCC supports many languages but they can't interact transparently. Some clumsy glue code is needed for that. C language support for FPC frontend would be possible but compiled (binary) C libraries could not be used and existing C source not used directly. Difference in default calling convention is solvable I guess. Anyway I don't see this as a very important feature neither. Multi-language support was mentioned earlier in DoDi's mails as part of the plan, after refactoring. That's why I wrote about it. The fact still is that his plan is fundamentally different from your plan. I don't really have an opinion about if DoDi's patches are good or bad. Maybe you did the right thing by not letting such big changes into FPC trunk. However, I am curious to see what he can achieve. He clearly likes to experiment and refactor a lot, and a fork is the only way to do that. The options are about like: 1. He will send some more mails and big refactoring patches which are again rejected, probably for good reason. After lots of frustration he gives up and the energy is vasted. Nobody is happy. 2. He will freely modify and refactor the code in a separate branch or fork. When there is a stable compiler available, features are compared and a healthy competition is born (hopefully). Everybody is happy. I am just saying that from those options I prefer to see number 2. Regards, Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.4.2 RC1 available
Marco van de Voort wrote: Hello, We have placed the first release-candidate of the Free Pascal Compiler version 2.4.2 on our ftp-servers. You can help improve the upcoming 2.4.2 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_2.4.2 I've not had time to do the tests "by the book" but I can report that RC1 builds using 2.4.0 on armel, PPC, SPARC and x86 (all Debian "Lenny"), and then can build itself. It's able to build Lazarus on SPARC, I've not checked the other platforms yet. The only niggle I've got is that when I tried to build using 2.2 it went part way through and then barfed because of an "out" parameter. Could the compiler version be checked right at the start of the build? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] unit tests for RTL & FCL + 2 patches
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote: Hi, Florian mentioned that the compiler is well tested, and I can see there are many .pp files in the src/tests/ hierarchy. Where would I look for the RTL and FCL unit tests? Is it the code in /tests/test/units/fpcunit/? If so, is that all of them, or is there another directory (eg: maybe for FCL) somewhere? Also attached are two patches for the /tests/test/units/fpcunit/ project. patch 001: Allows FPC 2.5.1 to actually compile the test suite patch 002: Changes lazarus project file options - session information is stored in separate .lps file - a unit output director to support multiple targets - a defined output filename that is easily accessible I applied the patch. I don't know how you managed to compile the code, but I fixed that as well. The test cases were to test the rewrite of the classes/sysutils units, they were not intended for end-user tests. In each case the project compiles now. (and 3 of 204 tests fail. I didn't check whether that's correct or not) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 16:42, schrieb Alexander Klenin: > On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote: >> On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote: >> >>> 1) I have serious suspicions that compile time on modern processors >>> is dominated by linking and I/O. >>> At least this is certainly true for FPC on Windows case. >> >> Do you remember the factor 10 compiling speed advangage of Delphi7 compared >> with FPC 2.4? >> http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html > > I do. I also remember that one of the goals of DoDi's previous set of > refactorings > was to address that discrepancy. Well, DoDi is not willing to fix the flaws of his patches so they were rejected, see e.g.: http://bugs.freepascal.org/view.php?id=17584 And now I shall apply patches which turn the compiler upside down and then I shall trust that he fixes the bugs the code potentially introduces? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
In our previous episode, Sergei Gorelkin said: > > > > Average string length 45 characters: > > ShortString: 12.0 s > > AnsiString: 3.2 s > > > > I agree that the first case is more relevant for the compiler, > > but still you can see that ShortStrings are clearly not always faster. > > > I believe it's not ShortStrings per se to blame, but storing them in a large > single memory block as > it is being done in TFPHashList. Adding a lot of keys will cause many > reallocations. Large size of > the block forces memory manager to use variable-size pool, which is less > efficient than using > fixed-size blocks in case of small chunks. I actually thought that too, and did a benchmark (cclasses')hashlist against an own implementation based on array of array (to reduce that by a magnitude) a few years back Mine was slower. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Michael Van Canneyt пишет: I believe it's not ShortStrings per se to blame, but storing them in a large single memory block as it is being done in TFPHashList. Adding a lot of keys will cause many reallocations. Large size of the block forces memory manager to use variable-size pool, which is less efficient than using fixed-size blocks in case of small chunks. Strange. The whole idea of the implementation was to improve memory efficiency. And at the time, it was definitely and consistently faster. If Alexander sends me his code, I will check, and then I should ask Peter Vreman, who wrote the code. (if he'll still answer). It is indeed very efficient regarding number of bytes occupied. Storing all strings in one block has no storage overhead at all. Stressing this implementation with huge amount of Add's won't show the best speed, but it has little common with the intended usage scenario, which is "single Add, multiple Find's". Also in the compiler, the average number of items in a single TFPHashList is not huge. It can grow huge in units like Windows (many procedures in one namespace), but these are more like extreme cases. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, 19 Oct 2010, Sergei Gorelkin wrote: Alexander Klenin пишет: Ok, I went ahead and have taken look at the code. I assume you speak about TFPHashList vs TFPCustomHashTable. The classes are not really comparable, because they use quite different internal data structures. So instead I converted TFPHashList list to use ansistrings. Benchmarking included 3*10^6 calls to Add and Find methods with the arguments of various lengths. Average string length 5 characters: ShortString: 1.15 s AnsiString: 1.56 s Average string length 45 characters: ShortString: 12.0 s AnsiString: 3.2 s I agree that the first case is more relevant for the compiler, but still you can see that ShortStrings are clearly not always faster. I believe it's not ShortStrings per se to blame, but storing them in a large single memory block as it is being done in TFPHashList. Adding a lot of keys will cause many reallocations. Large size of the block forces memory manager to use variable-size pool, which is less efficient than using fixed-size blocks in case of small chunks. Strange. The whole idea of the implementation was to improve memory efficiency. And at the time, it was definitely and consistently faster. If Alexander sends me his code, I will check, and then I should ask Peter Vreman, who wrote the code. (if he'll still answer). Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, 20 Oct 2010, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt wrote: If you need more convincing: the contnrs unit contains 2 hash classes. one based on ansistrings, one with pchars and shortstrings. The pchar version is easily 20% faster. It comes from the compiler code and was written specially by Peter Vreman. Try and improve that class with ansistrings. If you succeed, only then we can start making a case for using them in the compiler. Ok, I went ahead and have taken look at the code. I assume you speak about TFPHashList vs TFPCustomHashTable. The classes are not really comparable, because they use quite different internal data structures. But they perform the same function; hash on string with an associated data structure. So instead I converted TFPHashList list to use ansistrings. That was the point :-) Benchmarking included 3*10^6 calls to Add and Find methods with the arguments of various lengths. Average string length 5 characters: ShortString: 1.15 s AnsiString: 1.56 s Average string length 45 characters: ShortString: 12.0 s AnsiString: 3.2 s I agree that the first case is more relevant for the compiler, but still you can see that ShortStrings are clearly not always faster. I'm always open for benchmark tests. Can you please send me your test and the implementation ? I'd like to see when the balance shifts. Recently I had an implementation for TStringList.Sort which the author claimed was 25-45 times (!) faster than the quicksort. I've never been able to reproduce his claim - rather the opposite. Not even with Delphi (which, strangely enough, performed worse than FPC) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Thanks Helmut for your encouraging message. I enjoy lurking and learning by reading these extensive threads. Back in March 2010 there was a similar thread about Lazarus development and in the end several people posted their success stories which are now here: http://www.lazarussupport.com/lazarus/Testimonials I'm glad you came along to help us look at the "big picture" with your FPC success story! :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 04:54, Sergei Gorelkin wrote: > Alexander Klenin пишет: >> Benchmarking included 3*10^6 calls to Add and Find methods >> with the arguments of various lengths. >> >> Average string length 5 characters: >> ShortString: 1.15 s >> AnsiString: 1.56 s >> >> Average string length 45 characters: >> ShortString: 12.0 s >> AnsiString: 3.2 s >> >> I agree that the first case is more relevant for the compiler, >> but still you can see that ShortStrings are clearly not always faster. >> > I believe it's not ShortStrings per se to blame, but storing them in a large > single memory block as it is being done in TFPHashList. Adding a lot of keys > will cause many reallocations. Large size of the block forces memory manager > to use variable-size pool, which is less efficient than using fixed-size > blocks in case of small chunks. Very possible. I have even managed to get a few OutOfMemory errors while testing ShortStrings version. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Alexander Klenin пишет: Ok, I went ahead and have taken look at the code. I assume you speak about TFPHashList vs TFPCustomHashTable. The classes are not really comparable, because they use quite different internal data structures. So instead I converted TFPHashList list to use ansistrings. Benchmarking included 3*10^6 calls to Add and Find methods with the arguments of various lengths. Average string length 5 characters: ShortString: 1.15 s AnsiString: 1.56 s Average string length 45 characters: ShortString: 12.0 s AnsiString: 3.2 s I agree that the first case is more relevant for the compiler, but still you can see that ShortStrings are clearly not always faster. I believe it's not ShortStrings per se to blame, but storing them in a large single memory block as it is being done in TFPHashList. Adding a lot of keys will cause many reallocations. Large size of the block forces memory manager to use variable-size pool, which is less efficient than using fixed-size blocks in case of small chunks. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.10 15:40, schrieb Alexander Klenin: I fully understand that the reason for degrading the code structure was efficiency. I just doubt that it was/is a good trade-off. Dear FPC Team, After finishing porting the bullet physics library from C++ to FPC in the last 2 months (http://bulletphysics.org/wordpress/). I had the chance to compare Xcode, MS Visual C++ and MinGW GCC regarding compilation speed. FPC is about 3-20 times(!) faster then those (modern) compilers on pure compilation speed. That is a fact at least for me and my employees. I had to debug the library on multiple archs with multipe tools side by side, step by step to find my porting errors - and I had to add lots of debug code in the original code, so I was able to "feel" and measure the turn around times. I am happy that you all have a deep understanding of writing fast and memory efficient code, because I can use the compiler as spell checker. I am happy that I can use FPC to do 10 GBit Line speed network analysis and real time protocol identification under FreeBSD, with a small team of developers because they can read and debug pascal code fast and have superior turn around times. I am happy that I can also use "degraded" datastructures in conjunctions with lock free algorithms and that I have the choice to use them if I understand them. Thank you all for the exceptional stability of the FPC trunk on Windows, FreeBSD (32) and OSX because we use the latest trunk version to do our development (generics). Thank you that my company was/is able to write a cross platform OpenGL Engine for data visualization which now works with OpenGL 4, OpenCL and optimized Shadercode, completly driven by FPC. (Shadercode and OpenCL code is in C) Proving that FPC is able to feature recent technology projects. Thank you for your long time support of language features - using objects (TP objects) as generics has proven to be sucessfully fast for vector, matrix,quaternion and memory management operations while maintaining a FPU needed layout easily. Thank you all for your time reading, thinking, answering often stupid/lazy mails and bug reports from me. Please continue your good judgement about trunk codebase improvements. helmut ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 2010-10-19 19:38, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt wrote: If you need more convincing: the contnrs unit contains 2 hash classes. one based on ansistrings, one with pchars and shortstrings. The pchar version is easily 20% faster. It comes from the compiler code and was written specially by Peter Vreman. Try and improve that class with ansistrings. If you succeed, only then we can start making a case for using them in the compiler. Ok, I went ahead and have taken look at the code. I assume you speak about TFPHashList vs TFPCustomHashTable. The classes are not really comparable, because they use quite different internal data structures. So instead I converted TFPHashList list to use ansistrings. Benchmarking included 3*10^6 calls to Add and Find methods with the arguments of various lengths. Average string length 5 characters: ShortString: 1.15 s AnsiString: 1.56 s Average string length 45 characters: ShortString: 12.0 s AnsiString: 3.2 s I agree that the first case is more relevant for the compiler, but still you can see that ShortStrings are clearly not always faster Just curious: Would you, by any chance, have a figure for this: In a (self) compile operation, how many times are either of these these routines called? -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt wrote: > If you need more convincing: the contnrs unit contains 2 hash classes. > one based on ansistrings, one with pchars and shortstrings. The pchar > version is easily 20% faster. It comes from the compiler code and was > written specially by Peter Vreman. > > Try and improve that class with ansistrings. If you succeed, only then we > can start making a case for using them in the compiler. Ok, I went ahead and have taken look at the code. I assume you speak about TFPHashList vs TFPCustomHashTable. The classes are not really comparable, because they use quite different internal data structures. So instead I converted TFPHashList list to use ansistrings. Benchmarking included 3*10^6 calls to Add and Find methods with the arguments of various lengths. Average string length 5 characters: ShortString: 1.15 s AnsiString: 1.56 s Average string length 45 characters: ShortString: 12.0 s AnsiString: 3.2 s I agree that the first case is more relevant for the compiler, but still you can see that ShortStrings are clearly not always faster. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, 20 Oct 2010, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt wrote: What can be optimized, must be optimized. Sorry, but does not this sound slightly exaggerated? :-) 2) I may believe that records are faster then classes, but if they are faster then objects, then this is a compiler problem, since there should be literally no difference except the VMT pointer memory overhead. Actual usage of virtual calls may cause a slowdown, but it also may cause a speedup if it replaces a 'case' statement, which is usually so. The VMT is not the point. Objects are zeroed out. You are wrong. The code below outputs random garbage, not zeroes. Sorry, I was talking about classes. I don't use objects from TP; I consider them deprecated. Besides my personal opinion, the compiler already uses classes for some other things, and it's not very desirable to mix the two concepts. It sounds like you give us little credit. Sorry for that and thanks you for your work. But, by the same token, don't you think that you also give a little credit to Hans' work? Maybe his reasons are also good? As I explained in another mail, I think he tries too much too soon. First do some small and desired things, to build up credibility. Check the bugtracker for things to do. You'll be invited on the core team by itself if you do a good job. Then take on the big tasks. This is how everyone else made it on the FPC team. Not by wanting do reorganize everything all at once. That is just not realistic, simply from a human point of view. If I would attempt to do what he did, I would also get into serious trouble, even though I'm one of the oldest members on the team. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tuesday, 19. October 2010 17.17:04 Graeme Geldenhuys wrote: > Op 2010-10-19 17:06, Martin Schreiber het geskryf: > > core aware compiler without a team of highest skilled fulltime developers > > working several years... > > Why do you think we are not that already? :-) > Aha! Maybe that's the reason for the lower performance than Delphi . ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt wrote: > What can be optimized, must be optimized. Sorry, but does not this sound slightly exaggerated? :-) >> 2) I may believe that records are faster then classes, >> but if they are faster then objects, then this is a compiler problem, >> since there should be literally no difference except the VMT pointer >> memory overhead. Actual usage of virtual calls may cause a slowdown, >> but it also may cause a speedup if it replaces a 'case' statement, >> which is usually so. > > The VMT is not the point. > Objects are zeroed out. You are wrong. The code below outputs random garbage, not zeroes. type T1 = object x, y: Integer; end; procedure P; var obj: T1; begin Writeln(obj.x, obj.y); end; begin P; end. > It sounds like you give us little credit. Sorry for that and thanks you for your work. But, by the same token, don't you think that you also give a little credit to Hans' work? Maybe his reasons are also good? > Most things happen for a reason; You just don't know the reason. I fully understand that the reason for degrading the code structure was efficiency. I just doubt that it was/is a good trade-off. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19/10/10 15:42, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote: On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote: 1) I have serious suspicions that compile time on modern processors is dominated by linking and I/O. At least this is certainly true for FPC on Windows case. Do you remember the factor 10 compiling speed advangage of Delphi7 compared with FPC 2.4? http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html I do. I also remember that one of the goals of DoDi's previous set of refactorings was to address that discrepancy. Really? I didn't see any benchmarks? And since they were rejected, FPC will continue to be slower than Delphi. Cum hoc ergo propter hoc. This is a typical showcase for the premature micro-optimization -- for a few percentages of speed in the short term, you pay in reduced code maintainability, which precludes high-level optimizations in the long term. A very small group of unpaid people maintaining a compiler over several architectures and operating systems? Seems like the fpc team is doing quite well. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 17:06, Martin Schreiber het geskryf: > core aware compiler without a team of highest skilled fulltime developers > working several years... Why do you think we are not that already? :-) [...I have learned from past experience that assuming something is very bad, especially if your only medium of communication has been emails...] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tuesday, 19. October 2010 16.42:19 Alexander Klenin wrote: > > Do you remember the factor 10 compiling speed advangage of Delphi7 > > compared with FPC 2.4? > > http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html > > I do. I also remember that one of the goals of DoDi's previous set of > refactorings > was to address that discrepancy. > And since they were rejected, FPC will continue to be slower than Delphi. > This is a typical showcase for the premature micro-optimization -- > for a few percentages of speed in the short term, > you pay in reduced code maintainability, > which precludes high-level optimizations in the long term. IIRC one of the goals are to enable muti threaded compiling. I have a horror from that scenario. It is difficult enough to produce a stable single threaded compiler. I can't believe that it is possible to make a good multi core aware compiler without a team of highest skilled fulltime developers working several years... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, 20 Oct 2010, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt wrote: 2) I'd say that at least half of his mistakes could be avoided by better code structure of FPC -- he was really uncomfortable using strange records and pchars instead of normal objects and strings. That has nothing to do with code structure, but with efficiency. While it may be true that records/pchars increase efficiency, they also certainly _are_ an essential part of the code structure. And the price paid for whatever efficiency gains they bring is reduced maintainability of code. pchar and records are much faster than objects and strings. This has been established empirically a long time ago by the compiler developers. Speed of the compiler is an important factor, so records and pchars are used. 1) I have serious suspicions that compile time on modern processors is dominated by linking and I/O. At least this is certainly true for FPC on Windows case. But not on Linux. Even so, it doesn't matter. If linking is slow, it doesn't mean the rest should also be slow. What can be optimized, must be optimized. 2) I may believe that records are faster then classes, but if they are faster then objects, then this is a compiler problem, since there should be literally no difference except the VMT pointer memory overhead. Actual usage of virtual calls may cause a slowdown, but it also may cause a speedup if it replaces a 'case' statement, which is usually so. The VMT is not the point. Objects are zeroed out. Records are not. There have been various pleas for a faster fillchar() on this mailing list, and they are not without reason. 3) As for strings, I can see that the overhead may be substantial, but that does not mean one have to roll back all the way down to raw pointers. Atomic strings with memory pools, for example, might be a good alternative. There was no 'roll back'. Originally, there were no ansistrings, only shortstrings, so the compiler was written with pchars. Ansistrings have serious overhead associated with them, so when they appeared, they were not used. If you need more convincing: the contnrs unit contains 2 hash classes. one based on ansistrings, one with pchars and shortstrings. The pchar version is easily 20% faster. It comes from the compiler code and was written specially by Peter Vreman. Try and improve that class with ansistrings. If you succeed, only then we can start making a case for using them in the compiler. So with your last argument you actually strengthen Florians case. I am not so sure, it looks a lot like a premature optimization to me. Not 'premature'. It was done after heavy profiling of the compiler, and the speed improvements were very noticeable. It sounds like you give us little credit. Most things happen for a reason; You just don't know the reason. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 14:38, schrieb Alexander Klenin: > On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl > wrote: >> Am 19.10.2010 13:54, schrieb Alexander Klenin: >>> from fixing case and reformatting of Math unit >> >> This does not help anybody ;) > See, you have already rejected it ;-) > The initial motivation was that current unit have lower-case > procedure names, which is not Delphi-compatible > and messes up code completion. Ok, this is a point. I'am pretty sure that a patch which fixes casing of exported symbols will be accepted and I'am the first one who will apply it. However, this is no argument to do reformatting. Casing yes, but reformatting? > >>> to finishing/extending Paul's work on for..in loop. >> Does it still miss stuff? Actually, I never used it :) > > It does not "miss" stuff, but could be extended. > I meant http://wiki.freepascal.org/for-in_loop#Proposed_extensions > >> So you looked yourself into the refactored code so you can judge it as >> good? Did you send an email with your comment why it is good? > > Actually, I tried to, although svn made it extremely difficult > and I am not aware of git/hg mirror of branches. Ask Graeme. But I felt reviewing with tortoisesvn pretty easy while tortoisegit even doesn't allow me to diff pulled changes quickly in the pull window. > The changes are very promising (although IFDEF's are a mess, > but as I understand they are planned for removal). > I did not test and have not enough understanding of FPC internals > to spot any breakage by code inspection, but the readability > and modularization improvements are quite obvious to me. > >> Where did you comment on the critism I made? > I have really restrained myself from commenting on them > because I it is hard to do in a polite manner. Politeness is not important as long as the arguments are reasonable ;) > Since you insist, I will try: > >> - people knowing the old code for 15 years having to dig into new code > Do you even understand how backwards this sounds? > Using the outdatedness of code as an excuse not to refactor it > is usually reserved for big corporations, not modern open-source projects :-) Who says the code is outdated? I said only that people doing the work on FPC have to dig into new code for no gain. And at least I'am not willing to fix such new code if I see no gain. > >> - slower > Or maybe faster? Did you benchmark it? > Of did you see a specific location of code which will cause slowdown? Dislocation of code causes less efficient cache usage. Added calls, added class instance accesses. > >> - code spread over multiple locations > Which is called modularization aka OO, and is IMO the main point of the branch Only if it serves a purpose. There is no use on modularization or OO for itself. In German you call something like this over-engineered. > >> - lost svn blame history > use git I cannot see how git solves this for code being moved around and being reindented, not to mention upper/lower casing changes. > >> - last but not least, you coding style does not follow the compiler code > style > Which may be trivially fixed (btw, compiler code style is really ... > um... exotic). > This is out of discussion yet, the compiler uses its coding style and it should be consistent as far as possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Issue 17664 and FPC 2.4.2 RC
Hi,
i know that in a Release Candidate stage is difficult or not appropriate
to make big changes, but the http://bugs.freepascal.org/view.php?id=17664
is a trivial one.
"In the initialization section of the ibase60.inc, is missing the const
'fbembedlib' of the library name for the default Firebird Embedded name
'fbembed.dll' or 'libfbembed.'+sharedsuffix .
>initialization
> IBaseLibrary := LibraryHandler('Interbase', [gdslib,fbclib], @ibsymbols,
>length(ibsymbols));
witch results to never find the fbembed library, even if exists the
'fbembed.dll' in the path."
Is it possible to fix it for the fpc 2.4.2 Release ?
--
Dimitrios Chr. Ioannidis
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote: > On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote: > >> 1) I have serious suspicions that compile time on modern processors >> is dominated by linking and I/O. >> At least this is certainly true for FPC on Windows case. > > Do you remember the factor 10 compiling speed advangage of Delphi7 compared > with FPC 2.4? > http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html I do. I also remember that one of the goals of DoDi's previous set of refactorings was to address that discrepancy. And since they were rejected, FPC will continue to be slower than Delphi. This is a typical showcase for the premature micro-optimization -- for a few percentages of speed in the short term, you pay in reduced code maintainability, which precludes high-level optimizations in the long term. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote: > 1) I have serious suspicions that compile time on modern processors > is dominated by linking and I/O. > At least this is certainly true for FPC on Windows case. Do you remember the factor 10 compiling speed advangage of Delphi7 compared with FPC 2.4? http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 14:02, schrieb Florian Klaempfl: to finishing/extending Paul's work on for..in loop. Does it still miss stuff? Actually, I never used it :) Perhaps Alexander is talking about the points mentioned here: http://wiki.freepascal.org/for-in_loop#Proposed_extensions I am currently starting to use them myself (with a 2.4.3 at work and maybe a 2.4.2 at home :D ). For standard tasks they are indeed a very useful kind of sugar :P Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl wrote: > Am 19.10.2010 12:07, schrieb Alexander Klenin: >> I personally wanted to do some things for FPC (although Unicode was >> not one of them), >> but hesitated, because the current code is too messy and fragile to touch, > > In which areas? I have had plans/ideas in many areas, from fixing case and reformatting of Math unit to finishing/extending Paul's work on for..in loop. >> and refactorings are not welcome. > > Who says this? Usefull refactoring *is* welcome. But here I see, again and again, that good refactorings are rejected as "not useful". Well, maybe I should try myself but the experience of others is definitely discouraging. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 13:54, schrieb Alexander Klenin: > On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl > wrote: >> Am 19.10.2010 12:07, schrieb Alexander Klenin: >>> I personally wanted to do some things for FPC (although Unicode was >>> not one of them), >>> but hesitated, because the current code is too messy and fragile to touch, >> >> In which areas? > > I have had plans/ideas in many areas, > from fixing case and reformatting of Math unit This does not help anybody ;) > to finishing/extending Paul's work on for..in loop. Does it still miss stuff? Actually, I never used it :) > >>> and refactorings are not welcome. >> >> Who says this? Usefull refactoring *is* welcome. > > But here I see, again and again, that good refactorings are > rejected as "not useful". So you looked yourself into the refactored code so you can judge it as good? Did you send an email with your comment why it is good? Where did you comment on the critism I made? > Well, maybe I should try myself > but the experience of others is definitely discouraging. > Who is others? I remember very few *compiler* patches we rejected. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Alexander Klenin wrote: On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt wrote: 2) I'd say that at least half of his mistakes could be avoided by better code structure of FPC -- he was really uncomfortable using strange records and pchars instead of normal objects and strings. That has nothing to do with code structure, but with efficiency. This is hilarious. I could just as well say -- he was really uncomfortable using strange objects and strings instead of normal records and pchars. Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tuesday, 19. October 2010 15.42:30 Alexander Klenin wrote: > 2) I'd say that at least half of his mistakes could be avoided > by better code structure of FPC -- he was really uncomfortable > using strange records and pchars instead of normal objects and strings. Hmm, strange records and pchars are often necessary for good performance. A professional programmer or a hobby programmer with the needed skills to do compiler development on the necessary level has no problems to read and work with such code. I did not much reading in the FPC sources up to now but sometimes I saw possibilities to improve performace by using a little bit more pchars and strange records. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt wrote: >> 2) I'd say that at least half of his mistakes could be avoided >> by better code structure of FPC -- he was really uncomfortable >> using strange records and pchars instead of normal objects and strings. > > That has nothing to do with code structure, but with efficiency. While it may be true that records/pchars increase efficiency, they also certainly _are_ an essential part of the code structure. And the price paid for whatever efficiency gains they bring is reduced maintainability of code. > pchar and records are much faster than objects and strings. > This has been established empirically a long time ago by the compiler > developers. Speed of the compiler is an important factor, so records and > pchars are used. 1) I have serious suspicions that compile time on modern processors is dominated by linking and I/O. At least this is certainly true for FPC on Windows case. 2) I may believe that records are faster then classes, but if they are faster then objects, then this is a compiler problem, since there should be literally no difference except the VMT pointer memory overhead. Actual usage of virtual calls may cause a slowdown, but it also may cause a speedup if it replaces a 'case' statement, which is usually so. 3) As for strings, I can see that the overhead may be substantial, but that does not mean one have to roll back all the way down to raw pointers. Atomic strings with memory pools, for example, might be a good alternative. > So with your last argument you actually strengthen Florians case. I am not so sure, it looks a lot like a premature optimization to me. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl wrote: > Am 19.10.2010 14:02, schrieb Alexander Klenin: > The topic of this thread and the patch was/is alternative parsers. As > you worked on the case of string stuff (or your student) you might also > know that the fpc parser is written straight forward and anybody knowing > the dragon books might be able to work on it and far from being fragile. Oh, do not remind me of that. Do you know that said student had quit working on FPC because he found the code base to be a mess? (And which is sadder to me, he also took a different adviser for his next year course work). I actually teach compiler construction at the university, and he correctly noted that compilers produced by some students at the end of the course are better structured than FPC. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 14:48, schrieb Alexander Klenin: > On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl > wrote: >> Am 19.10.2010 14:02, schrieb Alexander Klenin: >> The topic of this thread and the patch was/is alternative parsers. As >> you worked on the case of string stuff (or your student) you might also >> know that the fpc parser is written straight forward and anybody knowing >> the dragon books might be able to work on it and far from being fragile. > > Oh, do not remind me of that. Do you know that said student > had quit working on FPC because he found the code base to be > a mess? > (And which is sadder to me, he also took a different adviser for > his next year course work). > I actually teach compiler construction at the university, > and he correctly noted that compilers produced by some > students at the end of the course are better structured than FPC. Oh really? Where can I download these great compilers? I hope they are ready for production use. BTW: We spend a lot of time to fix his mess of code :) No problem he was student, but I consider him far from being able to judge about code quality considering his work :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): > First Pascal-like languages and later C. > FPC's main developer doesn't see a need for it. Indeed. Please tell what a C front end to FPC helps? FPC has no advantage over existing C compilers except being a pascal compiler ;). Do you think any C developer will work on a C compiler written in pascal? It won't make interfacing C headers easier as explained multiple times. So what do you expect from a C front end? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl wrote: > Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): >> First Pascal-like languages and later C. >> FPC's main developer doesn't see a need for it. > > Indeed. Please tell what a C front end to FPC helps? FPC has no > advantage over existing C compilers except being a pascal compiler ;). > Do you think any C developer will work on a C compiler written in > pascal? It won't make interfacing C headers easier as explained multiple > times. So what do you expect from a C front end? Actually, I certainly think (and hope) that DoDi's goal is _not_ a "C frontend", but to find _any_ possible venue to upgrade the code structure of FPC code. I admire his persistence and productivity and my suggestion for a fork was not a trolling attempt (although it did start a flame, for which I am sorry). To get going, a fork needs some momentum and dedication and maybe he is the person able to pull it off. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 12:07, schrieb Alexander Klenin: > On Tue, Oct 19, 2010 at 17:59, Paul Ishenin wrote: >> 19.10.2010 14:49, Vincent Snijders wrote: >> >>> So maybe you cannot do anything for FPC, except creating an Enhanced FPC. >> >> About a year ago I created a document which describes what features FPC >> requires to compile recent Delphi code. If someone does not know what to do >> for FPC then he is welcome to implement one of missing features: >> >> http://wiki.lazarus.freepascal.org/delphi_language_features_which_fpc_does_not_have >> >> The most wanted feature is "Unicode string support". > > I personally wanted to do some things for FPC (although Unicode was > not one of them), > but hesitated, because the current code is too messy and fragile to touch, In which areas? > and refactorings are not welcome. Who says this? Usefull refactoring *is* welcome. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl wrote: > Am 19.10.2010 13:54, schrieb Alexander Klenin: >> from fixing case and reformatting of Math unit > > This does not help anybody ;) See, you have already rejected it ;-) The initial motivation was that current unit have lower-case procedure names, which is not Delphi-compatible and messes up code completion. >> to finishing/extending Paul's work on for..in loop. > Does it still miss stuff? Actually, I never used it :) It does not "miss" stuff, but could be extended. I meant http://wiki.freepascal.org/for-in_loop#Proposed_extensions > So you looked yourself into the refactored code so you can judge it as > good? Did you send an email with your comment why it is good? Actually, I tried to, although svn made it extremely difficult and I am not aware of git/hg mirror of branches. The changes are very promising (although IFDEF's are a mess, but as I understand they are planned for removal). I did not test and have not enough understanding of FPC internals to spot any breakage by code inspection, but the readability and modularization improvements are quite obvious to me. >Where did you comment on the critism I made? I have really restrained myself from commenting on them because I it is hard to do in a polite manner. Since you insist, I will try: > - people knowing the old code for 15 years having to dig into new code Do you even understand how backwards this sounds? Using the outdatedness of code as an excuse not to refactor it is usually reserved for big corporations, not modern open-source projects :-) > - slower Or maybe faster? Did you benchmark it? Of did you see a specific location of code which will cause slowdown? >- code spread over multiple locations Which is called modularization aka OO, and is IMO the main point of the branch >- lost svn blame history use git >- last but not least, you coding style does not follow the compiler code style Which may be trivially fixed (btw, compiler code style is really ... um... exotic). >> Well, maybe I should try myself >> but the experience of others is definitely discouraging. > Who is others? I remember very few *compiler* patches we rejected. Sorry, but I do not believe you have forgotten all the recent flame about the rejected changes ;-) -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] unit tests for RTL & FCL + 2 patches
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote: Hi, Florian mentioned that the compiler is well tested, and I can see there are many .pp files in the src/tests/ hierarchy. Where would I look for the RTL and FCL unit tests? Is it the code in /tests/test/units/fpcunit/? If so, is that all of them, or is there another directory (eg: maybe for FCL) somewhere? There are almost none. They exist between the other tests, but they are a minority. Also attached are two patches for the /tests/test/units/fpcunit/ project. patch 001: Allows FPC 2.5.1 to actually compile the test suite patch 002: Changes lazarus project file options - session information is stored in separate .lps file - a unit output director to support multiple targets - a defined output filename that is easily accessible PS: I gather there is no automated running of the above test suites anywhere - like there is for the compiler tests? No, but I am open for suggestions on how to organize the fpcunit tests. I will see about applying the patch. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, 20 Oct 2010, Alexander Klenin wrote: On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl wrote: Am 19.10.2010 14:48, schrieb Alexander Klenin: On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl wrote: I actually teach compiler construction at the university, and he correctly noted that compilers produced by some students at the end of the course are better structured than FPC. Oh really? Where can I download these great compilers? http://imcs.dvgu.ru/works/home?name=%D0%9A%D0%BE%D0%BC%D0%BF;wt=1567;do_select=1 Sorry, russian interface only. I hope they are ready for production use. Of course not, they are written in 4 months by the 3rd year students spending 3-4 hours per week. BTW: We spend a lot of time to fix his mess of code :) No problem he was student, but I consider him far from being able to judge about code quality considering his work :) I know, he is certainly not the best student, but not a bad one too. Still, two points: 1) While he may be a bad judge, but he is certainly a good case study of an average programmer trying to make sense of FPC codebase. 2) I'd say that at least half of his mistakes could be avoided by better code structure of FPC -- he was really uncomfortable using strange records and pchars instead of normal objects and strings. That has nothing to do with code structure, but with efficiency. pchar and records are much faster than objects and strings. This has been established empirically a long time ago by the compiler developers. Speed of the compiler is an important factor, so records and pchars are used. So with your last argument you actually strengthen Florians case. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] unit tests for RTL & FCL + 2 patches
Hi, Florian mentioned that the compiler is well tested, and I can see there are many .pp files in the src/tests/ hierarchy. Where would I look for the RTL and FCL unit tests? Is it the code in /tests/test/units/fpcunit/? If so, is that all of them, or is there another directory (eg: maybe for FCL) somewhere? Also attached are two patches for the /tests/test/units/fpcunit/ project. patch 001: Allows FPC 2.5.1 to actually compile the test suite patch 002: Changes lazarus project file options - session information is stored in separate .lps file - a unit output director to support multiple targets - a defined output filename that is easily accessible PS: I gather there is no automated running of the above test suites anywhere - like there is for the compiler tests? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ 001-fpcunit_tclist.pp.patch Description: application/mbox 002-fpcunit_testclasses.patch Description: application/mbox ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 10/19/2010 11:24 AM, Felipe Monteiro de Carvalho wrote: ? They were deeply frustrated that we have a simple and reliable Unicode support which supports any language in the world? I'm not going to discuss (again) what a beginner will do and what he will see when stepping character by character through a String containing German text ;) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl wrote: > Am 19.10.2010 14:48, schrieb Alexander Klenin: >> On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl >> wrote: >> I actually teach compiler construction at the university, >> and he correctly noted that compilers produced by some >> students at the end of the course are better structured than FPC. > > Oh really? Where can I download these great compilers? http://imcs.dvgu.ru/works/home?name=%D0%9A%D0%BE%D0%BC%D0%BF;wt=1567;do_select=1 Sorry, russian interface only. >I hope they are ready for production use. Of course not, they are written in 4 months by the 3rd year students spending 3-4 hours per week. > BTW: We spend a lot of time to fix his mess of > code :) No problem he was student, but I consider him far from being > able to judge about code quality considering his work :) I know, he is certainly not the best student, but not a bad one too. Still, two points: 1) While he may be a bad judge, but he is certainly a good case study of an average programmer trying to make sense of FPC codebase. 2) I'd say that at least half of his mistakes could be avoided by better code structure of FPC -- he was really uncomfortable using strange records and pchars instead of normal objects and strings. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 14:02, schrieb Alexander Klenin: > On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl > wrote: >> Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): >>> First Pascal-like languages and later C. >>> FPC's main developer doesn't see a need for it. >> >> Indeed. Please tell what a C front end to FPC helps? FPC has no >> advantage over existing C compilers except being a pascal compiler ;). >> Do you think any C developer will work on a C compiler written in >> pascal? It won't make interfacing C headers easier as explained multiple >> times. So what do you expect from a C front end? > > Actually, I certainly think (and hope) that DoDi's goal is _not_ a "C > frontend", > but to find _any_ possible venue to upgrade the code structure of FPC code. The topic of this thread and the patch was/is alternative parsers. As you worked on the case of string stuff (or your student) you might also know that the fpc parser is written straight forward and anybody knowing the dragon books might be able to work on it and far from being fragile. This why I see no use in the patch: the parser is understandable, maintainable and reasonable fast. Fragile are other parts: e.g. unit loading. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 12:47, schrieb Graeme Geldenhuys: /opt/fpc-2.4.0/bin/fpc -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -Us -Sg system.pp Free Pascal Compiler version 2.4.0 [2009/12/18] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl thread.inc(411,10) Warning: Function result does not seem to be set /opt/fpc-2.4.0/bin/fpc -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 ../unix/unixtype.pp Free Pascal Compiler version 2.4.0 [2009/12/18] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl Fatal: Can't find unit objpas used by unixtype Fatal: Compilation aborted Error: /opt/fpc-2.4.0/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) make[5]: *** [unixtype.ppu] Error 1 make[5]: Leaving directory `/opt/git/fpc_cpstrnew/rtl/linux' make[4]: *** [linux_all] Error 2 make[4]: Leaving directory `/opt/git/fpc_cpstrnew/rtl' make[3]: *** [rtl] Error 2 make[3]: Leaving directory `/opt/git/fpc_cpstrnew/compiler' make[2]: *** [next] Error 2 make[2]: Leaving directory `/opt/git/fpc_cpstrnew/compiler' make[1]: *** [ppc1] Error 2 make[1]: Leaving directory `/opt/git/fpc_cpstrnew/compiler' make: *** [cycle] Error 2 If I see this correctly, the makefile is trying to compile "unixtype" before "objpas" is compiled. Shouldn't "objpas" be the second unit that is compiled? Or was something added to "unixtype" that makes it depend on "objpas" now while that wasn't the case before? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 12:18, schrieb Graeme Geldenhuys: > > Like I've said a million times before, the management of the FPC project > seems a bit off (sorry if this offends some of you, don't take it > personally). Hardly anybody looks at the various branches, so to truly test > something new Indeed, it's just a matter of time which seems nobody to have, see e.g. cpstrnew branch: very few people test, nobody contributes or why is compilation broken? Even more it even doesn't affect the compiler, the rtl needs fixing, we need tests etc. Where are the fixes and enhancments for the rtl? Where are the tests? > a workflow similar to the git.git repository needs to be > adopted. It has nothing to do with workflow. > spare time, and the git development is a 1000x faster than FPC's, with > hundreds of contributors. See above about the cpstrnew branch. But if git helps a lot, where can I pull the fixes to the cpstrnew branch? Where are the other git repositories containing the great patches to FPC? You maintain your git mirror already for years, there must be some cloned repositories and forks with a lot of contributions. I guess a lot of it could go into trunk, git format-patch -XX together with svn-apply makes this really easy, just tell me the git urls ;) > > >> Also refactoring because of personal preferences, aesthetics or >> new design patterns or paradigms must be handled very carefully > > Yes, there goal is normally to make code more manageable and easier > understood by others - indirectly making contributions easier. See cpstrnew branch, it has nothing to do with the compiler, the rtl needs fixing. > > >> There is a big >> danger of degrading the stability by such changes which are not planned >> by the core developers. > > That is what unit testing frameworks where designed for. Unit test the > compiler code, so there is no surprises and no guessing required to know if > something broke something else or not. FPC has some tests, but I have no > idea how extensive they are. For the compiler they are very extensive, not for the rtl/packages/fcl. > Last time I looked at the various tests > results published on the web (I can't remember that URL of the top of my > head), http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi > the outcome looks rather sad - with many many failed tests. I'm not > sure of all those failures were false negatives though. Some tests are just added to remember that something is broken. Actually, what we do are regression testing. Newly broken stuff must be fixed immediatly, tests which worked never before will be fixed if possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
In our previous episode, Graeme Geldenhuys said: > > > > As mentioned in other mails, the compilation order is "first the new RTL, > > then the new compiler" > > I saw your reply to Sven. I didn't know that, and never used it like that > before. I guess I was lucky. http://www.stack.nl/~marcov/buildfaq/#toc-Section-2.2 http://www.stack.nl/~marcov/buildfaq/#toc-Section-1.7 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Lazarus unicode support (was: Re: [fpc-devel] Alternative parsers)
Ah, just to close the issue. The original text from Michael Schnell was ambiguous and I understood he was talking about the Lazarus unicode support, but now I see that he could be talking about the Free Pascal unicode support ... which are 2 different things. Indeed, if he was about Lazarus Unicode support the discussion bellongs elsewhere. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19 Oct 2010, at 12:47, Graeme Geldenhuys wrote: > Op 2010-10-19 12:33, Jonas Maebe het geskryf: >> >> As mentioned in other mails, the compilation order is "first the new RTL, >> then the new compiler" > > I saw your reply to Sven. I didn't know that, and never used it like that > before. I guess I was lucky. > > Anyway, just downloaded and installed a fresh copy of FPC 2.4.0 from > SourceForge. "make cycle FPC=..." still fails I when I have the time, > I'll take another look, but I can't spend more time on it now. > > Did you actually test the cpstrnew branch by compiling it yourself - after > the merge? Yes, but it was on Mac OS X. At first sight, there are however no differences between the Makefile.fpc of the cpstrnew branch and the one in trunk (other than that trunk as an extra iso7185 unit for iso mode support), so I'm not sure what's going on in what you posted. I have to run now, I'll look into it later. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 12:33, Jonas Maebe het geskryf: > > As mentioned in other mails, the compilation order is "first the new RTL, > then the new compiler" I saw your reply to Sven. I didn't know that, and never used it like that before. I guess I was lucky. Anyway, just downloaded and installed a fresh copy of FPC 2.4.0 from SourceForge. "make cycle FPC=..." still fails I when I have the time, I'll take another look, but I can't spend more time on it now. Did you actually test the cpstrnew branch by compiling it yourself - after the merge? ~ $ cd /opt/git/fpc_cpstrnew/compiler/ compiler $ make cycle FPC=/opt/fpc-2.4.0/bin/fpc make tempclean ppc3 make[1]: Entering directory `/opt/git/fpc_cpstrnew/compiler' /bin/rm -f ppcrossx64 ppc ppc1 ppc2 ppc3 ./msg2inc pp1.wpo pp2.wpo make 'OLDFPC=' next make[2]: Entering directory `/opt/git/fpc_cpstrnew/compiler' make rtlclean rtl make[3]: Entering directory `/opt/git/fpc_cpstrnew/compiler' make -C ../rtl clean make[4]: Entering directory `/opt/git/fpc_cpstrnew/rtl' /bin/rm -f fpcmade.x86_64-linux Package.fpc ppas.sh script.res link.res /bin/rm -f *.s *_ppas.sh make -C linux clean make[5]: Entering directory `/opt/git/fpc_cpstrnew/rtl/linux' /bin/rm -f ../../rtl/units/x86_64-linux/prt0.o ../../rtl/units/x86_64-linux/dllprt0.o ../../rtl/units/x86_64-linux/cprt0.o ../../rtl/units/x86_64-linux/gprt0.o /bin/rm -f ../../rtl/units/x86_64-linux/system.ppu ../../rtl/units/x86_64-linux/unixtype.ppu ../../rtl/units/x86_64-linux/ctypes.ppu ../../rtl/units/x86_64-linux/baseunix.ppu ../../rtl/units/x86_64-linux/strings.ppu ../../rtl/units/x86_64-linux/objpas.ppu ../../rtl/units/x86_64-linux/macpas.ppu ../../rtl/units/x86_64-linux/syscall.ppu ../../rtl/units/x86_64-linux/unixutil.ppu ../../rtl/units/x86_64-linux/fpintres.ppu ../../rtl/units/x86_64-linux/heaptrc.ppu ../../rtl/units/x86_64-linux/lineinfo.ppu ../../rtl/units/x86_64-linux/lnfodwrf.ppu ../../rtl/units/x86_64-linux/termio.ppu ../../rtl/units/x86_64-linux/unix.ppu ../../rtl/units/x86_64-linux/linux.ppu ../../rtl/units/x86_64-linux/initc.ppu ../../rtl/units/x86_64-linux/cmem.ppu ../../rtl/units/x86_64-linux/x86.ppu ../../rtl/units/x86_64-linux/ports.ppu ../../rtl/units/x86_64-linux/crt.ppu ../../rtl/units/x86_64-linux/printer.ppu ../../rtl/units/x86_64-linux/linuxvcs.ppu ../../rtl/units/x86_64-linux/sysutils.ppu ../../rtl/units/x86_64-linux/typinfo.ppu ../../rtl/units/x86_64-linux/math.ppu ../../rtl/units/x86_64-linux/matrix.ppu ../../rtl/units/x86_64-linux/varutils.ppu ../../rtl/units/x86_64-linux/charset.ppu ../../rtl/units/x86_64-linux/ucomplex.ppu ../../rtl/units/x86_64-linux/getopts.ppu ../../rtl/units/x86_64-linux/errors.ppu ../../rtl/units/x86_64-linux/sockets.ppu ../../rtl/units/x86_64-linux/gpm.ppu ../../rtl/units/x86_64-linux/ipc.ppu ../../rtl/units/x86_64-linux/serial.ppu ../../rtl/units/x86_64-linux/terminfo.ppu ../../rtl/units/x86_64-linux/dl.ppu ../../rtl/units/x86_64-linux/dynlibs.ppu ../../rtl/units/x86_64-linux/video.ppu ../../rtl/units/x86_64-linux/mouse.ppu ../../rtl/units/x86_64-linux/keyboard.ppu ../../rtl/units/x86_64-linux/variants.ppu ../../rtl/units/x86_64-linux/types.ppu ../../rtl/units/x86_64-linux/dateutils.ppu ../../rtl/units/x86_64-linux/sysconst.ppu ../../rtl/units/x86_64-linux/fmtbcd.ppu ../../rtl/units/x86_64-linux/cthreads.ppu ../../rtl/units/x86_64-linux/classes.ppu ../../rtl/units/x86_64-linux/fgl.ppu ../../rtl/units/x86_64-linux/convutils.ppu ../../rtl/units/x86_64-linux/stdconvs.ppu ../../rtl/units/x86_64-linux/strutils.ppu ../../rtl/units/x86_64-linux/rtlconsts.ppu ../../rtl/units/x86_64-linux/dos.ppu ../../rtl/units/x86_64-linux/objects.ppu ../../rtl/units/x86_64-linux/cwstring.ppu ../../rtl/units/x86_64-linux/fpcylix.ppu ../../rtl/units/x86_64-linux/clocale.ppu ../../rtl/units/x86_64-linux/exeinfo.ppu ../../rtl/units/x86_64-linux/syslinux.ppu ../../rtl/units/x86_64-linux/linux.ppu /bin/rm -f ../../rtl/units/x86_64-linux/system.o ../../rtl/units/x86_64-linux/unixtype.o ../../rtl/units/x86_64-linux/ctypes.o ../../rtl/units/x86_64-linux/baseunix.o ../../rtl/units/x86_64-linux/strings.o ../../rtl/units/x86_64-linux/objpas.o ../../rtl/units/x86_64-linux/macpas.o ../../rtl/units/x86_64-linux/syscall.o ../../rtl/units/x86_64-linux/unixutil.o ../../rtl/units/x86_64-linux/fpintres.o ../../rtl/units/x86_64-linux/heaptrc.o ../../rtl/units/x86_64-linux/lineinfo.o ../../rtl/units/x86_64-linux/lnfodwrf.o ../../rtl/units/x86_64-linux/termio.o ../../rtl/units/x86_64-linux/unix.o ../../rtl/units/x86_64-linux/linux.o ../../rtl/units/x86_64-linux/initc.o ../../rtl/units/x86_64-linux/cmem.o ../../rtl/units/x86_64-linux/x86.o ../../rtl/units/x86_64-linux/ports.o ../../rtl/units/x86_64-linux/crt.o ../../rtl/units/x86_64-linux/printer.o ../../rtl/units/x86_64-linux/linuxvcs.o ../../rtl/units/x86_64-linux/sysutils.o ../../rtl/units/x86_64-linux/typinfo.o ../../rtl/units/x86_64-linux/math.o ../../rtl/units/x86_64-linux/matrix.o ../../rtl/units/x86_64-linux/var
Re: [fpc-devel] Alternative parsers
2010/10/19 Graeme Geldenhuys : > Op 2010-10-19 09:07, Vincent Snijders het geskryf: >> >> Yes, but I doubt this possible fork will be, but feel free to prove me wrong. > > Nobody will know, until a fork has been made. As for your opinion that it > will simply fail is a bit of thumb sucking. Some commercial entity could > easily fork FPC, throw 20 full times developers at it, have a nice huge > budget, and take Embarcadero head-on with a cross-platform compiler and > with 32/64-bit support already done. You still think that would fail? Given the fact that 20 full time developer work on it, I think they have a reasonable chance to succeed. > > Just look at Qt today - it started with 2 developers that thought they > could do better than what was currently out there. Mozilla, a fork from > Netscape - a pretty good success I would think. Eclipse - an idea IBM had, > thinking it would do better that what Sun offered. Firebird DB (from old > Interbase), PostgreSQL, MS SQL Server (comes from the same original > codebase as PostgresSQL did), MS-DOS, MS Office,... Many, many more such > success cases exist. All examples of one person/entity thinking they can do > a better job than the original person/entity. > It can be done, but it must be done, to prove it. Just talk won't do it. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19 Oct 2010, at 12:23, Graeme Geldenhuys wrote: > Op 2010-10-19 11:43, Jonas Maebe het geskryf: >> >> I'm not sure how that's related to the merge I did. >> DefaultSystemCodePage is a system unit variable that was introduced in >> the cpstrnew branch. > > What good is a merge that breaks the compiling of the compiler? As I said, your problem is unrelated to the merge, and the merge did not break compiling the compiler. Prior to the merge, DefaultSystemCodePage was a) already in the RTL of the cpstrnew branch b) already used in the compiler of the cpstrnew branch. If everything compiled fine for you before, then maybe you had a compiled version of the cpstrnew branch somewhere that is no longer used now (maybe because a ppu version changed, or because it wasn't compiled with -Ur and the compiler is finding new versions of RTL sources, ...). > I simply loaded up the compiler/ppx86_64.lpi project, set the compiler to > be used by Lazarus IDE, and clicked Build All. I didn't even get as far as > compiling the RTL - I'm just trying to build the compiler itself, which > worked before the merge. I have a separate script which uses the new > compiler to build the RTL of that branch, but like I said, I haven't even > gotten that far. As mentioned in other mails, the compilation order is "first the new RTL, then the new compiler" Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 11:43, Jonas Maebe het geskryf: > > I'm not sure how that's related to the merge I did. > DefaultSystemCodePage is a system unit variable that was introduced in > the cpstrnew branch. What good is a merge that breaks the compiling of the compiler? > The error message suggests that you are trying to > compile the cpstrnew compiler against an RTL from a different version. > The cpstrnew compiler depends on the cpstrnew RTL. I simply loaded up the compiler/ppx86_64.lpi project, set the compiler to be used by Lazarus IDE, and clicked Build All. I didn't even get as far as compiling the RTL - I'm just trying to build the compiler itself, which worked before the merge. I have a separate script which uses the new compiler to build the RTL of that branch, but like I said, I haven't even gotten that far. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 10:49, Martin Schreiber het geskryf: > > FPC is used in *production*! I agree, but this shouldn't prevent enhancements, forward thinking and innovation. > We can't accept experimental changes of the compiler architecture in > trunk. For production use, and for "stability", that is what the releases are for. Stick to those then. Trunk is a development branch, you should *not* be using in for production work, because it is unstable, and can break in any commit. Like I've said a million times before, the management of the FPC project seems a bit off (sorry if this offends some of you, don't take it personally). Hardly anybody looks at the various branches, so to truly test something new, a workflow similar to the git.git repository needs to be adopted. Feature branches are used, a experimental/development branch exists where feature branches are merged together. This is the branch most would test (in terms of SubVersion speak, consider this Trunk), and inherently test those features too. Features in this branch are not guaranteed to make it into the release branch, but importantly, it gives them a time to shine and played with. A more stable branch should exist. This contains features that have been tried and tested, and got promoted to the next level. It is this branch that is used to cut new releases from. At that point "fixes" branches could be cut from the release branch. Fixes applied to the fixes branch can be merged back into the stable branch and vice-versa. If svn is not up to the job (I'm not saying it is), or seems like to much work using svn, then the SubVersion software is the wrong tool for the job, because what I described above is done with very little effort using Git. In the git.git repository, all this is managed by a single person in his spare time, and the git development is a 1000x faster than FPC's, with hundreds of contributors. > Also refactoring because of personal preferences, aesthetics or > new design patterns or paradigms must be handled very carefully Yes, there goal is normally to make code more manageable and easier understood by others - indirectly making contributions easier. > There is a big > danger of degrading the stability by such changes which are not planned > by the core developers. That is what unit testing frameworks where designed for. Unit test the compiler code, so there is no surprises and no guessing required to know if something broke something else or not. FPC has some tests, but I have no idea how extensive they are. Last time I looked at the various tests results published on the web (I can't remember that URL of the top of my head), the outcome looks rather sad - with many many failed tests. I'm not sure of all those failures were false negatives though. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 17:59, Paul Ishenin wrote: > 19.10.2010 14:49, Vincent Snijders wrote: > >> So maybe you cannot do anything for FPC, except creating an Enhanced FPC. > > About a year ago I created a document which describes what features FPC > requires to compile recent Delphi code. If someone does not know what to do > for FPC then he is welcome to implement one of missing features: > > http://wiki.lazarus.freepascal.org/delphi_language_features_which_fpc_does_not_have > > The most wanted feature is "Unicode string support". I personally wanted to do some things for FPC (although Unicode was not one of them), but hesitated, because the current code is too messy and fragile to touch, and refactorings are not welcome. So if there would be a fork with better code structure, it is quite plausible that I would contribute. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 11:52, schrieb Jonas Maebe: On 19 Oct 2010, at 11:45, Sven Barth wrote: Am 19.10.2010 11:43, schrieb Jonas Maebe: I'm not sure how that's related to the merge I did. DefaultSystemCodePage is a system unit variable that was introduced in the cpstrnew branch. The error message suggests that you are trying to compile the cpstrnew compiler against an RTL from a different version. The cpstrnew compiler depends on the cpstrnew RTL. Can it be then that the compiler (or at least that part of the code) is not checking whether its compiled using an older or a newer RTL? Isn't the process normally "compile new compiler with old RTL, compile new RTL with this compiler, compile new compiler with new RTL"? The normal process is "make all" in the top level fpc directory, or "make cycle" in the fpc/compiler directory. Both first compile the new RTL. It's the opposite that sometimes has to be done: the RTL always has to be compilable by older compilers. Ah ok. So I got this one wrong. Thanks for clarification. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19 Oct 2010, at 11:45, Sven Barth wrote: > Am 19.10.2010 11:43, schrieb Jonas Maebe: >> >> I'm not sure how that's related to the merge I did. DefaultSystemCodePage is >> a system unit variable that was introduced in the cpstrnew branch. The error >> message suggests that you are trying to compile the cpstrnew compiler >> against an RTL from a different version. The cpstrnew compiler depends on >> the cpstrnew RTL. > > Can it be then that the compiler (or at least that part of the code) is not > checking whether its compiled using an older or a newer RTL? > > Isn't the process normally "compile new compiler with old RTL, compile new > RTL with this compiler, compile new compiler with new RTL"? The normal process is "make all" in the top level fpc directory, or "make cycle" in the fpc/compiler directory. Both first compile the new RTL. It's the opposite that sometimes has to be done: the RTL always has to be compilable by older compilers. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote: > cresstr.pas(149,178) Error: Identifier not found "DefaultSystemCodePage" > cresstr.pas(165,117) Error: Identifier not found "DefaultSystemCodePage" > cresstr.pas(170,126) Error: Identifier not found "DefaultSystemCodePage" > cresstr.pas(320) Fatal: There were 3 errors compiling module, stopping I'm not sure how that's related to the merge I did. DefaultSystemCodePage is a system unit variable that was introduced in the cpstrnew branch. The error message suggests that you are trying to compile the cpstrnew compiler against an RTL from a different version. The cpstrnew compiler depends on the cpstrnew RTL. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 09:37, schrieb Michael Van Canneyt: [...] Currently all we got from Hans Peter were unmanageable patches supposedly fixing things that were not broken or in need of fixing. If he had first done some smaller things - take your pick in the bugtracker - and we had seen that this goes well, then maybe such pervasive changes would be discussable. You also would't let the handyman from around the corner construct a 10-story appartment building just like that, I suppose, and then go and happily live in the penthouse ? In each case, this is the "chronicle of a death foretold". Not because we don't want changes, but because all guiding road signs we put up have been ignored since day 1. Just read the mail threads. It starts with the discussion that the fcl-passrc parser doesn't handle all compiler constructs. Instead of fixing that, Hans-Peter went off on a completely different angle, for which none of the core developers saw any future, and on more than one occasion pointed this out. And here we are now... Agreed 100%. FPC is used in *production*! We can't accept experimental changes of the compiler architecture in trunk. Also refactoring because of personal preferences, aesthetics or new design patterns or paradigms must be handled very carefully so the quality of the compiler really increases over time. There is a big danger of degrading the stability by such changes which are not planned by the core developers. Many thanks to the FPC core team that they try to steadily improve the quality of the Free Pascal compiler and do not allow scientific experiments with the codebase. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 11:43, schrieb Jonas Maebe: On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote: cresstr.pas(149,178) Error: Identifier not found "DefaultSystemCodePage" cresstr.pas(165,117) Error: Identifier not found "DefaultSystemCodePage" cresstr.pas(170,126) Error: Identifier not found "DefaultSystemCodePage" cresstr.pas(320) Fatal: There were 3 errors compiling module, stopping I'm not sure how that's related to the merge I did. DefaultSystemCodePage is a system unit variable that was introduced in the cpstrnew branch. The error message suggests that you are trying to compile the cpstrnew compiler against an RTL from a different version. The cpstrnew compiler depends on the cpstrnew RTL. Can it be then that the compiler (or at least that part of the code) is not checking whether its compiled using an older or a newer RTL? Isn't the process normally "compile new compiler with old RTL, compile new RTL with this compiler, compile new compiler with new RTL"? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 11:31, Marc Weustink het geskryf: > > What if you use a released compiler as starting compiler ? > (other versions are not supported) Like I said, this was just a quick test so I could post some output. Originally I did use the latest released compiler - 2.4.0 I believe. I'll try later today with 2.4.0 and see what it does, just to confirm. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Graeme Geldenhuys wrote: Op 2010-10-19 10:51, Jonas Maebe het geskryf: You still have not said a single time what the actual problem is that you are having. I believe I have, but I can't remember all the errors, and I have no time to search the mail archive Just tried to compile that branch again under 64-bit linux. - Free Pascal Compiler version 2.4.3 [2010/08/02] for x86_64 ^ ^^ What if you use a released compiler as starting compiler ? (other versions are not supported) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Lazarus unicode support (was: Re: [fpc-devel] Alternative parsers)
On 19 Oct 2010, at 11:24, Felipe Monteiro de Carvalho wrote: > On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell wrote: >> And I in the German Lazarus Forum watched several beginners trying to use >> this Lazarus version for doing programs dealing with German text. >> >> They were a lot more than "not amused" but rather deeply frustrated. > > ? > > They were deeply frustrated that we have a simple and reliable Unicode > support which supports any language in the world? Please move this branch of the discussion to the lazarus (or lazarus-other) list. Jonas FPC mailing lists admin___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell wrote: > And I in the German Lazarus Forum watched several beginners trying to use > this Lazarus version for doing programs dealing with German text. > > They were a lot more than "not amused" but rather deeply frustrated. ? They were deeply frustrated that we have a simple and reliable Unicode support which supports any language in the world? -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 10:06, Michael Schnell het geskryf: > On 10/19/2010 07:50 AM, Alexander Klenin wrote: >> >> I suggest you start a git-maintained fork. > Of course git is superior to svn for this purpose. > > Is the "base" repository hosted on a git server ? Yes, I maintain the mirror on GitHub. http://github.com/graemeg/freepascal For more details see... http://wiki.lazarus.freepascal.org/git_mirrors Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 10:51, Jonas Maebe het geskryf: > > You still have not said a single time what the actual problem is that you are > having. I believe I have, but I can't remember all the errors, and I have no time to search the mail archive Just tried to compile that branch again under 64-bit linux. - Free Pascal Compiler version 2.4.3 [2010/08/02] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for x86-64 Compiling pp.pas Compiling catch.pas Compiling verbose.pas Compiling cutils.pas Compiling globtype.pas Compiling finput.pas Compiling cclasses.pas Compiling cstreams.pas Compiling comphook.pas Compiling systems.pas Compiling globals.pas Compiling cfileutl.pas Compiling globals.pas Compiling ./x86_64/cpuinfo.pas Compiling version.pas Compiling cmsgs.pas Compiling fmodule.pas Compiling ogbase.pas Compiling owbase.pas Compiling aasmbase.pas Compiling fmodule.pas Compiling symbase.pas Compiling symconst.pas Compiling symsym.pas Compiling widestr.pas Compiling cp8859_1.pas Compiling cp850.pas Compiling cp437.pas Compiling cp1251.pas Compiling cp866.pas Compiling cp8859_5.pas Compiling constexp.pas Compiling symtype.pas Compiling ppu.pas Compiling fpccrc.pas Compiling crefs.pas Compiling fmodule.pas Compiling symsym.pas Compiling symdef.pas Compiling tokens.pas Compiling node.pas Compiling ./x86/cpubase.pas Compiling cgbase.pas Compiling rgbase.pas Compiling cgutils.pas Compiling optbase.pas Compiling nutils.pas Compiling symsym.pas Compiling symdef.pas Compiling aasmtai.pas Compiling aasmdata.pas Compiling aasmtai.pas Compiling fmodule.pas Compiling symsym.pas Compiling symdef.pas Compiling parabase.pas Compiling symsym.pas Compiling symdef.pas Compiling ./x86/aasmcpu.pas Compiling aasmsym.pas Compiling symsym.pas Compiling defcmp.pas Compiling symtable.pas Compiling symsym.pas Compiling symnot.pas Compiling defutil.pas Compiling symtable.pas Compiling symutil.pas Compiling procinfo.pas Compiling optutils.pas Compiling nbas.pas Compiling ./x86/aasmcpu.pas Compiling ./x86/itcpugas.pas Compiling pass_1.pas Compiling procinfo.pas Compiling tgobj.pas Compiling cgobj.pas Compiling rgobj.pas Compiling fmodule.pas Compiling wpobase.pas Compiling scanner.pas Compiling switches.pas Compiling dbgbase.pas Compiling options.pas Compiling comprsrc.pas Compiling script.pas Compiling rabase.pas Compiling ./systems/i_bsd.pas Compiling rescmn.pas Compiling paramgr.pas Compiling ncgrtti.pas Compiling nutils.pas Compiling ncon.pas Compiling nld.pas Compiling htypechk.pas Compiling ncnv.pas Compiling ncal.pas Compiling ninl.pas Compiling nadd.pas Compiling nmat.pas Compiling nset.pas Compiling nflw.pas Compiling optloop.pas Compiling nflw.pas Compiling nmem.pas Compiling nset.pas Compiling ncgmem.pas Compiling pass_2.pas Compiling ncgutil.pas Compiling export.pas Compiling regvars.pas Compiling psub.pas Compiling optdfa.pas Compiling import.pas Compiling gendef.pas Compiling pbase.pas Compiling pstatmnt.pas Compiling pexpr.pas Compiling pinline.pas Compiling ptype.pas Compiling nobj.pas Compiling pdecsub.pas Compiling ./x86_64/cpupara.pas Compiling objcutil.pas Compiling objcdef.pas Compiling pdecl.pas Compiling ptconst.pas Compiling pdecvar.pas Compiling asmutils.pas Compiling pdecobj.pas Compiling pexports.pas Compiling ./x86_64/cgcpu.pas Compiling ./x86/cgx86.pas Compiling ./x86/rgx86.pas Compiling ./x86_64/rgcpu.pas Compiling opttail.pas Compiling optcse.pas optcse.pas(171,76) Warning: Conversion between ordinals and pointers is not portable optcse.pas(168,24) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. optcse.pas(234,24) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. optcse.pas(266,29) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. optcse.pas(284,22) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. Compiling aopt.pas Compiling aoptobj.pas Compiling aoptbase.pas Compiling ./x86_64/aoptcpub.pas Compiling aoptda.pas Compiling aoptobj.pas Compiling ./x86_64/aoptcpu.pas Compiling ./x86_64/aoptcpud.pas Compiling objcgutl.pas Compiling nopt.pas Compiling nobjc.pas symdef.pas(5128,10) Warning: User defined: : this is completely wrong on so many levels... Compiling ogmap.pas Compiling compiler.pas Compiling parser.pas Compiling fppu.pas Compiling wpoinfo.pas Compiling scandir.pas Compiling psystem.pas Compiling pmodules.pas Compiling link.pas Compiling owar.pas Compiling assemble.pas Compiling cresstr.pas cresstr.pas(149,178) Error: Identifier not found "DefaultSystemCodePage" cresstr.pas(165,117) Error: Identifier not found "DefaultSystemCodePage" cresstr.pas(170,126) Error: Identifier not found "DefaultSystemCodePa
Re: [fpc-devel] Alternative parsers
On Tuesday 19 October 2010 11:10:29 Matt Emson wrote: > On 19 Oct 2010, at 06:50, Alexander Klenin wrote: > > On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich > > > > wrote: > >> So there's left nothing what I could do for FPC. > > > > I suggest you start a git-maintained fork. > > I have been biting my tongue a lot this week and almost posted the same > thing earlier on Sunday. It strikes me that DoDi wants to do some > interesting, experimental and radical changes and refactoring to the > codebase. A fork is the only real option. This removes the burden from the > core developers, makes DoDi able to prove his theories without constantly > arguing with the core developers and stops the arguments on this list. As > I see it, Florian et al are less likely than ever to accept patches from > him. He does not want to conform to their coding style and is rocking the > status quo. DoDi sees Florian et al as a giant road block in his attempts > to move FPC forwards as an academic exercise. A fork will solve this issue > completely. +1 The current situation is frustrating for everybody. I understood DoDi's one goal is to refactor the front end so that other language parsers can be added. First Pascal-like languages and later C. FPC's main developer doesn't see a need for it. That is a fundamental difference. A fork is the only solution. Competition can be good and beneficial, too. If DoDi really comes up with a stable compiler that supports many languages, people start asking why FPC didn't do the same. Then maybe things get merged. It will not happen soon though. DoDi's changes are so fundamental that they inevitably break something first. I promise follow closely and test the fork if it becomes a reality. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 10/19/2010 07:50 AM, Alexander Klenin wrote: I suggest you start a git-maintained fork. Of course git is superior to svn for this purpose. Is the "base" repository hosted on a git server ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 10:37, Michael Van Canneyt het geskryf: > > Changes to the compiler are allowed and have been implemented at various > times with very good results. Paul is living proof of this. ...and you totally missed my sarcastic intent with that message. DoDi's path forward seems clear... Fork the project to experiment without obstructions to prove his worth, or use an "official" SVN branch to experiment, or use a Git branch/repository to experiment. Personally I use the later quite frequent with Lazarus and fpGUI - I have some 15+ local branches with various experimental changes for Lazarus and fpGUI (and it's many sub projects). I have given up contributing my changes to Lazarus, for the same reason Dodi is struggling now (irrespective if the feature is big or small). This doesn't bothers me any more, because I still benefit from my efforts and changes, while others don't - it's their loss not mine. Thank you for open source software! [...DoDi, here is my Git workflow...] I simply reset my local custom lazarus branch to the head svn branch (this way I pick up all the new bugs, bugfixes and features), merge in the various feature branches and be done with it. Occasionally I rebase my feature branch to keep them in sync with svn head development - this near eliminates chances for conflicts (99.9% of the time) when I do merges with my feature branches. I've been working like this for months with great success. It keeps me happy, and I mostly stay out of the way of the lazarus team. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 19 Oct 2010, at 10:40, Graeme Geldenhuys wrote: > I still have local changes that add more unicode support and improved > unicode support under Linux, but the unicode branch is currently not > compilable on my system - due to the latest merge done in that branch. So > my work regarding that branch is on hold. You still have not said a single time what the actual problem is that you are having. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 10:31, schrieb Florian Klaempfl: Am 19.10.2010 10:20, schrieb Sven Barth: Am 19.10.2010 10:12, schrieb Florian Klaempfl: Am 19.10.2010 09:32, schrieb Graeme Geldenhuys: Op 2010-10-19 08:59, Paul Ishenin het geskryf: The most wanted feature is "Unicode string support". What Hans-Peter meant is that even if he does implement Unicode String support, that would require changes in the compiler. Florian apparently doesn't like any changes to the compiler, When did I say this? What I said was: I won't merge changes into trunk which implement support for alternative parsers (this is the topic of this thread!) because nobody could explain me yet the use of alternative parsers for FPC users. So I would spend time in something with no gain for users resulting in even less time for other problems. Maybe somebody else will merge it, but he takes the burden to fix any regressions and maintain the changed code. To be honest (as someone who hasn't yet posted to this topic): You sounded very much like "we don't want to merge this" with "we" as in "the core devs". When did I write "we"? I think my initial statement was pretty clear: http://lists.freepascal.org/lists/fpc-devel/2010-October/022335.html Yes, you didn't write "we". But it came along as such. That might be, because you - as the initial developer of FPC - are more or less the leader of this project and as such an "I" from you is often perceived as a "we", although you might not mean it in that way. That's a psychological problem ^^ Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote: Op 2010-10-19 08:59, Paul Ishenin het geskryf: The most wanted feature is "Unicode string support". What Hans-Peter meant is that even if he does implement Unicode String support, that would require changes in the compiler. Florian apparently doesn't like any changes to the compiler, plus he sees no need for Unicode String support, so why would others. ;-) Changes to the compiler are allowed and have been implemented at various times with very good results. Paul is living proof of this. But in all cases the changes are - smaller in scope. - desired features. I don't think you would take it kindly if I showed up with an interior house designer and re-decorated your whole house in some flashy 70-ies hippy look, just because I think it looks better. You'd probably first ask him to do your son's room - as a test - and see how that turns out. Then maybe you'd let him work on the rest of your house. Same is true here. Currently all we got from Hans Peter were unmanageable patches supposedly fixing things that were not broken or in need of fixing. If he had first done some smaller things - take your pick in the bugtracker - and we had seen that this goes well, then maybe such pervasive changes would be discussable. You also would't let the handyman from around the corner construct a 10-story appartment building just like that, I suppose, and then go and happily live in the penthouse ? In each case, this is the "chronicle of a death foretold". Not because we don't want changes, but because all guiding road signs we put up have been ignored since day 1. Just read the mail threads. It starts with the discussion that the fcl-passrc parser doesn't handle all compiler constructs. Instead of fixing that, Hans-Peter went off on a completely different angle, for which none of the core developers saw any future, and on more than one occasion pointed this out. And here we are now... That we would be accused of not allowing changes, this also was foretold. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 10:18, Michael Schnell het geskryf: >> The most wanted feature is "Unicode string support". > Which means "new Delphi Strings" with dynamic code support ? > > There is a branch in the svn. How is the state and the pan ? I still have local changes that add more unicode support and improved unicode support under Linux, but the unicode branch is currently not compilable on my system - due to the latest merge done in that branch. So my work regarding that branch is on hold. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 10:20, schrieb Sven Barth: > Am 19.10.2010 10:12, schrieb Florian Klaempfl: >> Am 19.10.2010 09:32, schrieb Graeme Geldenhuys: >>> Op 2010-10-19 08:59, Paul Ishenin het geskryf: The most wanted feature is "Unicode string support". >>> >>> What Hans-Peter meant is that even if he does implement Unicode String >>> support, that would require changes in the compiler. Florian apparently >>> doesn't like any changes to the compiler, >> >> When did I say this? What I said was: I won't merge changes into trunk >> which implement support for alternative parsers (this is the topic of >> this thread!) because nobody could explain me yet the use of alternative >> parsers for FPC users. So I would spend time in something with no gain >> for users resulting in even less time for other problems. Maybe somebody >> else will merge it, but he takes the burden to fix any regressions and >> maintain the changed code. >> > > To be honest (as someone who hasn't yet posted to this topic): You > sounded very much like "we don't want to merge this" with "we" as in > "the core devs". When did I write "we"? I think my initial statement was pretty clear: http://lists.freepascal.org/lists/fpc-devel/2010-October/022335.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
I meant to write: -->> Some colleagues of mine need to port their projects from non-Unicode Delphi to the new Unicode enabled Delphi version. Sorry -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 10/19/2010 09:32 AM, Graeme Geldenhuys wrote: 'plus he sees no need for Unicode String support, so why would others. ;-) Some colleagues of mine need to port their projects from non-Delphi to the new Unicode enabled version. They are "not amused". I did try to work with the Unicode-enabled Lazarus (that abuses "ANSI"-Strings as UTF-8 Strings". Yak ! And I in the German Lazarus Forum watched several beginners trying to use this Lazarus version for doing programs dealing with German text. They were a lot more than "not amused" but rather deeply frustrated. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 10:12, schrieb Florian Klaempfl: Am 19.10.2010 09:32, schrieb Graeme Geldenhuys: Op 2010-10-19 08:59, Paul Ishenin het geskryf: The most wanted feature is "Unicode string support". What Hans-Peter meant is that even if he does implement Unicode String support, that would require changes in the compiler. Florian apparently doesn't like any changes to the compiler, When did I say this? What I said was: I won't merge changes into trunk which implement support for alternative parsers (this is the topic of this thread!) because nobody could explain me yet the use of alternative parsers for FPC users. So I would spend time in something with no gain for users resulting in even less time for other problems. Maybe somebody else will merge it, but he takes the burden to fix any regressions and maintain the changed code. To be honest (as someone who hasn't yet posted to this topic): You sounded very much like "we don't want to merge this" with "we" as in "the core devs". It wasn't really clear (at least to me and maybe some others as well) that you only spoke for yourself. And regarding Graeme's comment about Unicode String support: I believe that was meant in a sarcastic way. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On 10/19/2010 08:59 AM, Paul Ishenin wrote: The most wanted feature is "Unicode string support". Which means "new Delphi Strings" with dynamic code support ? There is a branch in the svn. How is the state and the pan ? Other stuff recently discussed is thread support (not or not perfectly functioning TThread.Synchronize, TThread.Suspend, SendMessage, non-existing TThread.Queue, ...) there are some hints in the forums and the Bugtracker. While most of this in fact are Lazarus-LCL originated issues, IMHO FPC is deeply involved, as it _should_ be able to use all this in projects that don't use the LCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys: > Op 2010-10-19 08:59, Paul Ishenin het geskryf: >> >> The most wanted feature is "Unicode string support". > > What Hans-Peter meant is that even if he does implement Unicode String > support, that would require changes in the compiler. Florian apparently > doesn't like any changes to the compiler, When did I say this? What I said was: I won't merge changes into trunk which implement support for alternative parsers (this is the topic of this thread!) because nobody could explain me yet the use of alternative parsers for FPC users. So I would spend time in something with no gain for users resulting in even less time for other problems. Maybe somebody else will merge it, but he takes the burden to fix any regressions and maintain the changed code. The alternative is: we merge any patch we get and if it's broken, well, we can hope that somebody provides another patch. But believe me, with this approach FPC will be unusable within a few months because the typical patch supplier does not check regression tests but we currently do it and fix the stuff we took responsibility by merging. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Sent from my iPhone On 19 Oct 2010, at 06:50, Alexander Klenin wrote: > On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich > wrote: > >> So there's left nothing what I could do for FPC. > > I suggest you start a git-maintained fork. I have been biting my tongue a lot this week and almost posted the same thing earlier on Sunday. It strikes me that DoDi wants to do some interesting, experimental and radical changes and refactoring to the codebase. A fork is the only real option. This removes the burden from the core developers, makes DoDi able to prove his theories without constantly arguing with the core developers and stops the arguments on this list. As I see it, Florian et al are less likely than ever to accept patches from him. He does not want to conform to their coding style and is rocking the status quo. DoDi sees Florian et al as a giant road block in his attempts to move FPC forwards as an academic exercise. A fork will solve this issue completely. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 09:07, Vincent Snijders het geskryf: > > Yes, but I doubt this possible fork will be, but feel free to prove me wrong. Nobody will know, until a fork has been made. As for your opinion that it will simply fail is a bit of thumb sucking. Some commercial entity could easily fork FPC, throw 20 full times developers at it, have a nice huge budget, and take Embarcadero head-on with a cross-platform compiler and with 32/64-bit support already done. You still think that would fail? Just look at Qt today - it started with 2 developers that thought they could do better than what was currently out there. Mozilla, a fork from Netscape - a pretty good success I would think. Eclipse - an idea IBM had, thinking it would do better that what Sun offered. Firebird DB (from old Interbase), PostgreSQL, MS SQL Server (comes from the same original codebase as PostgresSQL did), MS-DOS, MS Office,... Many, many more such success cases exist. All examples of one person/entity thinking they can do a better job than the original person/entity. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
Op 2010-10-19 08:59, Paul Ishenin het geskryf: > > The most wanted feature is "Unicode string support". What Hans-Peter meant is that even if he does implement Unicode String support, that would require changes in the compiler. Florian apparently doesn't like any changes to the compiler, plus he sees no need for Unicode String support, so why would others. ;-) [OK, I'll stop here...] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
2010/10/19 Graeme Geldenhuys : > I guess that doesn't mean Florian or some other core developer must accept > your patch or new features, but that's the beauty of open source software. > Simply fork the project and continue with your own Object Pascal compiler. > Many projects have done that in the past (the latest large project being > OpenOffice, now named LibreOffice), and many times the new forks are more > successful than the old - sometimes new management is all that is needed. Yes, but I doubt this possible fork will be, but feel free to prove me wrong. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
19.10.2010 14:49, Vincent Snijders wrote: So maybe you cannot do anything for FPC, except creating an Enhanced FPC. About a year ago I created a document which describes what features FPC requires to compile recent Delphi code. If someone does not know what to do for FPC then he is welcome to implement one of missing features: http://wiki.lazarus.freepascal.org/delphi_language_features_which_fpc_does_not_have The most wanted feature is "Unicode string support". Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
