Am 05.10.2014 02:11, schrieb David Nadlinger:
On Friday, 3 October 2014 at 23:00:53 UTC, Brian Hechinger wrote:
With my old set of packages I had no problems. I just now deleted
~/.dub and now I too get this error. Some issue with the openssl
module, yes, but what? This is a bit of an issue. :)
On Sat, 04 Oct 2014 16:52:08 +
John Colvin via Digitalmars-d-learn
wrote:
> It is a little noisy, but really very little. The only extra
> noise is the call to Afoo.
it's "very little" turns to "alot" with alot of classes with alot of
methods. and code readability suffers even from one such
On Friday, 3 October 2014 at 23:00:53 UTC, Brian Hechinger wrote:
With my old set of packages I had no problems. I just now
deleted
~/.dub and now I too get this error. Some issue with the openssl
module, yes, but what? This is a bit of an issue. :)
At first glance, this seems like a forward r
Cool,thanks.
Btw., there could be more special chars to encode...replace
beside ":"... like / @ and so on... see also
http://www.cyberciti.biz/faq/unix-linux-export-variable-http_proxy-with-special-characters/
for the background
Regards
notna
On Friday, 3 October 2014 at 11:13:11 UTC, Marc
BTW: Is there a preferred LLVM version to build ldc against?
Are there any fundamental pros to build with 3.5 instead of 3.4,
for instance, with regards to code generation quality?
I'm asking because I can only make the ldc build work with LLVM
3.4 on Ubuntu 14.04.
On Sunday, 28 September 2014 at 08:01:00 UTC, Nordlöw wrote:
I realized that this is the reason why msgpack doesn't
correctly pack std.container.Array.
I've added support for std.container.Array in msgpack-d by hand at
https://github.com/nordlow/msgpack-d/commits/container-support
On Saturday, 4 October 2014 at 15:54:26 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 15:29:55 +
John Colvin via Digitalmars-d-learn
wrote:
I don't really see the point though.
class A
{
void foo(int a) { Afoo(this, a); }
}
then declare and define Afoo however you
On Sat, 04 Oct 2014 15:29:55 +
John Colvin via Digitalmars-d-learn
wrote:
> I don't really see the point though.
>
> class A
> {
> void foo(int a) { Afoo(this, a); }
> }
>
> then declare and define Afoo however you like.
it's noisy hackery and namespace pollution. sure i can do this an
On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 11:01:28 +
John Colvin via Digitalmars-d-learn
wrote:
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
> On Sat, 04 Oct 2014 10:27:16 +
> John Col
On 10/4/2014 6:40 PM, Bauss wrote:
I am not able to run the output file compiled. I am not sure if it might
be an error with my commandline or not.
Operating System: Windows 8
Commandline Arguments Try1: -c hello.d out\hello.exe
Commandline Arguments Try2: -c hello.d -m32 out\hello.exe
Your c
On Sat, 04 Oct 2014 11:01:28 +
John Colvin via Digitalmars-d-learn
wrote:
> On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
> Digitalmars-d-learn wrote:
> > On Sat, 04 Oct 2014 10:27:16 +
> > John Colvin via Digitalmars-d-learn
> >
> > wrote:
> >
> >> Sorry, but that's just not
On Saturday, 4 October 2014 at 09:40:24 UTC, Bauss wrote:
I am not able to run the output file compiled. I am not sure if
it might be an error with my commandline or not.
Operating System: Windows 8
Commandline Arguments Try1: -c hello.d out\hello.exe
Commandline Arguments Try2: -c hello.d -m32
On Saturday, 4 October 2014 at 11:01:30 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 10:27:16 +
John Colvin via Digitalmars-d-learn
wrote:
Sorry, but that's just not how it works. There is no
requirement f
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 10:27:16 +
John Colvin via Digitalmars-d-learn
wrote:
Sorry, but that's just not how it works. There is no
requirement for the definition of a function to be found in
the same compilat
On Saturday, 4 October 2014 at 10:37:40 UTC, eles wrote:
On Saturday, 4 October 2014 at 10:27:18 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote:
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
On Sat, 04 Oct 2014 10:37:39 +
eles via Digitalmars-d-learn wrote:
> No "extern" required?...
nope.
signature.asc
Description: PGP signature
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 10:27:16 +
John Colvin via Digitalmars-d-learn
wrote:
is there any possibility to declare *class* *method* in one
Yes, that too. Is even worse.
On Saturday, 4 October 2014 at 10:27:18 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote:
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
So the compiler has no way of knowing whether you've fo
On Saturday, 4 October 2014 at 10:27:18 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote:
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
class ShapeSurface(T) {
public:
int formula();
On Sat, 04 Oct 2014 10:27:16 +
John Colvin via Digitalmars-d-learn
wrote:
> Sorry, but that's just not how it works. There is no requirement
> for the definition of a function to be found in the same
> compilation unit as it's declaration.
is there any possibility to declare *class* *method
On Saturday, 4 October 2014 at 09:39:12 UTC, Chris
Nicholson-Sauls wrote:
In the original you are casting an int to a pointer type, which
is legitimate (although rarely a good idea). The other side of
the matter is simply precedence.
cast(T)a.b;
Is really the same as:
cast(T)(a.b);
But th
On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote:
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
class ShapeSurface(T) {
public:
int formula();
that means you have a definition of formula elsewhere (which
th
On Saturday, 4 October 2014 at 09:39:12 UTC, Chris
Nicholson-Sauls wrote:
In the original you are casting an int to a pointer type, which
is legitimate (although rarely a good idea). The other side of
the matter is simply precedence.
cast(T)a.b;
Is really the same as:
cast(T)(a.b);
Yes, y
I am not able to run the output file compiled. I am not sure if
it might be an error with my commandline or not.
Operating System: Windows 8
Commandline Arguments Try1: -c hello.d out\hello.exe
Commandline Arguments Try2: -c hello.d -m32 out\hello.exe
hello.d:
import std.stdio;
void main()
{
In the original you are casting an int to a pointer type, which
is legitimate (although rarely a good idea). The other side of
the matter is simply precedence.
cast(T)a.b;
Is really the same as:
cast(T)(a.b);
25 matches
Mail list logo
