On 17 June 2012 18:33, bioinfornatics bioinfornat...@fedoraproject.org wrote:
Le dimanche 17 juin 2012 à 16:09 +0200, Alfredo Di Napoli a écrit :
On Sunday, 17 June 2012 at 12:42:57 UTC, bioinfornatics wrote:
Le dimanche 17 juin 2012 à 12:43 +0200, Alfredo Di Napoli a
écrit :
Just an
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate() increment;
void oops() const { this.increment(); }
On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate()
On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate()
On 06/18/2012 08:04 AM, Mehrdad wrote:
On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment =
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by
using the this-pointer*.
I see...
So that means you /can't/ tell something just by looking at a
part of
On 06/18/2012 08:19 AM, Mehrdad wrote:
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by using
the this-pointer*.
I see...
So that means you
Okay, how about this? http://ideone.com/VMlzS
Does this break const?
import std.stdio;
class S
{
this(int a)
{
this.a = a;
this.increment = { this.a++; };
}
int a;
void delegate() increment;
void oops() const {
On Sunday, 17 June 2012 at 10:49:30 UTC, Gor Gyolchanyan wrote:
On Sun, Jun 17, 2012 at 2:34 PM, Jacob Carlborg d...@me.com
wrote:
On 2012-06-17 07:15, Gor Gyolchanyan wrote:
Is it possible to use the VC2010 linker with DMD? That would
allow
easily linking with COFF libraries and building 64
On Monday, June 18, 2012 08:19:55 Mehrdad wrote:
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by
using the this-pointer*.
I see...
So that means
On Monday, 18 June 2012 at 07:58:50 UTC, Jonathan M Davis wrote:
That's powerful, but it needs pure as well to really be able to
just glance at it and know that it's not altering your object.
I see, so I need pure for the first example; thanks.
How about the second one though?
On Monday, 18 June 2012 at 07:58:50 UTC, Jonathan M Davis wrote:
That's powerful, but it needs pure as well to really be able to
just glance at it and know that it's not altering your object.
I see, so I need pure for the first example; thanks.
How about the second one though?
Hi,
last week I realized that a const version of
std.container.Array.opSlice() is missing. Now I looked at the code and I
think that it is a general design problem.
The docs state that c.Range is The primary range type associated with
the container.. I think we really always need two Range types
On Monday, June 18, 2012 09:14:59 Mehrdad wrote:
Okay, how about this? http://ideone.com/VMlzS
Does this break const?
import std.stdio;
class S
{
this(int a)
{
this.a = a;
this.increment = { this.a++; };
}
int
On 17/06/12 19:50, Artur Skawina wrote:
I took your random.d and ran with that:
[6612, 6650, 6704, 0, 6629, 6834, 6634, 6756, 6590, 6591]
[6589, 6587, 6636, 0, 6673, 6704, 6647, 6704, 6643, 6817]
[6744, 6552, 6602, 0, 6641, 6722, 6598, 6676, 6749, 6716]
[6641, 6583, 6710, 0,
On Sunday, 17 June 2012 at 10:49:30 UTC, Gor Gyolchanyan wrote:
Thanks for the reply.
This is so ridiculous and frustrating.
Use GDC?
16.06.2012 20:11, Walter Bright пишет:
On 6/16/2012 8:26 AM, Guillaume Chatelet wrote:
And then we wonder why software is
notorious for being delivered late and full of bugs, while other
engineers routinely deliver finished bridges, automobiles, electrical
appliances, etc., on time and with
bearophile , dans le message (digitalmars.D:169611), a écrit :
struct BilevelScan(Range) {
This is basically std.algorithm.joiner
So an idea is to introduce in D the multi-level Ranges:
SegmentedInputRange
SegmentedOutputRange
SegmentedForwardRange
SegmentedBidirectionalRange
On Monday, June 18, 2012 10:06:44 Matthias Walter wrote:
Hi,
last week I realized that a const version of
std.container.Array.opSlice() is missing. Now I looked at the code and I
think that it is a general design problem.
The docs state that c.Range is The primary range type associated
On 06/18/12 10:40, Joseph Rushton Wakeling wrote:
On 17/06/12 19:50, Artur Skawina wrote:
I took your random.d and ran with that:
[6612, 6650, 6704, 0, 6629, 6834, 6634, 6756, 6590, 6591]
[6589, 6587, 6636, 0, 6673, 6704, 6647, 6704, 6643, 6817]
[6744, 6552, 6602, 0, 6641, 6722,
Le 18/06/2012 07:36, Mehrdad a écrit :
Is it just me, or did I subvert the type system here?
delegate fail to ensure transitivity of type qualifier. This is no news.
This is however a big error.
I proposed a fix to that by changing the semantic of the type qualifier
depending on its
Le 18/06/2012 07:59, Matthias Walter a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate() increment;
Le 18/06/2012 09:58, Jonathan M Davis a écrit :
On Monday, June 18, 2012 08:19:55 Mehrdad wrote:
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by
using the
Steven Schveighoffer , dans le message (digitalmars.D:169568), a
écrit :
On Thu, 07 Jun 2012 22:16:21 -0400, Robert DaSilva spunit...@yahoo.com
wrote:
You're forgetting about Global data.
I wasn't so much forgetting it as I was ignoring it :)
My thought on that is that the shared
On 06/18/2012 02:45 PM, deadalnix wrote:
Le 18/06/2012 07:59, Matthias Walter a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
On 17/06/12 00:37, Walter Bright wrote:
On 6/14/2012 1:03 AM, Don Clugston wrote:
It is for debug builds.
Iain's data indicates that it's only a few % of the time taken on
semantic1().
Do you have data that shows otherwise?
Nothing recent, it's mostly from my C++ compiler testing.
But you
On Sunday, 17 June 2012 at 16:38:25 UTC, Damian wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
Will D get something like this? I find it to be of great use
with Go specifically and I'm sure it would benefit D just as
On 06/18/12 14:45, deadalnix wrote:
Le 18/06/2012 07:59, Matthias Walter a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
Le 18/06/2012 15:03, Timon Gehr a écrit :
On 06/18/2012 02:45 PM, deadalnix wrote:
Le 18/06/2012 07:59, Matthias Walter a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{
On 6/18/12 1:35 AM, Matthias Walter wrote:
On 06/18/2012 08:19 AM, Mehrdad wrote:
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by using
the this-pointer*.
On 6/18/12 2:14 AM, Mehrdad wrote:
Okay, how about this? http://ideone.com/VMlzS
Does this break const?
import std.stdio;
class S
{
this(int a)
{
this.a = a;
this.increment = { this.a++; };
}
int a;
void delegate() increment;
void oops() const { this.increment(); }
}
void main()
{
auto c =
On Monday, 18 June 2012 at 14:37:26 UTC, Andrei Alexandrescu
wrote:
On 6/18/12 1:35 AM, Matthias Walter wrote:
On 06/18/2012 08:19 AM, Mehrdad wrote:
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter
wrote:
Its not, that a const method cannot modify an object, it just
ensures that the
Le 18/06/2012 16:28, Artur Skawina a écrit :
It's fine, if you view a delegate as opaque.
No it isn't. You cannot ensure transitivity anywhere. This have obvious,
and severe drawback for concurrent programing (implicit sharing is back)
and GC performances (GC can eb crazy fast when it come
On Monday, 18 June 2012 at 12:43:04 UTC, deadalnix wrote:
Le 18/06/2012 07:36, Mehrdad a écrit :
Is it just me, or did I subvert the type system here?
delegate fail to ensure transitivity of type qualifier. This is
no news. This is however a big error.
Oh lol :( thought I'd discovered
Le 18/06/2012 16:43, Andrei Alexandrescu a écrit :
On 6/18/12 7:43 AM, deadalnix wrote:
Le 18/06/2012 07:36, Mehrdad a écrit :
Is it just me, or did I subvert the type system here?
delegate fail to ensure transitivity of type qualifier. This is no news.
This is however a big error.
I
On 6/18/12 7:43 AM, deadalnix wrote:
Le 18/06/2012 07:36, Mehrdad a écrit :
Is it just me, or did I subvert the type system here?
delegate fail to ensure transitivity of type qualifier. This is no news.
This is however a big error.
I proposed a fix to that by changing the semantic of the
On Monday, 18 June 2012 at 14:41:02 UTC, deadalnix wrote:
Le 18/06/2012 16:28, Artur Skawina a écrit :
It's fine, if you view a delegate as opaque.
No it isn't. You cannot ensure transitivity anywhere. This have
obvious, and severe drawback for concurrent programing
(implicit sharing is
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change anything either.
So 'pure' doesn't let you infer something just by looking at the code
either, right?
It does ! It tell you that the function have no side effect, and that
the function called with
On 6/18/12 9:45 AM, deadalnix wrote:
Le 18/06/2012 16:43, Andrei Alexandrescu a écrit :
On 6/18/12 7:43 AM, deadalnix wrote:
Le 18/06/2012 07:36, Mehrdad a écrit :
Is it just me, or did I subvert the type system here?
delegate fail to ensure transitivity of type qualifier. This is no news.
On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change
anything either.
So 'pure' doesn't let you infer something just by looking at
the code
either, right?
It does ! It tell you that the
On 06/18/12 16:41, deadalnix wrote:
Le 18/06/2012 16:28, Artur Skawina a écrit :
It's fine, if you view a delegate as opaque.
No it isn't. You cannot ensure transitivity anywhere. This have obvious, and
severe drawback for concurrent programing (implicit sharing is back) and GC
On Monday, 18 June 2012 at 14:55:42 UTC, Mehrdad wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
}
int a;
int
Hi group,
I've been reading up on D for the past few days--something I'd been
planning to do for quite a while--and find much to like and little to
dislike; as such, I am considering using it for my next project, which
would run on Linux (and possibly some other POSIX systems) and would
need to
On 17 June 2012 13:49, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote:
On Sun, Jun 17, 2012 at 2:34 PM, Jacob Carlborg d...@me.com wrote:
On 2012-06-17 07:15, Gor Gyolchanyan wrote:
Is it possible to use the VC2010 linker with DMD? That would allow
easily linking with COFF libraries
On 06/18/2012 03:47 PM, nazriel wrote:
On Sunday, 17 June 2012 at 16:38:25 UTC, Damian wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
Will D get something like this? I find it to be of great use
with Go specifically
On 18 June 2012 11:38, Kagamin s...@here.lot wrote:
On Sunday, 17 June 2012 at 10:49:30 UTC, Gor Gyolchanyan wrote:
Thanks for the reply.
This is so ridiculous and frustrating.
Use GDC?
I use GDC now. It produces COFF objects, and is technically capable of
linking against MSVC code,
On 17 June 2012 19:38, Damian damian...@hotmail.co.uk wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
Will D get something like this? I find it to be of great use
with Go specifically and I'm sure it would benefit
On 06/18/2012 04:55 PM, Mehrdad wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
}
int a;
int delegate()
Le 18/06/2012 16:51, Andrei Alexandrescu a écrit :
Mehrdad posted a code sample and you replied to it with what I could
only assume was an explanation of the code's behavior. I hope you'd
agree it was a reasonable assumption, whether or not it was correct.
The problem at work here is that this
On 18 June 2012 16:08, Manu turkey...@gmail.com wrote:
On 18 June 2012 11:38, Kagamin s...@here.lot wrote:
On Sunday, 17 June 2012 at 10:49:30 UTC, Gor Gyolchanyan wrote:
Thanks for the reply.
This is so ridiculous and frustrating.
Use GDC?
I use GDC now. It produces COFF objects, and
On 06/18/2012 04:33 PM, deadalnix wrote:
Le 18/06/2012 15:03, Timon Gehr a écrit :
On 06/18/2012 02:45 PM, deadalnix wrote:
Le 18/06/2012 07:59, Matthias Walter a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct
Matthias Walter , dans le message (digitalmars.D:170036), a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
Le 18/06/2012 16:55, Mehrdad a écrit :
On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change anything either.
So 'pure' doesn't let you infer something just by looking at the code
either, right?
On Monday, 18 June 2012 at 15:11:00 UTC, Timon Gehr wrote:
On 06/18/2012 04:55 PM, Mehrdad wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
On Monday, 18 June 2012 at 15:13:33 UTC, deadalnix wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
}
int a;
int delegate() pure increment;
auto oops() const { return this.increment(); }
}
void
Le 18/06/2012 17:16, Mehrdad a écrit :
On Monday, 18 June 2012 at 15:13:33 UTC, deadalnix wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
}
int a;
int delegate() pure increment;
auto oops()
Jacob Carlborg d...@me.com writes:
On 2012-06-18 16:56, Wouter Verhelst wrote:
However, what
I don't find is the answer to the two following questions:
- Does D support dlopen(), or some similar mechanism, to allow me to
load plugins at runtime?
Yes. You can compile D code to a
On Monday, 18 June 2012 at 15:16:58 UTC, Mehrdad wrote:
Explain it however you want.
The bottom line I'm getting at is, you can't re-order the
calls, EVEN IF by looking at them you can tell they're pure
@safe nothrow const...
(Sorry wasn't intending to make a mean comment -- my bad if it
On Monday, 18 June 2012 at 14:59:53 UTC, Timon Gehr wrote:
On 06/18/2012 03:47 PM, nazriel wrote:
On Sunday, 17 June 2012 at 16:38:25 UTC, Damian wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
Will D get something
On 06/18/2012 05:15 PM, Mehrdad wrote:
On Monday, 18 June 2012 at 15:11:00 UTC, Timon Gehr wrote:
On 06/18/2012 04:55 PM, Mehrdad wrote:
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
On Monday, 18 June 2012 at 15:19:26 UTC, deadalnix wrote:
Yes, but this isn't a problem with pure here, this is a problem
with const.
Hence the title...
The sample code should not compile.
What should the error be? Is it correct in the language spec?
Le 18/06/2012 17:20, Mehrdad a écrit :
On Monday, 18 June 2012 at 15:19:26 UTC, deadalnix wrote:
Yes, but this isn't a problem with pure here, this is a problem with
const.
Hence the title...
The sample code should not compile.
What should the error be? Is it correct in the language
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really
spend some
time fixing the /design/ of const before the implementation...
This is mostly about the design of object initialisation.
good idea or no?
Certainly.
My
On 06/18/2012 05:13 PM, deadalnix wrote:
Le 18/06/2012 16:55, Mehrdad a écrit :
On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change anything either.
So 'pure' doesn't let you infer something
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really
spend some
time fixing the /design/ of const before the implementation...
This is mostly about the design of object
On 06/18/2012 05:14 PM, Christophe Travert wrote:
Matthias Walter , dans le message (digitalmars.D:170036), a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{
Le 18/06/2012 17:23, Timon Gehr a écrit :
On 06/18/2012 05:13 PM, deadalnix wrote:
Le 18/06/2012 16:55, Mehrdad a écrit :
On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change anything
either.
Le 18/06/2012 17:28, Mehrdad a écrit :
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really spend some
time fixing the /design/ of const before the implementation...
This
On Monday, 18 June 2012 at 15:36:23 UTC, deadalnix wrote:
Le 18/06/2012 17:28, Mehrdad a écrit :
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really
spend some
time fixing
On 06/18/2012 05:28 PM, Mehrdad wrote:
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really spend some
time fixing the /design/ of const before the implementation...
This
Le 18/06/2012 17:50, Timon Gehr a écrit :
On 06/18/2012 05:28 PM, Mehrdad wrote:
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really spend some
time fixing the /design/ of
On 06/18/2012 05:12 PM, deadalnix wrote:
Le 18/06/2012 16:51, Andrei Alexandrescu a écrit :
Mehrdad posted a code sample and you replied to it with what I could
only assume was an explanation of the code's behavior. I hope you'd
agree it was a reasonable assumption, whether or not it was
Le 18/06/2012 18:04, Timon Gehr a écrit :
To explain my proposal, I have to make several thing clear first. You
have here 2 things to qualify : the delegate itself, and the hidden
parameter. As type qualifier are transitive in D, qualify the delegate
also transitively qualify the hidden
On 06/18/2012 06:12 PM, deadalnix wrote:
Le 18/06/2012 18:04, Timon Gehr a écrit :
It would be better to have 'nostatic' as the keyword for the
current 'pure' and 'pure' as a shortcut for 'immutable nostatic'.
This would also silence the 'pure is a misnomer' crowd.
I don't really have an
On Monday, 18 June 2012 at 16:23:39 UTC, Timon Gehr wrote:
I agree. Some of the keywords are poorly chosen, but this does
not have any actual _practical_ implications for coding.
Changing them, however, does.
Not sure if this was intended to be referring to my post or not,
but just to
On 6/18/12 10:15 AM, Mehrdad wrote:
So (**IMHO**) if that's really the case, we should really spend some
time fixing the /design/ of const before the implementation... good idea
or no?
It's the implementation (not design) of constructors typechecking that's
the problem.
Andrei
On 6/18/12 10:24 AM, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really spend some
time fixing the /design/ of const before the implementation...
This is mostly about the design of object initialisation.
good
On 06/18/2012 06:30 PM, Mehrdad wrote:
On Monday, 18 June 2012 at 16:23:39 UTC, Timon Gehr wrote:
I agree. Some of the keywords are poorly chosen, but this does not
have any actual _practical_ implications for coding. Changing them,
however, does.
Not sure if this was intended to be
Just thought I might say that it's ok to send pull requests for
any important/critical changes in upstream dmd, phobos and
druntime down to gdc if you feel it is the correct thing to do.
It has been done in the past for any showstopping bugs in the
library (various multithread related
On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not compatible with the MSVC linker or runtime
I intend to fix all of those, at least for 64 bit Windows, in the near term.
On 6/18/2012 6:07 AM, Don Clugston wrote:
On 17/06/12 00:37, Walter Bright wrote:
On 6/14/2012 1:03 AM, Don Clugston wrote:
It is for debug builds.
Iain's data indicates that it's only a few % of the time taken on
semantic1().
Do you have data that shows otherwise?
Nothing recent, it's
On Monday, 18 June 2012 at 17:54:40 UTC, Walter Bright wrote:
On 6/18/2012 6:07 AM, Don Clugston wrote:
On 17/06/12 00:37, Walter Bright wrote:
On 6/14/2012 1:03 AM, Don Clugston wrote:
It is for debug builds.
Iain's data indicates that it's only a few % of the time
taken on
semantic1().
Do
On Mon, 18 Jun 2012 10:50:44 -0700, Walter Bright
newshou...@digitalmars.com wrote:
On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not compatible with the MSVC linker or runtime
I intend to fix all of
On Monday, 18 June 2012 at 17:51:39 UTC, Walter Bright wrote:
On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not compatible with the MSVC linker or runtime
I intend to fix all of those, at least for 64 bit
On Monday, 18 June 2012 at 15:22:19 UTC, Wouter Verhelst wrote:
Ah, too bad.
Do you have a pointer to some more detailed information on
this? Just so
I can get a feel for how fast things are moving, and/or whether
it's
worth for me to wait for that -- I can get started on the other
parts;
On 18 June 2012 22:07, michael.larou...@gmail.com@puremagic.com
\Michaël.Larouche wrote:
On Monday, 18 June 2012 at 17:51:39 UTC, Walter Bright wrote:
On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not
On Monday, June 18, 2012 23:23:02 Manu wrote:
It really is. I suspect we will see a gigantic boots to the D community on
the back of this change! :)
Well, we could all use a good pair of shoes. ;)
- Jonathan M Davis
I think std.functional.curry is badly named because I think it's
a partial application (I suggest to rename it).
In Haskell and Scala currying is built-in, this is Haskell, shell
(ghci):
Prelude let foo x y z = x * 2 + y * 3 + y * 5
Prelude let foo1 = foo 5
Prelude let foo2 = foo1 4
Prelude
Kapps opantm2+s...@gmail.com wrote in message
news:jikemjmapclwcufpw...@forum.dlang.org...
On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:
I recently switched from Eclipse to monoD and found that all my code to
images etc was invalid because getcwd returns the directory that
On Monday, 18 June 2012 at 15:24:31 UTC, Mehrdad wrote:
On Monday, 18 June 2012 at 15:21:36 UTC, Timon Gehr wrote:
So (**IMHO**) if that's really the case, we should really
spend some time fixing the /design/ of const before the
implementation...
This is mostly about the design of object
Le 18/06/2012 17:29, Timon Gehr a écrit :
On 06/18/2012 05:14 PM, Christophe Travert wrote:
Matthias Walter , dans le message (digitalmars.D:170036), a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
Le 18/06/2012 09:14, Mehrdad a écrit :
Okay, how about this? http://ideone.com/VMlzS
Does this break const?
import std.stdio;
class S
{
this(int a)
{
this.a = a;
this.increment = { this.a++; };
}
int a;
void delegate() increment;
void oops() const { this.increment(); }
}
void main()
{
auto c
On 06/18/12 23:08, deadalnix wrote:
Le 18/06/2012 09:14, Mehrdad a écrit :
Okay, how about this? http://ideone.com/VMlzS
Does this break const?
import std.stdio;
class S
{
this(int a)
{
this.a = a;
this.increment = { this.a++; };
}
int a;
void delegate() increment;
void oops()
On Monday, 18 June 2012 at 20:53:27 UTC, Nick Sabalausky wrote:
Kapps opantm2+s...@gmail.com wrote in message
news:jikemjmapclwcufpw...@forum.dlang.org...
On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:
I recently switched from Eclipse to monoD and found that all
my code to
On 6/18/2012 11:10 AM, Adam Wilson wrote:
On Mon, 18 Jun 2012 10:50:44 -0700, Walter Bright newshou...@digitalmars.com
wrote:
On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not compatible with the MSVC
Does this somewhat vague statement meant that we are getting COFF
support in the near term?
Yes, because that is necessary for MSVC linker compatibility.
Hooray!
On Monday, 18 June 2012 at 18:05:59 UTC, Daniel wrote:
Same here, I wish there were a standardized pre-lexed-token
binary file-format, would benefit all text editors also, as
they need to lex it anyway to perform color syntax highlighting.
If I were to make my own language, I'd forego a
On 06/19/2012 02:47 AM, Chris Cain wrote:
On Monday, 18 June 2012 at 18:05:59 UTC, Daniel wrote:
Same here, I wish there were a standardized pre-lexed-token binary
file-format, would benefit all text editors also, as they need to lex
it anyway to perform color syntax highlighting.
If I were
I'm attempting Project Euler's problem 11.
http://projecteuler.net/problem=11
Currently, my code looks like posted below, and it gives
object.Error: Access Violation
at runtime.
Question: how to read that grid from a text file? (See link above.)
If you have ideas for using something other
IK:
Question: how to read that grid from a text file?
I don't know the cause of your problem. While investigating it I
have filed another bug:
http://d.puremagic.com/issues/show_bug.cgi?id=8260
In the meantime this (a bit scary) code solves your reading
problem:
import std.stdio,
1 - 100 of 138 matches
Mail list logo
