"Check the Console"? How do I do that? What console are you
referring to?
Also, why is this installer on the official-looking download page
if it doesn't work? Should whoever is in control of the page put
this other thing there instead? I have no idea how I was supposed
to know about DVM.
O
On 2012-09-17 01:33, Joseph Rushton Wakeling wrote:
If we're talking Debian, the only compilers to consider are GDC and LDC
-- DMD is non-free by Debian standards.
I'm sure the runtimes are different anyway. Although, I don't know how
LDC handles the calling convention.
--
/Jacob Carlborg
On 2012-09-17 07:49, Elias Zamaria wrote:
I am planning to try D for the first time in my life. I have a MacBook
Pro running OS X 10.6.8 (Snow Leopard).
I went on the D downloads page and clicked on the link for the dmd 2.060
installer for OS X. I opened it and double clicked on the "DMD2.pkg"
f
I am planning to try D for the first time in my life. I have a
MacBook Pro running OS X 10.6.8 (Snow Leopard).
I went on the D downloads page and clicked on the link for the
dmd 2.060 installer for OS X. I opened it and double clicked on
the "DMD2.pkg" file within it. The installer came up wit
On 9/17/12, cal wrote:
> On Sunday, 16 September 2012 at 17:38:35 UTC, deed wrote:
>> What does the nothrow stems from? Is this something new?
> The change is from this commit 4 months ago:
> 2886846a92c45d92308756cf4c077ae13f0f8460
https://github.com/D-Programming-Language/druntime/pull/225
I d
done: http://d.puremagic.com/issues/show_bug.cgi?id=8674
On 09/16/2012 05:08 PM, timotheecour wrote:
Is that a bug?
The code below returns:
"main.A!(double).A"
if we uncomment "auto c=make!A(1.0);", we get:
"main.a!(double).A"
module main;
import std.stdio;
class A(T){
T x;
this(T x){this.x=x;}
}
auto make(alias a,T...)(T args){
return new a!
ixid:
As a beginner with D I came across the advice that enum was the
correct way to specify global constants but this makes it feel
safer to use const when you want type checking and perhaps enum
isn't the right choice.
It's a safe and quite feature of D. Unfortunately for
implementation s
If this behavior is not a bug, I wonder what's the rationale, but
also, how can we have such a "make" function that doesn't mess up
the template class name depending on the order of which is used
first (the make!T variant or the new A!T) ?
Thanks, I had no idea that that was how it works, I tripped
myself up with my own assumptions so took a while to find an
error, knowing that makes it clearer.
On 09/16/2012 04:40 PM, Jonathan M Davis wrote:
> On Monday, September 17, 2012 01:03:46 ixid wrote:
>> If I use code like:
>>
>> enum ulong VAR = 10;
>>
>> I'd have expected this to be type checked when used as a ulong.
>> Instead it seems to be checked based on its absolute value and is
>> accep
On Monday, September 17, 2012 01:03:46 ixid wrote:
> If I use code like:
>
> enum ulong VAR = 10;
>
> I'd have expected this to be type checked when used as a ulong.
> Instead it seems to be checked based on its absolute value and is
> accepted for a function like:
>
> void fun(int n) {
> /
On 16/09/12 12:25, Jacob Carlborg wrote:
The runtimes are slightly different and the calling conventions are sometimes
different. For example, GDC uses the C calling convention of the system wheres
DMD uses a slightly modified version.
If we're talking Debian, the only compilers to consider are
If I use code like:
enum ulong VAR = 10;
I'd have expected this to be type checked when used as a ulong.
Instead it seems to be checked based on its absolute value and is
accepted for a function like:
void fun(int n) {
// Do stuff
}
If the value of VAR is set to more than int.max then t
On Sunday, 16 September 2012 at 22:08:53 UTC, deed wrote:
Exactly. I couldn't remember seeing this error before.
I've only used the dsource Win32 bindings, because there is often
stuff missing from the phobos ones:
http://www.dsource.org/projects/bindings/wiki/WindowsApi
But I don't underst
Exactly. I couldn't remember seeing this error before.
On Sunday, 16 September 2012 at 17:38:35 UTC, deed wrote:
What does the nothrow stems from? Is this something new?
Isn't the real question why the wndProc function is expected to
be nothrow?
The change is from this commit 4 months ago:
2886846a92c45d92308756cf4c077ae13f0f8460
On Sunday, 16 September 2012 at 21:12:42 UTC, deed wrote:
I did, but then I am not able to use writeln for debugging.
Is this restriction something new?
nothrow just means the function itself should not *exit* with an
exception. It is still legally allowed to call a throwing
function, provide
But why is the wndProc function nothrow?
Why do I have to mark it with nothrow?
deed:
I did, but then I am not able to use writeln for debugging.
writeln is a "throwing" function, so you can't use it inside a
nothrow function.
Is this restriction something new?
It's not new. I think writeln was always "throwing", since the
creation of "nothrow".
Bye,
bearophile
I did, but then I am not able to use writeln for debugging.
Is this restriction something new?
On Sunday, 16 September 2012 at 18:20:49 UTC, Jesse Phillips
wrote:
I'm thinking I this is supposed to be a compiler error and I
should report as a bug:
"It is illegal for a GotoStatement to be used to skip
initializations."
void main() {
goto b;
int num = 5;
b:
On 16-09-2012 19:39, deed wrote:
I get this error from a minimal windows example:
import core.runtime;
import std.c.windows.windows;
import std.string;
pragma(lib, "gdi32.lib");
extern (Windows)
{
int WinMain( ... ) { ... }
HRESULT appMain( ... ) {
...
WNDCLASS wc;
...
wc.l
I'm thinking I this is supposed to be a compiler error and I
should report as a bug:
"It is illegal for a GotoStatement to be used to skip
initializations."
void main() {
goto b;
int num = 5;
b:
num = 7;
}
I get this error from a minimal windows example:
import core.runtime;
import std.c.windows.windows;
import std.string;
pragma(lib, "gdi32.lib");
extern (Windows)
{
int WinMain( ... ) { ... }
HRESULT appMain( ... ) {
...
WNDCLASS wc;
...
wc.lpfnWndProc = &wndProc;
...
}
HRESU
On 2012-09-16 09:59, Thomas Koch wrote:
Hi,
I've started a discussion about packaging D libraries and programs for
Debian:
http://code.google.com/p/d-apt/issues/detail?id=1
From this discussion I learned, that it would make a difference which
version of which compiler created a library. Isn't
Hi,
I've started a discussion about packaging D libraries and programs for
Debian:
http://code.google.com/p/d-apt/issues/detail?id=1
>From this discussion I learned, that it would make a difference which
version of which compiler created a library. Isn't it that it doesn't matter
which C compi
27 matches
Mail list logo