"Manfred Nowak" <svv1999@hotmail.com> wrote...
> BCS wrote:
>
> [...]
>> as to the evaluation of the "wisper syntax" how about the following
> [...]
>
> Wohoo! Second strike. You are really clever!


And you, my friend, are quite foolish, trolling, or both.

Kris wrote:
> 
> So, what about atomicity? Does writefln() have some kind of an advantage over call-chaining, aka whisper notation? The answer is both yes and no. The notion that writefln() is atomic is only partly true ~ for one thing it is not synchronized. But that aside, it depends on what you want to call atomic. For instance:
[snip]
> or some variation upon that. You see what I'm getting at? The atomicty of writefln() is really in the eye of the beholder ... even assuming it were itself synchronized at the function level. This is, I imagine, why writefln() does not synchronize (at least, I doubt that it does, and you impled it doesn't).

I think it is atomic at the function level, though mostly as a side-effect.  Multiple successive calls to putchar are slow because each call has to lock the output stream to ensure stream integrity.  For this reason, writef locks the output stream at the outset and holds the lock until the call completes.  I believe this should provide call atomicity, though another implementation is not required to emulate this behavior.

> It is certainly why mango.io does not synchronize ~ would be just a waste of cycles, and is noted in the Stdout documentation.

Agreed.  Speculative locking in library code is generally pointless, as it rarely matches actual usage patterns.  The only exception IMO is access to any shared static data, as that is not typically something the user is aware of or can control externally.  This is the general thread-safety level of STL implementations.

>> Moreover,
>> writef and readf make it easier to specify things like formatting. Just add some
>> format args, and you can spitout hex output or binary just as easily as decimal.
> 
> Very true. This is why mango.io is a multi-level design. The whisper notation is intended to provide general purpose I/O for text and binary data. Mango.convert has all the printf() like facilities, which are then wrapped in a number of different ways for both classes and structs (the latter are great when you need to avoid the heap):
> 
> Sprint ~ binds a formatter to a char/wchar/dchar array.
> Format ~ binds a delegate-trio to a formatter.
> 
> The formatting is bound to the console in two alternate ways, so you can choose what feels comfortable:
> 
> Print ~ binds a formatter to the console
> Stdout ~ binds a formatter and a Whisper-writer to the console.
> 
> Additionally, mango.convert will *never*, itself, touch the heap. Never. From a throughput or server standpoint, that would be tantamount to criminal activity :-)

I have mixed feelings about OO-based formatted IO.  It can be quite nice in structured applications, but tends to be more complex in ad-hoc situations.  Still, Mango is quite a bit more flexible than writef and that it doesn't allocate memory is a huge bonus.  Personally, I'd like to have both options available.

> I'll just add that mango.io was built originally for high-throughput in a highly-threaded environment ~ t'was built very-much with threads in mind. The Phobos I/O at the time was not even close to being applicable for what was needed. And to this day it's still, ahh, uncohesive. Phobos is great for some folks. Mango is there for others, if they wish to use it.

Agreed.  While I think readf/writef is a great general purpose tool, it's Mango I'd use for serious work.  That said, my line of work is exactly what Mango was designed for so perhaps I'm a bit biased :-)


Sean

Some minor points:

"Sean Kelly" <sean@f4.ca> wrote...
>> It is certainly why mango.io does not synchronize ~ would be just a waste of cycles, and is noted in the Stdout documentation.
>
> Agreed.  Speculative locking in library code is generally pointless, as it rarely matches actual usage patterns.  The only exception IMO is access to any shared static data, as that is not typically something the user is aware of or can control externally.  This is the general thread-safety level of STL implementations.

I've always felt that writable globals were terribly poor-form in threaded environments. Encapsulation allows one to eliminate such things quite nicely ~ something that D truly excels at by providing aggregate-style structs. But, I suppose there are always limits?


>> Sprint ~ binds a formatter to a char/wchar/dchar array. Format ~ binds a delegate-trio to a formatter.
>>
>> The formatting is bound to the console in two alternate ways, so you can choose what feels comfortable:
>>
>> Print ~ binds a formatter to the console
>> Stdout ~ binds a formatter and a Whisper-writer to the console.
>>
>> Additionally, mango.convert will *never*, itself, touch the heap. Never. From a throughput or server standpoint, that would be tantamount to criminal activity :-)
>
> I have mixed feelings about OO-based formatted IO.  It can be quite nice in structured applications, but tends to be more complex in ad-hoc situations.  Still, Mango is quite a bit more flexible than writef and that it doesn't allocate memory is a huge bonus.  Personally, I'd like to have both options available.

Agreed on all counts. I'd like to clarify that mango.convert does have struct-based Format and Sprint ~ you just place them on the stack and call the ctor() function. There's an example here, at line 90: http://trac.dsource.org/projects/mango/browser/trunk/mango/convert/Rfc1123.d

>  Still, Mango is quite a bit more flexible than writef and that it doesn't
> allocate memory is a huge bonus.  Personally, I'd like to have both
> options available.

I can't see where writef allocates memory - though I haven't looked all that
hard. Can someone point out what use cases allocate?
Also what flexibility are you referring to?

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dnftfm$3mv$1@digitaldaemon.com...
>>  Still, Mango is quite a bit more flexible than writef and that it
>> doesn't allocate memory is a huge bonus.  Personally, I'd like to have
>> both options available.
>
> I can't see where writef allocates memory - though I haven't looked all that hard. Can someone point out what use cases allocate?

Ben; I don't think Sean actually said that writef() did? I can point you to some areas that do though: just did a grep through phobos for 'new' and the toString() functions are notable in this respect ~ these are often used instead of sprintf() to get good throughput where sprintf() might be considered overkill? Adding an HTTP header comes to mind? These toString() functions always tend to allocate from the heap, as does the date formatter ~ again something that's used heavily in some kinds of application.

There's one notable exception in toString() where it does not allocate. Here's the code:

/// ditto
char[] toString(uint u)
{   char[uint.sizeof * 3] buffer = void;
    int ndigits;
    char c;
    char[] result;

    ndigits = 0;
    if (u < 10)
 // Avoid storage allocation for simple stuff
 result = digits[u .. u + 1];
 [snip]
  return result;
}

See that ~ it returns a writable reference to the shared digit-map. Seems like a good reason to have read-only arrays?

These are all things that can be easily fixed.

"Kris" <fu@bar.com> wrote in message news:dng0ea$66g$1@digitaldaemon.com...
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dnftfm$3mv$1@digitaldaemon.com...
>>>  Still, Mango is quite a bit more flexible than writef and that it
>>> doesn't allocate memory is a huge bonus.  Personally, I'd like to have
>>> both options available.
>>
>> I can't see where writef allocates memory - though I haven't looked all that hard. Can someone point out what use cases allocate?
>
> Ben; I don't think Sean actually said that writef() did?

Oh - I thought "is a huge bonus" was meant to contrast with writef.

> I can point you to some areas that do though: just did a grep through phobos for 'new' and the toString() functions are notable in this respect ~ these are often used instead of sprintf() to get good throughput where sprintf() might be considered overkill? Adding an HTTP header comes to mind? These toString() functions always tend to allocate from the heap, as does the date formatter ~ again something that's used heavily in some kinds of application.

I agree toString typically allocates memory. I don't really follow the comparison with sprintf and adding HTTP headers, though.

If the date formatter allocates memory too often then I suggestion someone propose and/or submit some updates to the date formatter to improve it. That should be independent of the I/O system or writef/whispering. For example I vaguely remember suggesting various functions that return strings be passed an optional char[] to fill (somewhat like std.stream.Stream.readLine does).

> There's one notable exception in toString() where it does not allocate. Here's the code:
>
> /// ditto
> char[] toString(uint u)
> {   char[uint.sizeof * 3] buffer = void;
>    int ndigits;
>    char c;
>    char[] result;
>
>    ndigits = 0;
>    if (u < 10)
> // Avoid storage allocation for simple stuff
> result = digits[u .. u + 1];
> [snip]
>  return result;
> }
>
> See that ~ it returns a writable reference to the shared digit-map. Seems like a good reason to have read-only arrays?

oh no - here we go... readonly arrays again. ;-)

> These are all things that can be easily fixed.

ok. I'm sure people would be willing to listen to proposals about making toString (or toString-like functions) more efficient. I think that came up a few times during the COW/const/in-place threads.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote
>> I can point you to some areas that do though: just did a grep through phobos for 'new' and the toString() functions are notable in this respect ~ these are often used instead of sprintf() to get good throughput where sprintf() might be considered overkill? Adding an HTTP header comes to mind? These toString() functions always tend to allocate from the heap, as does the date formatter ~ again something that's used heavily in some kinds of application.
>
> I agree toString typically allocates memory. I don't really follow the comparison with sprintf

Simply noted that one is often used in place of the other. Both sprintf() and toString() are part of a "package" to convert from 'type' to string: number to string, time to string, and so one. If one needed, for example, to convert a number to a string then one would use either sprintf() or toString(). They're related by "intent" or usage. Was the implication otherwise?


> oh no - here we go... readonly arrays again. ;-)

Nope ... but then, do you find it acceptable the D library returns access to shared internals? ;-)

Kris wrote:

[something]

People living in cages always argue that free people are foolish, because the practice of living in a cage shows that after going more than five steps in one direction you hit the wall.

-manfred

(*cough*) ROFL!

I really thought you had no sense of humour, manfred. But it's clear you're a total comedienne :-D

BTW: you look foolish partly because of your blatant and outright gloating over something that (a) didn't hold any water to begin with and (b) was subsequently retracted as such. You went out on a limb in order to pour scorn and detriment upon others, and then promptly fell out of the tree. If you hadn't done that, you might have saved yourself some grief.

Thus, you really should try to take some responsibility and some humility upon yourself; heck, you *could* even note that "perhaps you made a mistake"?  That might restore a bit of faith in your intent?

We all make mistakes; I make 'em all the time. This post is probably another one.

Good luck!



"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:Xns9729381587AC6svv1999hotmailcom@63.105.9.61...
> Kris wrote:
>
> [something]
>
> People living in cages always argue that free people are foolish, because the practice of living in a cage shows that after going more than five steps in one direction you hit the wall.
>
> -manfred

On Sun, 11 Dec 2005 04:30:47 +0000 (UTC), Manfred Nowak wrote:

> Kris wrote:
> 
> [something]
> 
> People living in cages always argue that free people are foolish, because the practice of living in a cage shows that after going more than five steps in one direction you hit the wall.
> 
> -manfred

I assume by this that you hit a wall, Manfred.

No worries; doesn't matter. We all make mistakes and its good for our souls when we admit it publicly. You had me going there for moment; I was almost about to add you to my troll-file.


What does irk me though is that most of this pointless discussion could have been avoided just by Walter clearly stating his intention for D in this matter.

-- 
Derek Parnell
Melbourne, Australia
11/12/2005 4:50:33 PM