View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2005
DMD 0.128 release
Bugs fixed.

http://www.digitalmars.com/d/changelog.html
July 11, 2005
Re: DMD 0.128 release
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
July 11, 2005
Re: DMD 0.128 release
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.
July 11, 2005
Re: DMD 0.128 release
> 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.
July 12, 2005
Re: DMD 0.128 release
"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.
July 12, 2005
Re: DMD 0.128 release
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é
July 12, 2005
Re: DMD 0.128 release
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.
>
>
July 12, 2005
Re: DMD 0.128 release
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.
> 
>
July 13, 2005
Re: DMD 0.128 release
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.
July 13, 2005
Re: DMD 0.128 release
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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home