www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.128 release

reply "Walter" <newshound digitalmars.com> writes:
Bugs fixed.

http://www.digitalmars.com/d/changelog.html
Jul 10 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jul 11 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 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.
Jul 11 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 11 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jul 12 2005
next sibling parent jicman <jicman_member pathlink.com> writes:
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é
Jul 12 2005
prev sibling next sibling parent "Charles" <noone nowhere.com> writes:
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.
Jul 12 2005
prev sibling next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Jul 12 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 13 2005
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
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
Jul 13 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Deewiant wrote:


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


Does D still support these? I thought they had massive UTF problems too?


 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).


This is the same that I use under the various* Mac OS X shells, as well.

--anders

PS. Except for csh and tcsh, of course, as they are horribly broken.
     (http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/)
Jul 13 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Deewiant wrote:

 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.


<snip>

Doesn't follow.  If the command shell didn't distinguish, it would be 
impossible _not_ to redirect stderr if you're redirecting stdout.  As it 
happens, the Win9x command shell redirects stdout while leaving stderr 
going to the console.

But see

http://authors.phptr.com/corejava/faq.html

which provides a simple program to redirect stderr to stdout, which can 
then be redirected as desired.

The real solution, however, is for one of us to write or find a utility 
to launch a program, redirecting its stderr to a file.  I'm guessing it 
would be simple to do....

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.
Jul 13 2005
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Stewart Gordon wrote:

 Deewiant wrote:

 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.


 
 <snip>
 
 Doesn't follow.  If the command shell didn't distinguish, it would be
 impossible _not_ to redirect stderr if you're redirecting stdout. As it >
happens, the Win9x command shell redirects stdout while leaving stderr
 going to the console.


Right, my wording was confusing. I was talking about redirecting only
stderr whilst leaving stdout at the default. What I thought was that you
could redirect stderr along with stdout, but not each separately.

And you're right - on Win9x stderr is unredirectable without tools.
Jul 13 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 The real solution, however, is for one of us to write or find a utility
 to launch a program, redirecting its stderr to a file.  I'm guessing it 
 would be simple to do....


Use 4DOS command shell, it works on all win32.
It uses 2> syntax too.

http://www.jpsoft.com/download.htm
Jul 17 2005
parent reply Niko Korhonen <niktheblak hotmail.com> writes:
Andrew Fedoniouk wrote:

 Use 4DOS command shell, it works on all win32.
 It uses 2> syntax too.


Just remember that it's commercial software.

Anyway, everyone who is *serious* about using Windows with a console 
should already be familiar with 4NT and knows how to redirect the error 
stream. If hackin' away with console is one's cup of tea, one should 
seriously consider purchasing 4NT. The license cost is low compared to a 
lifetime of happy console hacking :)

IMO 4NT has some features that make it a worthwile competitor to *nix 
shells! (gasp!)

-- 
Niko Korhonen
SW Developer
Jul 17 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Niko Korhonen" <niktheblak hotmail.com> wrote in message 
news:dbfish$29o3$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 Use 4DOS command shell, it works on all win32.
 It uses 2> syntax too.


 Just remember that it's commercial software.


4DOS is free afaik.


 Anyway, everyone who is *serious* about using Windows with a console 
 should already be familiar with 4NT and knows how to redirect the error 
 stream. If hackin' away with console is one's cup of tea, one should 
 seriously consider purchasing 4NT. The license cost is low compared to a 
 lifetime of happy console hacking :)

 IMO 4NT has some features that make it a worthwile competitor to *nix 
 shells! (gasp!)

 -- 
 Niko Korhonen
 SW Developer
Jul 18 2005
next sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
Andrew Fedoniouk wrote:

 4DOS is free afaik.


Yes, right you are. I just thought that people will probably want to use 
4NT (which is not free) with W2k/XP.

-- 
Niko Korhonen
SW Developer
Jul 18 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Andrew Fedoniouk wrote:

 "Niko Korhonen" <niktheblak hotmail.com> wrote in message 
 news:dbfish$29o3$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 Use 4DOS command shell, it works on all win32.
 It uses 2> syntax too.






It used something similar to some Unix shells in my days.  Something like

   >&   redirect stdout and stderr
   >&>  redirect stderr only


 Just remember that it's commercial software.


 
 4DOS is free afaik.


<snip>

4DOS was shareware in its day.  They're simply releasing it as freeware 
now that it's no longer supported.

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.
Jul 18 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>

 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


Moreover, I can see people using this not-so-elegant workaround

int main() {
     try {
         ...
     } catch (Object o) {
         fwritefln(stderr, "Error: %s", o.toString);
         return 1;
     }
}

to get their programs behaving sanely by the standards of many of us. 
OTOH if this were made the built-in behaviour, I can't see the reverse 
idiom as being quite as common, but it is still available if somebody 
really does want it.

I don't see inflicting non-standard behaviour as the default as a Good 
Idea....

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.
Jul 13 2005
prev sibling next sibling parent reply qwerty <qwerty_member pathlink.com> writes:
In article <db2nso$309v$1 digitaldaemon.com>, Stewart Gordon says...

[snip]


 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:


Where did you get that idea from. Try this ...

dir 2>err.txt >dir.txt x:\*.*

and you will find that "err.txt" contains output from stderr and "dir.txt"
contains output from stdout.

This works on Win2000 and WinXP. Don't know about the older (unsupported?) ones.
Jul 13 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
qwerty wrote:
<snip>

 Where did you get that idea from. Try this ...
 
 dir 2>err.txt >dir.txt x:\*.*
 
 and you will find that "err.txt" contains output from stderr and "dir.txt"
 contains output from stdout.
 
 This works on Win2000 and WinXP. Don't know about the older (unsupported?)
ones.


That's half our point - the hack is specific to 2000/XP.

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.
Jul 14 2005
parent qwerty <qwerty_member pathlink.com> writes:
In article <db5a83$2a9q$1 digitaldaemon.com>, Stewart Gordon says...

qwerty wrote:
<snip>

 Where did you get that idea from. Try this ...
 
 dir 2>err.txt >dir.txt x:\*.*
 
 and you will find that "err.txt" contains output from stderr and "dir.txt"
 contains output from stdout.
 
 This works on Win2000 and WinXP. Don't know about the older (unsupported?)
ones.


That's half our point - the hack is specific to 2000/XP.


The 'hack'?  I would have thought that any 'hack' would apply to the unsupported
older Windows versions as the current Windows system support this without
resorting to any 'hacks'.
Jul 14 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>

 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:


Moreover, if some program uses stdout and stderr as appropriate, then 
even if the shell doesn't provide a means of redirecting stderr, one can 
use a tool to do this redirection.  OTOH given an arbitrary program that 
just writes everything to stdout, no tool can be relied upon to sift the 
errors from the regular output.

So preserving the distinction really is useful.

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.
Jul 14 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 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.


That is at the same time scary, and explanatory...
(explains why this patch hasn't gotten any priority)

I use stdout and stderr all the time, and would
prefer if D's treatment of them could be fixed ?

--anders

PS. Given any thoughts to the return code, as well ?
     (i.e. _define_ the return value of "void main()")
Jul 13 2005