From: bc@freeuk.com   
      
   On 24/10/2025 18:35, David Brown wrote:   
   > On 24/10/2025 15:27, bart wrote:   
   >> On 24/10/2025 03:00, Keith Thompson wrote:   
   >>> bart  writes:   
   >>>> On 24/10/2025 00:04, Keith Thompson wrote:   
   >>>>> bart  writes:   
   >>> [...]   
   >>>   
   >>> I note that you've ignored the vast majority of my previous article.   
   >>   
   >> I've noted it, but chose not to reply. You have a point of view and   
   >> attitude which I don't share.   
   >>   
   >> Mainly that you don't care how complicated a program for even a simple   
   >> task is, and how laborious and OS-dependent its build process is, so   
   >> long as it (eventually) works.   
   >>   
   >> That it favours your own OS, leaving users of other to have to jump   
   >> through extra hoops, doesn't appear to bother you.   
   >>   
   >   
   > Why would someone care what how someone else writes their code, or what   
   > it does, or what systems it runs on?  They guy who wrote cdecl gets to   
   > choose exactly how he wants to write it, and what systems it supports.   
   > We others get it for free - we can use it if we like and it if it suits   
   > our needs.  But neither Keith nor anyone else paid that guy to do the   
   > work, or contributed anything to the task, and we have no right to judge   
   > what he choose to do, or how he choose to do it.   
      
   This a curious argument: it's free software so you don't care in the   
   slightest how efficient it is or how user-friendly it might be to build?   
      
   This is a program that reads lines of text from the terminal and   
   translates them into another line of text. THAT needs thirty thousand   
   lines of configure script?! And that's even before you start compiling   
   the program itself.   
      
   I'm thinking of making available some software that does even less, but   
   wrap enough extra and POINTLESS levels complexity around that you'd need   
   to lease time on a super-computer to build it. But the software is free   
   so that makes it alright?   
      
   >   
   >>   
   >>   
   >> Well I built cdecl too, under WSL. Jesus, that looked a lot of work!   
   >   
   > I have no experience with WSL, so I can't comment on the effort there.   
      
   I was talking about all the stuff scrolling endlessly up to the screen   
   for a minute and a half while running the configure script and then   
   compiling the modules.   
      
   >> That program is 2.8 MB (10 times the size of my C compiler).   
   >   
   > First, as usual, nobody cares about a couple of megabytes.  Secondly, if   
   > you /do/ care, then you might do at least a /tiny/ bit of investigation.   
   >   First, run "strip" on it to remove debugging symbols - now it is a bit   
   > over 600 KB.  By running "strings" on it, I can see that about 100 KB is   
   > strings - messages, rules, types, keywords, etc.   
      
   If I was directly building it myself, then I would use -s with gcc. But   
   since the process is automatic via makefiles, I assumed it would give me   
   a working, production version, not a version needing to be debugged!   
      
   >> I guess you don't care about that either. But surely, you must be   
   >> curious about WHY it is so big? You must surely know, with your   
   >> decades of experience, that this is 100 times bigger than necessary   
   >> for such a task?   
   >   
   > Were you not curious, or did you just pull random sizes out of thin air   
   > as an excuse to complain again about any program written by anyone else   
   > but you?   
      
   I have a version of Algol68 Genie which is nearly 4MB on Windows.   
   Apparently the Linux version is 1-2MB only. You may recall this coming   
   up on comp.lang.c.   
      
   The point is, this is an implementation of an entire language, not just   
   printing some type info. And maybe it includes debugging info, and the   
   true size is even smaller; who knows?   
      
   While Tiny C, even if you don't care for its abilities, still HAS to be   
   able to decode full C99 type declarations. So understanding such types   
   has to be accomplished within its 200KB size.   
   > It is entirely possible that your little alternative is a useful program   
   > and does what you personally want and need with a smaller executable.   
   > But cdecl does a great deal more,   
      
   CDECL translates a single C type specification into linear LTR form. Or   
   vice versa. That's what nearly everyone needs it for, and why it exists.   
   Why, what other stuff does it do?   
      
   So, yes, anyone with an inquiring mind can form an idea of how much code   
   might be needed for such a task, and how it ought to compare with a   
   complete language implementations.   
      
   In fact, people have posted algorithms here for doing exactly the same.   
   I don't recall that they took tens of thousands of lines to describe.   
      
   > doing things that other people need   
   > and want (like handling C++ declarations - surely 100 times more effort   
   > than handling C declarations, especially the limited older standards you   
   > use).   
      
   So, it's a hundred times bigger than necessary due to C++. That explains   
   that then. (Sorry, 20 times bigger because whoever provided the build   
   system decided it should include debug info to make it 5 times as big   
   for no reason.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)