On Thursday, 16 March 2023 at 04:31:11 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
[...]
Correction.
With or without comments, mostly it doesn't compile,
occasionally it does!
I have no idea.
On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct M
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S,
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S)); //
Error: declaration `S` is alr
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3, 1
On Thursday, 15 September 2022 at 11:33:43 UTC, Dennis wrote:
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote:
I hope we have github bugs.
It's being worked on.
glad to know we are move into github.
Please help me create a bug report if who has free time and
bugs ac
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote:
I hope we have github bugs.
It's being worked on.
Please help me create a bug report if who has free time and
bugs account.
Here you go: https://issues.dlang.org/show_bug.cgi?id=23336
On Wednesday, 14 September 2022 at 14:41:38 UTC, Steven
Schveighoffer wrote:
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = {
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e = & d;
```
th
sh
Error: reinterpreting cast from
`const(validate_KnownRegex_enum_init_type)*` to
`const(upb_MiniTable_Enum)*` is not supported in CTFE
```
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e = &d.a;
```
./test.d(4): Error: expression `&c(3u, 4u).a` is not a constant
I need this to work around C struct array member like this:
```c
struct c {
uint32_t a, b;
uint32_t[] arr;
}
```
If I
On Thursday, 11 March 2021 at 17:41:27 UTC, rikki cattermole
wrote:
Try it with:
-allinst
It may just be deciding a template instance isn't required.
The error message could maybe be changed to include this? "Try
-allinst bla bla"
On Thursday, 11 March 2021 at 17:41:27 UTC, rikki cattermole
wrote:
Try it with:
-allinst
It may just be deciding a template instance isn't required.
Good workaround for such kind of bugs! )
Up to 2.063 : Failure with output: Error: unrecognized
switch '-allinst'
Since 2.064 :
Try it with:
-allinst
It may just be deciding a template instance isn't required.
On 3/11/21 8:41 AM, Iliya wrote:
> I am using dmd 2.094.1 on linux
Your program links fine for me with 2.094.2 on Linux.
Ali
On Thursday, 11 March 2021 at 17:25:35 UTC, Ali Çehreli wrote:
On 3/11/21 8:41 AM, Iliya wrote:
> I am using dmd 2.094.1 on linux
Your program links fine for me with 2.094.2 on Linux.
Ali
Thank you, Ali!
I also played with it on playground. Seems that it is a bug.
The compilation resu
y ideas on:
1. Why compiler searches for such function attributes - pure
nothrow @nogc @safe, as I don't specify them. Is this a bug or
feature?)
2. What changes are needed to compile this rather simple example.
Please, help me!
Reference to my piece of code in app.d:
struct IsEqual(
saved locally as
a ref int and then the destructor of S is called (set the local
cache to 0). Now the ref value is dereferenced and returned.
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
If this is a bug, then I don't know how to call it for the bug
tr
On Friday, 8 May 2020 at 14:32:33 UTC, kinke wrote:
On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote:
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
This is a regression, and a potentially pretty bad one, so thx
for tracking it down!
If this is a bug,
On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote:
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
This is a regression, and a potentially pretty bad one, so thx
for tracking it down!
If this is a bug, then I don't know how to call it for the bu
is called (set the local
cache to 0). Now the ref value is dereferenced and returned.
Now I am unsure if this is a bug or an undefined behavior that I
don't know.
If this is a bug, then I don't know how to call it for the bug
tracker.
I hope you can help me with this problem.
P
On 08/16/2019 02:07 PM, Andrey Zherikov wrote:
But:
- if I change line (1) to `auto args = ["app", "--foo", "foo", "--bar",
"bar"];` then this code works.
- if I remove line (2) then this code works.
Yes, it's a bug.
Another workaro
Here is the code I have which doesn't work:
```
string[] foo;
string[] bar;
auto args = ["app", "--bar", "bar", "--foo", "foo"]; // (1)
import std.getopt;
getopt(args,
std.getopt.config.stopOnFirstNonOption, // (2)
"foo", &foo,
"bar", &bar);
```
The error I s
uot;a");
}
This code does not even skip the 'int x;' declaration and
initialization - it happens the 2nd time after the goto to W -
but still errors with exactly the same error i.e. 'goto skips
declaration of variable x'. so this is _clearly_ a bug in the
compiler (r
teaching me something when I have 20+ years of programming
experience.
You don't realize you are just getting in my way. I want real
fucking help. I don't want to be taught programming 101. What I
want is someone to read what I say and interpret it the best they
possibly can with th
e dealing with a compiler bug or not. And if you
are, unless you're dealing with one that someone else already has found
independently and reported with a test case, somehow, you're going to need
to reduce it enough to be able to create a bug report with an example if you
want it fixed. A
is not working for me to do so at this point in time, but it
would be nice for sake of argument to assume I'm right...).
> Regardless, if you want to actually have your problem fixed,
> you're going to need to provide a reproducible test case in
> a bugzilla report, even i
ot;business" elsewhere if I don't
> like it.
>
> What I am talking about is about an obvious error(Ok, I haven't
> produced a simplified test case but dustmite or visual D is not
> working for me to do so at this point in time, but it would be
> nice for sake of arg
case in a
bugzilla report, even if it's large, otherwise no one is going
to be able to track it down for you.
That's easier said than done. I wasn't expecting anyone to be
able to fix a bug that can't be reproduced.
What I expect is that, given my assumptions that I
On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via Digitalmars-
d-learn wrote:
> Don't let their psychobabble fool you. They are wrong and you
> were right from the start.
...
> Case A:
> {
> if (true) goto X;
> int x;
> }
> X:
>
>
> Case B:
> {
> if (true) goto X;
>
approach. However, this:
{
if (true) goto X;
T x;
} // x.__dtor
X:
should not error at all, since goto skips both initialization and
use. No one is disputing that. From your posts if I understand
correctly it's that second case that errors in your code. If it
does, there'
ng" code in to a
semantically equivalent piece of code(this is known as
mathematical transformation, such as rewriting a mathematical
expression using logically valid rules) that involves no real
changes(such as adding scopes), and one fails and the other
doesn't, it means the comp
On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis
wrote:
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via
Digitalmars-d-learn wrote:
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
>> And I found a bit strange that in such code, since "x" is
>> never us
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn
wrote:
> On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
>
> wrote:
> >> And I found a bit strange that in such code, since "x" is
> >> never used, why it isn't skipped.
> >
> > It's skipped right over. The
On Tuesday, 6 November 2018 at 01:05:04 UTC, Neia Neutuladh wrote:
In C++, if you skip over `int i = 10;` it's an error, but not
if you skip over `int i;`.
In fact I agree with that rule more than the D one to be honest.
Since It isn't initialized and never used, I think a warning
should be e
On Tuesday, 6 November 2018 at 01:04:46 UTC, Stanislav Blinov
wrote:
...Even if you don't see any explicit use, it doesn't mean the
compiler doesn't see an implicit one.
Sorry I don't think that I follow that. How a compiler could see
an use when it's not being used/invoked on a program like i
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
And I found a bit strange that in such code, since "x" is
never used, why it isn't skipped.
It's skipped right over. The goto jumps out of the scope, and
the line with
int x;
is never run. In fact, if you compile with -w o
ot;);
> >>
> >> }
> >>
> >> Gives me this error: "source_file.d(4): Error: goto skips
> >> declaration of variable source.main.x at source_file.d(5)"
> >>
> >>
> >> Now, if I add a pair of brackets:
> >>
>
On Tue, 06 Nov 2018 00:33:56 +, MatheusBN wrote:
> Just to be clear, when you say "x exists at the label Q", you mean at
> the same scope, right?
The same or an outer scope. It's also invalid to write:
goto Y;
{
int x;
{
Y:
}
}
> That's interesting but a bit confusing isn't?
>
> A
On Tuesday, 6 November 2018 at 00:38:01 UTC, MatheusBN wrote:
On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov
wrote:
But here it's fine:
void main(){
{
goto Q;
S x;
} // <---
Q:
writeln("a");
}
because goto jumps over both initialization *and
On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov
wrote:
But here it's fine:
void main(){
{
goto Q;
S x;
} // <---
Q:
writeln("a");
}
because goto jumps over both initialization *and* destruction,
i.e. neither would even be performed.
I see b
uot;a");
}
Gives me this error: "source_file.d(4): Error: goto skips
declaration of variable source.main.x at source_file.d(5)"
Now, if I add a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So
t; }
>
> Gives me this error: "source_file.d(4): Error: goto skips
> declaration of variable source.main.x at source_file.d(5)"
>
>
> Now, if I add a pair of brackets:
>
> void main(){
> {
> goto Q;
> int x;
> }
> Q
ion of variable source.main.x at source_file.d(5)"
Now, if I add a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So Is this a bug?
No, it's not. Consider replacing that int with a type that ha
d a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So Is this a bug?
MatheusBN.
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
why the code bellow compiles?
D compilers are allowed to make that an error, but it might not.
With the current implementation,
dmd that.d
will compile, but
dmd -O that.d
will fail with an error. Yes, turning on optimizations h
On Monday, 22 October 2018 at 01:39:48 UTC, dangbinghoo wrote:
On Friday, 19 October 2018 at 09:08:32 UTC, Vijay Nayar wrote:
Technically the code you have is syntactically correct. You
are permitted to create a class variable without assigning it
to a class object. (Assigning it to a class o
On Friday, 19 October 2018 at 09:08:32 UTC, Vijay Nayar wrote:
Technically the code you have is syntactically correct. You
are permitted to create a class variable without assigning it
to a class object. (Assigning it to a class object would look
like "A a = new A();")
Which section of The
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd (2.082
incx(Args...)
{
void incx(T)(ref T t)
{
++t.x;
}
}
[...]
Not a bug, because when you explicitly specify template
parameters, they are specified in left-to-right order.
You have incx(T, Args...)(ref T t)
t.incx!(1, 2, 3); // 1 => T (error), 2 => Args[0], 3 => Args[1]
incx(t, 1,
), candidates are:
test.d(3): test.incx(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void incx(Args..., T)(ref T t);
This doesn't seem to work, because:
test.d(3): Error: template `test.incx(Args..., T)(ref T t)` template
tuple parameter must be last one
Hm... d
You can simply group them:
t.on!(
handlers!(
"abc", {
writeln("abc");
},
"cde", {
writeln("cde");
}
)
);
handlers!(
"abc", {
writeln("abc");
},
"cde", {
writeln("cde");
}
).bind(t);
On Tuesday, 16 October 2018 at 02:13:21 UTC, Ali Çehreli wrote:
On 10/15/2018 01:36 PM, Márcio Martins wrote:
> Considering that the declaration is legal, and that the
template
> parameter deduction works when Args.length == 0, but stops
working when
> Args.length > 0.
For deduction to work, th
On 10/15/2018 01:36 PM, Márcio Martins wrote:
> Considering that the declaration is legal, and that the template
> parameter deduction works when Args.length == 0, but stops working when
> Args.length > 0.
For deduction to work, there must be function arguments. So, just add
Args to the functio
(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void incx(Args..., T)(ref T t);
This doesn't seem to work, because:
test.d(3): Error: template `test.incx(Args..., T)(ref T t)`
template tuple parameter must be last one
Are you sure it's not a bug? It would be very un
On 10/15/18 12:46 PM, Steven Schveighoffer wrote:
Did you mean incx!(T, 1, 2, 3)(t) ?
Sorry, incx!(Test!uint, 1, 2, 3)(t)
-Steve
, 2, 3); // what?
incx(t, 1, 2, 3); // what?
writeln(t.x);
}
test.d(16): Error: template test.incx cannot deduce function from
argument types !(1, 2, 3)(Test!uint), candidates are:
test.d(3): test.incx(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void
import std.stdio;
void incx(T, Args...)(ref T t) {
++t.x;
}
static struct Test(T) {
T x;
}
void main() {
Test!uint t;
t.incx(); // works
t.incx!(); // works
incx(t);// works
t.incx!(1, 2, 3); // what?
incx(t, 1, 2, 3); // what?
On Friday, 10 August 2018 at 12:05:52 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote:
If you try the same without the mixin template, you'll see that
it doesn't work:
struct Test {
extern(C) pragma(crt_constructor) static void init(){ // work
On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote:
I think the static extern(C) nested function should just work
like global extern(C) function. DMD still report missing
symbols. Or I am wrong about this ?
template G(){
static extern(C) pragma(crt_constructor) void init(){}
On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote:
Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=19153
template G(){
pragma(crt_constructor) static extern(C) void init(){}
}
void main(){
mixin G
On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote:
The correct behavior would be for the compiler to show the
latter error message for a mixin'd function as well.
Filed a bug:
https://issues.dlang.org/show_bug.c
tter
error message for a mixin'd function as well.
Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=19153
--
Simen
[0]: from https://dlang.org/spec/attribute.html#linkage:
Note that extern(C) can be provided for all types of
declarations, including struct or class, even though there
#!/usr/bin/env rdmd
import core.stdc.stdio;
template G(size_t line = __LINE__, A...){
int i = 3;
static extern(C) pragma(crt_constructor) void init2(){
printf("init: %d\n", line);
}
}
pragma(crt_constructor) extern(C) void init1(){
printf("init fro
he code compiles. However, for the package
> protection it may happen that a subclass is in the same package
> (and just happened to me).
>
> Should I file a bug or is there a reason for such behavior?
I don't rememeber the reasoning at the moment, but it's most definitely no
ethod of
parent class, so there's no need in making it virtual. For
protected/public the code compiles. However, for the package
protection it may happen that a subclass is in the same package
(and just happened to me).
Should I file a bug or is there a reason for such behavior?
On Friday, 16 February 2018 at 13:57:07 UTC, Steven Schveighoffer
wrote:
You have a pretty good minimal test, put that in bugzilla along
with the forum thread link and all the info we know. Mark it as
a dmd bug, regression, along with the version where it
regressed (2.076.1), and I would tag
On 2/16/18 8:51 AM, arturg wrote:
On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer wrote:
Strictly speaking, this is not necessarily proof that it's in phobos,
there could have been changes elsewhere that cause one of the
conditions to fail.
However, testing this out, I fou
On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer
wrote:
Strictly speaking, this is not necessarily proof that it's in
phobos, there could have been changes elsewhere that cause one
of the conditions to fail.
However, testing this out, I found something very weird.
If you pr
.front
onlineapp.d(7): Error: template instance
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused it.
Looking at "moveAll" which is the one that causes the
p.d(7): Error: template instance
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused
it.
Looking at "moveAll" which is the one that causes the error, no
changes
emove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused it.
On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:
this code fails to compile:
void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();
if you comment out dgs.writeln; it works as expected,
it works if you use other types
this code fails to compile:
void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();
if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:
void delegate(int*) dg;
void delegate(i
static assertion fails. Making the filed a
public makes it compile properly. Should I file a bug or is by
design?
It's definitely a bug!
static assertion fails. Making the filed a
public makes it compile properly. Should I file a bug or is by
design?
getSymbolsByUDA seems to have some visibility thing going on.
Related to https://issues.dlang.org/show_bug.cgi?id=17973
perhaps? Though that only gives deprecation warnings, not
properly. Should I file a bug or is by
design?
On Thursday, 7 September 2017 at 16:08:53 UTC, Piotr Mitana wrote:
main.d(17): Error: one path skips constructor
main.d(15): Error: return without calling constructor
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Throwing_exception_in_constructor_28995.html
do I need the constructor call, if I throw the exception
anyway? Is this a bug?
This seems likely a bug, my understanding of this error is for
class inheritance, where it must call the super constructor for
all code paths to create the base class. With a struct the
compiler always has the
main()
{
A(2004, 43);
A("2004-43");
}
===
This throws a compilation error:
main.d(17): Error: one path skips constructor
main.d(15): Error: return without calling constructor
Why do I need the constructor call, if I throw the exception
anyway? Is this a bug?
from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
compiles with:
dmd 2.073
fails with:
dmd 2.074
dmd 2.075
from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
Interesting that the same code without immutable works.
from Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
I'd say it's a bug. There was a similar issue at one point whe
class main.Derived cannot implicitly generate a
default ctor when base class main.Base is missing a default ctor
Is it a bug or it should be like this?
On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a
bug.
Ah... right. Silly me. Of course, since string is actually
immutable(char)[].
That's b
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a bug.
ing* baz = cast(string*)malloc(50);
import std.c.stdio;
printf("%d %d", foo.length, baz.length );
compiles and prints:
5 -842150451
How come string* suddenly has a .length property?
Anyway the result is garbage, so I think this must be a bug.
DMD32 D Compiler v2.073.2
On Wednesday, 15 February 2017 at 19:56:31 UTC, berni wrote:
On Wednesday, 15 February 2017 at 16:11:36 UTC, drug wrote:
No, you recursively call main() and get segfault (due to stack
overflow) as expected
I thought, that an stack overflow leeds to an exception. But
that's not true, as I now
On Wednesday, 15 February 2017 at 16:11:36 UTC, drug wrote:
No, you recursively call main() and get segfault (due to stack
overflow) as expected
I thought, that an stack overflow leeds to an exception. But
that's not true, as I now see. Thanks for your answer.
15.02.2017 19:00, berni пишет:
I'm not sure if this is considered a bug:
import std.stdio;
import std.string;
int c = 0;
void main()
{
try {
write(++c," ");
stdout.flush();
int[10] tmp;
throw new Exception(format("%s",tmp));
}
I'm not sure if this is considered a bug:
import std.stdio;
import std.string;
int c = 0;
void main()
{
try {
write(++c," ");
stdout.flush();
int[10] tmp;
throw new Exception(format("%s",tmp));
} finally
{
main();
}
Le 13/12/2016 23:44, Johan Engelen a écrit :
On Tuesday, 13 December 2016 at 21:27:57 UTC, Xavier Bigand wrote:
Hi,
I have the following code snippet :
voidset()
{
GLfloat[]data = [
-1.0f, -1.0f, 0.0f,
1.0f, -1.0f, 0.0f,
0.0f, 1.0f, 0
On Tuesday, 13 December 2016 at 21:27:57 UTC, Xavier Bigand wrote:
Hi,
I have the following code snippet :
voidset()
{
GLfloat[] data = [
-1.0f, -1.0f, 0.0f,
1.0f, -1.0f, 0.0f,
0.0f,
Le 13/12/2016 22:39, ag0aep6g a écrit :
On 12/13/2016 10:27 PM, Xavier Bigand wrote:
voidset()
{
GLfloat[]data = [
-1.0f, -1.0f, 0.0f,
1.0f, -1.0f, 0.0f,
0.0f, 1.0f, 0.0f,
];
glBindVertexArray(mVAO);
glBufferDa
On 12/13/2016 10:27 PM, Xavier Bigand wrote:
voidset()
{
GLfloat[]data = [
-1.0f, -1.0f, 0.0f,
1.0f, -1.0f, 0.0f,
0.0f, 1.0f, 0.0f,
];
glBindVertexArray(mVAO);
glBufferData(GL_ARRAY_BUFFER, data.sizeof, cast(voi
Hi,
I have the following code snippet :
voidset()
{
GLfloat[] data = [
-1.0f, -1.0f, 0.0f,
1.0f, -1.0f, 0.0f,
0.0f, 1.0f, 0.0f,
];
glBindVertexArray(
to an assertion failure. Am I too tired to see the error or do you
think it's a bug ?
Bug. `alias this` is tried too eagerly.
What happens: The alias this of `new Item` is evaluated, leading to
`children ~= [];`.
see the error or
do you think it's a bug ?
1 - 100 of 361 matches
Mail list logo
