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.

Walter Bright schrieb am 2006-04-08:
> 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

> 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

> Also, could you post the full, exact command you used? Perhaps I have botched that up, too.

$ dmd a.d -ofx
gcc a.o -o x -lphobos -lpthread -lm -Xlinker -L/opt/dmd/dmd/lib
$ dmd a.d -ofy -L--gc-sections
gcc a.o -o y -lphobos -lpthread -lm -Xlinker -L/opt/dmd/dmd/lib -Xlinker --gc-sections
$ ls -sh1 x y
212K x
136K y
$ objdump -t y | awk "{ print (\$4); }" | grep "6string" | sed 's/\.gnu\.linkonce\.t//' | sort -u
_D3std6string3cmpFAaAaZi
_D3std6string4findFAawZi
_D3std6string6columnFAaiZi
_D3std6string7iswhiteFwZi
_D3std6string8toStringFkZAa
_D3std6string9inPatternFwAaZi
$ gcc --version
gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
$ ld --version
GNU ld version 2.16.1

Thomas

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