On Wednesday, 27 August 2014 at 05:45:34 UTC, eles wrote:
While this may be true in this case, I think that, in general,
you cannot draw such a clear line between what's recoverable
and what's not. If you really want to push things to the
extreme, the sole unrecoverable error shall be
On 23/08/14 19:50, jicman wrote:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Does the following make any difference?
const Size DEFAULT_SCAL = Size(5, 13)
--
/Jacob Carlborg
On 27/08/14 04:38, jicman wrote:
I wish I knew. :-( Above, in this same post I pasted all lines that had
Size and right below it all lines that had size. These are all the
places where Size is found. If you can tell me which one you think it
is, I can grab that piece of the code.
I found
On 8/27/2014 2:39 PM, Vladimir Panteleev wrote:
On Monday, 25 August 2014 at 03:19:09 UTC, Mike Parker wrote:
I use Exception for recoverable errors and Error for those that aren't.
Sorry, you're right, that description of Exception/Error is correct. But
I don't think that SDL initialization
Hi,
I'm using sdlang-d version 0.8.4
(http://code.dlang.org/packages/sdlang-d).
When I update dmd to version 2.066 today, I found that sdlang-d
won't link, with these errors:
Undefined symbols for architecture x86_64:
May be dub issue not taken updated compiler into consideration
and not rebuilding the deps. Try forcing it.
On Monday, 25 August 2014 at 17:16:10 UTC, Idan Arye wrote:
This CAN NOT BE DONE at compile-time, since the compiler
doesn't know at compile time the exact subclass of the instance
it'll get at runtime. To clarify: I'm not talking about the
creation of the multi-method mechanism - which *can*
Thanks again for all the responses. I've made tremendous
progress understanding the D build process.
I'm thinking I will probably create a more in depth GTK+ hello
world that attempts to covers some of the current D landscape.
For instance I now understand how DMD and RDMD work and how they
Hey all,
I just read the wiki article on DIP64 -
http://wiki.dlang.org/DIP64
The discrepancy between the annotation-style attributes such as
'@safe', '@property', etc and the keyword attributes 'pure' and
'nothrow' has always really bugged me ever since I started using
D.
How likely is it that
On Wed, 27 Aug 2014 13:49:47 +
Aerolite via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
The discrepancy between the annotation-style attributes such as
'@safe', '@property', etc and the keyword attributes 'pure' and
'nothrow' has always really bugged me ever since I
I get:
src\app.d(19): Error: None of the overloads of 'foo' are callable
using argument types (C3), candidates are:
src\app.d(28):main.foo(C1 c)
src\app.d(38):main.foo(C2 c)
It does work when I explicitly import c3.foo.
--- file app.d
module app;
import std.stdio;
import c3;
On Wednesday, 27 August 2014 at 13:49:48 UTC, Aerolite wrote:
Hey all,
I just read the wiki article on DIP64 -
http://wiki.dlang.org/DIP64
The discrepancy between the annotation-style attributes such as
'@safe', '@property', etc and the keyword attributes 'pure' and
'nothrow' has always really
On 8/27/2014 10:25 PM, Ryan wrote:
DSSS, XfBuild, Bud, RDMD, or premake4. Especially DSSS vs DUB. Is DUB a
replacement for DSSS?
You can look at it that way. It's both a package manager and build tool.
DSSS was abandoned long ago. Why not other tools -- XfBuild is no longer
maintained
On Wednesday, 27 August 2014 at 09:23:57 UTC, Marc Schütz wrote:
On Wednesday, 27 August 2014 at 02:16:37 UTC, Israel wrote:
On Wednesday, 27 August 2014 at 01:41:51 UTC, Messenger wrote:
Conjecture: your binary has its imports statically linked in,
and your linker doesn't remove unused code
It looks fine here, OSX 10.9.4
sdlang-d: =0.8.4
Im using DUB RC2 though
On Wednesday, 27 August 2014 at 16:24:23 UTC, Israel wrote:
On Wednesday, 27 August 2014 at 09:23:57 UTC, Marc Schütz wrote:
You could try using LDC. The latest version 0.14.0 already
uses --gc-sections automatically. (But it is based on DMD
2.065, so you cannot (yet) use all of the newest
This is something that has been on my mind since i discovered
this the other day. Does D provide automatic dereferencing for
accessing members through pointers?
Here's an example:
import core.stdc.stdlib : malloc, free;
struct Foo
{
public int bar;
}
void main(string[] args)
{
On Wed, Aug 27, 2014 at 07:25:41PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
This is something that has been on my mind since i discovered this the
other day. Does D provide automatic dereferencing for accessing
members through pointers?
[...]
Yes it does.
This is particularly
On Wednesday, 27 August 2014 at 13:49:48 UTC, Aerolite wrote:
Hey all,
I just read the wiki article on DIP64 -
http://wiki.dlang.org/DIP64
The discrepancy between the annotation-style attributes such as
'@safe', '@property', etc and the keyword attributes 'pure' and
'nothrow' has always really
On Wednesday, 27 August 2014 at 19:25:42 UTC, Gary Willoughby
wrote:
Why don't you need to dereference the pointer 'foo' to reach
its member 'bar'?
The compiler inserts the dereference for you. (It knows which
types are references and which are values and can do this
correctly) This makes
I'd be more convinced if the following statements were false:
1. Writing an automated upgrade tool is difficult
2. The compiler would have no way of knowing what @nothrow means
On Wednesday, 27 August 2014 at 19:42:40 UTC, Brian Schott wrote:
I'd be more convinced if the following statements were false:
1. Writing an automated upgrade tool is difficult
2. The compiler would have no way of knowing what @nothrow means
Oh, there's no question that having an automated
It would be nice if we could at least allow both nothrow and
@nothrow. Because nothrow is already a keyword there's no
possibility of a UDA overriding it. This would at least give
people the option of making their code look nicer.
The delete keyword is deprecated[1] and making that decision
On 08/27/2014 07:38 AM, Lemonfiend wrote:
I get:
src\app.d(19): Error: None of the overloads of 'foo' are callable using
argument types (C3), candidates are:
src\app.d(28):main.foo(C1 c)
src\app.d(38):main.foo(C2 c)
It does work when I explicitly import c3.foo.
--- file app.d
On Wednesday, 27 August 2014 at 19:36:08 UTC, Brian Schott wrote:
On Wednesday, 27 August 2014 at 19:25:42 UTC, Gary Willoughby
wrote:
Why don't you need to dereference the pointer 'foo' to reach
its member 'bar'?
The compiler inserts the dereference for you. (It knows which
types are
I've tried to express my problem in a mostly minimal example here:
https://gist.github.com/murphyslaw480/d4a5f857a104bcf62de1
The class Point has an alias this to its own property
'feature()', which returns a reference to a private member. When
I try to sort a Point[], DMD fails with mutable
rcor:
I've tried to express my problem in a mostly minimal example
here:
https://gist.github.com/murphyslaw480/d4a5f857a104bcf62de1
The class Point has an alias this to its own property
'feature()', which returns a reference to a private member.
When I try to sort a Point[], DMD fails with
On Wednesday, 27 August 2014 at 06:20:24 UTC, Jacob Carlborg
wrote:
On 23/08/14 19:50, jicman wrote:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Does the following make any difference?
const Size DEFAULT_SCAL = Size(5,
On Wednesday, 27 August 2014 at 20:17:11 UTC, Brian Schott wrote:
The delete keyword is deprecated[1] and making that decision
never broke any code.
[1] http://dlang.org/deprecate.html#delete
LOL. Yeah, we've broken code before, and Walter can be talked
into it, but it's hard, and it's only
On 8/28/2014 1:24 AM, Israel wrote:
On Wednesday, 27 August 2014 at 09:23:57 UTC, Marc Schütz wrote:
But, how would i configure dub and my dub.json to automatically
use those LDC switches if it isnt automatically built into dub?
You can pass compiler-specific flags by adding a dflags entry
On Wednesday, 27 August 2014 at 21:43:40 UTC, bearophile wrote:
It compiles if you use:
@property auto feature() const pure nothrow { return _feature; }
Otherwise I get strange errors like:
...\dmd2\src\phobos\std\exception.d(986,31): Error: pure
function 'std.exception.doesPointTo!(Point,
On Wednesday, 27 August 2014 at 19:25:42 UTC, Gary Willoughby
wrote:
I've taken a look in the std lib and the second form is used a
lot. Why don't you need to dereference the pointer 'foo' to
reach its member 'bar'?
Walter didn't want foo-bar so we have foo.bar
On Wed, 27 Aug 2014 20:17:10 +
Brian Schott via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
It would be nice if we could at least allow both nothrow and
@nothrow.
i believe this patch should be trivial. i'll try to look at this issue
closer and maybe produce another
33 matches
Mail list logo