https://issues.dlang.org/show_bug.cgi?id=4906
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P4
--
http://d.puremagic.com/issues/show_bug.cgi?id=4906
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
On 03/09/2012 01:43 AM, bearophile wrote:
Adam D. Ruppe:
D rox the web (and has for a while).
(Oh, you are starting to copy Andrei talk style now :-) The birth of community
words, idioms and sub-languages is a very common thing, sociology studies such
things a lot).
But there's always
Timon Gehr:
Comparing signed/unsigned is perfectly reasonable.
Right, but only if the numbers don't get implicit
reinterpretations to other intervals, as C/C++/D do.
Bye,
bearophile
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where Windows
got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for
On Thu, 08 Mar 2012 03:58:22 -0500, Don Clugston d...@nospam.com wrote:
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it
I think what Chad is looking for is a BlackHole/WhiteHole equivalent
which doesn't need abstract functions but which figures out all the
methods of a class at compile time and creates a subclass that
throws/does nothing on method invocation. An 'alias this' field would
be used that is
On Thu, Mar 08, 2012 at 02:57:00PM +0100, Andrej Mitrovic wrote:
[...]
I don't know why we don't have __traits(allFunction). We have
'getVirtualFunctions' but it requires a function name, but using
allMembers to filter out function names is damn difficult if you ask
me.
foreach (name;
On Mar 8, 2012, at 12:58 AM, Don Clugston d...@nospam.com wrote:
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it
could it be a good idea to add something like an check-scope for
modules,functions,etc. for typical fails to easy the detection?
wild-idea-and-syntax-list:
@CheckForNull
@CheckForNaN
@CheckForUnnormalFloat
...
x.d
modul x
@CheckForNull // will introduce NullChecks for the complete
On 3/8/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
foreach (name; __traits(allMembers, typeof(obj))) {
static if (__traits(compiles, __traits(getMember, obj,
name)))
{
alias typeof(__traits(getMember, obj,
Sorry,
mixin(getOverloads!(UnreliableResource)()); should be:
mixin(getOverloads!(Base)());
Plus I left over some code. Anyway the point is that was just a
hardcoded example of something that's doable, you'd probably want it
to be much more sophisticated before it goes into a library.
I like the way Scala handles this with the Option class. None
indicates no value which is equivalent to your null sentinal
value but it is a value itself so it is always safe to use.
Combined with pattern matching and the orElse methods makes it
very easy to use one variable that both stores
On Thu, Mar 08, 2012 at 05:49:20PM +0100, Andrej Mitrovic wrote:
On 3/8/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
foreach (name; __traits(allMembers, typeof(obj))) {
static if (__traits(compiles, __traits(getMember, obj,
name)))
{
On 3/8/2012 12:58 AM, Don Clugston wrote:
The documentation is terrible, but it's really a beautiful design.
I agree, it really is very flexible and useful. The downside is that it leaves
significant overhead in functions that are exception-aware, even if they never
throw or unwind.
And
On Thursday, 8 March 2012 at 22:20:10 UTC, Walter Bright wrote:
I agree, it really is very flexible and useful. The downside is
that it leaves significant overhead in functions that are
exception-aware, even if they never throw or unwind.
This problem is avoided by the switch to the
Regarding people that desire a compiler switch to add run-time tests inside the
binary that guard against null seg-faults to turn turn them into errors with a
stack trace: I have recently shown the D language to a friend. She answered me
that most code she writes is for the Web and it's not
On Friday, 9 March 2012 at 00:19:38 UTC, bearophile wrote:
So maybe for her D language is not needed, other more flexible
languages are better for her.
D rox the web (and has for a while).
Adam D. Ruppe:
D rox the web (and has for a while).
(Oh, you are starting to copy Andrei talk style now :-) The birth of community
words, idioms and sub-languages is a very common thing, sociology studies such
things a lot).
But there's always some space for improvements :-)
In D.learn
On 03/08/2012 10:40 AM, H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 02:57:00PM +0100, Andrej Mitrovic wrote:
I think what Chad is looking for is a BlackHole/WhiteHole equivalent
which doesn't need abstract functions but which figures out all the
methods of a class at compile time and creates a
On 03/07/2012 02:40 AM, Chad J wrote:
On 03/06/2012 12:19 PM, Timon Gehr wrote:
...
For example:
http://pm.inf.ethz.ch/publications/getpdf.php/bibname/Own/id/SummersMuellerTR11.pdf
CTFE and static constructors solve that issue for static data.
I can't seem to download the PDF... it always
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy = 5; }
}
Which would be lowered by the compiler into this:
class Bar
{
// Assume
On Mon, 05 Mar 2012 22:51:28 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, March 05, 2012 21:04:20 Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
michel.for...@michelf.com wrote:
That said, throwing an exception might not be a better response
On Tue, 06 Mar 2012 23:07:24 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 3/6/2012 8:05 PM, Walter Bright wrote:
What I'm talking about is the idea that one can recover from seg faults
resulting from program bugs.
I've written about this before, but I want to emphasize that
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
On 03/05/2012 11:27 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
There are two independent discussions being conflated here. One about
getting more
information out of
On Wed, 07 Mar 2012 09:22:27 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
Why is it fatal?
A segmentation fault indicates that a program
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access
memory
that is
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
Why is it fatal?
A segmentation fault indicates that a program tried to access
memory
that is
On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
Why is it
On Wed, Mar 07, 2012 at 09:22:27AM -0500, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
[...]
However, there are several causes of seg faults:
1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer now
points into no-mem
On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.
The point is, it's impossible to tell whether the null pointer was
On 03/07/2012 04:41 AM, Timon Gehr wrote:
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy = 5; }
}
Which would be lowered by the
On 03/08/2012 01:24 AM, Chad J wrote:
On 03/07/2012 04:41 AM, Timon Gehr wrote:
On 03/07/2012 02:40 AM, Chad J wrote:
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
class Foo
{
int dummy;
}
class Bar
{
Foo foo = new Foo();
this() { foo.dummy =
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
chadjoan@__spam.is.bad__gmail.com wrote:
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
I spoke too soon!
We missed one:
1. You forgot to initialize a variable.
2. Your memory has been
On 03/07/2012 02:09 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.
The point is, it's
On 03/07/2012 07:39 PM, Timon Gehr wrote:
On 03/08/2012 01:24 AM, Chad J wrote:
Though, more to the point:
I would probably forbid Foo foo = new Foo(this);. The design that
leads to this is creating circular dependencies, which is usually bad to
begin with.
Circular object references are
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
-Steve
Example?
Create an instance of the class which is immutable and represents an invalid
value. You could check whether something is that
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
-Steve
Example?
Create an instance of the class which is immutable and represents an invalid
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
-Steve
Example?
Create an
On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
You can use sentinels other than null.
On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
On 03/07/2012 10:21 AM, Steven
On 03/07/2012 11:17 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 20:44:59 Chad J
On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
Yeah, C and C++ might not do what's suggested but basically all other languages
do it.
People turn to C and C++ for systems work and high performance.
If you have a possible null, then check for it *yourself* sometimes
you know its null, sometimes you don't have any control. However, the
compiler has no way of knowing that. Its basically an all-or-nothing
thing with the compiler.
However, the compiler can (and I think does) warn of possible
On 3/5/2012 12:05 PM, Nick Sabalausky wrote:
Walter Brightnewshou...@digitalmars.com wrote in message
news:jiunst$qrm$1...@digitalmars.com...
3. Intercepting and recovering from seg faults, div by 0, etc., all sounds
great on paper. In practice, it is almost always wrong. The only exception
On 03/05/2012 05:39 AM, Adam D. Ruppe wrote:
On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
News to me. I've had bad runs with that back in the day, but maybe
things have improved a bit.
Strangely, I've never had a problem with gdb and D,
as far back as 2007.
(at least for the basic
On 2012-03-06 10:11, James Miller wrote:
If you have a possible null, then check for it *yourself* sometimes
you know its null, sometimes you don't have any control. However, the
compiler has no way of knowing that. Its basically an all-or-nothing
thing with the compiler.
If I know there is a
On 04/03/12 04:34, Walter Bright wrote:
On 3/3/2012 6:53 PM, Sandeep Datta wrote:
It's been there for 10 years, and turns out to be a solution looking
for a
problem.
I beg to differ, the ability to catch and respond to such asynchronous
exceptions is vital to the stable operation of long
James Miller:
If you have a possible null, then check for it *yourself* sometimes
you know its null, sometimes you don't have any control. However, the
compiler has no way of knowing that. Its basically an all-or-nothing
thing with the compiler.
In a normal program there are many situations
On 03/06/2012 02:54 AM, Jacob Carlborg wrote:
On 2012-03-06 08:53, Jacob Carlborg wrote:
On 2012-03-06 03:04, Steven Schveighoffer wrote:
Certainly for Mac OS X, it should do the most informative appropriate
thing for the OS it's running on. Does the above happen for D programs
currently on
On 03/06/2012 03:27 AM, Walter Bright wrote:
On 3/5/2012 11:51 AM, Jacob Carlborg wrote:
Yeah, C and C++ might not do what's suggested but basically all other
languages
do it.
People turn to C and C++ for systems work and high performance.
Optional. Flags.
If there is a truly unavoidable
Sandeep Datta:
I am just going to leave this here...
*Fast Bounds Checking Using Debug Register*
http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
Is this idea usable in DMD to speed up D code compiled in non-release mode?
Bye,
bearophile
On 2012-03-06 10:53:19 +, Jacob Carlborg d...@me.com said:
On Mac OS X the runtime would only need to catch any exception (as it
already does) and print the stack trace. But also re-throw the
exception to let the OS handle the logging of the exception (at least I
hope that will work).
On 2012-03-06 13:48, Chad J wrote:
On 03/06/2012 02:54 AM, Jacob Carlborg wrote:
On 2012-03-06 08:53, Jacob Carlborg wrote:
On 2012-03-06 03:04, Steven Schveighoffer wrote:
Certainly for Mac OS X, it should do the most informative appropriate
thing for the OS it's running on. Does the above
On Tuesday, 6 March 2012 at 09:11:07 UTC, James Miller wrote:
If you have a possible null, then check for it *yourself*
sometimes
you know its null, sometimes you don't have any control.
However, the
compiler has no way of knowing that. Its basically an
all-or-nothing
thing with the compiler.
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types
means that they are the default and checked statically, ideally
using data flow analysis.
I agree that non-nullable types should be made the default and
statically
On Mar 6, 2012, at 3:14 AM, Don Clugston d...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where Windows
got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for floating point traps to be fully
On Tue, 06 Mar 2012 14:22:09 +0100, bearophile bearophileh...@lycos.com
wrote:
Sandeep Datta:
I am just going to leave this here...
*Fast Bounds Checking Using Debug Register*
http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
Is this idea usable in DMD to speed up D code compiled in
On Tue, 06 Mar 2012 12:14:56 +0100, Don Clugston d...@nospam.com wrote:
On 04/03/12 04:34, Walter Bright wrote:
On 3/3/2012 6:53 PM, Sandeep Datta wrote:
It's been there for 10 years, and turns out to be a solution looking
for a
problem.
I beg to differ, the ability to catch and respond to
On Tuesday, 6 March 2012 at 15:46:54 UTC, foobar wrote:
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types
means that they are the default and checked statically,
ideally using data flow analysis.
I agree that
06.03.2012 8:04, Chad J пишет:
On 03/06/2012 12:07 AM, Jonathan M Davis wrote:
If you dereference a null pointer, there is a serious bug in your
program.
Continuing is unwise. And if it actually goes so far as to be a segfault
(since the hardware caught it rather than the program), it is
On 03/06/2012 03:39 PM, Mantis wrote:
06.03.2012 8:04, Chad J пишет:
On 03/06/2012 12:07 AM, Jonathan M Davis wrote:
If you dereference a null pointer, there is a serious bug in your
program.
Continuing is unwise. And if it actually goes so far as to be a segfault
(since the hardware caught
On 03/06/2012 12:19 PM, Timon Gehr wrote:
On 03/06/2012 04:46 PM, foobar wrote:
On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:
This is quite close, but real support for non-nullable types means
that they are the default and checked statically, ideally using data
flow analysis.
On 3/6/2012 5:29 PM, Chad J wrote:
But what do you say to the notion of isolation? someFunc is isolated from
riskyShenanigans becuase it /knows/ what state is touched by riskyShenanigans.
If riskyShenanigans does something strange and unexpected, and yes, it does have
a bug in it, then I feel
On Tue, Mar 06, 2012 at 08:29:35PM -0500, Chad J wrote:
[...]
But what do you say to the notion of isolation? someFunc is
isolated from riskyShenanigans becuase it /knows/ what state is
touched by riskyShenanigans. If riskyShenanigans does something
strange and unexpected, and yes, it does
Chad J:
I can't seem to download the PDF... it always gives me just two bytes.
But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:
There are some links here:
http://d.puremagic.com/issues/show_bug.cgi?id=4571
Bye,
bearophile
On Mar 6, 2012, at 6:29 PM, Walter Bright newshou...@digitalmars.com wrote:
On 3/6/2012 5:29 PM, Chad J wrote:
But what do you say to the notion of isolation? someFunc is isolated from
riskyShenanigans becuase it /knows/ what state is touched by
riskyShenanigans.
If riskyShenanigans does
On 3/6/2012 8:05 PM, Walter Bright wrote:
What I'm talking about is the idea that one can recover from seg faults
resulting from program bugs.
I've written about this before, but I want to emphasize that attempting to
recover from program BUGS is the absolutely WRONG way to go about writing
On 3/6/2012 7:08 PM, Sean Kelly wrote:
Minor point, but some apps are designed such that segfaults are intended. I
worked on a DB that dynamically mapped memory in the segfault handler and
then resumed execution. Since D is a systems languages, very few assumptions
can be made about error
Oh alright. Then we're in complete agreement.
On Mar 6, 2012, at 8:05 PM, Walter Bright newshou...@digitalmars.com wrote:
On 3/6/2012 7:08 PM, Sean Kelly wrote:
Minor point, but some apps are designed such that segfaults are intended. I
worked on a DB that dynamically mapped memory in the
On 2012-03-05 07:25, Walter Bright wrote:
On 3/4/2012 6:31 PM, Chad J wrote:
class Bar
{
int foo;
}
void main()
{
Bar bar;
try {
bar.foo = 5;
} catch ( Exception e ) {
writefln(%s,e);
}
}
DMD 2.057 on Gentoo Linux, compiled with -g -debug. It prints this:
Segmentation fault
Very frustrating!
On Monday, 5 March 2012 at 09:09:30 UTC, Jacob Carlborg wrote:
On 2012-03-05 07:25, Walter Bright wrote:
[…]
run (run your program)
bt (print a backtrace)
quit (exit gdb)
[…]
Is demangling supposed to work on Mac OS X?
As the D demangling support was added in GDB 7.something,
unfortunately
On Monday, 5 March 2012 at 00:33:18 UTC, Nathan M. Swan wrote:
On Saturday, 3 March 2012 at 02:51:41 UTC, Walter Bright wrote:
Adding in software checks for null pointers will dramatically
slow things down.
What about the debug/release difference? Isn't the point of
debug mode to allow
On 3/4/2012 11:50 PM, Chad J wrote:
Problems:
- I have to rerun the program in a debugger to see the stack trace. This is a
slow workflow. It's a big improvement if the segfault is hard to find, but only
a small improvement if the segfault is easy to find. Very bad if I'm prototyping
No hardware support for them, so no choice.
I am just going to leave this here...
*Fast Bounds Checking Using Debug Register*
http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
Le 03/03/2012 21:10, Timon Gehr a écrit :
On 03/03/2012 09:00 PM, deadalnix wrote:
Le 03/03/2012 20:06, Walter Bright a écrit :
On 3/3/2012 2:13 AM, bearophile wrote:
Walter:
Adding in software checks for null pointers will dramatically slow
things
down.
Define this use of dramatically in
On 2012-03-05 11:38, Walter Bright wrote:
On 3/4/2012 11:50 PM, Chad J wrote:
I'm pretty sure other languages like C# and Java get this right.
Haven't used
those two in a while though. Haxe... totally got this right. Also
Actionscript 3
by proxy. Hell, even Synergy/DE, the DIBOL (!!) derivative
On Mon, 05 Mar 2012 10:43:22 +0100, David Nadlinger s...@klickverbot.at
wrote:
On Monday, 5 March 2012 at 09:09:30 UTC, Jacob Carlborg wrote:
On 2012-03-05 07:25, Walter Bright wrote:
[…]
run (run your program)
bt (print a backtrace)
quit (exit gdb)
[…]
Is demangling supposed to work on
Personally I'd love to get more info about out-of-bounds errors. E.g.
for arrays, which index the code attempted to access, and for hashes
which key.
Sure it's easy to use an enforce, but I'd rather have that inserted in
debug builds with bounds checking anyway. For example:
void main()
{
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix deadal...@gmail.com wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
Isn't it quite unsafe to throw an exception in a signal ?
One does not need to throw an exception. Just print a stack trace. I've
advocated for this multiple times. I
On Mon, Mar 05, 2012 at 02:50:25AM -0500, Chad J wrote:
[...]
Problems:
- I have to rerun the program in a debugger to see the stack trace.
Nope. You can run it on a dumped core.
[...]
- It only gives one line number. I imagine there's a way to get it to
spill the rest? At least it's the
On Mon, Mar 05, 2012 at 02:30:14PM +0100, Andrej Mitrovic wrote:
Personally I'd love to get more info about out-of-bounds errors. E.g.
for arrays, which index the code attempted to access, and for hashes
which key.
Personally, I'd love to see D's added string capabilities put to good
use in
On Monday, 5 March 2012 at 06:19:53 UTC, Chad J wrote:
That's cool. Maybe someone should stick it in Phobos?
I just made a patch and sent it up. It'll have to be
reviewed by the others, but I expect we'll have something
in std.typecons for the next release.
I also didn't know about
On 3/5/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
snip
Yep, agreed with everything you've said.
Also, I find your message signatures amusing. :P
Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix deadal...@gmail.com wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
Isn't it quite unsafe to throw an exception in a signal ?
One does not need to throw an exception. Just print a stack
On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
On 2012-03-05 11:38, Walter Bright wrote:
Notably, C and C++ do not do what you suggest.
Just because C and C++ do something in a certain way doesn't make it a valid
reason to do the same thing in D.
I think this is an argument we need to stop using
On 3/5/2012 8:07 AM, H. S. Teoh wrote:
A file not found exception should tell you what the offending filename is.
std.file.read(adsfasdf) gives:
std.file.FileException@std\file.d(305): adsfasdf: The system cannot find the
file specified.
On Mon, Mar 05, 2012 at 11:06:40AM -0800, Walter Bright wrote:
On 3/5/2012 8:07 AM, H. S. Teoh wrote:
A file not found exception should tell you what the offending filename is.
std.file.read(adsfasdf) gives:
std.file.FileException@std\file.d(305): adsfasdf: The system cannot
find the file
On Mon, Mar 05, 2012 at 06:12:43PM +0100, Andrej Mitrovic wrote:
[...]
Also, I find your message signatures amusing. :P
I have a file of amusing quotes that I collected over the years from
various sources (including some not-so-funny ones I made up myself), and
a 1-line perl script hooked to my
Walter Bright newshou...@digitalmars.com wrote in message
news:jj32l2$1dk$1...@digitalmars.com...
On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
On 2012-03-05 11:38, Walter Bright wrote:
Notably, C and C++ do not do what you suggest.
Just because C and C++ do something in a certain way doesn't
Walter Bright newshou...@digitalmars.com wrote in message
news:jj252v$15vf$1...@digitalmars.com...
On 3/4/2012 11:50 PM, Chad J wrote:
Problems:
- I have to rerun the program in a debugger to see the stack trace. This
is a
slow workflow. It's a big improvement if the segfault is hard to
On 2012-03-05 20:02, Walter Bright wrote:
On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
On 2012-03-05 11:38, Walter Bright wrote:
Notably, C and C++ do not do what you suggest.
Just because C and C++ do something in a certain way doesn't make it a
valid
reason to do the same thing in D.
I
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:ewuffoakafwmuybbz...@forum.dlang.org...
On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
It's that I simply cannot expect users to run my code in a debugger.
:) I'm lucky if I can get more from my users than
the site doesn't
Walter Bright newshou...@digitalmars.com wrote in message
news:jiunst$qrm$1...@digitalmars.com...
3. Intercepting and recovering from seg faults, div by 0, etc., all sounds
great on paper. In practice, it is almost always wrong. The only exception
(!) to the rule is when sandboxing a plugin
On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix deadal...@gmail.com wrote:
Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix deadal...@gmail.com
wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
Isn't it quite unsafe to throw an exception
Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix deadal...@gmail.com wrote:
Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix deadal...@gmail.com
wrote:
Le 02/03/2012 15:37, Jacob Carlborg a écrit :
Isn't it quite
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 3/4/2012 11:50 PM, Chad J wrote:
Problems:
- I have to rerun the program in a debugger to see the stack trace.
This is a
slow workflow. It's a big improvement if the segfault is hard to find,
but only
On Mon, Mar 05, 2012 at 05:31:34PM -0500, Steven Schveighoffer wrote:
[...]
I wholeheartedly agree that we should use the hardware features that
we are given, and that NullPointerException is not worth the bloat.
But we should be doing *something* better than just printing
Segmentation Fault.
On Monday, March 05, 2012 15:05:57 Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:jiunst$qrm$1...@digitalmars.com...
3. Intercepting and recovering from seg faults, div by 0, etc., all sounds
great on paper. In practice, it is almost always wrong. The
1 - 100 of 174 matches
Mail list logo
