In our previous episode, Graeme Geldenhuys said: > OK, so once again it is proven that Unicode is just not "sexy" enough > for the core team, so it will stay stagnant for a few more years.
No. Simply getting older. > That's unless a member ignores all discussions and does his own thing [or > gets paid for the job]. As Florian likes to says so often, whoever > implements it decides. Unfortunately that courtesy is not extended to > non-members, because what good is a patch [of such magnitude and effort] > with no chance of ever being committed. So we are at the mercy of the FPC > gods. No. Core members have some freedom in doing their own thing because of a proven track record, and the knowledge they will generally see a feature or a development to the end. And indeed, external patches and committers first need to prove themselves. But there are many precedents (like Giuliano doing the resource strings), and committers are being added all the time. There probably near an handful of committers who are newer to the project than you. More if you count db-core. But then you have to work within the team, and respect some traditions and sentiments. And if there is one thing I hope others get from this discussion is that you and Martin never got that. But at least Martin _tried_ during the 2.2.2 tcomponent rewrite. Same goes for Mr. Schnell. > Many of use non-core developers have given our input with multiple > solutions, to try and help the private discussions along. I haven't seen actual input. Mostly I only have seen some simplistic outlines of radical new solutions that weren't fleshed out enough to fill the backside of a beercoaster. And most of them were thrown in together with some anti-Delphi sentiment. I have never even seen serious attempts from each one of you (like categorizing the objections, adapting to it, keeping documentation or points lists). (for the unicode part at least. The 2.2.2 work by Martin was certainly valued) > But I guess all of us are not knowledgeable enough people. I wouldn't say that. But the two of you have the problem you always choose radical solutions, don't have a history of working on core, never done major projects inside > What a nice F*** Y** to the community. So basically you just go on bullying in the maillists till you get a carte blanche up front. Well, IT WON'T HAPPEN. I dare you to bring up one piece of proposal that is detailed, consistent, and mustn't be extracted from some maillist discussion, and that shows some signs that criticism on it was processed. > Well, let me just say that the idea of two RTL's is rather ridiculous > too!! It was my idea actually, to repair the worst problem with delphi compatibility; the fact that Delphi broke backwards compatibility. But I abandonned it, because there seemed to be little support, and people kept believing an overload here and there would solve the problem. IOW there is no acceptance of the fact that the default stringtype is much more a global change than a per unit change. So in spring I gave up, and am now in favour of a 100% delphi compatible utf16 solution, compatibility break included. (maintain 2.6.x a bit longer though, if people care) > You guys keep bitching about not having enough developers, so how > on earth do you think you are going to be able to maintain developing > two RTL's, patching too RTL's when bugs are reported Again you show your lack of knowledge. It _was_ about two releases built for every target from a single codebase. One 1-byte as default, one 2-byte. I/we hoped we could polish away the different 1-byte codepages away in the RTL initialization. (so the 1-byte RTL could be used for both the old Delphi 1-byte as one where it is hard utf8. There are some problems with stdio there though) But that means one codebase compiled twice (once for 1-byte, one for twobyte), only with different default types, so that inheriting methods with string types keep working. > inform the public to remember to mention which RTL they are using when > reporting bugs, keeps those two RTL's in sync over time etc. It is that, or rewrite it. Note that originally the two RTL solution was a temporary solution, to allow Lazarus to gradually change from manual to compiler supported unicode types. (and thus not stick to an old release for an extended period of time). I then still assumed that over time on windows the 1-byte one would disappear and on *nix the two byte one. Only when protests came, it became somewhat permanent. > Yeah, it seams you guys are sometimes not to knowledgeable either. All > you are going to do is create more work for yourselves. But hey, who are > we to state the obvious. This message is a perfect example how you let yourself guide by sentiment. You seem to have started to believe your own advocatism, and think it is evil core that is holding you back, rather than the fact that doing a few minor bugs and spelling corrections in the docs will not give you carte blanche up front to outline major compiler features that will haunt the project for ten+ years. And everytime that is pointed out to you, and are advised to start working, you mumble something non committal about the great (but irrelevant) work you say you do outside the FPC/Lazarus project, and keep numb for a while. Of course after a while you restart with your usual arrogance. I've been timing it, and usually the period is about 4 months. > Anyway, I can see where this thread is heading... just another waist of > time. So I'll stop here. For 4 months. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
