Walter Bright wrote:
> kris wrote:
I see you snipped the questions about trying to understand the need for
Ares? I thought those were realistic, reasonable, and pertinent
questions in the search to understand why you can't understand Ares exists.
Are they just not important enough to warrant attention? Here they are
again:
<repost>
Kris: Why do you think Ares exists anyway?
Walter: I'm trying to understand.
Kris: Ah. That makes some sense now ~ so, you're saying you don't see
any need for a better library? That you're trying to understand what
such a need might be?
</repost>
Those are important questions, since they'll help clarify the apparently
vast divide between what you think of as a library, and what I do. I
doubt very much that I'm alone upon that sea of confusion. If I were,
Ares would not exist. I feel its important for you to be open about your
perspective on "alternate" libraries vs Phobos ~ after all, there's a
lot of people putting a lot of effort into making those available ...
BTW: the phrase "better library" is used there because that what Ares
was designed to be. I now realise that you may have interpreted that as
some kind of an "insult" to Phobos. Many pardons.
> For printf, the actual coupling problem is:
>
> 1) It pulls in floating point formatting code. This turns out to not be
> correct.
Mea culpa; easy mistake to make when there's nothing else referencing
FP, wouldn't you say? Who might have guessed it were std.string instead
of printf() ?
> 2) It's bloated. The bloat turns out to be 4K code - a big problem on an
> 8 bit machine to be sure, but not on a 32 bit one.
> 3) It pulls in the entire C I/O system. This turns out to also not be
> correct. It pulls in a reasonable portion of it.
Smoke & mirrors: If the C IO were not already leaking in via a number of
other holes in the boat, then the reference within object.d would be
solely responsible for pulling in everything that printf references.
This does amount to a rather large majority of the C IO subsystem, as
you know. Yes, you've made it perfectly clear that you have no interest
in even trying to see any relationship therein.
> 4) It should be replaceable/hookable. Yes, it is.
By stubbing out dependencies? That's not what I'd call good design. If
you think it is, then we can agree to disagree.
> On the other hand, the advantages of having a print in Object are:
>
> 1) Every object can be relied upon to have some sort of print method.
If that has such an immeasurable value, why is it not used more? I
submit this particular "reason to exist" is of questionable merit. D
deserves better debugging support than object.print() ~ there's a decent
logging package in mango.log ... doesn't even allocate memory.
> 2) Substituting a toString() is problematic because it usually requires
> extra allocation and hence double buffering - so most I/O systems avoid
> such designs.
I see. The type of trivial, lazy, and inflexible debugging-output
represented by object.print() needs to avoid double buffering at all costs?
> Also, the print is often used for debugging, and having it
> be forced to use an allocation can upset what one is trying to debug -
> by causing a gc collection cycle, for example.
Pardon me; std.string is the one of the worst offenders in terms of
wasteful memory allocation that I've seen in decades. It appears that
every single toString() method allocates from the heap, Walter. I would
have mentioned this before, but we couldn't even get past the introduction.
To use your own words "Also, the print is often used for debugging, and
having it be forced to use an allocation can upset what one is trying to
debug - by causing a gc collection cycle, for example.".
I'm sure you realise that print() method invokes toString(), quite
possibly resulting in calls to std.string.toString()? Which does wholly
unecessary memory allocations? Pardon me, but std.string is hardly the
shining light to be held aloft in such matters.
> 3) It being synchronized with C's IO means it doesn't screw up when
> mixed with normal IO code.
That's really stretching: you don't need printf() to synchronize with
normal IO. Use one of the lower layers instead, since none of the
formatting options are actually used ~ as you know. This is a good
example of using an "expensive" library function where a "less costly"
one would suffice perfectly well. Again, the functionality is of
questionable value anyway.
> No, I did not ignore it. I don't feel it's productive to rewrite the
> functions in std.string in each module. std.string is not a burdensome
> piece of code.
It is most certainly burdensome, Walter. Allocating memory is one of the
most expensive things one can do in this realm ~ std.string does it with
gay abandon. How does that fit with your position?
> I'll agree with you that pointless and gratuitous coupling should be
> avoided, but that is not the case with the two examples we're discussing.
I submit that printf() within object.d is gratuitous and almost entirely
pointless. And not even used appropriately. There's fair reason why one
won't see that kind of appendage in mainstream designs.
The coupling to std.string is indeed pulling in unwarranted FP support,
so there is clearly an issue there. Std.string also happens to allocate
memory for each toString() method (looks like all of them do?). That is
harldy wise to do at a low level, especially where it can be easily
avoided. You spelt out some reasons to avoid that yourself, vis-a-vis
allocation whilst debugging.
>
>> Looking again at your recital of adamant examples, I'm rather sorry,
>> and entirely disappointed that's all you got from this exchange.
>
>
> I used the word adamant because you haven't acknowledged that I've
> addressed the underlying __fltused and std.uni issues, you haven't
> acknowledged that they are solvable compiler issues rather than library
> design issues, and just keep pushing the same solution.
Sigh
> I shall reiterate that what I was doing was addressing what the
> underlying issue with coupling was. If those can be successfully
> addressed, then there is no coupling issue.
I'm very happy you found some problems and were able to rectify them.
That's great! But that doesn't, in any shape or form, mean there's no
coupling issues. You think these are the only examples? You feel it's OK
for std.string to be allocating from the heap, when it can easily be
avoided instead? That it's cool for low level language-support code
(like object.d) to be invoking the GC where it could easily be avoided?
I don't. But, I'd be perfectly content if you were to leave it just as it is

Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-06:
>> Although there is a lot of code in std.string, unreferenced free
>> functions in it should be discarded by the linker. A check of the
>> generated .map file should verify this - it is certainly supposed to
>> work that way.
>
> That's not what is happening on Linux:
Hmm. I tried --gc-symbols, which is supposed to do it, but nothing
happens (even when I try it on C++ files). Can you try --gc-symbols on
your system?

Walter Bright schrieb am 2006-04-07:
> Thomas Kuehne wrote:
>> Walter Bright schrieb am 2006-04-06:
>>> Although there is a lot of code in std.string, unreferenced free
>>> functions in it should be discarded by the linker. A check of the
>>> generated .map file should verify this - it is certainly supposed to
>>> work that way.
>>
>> That's not what is happening on Linux:
>
> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing
> happens (even when I try it on C++ files). Can you try --gc-symbols on
> your system?
doesn't work: --gc-symbols
seems to work: --gc-sections
Thomas

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Walter Bright schrieb am 2006-04-07:
>> Thomas Kuehne wrote:
>>> Walter Bright schrieb am 2006-04-06:
>>>> Although there is a lot of code in std.string, unreferenced free
>>>> functions in it should be discarded by the linker. A check of the
>>>> generated .map file should verify this - it is certainly supposed to
>>>> work that way.
>>> That's not what is happening on Linux:
>> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing
>> happens (even when I try it on C++ files). Can you try --gc-symbols on
>> your system?
>
> doesn't work: --gc-symbols
> seems to work: --gc-sections
Right, I typo'd it. However, --gc-sections doesn't work on my system -
everything is still linked in. But it does on yours - not all of
std.string is linked in?

Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-07:
>> Thomas Kuehne wrote:
>>> Walter Bright schrieb am 2006-04-06:
>>>> Although there is a lot of code in std.string, unreferenced free
>>>> functions in it should be discarded by the linker. A check of the
>>>> generated .map file should verify this - it is certainly supposed to
>>>> work that way.
>>> That's not what is happening on Linux:
>> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing
>> happens (even when I try it on C++ files). Can you try --gc-symbols on
>> your system?
>
> doesn't work: --gc-symbols
> seems to work: --gc-sections
Also, could you post the full, exact command you used? Perhaps I have
botched that up, too.

Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-08:
>> Right, I typo'd it. However, --gc-sections doesn't work on my system -
>> everything is still linked in. But it does on yours - not all of
>> std.string is linked in?
>
> Correct
This is good news. The documentation on --gc-sections is pretty sparse,
I wasn't sure it was intended to do that, and it does nothing on my system.
> $ ld --version
> GNU ld version 2.16.1
I'm using ld 2.13. The release notes say that --gc-sections works for
it, but I guess it doesn't actually :-(. Anyhow, it is good news that it
is working on your system. I'll modify dmd to pass the --gc-sections
command through to the linker, and I'll not worry about older ld's
ignoring the switch.
Thanks for helping out with this.

In article <e17um0$1hts$1@digitaldaemon.com>, Walter Bright says...
>
>Thomas Kuehne wrote:
>> Walter Bright schrieb am 2006-04-08:
>>> Right, I typo'd it. However, --gc-sections doesn't work on my system -
>>> everything is still linked in. But it does on yours - not all of
>>> std.string is linked in?
>>
>> Correct
>
>This is good news. The documentation on --gc-sections is pretty sparse,
>I wasn't sure it was intended to do that, and it does nothing on my system.
>
>> $ ld --version
>> GNU ld version 2.16.1
>
>I'm using ld 2.13. The release notes say that --gc-sections works for
>it, but I guess it doesn't actually :-(. Anyhow, it is good news that it
>is working on your system. I'll modify dmd to pass the --gc-sections
>command through to the linker, and I'll not worry about older ld's
>ignoring the switch.
>
>Thanks for helping out with this.
Might want to take a look at the gcc '-s' switch as well. Man page (under gcc
linking options):
-s Remove all symbol table and relocation information from the executable.
It dramatically reduces the size of the executables on my system. Don't have
much experience with it yet though.
- Dave

Sean Kelly wrote:
> Walter Bright wrote:
>>
>> BTW, internal\dmain2.d also uses printf to print out an error message
>> relating to any uncaught exceptions.
>
> Ares currently uses fprintf for this purpose, which is essentially the
> same thing. And as you say, it would be easy enough to hook the
> function if this behavior isn't desirable.
>
> I'm glad the compiler issues came to light however. I don't suppose
> this will have any impact on the template code generation problem in
> libraries?
>
>
> Sean
Sean - could you point me to some links or post some example code on this?
Thanks,
- Dave

Dave wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>>
>>> BTW, internal\dmain2.d also uses printf to print out an error message
>>> relating to any uncaught exceptions.
>>
>> Ares currently uses fprintf for this purpose, which is essentially the
>> same thing. And as you say, it would be easy enough to hook the
>> function if this behavior isn't desirable.
>>
>> I'm glad the compiler issues came to light however. I don't suppose
>> this will have any impact on the template code generation problem in
>> libraries?
>
> Sean - could you point me to some links or post some example code on this?
http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d
See the "catch" blocks near the end of the file.
Sean