Fawzi Mohamed wrote:
I don't find a valid D1 expression to put in place of scope, or to
somehow hide it, i.e. how do you write something like
module t;
void f(scope void delegate() action){
action();
}
void main(){
f(scope delegate(){
printf("bla\n");
});
}
so that it is v
On 19-nov-10, at 08:08, Walter Bright wrote:
Fawzi Mohamed wrote:
From the discussion it seems that defining something like:
version(D_Version2){
mixin(`
template Const(T){
alias const(T) Const;
}
template Immutable(T){
alias immutable(T) Immutable;
}
immutable(T
On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote:
> I just created a new D Improvement Proposal to fix the toString problem
> I brought up several posts ago.
>
> See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
I think it's best to leave out the '%' from the format s
Fawzi Mohamed wrote:
From the discussion it seems that defining something like:
version(D_Version2){
template Const(T){
alias const(T) Const;
}
template Immutable(T){
alias immutable(T) Immutable;
}
immutable(T) Idup(T)(T val){
return val.idup;
}
On Thu, 18 Nov 2010 11:26:39 +, Steve Teale wrote:
> I had D code that provided a basis for creation of Windows services,
> which I have just tried to get working with the latest D2.
>
> No dice.
>
I have made some progress in understanding this. It appears that any D
static data structures
> As I said before, I don't know if the thread being created by the
> windows service procedure is properly initializing the D modules of the
> library/runtime. Try as the first line of ServiceMain to initialize the
> current thread:
>
> auto mythread = thread_attachThis();
>
> see http://www.d
From the discussion it seems that defining something like:
version(D_Version2){
template Const(T){
alias const(T) Const;
}
template Immutable(T){
alias immutable(T) Immutable;
}
immutable(T) Idup(T)(T val){
re
bearophile wrote:
C#4 designers seem to have found a way to implement "old" (Prestate Values)
correctly enough, so can't D2 adopt a similar solution?
C#'s designers did not implement contract inheritance, which is a rather
critical feature. Without inheritance, contracts are little more than j
Most Recent: http://is.gd/hovyR
Other than some minor documentation changes, all of the changes are to the
implementation rather than the API, though those changes are fairly minimal as
well (albeit important).
I fixed it so that the stopwatch code uses a monotonic clock on both Windows
and
L
On 16/11/2010 19:11, Steve Teale wrote:
I have moaned several times about the fact that this module does not
have a method for creating a date from the system clock.
Does getUTCtime() not do this? What does it do then?
It also strikes me as odd that it does not include a table of leap
secon
On Thursday, November 18, 2010 14:21:20 Steven Schveighoffer wrote:
> I just created a new D Improvement Proposal to fix the toString problem I
> brought up several posts ago.
>
> See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Looks good overall, but I would point out that the te
Asynchronous Programming in C#5:
http://blogs.microsoft.co.il/blogs/arik/archive/2010/10/30/pdc-2010-the-future-of-c-and-visual-basic.aspx
This is several hundreds MBs, I don't know the link to the low-res mp4 file:
http://videoaz.microsoftpdc.com/vod/pdc10_pre_event/ShowContent_VOD/FT09_AndersHej
Jonathan M Davis Wrote:
> Just dereference the pointer. I believe that in effect you have a pointer to
> a
> reference, not a pointer to an Object. Regardless of what it does internally
> though, the way to get at the object is to dereference it. If you had
The question wasn't exactly about ho
Jens Mueller:
> I see. bearophile even has a bug for this problem
> (http://d.puremagic.com/issues/show_bug.cgi?id=5027)
Issue 5027 is about ghost fields, not about "old", it's a related but separated
problem/solution. In the meantime the idea of ghost fields was shot down for
not being so impo
Andrei Alexandrescu wrote:
> On 11/18/10 1:57 PM, Jens Mueller wrote:
> >bearophile wrote:
> >>Jens Mueller:
> >>
> >>>I don't like the "old" approach.
> >>
> >>Why?
> >>(It's the canonical way to solve the problem you have had. It is present in
> >>Eiffel and C# and probably something similar is
Steven Schveighoffer:
> I just created a new D Improvement Proposal to fix the toString problem I
> brought up several posts ago.
Thank you for writing the DIP. It looks interesting. I suggest to add an
example, the implementation of toString() and writeTo() for a simple struct
like this (or
On Thu, 18 Nov 2010 21:13:19 +0100, Don wrote:
> Lars T. Kyllingstad wrote:
>> First of all, I think Andrei has already implemented this in the
>> write*() functions. I use this toString() style also for
>> std.complex.Complex, and I can print complex numbers no problem.
>
> Really? It doesn't w
On Thursday, November 18, 2010 14:20:01 Jesse Phillips wrote:
> I usually avoid using pointers and classes together (actually I don't use
> pointers very much). But using 'in' on an associative array provides a
> pointer.
>
> In any case, I ended up casting the pointer to the class type. (The
> si
On 11/18/10 2:02 PM, bearophile wrote:
Andrei:
I don't see anything remotely clever in the solution I suggested.
I am not clever enough...
This would be more credible if this were indeed a matter of being
clever. It is a basic juxtaposition of ubiquitous features.
At some point it's wor
I just created a new D Improvement Proposal to fix the toString problem I
brought up several posts ago.
See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
-Steve
Jens Mueller:
>This copying behind the scenes seems surprising to me. Maybe I do not fully
>understand the
approach.<
The compiler statically knows what things are needed in their older state (only
ones accessed with "old." in the postcondition), so useless copying is avoided.
>that right now
I usually avoid using pointers and classes together (actually I don't use
pointers very much). But using 'in' on an associative array provides a pointer.
In any case, I ended up casting the pointer to the class type. (The simplified
example isn't showing the behavior). The results were not good.
Andrei Alexandrescu wrote:
On 11/18/10 1:25 PM, Don wrote:
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
std.comp
On 11/18/10 1:07 PM, bearophile wrote:
Andrei:
I don't think they have contracts in interfaces, which is where most difficulty
lies.<
There is some discussion about this topic at page 11 here:
http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf
That approach is essentially a
Andrei Alexandrescu wrote:
On 11/18/10 1:50 PM, Michel Fortin wrote:
On 2010-11-18 16:02:40 -0500, "Steven Schveighoffer"
said:
class obj
{
char[] name;
this(char[] name) { this.name = name;}
}
What to do there?
I agree that it just seems like good class design to have obj.name be immutab
On 11/18/10 1:57 PM, Jens Mueller wrote:
bearophile wrote:
Jens Mueller:
I don't like the "old" approach.
Why?
(It's the canonical way to solve the problem you have had. It is present in
Eiffel and C# and probably something similar is present in the DbC for Java.
But surely other solutions
Denis Koroskin wrote:
All these are ugly.
I agree.
Andrei:
> I don't see anything remotely clever in the solution I suggested.
I am not clever enough...
> At some point it's worth starting to use the language to devise solutions
> to problems instead of inventing a new feature for any problem that
> comes about.
That was not a new unexpected
bearophile wrote:
> Jens Mueller:
>
> > I don't like the "old" approach.
>
> Why?
> (It's the canonical way to solve the problem you have had. It is present in
> Eiffel and C# and probably something similar is present in the DbC for Java.
> But surely other solutions are possible.)
Somehow it
On 2010-11-18 16:02:40 -0500, "Steven Schveighoffer"
said:
class obj
{
char[] name;
this(char[] name) { this.name = name;}
}
What to do there? If name is typically a string literal, then string
is appropriate. But if there are cases where a name is passed in via
a char[] allocat
On 11/18/10 1:50 PM, Michel Fortin wrote:
On 2010-11-18 16:02:40 -0500, "Steven Schveighoffer"
said:
class obj
{
char[] name;
this(char[] name) { this.name = name;}
}
What to do there? If name is typically a string literal, then string
is appropriate. But if there are cases where a name is pa
On 11/18/10 1:25 PM, Don wrote:
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
std.complex.Complex, and I can print
On Thursday 18 November 2010 13:29:15 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Thursday 18 November 2010 12:08:19 Jens Mueller wrote:
> > > I like it.
> > > Thanks.
> > > What I'd even like better (because contracts are release specific):
> > > release {
> > >
> > > const currentWi
On 11/18/10 1:07 PM, bearophile wrote:
Andrei:
I don't think they have contracts in interfaces, which is where most difficulty
lies.<
There is some discussion about this topic at page 11 here:
http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf
At any rate, it's not that we
On Thu, 18 Nov 2010 16:25:28 -0500, Don wrote:
Steven Schveighoffer wrote:
I'd suggest trying one of those other format types without the numeric
parts.
-Steve
writefln("z = %f z2 = %f", z, z2);
z = 10+1.5e-06i z2 = 10.00+0.01i
writefln("z = %e z2 = %e", z, z2);
z = 1
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
std.complex.Complex, and I can print complex numbers no problem.
Jonathan M Davis wrote:
> On Thursday 18 November 2010 12:08:19 Jens Mueller wrote:
> >
> > I like it.
> > Thanks.
> > What I'd even like better (because contracts are release specific):
> > release {
> > const currentWidth = width;
> > const currentHeight = height;
> > scope (exit) {
On Thursday 18 November 2010 13:02:40 Steven Schveighoffer wrote:
> On Thu, 18 Nov 2010 15:49:10 -0500, Walter Bright
>
> wrote:
> > Steven Schveighoffer wrote:
> >> It's not impossible, but Tango's #1 rule is minimize heap allocations.
> >> By peppering idup everywhere, you have created a confli
On Thursday 18 November 2010 03:35:49 Kagamin wrote:
> Jonathan M Davis Wrote:
> > If you have a better way to do it, I'm all ears. However, it's the only
> > way that I know of to get high-precision time on Windows.
>
> Use GetSystemTime. At least, it will be correct.
Actually, looking at TickDu
Andrei:
>I don't think they have contracts in interfaces, which is where most
>difficulty lies.<
There is some discussion about this topic at page 11 here:
http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf
>At any rate, it's not that we can't do it, it was just a large effort
On Thu, 18 Nov 2010 15:49:10 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
It's not impossible, but Tango's #1 rule is minimize heap allocations.
By peppering idup everywhere, you have created a conflict with the main
goal. Refactoring in these cases isn't quite as simple as y
On Thu, 18 Nov 2010 22:39:31 +0300, Walter Bright
wrote:
Denis Koroskin wrote:
From my experience, a bigger issue is that
version (D2) {
/* some D2 only code involving const etc */
}
simply won't compile in D1, because even if it's D2-only the code
needs to be correct D1 code as well
Walter Bright wrote:
I agree that's an issue. Currently, the only way to deal with this is
one of:
There's a 4th method I almost hesitate to mention, but you can use a common
source code file, and a macro text preprocessor (such as m4) to generate the D1
and D2 versions from it.
Steven Schveighoffer wrote:
It's not impossible, but Tango's #1 rule is minimize heap allocations.
By peppering idup everywhere, you have created a conflict with the main
goal. Refactoring in these cases isn't quite as simple as you say, and
it certainly won't be backwards compatible.
If yo
Jens Mueller:
> I don't like the "old" approach.
Why?
(It's the canonical way to solve the problem you have had. It is present in
Eiffel and C# and probably something similar is present in the DbC for Java.
But surely other solutions are possible.)
> Don't get your point here. You neither lik
On Thursday 18 November 2010 12:08:19 Jens Mueller wrote:
> Andrei Alexandrescu wrote:
> > On 11/18/10 9:48 AM, Jens Mueller wrote:
> > >I think of an member function invariant as something more fine-grained
> > >than a class invariant. Of course calling move() needs to preserve the
> > >class inva
Andrei Alexandrescu wrote:
> On 11/18/10 12:08 PM, Jens Mueller wrote:
> >What I'd even like better (because contracts are release specific):
> >release {
> > const currentWidth = width;
> > const currentHeight = height;
> > scope (exit) {
> > assert(currentWidth == width);
> >
On Thu, 18 Nov 2010 14:43:17 -0500, spir wrote:
On Thu, 18 Nov 2010 07:34:01 -0500
"Steven Schveighoffer" wrote:
4. if you intend on returning a portion of the string, well, currently
you're SOL, but eventually inout will come into play here.
For example, Tango's log package fell under rule
bearophile wrote:
> Jens Mueller:
>
> > I have a rectangle and one of its methods moves the upper left
> > of the rectangle. I have two invariants when moving a rectangle: The
> > width and the height do not change. I could do something like the
> > following:
> >
> > void move(...) {
> > int
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
std.complex.Complex, and I can print complex numbers no problem.
Really? It doesn't work for
On 11/18/10 12:08 PM, Jens Mueller wrote:
What I'd even like better (because contracts are release specific):
release {
const currentWidth = width;
const currentHeight = height;
scope (exit) {
assert(currentWidth == width);
assert(currentHeight == height);
}
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the write*()
functions. I use this toString() style also for std.complex.Complex, and
I can print complex numbers no problem.
Really? It doesn't work for me.
import std.complex;
import std.stdio;
void ma
On Thu, 18 Nov 2010 07:34:01 -0500
"Steven Schveighoffer" wrote:
> 4. if you intend on returning a portion of the string, well, currently
> you're SOL, but eventually inout will come into play here.
>
> For example, Tango's log package fell under rules 1 and 3 (most of the
> time you are cre
On Thu, 18 Nov 2010 14:50:06 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 14:19:12 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
My recommendation -- when you are ready, switch wholly to D2. Don't
bother with compatibility, it's just not possi
Andrei Alexandrescu wrote:
> On 11/18/10 9:48 AM, Jens Mueller wrote:
> >I think of an member function invariant as something more fine-grained
> >than a class invariant. Of course calling move() needs to preserve the
> >class invariant but actually in case of move() it should also do
> >something
On Thu, 18 Nov 2010 17:01:03 + (UTC)
"Lars T. Kyllingstad" wrote:
> That said, I also think toString is a bad name for this. Especially
> considering it will be used as an imperative, i.e.
>
> obj.toString(sink);
obj.writeTo(sink);
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
sp
On 11/18/2010 12:39, Walter Bright wrote:
> I agree that's an issue. Currently, the only way to deal with this is
> one of:
>
> 1. Minimize the differences, and maintain two copies of the source code.
> Using the (rather fabulous) meld tool (available on Linux), the merging
> is pretty easy. I use
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> On Thu, 18 Nov 2010 22:19:12 +0300, Walter Bright
> wrote:
> > Steven Schveighoffer wrote:
> >> My recommendation -- when you are ready, switch wholly to D2. Don't
> >> bother with compatibility, it's just not possible.
> >
> > From wh
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 14:19:12 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
My recommendation -- when you are ready, switch wholly to D2. Don't
bother with compatibility, it's just not possible.
From what you wrote, it appears that most of the difficu
On Thu, 18 Nov 2010 14:19:12 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
My recommendation -- when you are ready, switch wholly to D2. Don't
bother with compatibility, it's just not possible.
From what you wrote, it appears that most of the difficulties were in
dealing wit
Denis Koroskin wrote:
From my experience, a bigger issue is that
version (D2) {
/* some D2 only code involving const etc */
}
simply won't compile in D1, because even if it's D2-only the code needs
to be correct D1 code as well.
I agree that's an issue. Currently, the only way to deal wi
On Thu, 18 Nov 2010 20:07:38 +0900
Mike Parker wrote:
> On 11/18/2010 7:51 PM, Fawzi Mohamed wrote:
> > Is there any "porting" guide around in a wiki?
> > If not a page where to share the best tricks would be nice "D1->D2
> > conversion tricks"?
> >
> > In the short term I don't think that going
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> I want to create a DIP, but it looks like I can't edit anything without a
> 'valid' username. However, when I put schveiguy as a username, it says
> that's not valid. How do I get a valid username?
> -Steve
The username has to
On Thu, 18 Nov 2010 22:19:12 +0300, Walter Bright
wrote:
Steven Schveighoffer wrote:
My recommendation -- when you are ready, switch wholly to D2. Don't
bother with compatibility, it's just not possible.
From what you wrote, it appears that most of the difficulties were in
dealing wit
On 11/18/10 11:19 AM, Kagamin wrote:
Steven Schveighoffer Wrote:
to!string(x);
What's with text(x); ?
text, wtext, and dtext accept a variable number of arguments of all
types and create one string by concatenating to!(w|d|)string for all inputs.
Andrei
Steven Schveighoffer wrote:
My recommendation -- when you are ready, switch wholly to D2. Don't
bother with compatibility, it's just not possible.
From what you wrote, it appears that most of the difficulties were in dealing
with strings. Might I suggest:
1. Replace all occurrences of char[
Steven Schveighoffer Wrote:
> to!string(x);
>
What's with text(x); ?
On Thu, 18 Nov 2010 13:53:53 -0500, Steve Teale
wrote:
On Thu, 18 Nov 2010 08:33:12 -0500, Steven Schveighoffer wrote:
I think using a class in D is a good idea. But what you may need is
global functions which forward to your class methods. This is how I
would probably do it.
-Steve
S
On Thu, 18 Nov 2010 08:33:12 -0500, Steven Schveighoffer wrote:
>
> I think using a class in D is a good idea. But what you may need is
> global functions which forward to your class methods. This is how I
> would probably do it.
>
> -Steve
Steve,
Thanks. I kind of went that way. Having done
On Thu, 18 Nov 2010 10:14:07 -0500, Steven Schveighoffer
wrote:
Should we create a DIP for this? I'll volunteer to spearhead the effort
if people are on board.
I want to create a DIP, but it looks like I can't edit anything without a
'valid' username. However, when I put schveiguy as
On 11/18/10 10:12 AM, bearophile wrote:
Andrei:
There is a limitation of the current system in that the out contract
can't see the scope of the in contract. Walter and I tried to find a
solution, but it was technically difficult in the presence of inheritance.
C#4 designers seem to have found
Andrei:
> There is a limitation of the current system in that the out contract
> can't see the scope of the in contract. Walter and I tried to find a
> solution, but it was technically difficult in the presence of inheritance.
C#4 designers seem to have found a way to implement "old" (Prestate
Jens Mueller:
> I have a rectangle and one of its methods moves the upper left
> of the rectangle. I have two invariants when moving a rectangle: The
> width and the height do not change. I could do something like the
> following:
>
> void move(...) {
> int currentWidth = width;
> int cur
On Thursday, November 18, 2010 10:03:16 Jonathan M Davis wrote:
> On Thursday, November 18, 2010 09:48:08 Jens Mueller wrote:
> > Does it make more sense to talk about an invariant for a member
> > function? I mean the member function changes the state of the instance
> > but there may be some inva
On 11/18/10 9:48 AM, Jens Mueller wrote:
I think of an member function invariant as something more fine-grained
than a class invariant. Of course calling move() needs to preserve the
class invariant but actually in case of move() it should also do
something more, namely before calling and after t
On Thursday, November 18, 2010 09:48:08 Jens Mueller wrote:
> Does it make more sense to talk about an invariant for a member
> function? I mean the member function changes the state of the instance
> but there may be some invariant when changing it. Basically some change
> is allowed but the other
Jonathan M Davis wrote:
> On Thursday 18 November 2010 06:09:33 Jens Mueller wrote:
> > Hi,
> >
> > I'm wondering what's a good way to do invariants for methods. In my
> > example I have a rectangle and one of its methods moves the upper left
> > of the rectangle. I have two invariants when moving
On Thu, 18 Nov 2010 10:53:20 -0500, Steven Schveighoffer wrote:
> On Thu, 18 Nov 2010 10:44:00 -0500, Nick Sabalausky wrote:
>
>> I like it, *provided that* there's a quick-and-easy way to just get a
>> string
>> when that's all you want. At the very least there should be a standard
>> sink
>> f
On 11/18/10 7:14 AM, Steven Schveighoffer wrote:
A recent bug report reminded me of how horrible D is at printing custom
types.
Consider a container type that contains 1000 elements, such as a linked
list. If you print this type, you would expect to get a printout similar
to an array, i.e.:
[ 1
On Thursday 18 November 2010 06:09:33 Jens Mueller wrote:
> Hi,
>
> I'm wondering what's a good way to do invariants for methods. In my
> example I have a rectangle and one of its methods moves the upper left
> of the rectangle. I have two invariants when moving a rectangle: The
> width and the he
On Thu, 18 Nov 2010 10:14:07 -0500, Steven Schveighoffer wrote:
> A recent bug report reminded me of how horrible D is at printing custom
> types.
>
> Consider a container type that contains 1000 elements, such as a linked
> list. If you print this type, you would expect to get a printout
> simi
On 2010-11-18 11:51, Fawzi Mohamed wrote:
Is there any "porting" guide around in a wiki?
If not a page where to share the best tricks would be nice "D1->D2
conversion tricks"?
In the short term I don't think that going D2 only is really an option
for me, so how feasible it is to keep the code ba
On 18-nov-10, at 16:53, Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 10:44:00 -0500, Nick Sabalausky wrote:
I like it, *provided that* there's a quick-and-easy way to just get
a string
when that's all you want. At the very least there should be a
standard sink
function that's a default
On 18-nov-10, at 17:01, Fawzi Mohamed wrote:
[...]
If you take a look at blip.
ehm that was a leftover form my editing that I did not see because it
was outside the visible area in my mail program... just ignore it.
well you *can* look at blip, but well you get the point...
On 18-nov-10, at 16:14, Steven Schveighoffer wrote:
A recent bug report reminded me of how horrible D is at printing
custom types.
Consider a container type that contains 1000 elements, such as a
linked list. If you print this type, you would expect to get a
printout similar to an array
On Thu, 18 Nov 2010 10:14:07 -0500, Steven Schveighoffer
wrote:
There is a better way, as demonstrated by BigInt (whose author refuses
to implement toString()):
void toString(scope void delegate(scope const(char)[] data), string
format = null)
I should also note, I'm not fond of call
On Thu, 18 Nov 2010 10:44:00 -0500, Nick Sabalausky wrote:
I like it, *provided that* there's a quick-and-easy way to just get a
string
when that's all you want. At the very least there should be a standard
sink
function that's a default argument to toString that just simply builds a
string
"Steven Schveighoffer" wrote in message
news:op.vmdglth8eav...@localhost.localdomain...
>A recent bug report reminded me of how horrible D is at printing custom
>types.
>
> Consider a container type that contains 1000 elements, such as a linked
> list. If you print this type, you would expect
Hi Sean,
On Tue, 16 Nov 2010 10:45:37 -0500, Sean Kelly wrote:
> Graham Fawcett Wrote:
>
>> On Fri, 12 Nov 2010 18:15:15 -0500, Sean Kelly wrote:
>> >
>> > To be honest, I haven't spent much time with Go because my
>> > cursory exposure to the language hasn't shown it to solve the
>> > problems
A recent bug report reminded me of how horrible D is at printing custom
types.
Consider a container type that contains 1000 elements, such as a linked
list. If you print this type, you would expect to get a printout similar
to an array, i.e.:
[ 1 2 3 4 5 ... 1000 ]
If you do this:
writ
Hi,
I'm wondering what's a good way to do invariants for methods. In my
example I have a rectangle and one of its methods moves the upper left
of the rectangle. I have two invariants when moving a rectangle: The
width and the height do not change. I could do something like the
following:
void mov
On Thu, 18 Nov 2010 06:26:39 -0500, Steve Teale
wrote:
I had D code that provided a basis for creation of Windows services,
which I have just tried to get working with the latest D2.
No dice.
The point of failure was in this method
static void StartService()
{
if (!StartServiceCtrlDis
I'm not familiar with the API, but are you able to declare your original _sta
as immutable and call it a day? Immutable data should have the same protection
as __gshared but with no implications of bypassing the type system.
If that's not helpful, can you give more details like calling patterns?
On Thu, 18 Nov 2010 05:51:32 -0500, Fawzi Mohamed wrote:
Is there any "porting" guide around in a wiki?
If not a page where to share the best tricks would be nice "D1->D2
conversion tricks"?
In the short term I don't think that going D2 only is really an option
for me, so how feasible it
Mike Parker wrote:
On 11/18/2010 7:51 PM, Fawzi Mohamed wrote:
In the short term I don't think that going D2 only is really an option
for me, so how feasible it is to keep the code base compatible to both
D1 and D2?
I know that one can define some templates (for example Const(T),),
and ma
On Wed, 17 Nov 2010 22:18:09 -0800, Jonathan M Davis wrote:
> Structs can't have default constructors, so it's impossible to do that.
> In the case of std.datetime, the way to get the current time is
> Clock.currTime(), and since SysTime has a toString() method, you can
> just print it. So, you ca
Jonathan M Davis Wrote:
> If you have a better way to do it, I'm all ears. However, it's the only way
> that
> I know of to get high-precision time on Windows.
Use GetSystemTime. At least, it will be correct.
I had D code that provided a basis for creation of Windows services,
which I have just tried to get working with the latest D2.
No dice.
The point of failure was in this method
static void StartService()
{
if (!StartServiceCtrlDispatcherA(cast(SERVICE_TABLE_ENTRY *) &_sta[0]))
{
...
On 18-nov-10, at 12:07, Mike Parker wrote:
On 11/18/2010 7:51 PM, Fawzi Mohamed wrote:
Is there any "porting" guide around in a wiki?
If not a page where to share the best tricks would be nice "D1->D2
conversion tricks"?
In the short term I don't think that going D2 only is really an
option
On 11/18/2010 7:51 PM, Fawzi Mohamed wrote:
Is there any "porting" guide around in a wiki?
If not a page where to share the best tricks would be nice "D1->D2
conversion tricks"?
In the short term I don't think that going D2 only is really an option
for me, so how feasible it is to keep the code
1 - 100 of 101 matches
Mail list logo
