Re: [fpc-other] Fork
I don't have the top post ( http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html ) in this thread to comment on in a more conversation fashion, as a result I reverting to bulleted listing of my views on the subject. 1) In the fpc-devel I have read quite a few arguments that FPC is production quality and no significant changes can be afforded to that code. While I sympathize with what that implies, it also means that, structurally, FPC is more or less frozen --except for very small incremental alterations, there isn't much that can be done with/to it. That brings me to this remark by DoDi: "Unfortunately some restrictions apply to the possible changes to the original code, when we want to stay in sync with the SVN trunk." I am not at all sure that this is the way to go about it. It is very likely that the needed changes will soon amount to a shape that will make it impossible to stay in sync with the FPC trunk. So, I think it would be more sensible/rational to remove this artificial/unsustainable restriction/desire and decide to call this a proper fork for a new version which may or may not be source-mergeable with the FPC trunk. 2) As it is, FPC codebase represents a very high barrier of entry for the uninitiated, drastically reducing any chances of outsiders coming in and contributing. To help with that, I'd like to see the new FPC to be functionally as modularized as possible with sufficiently clear boundaries between each so that people can work on parts without having to know and worry about the whole thing all the time. I can hear the 'speed arguments' (that, doing this would lower the speed of compilation etc.) but I am yet to be convinced; plus, if I had to choose between sacrificing a few percent on raw performance and the ease of maintainability, I'll always go for the ease of maintainability. 3) Alternative parsers. I have read all the objections about this. Yes, it may not solve every single problem. Yes, it will not mean FPC will take over GCC. Yes, not everyone need this functionality. Etc. Etc. But, all these seem to ignore one simple fact: Object Pascal (OP) is not a widely used language. A lot of code that is out there is in some other language. Which means, OP developers have either to reinvent most wheels by rewriting the code they need (even though it is readily available in some other language) or try to convert that code into OP. All this is not only a major waste of time, sometimes it requires extensive knowledge of that language. So, IMO, anything that helps using that large amount of code base can only be GOOD THING even if it isn't perfect all the time. -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Am 21.10.2010 22:13, schrieb Adem: > I don't have the top post ( > http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html ) > in this thread to comment on in a more conversation fashion, as a result > I reverting to bulleted listing of my views on the subject. > > 1) In the fpc-devel I have read quite a few arguments that FPC is > production quality and no significant changes can be afforded to that code. > > While I sympathize with what that implies, it also means that, > structurally, FPC is more or less frozen This is wrong. If a big change promises significant advantages for FPC users, it will be done. Things like turning the parser upside down simply don't have an significant advantage for users. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 2010-10-20 09:31, Graeme Geldenhuys wrote: Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf: SourceForge has good project management tools, from bug reporting, mailing lists (though I prefer newsgroups), I also prefer newsgroups. I could try to set one up, but INN simply scares me. Even if I could get it working, there's also the issue of authentication (to prevent spammers). Further, a server I set up at home is never going to be as robust as one that runs in a professional environment by professionals --see what happened to forums.talkto.net But, all my googling couldn't locate a single ISV/ISP that provides private NNTP service with authentication --much like CodeGear's. Could someone suggest a couple of leads. -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 2010-10-21 23:47, Florian Klämpfl wrote: This is wrong. If a big change promises significant advantages for FPC users, it will be done. The qualifier 'significant' (above and below) is far too subjective sometimes to even have a hope of arriving at a common ground. But, I'll take my chaces and point at DoDi's alternative parsers proposal. To me, it does sound like quite a significant advantage. But, apparently, not so for you... Things like turning the parser upside down simply don't have an significant advantage for users. About the 'significant advantage' bit, see above. If with the new parser design we can produce exactly the same binaries and it handles all the source code that the current compiler does, why does it matter which way up the parser stands? -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
2010/10/21 Adem : > On 2010-10-21 23:47, Florian Klämpfl wrote: > > This is wrong. If a big change promises significant advantages for FPC > users, it will be done. > > The qualifier 'significant' (above and below) is far too subjective > sometimes to even have a hope of arriving at a common ground. > > But, I'll take my chaces and point at DoDi's alternative parsers proposal. > > To me, it does sound like quite a significant advantage. Oh wow, so you want to change the parser because it "sounds" nice to you? Seriously, if this work was done more co-operatively with the fpc team, it may have made it. But I think it is too ambitious in the first place. Some people maintain patch quilts for ages before it makes it into the kernel, for example. Henry ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 2010-10-22 01:23, Henry Vermaak wrote: 2010/10/21 Adem: On 2010-10-21 23:47, Florian Klämpfl wrote: This is wrong. If a big change promises significant advantages for FPC users, it will be done. The qualifier 'significant' (above and below) is far too subjective sometimes to even have a hope of arriving at a common ground. But, I'll take my chaces and point at DoDi's alternative parsers proposal. To me, it does sound like quite a significant advantage. Oh wow, so you want to change the parser because it "sounds" nice to you? You didn't read Florian's post; did you? Let me copy&paste the relevant bit here: "If a big change *promises* significant advantages for FPC users, it will be done." Did you notice the word 'promises'? Seriously, if this work was done more co-operatively with the fpc team, it may have made it. But I think it is too ambitious in the first place. Some people maintain patch quilts for ages before it makes it into the kernel, for example. You make it sound like some of those religious orders where you have to spend years of your life... just to prove your piety. Meritocracy out, monasticism in? :) -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
2010/10/21 Adem : > On 2010-10-22 01:23, Henry Vermaak wrote: > > 2010/10/21 Adem : > > On 2010-10-21 23:47, Florian Klämpfl wrote: > > This is wrong. If a big change promises significant advantages for FPC > users, it will be done. > > The qualifier 'significant' (above and below) is far too subjective > sometimes to even have a hope of arriving at a common ground. > > But, I'll take my chaces and point at DoDi's alternative parsers proposal. > > To me, it does sound like quite a significant advantage. > > Oh wow, so you want to change the parser because it "sounds" nice to you? > > You didn't read Florian's post; did you? > > Let me copy&paste the relevant bit here: > > "If a big change promises significant advantages for FPC users, it will be > done." > > Did you notice the word 'promises'? Somehow you have to prove these "promises". > Seriously, if this work was done more co-operatively with the fpc team, it > may have made it. But I think it is too ambitious in the first place. Some > people maintain patch quilts for ages before it makes it into the kernel, > for example. > > You make it sound like some of those religious orders where you have to > spend years of your life... just to prove your piety. I don't care what it "sounds" like to you, I'm pointing you to valid examples of real features that are complicated and that need to mature and to evolve, but most of all, need a lot of work before they can prove that they are worth anything. To implement a complicated feature, you need to break down the implementation into a lot of patches to make it easy for review. People aren't going to start accepting your refactoring patches because you promise them that it'll be worth it in the long run. > Meritocracy out, monasticism in? :) Whatever works for you. Henry ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
On 2010-10-22 02:50, Henry Vermaak wrote: 2010/10/21 Adem: On 2010-10-22 01:23, Henry Vermaak wrote: Did you notice the word 'promises'? Somehow you have to prove these "promises". And, how exactly do you expect them to be proved? On paper? Seriously, if this work was done more co-operatively with the fpc team, it may have made it. But I think it is too ambitious in the first place. Some people maintain patch quilts for ages before it makes it into the kernel, for example. You make it sound like some of those religious orders where you have to spend years of your life... just to prove your piety. I don't care what it "sounds" like to you, I'm pointing you to valid examples of real features that are complicated and that need to mature and to evolve, but most of all, need a lot of work before they can prove that they are worth anything. OK. Let me take a step back. You did say, above, "/Seriously, if this work was done more co-operatively with the fpc team, it may have made it./" which implies the approach was less than co-operative. Fine, lest's look at that: Did you notice the response from the core that --/to the effect, that is/-- the code is 15 years mature and those who are familiar with it aren't prepared to see things shifted around. Would you consider this as anything more than an invitation to do --at best-- cosmetic changes? Or, let me ask it another way: How would you achieve co-operativetiveness --other than staying out? You also said, above, "/But I think it is too ambitious in the first place./" Interesting. Unless I am reading this completely wrong, you're not saying the direction/aim is wrong; just that it is 'too ambitious'. I would have no qualms with that. But, expect you to follow it up with something like "among that list, do this first and let's see how it works, then you could move on to this", but, definitely not (I hope) something sounding like "don't touch any of this in more than a couple of lines at a time". Maybe you thought I sniped back, and hence didn't let you get to that point --if so, I am sorry--, but I personally would appreciate if you could do it now. To implement a complicated feature, you need to break down the implementation into a lot of patches to make it easy for review. People aren't going to start accepting your refactoring patches because you promise them that it'll be worth it in the long run. What you said is of course true for incremental changes; but not so much for architectural ones that by necessity result in large changes. Please take a look at the roadmap for FPC v3.0 here: http://mantis.freepascal.org/roadmap_page.php where it says "22 of 27 issue(s) resolved. Progress (81%).". Great. A lot of hardwork is being done and all those doing it are busy. But, where and how do you discuss things about the general direction, i.e. architecture questions? And the reason is, everyone is too busy to spend time discussing things that are not immediately relevant to a bug or a certain ancillary feature. -- Cheers, Adem ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
I'm probably not the best person to comment here, since I've already been blasted in the past for telling things like they are, but me personally, if I wanted to do something major with fpc, I'd not bother trying to get it integrated to the main branch, I'd spawn my own project, call it something else, and make it clear that it comes from the fpc main trunk. That would satisfy the open source requirements, and give me the ability to make whatever changes I thought would be worthwhile. Probably not the best approach, but it sure would make things easier on me. :) Of course, compilers aren't my strong suit, so in my case, the above doesn't apply, but just saying, if it were me, and I wanted to do what you're suggestin, that would be my approach. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
