Re: Dictonaries benchmark

[Dmitry Olshansky]

On 10.04.2012 7:14, SomeDude wrote:

On Tuesday, 10 April 2012 at 01:34:30 UTC, Andrei Alexandrescu wrote:

I think we can derive quite a few insights from here:

http://lh3lh3.users.sourceforge.net/udb.shtml


Andrei


You probably already came accross this benchmark by John-Mark Gurney
http://attractivechaos.wordpress.com/2008/08/28/comparison-of-hash-table-libraries/

who also happens to be the author of these C libraries:
http://attractivechaos.awardspace.com/
(from which Heng Li derived his own optimized implementation)
and a fan of D.





On another matter, Heng Li publishes this regex benchmark:
http://lh3lh3.users.sourceforge.net/reb.shtml
Surprisingly (or maybe not), egrep is faster than everything else by a
very large margin.


>Another possible reason that egrep is fast may be because it does not 
>keep track of grouping.


Being in the know I tell you that fogetting about groups lets you to 
make "bare bones" automation which is an order of magnituide faster then.


BTW it's been years since I see this benchmark. Still no D listed tough 
(is he a fan of D?). For one thing the date pattern is exceptionally 
fast with new std.regex.


--
Dmitry Olshansky

Re: Windows 8 Metro support

[Sönke Ludwig]

Am 10.04.2012 08:55, schrieb Jacob Carlborg:

On 2012-04-10 08:50, Sönke Ludwig wrote:


Haven't seen it before. Unfortunately, he doesn't talk about the
language runtime in detail, but he does talk about how the standard
library needs to be adjusted to use Metro style libraries so I guess the
same would apply to the language RT.

At the end he gives some links and this one might be interesting:
http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T
I'll try to watch that later today.


The thing is, as I understand it, you should be able to use the native
types and standard library types/functions through the WinRT API. So you
would basically build, for example, a (or a couple of) WinRT range(s)to
be able to iterate D collections.

I'm not sure if the language runtime needs to be changed. It depends on
what's expected from the WinRT API.



Okay, I would agree to the first part. This would make the interaction 
with WinRT bidirectional and more or less seemless. But one thing in 
particular, that you are not allowed to do is to use kernel32.dll (at 
least I was told). So you still have to rewrite all the C-library 
functions (such as fopen(), malloc() and so on) and anything that the D 
runtime or Phobos uses from kernel32 or similar libraries; I gues the 
same applies to ws2_32 and so on.

Re: Windows 8 Metro support

[Sönke Ludwig]

Am 10.04.2012 06:09, schrieb Jonathan M Davis:

On Monday, April 09, 2012 23:58:26 Nick Sabalausky wrote:

Speaking of platform support problems, this 64-bit data corruption issue has
been sitting around for months, and basically fubars most (all?) programs
on 64-bit that use old-style varargs (such as std.string.format):

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


Oh, that's easy to top. Passing structs to C functions in 64-bit doesn't work:

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

- Jonathan M Davis


I know I've suffered quite a bit from that one, especially because it 
can be quite hidden and required modifying and maintaining external C 
libraries that expect structs by value.

Re: Windows 8 Metro support

[Jacob Carlborg]

On 2012-04-10 09:24, Sönke Ludwig wrote:


Okay, I would agree to the first part. This would make the interaction
with WinRT bidirectional and more or less seemless. But one thing in
particular, that you are not allowed to do is to use kernel32.dll (at
least I was told). So you still have to rewrite all the C-library
functions (such as fopen(), malloc() and so on) and anything that the D
runtime or Phobos uses from kernel32 or similar libraries; I gues the
same applies to ws2_32 and so on.


That doesn't sound like a good idea, to force every language to rewrite 
their runtime and standard library.


--
/Jacob Carlborg

Object arrays in D

[CrudOMatic]

The D documentation is a little lacking in a lot of areas. I'm 
needing to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are left 
in the deck - when zero, Deck is discarded from the Shoe */

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}

the cards[] array is meant to be an array of Card objects, and 
I'm initializing it in the constructor as seen above. This hasn't 
been tested yet, but I'm needing to know if this is the correct 
way of doing it - to save headaches later.


Also, while I'm here, how would you go about moving objects from 
the cards array in the Deck class to another class containing a 
cards array - I'm talking about MOVING them, not COPYING them. I 
don't want any issues with references being destroyed after being 
moved to another class when I happen to destroy an instance of 
the Deck class.

Re: Windows 8 Metro support

[Sönke Ludwig]

Am 10.04.2012 09:30, schrieb Jacob Carlborg:

On 2012-04-10 09:24, Sönke Ludwig wrote:


Okay, I would agree to the first part. This would make the interaction
with WinRT bidirectional and more or less seemless. But one thing in
particular, that you are not allowed to do is to use kernel32.dll (at
least I was told). So you still have to rewrite all the C-library
functions (such as fopen(), malloc() and so on) and anything that the D
runtime or Phobos uses from kernel32 or similar libraries; I gues the
same applies to ws2_32 and so on.


That doesn't sound like a good idea, to force every language to rewrite
their runtime and standard library.

... or they use the VisualStudio C/C++ runtime as their base, which is 
already adapted.


But since this is all just theory and guesswork, some real tests are 
probably in order - maybe I can do that tomorrow but unfortunately, my 
time is currently extremely limited.

Re: Precise GC

[deadalnix]

Le 09/04/2012 23:27, Walter Bright a écrit :

On 4/9/2012 11:30 AM, deadalnix wrote:

In the other hand, TLS can be collected independently and only
influence the
thread that own the data. Both are every powerfull improvement, and
the design
you propose « as this » cannot provide any mean to handle that. Which
is a big
missed opportunity, and will be hard to change in the future.


I think this is an orthogonal issue.


You mean an allocator/deallocator one ?

I'm not sure. For instance, concurrent shared memory scanning will 
require some magic on reference changes (it can be hooked into the 
program using page protection). In such a case, you have constraint in 
what the scanning function can do or can't.


If the function is scanning immutable data, such a constraint disappears.

In a similar way, when scanning TLS, you'll want to avoid going into non 
TLS world. This is currently possible only of you go back to main GC 
code and trigger the indirect call every single time you encounter a 
pointer or a reference. This is going to be a performance killer on many 
architecture.


So this code, in a way or another will need to be aware of the 
qualifier. Or it will either require to pass every single 
pointer/reference into an indirect function call, or forget about 
optimizations that the type system has been made to allow (in the 
program in general, not especially in the GC).

Re: Windows 8 Metro support

[John Chapman]

On Tuesday, 10 April 2012 at 07:24:09 UTC, Sönke Ludwig wrote:
But one thing in particular, that you are not allowed to do is 
to use kernel32.dll (at least I was told). So you still have to 
rewrite all the C-library functions (such as fopen(), malloc() 
and so on) and anything that the D runtime or Phobos uses from 
kernel32 or similar libraries; I gues the same applies to 
ws2_32 and so on.


Not strictly true. Here's the subset of the Win32 API that can be 
used in Metro apps: 
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx

Re: Precise GC

[deadalnix]

Le 10/04/2012 00:39, Manu a écrit :

It is, and I still don't follow. I can't imagine there are any indirect
function calls, except for the ones introduced by this proposal, where
you may register a function to mark the pointers in complex structs.
You seem to be suggesting that another one already exists anyway? Where
is it? Why is it there?


OK, back to basics.

For every type, a function template (let's call it GCscan) will be 
instantiated to scan it. This function can be ANY code. ANY code include 
the possibility for GCscan!A to call GCscan!B directly, without going 
back to GC main loop and indirect call. If inlined, you can forget about 
function call at all (and you can force that using mixin template for 
example, but it is likely to massively generate code bloat).


This can't be done for reference/pointer to polymorphic types, but for 
any other it is an available option, and it can reduce dramatically the 
number of indirect calls.

Re: Object arrays in D

[simendsjo]

On Tue, 10 Apr 2012 09:41:28 +0200, CrudOMatic   
wrote:


The D documentation is a little lacking in a lot of areas. I'm needing  
to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are left in the  
deck - when zero, Deck is discarded from the Shoe */

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}

the cards[] array is meant to be an array of Card objects, and I'm  
initializing it in the constructor as seen above. This hasn't been  
tested yet, but I'm needing to know if this is the correct way of doing  
it - to save headaches later.


Also, while I'm here, how would you go about moving objects from the  
cards array in the Deck class to another class containing a cards array  
- I'm talking about MOVING them, not COPYING them. I don't want any  
issues with references being destroyed after being moved to another  
class when I happen to destroy an instance of the Deck class.


In D, arrays includes the number of elements in the array.

Card[] cards;
assert(cards.length == 0); // Automatically initialized to 0 elements
cards.length = cardCount; // cards gets cardCount of null elements
cards.reserve(cardCount); // This just extends the array without filling  
with null elements. cards.length stays at 0


D includes array slices - a view into an array. This way, you can  
reference cards without copying them.

auto other = cards[1..$-1]; // all but first and last card

I'll let someone else answer the moving part as I'm not sure how that  
could be done.


The delete statement is going away. You should use clear(cards) instead.  
This really isn't needed as Ds GC will take care of it eventually.


Your example could be written as

class Deck {
  Card[] cards;
  @property int cardCount() {
return cards.length;
  }
  this(int no_cards) {
cards.reserve(no_cards);
  }
}

Arrays are more complicated than they seem at first. I recommend you read  
this article: http://dlang.org/d-array-article.html


D has a newsgroup, .learn, for beginner questions.

Re: Dictonaries benchmark

[Somedude]

Le 10/04/2012 09:07, Dmitry Olshansky a écrit :
> On 10.04.2012 7:14, SomeDude wrote:
>> On Tuesday, 10 April 2012 at 01:34:30 UTC, Andrei Alexandrescu wrote:
>>> I think we can derive quite a few insights from here:
>>>
>>> http://lh3lh3.users.sourceforge.net/udb.shtml
>>>
>>>
>>> Andrei
>>
>> You probably already came accross this benchmark by John-Mark Gurney
>> http://attractivechaos.wordpress.com/2008/08/28/comparison-of-hash-table-libraries/
>>
>>
>> who also happens to be the author of these C libraries:
>> http://attractivechaos.awardspace.com/
>> (from which Heng Li derived his own optimized implementation)
>> and a fan of D.
>>
> 
> 
>> On another matter, Heng Li publishes this regex benchmark:
>> http://lh3lh3.users.sourceforge.net/reb.shtml
>> Surprisingly (or maybe not), egrep is faster than everything else by a
>> very large margin.
> 
>>Another possible reason that egrep is fast may be because it does not
>>keep track of grouping.
> 
> Being in the know I tell you that fogetting about groups lets you to
> make "bare bones" automation which is an order of magnituide faster then.
> 
> BTW it's been years since I see this benchmark. Still no D listed tough
> (is he a fan of D?). For one thing the date pattern is exceptionally
> fast with new std.regex.
> 
Given he has been following the language for years, I tend to think so
http://attractivechaos.wordpress.com/

(and he wrote somewhere that D was the language he was most interested in)

Re: Object arrays in D

[CrudOMatic]

On Tuesday, 10 April 2012 at 08:05:33 UTC, simendsjo wrote:
On Tue, 10 Apr 2012 09:41:28 +0200, CrudOMatic 
 wrote:


The D documentation is a little lacking in a lot of areas. I'm 
needing to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are 
left in the deck - when zero, Deck is discarded from the Shoe 
*/

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}

the cards[] array is meant to be an array of Card objects, and 
I'm initializing it in the constructor as seen above. This 
hasn't been tested yet, but I'm needing to know if this is the 
correct way of doing it - to save headaches later.


Also, while I'm here, how would you go about moving objects 
from the cards array in the Deck class to another class 
containing a cards array - I'm talking about MOVING them, not 
COPYING them. I don't want any issues with references being 
destroyed after being moved to another class when I happen to 
destroy an instance of the Deck class.


In D, arrays includes the number of elements in the array.

Card[] cards;
assert(cards.length == 0); // Automatically initialized to 0 
elements
cards.length = cardCount; // cards gets cardCount of null 
elements
cards.reserve(cardCount); // This just extends the array 
without filling with null elements. cards.length stays at 0


D includes array slices - a view into an array. This way, you 
can reference cards without copying them.

auto other = cards[1..$-1]; // all but first and last card

I'll let someone else answer the moving part as I'm not sure 
how that could be done.


The delete statement is going away. You should use clear(cards) 
instead. This really isn't needed as Ds GC will take care of it 
eventually.


Your example could be written as

class Deck {
  Card[] cards;
  @property int cardCount() {
return cards.length;
  }
  this(int no_cards) {
cards.reserve(no_cards);
  }
}

Arrays are more complicated than they seem at first. I 
recommend you read this article: 
http://dlang.org/d-array-article.html


D has a newsgroup, .learn, for beginner questions.


Thanks, I'm not sure if this is what I was after though. Let me 
explain a little more, and you can tell me if I'm stupid or not.


To make it simple - I have 4 (well more than 4, but trying to get 
these shored up first) classes, Shoe, Deck, Hand and Card.


The Shoe class contains anywhere from 4 to 8 Deck objects in a 
Deck array.


The Deck class contains anywhere from 40 to 54 Card objects in a 
Card array.


The Hand class contains a 2-dimensional array of Card Objects 
([2][]), that are to be moved from the Deck array and placed here.


The Card class just contains info on the card in question.

The cardCount property in Deck gets decremented each time a card 
is dealt from it, until it reaches zero - which then that 
instance of the Deck object is removed from the Deck array in 
Shoe - thus why I needed to move instead of just copying or 
referencing.


The way I'm understanding your solution is that you are treating 
it just as a normal property instead of a generic object 
reference count. If not, then I've mistaken what you were 
meaning. It's merely there to tell me how many objects are left 
until time to clear() it away.

Re: Small Buffer Optimization for string and friends

[Artur Skawina]

On 04/10/12 07:01, Nick Sabalausky wrote:
> "Andrei Alexandrescu"  wrote in message 
> news:jlut8k$j4o$1...@digitalmars.com...
>>
>> I agree. So we have the counterarguments:
>>
>> 1. Lowering would treat array primitives as sheer D code, subject to 
>> refusal of inlining. That means worse performance.
>>
> 
> So in other words, we need the @forceinline that some people have strongly 
> requested? Make it work even without -inline, and then add -noinline for any 
> rare cases where someone might need to forcefully disable @forceinline. 
> Shouldn't that take care of it?

Obviously, yes, but should wait until enough attribute support is in place and
not be just a @inline hack (no point in naming it forceinline - there's no
other kind of inline).

>> 2. Unless the compiler takes special measures, source-level debuggers will 
>> trace through core, uninteresting code for array operations.
>>
> 
> Would @forceinline fix this?

No, but the compiler could just omit the debuginfo for the lowerings, unless
requested with a flag.

>> 3. There are patterns that attempt to optimize by e.g. using .ptr, but end 
>> up pessimizing code because they trigger multiple memory allocations.
> 
> Someone's suggestion of just making .ptr null instead of doing implicit 
> allocations was an interesting idea.

I hope that wasn't a serious suggestion. What might be possible is passing
strings by reference and atomically changing the representation when (if) a
pointer is needed. That would have problems too (ABI change, can't have RO
strings, can't keep the small strings in registers etc).
Doing the small buffer optimization for a new type may be possible, but trying
to add it to the current char[] arrays is probably not a good idea.

artur

Re: Windows 8 Metro support

[bls]

On 04/09/2012 10:12 AM, Dmitry Olshansky wrote:

Simply put WinRT is a major update on COM technology and even here it's
backwards compatible with the old COM.
The fact that OS API is expossed through this new COM interface is just
a nice feature. I was kind of wondering when they will finally ditch
Win32 API.


And some details at :
http://www.codeproject.com/Articles/262151/Visual-Cplusplus-and-WinRT-Metro-Some-fundamentals

Since WinRT programming in C++ is such a pain, I think we can see this 
as a chance for D2.

Re: Small Buffer Optimization for string and friends

[deadalnix]

Le 08/04/2012 16:52, Andrei Alexandrescu a écrit :

On 4/8/12 4:54 AM, Manu wrote:

On 8 April 2012 12:46, Vladimir Panteleev mailto:vladi...@thecybershadow.net>> wrote:

On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote:

Walter and I discussed today about using the small string
optimization in string and other arrays of immutable small objects.

On 64 bit machines, string occupies 16 bytes. We could use the
first byte as discriminator, which means that all strings under
16 chars need no memory allocation at all.


Don't use the first byte. Use the last byte.

The last byte is the highest-order byte of the length. Limiting
arrays to 18.37 exabytes, as opposed to 18.45 exabytes, is a much
nicer limitation than making assumptions about the memory layout.


What is the plan for 32bit?


We can experiment with making strings shorter than 8 chars in-situ. The
drawback will be that length will be limited to 29 bits, i.e. 512MB.

Andrei




As it is a flag, why not limit the string size to 2GB instead of 512MB ?

Re: Can't assign to static array in ctor?

[bearophile]

Andrei Alexandrescu:

I'll note that fixing this bug is more difficult than it might 
seem,
particularly when immutable members and immutable constructors 
come into

play.

Some flow control is needed. At start each member variable of 
the object
starts in a "raw" state. The constructor code progressively 
assigns to

members, putting them in a "cooked" state.

Although the syntax looks like assignment, the constructors 
should be

called for struct members.

A "cooked" member cannot be assigned to again.

No function call that takes this (including members) is allowed 
until

all members have become "cooked".

If the constructor was const or immutable, the object 
effectively

becomes const or immutable exactly at the point all members are
"cooked". At that point in the constructor, the object or its 
members

can be passed to functions.


That reminds me of this approach to implement non-nullables:
http://research.microsoft.com/pubs/67461/non-null.pdf

Bye,
bearophile

Re: Object arrays in D

[simendsjo]

On Tue, 10 Apr 2012 10:53:58 +0200, CrudOMatic   
wrote:



On Tuesday, 10 April 2012 at 08:05:33 UTC, simendsjo wrote:
On Tue, 10 Apr 2012 09:41:28 +0200, CrudOMatic   
wrote:


The D documentation is a little lacking in a lot of areas. I'm needing  
to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are left in the  
deck - when zero, Deck is discarded from the Shoe */

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}

the cards[] array is meant to be an array of Card objects, and I'm  
initializing it in the constructor as seen above. This hasn't been  
tested yet, but I'm needing to know if this is the correct way of  
doing it - to save headaches later.


Also, while I'm here, how would you go about moving objects from the  
cards array in the Deck class to another class containing a cards  
array - I'm talking about MOVING them, not COPYING them. I don't want  
any issues with references being destroyed after being moved to  
another class when I happen to destroy an instance of the Deck class.


In D, arrays includes the number of elements in the array.

Card[] cards;
assert(cards.length == 0); // Automatically initialized to 0 elements
cards.length = cardCount; // cards gets cardCount of null elements
cards.reserve(cardCount); // This just extends the array without  
filling with null elements. cards.length stays at 0


D includes array slices - a view into an array. This way, you can  
reference cards without copying them.

auto other = cards[1..$-1]; // all but first and last card

I'll let someone else answer the moving part as I'm not sure how that  
could be done.


The delete statement is going away. You should use clear(cards)  
instead. This really isn't needed as Ds GC will take care of it  
eventually.


Your example could be written as

class Deck {
  Card[] cards;
  @property int cardCount() {
return cards.length;
  }
  this(int no_cards) {
cards.reserve(no_cards);
  }
}

Arrays are more complicated than they seem at first. I recommend you  
read this article: http://dlang.org/d-array-article.html


D has a newsgroup, .learn, for beginner questions.


Thanks, I'm not sure if this is what I was after though. Let me explain  
a little more, and you can tell me if I'm stupid or not.


To make it simple - I have 4 (well more than 4, but trying to get these  
shored up first) classes, Shoe, Deck, Hand and Card.


The Shoe class contains anywhere from 4 to 8 Deck objects in a Deck  
array.


The Deck class contains anywhere from 40 to 54 Card objects in a Card  
array.


The Hand class contains a 2-dimensional array of Card Objects ([2][]),  
that are to be moved from the Deck array and placed here.


The Card class just contains info on the card in question.

The cardCount property in Deck gets decremented each time a card is  
dealt from it, until it reaches zero - which then that instance of the  
Deck object is removed from the Deck array in Shoe - thus why I needed  
to move instead of just copying or referencing.


The way I'm understanding your solution is that you are treating it just  
as a normal property instead of a generic object reference count. If  
not, then I've mistaken what you were meaning. It's merely there to tell  
me how many objects are left until time to clear() it away.


Not quite sure where you are going with this..

class Deck {
  Card popBack() {
auto card = cards.popBack(); // get last card. cards.length is  
decremented
assumeSafeAppend(cards); // now we can add cards to the deck without  
it relocating - not sure if you need this though

return card;
  }
}

I don't know why you cannot just use a reference. When you stop using a  
Deck, the cards won't be cleaned by the GC as you are referencing Cards  
from other parts of the program - like Hand.

Re: Custom attributes (again)

[deadalnix]

Le 10/04/2012 00:19, Walter Bright a écrit :

On 4/6/2012 4:20 AM, Manu wrote:

On 4/6/2012 2:54 AM, Timon Gehr wrote:
Should add additional information to the type Foo.
Attributes are on the declaration, and not passed around.


Right, they are not added to the *type*.


No, they are not, or it will become a crazy mess.

Re: Object arrays in D

[CrudOMatic]

On Tuesday, 10 April 2012 at 09:15:13 UTC, simendsjo wrote:
On Tue, 10 Apr 2012 10:53:58 +0200, CrudOMatic 
 wrote:



On Tuesday, 10 April 2012 at 08:05:33 UTC, simendsjo wrote:
On Tue, 10 Apr 2012 09:41:28 +0200, CrudOMatic 
 wrote:


The D documentation is a little lacking in a lot of areas. 
I'm needing to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are 
left in the deck - when zero, Deck is discarded from the 
Shoe */

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}

the cards[] array is meant to be an array of Card objects, 
and I'm initializing it in the constructor as seen above. 
This hasn't been tested yet, but I'm needing to know if this 
is the correct way of doing it - to save headaches later.


Also, while I'm here, how would you go about moving objects 
from the cards array in the Deck class to another class 
containing a cards array - I'm talking about MOVING them, 
not COPYING them. I don't want any issues with references 
being destroyed after being moved to another class when I 
happen to destroy an instance of the Deck class.


In D, arrays includes the number of elements in the array.

Card[] cards;
assert(cards.length == 0); // Automatically initialized to 0 
elements
cards.length = cardCount; // cards gets cardCount of null 
elements
cards.reserve(cardCount); // This just extends the array 
without filling with null elements. cards.length stays at 0


D includes array slices - a view into an array. This way, you 
can reference cards without copying them.

auto other = cards[1..$-1]; // all but first and last card

I'll let someone else answer the moving part as I'm not sure 
how that could be done.


The delete statement is going away. You should use 
clear(cards) instead. This really isn't needed as Ds GC will 
take care of it eventually.


Your example could be written as

class Deck {
 Card[] cards;
 @property int cardCount() {
   return cards.length;
 }
 this(int no_cards) {
   cards.reserve(no_cards);
 }
}

Arrays are more complicated than they seem at first. I 
recommend you read this article: 
http://dlang.org/d-array-article.html


D has a newsgroup, .learn, for beginner questions.


Thanks, I'm not sure if this is what I was after though. Let 
me explain a little more, and you can tell me if I'm stupid or 
not.


To make it simple - I have 4 (well more than 4, but trying to 
get these shored up first) classes, Shoe, Deck, Hand and Card.


The Shoe class contains anywhere from 4 to 8 Deck objects in a 
Deck array.


The Deck class contains anywhere from 40 to 54 Card objects in 
a Card array.


The Hand class contains a 2-dimensional array of Card Objects 
([2][]), that are to be moved from the Deck array and placed 
here.


The Card class just contains info on the card in question.

The cardCount property in Deck gets decremented each time a 
card is dealt from it, until it reaches zero - which then that 
instance of the Deck object is removed from the Deck array in 
Shoe - thus why I needed to move instead of just copying or 
referencing.


The way I'm understanding your solution is that you are 
treating it just as a normal property instead of a generic 
object reference count. If not, then I've mistaken what you 
were meaning. It's merely there to tell me how many objects 
are left until time to clear() it away.


Not quite sure where you are going with this..

class Deck {
  Card popBack() {
auto card = cards.popBack(); // get last card. cards.length 
is decremented
assumeSafeAppend(cards); // now we can add cards to the 
deck without it relocating - not sure if you need this though

return card;
  }
}

I don't know why you cannot just use a reference. When you stop 
using a Deck, the cards won't be cleaned by the GC as you are 
referencing Cards from other parts of the program - like Hand.


h... so no need for a generic object reference counter. Nice. 
I was trying to approach it from a literal sense (e.g. card moves 
from deck to player's hand) - when you do the popBack() is that 
object returned and deleted from the original array, or just the 
reference returned and ref removed from original array?


The whole thing is supposed to be a large 21 simulator - 
everything from 21, to blackjack, to Spanish 21 to Ventiuna.


I was trying to use literal real-world ideas of objects, and was 
wanting the moving so I didn't have weird issues later down the 
ro

Re: The Downfall of Imperative Programming

[Kagamin]

On Monday, 9 April 2012 at 20:22:30 UTC, Mirko Pilger wrote:

http://fpcomplete.com/the-downfall-of-imperative-programming/

---
All data is immutable. All functions are pure. You might think 
this is crazy — how can you program with such stifling 
restrictions? It turns out that people have been doing just that 
for a long time. In fact the most popular language for parallel 
and distributed programming is Erlang — a functional language. 
An even better candidate for parallel programming is Haskell, 
which supports a large variety of parallel paradigms.

---
http://flyingfrogblog.blogspot.com/2008/08/haskells-virginity.html
Oookay.

Re: GSoC 2012 Proposal: Continued Work on a D Linear Algebra library (SciD - std.linalg)

[Timon Gehr]

On 04/10/2012 03:24 AM, Cristi Cobzarenco wrote:

Thanks for the suggestions!

I don't think UFCS would help us. Our problem is that we can't do this:
triangular.d:
   struct TriangularMatrix {

   }

   void sum( T )( T x ) if( is( T : TriangularMatrix ) ) {

   }

diagonal.d:
   struct DiagonalMatrix {

   }

   void sum( T )( T x ) if( is( T : DiagonalMatrix ) ) {
   }

main.d:
import diagonal;
import triangular;

void bar() {
TriangularMatrix a;
Diagonal b;
sum( a );  // this does not compile because sum() is ambiguous
sum( b );  // nor does this
}


There are no ambiguities in that example, and if ambiguities occur, they 
can always be fixed manually.




This, AFAIK, is deliberate to avoid name hijacking - ADL in C++ had its
share of criticism. I doubt we will ever get this behaviour in D and
that is perhaps a good thing. I may have misunderstood UFCS though - or
what you meant by making non-member function calls look nicer - please
correct me if that's the case.

Don't worry about long names, t() is already the way transposition is
defined SciD. Moreover, it's a property so you can actually do "a.t * a"
- convenience galore. I'm also considering of creating a submodule like
std.linalg.short which defines aliases with short names for types and
free functions - this will allow particularly numerics-heavy functions
to be written more compactly. I'm not entirely sure it would be a good
idea though as it may sacrifice readability where it's most needed.

---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco



If you change 'Diagonal' to 'DiagonalMatrix', this compiles fine.

Re: Foreach Closures?

[Andrej Mitrovic]

On 4/9/12, Kevin Cox  wrote:
> The
> reason I aski is because if you have a return statement inside a foreach it
> returns from the outside function not the "closure".

I don't like this subtle thing. For example let's say a newbie were to
implement a function called "isDirEmpty". The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:

bool isEmptyDir(string path)
{
foreach (_; dirEntries(path, SpanMode.shallow))
return false;

return true;
}

isEmptyDir never returns false. All that false statement does is break
out of the foreach loop.

Of course the right way to implement this is:

bool isEmptyDir(string path)
{
return dirEntries(path, SpanMode.shallow).empty;
}

But still, the first version is extremely subtle. The semantics of
that code completely change based on whether dirEntries is an array, a
range, or an opApply.

Re: Object arrays in D

[simendsjo]

On Tue, 10 Apr 2012 11:27:19 +0200, CrudOMatic   
wrote:
h... so no need for a generic object reference counter. Nice. I was  
trying to approach it from a literal sense (e.g. card moves from deck to  
player's hand) - when you do the popBack() is that object returned and  
deleted from the original array, or just the reference returned and ref  
removed from original array?


The reference is returned, and it's still in the array - kind of... Say:
cards is [Card1, Card2]
cards.popBack();
cards is now [Card1], but Card2's reference is still there in position 2.  
The length of the array in decremented.
If you try to append a card to cards, the runtime will see you're trying  
to write over the reference for Card2, so it will create a new array to  
avoid this.
If you use assumeSafeAppend, you say that you don't mind overwriting this  
reference.
Remember that as long as you hold a reference to Card2 somewhere, the GC  
won't delete the instance even if the reference no longer exists in the  
cards array.


I was trying to use literal real-world ideas of objects, and was wanting  
the moving so I didn't have weird issues later down the road, like not  
knowing why a reference was hanging around. I understand D has a GC, but  
sometimes it pays to do management yourself.


A card game doesn't sound like heavy use of the GC, so I don't think that  
should be a problem.

Re: Foreach Closures?

[Dmitry Olshansky]

On 10.04.2012 13:33, Andrej Mitrovic wrote:

On 4/9/12, Kevin Cox  wrote:

The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the "closure".


I don't like this subtle thing. For example let's say a newbie were to
implement a function called "isDirEmpty". The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:

bool isEmptyDir(string path)
{
 foreach (_; dirEntries(path, SpanMode.shallow))
 return false;

 return true;
}

isEmptyDir never returns false. All that false statement does is break
out of the foreach loop.


Wake up! dirEntries produce a lazy _range_ and it's not opApply & 
closures. And you were the one to come up with this cool 
parallel(dirEntries(...)) thing back when it was introduced.


Anyway that "return" false would have been translated to some 
"black-magic" jump.




Of course the right way to implement this is:

bool isEmptyDir(string path)
{
 return dirEntries(path, SpanMode.shallow).empty;
}

But still, the first version is extremely subtle. The semantics of
that code completely change based on whether dirEntries is an array, a
range, or an opApply.


array vs range is the same here. opApply is the weirdo.

--
Dmitry Olshansky

Re: Object arrays in D

[CrudOMatic]

On Tuesday, 10 April 2012 at 09:52:45 UTC, simendsjo wrote:
On Tue, 10 Apr 2012 11:27:19 +0200, CrudOMatic 
 wrote:
h... so no need for a generic object reference counter. 
Nice. I was trying to approach it from a literal sense (e.g. 
card moves from deck to player's hand) - when you do the 
popBack() is that object returned and deleted from the 
original array, or just the reference returned and ref removed 
from original array?


The reference is returned, and it's still in the array - kind 
of... Say:

cards is [Card1, Card2]
cards.popBack();
cards is now [Card1], but Card2's reference is still there in 
position 2. The length of the array in decremented.
If you try to append a card to cards, the runtime will see 
you're trying to write over the reference for Card2, so it will 
create a new array to avoid this.
If you use assumeSafeAppend, you say that you don't mind 
overwriting this reference.
Remember that as long as you hold a reference to Card2 
somewhere, the GC won't delete the instance even if the 
reference no longer exists in the cards array.


I was trying to use literal real-world ideas of objects, and 
was wanting the moving so I didn't have weird issues later 
down the road, like not knowing why a reference was hanging 
around. I understand D has a GC, but sometimes it pays to do 
management yourself.


A card game doesn't sound like heavy use of the GC, so I don't 
think that should be a problem.


Awesome. One last question, does popFront() have the same effect 
of decreasing length - or should I avoid popFront()?

Re: Foreach Closures?

[Andrej Mitrovic]

On 4/10/12, Dmitry Olshansky  wrote:
> Wake up! dirEntries produce a lazy _range_ and it's not opApply

Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH

test.d:
import std.file;

bool isEmptyDir(string path)
{
foreach (string name; dirEntries(path, SpanMode.shallow))
return false;

return true;
}

void main()
{
isEmptyDir(".");
}

$ rdmd test.d
> we're in oppapply

Re: Object arrays in D

[simendsjo]

On Tue, 10 Apr 2012 12:01:10 +0200, CrudOMatic   
wrote:


Awesome. One last question, does popFront() have the same effect of  
decreasing length - or should I avoid popFront()?


popFront will also reduce the length, but it will slice away the first  
item. Read the article I linked earlier.
This means that if you append to the array, the array will keep expanding  
and eventually relocate as you cannot reuse the front of the array without  
doing some manual work.

It sounds to me like you want popBack and assumeSafeAppend.

This is basically what popBack and popFront from std.array looks like:

void popBack(A)(ref A a)
{
a = a[0 .. $ - 1]; // $ is a.length
}

void popFront(A)(ref A a)
{
a = a[1 .. $];
}

Re: Object arrays in D

[CrudOMatic]

Thanks much.

Re: Custom attributes (again)

[Timon Gehr]

On 04/10/2012 12:18 AM, Walter Bright wrote:

On 4/6/2012 3:49 AM, Timon Gehr wrote:

On 04/06/2012 12:23 PM, Walter Bright wrote:

On 4/6/2012 2:54 AM, Timon Gehr wrote:

Should add additional information to the type Foo. I don't see any
issues with
it, and not supporting it would be very strange.


How would:

@attr(foo) int x;
int y;

work? Are x and y the same type or not?


Yes, they are.

(But a future extension might leave this choice up to 'foo')


Now, consider:

auto c = b ? x : y;

What type does c have? int or @attr(foo)int ? And that's really just the
beginning. How about:

struct S(T) {
T t;
}

Instantiate it with S!int and S!(@attr(foo)int). Are those the same
instantiation, or different? If the same, does S.t have the attribute or
not?


There is no such thing as an @attr(foo) int, because @attr is not a type
constructor.


But you said it was added to the *type*.


What I said was that it is added to the declaration. If the declaration 
happens to declare a type, then that must affect the type:


@attr(foo) struct Foo{} // annotate 'foo'

@attr(bar) Foo x;

__traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar'

__traits(getAttributes, x); // this will find 'bar', but not 'foo'

Re: The Downfall of Imperative Programming

[James Miller]

* Marco Leise  [2012-04-10 05:57:52 +0200]:

> Am Tue, 10 Apr 2012 12:50:32 +1200
> schrieb James Miller :
> 
> > Slightly OT: With the unstoppable march of parallel programming, does
> > anybody else find node.js incredibly infuriating, since it is
> > single-core.
> 
> Don't blame the library. EcmaScript was designed to be single-core. I imagine 
> that web scripting language to be much more complex with multi-threading in 
> user code. You are using the wrong tool for the job ;)
> 
> -- 
> Marco
> 

I meant that the fact that node.js is gaining popularity, despite the
fact that we want to move away from single-threaded applications, is
incredibly backwards.

I'm not using node, I have to use PHP at work, which at the very least
gets help from the webserver in terms of parallel processing.

--
James Miller

Re: std.benchmark ready for review. Manager sought after

[Jens Mueller]

Andrei Alexandrescu wrote:
> Hello,
> 
> 
> I finally found the time to complete std.benchmark. I got to a very
> simple API design, starting where I like it: one line of code.
> 
> Code is in the form of a pull request at
> https://github.com/D-Programming-Language/phobos/pull/529. (There's
> some noise in there caused by my git n00biness). Documentation is at
> http://erdani.com/d/web/phobos-prerelease/std_benchmark.html.
> 
> If reasonable and at all possible, I'd like to bump the priority of
> this proposal. Clearly D's user base is highly interested in
> efficiency, and many of the upcoming libraries have efficiency a
> virtual part of their design. So we should get std.benchmark in soon
> and require that new addition come with benchmarks for their
> essential functionality.
> 
> My vision is that in the future Phobos will have a significant
> benchmarks battery, which will help improving Phobos and porting to
> new platforms.

I come to think the same.

How come that the times based relative report and the percentage based
relative report are mixed in one result? And how do I choose which one
I'd like to see in the output.

When benchmarking you can measure different things at the same time. In
this regard the current proposal is limited. It just measures wall clock
time. I believe extending the StopWatch to measure e.g. user CPU time is
a useful addition.
In general, allowing user defined measurements would be great.
E.g. to measure the time spend in user mode.
() => {
 tms t;
 times(&t);
 return t.tms_utime;
  }

Note, that this code does not need to be portable. You can also use
version() else static assert.

Things that come to mind that I'd like to measure.
Time measurements:
  * User CPU time
  * System CPU time
  * Time spent in memory allocations
Count measurements:
  * Memory usage
  * L1/L2/L3 cache misses
  * Number of executed instructions
  * Number of memory allocations

Of course wall clock time is the ultimate measure when benchmarking.
But often you need to investigate further (doing more measurements).

Do you think adding this is worthwhile?

All in all the user interface has been greatly simplified.

Jens

Re: Foreach Closures?

[Timon Gehr]

On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky  wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.


test.d:
import std.file;

bool isEmptyDir(string path)
{
 foreach (string name; dirEntries(path, SpanMode.shallow))
 return false;

 return true;
}

void main()
{
 isEmptyDir(".");
}

$ rdmd test.d

we're in oppapply

Re: Foreach Closures?

[Timon Gehr]

On 04/10/2012 11:33 AM, Andrej Mitrovic wrote:

On 4/9/12, Kevin Cox  wrote:

The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the "closure".


I don't like this subtle thing. For example let's say a newbie were to
implement a function called "isDirEmpty". The first hint is to try to
walk the directory iteratively and return as soon as there's a match,
e.g.:

bool isEmptyDir(string path)
{
 foreach (_; dirEntries(path, SpanMode.shallow))
 return false;

 return true;
}

isEmptyDir never returns false.


Yes it does.


All that false statement does is break
out of the foreach loop.



??? No, it returns false from isEmptyDir, unless the opApply 
implementation abuses operator overloading.

Re: Foreach Closures?

[Timon Gehr]

On 04/10/2012 12:50 PM, Timon Gehr wrote:

On 04/10/2012 12:47 PM, Timon Gehr wrote:

On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.



WTF??! It is actually wrong in Phobos. Bug!


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

Re: Foreach Closures?

[Timon Gehr]

On 04/10/2012 12:47 PM, Timon Gehr wrote:

On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.



WTF??! It is actually wrong in Phobos. Bug!

Re: Foreach Closures?

[Dmitry Olshansky]

On 10.04.2012 14:06, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky  wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



Yeah recent change allowed to use straight alias this in DirEntry struct 
thus there is no need for separate opApply now.



test.d:
import std.file;

bool isEmptyDir(string path)
{
 foreach (string name; dirEntries(path, SpanMode.shallow))
 return false;

 return true;
}

void main()
{
 isEmptyDir(".");
}

$ rdmd test.d

we're in oppapply



--
Dmitry Olshansky

Re: Foreach Closures?

[Dmitry Olshansky]

On 10.04.2012 14:50, Timon Gehr wrote:

On 04/10/2012 12:47 PM, Timon Gehr wrote:

On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.



WTF??! It is actually wrong in Phobos. Bug!


Is it still opApply in Phobos?
I mean I did the pull that removed it.

--
Dmitry Olshansky

Re: Foreach Closures?

[Timon Gehr]

On 04/10/2012 12:54 PM, Dmitry Olshansky wrote:

On 10.04.2012 14:50, Timon Gehr wrote:

On 04/10/2012 12:47 PM, Timon Gehr wrote:

On 04/10/2012 12:06 PM, Andrej Mitrovic wrote:

On 4/10/12, Dmitry Olshansky wrote:

Wake up! dirEntries produce a lazy _range_ and it's not opApply


Sorry? Change DirIterator in std.file to this:
http://pastebin.com/DHvXuFeH



You are doing it wrong.
Use:
if(auto r=dg(s)) return r;
instead.



WTF??! It is actually wrong in Phobos. Bug!


Is it still opApply in Phobos?
I mean I did the pull that removed it.



Yes, it is fixed in git head. Sorry for the noise.

Re: The new std.process?

[Steven Schveighoffer]

On Mon, 09 Apr 2012 22:48:26 -0400, Andrei Alexandrescu  
 wrote:



On 4/9/12 9:38 PM, Nick Sabalausky wrote:

"Jonathan M Davis"  wrote in message

https://github.com/kyllingstad/phobos/tree/new-std-process



Oh yea. *Now* I remember asking the same thing before and getting pretty
much the same answer...


I think you must have felt a disturbance in the force.  Literally  
yesterday at around 8:30 am, I finally got around to verifying 2.058  
includes the pipe fix (and it does!), so I think we are clear to get this  
ready for review.  Hopefully by 2.060 (2.059 is out for beta right now).



Shall we add that to the review queue?


It's on the trello board for phobos reviews, in development.  I need to  
get in touch with Lars, it's his baby.


BTW, I can't stress how much I dislike windows D development, especially  
when I have to use git.  Linux just seems so much easier, that I dread  
ever having to test D windows stuff.  I suppose if it was my main  
platform, I wouldn't have to scrap around setting shit up every time I  
want to test something.


-Steve

Re: GSoC 2012 Proposal: Continued Work on a D Linear Algebra library (SciD - std.linalg)

[Cristi Cobzarenco]

Timon is, of course, right. I got a bit confused when trying to simplify in
a hurry. What I meant was actually something like this:

ops.d:
import std.stdio;

int sum( T )( T mat ){
 writeln("ops.sum");
// return reduce!"a+b"( 0, mat );
 return 1;
}

int numelems( T )( T mat ) {
// return mat.rows * mat.columns;
 return 1;
}

int mean( T )( T mat ) {
return sum( mat ) / numelems( mat );
}

diagonal.d:
import ops;
import std.stdio;

struct DiagonalMatrix {
 }

int sum( T : DiagonalMatrix )( T mat ) {
writeln( "diagonal.sum" );
// return reduce!"a+b"( 0, mat.diagonal() );
 return 1;
}

main.d:
import ops;
import diagonal;

void main() {
 DiagonalMatrix mat;
sum( mat );   // this will not compile, but if removed mean
 mean( mat ); // will use ops.sum, not diagonal.sum anyway
}

The first problem could, in theory, be fixed using a member flag, something
like enum specializedSum = true; and ops.sum could be redefined as: int
sum( T )( T mat ) if( !T.specializedSum ) {}. But in this case mean() would
still try to use  ops.sum which will fail. All of this can be easily fixed
by providing member functions, and having the free functions call the
member ones when they exist.

---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco



On 10 April 2012 10:35, Timon Gehr  wrote:

> On 04/10/2012 03:24 AM, Cristi Cobzarenco wrote:
>
>> Thanks for the suggestions!
>>
>> I don't think UFCS would help us. Our problem is that we can't do this:
>> triangular.d:
>>   struct TriangularMatrix {
>>
>>   }
>>
>>   void sum( T )( T x ) if( is( T : TriangularMatrix ) ) {
>>
>>   }
>>
>> diagonal.d:
>>   struct DiagonalMatrix {
>>
>>   }
>>
>>   void sum( T )( T x ) if( is( T : DiagonalMatrix ) ) {
>>   }
>>
>> main.d:
>> import diagonal;
>> import triangular;
>>
>> void bar() {
>>TriangularMatrix a;
>>Diagonal b;
>>sum( a );  // this does not compile because sum() is ambiguous
>>sum( b );  // nor does this
>> }
>>
>
> There are no ambiguities in that example, and if ambiguities occur, they
> can always be fixed manually.
>
>
>> This, AFAIK, is deliberate to avoid name hijacking - ADL in C++ had its
>> share of criticism. I doubt we will ever get this behaviour in D and
>> that is perhaps a good thing. I may have misunderstood UFCS though - or
>> what you meant by making non-member function calls look nicer - please
>> correct me if that's the case.
>>
>> Don't worry about long names, t() is already the way transposition is
>> defined SciD. Moreover, it's a property so you can actually do "a.t * a"
>> - convenience galore. I'm also considering of creating a submodule like
>> std.linalg.short which defines aliases with short names for types and
>> free functions - this will allow particularly numerics-heavy functions
>> to be written more compactly. I'm not entirely sure it would be a good
>> idea though as it may sacrifice readability where it's most needed.
>>
>> ---
>> Cristi Cobzarenco
>> BSc in Artificial Intelligence and Computer Science
>> University of Edinburgh
>> Profile: 
>> http://www.google.com/**profiles/cristi.cobzarenco
>>
>>
> If you change 'Diagonal' to 'DiagonalMatrix', this compiles fine.
>
>

Re: Foreach Closures?

[Andrej Mitrovic]

On 4/10/12, Timon Gehr  wrote:
> Yes, it is fixed in git head. Sorry for the noise.

Sorry for my noise too, I didn't know it was fixed in git head. :)

Re: Custom attributes (again)

[Steven Schveighoffer]

On Tue, 10 Apr 2012 06:32:00 -0400, Timon Gehr  wrote:


On 04/10/2012 12:18 AM, Walter Bright wrote:



But you said it was added to the *type*.


What I said was that it is added to the declaration. If the declaration  
happens to declare a type, then that must affect the type:


@attr(foo) struct Foo{} // annotate 'foo'

@attr(bar) Foo x;

__traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar'

__traits(getAttributes, x); // this will find 'bar', but not 'foo'


I should clarify that it's *associated* with the type.  It should not  
affect the type in how it functions, at all.  For all usages of Foo except  
to get attributes associated with its declaration, it should be treated as  
if it doesn't have an attribute on it.


So it doesn't affect how the type operates or how it's matched, etc.  
except in the capacity that you query its attributes.


-Steve

Re: Object arrays in D

[Steven Schveighoffer]

On Tue, 10 Apr 2012 03:41:28 -0400, CrudOMatic   
wrote:


The D documentation is a little lacking in a lot of areas. I'm needing  
to know an exact way of making arrays of objects.


For example:

/* Deck class */
// Will be adjusted with the proper cards for each game type
class Deck {
		/* Card count - used to keep track of how many cards are left in the  
deck - when zero, Deck is discarded from the Shoe */

int cardCount;
/* Cards array - initialized to cardCount elements */
Card cards[];

/* Constructor */
this(int no_cards) {
cardCount = no_cards;
cards = new Card[cardCount];
}

/* Destructor */
~this() {
delete cards;
}
}


I want to stop you right there.  *DON'T* use a destructor here, you will  
have issues, mostly of the random segfault nature.


Quickly explained, if the Deck class and it's cards array are destroyed at  
the same time in the GC, there is no guarantee that the cards array is  
valid when you try to destroy it.


Destructors are strictly for cleaning up resources that *AREN'T* allocated  
by the GC.  For example anything created with C's malloc, or an open file  
descriptor, etc.


the cards[] array is meant to be an array of Card objects, and I'm  
initializing it in the constructor as seen above. This hasn't been  
tested yet, but I'm needing to know if this is the correct way of doing  
it - to save headaches later.


This is fine.  Note that D slices (what cards[] is) contain a length  
member, so no need to store an extra member.


Also, while I'm here, how would you go about moving objects from the  
cards array in the Deck class to another class containing a cards array  
- I'm talking about MOVING them, not COPYING them. I don't want any  
issues with references being destroyed after being moved to another  
class when I happen to destroy an instance of the Deck class.


All classes are references (i.e. an element of cards is a single pointer  
to a Card instance). There is no need to move them, as a straight copy is  
just copying the reference.  And since you have removed the dtor, there  
should be no worry about accidentally destroying the cards ;)


You really should read the spec page on classes  
(http://dlang.org/class.html) and I highly recommend picking up the D  
programming language book.


-Steve

Re: Custom attributes (again)

[Steven Schveighoffer]

On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg  wrote:


On 2012-04-09 23:49, deadalnix wrote:


If it is available at compile time, it is implementable at runtime as a
lib. So you pay for it only if you use it, and you don't add feature in
the language just because it is convenient.


I'm not saying how it should be implemented, just that it should be  
accessible at runtime.


I think there was some confusion, read a quote of what you said:

"I don't see why the attributes *should* be accessible at runtime"

Emphasis added.  I think you meant "shouldn't"

-Steve

Re: The new std.process?

[Jacob Carlborg]

On 2012-04-10 13:18, Steven Schveighoffer wrote:


BTW, I can't stress how much I dislike windows D development, especially
when I have to use git. Linux just seems so much easier, that I dread
ever having to test D windows stuff. I suppose if it was my main
platform, I wouldn't have to scrap around setting shit up every time I
want to test something.

-Steve


I agree. I recommend you use the git shell, which is basically cygwin.

--
/Jacob Carlborg

Re: The new std.process?

[Steven Schveighoffer]

On Tue, 10 Apr 2012 07:41:23 -0400, Jacob Carlborg  wrote:


On 2012-04-10 13:18, Steven Schveighoffer wrote:


BTW, I can't stress how much I dislike windows D development, especially
when I have to use git. Linux just seems so much easier, that I dread
ever having to test D windows stuff. I suppose if it was my main
platform, I wouldn't have to scrap around setting shit up every time I
want to test something.

-Steve


I agree. I recommend you use the git shell, which is basically cygwin.


I do.  I still hate it :)  I suppose this time it was because I had to  
merge specifically 2.058 changes, so I had to use a tag (never did that  
before, and because of my typo, it wasn't working).


-Steve

Re: Custom attributes (again)

[Jacob Carlborg]

On 2012-04-10 13:41, Steven Schveighoffer wrote:

On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg  wrote:


On 2012-04-09 23:49, deadalnix wrote:


If it is available at compile time, it is implementable at runtime as a
lib. So you pay for it only if you use it, and you don't add feature in
the language just because it is convenient.


I'm not saying how it should be implemented, just that it should be
accessible at runtime.


I think there was some confusion, read a quote of what you said:

"I don't see why the attributes *should* be accessible at runtime"

Emphasis added. I think you meant "shouldn't"

-Steve


Yeah, I did, hehe :)

This thread is getting too long now.

--
/Jacob Carlborg

Re: The new std.process?

[Jacob Carlborg]

On 2012-04-10 13:47, Steven Schveighoffer wrote:

On Tue, 10 Apr 2012 07:41:23 -0400, Jacob Carlborg  wrote:


On 2012-04-10 13:18, Steven Schveighoffer wrote:


BTW, I can't stress how much I dislike windows D development, especially
when I have to use git. Linux just seems so much easier, that I dread
ever having to test D windows stuff. I suppose if it was my main
platform, I wouldn't have to scrap around setting shit up every time I
want to test something.

-Steve


I agree. I recommend you use the git shell, which is basically cygwin.


I do. I still hate it :)


Can't argue with you there :)

This kind of software development works so much better on a Posix system.

--
/Jacob Carlborg

Re: Object arrays in D

[CrudOMatic]

Sorry, but a small issue.

the line: auto card = cards.popBack();

throws the errors:

error: variable xxx.card voids have no value
error: expression popBack(this.cards) is void and has no value

I tried reserving the space, I even tried cards = new 
Card[no_cards];

Re: Object arrays in D

[simendsjo]

On Tue, 10 Apr 2012 13:58:44 +0200, CrudOMatic   
wrote:



Sorry, but a small issue.

the line: auto card = cards.popBack();

throws the errors:

error: variable xxx.card voids have no value
error: expression popBack(this.cards) is void and has no value

I tried reserving the space, I even tried cards = new Card[no_cards];


Sorry, popBack returns void. You have to get the back of the array before  
calling popBack(). Here's an example:


import std.array;
class Card {}
void main() {
Card[] cards;
cards.reserve(1024);
assert(cards.capacity >= 1024);
assert(cards.length == 0); // still 0

cards ~= new Card(); // add a Card
assert(cards.length == 1);

auto card = cards.back; // get last element
cards.popBack(); // remove last element
assert(card); // non-null
assert(cards.length == 0); // "empty" again
assumeSafeAppend(cards); // allow us to append to it without  
reallocating


auto oldptr = cards.ptr;
cards ~= new Card();
assert(cards.length == 1);
assert(card); // card still alive and kicking
assert(cards.ptr == oldptr); // and no reallocation
}

Re: The Downfall of Imperative Programming

[Sönke.Ludwig]

On Tuesday, 10 April 2012 at 10:38:28 UTC, James Miller wrote:

* Marco Leise  [2012-04-10 05:57:52 +0200]:


Am Tue, 10 Apr 2012 12:50:32 +1200
schrieb James Miller :

> Slightly OT: With the unstoppable march of parallel 
> programming, does

> anybody else find node.js incredibly infuriating, since it is
> single-core.

Don't blame the library. EcmaScript was designed to be 
single-core. I imagine that web scripting language to be much 
more complex with multi-threading in user code. You are using 
the wrong tool for the job ;)


--
Marco



I meant that the fact that node.js is gaining popularity, 
despite the
fact that we want to move away from single-threaded 
applications, is

incredibly backwards.

I'm not using node, I have to use PHP at work, which at the 
very least

gets help from the webserver in terms of parallel processing.

--
James Miller


I haven't used it, but node.js has clusters
(http://nodejs.org/docs/v0.6.0/api/cluster.html) which often
should be just as good.

But performing I/O using single-threaded asynchronous I/O instead
of threaded blocking I/O is a huge win in terms of performance -
it would just be nice to have threading on top to do the number
crunching work.

Re: Windows 8 Metro support

[Sönke.Ludwig]

On Tuesday, 10 April 2012 at 07:58:57 UTC, John Chapman wrote:

On Tuesday, 10 April 2012 at 07:24:09 UTC, Sönke Ludwig wrote:
But one thing in particular, that you are not allowed to do is 
to use kernel32.dll (at least I was told). So you still have 
to rewrite all the C-library functions (such as fopen(), 
malloc() and so on) and anything that the D runtime or Phobos 
uses from kernel32 or similar libraries; I gues the same 
applies to ws2_32 and so on.


Not strictly true. Here's the subset of the Win32 API that can 
be used in Metro apps: 
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx


Great! I was looking for such a list, thanks.

So since you have at least HeapAlloc and some other functions, it 
looks like a doable task to just adjust the existing runtime. 
Just many functions like CreateFile would need to be changed to 
their allowed counterparts as it looks.


But the question is still if that snn.lib or what else is beeing 
linked in can be adjusted or still needs to be replaced.

Re: Windows 8 Metro support

[mist]

Oh, crap.
I wish your message could have appeared a week or two earlier. 
Almost smashed my head against the wall trying to figure the hell 
out of x64 seg fault.

Re: The new std.process?

[Alex Rønne Petersen]

On 10-04-2012 13:47, Steven Schveighoffer wrote:

On Tue, 10 Apr 2012 07:41:23 -0400, Jacob Carlborg  wrote:


On 2012-04-10 13:18, Steven Schveighoffer wrote:


BTW, I can't stress how much I dislike windows D development, especially
when I have to use git. Linux just seems so much easier, that I dread
ever having to test D windows stuff. I suppose if it was my main
platform, I wouldn't have to scrap around setting shit up every time I
want to test something.

-Steve


I agree. I recommend you use the git shell, which is basically cygwin.


I do. I still hate it :) I suppose this time it was because I had to
merge specifically 2.058 changes, so I had to use a tag (never did that
before, and because of my typo, it wasn't working).

-Steve


Do you use mintty? It _really_ helps. It's much better than those dumb 
bash-in-cmd.exe approaches.


--
- Alex

Re: Object arrays in D

[CrudOMatic]

Thanks, works fine now.

Re: std.benchmark ready for review. Manager sought after

[Martin Nowak]

I've analyzed this quite a bit at work and the average and median are  
not very informative. You need the mode, but in most benchmarks the mode  
is very close to the minimum, so using the minimum is even better.



How is it better?

In speed measurements, all noise is additive (there's no noise that may  
make a benchmark appear to run faster). There are also quite a few  
outliers. Recording the average will include a fair amount of noise.



The benchmarked function itself could have a relevant variance, e.g.
when using randomized algorithms. You already get that from the LRU table
in the array append cache.

Re: Precise GC

[Andrei Alexandrescu]

On 4/10/12 3:03 AM, deadalnix wrote:

For every type, a function template (let's call it GCscan) will be
instantiated to scan it. This function can be ANY code. ANY code include
the possibility for GCscan!A to call GCscan!B directly, without going
back to GC main loop and indirect call. If inlined, you can forget about
function call at all (and you can force that using mixin template for
example, but it is likely to massively generate code bloat).


That is correct. The code bloat is equal to that generated if the end 
user sat down and wrote by hand appropriate routines for collection for 
all types.



This can't be done for reference/pointer to polymorphic types, but for
any other it is an available option, and it can reduce dramatically the
number of indirect calls.


Indeed. For non-final class member variables, the template will fetch 
their Typeinfo, from that the pointer to the mark function, and will 
issue the call through pointer.



Andrei

Re: Can't assign to static array in ctor?

[Andrei Alexandrescu]

On 4/10/12 4:04 AM, bearophile wrote:

Andrei Alexandrescu:


I'll note that fixing this bug is more difficult than it might seem,
particularly when immutable members and immutable constructors come into
play.

Some flow control is needed. At start each member variable of the object
starts in a "raw" state. The constructor code progressively assigns to
members, putting them in a "cooked" state.

Although the syntax looks like assignment, the constructors should be
called for struct members.

A "cooked" member cannot be assigned to again.

No function call that takes this (including members) is allowed until
all members have become "cooked".

If the constructor was const or immutable, the object effectively
becomes const or immutable exactly at the point all members are
"cooked". At that point in the constructor, the object or its members
can be passed to functions.


That reminds me of this approach to implement non-nullables:
http://research.microsoft.com/pubs/67461/non-null.pdf


Yes, that's our source of inspiration for cooked/raw.

Andrei

Re: Shared library in D on Linux

[Ellery Newcomer]

On 04/10/2012 01:31 AM, Jacob Carlborg wrote:


The module info (contains the module constructors) need to be setup
differently when linking as a shared library.



The odd thing is, when you skip _init and _fini and just do

rt_init();
writeln("stuff");
rt_term();

it doesn't segfault

Re: Windows 8 Metro support

[simendsjo]

On Tue, 10 Apr 2012 15:02:15 +0200, mist  wrote:


Oh, crap.
I wish your message could have appeared a week or two earlier. Almost  
smashed my head against the wall trying to figure the hell out of x64  
seg fault.


I hit it a couple of weeks ago and posted in .learn :)
My head was quite bloody by the time someone referenced that bug too

Re: Object arrays in D

[Jesse Phillips]

class Deck {
  Card popBack() {
auto card = cards.popBack(); // get last card. cards.length


Note that popBack() is void:
http://dlang.org/phobos/std_array.html#popBack

use

auto card = cards.back();
cards.popBack();

Re: Windows 8 Metro support

[mist]

Ugh, my spare time is rather hindered by trying to follow all 
messages in D.announce and D groups ( and googling for all 
unknown stuff cool guys are talking about ) - I am afraid that 
adding D.learn to this everyday list would have made me a goner.. 
and you have just named a reason why it should be done! :)

Cod generation for different targets ( x386, x486 etc )

[Timofei Bolshakoc]

I am using D ver. 2 for more then a year - since version 2.051. 
My target architecture is Linux on Vortex DX SoC - 
http://www.vortex86sx.com/?page_id=197
It is compatible with x586 architecture. Till version 2.057 
everything was OK, but when I recompiled my working code with 
2.057 VERY strange behaviour was observed - I can't even describe 
it correctly. I think that something was broken in floating point 
support. I returned to version 2.056.


So, the question is - can I generate code for different x86 
targets - x486, x586, x686 etc using dmd. I like dmd and do not 
want to switch to gdc if it will be possible to stay on dmd. I 
did not tried 2.058 yet - please tell me if I should.

Re: Cod generation for different targets ( x386, x486 etc )

[Timofei Bolshakoc]

Sorry -
Code generation 

Re: The Downfall of Imperative Programming

[Paulo Pinto]

No really.

Scala, Clojure and Ocaml also do have quite industry support already.
Actually on my job, any client would pick one of those over D, as they
are slowly being accepted in enterprise projects.

A curious fact is that the FP fans have much to thank to Microsoft, as
it is the company with more FP research on their paychecks. Many open
source fans are not aware that a few of the main developers in the Ocaml 
and Haskell communities, work for Microsoft Research labs.


--
Paulo

Am 10.04.2012 02:25, schrieb Froglegs:

I like functional languages, but the only one that seems to have much
support is F#.


I've used TBB Flow Graph in C++ and found it to be a major improvement
over straight parallel algorithms/tasks/message passing etc which seem
to be the norm(like in D). Expressing dependencies between separate
nodes was super easy.



Do any other languages have support for flow based concurrency like
C++/TBB?

More mentors needed

[Andrei Alexandrescu]

Hello,


We have been blessed with quite a few strong proposals, actually more 
than mentors (unlike last year).


If anyone here is willing to mentor a D project, please let let us know. 
We're looking for competent and established community members who are 
willing to guide a student through the hoops of a real project.


Mentoring a GSoC project on D is a great way to make a lasting positive 
impact on the language. It is hard but rewarding work. Please consider 
applying, and ask here any questions you might have.



Thanks,

Andrei

Re: The Downfall of Imperative Programming

[Gour]

On Tue, 10 Apr 2012 18:06:37 +0200
Paulo Pinto  wrote:

> Scala, Clojure and Ocaml also do have quite industry support already.

How does the GUI world of Ocaml look like?


Sincerely,
Gour

-- 
According to the three modes of material nature and the work 
associated with them, the four divisions of human society are 
created by Me. And although I am the creator of this system, 
you should know that I am yet the nondoer, being unchangeable.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: The Downfall of Imperative Programming

[bls]

On Tuesday, 10 April 2012 at 16:30:34 UTC, Gour wrote:

On Tue, 10 Apr 2012 18:06:37 +0200
Paulo Pinto  wrote:

Scala, Clojure and Ocaml also do have quite industry support 
already.


How does the GUI world of Ocaml look like?


Sincerely,
Gour


GTK

Re: Custom attributes (again)

[Marco Leise]

Am Tue, 10 Apr 2012 13:53:09 +0200
schrieb Jacob Carlborg :

> On 2012-04-10 13:41, Steven Schveighoffer wrote:
> > On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg  wrote:
> >
> >> On 2012-04-09 23:49, deadalnix wrote:
> >>
> >>> If it is available at compile time, it is implementable at runtime as a
> >>> lib. So you pay for it only if you use it, and you don't add feature in
> >>> the language just because it is convenient.
> >>
> >> I'm not saying how it should be implemented, just that it should be
> >> accessible at runtime.
> >
> > I think there was some confusion, read a quote of what you said:
> >
> > "I don't see why the attributes *should* be accessible at runtime"
> >
> > Emphasis added. I think you meant "shouldn't"
> >
> > -Steve
> 
> Yeah, I did, hehe :)
> 
> This thread is getting too long now.

So in the end we more or less agree that Walter and others can implement useful 
attributes for compile-time, whereas runtime support is nice-to-have (or can be 
provided by a lib)? My intention is to make it easier for the one who 
implements them if runtime support proves difficult.

-- 
Marco

Starting with D(2)

[Lars Johansson]

Hey all, I do not find a better suited forum or blog to ask some 
newbie questions.
I read some about D. Some years ago I actually wrote some small 
D1/tango programs just for fun. Now I like to start do some more 
serious stuff with D2. But there are some things bugging me.
It seems there is a blood feuds among D and tango communities. 
This looks bad, and something I do not like.


But more important I can not find good documentation how to 
install D2 with tango and phobos2. There are probably other 
useful libraries, where do I find them and how do I install them. 
I'm primarily looking for a Windows install. I managed to install 
D (dmd and probably phobos2) some examples do not even compile, 
so I probably didn't do a successful install.


I appreciate if someone can give some advice.

Re: Shared library in D on Linux

[Jacob Carlborg]

On 2012-04-10 16:21, Ellery Newcomer wrote:

On 04/10/2012 01:31 AM, Jacob Carlborg wrote:


The module info (contains the module constructors) need to be setup
differently when linking as a shared library.



The odd thing is, when you skip _init and _fini and just do

rt_init();
writeln("stuff");
rt_term();

it doesn't segfault


Are the module constructors run?

--
/Jacob Carlborg

Re: Shared library in D on Linux

[Ellery Newcomer]

On 04/10/2012 12:04 PM, Jacob Carlborg wrote:



The odd thing is, when you skip _init and _fini and just do

rt_init();
writeln("stuff");
rt_term();

it doesn't segfault


Are the module constructors run?



they would have to be for writeln to not segfault

MD5, SHA1, SHA256, CRC32

[Russel Winder]

I'm in need of calculating these numbers as part of a program.  Java,
Python, Go, all provide these algorithms "out of the box".  From what I
can see D does not.  There is a crc32 module and a std/md5 module but...

Have I just missed something?

Thanks.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: The Downfall of Imperative Programming

[Russel Winder]

Two quite interesting points to make here:

1.  OCaml has a GIL and so, like CPython (*), is forced to use operating
system processes to obtain parallelism. Also OCaml has imperative
features, it is not a pure functional language.  Clojure followed this
route as well, using STM to deal with locking issues.

2. Haskell is a lazy language which means:
a. it can work with infinite data structures; and
b. it is incredibly difficult to create parallel codes.

Simon Peyton Jones and Simon Marlow have had to do a great deal of very
clever work to make Data Parallel Haskell, but it is to Haskell what
NumPy is to Python. 

I am a fan of declarative expression, I prefer functional approaches
over explicitly imperative ones.  For the moment though using single
assignment in imperative languages with all the lambda/closure
technology and using functional programming thinking is the best
compromise.  OCaml (and its clone F#) and Haskell are likely to remain
tiny bit part players for a long while.

On the JVM the interesting question is whether Clojure finally makes
Lisp a mainstream language outside of one or two domains.


(*) PyPy is experimenting with STM to replace use of a GIL.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Cod generation for different targets ( x386, x486 etc )

[Iain Buclaw]

On 10 April 2012 17:08, Timofei Bolshakoc  wrote:
> Sorry -
> Code generation 

Join the dark side! :)


On the offhand note, do you have an example of this weirdness?  Have
you tried compiling with -nofloat ?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Shared library in D on Linux

[Jacob Carlborg]

On 2012-04-10 19:12, Ellery Newcomer wrote:


they would have to be for writeln to not segfault


Ok, I see.

--
/Jacob Carlborg

Re: Custom attributes (again)

[Jacob Carlborg]

On 2012-04-10 19:02, Marco Leise wrote:


So in the end we more or less agree that Walter and others can implement useful 
attributes for compile-time, whereas runtime support is nice-to-have (or can be 
provided by a lib)? My intention is to make it easier for the one who 
implements them if runtime support proves difficult.


Something like that.

--
/Jacob Carlborg

Re: Starting with D(2)

[Jacob Carlborg]

On 2012-04-10 19:00, Lars Johansson wrote:

Hey all, I do not find a better suited forum or blog to ask some newbie
questions.
I read some about D. Some years ago I actually wrote some small D1/tango
programs just for fun. Now I like to start do some more serious stuff
with D2. But there are some things bugging me.
It seems there is a blood feuds among D and tango communities. This
looks bad, and something I do not like.

But more important I can not find good documentation how to install D2
with tango and phobos2. There are probably other useful libraries, where
do I find them and how do I install them. I'm primarily looking for a
Windows install. I managed to install D (dmd and probably phobos2) some
examples do not even compile, so I probably didn't do a successful install.

I appreciate if someone can give some advice.


I great way to install D (including Phobos) is to use DVM:

https://bitbucket.org/doob/dvm

For D2, Tango is just like any other library, no special treatment is 
needed.


https://github.com/SiegeLord/Tango-D2

--
/Jacob Carlborg

Re: Shared library in D on Linux

[Timo Westkämper]

On Tuesday, 10 April 2012 at 14:21:28 UTC, Ellery Newcomer wrote:

On 04/10/2012 01:31 AM, Jacob Carlborg wrote:


The module info (contains the module constructors) need to be 
setup

differently when linking as a shared library.



The odd thing is, when you skip _init and _fini and just do

rt_init();
writeln("stuff");
rt_term();

it doesn't segfault


Yes, I experienced the same.

Re: Starting with D(2)

[H. S. Teoh]

On Tue, Apr 10, 2012 at 07:00:39PM +0200, Lars Johansson wrote:
> Hey all, I do not find a better suited forum or blog to ask some
> newbie questions.

Try d-learn (digitalmars-d-le...@puremagic.com).


> I read some about D. Some years ago I actually wrote some small
> D1/tango programs just for fun. Now I like to start do some more
> serious stuff with D2. But there are some things bugging me.
> It seems there is a blood feuds among D and tango communities. This
> looks bad, and something I do not like.

This is ancient history. It only applies to D1.


> But more important I can not find good documentation how to install
> D2 with tango and phobos2. There are probably other useful
> libraries, where do I find them and how do I install them. I'm
> primarily looking for a Windows install. I managed to install D (dmd
> and probably phobos2) some examples do not even compile, so I
> probably didn't do a successful install.
> 
> I appreciate if someone can give some advice.

Have you tried the instructions on this page:

http://dlang.org/dmd-windows.html

?

If you still have trouble after that, somebody here or on d-learn will
be more than happy to assist you.


T

-- 
INTEL = Only half of "intelligence".

Re: MD5, SHA1, SHA256, CRC32

[Walter Bright]

On 4/10/2012 2:25 AM, Russel Winder wrote:

I'm in need of calculating these numbers as part of a program.  Java,
Python, Go, all provide these algorithms "out of the box".  From what I
can see D does not.  There is a crc32 module and a std/md5 module but...

Have I just missed something?


The crc32 and md5 are two of them. Nobody has done the others. I know the md5 
one is a straightforward translation from the C version. The others could be 
done the same way.


Also, there's:

https://github.com/D-Programming-Deimos/openssl

Re: Small Buffer Optimization for string and friends

[Marco Leise]

Am Tue, 10 Apr 2012 10:50:24 +0200
schrieb Artur Skawina :

> Obviously, yes, but should wait until enough attribute support is in place and
> not be just a @inline hack.

If you refer to the proposed user attributes, they wont change the operation of 
the compiler. Only your own program code will know how to use them. @inline, 
@safe, @property, final, nothrow, ... on the other hand are keywords that 
directly map to flags and hard wired logic in the compiler. Correct me if I'm 
wrong.

-- 
Marco

Re: MD5, SHA1, SHA256, CRC32

[Adam D. Ruppe]

There's a few of us who have written our own
implementations of these, but as far as I know
none of them are considered good enough for
stdlib.


But if you just want something you can use now,
here's mine for sha:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/sha.d

assert(hashToString(SHA1("abc")) == 
"a9993e364706816aba3e25717850c26c9cd0d89d");
assert(hashToString(SHA256("abc")) == 
"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad");

Export ?

[deadalnix]

On this newsgroup with Jonathan M Davis, we started discussing export. 
As it was off topic, and as it was interesting, I wish to bring it here.


As most of you know, all symbol on posix systems are export, but not on 
windows. As D have an export keyword, the question is what to do with it.


The need for change in the UNIX world of this behavior exists, and some 
move has been made in direction of explicitly hiding symbols ( see 
http://gcc.gnu.org/wiki/Visibility ).


For consistency across systems, I suggest that, unless marked as 
exported, symbols are hidden by default. This have other advantages as 
shown in the linked page about gcc. For D, it also mean that the linker 
will have all information to finalize all methods that are not marked as 
export, and I think this is something we want to mitigate the cost of 
all methods virtual by default.


The site says : « Ex­port means that any code out­side the ex­e­cutable 
can ac­cess the mem­ber. Ex­port is anal­o­gous to ex­port­ing 
de­f­i­n­i­tions from a DLL. » so, clearly it is not saying anything 
about posix systems (you'll not find many DLL on those) and not what D 
compiler does.


It means that export comes as an extra qualifier, and not as an 
alternative to public/private/protected/package . You can be both export 
AND public/private/protected/package .


This already have been discussed here, but no conclusion has been made.

Re: std.benchmark ready for review. Manager sought after

[Denis Shelomovskij]

09.04.2012 17:26, Andrei Alexandrescu пишет:

On 4/9/12 2:06 AM, Denis Shelomovskij wrote:

Why will recording the average produce so much noise?


As I explained, the average takes noise and outliers (some very large,
e.g. milliseconds in a benchmark that takes microseconds) into account.
The minimum is shielded from this issue. In the limit, the minimum for
infinitely many measurements is the sought-after result.


As I see, floating
point arithmetic is now used without a strong reason so it looks like a
time of this part isn't valuable. Or is it just a temporary solution?


I don't understand "time of this part".


Looks like a misunderstanding because of my bad English: "Recording the 
average will include a fair amount of noise" means for me that a process 
of "recording the average" produces "a fair amount of noise" itself, not 
that "a result includes noise".



--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Export ?

[Jonathan M Davis]

On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
> On this newsgroup with Jonathan M Davis, we started discussing export.
> As it was off topic, and as it was interesting, I wish to bring it here.
> 
> As most of you know, all symbol on posix systems are export, but not on
> windows. As D have an export keyword, the question is what to do with it.
> 
> The need for change in the UNIX world of this behavior exists, and some
> move has been made in direction of explicitly hiding symbols ( see
> http://gcc.gnu.org/wiki/Visibility ).

As I said in the other thread, I _hate_ export. It's one of Windows largest 
misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The 
fact that Linux exports everything is _fantastic_. It's so much easier to deal 
with. I'd _hate_ to see Linux or anything we do move in the direction of what 
Windows has done.

- Jonathan M Davis

Re: MD5, SHA1, SHA256, CRC32

[Piotr Szturmaj]

Adam D. Ruppe wrote:

There's a few of us who have written our own
implementations of these, but as far as I know
none of them are considered good enough for
stdlib.


But if you just want something you can use now,
here's mine for sha:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/sha.d


And here's mine: 
https://github.com/pszturmaj/phobos/blob/master/std/crypto/hash/sha.d 
(yeah, I need to move it to a new branch)

Re: The Downfall of Imperative Programming

[Gour]

On Tue, 10 Apr 2012 19:01:07 +0200
"bls"  wrote:

> GTK

Then, D is better even in that regard. ;)


Sincerely,
Gour


-- 
Whenever and wherever there is a decline in religious practice, 
O descendant of Bharata, and a predominant rise of irreligion — 
at that time I descend Myself.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: Foreach Closures?

[Marco Leise]

Am Tue, 10 Apr 2012 08:46:05 +0200
schrieb Jacob Carlborg :

> Descent can handle:
> 
> * Syntax highlighting
> * Semantic highlighting
> * Show lex, parse and semantic errors
> * Compile time debugging
> * Compile time view
> * Formatting
> * Show the actual type of an inferred or aliased type
> * Smart autocompletion
> * Many other things as well
> 
> Note that in addition to (most of) the above, JDT can handle a lot more. 
> The compiler is the only tool that can properly handle this. It's also 
> the only sane approach, to have the compiler usable as a library.
> 
> Just take a look how it used to be (and in some cases are) in the C/C++ 
> world before Clang and LLVM came a long:
> 
> * You have the compiler
> * An IDE with a "parser/compiler"
> * The debugger with an (expression) "compiler"
> 
> All these "compilers" are different and need to stay in synch. That's 
> not how you do good software development. You build a compiler library 
> that can be used in all the above tools. BTW, it's only the real 
> compiler that can handle everything properly.

I think you are right. So clearly to make bindings possible this library would 
export a set of C functions. (I should think of export(C) as the "least common 
denominator" here.) DMD is no where close to look like a library and 
IDEs/debuggers need a different set of features. I think we can start a new 
thread to discuss this and maybe a Wiki page to collect ideas and brainstorm, 
unless there are better tools for that available. It would be nice if the 
developers of DDT, Descent, Mono-D and VisualD could share their insights there 
to get the requirements straight.

-- 
Marco

Re: Export ?

[Kapps]

On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:


As I said in the other thread, I _hate_ export. It's one of 
Windows largest
misfeatures IMHO. It drives me nuts when I have to deal with it 
in C++. The
fact that Linux exports everything is _fantastic_. It's so much 
easier to deal
with. I'd _hate_ to see Linux or anything we do move in the 
direction of what

Windows has done.

- Jonathan M Davis


Agreed. Ideally, there would be a compiler flag to export all 
public symbols by default. Public is there for a reason, public 
is default for a reason. Now forcing a bunch of clutter just to 
add expor to everything, would defeat the purpose and is the 
single largest reason I don't use DLLs.

Re: MD5, SHA1, SHA256, CRC32

[Manu]

On 10 April 2012 20:41, Piotr Szturmaj  wrote:

> Adam D. Ruppe wrote:
>
>> There's a few of us who have written our own
>> implementations of these, but as far as I know
>> none of them are considered good enough for
>> stdlib.
>>
>>
>> But if you just want something you can use now,
>> here's mine for sha:
>>
>> https://github.com/adamdruppe/**misc-stuff-including-D-**
>> programming-language-web-**stuff/blob/master/sha.d
>>
>
> And here's mine: https://github.com/pszturmaj/**
> phobos/blob/master/std/crypto/**hash/sha.d(yeah,
>  I need to move it to a new branch)
>

I've needed these the past few days too.. what makes this one unsuitable
for std? I see you've put it in the std namespace ;)
Is there something holding it back?

Re: Export ?

[Paulo Pinto]

Windows is not alone in this regard. AIX uses a similar behaviour

http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/topic/com.ibm.vacpp7a.doc/proguide/ref/compile_library.htm#compile_library

Remember not all UNIXes are made alike. :)

--
Paulo



On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:

On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:
On this newsgroup with Jonathan M Davis, we started discussing 
export.
As it was off topic, and as it was interesting, I wish to 
bring it here.


As most of you know, all symbol on posix systems are export, 
but not on
windows. As D have an export keyword, the question is what to 
do with it.


The need for change in the UNIX world of this behavior exists, 
and some
move has been made in direction of explicitly hiding symbols ( 
see

http://gcc.gnu.org/wiki/Visibility ).


As I said in the other thread, I _hate_ export. It's one of 
Windows largest
misfeatures IMHO. It drives me nuts when I have to deal with it 
in C++. The
fact that Linux exports everything is _fantastic_. It's so much 
easier to deal
with. I'd _hate_ to see Linux or anything we do move in the 
direction of what

Windows has done.

- Jonathan M Davis

Re: Foreach Closures?

[Jacob Carlborg]

On 2012-04-10 19:49, Marco Leise wrote:


I think you are right. So clearly to make bindings possible this library would export a 
set of C functions. (I should think of export(C) as the "least common 
denominator" here.) DMD is no where close to look like a library and IDEs/debuggers 
need a different set of features. I think we can start a new thread to discuss this and 
maybe a Wiki page to collect ideas and brainstorm, unless there are better tools for that 
available. It would be nice if the developers of DDT, Descent, Mono-D and VisualD could 
share their insights there to get the requirements straight.



Sounds like a good idea.

--
/Jacob Carlborg

Re: The Downfall of Imperative Programming

[Paulo Pinto]

Microsoft is taking a careful approach with F# in what concerns 
GUIs.


Actually they are promoting C# or VB.NET code for the GUI part, 
while

leaving all the business code for F#.

This approach seems to cater more for the business audience, as to
have the GUI also written in F#.

--
Paulo

On Tuesday, 10 April 2012 at 17:42:24 UTC, Gour wrote:

On Tue, 10 Apr 2012 19:01:07 +0200
"bls"  wrote:


GTK


Then, D is better even in that regard. ;)


Sincerely,
Gour

Re: The Downfall of Imperative Programming

[Paulo Pinto]

My favourite FP language is Haskell, but I doubt most "code
monkeys"
will ever be able to grasp it, while impure ones are more
approachable
in enterprise environments.

The issues you point out are actually more implementation
issues than language related, right?

--
Paulo

On Tuesday, 10 April 2012 at 17:19:00 UTC, Russel Winder wrote:

Two quite interesting points to make here:

1.  OCaml has a GIL and so, like CPython (*), is forced to use 
operating
system processes to obtain parallelism. Also OCaml has 
imperative
features, it is not a pure functional language.  Clojure 
followed this

route as well, using STM to deal with locking issues.

2. Haskell is a lazy language which means:
a. it can work with infinite data structures; and
b. it is incredibly difficult to create parallel codes.

Simon Peyton Jones and Simon Marlow have had to do a great deal 
of very
clever work to make Data Parallel Haskell, but it is to Haskell 
what

NumPy is to Python.

I am a fan of declarative expression, I prefer functional 
approaches
over explicitly imperative ones.  For the moment though using 
single

assignment in imperative languages with all the lambda/closure
technology and using functional programming thinking is the best
compromise.  OCaml (and its clone F#) and Haskell are likely to 
remain

tiny bit part players for a long while.

On the JVM the interesting question is whether Clojure finally 
makes

Lisp a mainstream language outside of one or two domains.


(*) PyPy is experimenting with STM to replace use of a GIL.

Re: Object arrays in D

[Marco Leise]

Am Tue, 10 Apr 2012 07:35:31 -0400
schrieb "Steven Schveighoffer" :

> Destructors are strictly for cleaning up resources that *AREN'T* allocated  
> by the GC.  For example anything created with C's malloc, or an open file  
> descriptor, etc.

This I think is a very good advice to beginners. Short and precise. It is much 
more fun to use a new language when you can also free your mind from some 
archaic concepts now and then :)

-- 
Marco

Re: MessagePack

[Masahiro Nakagawa]

Hi Andrej,

Sorry, I wasn't aware that this thread.

I just deleted the old repository ;)

On Saturday, 24 March 2012 at 05:31:10 UTC, Andrej Mitrovic wrote:

On 3/24/12, Andrej Mitrovic  wrote:

https://github.com/msgpack/msgpack-d


Btw, thank you very much for your hard work Masahiro Nakagawa! 
Your
serialization library has reduced my waiting time by over 20 
seconds

(I used Json before even though I didn't need a human-readable
format).


Thanks!

In japan, many companies use MessagePack to reduce the processing 
time.
I also use MessagePack in companies job and communicate other 
languages :)



Masahiro

Re: MD5, SHA1, SHA256, CRC32

[Piotr Szturmaj]

Manu wrote:

On 10 April 2012 20:41, Piotr Szturmaj https://github.com/pszturmaj/__phobos/blob/master/std/crypto/__hash/sha.d

(yeah, I need to move it to a new branch)


I've needed these the past few days too.. what makes this one unsuitable
for std? I see you've put it in the std namespace ;)
Is there something holding it back?


Incompleteness :) I'm currently working on a commercial project and I 
don't have much time for this.


http://prowiki.org/wiki4d/wiki.cgi?CryptoDevel (any help will be 
appreciated)

Re: The Downfall of Imperative Programming

[Gour]

On Tue, 10 Apr 2012 20:19:13 +0200
"Paulo Pinto"  wrote:

> My favourite FP language is Haskell, but I doubt most "code
> monkeys" will ever be able to grasp it, while impure ones are more
> approachable in enterprise environments.

That's right...I tried with Haskell, liked its syntax a lot, but was not
sure I really grokked monads. Moreover, I lost few potential
contributors because of insisting on Haskell.

Now, I hope to get some of the FP features by using Haskell and have
easier time not to think about unsafePerformIO & co. :-)


Sincerely,
Gour


-- 
The senses, the mind and the intelligence are the sitting places 
of this lust. Through them lust covers the real knowledge of the 
living entity and bewilders him.


signature.asc
Description: PGP signature

Re: Small Buffer Optimization for string and friends

[Artur Skawina]

On 04/10/12 19:25, Marco Leise wrote:
> Am Tue, 10 Apr 2012 10:50:24 +0200
> schrieb Artur Skawina :
> 
>> Obviously, yes, but should wait until enough attribute support is in place 
>> and
>> not be just a @inline hack.
> 
> If you refer to the proposed user attributes, they wont change the operation 
> of the compiler. Only your own program code will know how to use them. 
> @inline, @safe, @property, final, nothrow, ... on the other hand are keywords 
> that directly map to flags and hard wired logic in the compiler. Correct me 
> if I'm wrong.

I'm saying that introducing new function attributes like @inline to the 
language,
when there's a real possibility of "generic" attributes being invented in the 
near
future, may not be a good idea. Any generic scheme should also work for @inline 
and
the many other attrs that i've mentioned before - there's no reason to 
artificially
limit the support to *just* user attributes.

artur