Re: [fpc-devel] Alternative parsers
On Wednesday 20 October 2010 13:52:58 Marco van de Voort wrote: > In our previous episode, Juha Manninen (gmail) said: > > Still, C would be doable, for porting SOME existing code to co-operarate > > directly with pascal code. If the C code uses lots of library calls it > > can't be used directly. But, there is code for math and compression etc. > > which don't call libraries much. > > The implementation is much easier I guess yes. But the interoperability > remains the same. You still won't be able to access C headers directly from > Pascal. > > Moreover I think the goals of such project can be much easier accomplished > by having a C compiler that outputs (FPC) pascal source. True. DoDi must have some idea to solve it with the frontend. Automatic header conversion as part of the frontend maybe? > > Languages like ADA, Modula (and Fortran ? and Basic ? ) would be > > realistic. > > Modula2 is a special case since very related to Pascal. It needs some work > in the module handling (but that work can be recycled for other pascal > dialects that were inspired by that, like ISO Pascal too), but the main > problem is the lexer/parser, because M2 is case sensitive and has a > different block structure (which goes beyond merely being a pascal > dialect). So that requires changes also to compiler internals and not only to frontend? Ok then. > The only other problem I can think of is that is primarily has unsigned > arithmetic, which might require enhancements/debugging on the semantic > parts. > > > I think the same goes for Ada as for C++. The language is so huge, that it > is probably better to fork, throw away the pascal part, and then later when > the ada support is ok, backport the pascal part back into the Ada compiler. > (that will probably be somewhere near 2022) > > I don't know fortran enough to comment, and Basic is so balkanized dialect > mess that nothing can be said about that without specification of what > dialect you mean. I can only image VB here, but VB is very complex > internally, and the existing codebases are horribly windows specific). > Moreover when it finally would be production ready, VB6 would probably be > near extinction. I have to agree. A frontend can't solve those. Fortran would be the most realistic I guess but only few people would need it. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wednesday 20 October 2010 13:08:15 Marco van de Voort wrote: > That is exactly the kind of circle reasoning that haunts these discussions. > The actual target is a constant flux, and adapts to suit the reasoning: > > MS> We need a C++ frontend > MV> Why ? > MS> porting to Pascal is such a horror, and then we could C++ code as is. > MV> implementing a C++ does not mean interoperability > JH> Then change C++ so that is interoperable. > MV> But then you are can't compile foreign C++ code anymore! Yes, I admit C++ is a bad example. I would also say there is no practical way to integrate it with FPC. It was not listed in DoDi's plans either. Somehow the topic shifted here. Still, C would be doable, for porting SOME existing code to co-operarate directly with pascal code. If the C code uses lots of library calls it can't be used directly. But, there is code for math and compression etc. which don't call libraries much. Languages like ADA, Modula (and Fortran ? and Basic ? ) would be realistic. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
On Wednesday 20 October 2010 11:53:02 Marco van de Voort wrote: > Again: Combining two languages into one compiler doesn't magically make > them interoperable. And the only existing example doesn't exactly have a > crack record on using C++ FROM Delphi (the otherway around is different, > I'm told, not elegant, but doable). > > Basically it would mean implementing the innerards of C++ into the whole > existing (pascal) compiler too, so that the pascal compiler can access C++ > objects, not just a two bit extra parser. (which is also not so simple as > it sounds, since probably backends mod to execute C++ in a compliant way > are also possible). No, it would be the other way around. The "kind of C++" or "pseudo C++" or whatever would map to the existing compiler's data and object structure. I think Michael Schnell's idea is about the same as mine (see the other mail). However, C++ is a poor example because its syntax is a deep swamp. Ok, I don't start with multiply inheritance or templates... The frontend would need to ban lots of syntax, practically creating a new C++ related language ... No thanks for me ... I see C++ as an example of how NOT to do things. Other language frontends would be realistic IMO. Juha ___ 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] 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
[fpc-devel] Re: [Lazarus] Syntax highlighting anomalies
On Saturday 09 October 2010 09:51:59 Alexander Klenin wrote: > On Sat, Oct 9, 2010 at 14:24, Hans-Peter Diettrich wrote: > >> break, continue and exit are not keywords. They could be > >> redefined. > > > > I'd appreciate when, at least in mode FPC, these words would become > > keywords. As already mentioned, a redefinition of these procedures can > > only cause trouble. When they occur in legacy code, it would do no harm > > when such modules had to be compiled in an different (Delphi) mode. > > Yes, this would be a good change, similar to restrictiions on the duplicate > variable names in the overlapping scopes. > I think, however, that this change has near-zero chance of > getting through fpc core team. I would vote for this this, too. Maybe nobody asked the fpc core team, so I cross-post this also to fpc-devel list. I just realized how important the duplicate variable name restriction is when I tried to convert some existing code. Clearly the original author didn't always know which variable gets used. Juha > One relevant data point: for many years, > I use Delphi for the "Programming 101" university course I teach. > Every year, out of approx. 15 students in the group, 5-6 make the mistake > of naming some component or variable "exit" or "break", and spend > hours or even days trying to find the problem, until they finally give > up and ask me for help. > > -- > Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic Arrays as Static class variables
On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote: > Hi, > > I just tried and can reproduce this with fpc rev. 16078 on win64. Same thing here on Linux , AMD64, few days old FPC trunk version. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote: > And why does the Delphi commandline compiler (dcc32) not need this IDE > assistance? My guess is that dcc32 works as an integrated make program + compiler and thus doesn't start external processes for each file. Or, if it starts an external process then it can use some (hidden) temporary file with pre-scanned info of the project. So the compiler would only open one "info" file instead of scanning the whole search paths. I used the IDE always when working with Delphi and don't really know dcc32. Guessing only. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
On Saturday 11 September 2010 09:55:14 Martin Schreiber wrote: > On Friday 10 September 2010 17:43:59 Adem wrote: > > Sometime ago, there was a brief mention of multi-threading FPC would be > > counter productive because compilation process was mostly disk IO bound > > --this is what I understood anyway. > > > > I wanted to check to see if disk IO was really limiting FPC/Lazarus > > compile performance. > > Interesting is that Delphi 7 compiles about 10 times faster than FPC on the > same machine. > http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html > Results with more code and FPC 2.4: > http://thread.gmane.org/gmane.comp.ide.mseide.user/18797 > One would think Delphi and FPC need the same disk IO? I read the threads. My guess is also that the slowness comes from searching and writing many files in big directory structures. It is slow even if the files are cached. Also starting a new process is slow. These OS kernel tasks are difficult to measure and process monitors don't give reliable results. Suggestion: Create an API for integrating FPC with IDEs and special "make" programs. The API would pass info about exact file names and locations. It could also pass the whole source memory buffers. Then build FPC as a dynamic shared library. There would be 2 FPC binaries then: the traditional executable, and a shared library to be called from external programs. For example Lazarus IDE already scans a lot of information about project's files and directories. That info could be "easily" passed to compiler. Codetools in Lazarus already parses lots of code. The whole parsed interface section could be passed to compiler (symbol table and whatnot). ... but that is the next step, let's stick with file info now... Then there would be a new dedicated build program which reads all project info first and then calls the compile function (not a separate process) in the shared lib for each source file. No expensive process startups, no searching for include files again for each source file from huge directory structures. I bet it would make a BIG difference in speed. Delphi must be doing something like this although I don't know details. After that it makes sense to make the compiler multi-threaded. It could scale almost linearly with CPU cores (maybe). I haven't seen such ideas in these mailing lists. Is it possible I am the first one to have it? I don't believe because the idea is so obvious. If there is already such development with the new make tools then sorry for my ignorance. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel processing in the compiler
On Sunday 05 September 2010 13:29:38 Graeme Geldenhuys wrote: > Reading Jonas's comments and your reply above, it seems a git mirror > (or a subversion/git dual setup) would be much better suited for your > working style. git allows local commits and local branches. Ideal for > cases like "so those changes don't get lost" or braking a large set of > changes into smaller commits. +1 I can recommend it, too. In some earlier mail I mentioned it would solve DoDi's problems with merging his branch with trunk after they have deviated much from each other. Having your local git branch active, just run : $ git rebase master (assuming master branch is trunk) I just recently created a git branch from my old Lazarus Build Profiles patch. It took some effort to solve all conflicts but now I am confident I can keep it in sync with trunk easily by running "git rebase master" once a week or so. It is good in case the feature is accepted for Lazarus in future (during next 5 year plan maybe). Git seems to be a good tool for such things and it integrates well with SVN. Everybody should be happy. :-) Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
