On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote:
Still same problem, You can`t allocate more then 16M on stack.
Use dynamic allocation
I don't think new MyStruct allocates on stack, actually
allocating ~16MB on stack will immediatelly crash the program
which is not the case
V Sat, 01 Aug 2015 19:21:36 +
NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno:
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
No you don't. You still use static allocation for array
Can clarify why does that happen and I still suspect it's a
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote:
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
Sorry, I can't see _the_ point in that. I understand that could
be a problem if it was a global array but this scenery is
completely wrong in my view. I'm already going to
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
No you don't. You still use static allocation for array
Can clarify why does that happen and I still suspect it's a
static allocation it would increase output exe if it was really
that static..?
V Sat, 01 Aug 2015 19:16:16 +
NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno:
On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote:
Still same problem, You can`t allocate more then 16M on stack.
Use dynamic allocation
I don't think new MyStruct
On Saturday, 1 August 2015 at 19:33:26 UTC, Daniel Kozak wrote:
My fault It is not on stack, but still it is a static allocation
I think you're misusing static allocation and static
declaration for each other.
V Sat, 01 Aug 2015 18:07:50 +
NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno:
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by
On Wednesday, 15 July 2015 at 15:58:17 UTC, Daniel Kozák wrote:
On Wed, 15 Jul 2015 15:45:43 +
rumbu ru...@rumbu.ro wrote:
struct S { int a, b; }
auto s = cast(S)10;
//compiles and sets s.a to 10.
It works also for any other type, if the structure contains a
member of that type in the
struct S { int a, b; }
auto s = cast(S)10;
//compiles and sets s.a to 10.
It works also for any other type, if the structure contains a
member of that type in the first position.
Is this normal behaviour?
in the first position.
Is this normal behaviour?
I would say this is a bug. As far as I know, it's not defined in the
spec.
-Steve
It is defined:
Casting a value v to a struct S, when value is not a struct of the same
type, is equivalent to:
S(v)
On 7/15/15 11:45 AM, rumbu wrote:
struct S { int a, b; }
auto s = cast(S)10;
//compiles and sets s.a to 10.
It works also for any other type, if the structure contains a member of
that type in the first position.
Is this normal behaviour?
I would say this is a bug. As far as I know, it's
On Wed, 15 Jul 2015 15:45:43 +
rumbu ru...@rumbu.ro wrote:
struct S { int a, b; }
auto s = cast(S)10;
//compiles and sets s.a to 10.
It works also for any other type, if the structure contains a
member of that type in the first position.
Is this normal behaviour?
Yes, this is OK
On Monday, 29 June 2015 at 14:28:06 UTC, anonymous wrote:
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo
works just fine.
(assuming that its base class constructor is pure),
since theoretically, it should be able to be pure, but that would be a
change in the language. What you're seeing is not a bug. It's how the
current design works.
- Jonathan M Davis
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo works
just fine.
https://issues.dlang.org/show_bug.cgi?id=14751
I'd say bug, I think the array function is trying an optimization
it shouldn't be trying for immutable classes.
you're seeing is not a bug.
It's how the current design works.
- Jonathan M Davis
No it is a bug in std.conv.emplaceRef or more probably in std.array.
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
/usr/include/dmd/phobos/std/conv.d(4028): Error: cannot
implicitly convert expression
On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote:
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
Somehow reminds me of this lambda:
On Friday, 15 May 2015 at 08:44:41 UTC, Ivan Kazmenko wrote:
Somehow reminds me of this lambda:
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L127-L128
Maybe it generally blocks for initialization of variables:
On 05/14/2015 03:39 PM, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes,
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something
On Thursday, 14 May 2015 at 22:55:43 UTC, Ali Çehreli wrote:
Yes, it is weird but that value happens to be the address of
the function. Here is another test:
import std.stdio;
void foo() pure nothrow @nogc @safe
{}
void main()
{
void printInfo(T)(T t)
{
writefln(%s %s,
On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote:
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
You told it to output a function literal, so it did.
(That or you told it to output a
Turns out that I can put into the function writeln almost any
design language:
-
import std.stdio;
void main() {
writeln( { int n = 5; } );
}
-
http://ideone.com/Rp7gZ2
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler will not be able to distinguish the literal from
the ordinary
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types (int)
It is a concept called name
On Sunday, May 10, 2015 10:48:33 Ali Çehreli via Digitalmars-d-learn wrote:
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Jack Applegame wrote:
test(10); // error
One can import the declaration by using an alias:
class A {
void test(int) {}
}
class B : A {
alias test= super.test;
void test() {
super.test(1); // compiles
test(10); // compiles
}
}
-manfred
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types
(int)
Ok, it's a feature. Thanks.
this in my class:
class Parent {
class Child { }
mixin MyMixin;
}
mixin Template MyMixin() {
private alias T = ...; // the culprit!
}
Should the private alias be able to escape? Is this a bug or
expected behavior?
Also, is there a nice way to create template-level aliases in
mixin
!
Wat???
After much confusion, I finally discovered this in my class:
class Parent {
class Child { }
mixin MyMixin;
}
mixin Template MyMixin() {
private alias T = ...; // the culprit!
}
Should the private alias be able to escape? Is this a bug or
expected behavior?
Also
that that entails wraparound, because we're dealing with
fixed-length integers.
This isn't a bug.
- Jonathan M Davis
Thank you all for your answers. I use long.max as an initializer for my
data sorted by time to place new data to back of the queue. So the only
inconvinience for me is a diagnostic
with
fixed-length integers.
This isn't a bug.
- Jonathan M Davis
On Tuesday, 31 March 2015 at 11:51:26 UTC, drug wrote:
import std.datetime;
import std.stdio;
void main()
{
long.max.SysTime.toISOExtString.writeln;
}
dmd 2.065 (dpaste.dzfl.pl):
+29228-09-14T02:48:05.4775807
dmd v2.067-devel-c6b489b (using Digger):
-29227-04-20T00:11:54.5224191
import std.datetime;
import std.stdio;
void main()
{
long.max.SysTime.toISOExtString.writeln;
}
dmd 2.065 (dpaste.dzfl.pl):
+29228-09-14T02:48:05.4775807
dmd v2.067-devel-c6b489b (using Digger):
-29227-04-20T00:11:54.5224191
could somebody confirm it?
On Friday, 27 March 2015 at 00:50:34 UTC, Hugo wrote:
On Thursday, 26 March 2015 at 12:29:03 UTC, John Colvin wrote:
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between
On Friday, 27 March 2015 at 08:43:56 UTC, John Colvin wrote:
Think of it as compile-time arguments and run-time arguments.
First set of parenthesis are compile-time, second are run-time.
The parenthesis are optional for compile-time arguments iff
there's only one of them.
I really
.
Perhaps I have found a bug. Actually I am not sure because I am
not yet familiar with the way to use templates, so there is the
possibility that I am using incorrect arguments.
If only the documentation and/or test units were more clear...
On Thursday, 26 March 2015 at 10:07:07 UTC, Hugo wrote:
If only the documentation and/or test units were more clear...
OK, I made a simpler test, using an example from the
documentation:
void main() {
import std.stdio, std.array, std.bitmanip;
auto buffer = appender!(const
to the
slice, but that may be ugly/hard to do.
Hmm... isnt that't what the std.bitmanip.write function is for? It even
provides an index.
Quite possibly write and append do the same thing for arrays because of
the way slices support the output range idiom.
Perhaps I have found a bug
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
On Thursday, 26 March 2015 at 10:07:07 UTC, Hugo wrote:
If only the documentation and/or test units were more clear...
OK, I made a simpler test, using an example from the
documentation:
void main() {
import std.stdio, std.array,
On Thursday, 26 March 2015 at 12:29:03 UTC, John Colvin wrote:
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes of
invocation...
void main() {
import
On Monday, 16 March 2015 at 20:03:36 UTC, Marc Schütz wrote:
You can file bugs against component websites there.
Thanks.
This has already been fixed AFAIK, it's just not yet deployed.
OK.
On Monday, 16 March 2015 at 20:00:24 UTC, Dennis Ritchie wrote:
I don't know where to write about a bug on the website, so I
decided to write in this section.
This is the official bug tracker:
https://issues.dlang.org/enter_bug.cgi
You can file bugs against component websites
I don't know where to write about a bug on the website, so I
decided to write in this section.
This page is not displayed correctly:
http://dlang.org/phobos/std_format.html
On Sunday, February 22, 2015 17:45:48 Ali Çehreli via Digitalmars-d-learn wrote:
On 02/22/2015 03:17 PM, Martin Nowak wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
You should use shared static this to initialize
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
You should use shared static this to initialize immutable
variables.
On Monday, 23 February 2015 at 04:04:08 UTC, ketmar wrote:
On Mon, 23 Feb 2015 02:15:08 +, stewarth wrote:
On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote:
On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak
wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth
On 02/22/2015 03:17 PM, Martin Nowak wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
You should use shared static this to initialize immutable variables.
Is that because they are not thread-local? If so, initializing
On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
You should use shared static this to initialize immutable
variables.
OK, thanks a lot for the help.
Cheers,
On Mon, 23 Feb 2015 02:15:08 +, stewarth wrote:
On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote:
On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
On Monday, 23 February 2015 at 02:10:09 UTC, amber wrote:
On Sunday, 22 February 2015 at 23:17:33 UTC, Martin Nowak wrote:
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote:
I've gone with static this() approach and it works.
You should use shared static this to initialize
On Thursday, 19 February 2015 at 07:46:51 UTC, Ali Çehreli wrote:
On 02/18/2015 10:39 PM, stewarth wrote:
This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
struct B {
A* a;
In any case, that must be immutable(A)*.
}
static immutable B
On 02/18/2015 10:39 PM, stewarth wrote:
This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
struct B {
A* a;
In any case, that must be immutable(A)*.
}
static immutable B[] someB = [{a:someA[0]}, {a:someA[1]}];
I want it to initialize
, someB);
}
---
Error under DMD 2.067-b2:
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][0]'
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][1]'
Is this a bug, or a deliberate change?
I'm thinking a bug because I want
On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote:
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new
On Friday, 30 January 2015 at 13:56:17 UTC, anonymous wrote:
On Friday, 30 January 2015 at 13:39:05 UTC, BBaz wrote:
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto
On 30.01.2015 16:56, anonymous wrote:
Besides, it's a bad idea to call a member init, because it steals the
name of the default initializer. It doesn't override the default
initializer, it just takes its name. The compiler should not accept it,
in my opinion.
Good remark! I'll rename it.
On 30.01.2015 17:04, BBaz wrote:
Yes, that was the point: bad idea to call a member init.
But I've missed something with inference of return type...
let's call this the BMS : big-mouth-syndrom...
I didn't know it could be ommitted...I thought it could be if the
function has
, Phobos bug I think.
The real problem is if I comment my unittest out then it compiles. Why
my unittest causes this behaviour?
= new Container();
return instance;
}
}
unittest
{
alias IntManager = Manager!int;
auto im = IntManager.init();
}
void main() {}
```
run it using
rdmd -unittest filename.d
it fails in a RedBlackTree unittest with 2.065 and 2.066, is it
bug?
Reduced:
import
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you tried
---
static typeof(this) init()
{
auto instance = new
On Friday, 30 January 2015 at 13:34:57 UTC, drug wrote:
On 30.01.2015 16:31, BBaz wrote:
On Friday, 30 January 2015 at 12:32:05 UTC, drug wrote:
static init()
{
auto instance = new typeof(this)();
instance._cont = new Container();
return instance;
}
have you
strikes again.)
That test looks wrong. So, Phobos bug I think.
I guess it is bug in this unittest, because it fails if I set predicate
less to ab instead of a b. Spaces rule in this case.
(equal(r, vals));
(Tab + Enter strikes again.)
That test looks wrong. So, Phobos bug I think.
I guess it is bug in this unittest, because it fails if I set predicate
less to ab instead of a b. Spaces rule in this case.
Filed a bug https://issues.dlang.org/show_bug.cgi?id=14082
;
}
}
unittest
{
alias IntManager = Manager!int;
auto im = IntManager.init();
}
void main() {}
```
run it using
rdmd -unittest filename.d
it fails in a RedBlackTree unittest with 2.065 and 2.066, is it bug?
On Tuesday, 27 January 2015 at 12:02:59 UTC, Vladimir Panteleev
wrote:
Always. But the check seems very simple, and is easily
circumvented. This compiles:
byte[] func() {
byte[1024] buffer;
auto p = buffer[0..3];
return p;
}
I think this is the first step of a long and difficult way.
Hi!
I thought at least in safe mode this code will not compile or I
get warning:
byte[] func() @safe {
byte[1024] buffer;
return buffer[0..3];
}
void main() {
auto b = func();
b[0] = 1;
}
But no any error. Dlang do not catch this?
WBR,
Fyodor.
On Tuesday, 27 January 2015 at 11:41:21 UTC, Fyodor Ustinov wrote:
byte[] func() @safe {
byte[1024] buffer;
return buffer[0..3];
}
void main() {
auto b = func();
b[0] = 1;
}
In 2.067, this is an error:
test.d(4,9): Error: escaping reference to local variable buffer
On Tuesday, 27 January 2015 at 11:51:43 UTC, Vladimir Panteleev
wrote:
In 2.067, this is an error:
test.d(4,9): Error: escaping reference to local variable buffer
Always or only in safe mode?
On Tuesday, 27 January 2015 at 12:01:11 UTC, Fyodor Ustinov wrote:
On Tuesday, 27 January 2015 at 11:51:43 UTC, Vladimir Panteleev
wrote:
In 2.067, this is an error:
test.d(4,9): Error: escaping reference to local variable buffer
Always or only in safe mode?
Always. But the check seems
Vladimir Panteleev:
But the check seems very simple, and is easily circumvented.
This compiles:
byte[] func() {
byte[1024] buffer;
auto p = buffer[0..3];
return p;
}
I guess such bugs will be detected (in safe code only!) after the
implementation of: http://wiki.dlang.org/DIP69
file a bug at https://issues.dlang.org/. And since you seem
to know how to fix it, maybe you can make a pull request via GitHub,
too?
https://issues.dlang.org/show_bug.cgi?id=14007
I am not familiar with Github's pull system etc. So, I will prepare
the fixed code and attach it on issue.
Fixed
On Monday, 19 January 2015 at 05:35:46 UTC, tcak wrote:
Fixed shm.d file is put on issue page. If someone could put a
pull request on Github with it.
shmid_ds is on version(linux) part is fixed up on it, and works
properly. But tested on 64-bit system only.
Aand it's in:
On Monday, 19 January 2015 at 04:18:47 UTC, tcak wrote:
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote:
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at https
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote:
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at https://issues.dlang.org/. And since you
seem to know how to fix it, maybe you
I create a shared memory by using shmget. And attach to it by
using shmat.
Finally, I use shmctl to get statistics to learn number of
attachments to
that shared memory. According to documentation
(linux.die.net/man/2/shmat), number of attachments should be 1.
Same codes, C returns 1, D
On Sunday, 18 January 2015 at 16:06:39 UTC, tcak wrote:
I create a shared memory by using shmget. And attach to it by
using shmat.
Finally, I use shmctl to get statistics to learn number of
attachments to
that shared memory. According to documentation
(linux.die.net/man/2/shmat), number of
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at https://issues.dlang.org/. And since you
seem to know how to fix it, maybe you can make a pull request via
GitHub, too?
as a dependency on my dub.json,
and I
haven't really used the library as of the time of its
building.
So, is this a bug?
Short answer:
Don't build with ldc.
Long answer:
http://forum.dlang.org/post/m6m5tc$2c4d$1...@digitalmars.com
Grr grr grr.
Grr Grr indeed.
Now to figure out how to switch dub
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json, and
I haven't really used the library as of the time of its building.
So, is this a bug?
On 26/12/2014 6:58 p.m., Jack wrote:
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json, and I
haven't really used the library as of the time of its building.
So, is this a bug?
Short
the library as of the time of its building.
So, is this a bug?
Short answer:
Don't build with ldc.
Long answer:
http://forum.dlang.org/post/m6m5tc$2c4d$1...@digitalmars.com
Grr grr grr.
Grr Grr indeed.
Now to figure out how to switch dub to dmd again.
Thanks
wrote:
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!(readTinyInt, ubyte)
is not defined
template insertReadMethods(string MethodName, DataType)
{
enum insertReadMethods = ;
}
struct
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
I think I mimized the coding too much.
What I actually want to achieve is to generate read methods
in the structure for different data types (Ubyte, short, int):
I thought the
thanks a lot. That makes sense.
Kind regards
André
On Friday, 5 December 2014 at 09:29:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I think I mimized the coding too much.
What I
On Wednesday, 3 December 2014 at 18:25:41 UTC, bearophile wrote:
Ali Çehreli:
Attempting to compile with a recent dmd git head causes
segmentation fault. Any compiler crash is a compiler bug.
Please report it at
https://issues.dlang.org/
Ali
A first reduction for Bugzilla:
alias
On 12/3/14 6:09 PM, Ali Çehreli wrote:
On 12/03/2014 03:02 PM, drsneed wrote:
Check out http://dpaste.dzfl.pl/a5ada78fccf5
If my function named IWillNotCompile is run, I get an error stating
Component!int' and 'Component!int' are not compatible.
If my function named IWillCompile is run, there
On 12/04/2014 06:37 AM, Steven Schveighoffer wrote:
All that being said, what a horrible error message!
https://issues.dlang.org/show_bug.cgi?id=13818
Ali
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!(readTinyInt, ubyte)
is not defined
template insertReadMethods(string MethodName, DataType)
{
enum insertReadMethods = ;
}
struct Data
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!(readTinyInt, ubyte
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!(readTinyInt, ubyte
Hi,
Is this a bug in the compiler?
import std.stdio;
import std.typetuple;
class A {
int foo() {
return 0;
}
}
class B : A {
alias A.foo foo;
override int foo() {
return 1;
}
}
template ItemProperty(item, string
1001 - 1100 of 1912 matches
Mail list logo
