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

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

 redirect the output to a file, and using stderr always seems to just

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

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

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.

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:
 
 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