On Sunday, 24 February 2013 at 11:31:01 UTC, deed wrote:
On Saturday, 23 February 2013 at 14:27:58 UTC, Dicebot wrote:
What has happened with dpaste recently?
Paste itself does work, but compilation does not anymore.
It has been like that since this thread was started.
Ugh, I have noticed
On Sunday, 24 February 2013 at 00:14:14 UTC, Ali Çehreli wrote:
Does the compiler inline any function even without -inline?
What level of optimization is applied even without -O? One that
comes to mind is the elision of certain struct object copies.
Is such an optimization applied without -O?
On 2/24/13 4:58 AM, H. S. Teoh wrote:
I find this rather frustrating... sometimes it feels like Phobos is
suffering from premature standardization - we have a module with a
design that isn't very good, but just because it somehow got put into
Phobos, now it has to stick, no matter what.
It's a
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is problematic as has been discussed. I think we could address
immediate needs by attaching an attribute to import, e.g.:
On 02/23/2013 08:39 PM, H. S. Teoh wrote:
On Sat, Feb 23, 2013 at 05:32:08PM -0800, Jonathan M Davis wrote:
On Saturday, February 23, 2013 20:14:14 Steven Schveighoffer wrote:
On Sat, 23 Feb 2013 20:07:43 -0500, Jonathan M Davisjmdavisp...@gmx.com
wrote:
[...]
We might be able to remove
On Sunday, February 24, 2013 08:58:38 deadalnix wrote:
I would bet for register promotions, dead read/write eliminations
and alike. I don't expect inline to be part of it.
It would actually be problematic if it were, because it would screw with
debugging.
- Jonathan M Davis
On 02/23/2013 09:07 PM, Jonathan M Davis wrote:
On Saturday, February 23, 2013 18:58:28 H. S. Teoh wrote:
I suppose std.proc is out of the question? ;-)
I don't know. Maybe.
I find this rather frustrating... sometimes it feels like Phobos is
suffering from premature standardization - we
Any word on the review process for this?
For now I have been using it in my projects by just putting it in
std/net on its own.
But I'd obviously like to see it in the standard library some
down, as its URI parsing is very valuable. :)
would it make sense to incoporate test from the ICU testsuite - there
are api tests and many data tests around
some can find the tests in the current release under
icu4c-50_1_2-src\icu\source\test
Am 29.01.2013 22:52, schrieb Dmitry Olshansky:
Recap:
During a couple of rounds of the informal
On Sunday, 24 February 2013 at 08:16:37 UTC, Jonathan M Davis
wrote:
On Sunday, February 24, 2013 08:58:38 deadalnix wrote:
I would bet for register promotions, dead read/write
eliminations
and alike. I don't expect inline to be part of it.
It would actually be problematic if it were,
On Sunday, February 24, 2013 10:05:01 Andrei Alexandrescu wrote:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is problematic as has been discussed. I think we could
On Sunday, February 24, 2013 09:33:12 deadalnix wrote:
On Sunday, 24 February 2013 at 08:16:37 UTC, Jonathan M Davis
wrote:
On Sunday, February 24, 2013 08:58:38 deadalnix wrote:
I would bet for register promotions, dead read/write
eliminations
and alike. I don't expect inline to be
24-Feb-2013 12:05, Andrei Alexandrescu пишет:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is problematic as has been discussed. I think we could address
immediate needs
On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
24-Feb-2013 12:05, Andrei Alexandrescu пишет:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is
On 24 Feb 2013 01:41, Daniel Murphy yebbl...@nospamgmail.com wrote:
Iain Buclaw ibuc...@ubuntu.com wrote in message
news:mailman.1489.1361640428.22503.digitalmar...@puremagic.com...
I don't use any part of the dmd backend. :o)
I know, I'm just saying there's a lot to do for the
24-Feb-2013 13:17, Jonathan M Davis пишет:
On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
24-Feb-2013 12:05, Andrei Alexandrescu пишет:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import
On 23 Feb 2013 20:25, jerro a...@a.com wrote:
BTW, I think the clearest remains my generator proposal:
string randomString =
fastGenerator!(() = letters[uniform(0, $)]).take(9).array;
If the goal was to replace iota(n).map, it may be better to just have
something like:
On Sunday, February 24, 2013 13:35:31 Dmitry Olshansky wrote:
24-Feb-2013 13:17, Jonathan M Davis пишет:
On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
24-Feb-2013 12:05, Andrei Alexandrescu пишет:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use
Am 23.02.2013 12:31, schrieb Lars T. Kyllingstad:
It's been years in the coming, but we finally got it done. :) The
upshot is that the module has actually seen active use over those years,
both by yours truly and others, so hopefully the worst wrinkles are
already ironed out.
Pull request:
On Sat, 2013-02-23 at 23:22 +0400, Dmitry Olshansky wrote:
[…]
Would be nice to know if there is something that can represent this C
snippet without the usual heaps of verbosity:
enum {
STATUS_OK = 0,
STATUS_FAIL_REASON_XYZ,
... ad infinitum (but presently dozens)
};
enum
On Sat, 2013-02-23 at 14:58 +0100, deadalnix wrote:
[…]
Comparing ant and maven is not appropriate here as maven is a
build system + a package manager when ant only builds.
Comparing Ant and Maven is perfectly valid since the goal of both is to
build software from source.
The plugin system
On Sat, 2013-02-23 at 10:08 -0700, David Gileadi wrote:
[…]
I love Gradle! Official site at http://www.gradle.org, with very good
docs including getting started tutorials.
Excellent. So do I, but I am biased. But less so that I was three or
four years ago.
In practice I've found it to be
24-Feb-2013 14:34, Russel Winder пишет:
On Sat, 2013-02-23 at 23:22 +0400, Dmitry Olshansky wrote:
[…]
Would be nice to know if there is something that can represent this C
snippet without the usual heaps of verbosity:
enum {
STATUS_OK = 0,
STATUS_FAIL_REASON_XYZ,
... ad infinitum (but
On 02/24/2013 04:59 AM, Steven Schveighoffer wrote:
...
D is much different (and better IMO)
...
IMO The best way to think about it is that the two approaches are not
comparable. D templates are a kind of hygienic macro system for
declarations. Java does not have this. Java generics make
On 2013-02-22 19:13, Marco Leise wrote:
I think contributing to D requires more than a VM image
download and a good old Wiki page gets the job done as well.
When you dived in that far you probably have a native
installation.
It's something different to have additional VMs to test code
on Linux,
On 2013-02-24 09:43, Jonathan M Davis wrote:
Well, there are three aspects to what usually is meant by a debug build:
1. Debug symbols are compiled in.
2. Optimizations are not enabled.
3. Assertions _are_ enabled.
For dmd, the first one is controlled by -g and -gc, the second one is
On 02/10/2013 03:42 PM, kenji hara wrote:
2013/2/10 kenji hara k.hara...@gmail.com mailto:k.hara...@gmail.com
I opened the pull request #1413 in the beta term for 2.061, but it
had _accidentally_ released without deeply discussion.
1, What about support for nonblocking wait(). It would be very
nice not to block the main thread if you really don't care about
waiting for the sub process but just want to be nice and not
create zombies.
2, What about nonblocking read/writes or support for timing out
reads/writes at
On 2/24/13 11:06 AM, Dmitry Olshansky wrote:
24-Feb-2013 12:05, Andrei Alexandrescu пишет:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is problematic as has been
I apologise if this gets posted twice, but my newsgroup client is
acting up.
On Saturday, 23 February 2013 at 16:44:30 UTC, H. S. Teoh wrote:
I just looked over the docs. Looks very good!
Thanks! :)
Just a few minor comments:
- wait():
- Some code examples would be nice.
The wait()
On Sunday, 24 February 2013 at 04:54:13 UTC, Jonathan M Davis
wrote:
On Saturday, February 23, 2013 19:47:54 Nathan M. Swan wrote:
Why not just deprecate everything currently in std.process and
drop in
the new stuff? It might be a bit ugly, but it prevents both
code
breakage _and_ a
On Sun, 24 Feb 2013 08:03:24 -0500, Jonas Drewsen jdrew...@nospam.com
wrote:
1, What about support for nonblocking wait(). It would be very nice not
to block the main thread if you really don't care about waiting for the
sub process but just want to be nice and not create zombies.
On Sunday, 24 February 2013 at 00:11:42 UTC, H. S. Teoh wrote:
BTW, is std.process2 just the temporary name, or are we
seriously
going to put in a std.process2 into Phobos? I'm hoping the
former, as
the latter is unforgivably ugly.
I agree, it's not ideal, but unforgivably ugly is taking it
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T.
Kyllingstad wrote:
It's been years in the coming, but we finally got it done. :)
The upshot is that the module has actually seen active use over
those years, both by yours truly and others, so hopefully the
worst wrinkles are already
On Sunday, 24 February 2013 at 10:23:36 UTC, Sönke Ludwig wrote:
I haven't read all responses (sorry), but considering that
there don't
seem to be API conflicts between the old and new std.process,
why don't
we just keep the old C style functions and deprecate them? No
need to
rename or
On Sun, 24 Feb 2013 10:01:12 -0500, Lars T. Kyllingstad
pub...@kyllingen.net wrote:
Wait for all processes:
This would certainly be convenient, and it is simple to implement. It
would require a static __gshared Pid[int] of all processes created by
spawnProcess(), and we'd simply call
On Sunday, 24 February 2013 at 15:37:10 UTC, Steven Schveighoffer
wrote:
On Sun, 24 Feb 2013 10:01:12 -0500, Lars T. Kyllingstad
pub...@kyllingen.net wrote:
Wait for all processes:
This would certainly be convenient, and it is simple to
implement. It would require a static __gshared
This code currently compiles:
int bar();
@bar() void foo(){}
But this gives an error, as expected:
int bar();
@bar() void foo(){}
pragma(msg, __traits(getAttributes, foo));
I would expect the first example to give an error too. Is the
current behavior deliberate or is it a DMD bug?
On 2/24/13 1:50 PM, Timon Gehr wrote:
On 02/24/2013 04:59 AM, Steven Schveighoffer wrote:
...
D is much different (and better IMO)
...
IMO The best way to think about it is that the two approaches are not
comparable. D templates are a kind of hygienic macro system for
declarations. Java does
On Sunday, 24 February 2013 at 16:04:19 UTC, jerro wrote:
This code currently compiles:
int bar();
@bar() void foo(){}
But this gives an error, as expected:
int bar();
@bar() void foo(){}
pragma(msg, __traits(getAttributes, foo));
I would expect the first example to give an error too. Is the
Why the fist is wrong? It is a call expression which is
acceptable according to the UDA grammar.
I'm not saying the syntax in the first example is, or should be,
invalid.
The reason the second
does not compile is because the statement is evaluated at CT,
and
interpreter cannot evaluate
On 02/24/2013 05:20 PM, Andrei Alexandrescu wrote:
On 2/24/13 1:50 PM, Timon Gehr wrote:
On 02/24/2013 04:59 AM, Steven Schveighoffer wrote:
...
D is much different (and better IMO)
...
IMO The best way to think about it is that the two approaches are not
comparable. D templates are a kind
I am quite sick of DMDFE breaking my code every release with bugs
that are then solved for the next release (that is, if they are
solved). If I track the latest compiler, then my code is broken
for older compilers (and you are kidding yourselves if you think
people always use the latest
On 02/24/2013 05:48 PM, SiegeLord wrote:
...
(because every DMDFE keeps adding features... soon we'll have all the
features)...
...
You realize that you are complaining about this in a feature request? :o)
Maybe this feature is already available and I'm not aware of it?
static
On Sunday, 24 February 2013 at 16:54:20 UTC, Timon Gehr wrote:
You realize that you are complaining about this in a feature
request? :o)
Using D requires doublethink.
Maybe this feature is already available and I'm not aware of
it?
static assert(__VERSION__==2060);
This works, but is it
On 02/24/2013 06:00 PM, SiegeLord wrote:
On Sunday, 24 February 2013 at 16:54:20 UTC, Timon Gehr wrote:
You realize that you are complaining about this in a feature request? :o)
Using D requires doublethink.
For the moment I'm just sticking with 2.060, because I have failed to
reduce all
On Sun, 24 Feb 2013 10:53:48 -0500, Lars T. Kyllingstad
pub...@kyllingen.net wrote:
On Sunday, 24 February 2013 at 15:37:10 UTC, Steven Schveighoffer wrote:
Either of these is possible similar to how core.thread keeps track of
all threads, we could simply ignore any child exits that we
On Sunday, 24 February 2013 at 17:05:57 UTC, Timon Gehr wrote:
The documentation is often wrong anyway, but here you go:
http://dlang.org/lex.html
(look for 'Special Tokens')
Hmm... it is documented as Compiler version as an integer, such
as 2001. I wouldn't except this to match the DMDFE
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T.
Kyllingstad wrote:
Pull request:
https://github.com/D-Programming-Language/phobos/pull/1151
Code:
https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
Documentation:
On Sunday, 24 February 2013 at 16:36:05 UTC, jerro wrote:
The reason the second
does not compile is because the statement is evaluated at CT,
and
interpreter cannot evaluate call without source, like a regular
explicit call.
I know that, the thing is that it will give this error every
time
extern(C) int bar();
@bar() void foo(){}
//pragma(msg, __traits(getAttributes, foo));
void main()
{
auto x = __traits(getAttributes, foo)[0];
}
is compilable and runnable when linker knows where bar() is.
So this is actually supposed to work? The documentation says:
User Defined
24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
Pull request:
https://github.com/D-Programming-Language/phobos/pull/1151
Code:
https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
Documentation:
On Sun, 24 Feb 2013 03:46:32 +0100, Andrej Mitrovic wrote:
Ah but how can you guarantee we won't ever need a 3rd rewrite? It's
always possible we might need one in the future.
I think you want to guarantee that it CAN be re-written, because existing
code always becomes crufty, and even less
24-Feb-2013 22:05, Dmitry Olshansky пишет:
24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
Pull request:
https://github.com/D-Programming-Language/phobos/pull/1151
Code:
On Sunday, 24 February 2013 at 18:05:14 UTC, Dmitry Olshansky
wrote:
24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T.
Kyllingstad wrote:
Pull request:
https://github.com/D-Programming-Language/phobos/pull/1151
Code:
To me, asynchronous implies that something is going on in the
background that will produce a result in the future. That is
not what happens here.
I agree that nonBlockingWait() is less than ideal, though,
mainly because it is an oxymoron. :) I considered status,
isAlive, etc., but I think
24-Feb-2013 22:42, Lars T. Kyllingstad пишет:
On Sunday, 24 February 2013 at 18:05:14 UTC, Dmitry Olshansky wrote:
24-Feb-2013 21:41, Lars T. Kyllingstad пишет:
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad
wrote:
Pull request:
On Sun, 24 Feb 2013 13:03:26 -0500, jerro a...@a.com wrote:
extern(C) int bar();
@bar() void foo(){}
//pragma(msg, __traits(getAttributes, foo));
void main()
{
auto x = __traits(getAttributes, foo)[0];
}
is compilable and runnable when linker knows where bar() is.
So this is actually
On Sunday, February 24, 2013 13:07:39 Jacob Carlborg wrote:
On 2013-02-24 09:43, Jonathan M Davis wrote:
Well, there are three aspects to what usually is meant by a debug build:
1. Debug symbols are compiled in.
2. Optimizations are not enabled.
3. Assertions _are_ enabled.
On Sunday, 24 February 2013 at 18:03:29 UTC, jerro wrote:
extern(C) int bar();
@bar() void foo(){}
//pragma(msg, __traits(getAttributes, foo));
void main()
{
auto x = __traits(getAttributes, foo)[0];
}
is compilable and runnable when linker knows where bar() is.
So this is actually
On 02/24/2013 05:04 PM, jerro wrote:
This code currently compiles:
int bar();
@bar() void foo(){}
But this gives an error, as expected:
int bar();
@bar() void foo(){}
pragma(msg, __traits(getAttributes, foo));
I would expect the first example to give an error too. Is the current
behavior
On Sunday, 24 February 2013 at 18:56:39 UTC, jerro wrote:
To me, asynchronous implies that something is going on in
the background that will produce a result in the future. That
is not what happens here.
I agree that nonBlockingWait() is less than ideal, though,
mainly because it is an
On 02/24/2013 08:19 PM, Timon Gehr wrote:
On 02/24/2013 05:04 PM, jerro wrote:
This code currently compiles:
int bar();
@bar() void foo(){}
But this gives an error, as expected:
int bar();
@bar() void foo(){}
pragma(msg, __traits(getAttributes, foo));
I would expect the first example to
On Sun, Feb 24, 2013 at 10:05:01AM +0200, Andrei Alexandrescu wrote:
On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
Phobos modules which already use std.process would have to be changed
to directly import std.process1 or std.process2.
This is problematic as has been discussed. I think we could
On Sun, 24 Feb 2013 19:42:23 +0100, Lars T. Kyllingstad wrote:
http://www.kyllingen.net/code/std-process2/phobos-prerelease/
std_process2.html
Ok, a new version with non-blocking wait is up.
asyncWait would be less verbose :)
To me, asynchronous implies that something is going on in the
On Sunday, 24 February 2013 at 19:45:26 UTC, H. S. Teoh wrote:
Alternatively, use a version identifier:
version = newStdProcess;
import std.process; // get new version
-
//version = newStdProcess;
import std.process; // get old version
Then
On Sunday, 24 February 2013 at 14:44:51 UTC, Steven Schveighoffer
wrote:
On Sun, 24 Feb 2013 08:03:24 -0500, Jonas Drewsen
jdrew...@nospam.com wrote:
1, What about support for nonblocking wait(). It would be very
nice not to block the main thread if you really don't care
about waiting for
On 2/24/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
Yeah, which just adds the confusion, because all it does is enable debug
bocks.
The feature almost doesn't pay its weight. I mean technically you can
use -version=Debug and then use version(Debug) blocks. All `debug`
does is saves a little
On 2/24/13, Chris Nicholson-Sauls ibisbase...@gmail.com wrote:
- Old module remains available as 'std.process' but with a
pragma(msg) warning users that it will go away next release.
(It'd be even better to have a pragma(warn), actually.)
We have deprecated(message) for that. And it gives
On Sunday, 24 February 2013 at 17:41:44 UTC, Lars T. Kyllingstad
wrote:
Ok, a new version with non-blocking wait is up.
1. Can the Firefox example be replaced with something else?
Spawning a specific browser to open a webpage is bad practice,
and I've noticed in several programs. It would be
On 02/24/2013 09:57 PM, Andrej Mitrovic wrote:
On 2/24/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
Yeah, which just adds the confusion, because all it does is enable debug
bocks.
The feature almost doesn't pay its weight. I mean technically you can
use -version=Debug and then use
On Sun, 24 Feb 2013 15:49:52 +0400
Dmitry Olshansky dmitry.o...@gmail.com wrote:
c) a VM. Like it or not but corps love VMs and safe isolated
environments. For us the fact that it's cross-platform also removes
quite a bit of pain, plus no memory corruption bugs etc.
Luckily, modern server
On Sun, 24 Feb 2013 11:43:24 -0800, H. S. Teoh wrote:
@v2.070+ import std.process;
Better yet, @v.2070. So that later on it can be extended to @v2.070
v2.084, etc.. But I don't know if it's a good idea to push it that
far...
Now that I think about it more, this is not an import-level
On 2/24/13, Vladimir Panteleev vladi...@thecybershadow.net wrote:
a) they come with a very thorough unit test
Unfortunately those unittests are never being run in the Phobos
test-suite and as a result a regression was missed (which was fixed by
now):
On 2/24/2013 8:48 AM, SiegeLord wrote:
I am quite sick of DMDFE breaking my code every release with bugs
that are then solved for the next release (that is, if they are
solved).
Here's the current regression list:
On Sun, 24 Feb 2013 16:04:43 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Sunday, 24 February 2013 at 17:41:44 UTC, Lars T. Kyllingstad wrote:
Ok, a new version with non-blocking wait is up.
3. The documentation for the gui config item seems to be wrong: it
prevents
On 2/24/2013 9:05 AM, Timon Gehr wrote:
For the moment I'm just sticking with 2.060, because I have failed to reduce all
the forward reference regressions introduced in 2.061.
I've found dustmite to be pretty helpful reducing things down.
On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
On 2/24/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
Yeah, which just adds the confusion, because all it does is enable debug
bocks.
The feature almost doesn't pay its weight. I mean technically you can
use -version=Debug and then use
On 02/24/2013 11:22 PM, Walter Bright wrote:
On 2/24/2013 9:05 AM, Timon Gehr wrote:
For the moment I'm just sticking with 2.060, because I have failed to
reduce all
the forward reference regressions introduced in 2.061.
I've found dustmite to be pretty helpful reducing things down.
The
On Sunday, February 24, 2013 14:28:42 Walter Bright wrote:
On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
On 2/24/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
Yeah, which just adds the confusion, because all it does is enable debug
bocks.
The feature almost doesn't pay its weight. I
On Sunday, February 24, 2013 14:22:42 Walter Bright wrote:
On 2/24/2013 9:05 AM, Timon Gehr wrote:
For the moment I'm just sticking with 2.060, because I have failed to
reduce all the forward reference regressions introduced in 2.061.
I've found dustmite to be pretty helpful reducing
On 02/23/2013 09:28 PM, Steven Schveighoffer wrote:
...
But I have not gotten around to pitching it because I need to come up
with a really good solution :) Walter is so sour on any tail-const
solution from past attempts that it has to be bullet-proof and easy.
...
Just add some form of
On Sunday, 24 February 2013 at 21:40:24 UTC, Andrej Mitrovic
wrote:
On 2/24/13, Vladimir Panteleev vladi...@thecybershadow.net
wrote:
a) they come with a very thorough unit test
Unfortunately those unittests are never being run in the Phobos
test-suite and as a result a regression was missed
On Sunday, 24 February 2013 at 22:13:35 UTC, Steven Schveighoffer
wrote:
On Sun, 24 Feb 2013 16:04:43 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Sunday, 24 February 2013 at 17:41:44 UTC, Lars T.
Kyllingstad wrote:
Ok, a new version with non-blocking wait is up.
3. The
On 2/25/13, Vladimir Panteleev vladi...@thecybershadow.net wrote:
Full code of my ls test program:
Works for me on XP. Using 'ls' from GnuWin32.
On Sun, 24 Feb 2013 18:52:04 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Sunday, 24 February 2013 at 22:13:35 UTC, Steven Schveighoffer wrote:
On Sun, 24 Feb 2013 16:04:43 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Sunday, 24 February 2013 at
On Monday, 25 February 2013 at 00:02:54 UTC, Steven Schveighoffer
wrote:
Hm... that message is printed out if the code cannot set the
inherit handle flag on the specific stdin.
Are you on windows 64 or 32? It's a large difference since one
uses MSVCRT and one uses DMCRT. Also, I don't have
On Sunday, 24 February 2013 at 14:43:50 UTC, Lars T. Kyllingstad
wrote:
[snip]
Hi Lars,
First of all, about environment. I think the old behavior makes
more sense.
I think you had a good point about making it behave like an
associative array. I would expect using opIndex with an
On Sun, 24 Feb 2013 19:17:44 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at 00:02:54 UTC, Steven Schveighoffer wrote:
Hm... that message is printed out if the code cannot set the inherit
handle flag on the specific stdin.
Are you on windows 64
On Monday, 25 February 2013 at 00:27:10 UTC, Steven Schveighoffer
wrote:
On Sun, 24 Feb 2013 19:17:44 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at 00:02:54 UTC, Steven
Schveighoffer wrote:
Hm... that message is printed out if the code cannot set
On Sun, 24 Feb 2013 19:35:36 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at 00:27:10 UTC, Steven Schveighoffer wrote:
On Sun, 24 Feb 2013 19:17:44 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at
On Monday, 25 February 2013 at 00:44:43 UTC, Steven Schveighoffer
wrote:
Can you catch the exception and print out GetLastError()?
87 (ERROR_INVALID_PARAMETER): The parameter is incorrect.
Consider using FileException, which calls sysErrorString.
On Monday, 25 February 2013 at 00:44:43 UTC, Steven Schveighoffer
wrote:
1. The file descriptor from stdin failed to come out, and
windows gives back a valid handle from GetStdHandle
2. The file descriptor is valid (0 or above), but
_fdToHandle/_get_osfhandle fails to get a valid handle
On Feb 24, 2013 10:41 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 02/24/2013 11:22 PM, Walter Bright wrote:
On 2/24/2013 9:05 AM, Timon Gehr wrote:
For the moment I'm just sticking with 2.060, because I have failed to
reduce all
the forward reference regressions introduced in 2.061.
I've
On Feb 24, 2013 10:16 PM, Walter Bright newshou...@digitalmars.com
wrote:
On 2/24/2013 8:48 AM, SiegeLord wrote:
I am quite sick of DMDFE breaking my code every release with bugs
that are then solved for the next release (that is, if they are
solved).
Here's the current regression list:
On Sun, 24 Feb 2013 19:57:41 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at 00:44:43 UTC, Steven Schveighoffer wrote:
1. The file descriptor from stdin failed to come out, and windows gives
back a valid handle from GetStdHandle
2. The file
On Monday, 25 February 2013 at 00:57:42 UTC, Vladimir Panteleev
wrote:
Looks like it. Maybe you can't SetHandleInformation on standard
handles in Windows 7?
GetHandleInformation reveals that HANDLE_FLAG_INHERIT is already
set for the stdin handle for me.
On Monday, 25 February 2013 at 01:09:32 UTC, Steven Schveighoffer
wrote:
Did you try SetHandleInformation directly on that handle? It's
still slightly possible that some other call caused the
exception while this one was being thrown.
I put a writeln in the if, so I'm quite sure that it was
On Monday, 25 February 2013 at 01:10:08 UTC, Vladimir Panteleev
wrote:
On Monday, 25 February 2013 at 00:57:42 UTC, Vladimir Panteleev
wrote:
Looks like it. Maybe you can't SetHandleInformation on
standard handles in Windows 7?
GetHandleInformation reveals that HANDLE_FLAG_INHERIT is
already
On Sun, 24 Feb 2013 20:15:02 -0500, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
On Monday, 25 February 2013 at 01:10:08 UTC, Vladimir Panteleev wrote:
On Monday, 25 February 2013 at 00:57:42 UTC, Vladimir Panteleev wrote:
Looks like it. Maybe you can't SetHandleInformation on
1 - 100 of 195 matches
Mail list logo
