Milan Jurik <[email protected]> wrote: > > You may be able to agree with me on better thandards than the ones I > > currently > > use but you will not succeed to let me agree on inferior standards. > > > > Well, I do not consider ANSI C and other requirements sent by James > Carlson as "inferior". Which is the basic of our disagreement probably. > You can consider ON gate "C style" as not ideal but it is based on years > of experience of many contributors.
>From your wording, it seems that that you just do not understand me and that you simply missunderstand me because you did never look at my code. All my code makes advantages from ANSI C, most of the code in ON however does not make advantage from ANSI C. It is up to you top learn that you get a benefit from what I offer. What I offer is based on at least as many years of experiences as the code in ON. My code however has the advantage that I do update _all_ my code every time I see a way to make things better. This is the major flaw in the code in ON. A lot of the code in ON has not been touched since more than 10 years and thus does not include the experience you are talking about. > I heard several complains about that AST code was included to ON gate. I > heard the reasons from the responsible team. For now there is not real > benefit for it, maybe there will be some in future. But the framework > was included to keep large portion of source code in sync with upstream. > What you are proposing it is to include your large own framework and > some files where upstream of these files are not changed so frequently > as it is in case of AST tools. It is not comparable. I am not going to introduce pitfalls into my code just in order to make a single person happy who did not even look at it. I offer a significant amount of code that is well maintained. The only way to keep a large amount of code in sync with the maintained source is to keep it the way it is maintained. And please note that while AST replaces nearly everything from libc, my development model is to carefully add code to the existing base of the various OS platforms. > I participated on design for portability of one large and complex tools > years ago. I agree it is beneficial to maintain it in many cases. But > not in this case. Maintaining "multiplatfrom" implementation of > strnlen() is not useful at all. Sorry. And these days I do not see "K&R > C" and maintaining own set of header files with system definitions as > good for multiplatform support. Nor short names of variables. Sorry. We are not talking about strnlen() here but about a lot of code that I maintain. This is code that I have written from scratch and this is also code that Sun/Oracle is no longer willing to maintain and that I now maintain for iterested people. If you don't understand this, you are probably the wrong person to talk to. If you just like to take 5 lines of code from me, I recommend you that you take the 5 lines and add you own build framework around it. If you like to take more than half a million lines of code, you better don't change it and take it the way it is maintained. > > I am trying to start a collaboration with (formerly) Sun now Orcale since a > > long time. It is up to you to benefit from my offer. > > > > No, I am not ready to spend my own time to port your code to ON gate. I > could sponsor some of these contributions if somebody is willing to do > such thing (like sign SCA or how it is called today, including you, of > course, write PSARC if needed, prepare "hg export" based on current ON > gate, do the testing). Even sponsorship of it would take significant > portion of my time and I am not paid by the company for porting your > stuff to ON gate. If you like me to help you with your work after Sun did ignore my offers for 5 years, you would first need do the work to verify interest and to get the needed credibility. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
