On 08/30/2012 02:41 AM, Danny Arends wrote:
I wrote a blog post about the stuff I've been doing last weekend using
CTFE.
All comments are welcome, you can find the blog post at:
http://www.dannyarends.nl/index.cgi?viewDetailed=00029
Danny Arends
http://www.dannyarends.nl
Thanks for the
http://dave.cheney.net/2012/09/03/another-go-at-the-next-big-language
Hacker news discussion
http://news.ycombinator.com/item?id=4468731
Reddit
http://www.reddit.com/r/golang/comments/z9ltl/another_go_at_the_next_big_language/
Michal Minich:
http://dave.cheney.net/2012/09/03/another-go-at-the-next-big-language
Hacker news discussion
http://news.ycombinator.com/item?id=4468731
Reddit
http://www.reddit.com/r/golang/comments/z9ltl/another_go_at_the_next_big_language/
An interesting quotation from the various
On 2012-09-02 17:06, Alex Rønne Petersen wrote:
The argument seems to be that since an array search is O(n) and an AA
lookup is O(1), this example would be misleading.
What would it be for this set type?
--
/Jacob Carlborg
On 2012-09-02 17:29, Dmitry Olshansky wrote:
I wouldn't question utility but rather the implementation of the above.
One thing I'd love to see is thing like
handful!(struct, class, union)
that does pre-process contents at compile time to speed up search.
In other words it's possible to not
On 9/3/12 6:47 AM, Walter Bright wrote:
On 9/2/2012 4:40 PM, Andrei Alexandrescu wrote:
On 9/2/12 10:24 PM, Walter Bright wrote:
On 9/2/2012 7:45 AM, Andrei Alexandrescu wrote:
On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
[snip]
The alternative would be to simply define these as functions:
On 2012-09-02 17:16, Andrei Alexandrescu wrote:
Iota is a different notion (it has a step).
Yes, but that is optional, making iota a more general form of an interval.
--
/Jacob Carlborg
On 2012-09-02 17:17, Andrei Alexandrescu wrote:
The difference is in scale and primitives offered. Handful would be
read-only and limited to the size of its initializer. Its representation
would take advantage of that.
Anyhow, I think among would be a simpler solution for this all.
This
On 9/3/12 8:29 AM, Jacob Carlborg wrote:
On 2012-09-02 17:16, Andrei Alexandrescu wrote:
Iota is a different notion (it has a step).
Yes, but that is optional, making iota a more general form of an
interval.
I think in this case the generalization goes the wrong way.
Andrei
On 9/3/12 8:28 AM, Jacob Carlborg wrote:
On 2012-09-02 17:29, Dmitry Olshansky wrote:
I wouldn't question utility but rather the implementation of the above.
One thing I'd love to see is thing like
handful!(struct, class, union)
that does pre-process contents at compile time to speed up
On 9/3/12 8:31 AM, Andrei Alexandrescu wrote:
On 9/3/12 8:28 AM, Jacob Carlborg wrote:
On 2012-09-02 17:29, Dmitry Olshansky wrote:
I wouldn't question utility but rather the implementation of the above.
One thing I'd love to see is thing like
handful!(struct, class, union)
that does
On Mon, 03 Sep 2012 08:29:34 +0200, Jacob Carlborg d...@me.com wrote:
On 2012-09-02 17:16, Andrei Alexandrescu wrote:
Iota is a different notion (it has a step).
Yes, but that is optional, making iota a more general form of an
interval.
It's not optional, it has a default value.
--
On Mon, 03 Sep 2012 08:34:33 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
we could add in to Tuple and get to write:
if (x in tuple(struct, class, union)) { ... }
if (x in tuple(1, new Foo(), baa!) { ... }
Just kidding.
tuple has the inconvenience that we don't know
Hi,
Is there anyone out there using SCons to build D code? If so it would be
good to get some alpha and beta testers for the evolution of D support
in SCons.
I appreciate that other build frameworks may be the preferred ones for
D, let us not start a which build framework is the best debate, at
On 02/09/12 22:42, SomeDude wrote:
On Sunday, 2 September 2012 at 15:09:50 UTC, deadalnix wrote:
Le 02/09/2012 16:51, Jacob Carlborg a écrit :
I really don't like the name handful. What would be the difference
compared to a regular set container? To me it sounds like we should have
a standard
Le 3 sept. 2012 08:42, Simen Kjaeraas simen.kja...@gmail.com a écrit :
On Mon, 03 Sep 2012 08:34:33 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
we could add in to Tuple and get to write:
if (x in tuple(struct, class, union)) { ... }
if (x in tuple(1, new Foo(), baa!)
On 9/3/12 10:27 AM, Philippe Sigaud wrote:
People here are talking about sets, but does Andrei really have sets in
mind? That has consequences if you want 'in' to return a pointer to a value.
I wanted to define a couple of simple convenience functions. It seems
we've headed into a paralysis
On Sunday, 2 September 2012 at 23:40:01 UTC, Peter Alexander
wrote:
Consider:
myAssert(false, %d, 1);
What is Args? %d, 1 could refer to the optional arguments, or
the variadic arguments. Both match.
Easy: the variadic arguments are not, themselves, optional.
Match the variadic. This
On Monday, 3 September 2012 at 09:15:08 UTC, Chris
Nicholson-Sauls wrote:
On Sunday, 2 September 2012 at 23:40:01 UTC, Peter Alexander
wrote:
Consider:
myAssert(false, %d, 1);
What is Args? %d, 1 could refer to the optional arguments,
or the variadic arguments. Both match.
Easy: the
On 1 September 2012 19:08, Dmitry Olshansky dmitry.o...@gmail.com wrote:
On 01-Sep-12 19:58, Peter Alexander wrote:
C:
int mul(int x, int y);
Future D:
pure @safe nothrow nogc commutative associative distributive
@forceinline mayoverflow int mul(int x, int y);
No it's GNU C++ of
On Monday, 3 September 2012 at 09:01:37 UTC, Andrei Alexandrescu
wrote:
On 9/3/12 10:27 AM, Philippe Sigaud wrote:
People here are talking about sets, but does Andrei really
have sets in
mind? That has consequences if you want 'in' to return a
pointer to a value.
I wanted to define a couple
On 9/3/12 11:37 AM, Sven Torvinger wrote:
On Monday, 3 September 2012 at 09:01:37 UTC, Andrei Alexandrescu wrote:
On 9/3/12 10:27 AM, Philippe Sigaud wrote:
People here are talking about sets, but does Andrei really have sets in
mind? That has consequences if you want 'in' to return a pointer
On Monday, 3 September 2012 at 09:24:42 UTC, Peter Alexander
wrote:
On Monday, 3 September 2012 at 09:15:08 UTC, Chris
Nicholson-Sauls wrote:
On Sunday, 2 September 2012 at 23:40:01 UTC, Peter Alexander
wrote:
Consider:
myAssert(false, %d, 1);
What is Args? %d, 1 could refer to the optional
On Monday, 3 September 2012 at 10:42:34 UTC, Andrei Alexandrescu
wrote:
I would advocate using, a x b, this trivially addresses
open/closed
intervals etc.
I disagree with the porting from other languages argument...
comparing
bool with is not a common occurring pattern, and even if
there
On Monday, 3 September 2012 at 11:20:27 UTC, Sven Torvinger wrote:
if (a.among(struct, class, union)) { ... }
Wouldn't that rather be a.among!(struct, class, union)? If
the string is not known at compile-time, I'd prefer to focus on
optimizing something along the lines of [struct, class,
On Monday, September 03, 2012 11:25:05 Peter Alexander wrote:
On Monday, 3 September 2012 at 09:15:08 UTC, Chris
Nicholson-Sauls wrote:
On Sunday, 2 September 2012 at 23:40:01 UTC, Peter Alexander
wrote:
Consider:
myAssert(false, %d, 1);
What is Args? %d, 1 could refer to
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
I thought this should have zero impact, because in D, because
. is supposed to deference for you if needed.
I find it strange though that
Dmitry Olshansky wrote:
On 01-Sep-12 19:58, Peter Alexander wrote:
C:
int mul(int x, int y);
Future D:
pure @safe nothrow nogc commutative associative distributive
@forceinline mayoverflow int mul(int x, int y);
Either way this is a kind of thing that only some users need but std
library
Dmitry Olshansky wrote:
On 01-Sep-12 17:01, Adam D. Ruppe wrote:
On Saturday, 1 September 2012 at 12:39:41 UTC, Dmitry Olshansky wrote:
I'd say
@nogc:
at the top and deal is sealed.
BTW don't forget a @yesgc would be good to counter it. We need
a way to turn off each attribute to use this
On 02/09/2012 20:31, timotheecour wrote:
void myAssert(int line = __LINE__, string file = __FILE__,
Args...)(lazy bool condition, lazy Args args) {
Won't that create template code bloat ? Ie everytime myAssert is used
a new function is created.
...
Another option is to use a lazy tuple
On 9/3/12 1:24 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 11:20:27 UTC, Sven Torvinger wrote:
if (a.among(struct, class, union)) { ... }
Wouldn't that rather be a.among!(struct, class, union)?
I'd rather have a regular function (more generally applicable) that the
inliner
On 03/09/2012 13:51, Nick Treleaven wrote:
myAssertBody(condition, format(Assertion failed @ %s:%d: , file, line,
args));
Oops, that is unsafe, fixed:
void myAssert(string file = __FILE__, int line = __LINE__, Args...)(
lazy bool condition, lazy string messageFormat, lazy Args args)
On 01/09/12 15:16, Carl Sturtivant wrote:
What is the design logic behind
364.d(9): Error: alias this compileme364.number.__anonymous there can
be only one alias this
--- not a complaint, I'd just like to hear opinion of the basis of
the above restriction from experts.
This is a limitation
On Monday, 3 September 2012 at 12:58:05 UTC, Andrei Alexandrescu
wrote:
On 9/3/12 1:24 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 11:20:27 UTC, Sven Torvinger
wrote:
if (a.among(struct, class, union)) { ... }
Wouldn't that rather be a.among!(struct, class, union)?
I'd rather
On 9/3/12 3:53 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 12:58:05 UTC, Andrei Alexandrescu wrote:
On 9/3/12 1:24 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 11:20:27 UTC, Sven Torvinger wrote:
if (a.among(struct, class, union)) { ... }
Wouldn't that rather be
On Mon, Sep 03, 2012 at 08:19:19AM +0100, Russel Winder wrote:
Hi,
Is there anyone out there using SCons to build D code?
I (still) am!
If so it would be good to get some alpha and beta testers for the
evolution of D support in SCons.
[...]
Currently my D projects aren't very complex
On 09/03/2012 01:37 AM, Andrei Alexandrescu wrote:
On 9/2/12 7:31 PM, Timon Gehr wrote:
On 09/02/2012 06:45 PM, Andrei Alexandrescu wrote:
On 9/2/12 6:44 PM, Andrei Alexandrescu wrote:
[snip]
The remaining question is where to put among and between.
std.functional?
Andrei
They are not
David Nadlinger:
Where would the real difference to [struct, class,
union].canFind(a) then? A sufficiently smart compiler (tm)
could optimize this to a efficient string prefix switch
statement just as well…
I think a smart compiler is not needed.
Maybe a general solution is to introduce a
I thought this should have zero impact, because in D, because
. is supposed to deference for you if needed.
D can't do this all the time: struct pointer assignment for
example, should not automatically cause the corresponding structs
to be assigned.
struct S
{
void foo();
}
void
if (a in handful(struct, class, union))
How is this different from
if(canFind([struct, class, union], a) {...}
It's a lot cleaner without the mess of brackets. You missed a )
on the second one, which, without intending snarkiness, perhaps
demonstrates the greater elegance of the former?
struct S
{
void foo();
}
void bar(S);
void main()
{
auto r = new S;
r.foo();
bar(r); //derp
r.bar(); //derp
};
bar(r) would need D to support an implied conversion of S* to S
(or to ref S with bar having a reference parameter if you
wanted to avoid copying), for this to work.
However I'd use different names: among=isOneOf,
between=isInRange.
I forgot to state the reason, namely, I think boolean functions
should be named so that you can tell they return bool, as
between could easily be a function that places a value into a
range rather than tests whether it is in
if (a.among(struct, class, union)) { ... }
if (b.between(1, 100)) { ... }
Is between inclusive or not of the endpoints?
After quite a bit of thought, I think inclusive is the right
way.
Then there's no way to specify an empty interval. I suppose
with between that would not be relevant.
On Monday, 3 September 2012 at 15:46:49 UTC, Carl Sturtivant
wrote:
It seems that the following discussion is relevant to the above.
Why can't we have reference variables
http://forum.dlang.org/thread/ruwapnhkuvozitefz...@forum.dlang.org
A conservative viewpoint is that converting S* to ref S
On Monday, 3 September 2012 at 00:01:09 UTC, foobar wrote:
2 (extending type). We want to define type (likely classes)
and then
extend its functionality.
AFAIK C# attributes belong to this camp (correct me if I am
wrong). In
this case (likely class) type implicitly derives
from attribute
On Monday, 3 September 2012 at 12:12:46 UTC, monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
I answered this question in BZ couple of days ago in an issue
8603 which
On Monday, 3 September 2012 at 15:10:46 UTC, ixid wrote:
if (a in handful(struct, class, union))
How is this different from
if(canFind([struct, class, union], a) {...}
It's a lot cleaner without the mess of brackets.
I find the difference between »a in handful(struct, class,
union)« and
On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu
wrote:
A sufficiently smart compiler (tm) could
optimize this to a efficient string prefix switch statement
just as well…
I agree. But then
http://c2.com/cgi/wiki?SufficientlySmartCompiler.
This is exactly my point: My
On Monday, September 03, 2012 19:52:26 David Nadlinger wrote:
On Monday, 3 September 2012 at 15:10:46 UTC, ixid wrote:
if (a in handful(struct, class, union))
How is this different from
if(canFind([struct, class, union], a) {...}
It's a lot cleaner without the mess of brackets.
I
On 03-Sep-12 16:32, Piotr Szturmaj wrote:
Dmitry Olshansky wrote:
On 01-Sep-12 17:01, Adam D. Ruppe wrote:
On Saturday, 1 September 2012 at 12:39:41 UTC, Dmitry Olshansky wrote:
I'd say
@nogc:
at the top and deal is sealed.
BTW don't forget a @yesgc would be good to counter it. We need
a
On Monday, 3 September 2012 at 16:21:08 UTC, Maxim Fomin wrote:
The question with this approach is follows: if attributes are
just another way of deriving why not use old syntax?
I think you conflate two concepts - the custom attributes
_themselves_ can use the old syntax for polymorphism
On 09/03/2012 08:01 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu wrote:
A sufficiently smart compiler (tm) could
optimize this to a efficient string prefix switch statement just as
well…
I agree. But then
On 03/09/2012 08:19, Russel Winder wrote:
Hi,
Is there anyone out there using SCons to build D code? If so it would be
good to get some alpha and beta testers for the evolution of D support
in SCons.
I appreciate that other build frameworks may be the preferred ones for
D, let us not start a
On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
I thought this should have zero impact, because in D, because
. is supposed to
On Monday, September 03, 2012 20:29:27 Timon Gehr wrote:
On 09/03/2012 08:01 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu wrote:
A sufficiently smart compiler (tm) could
optimize this to a efficient string prefix switch statement just as
On 09/03/2012 05:05 PM, bearophile wrote:
David Nadlinger:
Where would the real difference to [struct, class,
union].canFind(a) then? A sufficiently smart compiler (tm) could
optimize this to a efficient string prefix switch statement just as
well…
I think a smart compiler is not needed.
On Sunday, 2 September 2012 at 20:24:29 UTC, Walter Bright wrote:
On 9/2/2012 7:45 AM, Andrei Alexandrescu wrote:
On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
[snip]
The alternative would be to simply define these as functions:
if (a.among(struct, class, union)) { ... }
if (b.between(1,
On Monday, 3 September 2012 at 18:45:42 UTC, Jonathan M Davis
wrote:
On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
I thought this
Just to be pellucidly clear, the case you think likely has merit
is for an enhancement so that
S* p; //suitably initialized
can e.g. make the call
p.func(3);
of
void func(S s, int i) { ... }
or
void func(ref S s, int i) { ... }
right?
(Where it's important that the S parameter is first in
On 09/03/2012 08:53 PM, Jonathan M Davis wrote:
On Monday, September 03, 2012 20:29:27 Timon Gehr wrote:
On 09/03/2012 08:01 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu wrote:
A sufficiently smart compiler (tm) could
optimize this to a efficient
On Monday, 3 September 2012 at 19:49:14 UTC, monarch_dodra wrote:
On Monday, 3 September 2012 at 18:45:42 UTC, Jonathan M Davis
wrote:
On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap.
On Monday, 3 September 2012 at 18:45:42 UTC, Jonathan M Davis
wrote:
However, one thing to remember that complicates this a bit is
that it's perfectly possible to declare a function which is
overloaded with one function taking a pointer and one not.
void func(S* s, int i) {...}
void func(S s,
In C++, I often did it with iterators:
for(it ...)
{
int val = *it;
//now, we can access it with value semantics through val.
}
?
with(it) should help a lot but here. Still it was bogus back then when I
used it with pointers, not sure how good it is now.
Good
On Monday, 3 September 2012 at 12:12:46 UTC, monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
I thought this should have zero impact, because in D, because
. is supposed
On Monday, September 03, 2012 23:19:07 Carl Sturtivant wrote:
So I'm wondering if a language extension along the following
lines would solve your problem,
Whoa. Stop right there. Language extension? If you think that you need a
language extension to solve a problem, odds are that you're going
On Monday, 3 September 2012 at 11:17:39 UTC, Chris
Nicholson-Sauls wrote:
1) Empty array stands in for empty variadic. [snip]
In reality, though, we have neither of these things. [snip]
Turns out, I was quite wrong, and I'm happy to be. Empty array
is accepted for typesafe variadics just
On Monday, 3 September 2012 at 21:44:15 UTC, Jonathan M Davis
wrote:
On Monday, September 03, 2012 23:19:07 Carl Sturtivant wrote:
So I'm wondering if a language extension along the following
lines would solve your problem,
Whoa. Stop right there. Language extension? If you think that
you
On Tuesday, September 04, 2012 00:21:53 Carl Sturtivant wrote:
---same thing (specialized to struct S) in my first reply.
I'm just fishing, seeking a boundary.
There is a cleanness issue to discuss. It would be nice to know
what you think about implicit conversion from 'S*' to 'ref S'
(and
On 9/3/12 8:01 PM, David Nadlinger wrote:
On Monday, 3 September 2012 at 14:04:18 UTC, Andrei Alexandrescu wrote:
A sufficiently smart compiler (tm) could
optimize this to a efficient string prefix switch statement just as
well…
I agree. But then
On 9/3/12 9:15 PM, Timon Gehr wrote:
This would eventually lead to a solution like
bool among(S,T...)(S needle, auto enum T haystack){
...
foreach(h;haystack) static if(__traits(isConstant, h)){ ... }
...
}
Which is still rather specific.
Anyway, I don't consider among trying to be clever
On Monday, 3 September 2012 at 22:38:28 UTC, Jonathan M Davis
wrote:
On Tuesday, September 04, 2012 00:21:53 Carl Sturtivant wrote:
---same thing (specialized to struct S) in my first reply.
I'm just fishing, seeking a boundary.
There is a cleanness issue to discuss. It would be nice to know
On Monday, 3 September 2012 at 22:37:30 UTC, Andrei Alexandrescu
wrote:
among is a simple function, not a special case.
I was more thinking of the »in … handful« proposal here,
which would entail creating a new type (presumably just with a
single method, opIn_r) just to get a somewhat spiffy
On Tuesday, September 04, 2012 00:49:48 Carl Sturtivant wrote:
Thank you for your frankness. The above being the case, I wonder
why p.frog where p is a pointer has been made to work when a
wrapper will do the job. Is that something that might best be
removed? It is after all an aesthetic
On Monday, 3 September 2012 at 23:13:26 UTC, Jonathan M Davis
wrote:
On Tuesday, September 04, 2012 00:49:48 Carl Sturtivant wrote:
Thank you for your frankness. The above being the case, I
wonder
why p.frog where p is a pointer has been made to work when a
wrapper will do the job. Is that
On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:
I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.
[snip]
Enhancement Request:
http://d.puremagic.com/issues/show_bug.cgi?id=8616
-
On 2012-08-31 16:35, kntroh wrote:
I regret that it can't help.
Actually, I think it should be possible to work on the Mac OS X port
until link time. Although I don't know how fun that will be. Let me know
what you think and I can upload the repository I have and help you get
started.
--
On 2012-09-03 13:00, kntroh wrote:
I think it's nice idea. I may be able to do work for DWT2-Mac, and we may be get
help of somebody has a Mac.
I guess, many D users want a GUI Library for Mac.
I'll upload the repository to night and write down some instructions to
get started with.
I do
On 2012-09-03 13:00, kntroh wrote:
I think it's nice idea. I may be able to do work for DWT2-Mac, and we may be get
help of somebody has a Mac.
I guess, many D users want a GUI Library for Mac.
I've uploaded a new repository for DWT Mac OS X:
https://github.com/d-widget-toolkit/dwt-mac
On 2012-09-03 00:05, timotheecour wrote:
I got that too. So I also tried linking my D program against a C library
that would call those set jmp and long jmp functions, but that crashed
too. So I guess there's currently no clean way to recover from signals
on OSX ?
I have no idea.
--
/Jacob
The diagnostic message can definitely be better.
On 28/08/12 19:40, Philippe Sigaud wrote:
On Tue, Aug 28, 2012 at 2:07 PM, Chris Cain clc...@uncg.edu wrote:
On Tuesday, 28 August 2012 at 11:39:20 UTC, Danny Arends wrote:
Ahhh I understand...
As a follow up, is it then possible to 'track' filling a
large enum / immutable on compile time by
On Sunday, 26 August 2012 at 19:24:03 UTC, Carl Sturtivant wrote:
Here are some examples that are not demangled by
std.demangle.demangle :
_D13libd_demangle12__ModuleInfoZ
_D15TypeInfo_Struct6__vtblZ
_D3std5stdio12__ModuleInfoZ
_D3std6traits15__T8DemangleTkZ8Demangle6__initZ
On Mon, Sep 3, 2012 at 1:27 PM, Don Clugston d...@nospam.com wrote:
Godd adivce, except beware of using ++ and --, they don't work at
compile-time. I'm regularly caught unaware by this, particularly while
looping.
Really? That's scary. Is there a bug report for this?
I re-tried this and I
Philippe Sigaud:
Worth a bug report?
Yeah. CTFE must give the same results when CTFE works.
A simpler test case for Bugzilla:
import std.stdio;
int[] foo(int[] data) {
foreach (i, ref x; data) {
x++;
i++;
}
return data;
}
void main() {
enum result1 =
Why this simple program don't show white square?
import std.stdio;
import derelict.opengl3.gl;
import derelict.glfw3.glfw3;
const uint width = 200;
const uint height = 200;
void init()
{
glViewport(0,0,width,height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
On Monday, 3 September 2012 at 15:21:59 UTC, Zhenya wrote:
Why this simple program don't show white square?
void display()
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_POLYGON);
glVertex2d(0,0);
glVertex2d(0,height);
On Monday, 3 September 2012 at 16:57:08 UTC, cal wrote:
On Monday, 3 September 2012 at 15:21:59 UTC, Zhenya wrote:
Why this simple program don't show white square?
void display()
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_POLYGON);
glVertex2d(0,0);
On Monday, 3 September 2012 at 17:02:46 UTC, Zhenya wrote:
that dosn't work
How large is your window?
glViewport(0,0,width,height);
should really be setting to the window size - so if you make your
window 800,800, this should be
glViewport(0,0,800,800);
On Monday, 3 September 2012 at 17:08:55 UTC, cal wrote:
On Monday, 3 September 2012 at 17:02:46 UTC, Zhenya wrote:
that dosn't work
How large is your window?
glViewport(0,0,width,height);
should really be setting to the window size - so if you make
your window 800,800, this should be
On Monday, 3 September 2012 at 17:12:04 UTC, cal wrote:
On Monday, 3 September 2012 at 17:08:55 UTC, cal wrote:
On Monday, 3 September 2012 at 17:02:46 UTC, Zhenya wrote:
that dosn't work
How large is your window?
glViewport(0,0,width,height);
should really be setting to the window size -
On Mon, Sep 3, 2012 at 4:08 PM, bearophile bearophileh...@lycos.com wrote:
Worth a bug report?
Yeah. CTFE must give the same results when CTFE works.
http://d.puremagic.com/issues/show_bug.cgi?id=8614
On Monday, 3 September 2012 at 17:16:54 UTC, Zhenya wrote:
I added it to this code,but nothing changed(
Its a puzzler then, FWIW the following code works for me (I don't
use GLFW, I have my own window routines, but the opengl-specific
calls are the same).
Window(window1,
On Monday, 3 September 2012 at 15:21:59 UTC, Zhenya wrote:
Why this simple program don't show white square?
import std.stdio;
import derelict.opengl3.gl;
import derelict.glfw3.glfw3;
const uint width = 200;
const uint height = 200;
void init()
{
glViewport(0,0,width,height);
On Monday, 3 September 2012 at 18:47:25 UTC, Ivan Agafonov wrote:
On Monday, 3 September 2012 at 15:21:59 UTC, Zhenya wrote:
Why this simple program don't show white square?
import std.stdio;
import derelict.opengl3.gl;
import derelict.glfw3.glfw3;
const uint width = 200;
const uint height =
http://d.puremagic.com/issues/show_bug.cgi?id=8608
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||CTFE, ice
http://d.puremagic.com/issues/show_bug.cgi?id=8498
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||CTFE, wrong-code
http://d.puremagic.com/issues/show_bug.cgi?id=8598
--- Comment #2 from github-bugzi...@puremagic.com 2012-09-03 01:19:58 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
http://d.puremagic.com/issues/show_bug.cgi?id=8608
--- Comment #2 from Eyy�b Sari eyyub.pangeara...@gmail.com 2012-09-03
01:58:26 PDT ---
(In reply to comment #1)
CTFE is invoked because doFor(file) is an expression
Oh indeed, I didn't notice that...sorry.
The internal compiler error
http://d.puremagic.com/issues/show_bug.cgi?id=8498
--- Comment #2 from timon.g...@gmx.ch 2012-09-03 08:09:07 PDT ---
(In reply to comment #1)
Here's a reduced test case. There are 10 iterations, even though the iteration
variable is changed.
int fun(){
int r=0;
foreach(i;0..10) {
http://d.puremagic.com/issues/show_bug.cgi?id=8614
Summary: Cannot change the iteration index during CTFE
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
1 - 100 of 108 matches
Mail list logo
