From: david.brown@hesbynett.no
On 24/10/2025 20:50, bart wrote:
> 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?
>
If I find that installing or using software is difficult, then I would
look elsewhere for alternatives that worked better for me. But unless
the software author is doing some kind of harm to other people (such as
knowingly or intentionally giving incorrect results from his program, or
violating other people's copyrights or "stealing" their work), who am I
to judge how he choices to write his software? He makes his own
decisions on how to write it, and I make my own decisions on whether or
not to use it. Equally, as he has chosen to publish the software under
the GPL, he has no right to judge or care about how I use the software.
Of course people can have opinions, and express them, but that's very
different from having some sort of requirement to be bothered about
something we don't feel is as good as it could be. (And in this case, I
don't see that the software is too big, given what it does, and I don't
see the build process as unduly difficult, given the author's
preferences, interests and aims. And no doubt someone will publish an
easy to install Windows build of it sooner or later.)
> 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?
>
Feel free do to that if you like. If it is useful enough, people might
use it - if it is not, then they won't. No one is going to complain if
you publish such software.
>>
>>>
>>>
>>> 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.
>
You are getting worked up about some text output that scrolled
"endlessly" for a minute and a half? (Do you spot the exaggeration
here?) Of course it is less of an issue for me - "./configure" took a
mere 10 seconds on my ten year old machine. But even at a minute and a
half, it's just a task that the computer runs, once, and it is done
without effort. Try relaxing a little more, and perhaps use that minute
and a half to stretch your legs or drink some coffee, rather than to
build up a pointless fury.
>>> 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!
>
Actually, on closer checking (not because /I/ care, but because /you/
apparently care) it was not debugging information, but all the linking
and symbolic information that is a normal part of elf format files when
they are built (allowing for incremental linking, using the files as
static libraries for other programs, tracing the programs,
fault-finding, etc.). Sometimes build processes strip these as part of
their build or "make install" process (indeed there is a "make
install-strip" option). Usually it doesn't matter much on *nix systems
- after all, the extra disk space has a cost of about a microdollar and
the OS won't even bother reading that part of the elf file into ram when
running the program.
>> 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?
>
RTFM.
> 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
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
