Re: Looking for documentation of D's lower-level aspects.

2011-10-21 Thread Jonathan M Davis 
On Saturday, October 22, 2011 04:12:36 Sean Silva wrote:
> > You _can_ use D with no to minimal GC, but you have to be very careful.
> > A good chunk of the standard library would be completely unusable
> > without the GC (primarily anything which might allocate or append to an
> > array), you have to be very careful when using arrays (since appending
> > to them wouldn't work, and you have to worry about who owns an array so
> > that slices don't result in memory leaks or you using a slice which has
> > already be freed), and there are some cases where something might
> > allocate using the GC when you don't expect. For instance.
> > int[3] a = [1, 2, 3];
> > currently allocates a dynamic array which is the copied into the static
> > array. It shouldn't allocate like that, and it _will_ be fixed so that
> > it doesn't, but for now it does.
> > Generally, I'd say that the best way to deal with D is to just not worry
> > about the GC until you profile your code and see that it's a problem.
> > If don't need inheritance and so are using primarily structs rather
> > than classes, you often don't need to allocate much on the heap. If
> > you're not doing a lot with classes, the primary thing on the heap
> > would be arrays (including strings). But if you're smart about avoiding
> > unnecessary allocations, the abilities that the GC gives you with
> > arrays (such as concatenation and the ability to use slices without
> > worrying about how many references to it there are) are well worth it.
> > Essentially, as long as you avoid constantly allocating stuff on the
> > heap, the GC shouldn't cause you much trouble.
> > - Jonathan M Davis
> 
> I don't have anything against GC or just having the GC hang around. In fact,
> it is GC and D's "nice" dynamic arrays that let it do so much cool stuff at
> compile time (since they are safe), which is one of the biggest wins of D
> IMO.
> 
> For me, it's not so much a matter of performance as that I personally prefer
> to have a coherent interface to all my containers, so even though it is a
> bit of syntactic overhead, I would prefer `Vector!int` and `List!int` than
> `int[]` and `List!int`. Built-in niceties are great, but for real work I
> prefer to have a coherent library. E.g. my C++ code using STL has *far*
> fewer bugs than my Python code, and I'm equally knowledgeable about both
> languages, maybe Python a bit more since I've used it longer (that STL
> achieves raw C performance is another big benefit). For me, it's the same
> reason that it's preferable to have `sort()` be a free function (within a
> coherent algorithms library like std.algorithm) rather than a method of the
> built-in arrays (I noticed that D has `array.sort`, but I think it must be
> a carry-over from the past before D had std.algorithm; or maybe it is for
> compile-time programming?).

The built-in sort on arrays is going away. std.algorithm.sort should be used 
instead. I'm afraid that I don't understand what your comments on the STL have 
to do with the GC though. And stuff in Phobos (such as std.algorithm) is very 
much like the STL - only it uses ranges instead of iterators. The main item 
lacking is a comprehensive list of containers, and the main reason that 
std.container doesn't have more yet is because the custom allocator stuff is 
still being sorted out, and Andrei doesn't want to implement them all and then 
have to change them to work with custom allocators. So, once that's done, I 
don't know what the STL would really give you that Phobos doesn't.

- Jonathan M Davis

Re: Looking for documentation of D's lower-level aspects.

2011-10-21 Thread Sean Silva 
> You _can_ use D with no to minimal GC, but you have to be very careful. A good
> chunk of the standard library would be completely unusable without the GC
> (primarily anything which might allocate or append to an array), you have to
> be very careful when using arrays (since appending to them wouldn't work, and
> you have to worry about who owns an array so that slices don't result in
> memory leaks or you using a slice which has already be freed), and there are
> some cases where something might allocate using the GC when you don't expect.
> For instance.
> int[3] a = [1, 2, 3];
> currently allocates a dynamic array which is the copied into the static array.
> It shouldn't allocate like that, and it _will_ be fixed so that it doesn't, 
> but
> for now it does.
> Generally, I'd say that the best way to deal with D is to just not worry about
> the GC until you profile your code and see that it's a problem. If don't need
> inheritance and so are using primarily structs rather than classes, you often
> don't need to allocate much on the heap. If you're not doing a lot with
> classes, the primary thing on the heap would be arrays (including strings).
> But if you're smart about avoiding unnecessary allocations, the abilities that
> the GC gives you with arrays (such as concatenation and the ability to use
> slices without worrying about how many references to it there are) are well
> worth it.
> Essentially, as long as you avoid constantly allocating stuff on the heap, the
> GC shouldn't cause you much trouble.
> - Jonathan M Davis

I don't have anything against GC or just having the GC hang around. In fact, it 
is GC and D's "nice" dynamic arrays that let it do so much
cool stuff at compile time (since they are safe), which is one of the biggest 
wins of D IMO.

For me, it's not so much a matter of performance as that I personally prefer to 
have a coherent interface to all my containers, so even though
it is a bit of syntactic overhead, I would prefer `Vector!int` and `List!int` 
than `int[]` and `List!int`. Built-in niceties are great, but
for real work I prefer to have a coherent library. E.g. my C++ code using STL 
has *far* fewer bugs than my Python code, and I'm equally
knowledgeable about both languages, maybe Python a bit more since I've used it 
longer (that STL achieves raw C performance is another big
benefit). For me, it's the same reason that it's preferable to have `sort()` be 
a free function (within a coherent algorithms library like
std.algorithm) rather than a method of the built-in arrays (I noticed that D 
has `array.sort`, but I think it must be a carry-over from the
past before D had std.algorithm; or maybe it is for compile-time programming?).

opAssign for structs

2011-10-21 Thread Sean Silva 
In the language definition , it 
says:

> Struct assignment t=s is defined to be semantically equivalent to:
>   t = S.opAssign(s);
> where opAssign is a member function of S:
>   S* opAssign(S s)
>   {   ... bitcopy *this into tmp ...
>   ... bitcopy s into *this ...
>   ... call destructor on tmp ...
>   return this;
>   }

I'm struggling with this on 4 fronts:

1. What is `this`, when opAssign is called off of the type? (does it even make 
sense to call a member function without an instance?)
2. The return value of opAssign is `S*`, so it would seem that `t` is assigned 
a pointer value?
3. What is `tmp`, just another stack allocated instance of S?
4. What is the syntax for explicitly calling the destructor? (In C++, it is 
tmp.~S(), but in D would it be tmp.~this() or what?)

Re: Looking for documentation of D's lower-level aspects.

2011-10-21 Thread Jonathan M Davis 
On Saturday, October 22, 2011 01:20:05 Sean Silva wrote:
> == Quote from Trass3r (u...@known.com)'s article
> 
> > Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
> 
> :
> > > == Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
> 
> article
> 
> > >> Right now D isn't ready to be used in this fashion
> > > 
> > > It looks there's a more-or-less functional kernel written in D
> 
> (and
> 
> > > pretty well documented too):
> > > http://wiki.xomb.org/index.php?title=Main_Page
> > 
> > "You do not need the Tango standard library to compile XOmB as it
> 
> contains
> 
> > its own standard calls and runtime."
> 
> that was my point ... that it seems that D *is* "ready to be used in
> this fashion" ;)

You _can_ use D with no to minimal GC, but you have to be very careful. A good 
chunk of the standard library would be completely unusable without the GC 
(primarily anything which might allocate or append to an array), you have to 
be very careful when using arrays (since appending to them wouldn't work, and 
you have to worry about who owns an array so that slices don't result in 
memory leaks or you using a slice which has already be freed), and there are 
some cases where something might allocate using the GC when you don't expect. 
For instance.

int[3] a = [1, 2, 3];

currently allocates a dynamic array which is the copied into the static array. 
It shouldn't allocate like that, and it _will_ be fixed so that it doesn't, but 
for now it does.

Generally, I'd say that the best way to deal with D is to just not worry about 
the GC until you profile your code and see that it's a problem. If don't need 
inheritance and so are using primarily structs rather than classes, you often 
don't need to allocate much on the heap. If you're not doing a lot with 
classes, the primary thing on the heap would be arrays (including strings). 
But if you're smart about avoiding unnecessary allocations, the abilities that 
the GC gives you with arrays (such as concatenation and the ability to use 
slices without worrying about how many references to it there are) are well 
worth it.

Essentially, as long as you avoid constantly allocating stuff on the heap, the 
GC shouldn't cause you much trouble.

- Jonathan M Davis

Re: Cannot use auto return while using class invariants

2011-10-21 Thread simendsjo 

On 22.10.2011 02:06, Jonathan M Davis wrote:

On Friday, October 21, 2011 16:51 simendsjo wrote:

Is this a temporary restriction?

class C {
invariant() { }
auto f() {
return 1;
}
}

Error: function C.f post conditions are not supported if the return type
is inferred


http://d.puremagic.com/issues/show_bug.cgi?id=5039


Thanks. Doesn't look like it will be fixed for a while.

Re: Looking for documentation of D's lower-level aspects.

2011-10-21 Thread Sean Silva 
== Quote from Trass3r (u...@known.com)'s article
> Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
:
> > == Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
article
> >> Right now D isn't ready to be used in this fashion
> >
> > It looks there's a more-or-less functional kernel written in D
(and
> > pretty well documented too):
> > http://wiki.xomb.org/index.php?title=Main_Page
> "You do not need the Tango standard library to compile XOmB as it
contains
> its own standard calls and runtime."

that was my point ... that it seems that D *is* "ready to be used in
this fashion" ;)

Re: Cannot use auto return while using class invariants

2011-10-21 Thread Jonathan M Davis 
On Friday, October 21, 2011 16:51 simendsjo wrote:
> Is this a temporary restriction?
> 
> class C {
> invariant() { }
> auto f() {
> return 1;
> }
> }
> 
> Error: function C.f post conditions are not supported if the return type
> is inferred

http://d.puremagic.com/issues/show_bug.cgi?id=5039

Cannot use auto return while using class invariants

2011-10-21 Thread simendsjo 

Is this a temporary restriction?

class C {
invariant() { }
auto f() {
return 1;
}
}

Error: function C.f post conditions are not supported if the return type 
is inferred

Re: AI Challenge - Ants

2011-10-21 Thread maarten van damme 
great, I'm going to try it out.
I've been looking for something fun to do while improving programming skill
for ages and this looks great :)

creating a proxy dll

2011-10-21 Thread maarten van damme 
I'm trying to create a proxy dll( a dll forwarding all it's functions to
another dll)
I renamed the dll I want to replace (let's call him foo) to oldfoo.dll
then I created the import library oldfoo.lib and created oldfoo.def with as
syntax

"
LIBRARY "oldfoo"

IMPORTS
internalbar=oldfoo.bar
...
"

and then I created a D file called foo.d with a valid dllmain and then an
extern(c) block with in it the following syntax:

"
void * internalbar();
...

//
void *bar(){asm{naked;jmp internalbar;}}
...
"

and when I compile it I get the following error:

"
C:\Users\maarten\Desktop\workingdir>dmd foo.d oldfoo.def oldfoo.lib
OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 148: USE16/USE32 Mismatch : DGROUP
C:\D\dmd2\windows\bin\..\lib\SNN.lib(dllstart)
 Error 83: Illegal frame on start address
OPTLINK : Warning 174: 32-bit Segments Inappropriate for 16-bit Segmented
output

foo.obj(foo)
 Error 35: Cannot Reach TARGET from FRAME at Relative 0002BH  from
 Segment _TEXT
 FRAME  = Frame of Group FLAT 
 TARGET = External Symbol
_D4core3sys7windows3dll18dll_process_detachFT4core3sys
7windows7windows6HANDLEbZv 00070H
 FIXUPP Type = 32-bit Conditional JMP
--- errorlevel 2
"

Can someone point me a bit in the right direction? I've tried this in the
past but then I understood nearly nothing about .def files an .lib files.
Now that I know a bit more I wanted to take up the challenge again.

Re: AI Challenge - Ants

2011-10-21 Thread Marco Leise 

Am 21.10.2011, 06:31 Uhr, schrieb Jonathan M Davis :


On Friday, October 21, 2011 06:22:43 Marco Leise wrote:

Hi! I've been part of the team behind http://aichallenge.org/. We just
started our next challenge about 30 minutes ago.
This will be the first time that DMD 2.054 is supported there and since
I've been posting on this NG a few times I though it would be a good  
place

to make an announcement.

So here is the deal: You write a program that controls a population of
ants. You get a number of ant hills and explore the map with your ant
horde looking for food to produce more ants and enemy ant hills that you
can raze for points.
There is fog-of-war and obstacles. Moving ants in groups gives them  
better
chances to survive by outnumbering enemies. The map is on a grid and  
ants

wrap around if they move over the edges. A match usually has between 2-8
players and is turn based. The players make their moves simultaneously
within a time window of 500ms. Oh yeah and it is free to sign up and
requires no previous knowledge in AI programming.

Feel free to ask questions on the IRC channel #aichallenge on Freenode.


Sounds cool, but there's actually a list specifically for announcements:
digitalmars-d-announce. http://www.digitalmars.com/NewsGroup.html

- Jonathan M Davis


Thanks for mentioning it.

Re: Chars sorting and copies

2011-10-21 Thread Kagamin 
bearophile Wrote:

> I have many strings and I want to use as associative array kay a sorted 
> concat of two strings (it's a signature of the two strings):
> 
> 
> import std.algorithm;
> void main() {
> string a = "red";
> string b = "green";
> int[string] aa;
> //aa[(a ~ b).sort] = 1;
> //aa[(a ~ b).sort.idup] = 1;
> aa[(a.dup ~ b.dup).sort.idup] = 1;
> }
> 
> I think the first way used to work, the second way was recently forbidden 
> (and you can't use char[] as associative array key). The third way now works, 
> but array.sort will go away.
> 
> So do you know what's a copy-minimizing (and possibly short) way to perform 
> this, in future?
> 
> Bye and thank you,
> bearophile

http://www.d-programming-language.org/phobos/std_algorithm.html#setUnion ?

Re: Implicit cast to immutable

2011-10-21 Thread Christophe 
"Daniel Murphy" , dans le message (digitalmars.D.learn:30139), a écrit :
> "bearophile"  wrote in message 
> news:j7jepi$prp$1...@digitalmars.com...
>> Daniel Murphy:
>>
>>> 2)
>>> immutable(int[]) fun() { return new int[]; } // conversion happens here
>>> immutable x  = fun();
>>>
>>> Bearophile's example is of the second, where it definately matters what 
>>> the
>>> purity of the function is.
>>
>> This is the enhancement request I have written days ago:
>> http://d.puremagic.com/issues/show_bug.cgi?id=6783
>>
>> Bye,
>> bearophile
> 
> Yes, and the problem in that report is that the function is const-pure, not 
> strong-pure.
> Without checking if the return type can contain a non-immutable reference 
> from the arguments, it is not safe to implicitly convert the result to 
> immutable.
> 
> eg.
> immutable(int[]) foo(in int[] x) { return x; }
> auto g = [1, 2, 3];
> auto a = foo(g.idup); //safe
> auto b = foo(g); // unsafe
> 
> Checking at the call site is possible, but not from inside the function.
> 
> int[] foo(in int[] x) { return new int[](3); }
> auto g = [1, 2, 3];
> immutable a = foo(g.idup); // safe
> immutable b = foo(g); // unsafe, and easily rejected
> 
> In your example, it is safe as the argument is not returned.  Allowing this 
> in the general case requires checking (recursively) that the return type 
> does not contain any types that any of the arguments can implicitly convert 
> to that are non-immutable. 

What is the rule ?
The result of a pure function can be cast to immutable if the arguments 
are immutable. That requires specific checking by the compiler. The real 
type of the argument prior to the conversion to the argument type has to 
be checked.

in, scope, or inout arguments are supposed to solve the problem with 
function site checking: without call-site checking, which are IMO a 
rather bad idea.

The result of
pure int[] foo(in int[] x);
is castable to immutable, since elements of x are not supposed to escape 
the function.

The result of
pure int[] foo(const int[] x);
is not, because the value return by foo may be elements of x.