"Paul A. Rombouts" <[EMAIL PROTECTED]> writes:
> > 1) Some changes will definitely not be included.
> >
> > These are for example the changes that stop it compiling on anything
> > except Linux.
...
> Strange that you mention perl in the list of extra programs that are required,
> because you use it yourself in your Makefiles. (But I see your point, I'll
> change the Makefile so that it will also run if perl is missing.)
It is a small difference, but easy to make and loses nothing.
> I've explicitly warned people that you need GNU tools to compile the patched
> code.
> There is no such thing as absolute portability, you can only be portable to a
> certain degree. GNU portability is all I strive for, because I simply don't have
> any intention of running my code on any other system.
My target for portability is to not use features that I know or think
to be of limited availability (like GNU extensions). I also reduce
the dependence on advanced features in Makefiles or source files when
people tell me that it fails to compile. This is why some of my
Makefiles and source code seem "primitive".
> (On the other hand, I
> don't want be to restricted to Linux, so if anyone detects a change that can
> only run on Linux, but not on another GNU system, I'd appreciate it very much
> if that was pointed out to me.)
I may be missing something, but there are only two GNU systems aren't
there; GNU/Linux and the Hurd? (No arguments about Linux not being a
GNU system please).
> I don't like the way that striving for portability restricts you to a limited
> set of common tools. Some GNU extensions make great sense to me, and enable
> solutions that are (much) more elegant. And finding elegant solutions is for me
> one of the most rewarding aspects of coding. After all, I'm hacking WWWOFFLE to
> scratch my own itch; nobody is paying me to do it.
Nobody pays me for it either, I also do it for the enjoyment and the
knowledge that other people like and use my programs. One of the
prices for this is to have to use some non-elegant features to
work-around other UNIX systems. This addds to the fun and I have
learnt a lot about writing portable code.
> Some of the macros I wrote could be replaced by functions. Some are butt ugly.
> These are valid criticisms. But I fail to see what makes
>
> char *copy=malloc(strlen(string)+1);
> strcpy(copy,string);
>
> so much more desirable than
>
> char *copy=strdup(string);
This is the point (problem) about different coding styles, we will
never agree. You disagree with the code above like I use and I
disagree about (for example) the strcmp_litbeg() macro that you have
introduced. I don't see why you need to use a separate macro
strcmp_litbeg(foo,"bar")
rather than a more optimal
strncmp(foo,"bar",sizeof("bar")-1)
which is only slightly better than
strncmp(foo,"bar",3)
which is what I use.
> > 2) Some changes should be included.
> >
> > These are usually obvious to spot. Some are spelling mistakes in
> > source code or obvious programming errors. Anything that is obvious
> > in this sense should be included, the problem is finding it.
>
> I've reported some of these small errors to you in the past. The problem is that
> it takes time to write neat little e-mails reporting every little error
> separately, time that I would rather spend coding.
I believe that all of these have been included in WWWOFFLE. Are there
any that you have reported that I ignored?
> > 3) Some changes that might be included.
...
> I never expected that my patch or any sizeable part of it would end up in the
> main WWWOFFLE code, this was not my reason for publishing it. The changes that
> I've made to the WWWOFFLE code were simply to satisfy my own personal needs.
> And I am pleased with the result: I find that the modified version runs
> much better and is much more useful than the original version.
I understood that you did not intend me to include the whole thing. I
was only answering the question that was asked of me; which was if I
would be including it.
> I've succeeded in getting a few features into the main code: the
> request-redirection option, the CGI-interface and unlimited number of *'s in
> patterns are the most important. But overall, my experience with this has been a
> negative one: for instance I put a lot of work into making the patch for the
> CGI-interface, but the way it ended up in the main code was not very useful to
> me.
Is there anything specific about your CGI patch that I included (with
some changes) that you dislike? I thought that there was only one
part of the functionality that I removed (the Location header built-in
redirection).
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.7/user.html
