Bugs fixed.

http://www.digitalmars.com/d/changelog.html

Walter wrote:

> Bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html

(http://www.digitalmars.com/d/changelog.html#new0128, which says:)

> Ben Hinkle's update for stream.d and std_stream.html: As discussed
> in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26073
> scanf and vscanf have been modified and renamed to readf and vreadf
> (with doc updates, too).

Is there any chance of getting this "vreadf" implementation into a
stand-alone unformat implementation instead ? Or wasn't the addition
of std.string.unformat a good addition to the old std.string.format ?

i.e. the std.unformat.unFormat function:
void unFormat( dchar delegate() getc, dchar delegate(dchar) ungetc,
              TypeInfo[] arguments, va_list argptr);

That would make the new functions possible to add to std.stdio as well,
as in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/21692
or will that module (stdio) be deprecated now with the new std.stream ?

--anders

Walter wrote:
> Bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368

If urgency is really your only doubt, then here's why I feel it should be just put in right now:

1. Once a fix is written, checking it in is quick and straightforward, not really something worth the time and effort of questioning the urgency of.

2. Putting in fixes as and when they're written is a positive sign for the public image.  Nobody likes to see a programming language, library or application having poor standards of maintenance.

3. Gratuitously holding back accepting contributions defeats half the point of a project being open source.

4. Such a trivial action takes little more time to do straight away than to add to a todo list, only to be finally done some time in the indefinite future.

5. If a fix isn't checked in on a good timescale, it can become out of date.  Consequently it will take a bit of work to update the patch to work with the newer version, which may have changed divergently.

6. As such, it's getting even sillier than the points that were raised here a while back:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/7199

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

> Is there any chance of getting this "vreadf" implementation into a stand-alone unformat implementation instead ? Or wasn't the addition of std.string.unformat a good addition to the old std.string.format ?
>
> i.e. the std.unformat.unFormat function:
> void unFormat( dchar delegate() getc, dchar delegate(dchar) ungetc,
>               TypeInfo[] arguments, va_list argptr);
>
> That would make the new functions possible to add to std.stdio as well, as in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/21692

Sounds reasonable. The changes I made to std.stream to make vreadf were actually pretty small. I didn't go as far as Sean did with supporting infs, nans, bits and scansets. Also I tried to make sure vreadf didn't allocate memory unless it really needed to. I kindof figured that since Walter wrote doFormat/writef that he'd do undoFormat/readf if he thought it was needed - but maybe the thing to do is to send him a few implementations and let him take it from there.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:datjmu$11ou$1@digitaldaemon.com...
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368
>
> If urgency is really your only doubt, then here's why I feel it should be just put in right now:
>
> 1. Once a fix is written, checking it in is quick and straightforward, not really something worth the time and effort of questioning the urgency of.
>
> 2. Putting in fixes as and when they're written is a positive sign for the public image.  Nobody likes to see a programming language, library or application having poor standards of maintenance.
>
> 3. Gratuitously holding back accepting contributions defeats half the point of a project being open source.
>
> 4. Such a trivial action takes little more time to do straight away than to add to a todo list, only to be finally done some time in the indefinite future.
>
> 5. If a fix isn't checked in on a good timescale, it can become out of date.  Consequently it will take a bit of work to update the patch to work with the newer version, which may have changed divergently.

My only reservation for inserting the patch (to write uncaught exception error messages to stderr) is that I've never liked stderr. I just prefer to redirect the output to a file, and using stderr always seems to just confuse the issue rather than be helpful.

In article <db10hp$16a0$1@digitaldaemon.com>, Walter says...
>
>
>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:datjmu$11ou$1@digitaldaemon.com...
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368
>>
>> If urgency is really your only doubt, then here's why I feel it should be just put in right now:
>>
>> 1. Once a fix is written, checking it in is quick and straightforward, not really something worth the time and effort of questioning the urgency of.
>>
>> 2. Putting in fixes as and when they're written is a positive sign for the public image.  Nobody likes to see a programming language, library or application having poor standards of maintenance.
>>
>> 3. Gratuitously holding back accepting contributions defeats half the point of a project being open source.
>>
>> 4. Such a trivial action takes little more time to do straight away than to add to a todo list, only to be finally done some time in the indefinite future.
>>
>> 5. If a fix isn't checked in on a good timescale, it can become out of date.  Consequently it will take a bit of work to update the patch to work with the newer version, which may have changed divergently.
>
>My only reservation for inserting the patch (to write uncaught exception error messages to stderr) is that I've never liked stderr. I just prefer to redirect the output to a file, and using stderr always seems to just confuse the issue rather than be helpful.

One of the very few times that I agree with Walter. :-)  Just kidding Walter.

josé

I agree, it gets worse when they send output to both.  And when you do programming on both win32 & linux, its always a pain to lookup the proper redirect syntax too.

Charlie

"Walter" <newshound@digitalmars.com> wrote in message news:db10hp$16a0$1@digitaldaemon.com...
>
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:datjmu$11ou$1@digitaldaemon.com...
> > http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368
> >
> > If urgency is really your only doubt, then here's why I feel it should be just put in right now:
> >
> > 1. Once a fix is written, checking it in is quick and straightforward, not really something worth the time and effort of questioning the urgency of.
> >
> > 2. Putting in fixes as and when they're written is a positive sign for the public image.  Nobody likes to see a programming language, library or application having poor standards of maintenance.
> >
> > 3. Gratuitously holding back accepting contributions defeats half the point of a project being open source.
> >
> > 4. Such a trivial action takes little more time to do straight away than to add to a todo list, only to be finally done some time in the indefinite future.
> >
> > 5. If a fix isn't checked in on a good timescale, it can become out of date.  Consequently it will take a bit of work to update the patch to work with the newer version, which may have changed divergently.
>
> My only reservation for inserting the patch (to write uncaught exception error messages to stderr) is that I've never liked stderr. I just prefer
to
> redirect the output to a file, and using stderr always seems to just
confuse
> the issue rather than be helpful.
>
>

On Linux/Unix stderr makes a lot of sense, and it's easy to redirect it to a file if you wish.  On MSWind, this may be a different matter.

Walter wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:datjmu$11ou$1@digitaldaemon.com...
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368
>>
>> If urgency is really your only doubt, then here's why I feel it should
>> be just put in right now:
>>
>> 1. Once a fix is written, checking it in is quick and straightforward,
>> not really something worth the time and effort of questioning the
>> urgency of.
>>
>> 2. Putting in fixes as and when they're written is a positive sign for
>> the public image.  Nobody likes to see a programming language, library
>> or application having poor standards of maintenance.
>>
>> 3. Gratuitously holding back accepting contributions defeats half the
>> point of a project being open source.
>>
>> 4. Such a trivial action takes little more time to do straight away than
>> to add to a todo list, only to be finally done some time in the
>> indefinite future.
>>
>> 5. If a fix isn't checked in on a good timescale, it can become out of
>> date.  Consequently it will take a bit of work to update the patch to
>> work with the newer version, which may have changed divergently.
> 
> My only reservation for inserting the patch (to write uncaught exception
> error messages to stderr) is that I've never liked stderr. I just prefer to
> redirect the output to a file, and using stderr always seems to just confuse
> the issue rather than be helpful.
> 
> 

Charles Hixson wrote:
> On Linux/Unix stderr makes a lot of sense, and it's easy to redirect it to a file if you wish.
<snip top of upside-down reply>

Is there a means of redirecting stderr that works across all Unix shells?  Or are you just supposed to be using a shell that supports it if you're going to do it?

> On MSWind, this may be a different matter.

True, there isn't an easy way of redirecting stderr on Windows, short of using a home-made or third-party utility.  We are thus faced with two options:

(a) being forced to redirect errors to the same place as normal output
(b) not being able to redirect errors at all

To me, (b) is the lesser of two evils.  (a) not only tends to be undesirable, but can be useless e.g. when using the program as a filter for Doxygen.  I refer you back here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2001

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> True, there isn't an easy way of redirecting stderr on Windows, short of using a home-made or third-party utility.  We are thus faced with two options:
> 

On Windows 9x and ME, it's AFAIK impossible since the command shell doesn't distinguish between stderr and stdout.

On the NT-based Windowses, just use 2> instead of >. This basically
means to redirect the second handle (which happens to be stderr) instead
of the default (which is stdout).

E.g. if your program looks like this:

import std.stdio;
void main(char[][] args) { fwritef(stderr, "asdf"); }

You can redirect the output to asdf.txt by running simply:

asdf 2> asdf.txt

Further information: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx