Re: Value Range Propagation

[Vladimir Panteleev]

On Wed, 23 Feb 2011 08:23:32 +0200, Walter Bright  
 wrote:



http://ddj.com/blog/archives/2011/02/value_range_pro.html


http://www.digitalmars.com/d/2.0/ctod.html#types , which is linked from  
the article, still mentions the bit type.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: We need to rethink remove in std.container

[Philippe Sigaud]

On Tue, Feb 22, 2011 at 23:20, Steven Schveighoffer  wrote:
>
> s/insert/put
>
> Now all containers that support insertion are output ranges...
>
> Or am I missing something?

I mean that, in the same way that a container can expose its elements
as an input range using [], a partially filled container could give
access to its empty 'slots' (created by 'reserve()' ) via an output
range.

Re: DMD versions

[Walter Bright]

Russel Winder wrote:

On Fri, 2011-02-18 at 14:47 +0100, Jens Mueller wrote:

If you start dmd without any arguments it will give you the information
as well.
$ dmd
Digital Mars D Compiler v2.052
...

So you can parse the first line of this output.


OK, that is the same as "dmd --help", I can make it work.  Thanks.


Just for fun, try:

   dmd -man

!!

Value Range Propagation

[Walter Bright]

http://ddj.com/blog/archives/2011/02/value_range_pro.html

Re: dmd, x64 and Windows

[Andrej Mitrovic]

I've tried to build it on native windows. It seems to build fine, and
after I've issued make install it got installed to build/mingw32.

But I'm missing libstdc++.dll. I couldn't figure out where to download
the dll from, the MinGW sourceforge website is horrible to browse
through.
I copied the DLL from an existing 4.5.2 MinGW installation.

I tried compiling a simple test project:

gdc main.d
ld.exe: cannot find -lpthread

I've already copied these:
* binutils 2.20.51
* mingw-runtime 3.18
* w32api 3.14

But maybe I'm missing more runtime libraries. Probably some lib
package that has the libstdc++.dll file as well. Any clues?

Re: Frustratingly D

[Jesse Phillips]

Things are moving in the direction you want, but it is slow. Wiki4D is a good 
place to put tutorials and read them.

http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage

Here are some quick comments:

Nicholas Wrote:

> Here are some particular annoyances that need further
> clarification/examples/comparisons to their siblings:
> std.concurrency vs std.thread

MPI vs Threads

> std.date vs. std.datetime

std.date is deprecated.

> std.regex vs. std.regexp (scheduled for)

std.regexp is deprecated. (scheduled for)

> std.file vs. std.cstream and there's quite a bit of crossover with std.stream
> std.xml: unfortunately one of the few modules that doesn't have a sibling.

std.jason? Actually std.xml is probably gone in the next release, too many bugs.

> And Andrei, you're a great programmer but your example-giving skills could be
> strengthened.  From std.array to std.range to std.random, all your examples
> are equivalent to this:
> auto a = [ 1, 2, 3 ];
> assert( ... );

I think this is a good way to show the input and output. Unlike other examples 
where the program must be run because it uses print statements.

> auto a = obj.method( "guess what i'm returning" );

That is what the documentation is for. Since the example is in the 
documentation that shouldn't be hard to find.

I don't know about other people but documentation for the library is one of the 
things I keep open/available when I'm using the library. I just hope that the 
return type for an 'auto function' is printed in the documentation instead of 
just 'auto'

> I like auto.  I use it sometimes.  But it's not always clear what's taking
> place in the examples.  I believe you should exclude auto from all examples
> except when explaining auto.

A lot of Phobos returns templated structs, these things can get quite scary to 
a new user. There is also an aspect where being concerned about the type is 
unimportant. And good documentation will make it easier to find the information 
you are really after.


> I see great potential in D and enjoy it.  I would like to see the
> documentation improve and the standard library cleaned up.  I'm sure there are
> a million reasons why it evolved into what it has so far but for a new user
> those reasons are unimportant.  Put them in the "History of D".

It is much better than it used to be. More work is being done on these issues 
though. Now we just need them finished a little more.

Re: dmd, x64 and Windows

[Iain Buclaw]

== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> I've been trying to compile GDC the last couple of days. I've ran into
> some issues, but I've put them in GDC tickets and it seems from the
> last comments that Iain Buclaw has managed to create a cross-compiler
> setup and working. This is all last-minute info so I don't know if
> we'll have GDC working on Windows just yet.

D2 Ming32 cross-compiler built, but haven't yet tested the quality of the object
files outputted (will no doubt be using WINE).

Changeset: https://bitbucket.org/goshawk/gdc/changeset/978bb5bc82cf

And briefly documented, as I *will* forget when the morning comes:
https://bitbucket.org/goshawk/gdc/wiki/MinGWCrossCompile

Re: Lazy lists

[spir]

On 02/23/2011 03:28 AM, bearophile wrote:

A task from the RosettaCode site asks to generate a Sierpinski carpet like 
this, on given order:


###
# ## ## ## ## ## ## ## ## #
###
###   ##   ##   ###
# #   # ## #   # ## #   # #
###   ##   ##   ###
###
# ## ## ## ## ## ## ## ## #
###
# #
# ## ## # # ## ## #
# #
###   ### ###   ###
# #   # # # #   # #
###   ### ###   ###
# #
# ## ## # # ## ## #
# #
###
# ## ## ## ## ## ## ## ## #
###
###   ##   ##   ###
# #   # ## #   # ## #   # #
###   ##   ##   ###
###
# ## ## ## ## ## ## ## ## #
###


This is a Scala implementation of a function that prints the carpet:


def nextCarpet(carpet: List[String]): List[String] = (
   carpet.map(x =>  x + x + x) :::
   carpet.map(x =>  x + x.replace('#', ' ') + x) :::
   carpet.map(x =>  x + x + x))

def sierpinskiCarpets(n: Int) = (Iterator.iterate(List("#"))(nextCarpet) drop n 
next) foreach println



A D version that uses arrays:

import std.stdio, std.string, std.algorithm, std.array, std.range;

string[] nextCarpet(string[] c) {
 auto b = array(map!q{a ~ a ~ a}(c));
 return b ~ array(map!q{a ~ a.replace("#"," ") ~ a}(c)) ~ b;
}

void main() {
 auto c = recurrence!((a, n){ return nextCarpet(a[n-1]); })(["#"]);
 writeln(array(take(c, 4)).back.join("\n"));
}


Few notes:
- I don't know how to take just the 4th item of a lazy sequence. array(take(c, 
4)).back is not good.

- recurrence() is a bit overkill. A function like iterate() simplifies the code:
auto c = iterate!nextCarpet(["#"], 4);

- I don't see a simple way to create a lazy nextCarpet(), without those array(). The seed (["#"]) 
can't be an array, but even wrapping it with a lazy map!q{a}(["#"]) solves nothing. 
chain(map(chain...))) are all different types, so I think it can't work. The types in that Scala code are 
sound because it uses a lazy list type, that supports the ::: operator for concatenation, and 
List("#") to create the correctly typed seed. That carpet.map() returns a List[String]. So both the 
input and output of the Scala nextCarpet() are of the same type, List[String]. So such lazy list type 
template becomes really useful if you want to program in a lazy functional style.


Maybe we should reverse the point of view and start with Range. A base type for 
anything 'sequential' (iterable) is Range of E (element type). Then, an array 
E[] is a Range of E that just happens to have its elements pre-stored. Ditto 
for any other collection. And a slice, or any other kind of 'view' into a 
collection, is a Range of E that just happens to have direct access to its 
elements (in memory, via pointer; or via cursor, or whatever).


Denis
--
_
vita es estrany
spir.wikidot.com

Lazy lists

[bearophile]

A task from the RosettaCode site asks to generate a Sierpinski carpet like 
this, on given order:


###
# ## ## ## ## ## ## ## ## #
###
###   ##   ##   ###
# #   # ## #   # ## #   # #
###   ##   ##   ###
###
# ## ## ## ## ## ## ## ## #
###
# #
# ## ## # # ## ## #
# #
###   ### ###   ###
# #   # # # #   # #
###   ### ###   ###
# #
# ## ## # # ## ## #
# #
###
# ## ## ## ## ## ## ## ## #
###
###   ##   ##   ###
# #   # ## #   # ## #   # #
###   ##   ##   ###
###
# ## ## ## ## ## ## ## ## #
###


This is a Scala implementation of a function that prints the carpet:


def nextCarpet(carpet: List[String]): List[String] = (
  carpet.map(x => x + x + x) :::
  carpet.map(x => x + x.replace('#', ' ') + x) :::
  carpet.map(x => x + x + x))
 
def sierpinskiCarpets(n: Int) = (Iterator.iterate(List("#"))(nextCarpet) drop n 
next) foreach println



A D version that uses arrays:

import std.stdio, std.string, std.algorithm, std.array, std.range;
 
string[] nextCarpet(string[] c) {
auto b = array(map!q{a ~ a ~ a}(c));
return b ~ array(map!q{a ~ a.replace("#"," ") ~ a}(c)) ~ b;
}
 
void main() {
auto c = recurrence!((a, n){ return nextCarpet(a[n-1]); })(["#"]);
writeln(array(take(c, 4)).back.join("\n"));
}


Few notes:
- I don't know how to take just the 4th item of a lazy sequence. array(take(c, 
4)).back is not good.

- recurrence() is a bit overkill. A function like iterate() simplifies the code:
auto c = iterate!nextCarpet(["#"], 4);

- I don't see a simple way to create a lazy nextCarpet(), without those 
array(). The seed (["#"]) can't be an array, but even wrapping it with a lazy 
map!q{a}(["#"]) solves nothing. chain(map(chain...))) are all different types, 
so I think it can't work. The types in that Scala code are sound because it 
uses a lazy list type, that supports the ::: operator for concatenation, and 
List("#") to create the correctly typed seed. That carpet.map() returns a 
List[String]. So both the input and output of the Scala nextCarpet() are of the 
same type, List[String]. So such lazy list type template becomes really useful 
if you want to program in a lazy functional style.

Bye,
bearophile

Re: Uh... destructors?

[%u]

>> - private makes no sense since (unless we're trying to imitate C++ here) 
>> destructors are only called from
the runtime, and nowhere else.
>> - The only meaningful attribute there is extern(C).

> In what way is extern(C) meaningful for a destructor?

I guess it would be logical to specify that, if someone is desperately trying 
to get C code to interop with
D. But I don't think it's too useful... it's just not meaningless.


>> I would agree that DMD should ignore the attributes that are redundant or 
>> optional (e.g. it should be
okay for "static" to be written and/or omitted at the module-level, and DMD 
should ignore it) but I don't
see why _wrong_ attributes should be ignored... it confuses the programmer, 
opens the potential for error,
and doesn't have any benefits.

> I entirely agree.  It's been discussed quite a bit:
> http://d.puremagic.com/issues/show_bug.cgi?id=3118

Interesting... thanks for the link!

Re: How to do Generic Programming in D?

[Adam D. Ruppe]

bearophile wrote:
> Is this enough to make some C++ shops switch to D2?

If they are doing new code, it should be! For existing code, that
depends on their specific situation.

The reason I was writing C++ recently though was Qt - I wanted
to use existing code. (QtD is so, so close, but has some
showstopper bugs on Windows and doubled the size of the
distribution... so I instead wrote the GUI in C++ and the rest
of the app in D. Then I got the best of both worlds.)

> Firms that have megabytes of complex C++ legacy code are not
> going to translate it to D2 just because D2 has something nicer.

Most likely, they aren't going to translate it *at all*. There's
rarely a big benefit in translating code.

But, when writing fresh code, those nicer things add up to a big
difference.

> And there are significant problems in integrating D2 code in C++
> projects. The switch from C to C++ was much more smooth.

I don't know, I've never tried that. But integrating C++ into D2
apps isn't too bad.

> And lot of people have already stopped using static compilers
> like C++ ones and have switched to the niceties of a virtual
> machine, dynamic compilation, etc.

Their loss.

Re: Frustratingly D

[spir]

On 02/23/2011 01:15 AM, bearophile wrote:

Nicholas:


auto a = obj.method( "guess what i'm returning" );


I like auto.  I use it sometimes.  But it's not always clear what's taking
place in the examples.  I believe you should exclude auto from all examples
except when explaining auto.


Unfortunately this happens in normal code too, not just in examples. auto is 
practically necessary when you use lazy iterables, because their type is 
usually too much complex to write, but in the other cases it obfuscates the 
code a little.

In dynamic languages it's like using auto everywhere. But programmers of dynamic 
languages survive because they program in a way that makes the implicit types a bit more 
easy to guess :-) D code that uses "auto" a lot needs to be written in the same 
way, with very well chosen variable names, etc.


???

unittest {
auto a = [1,2,3];
auto x = map!((i) { return i+1; })(a);
writeln(typeid(x));
// --> test.__unittest3.Map!(__dgliteral1,int[]).Map
}

There's no such type in any dynamic language I know of ;-)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: Frustratingly D

[Adam D. Ruppe]

Nicholas wrote:
> The online documentation has a bunch of cluttered links at the top,
> no hierarchy, no dates, and it reads like a list of nutritional facts.

Andrei and I are both working on improving the situation. I forgot
where Andrei's playground is, but I copied a lot of his ideas on my
site too. Here's one page:

Andrei's cheat sheet idea is visible here:
http://arsdnet.net/d-web-site/std_stdio.html

And my first draft at hierarchy:
http://arsdnet.net/d-web-site/std_algorithm.html

(the cheat sheet is significantly better IMO)


Once you get the know the library, my other project, a
documentation name search might be useful to you:
http://dpldocs.info/

You can jump to a module or function by putting it on the url:

http://dpldocs.info/std.stdio.File

And it does a quick keyword search too if you don't give a full
name. Note it lags a bit on Phobos versions because I only update
it every other release.

Re: Frustratingly D

[bearophile]

Nicholas:

> auto a = obj.method( "guess what i'm returning" );
> 
> 
> I like auto.  I use it sometimes.  But it's not always clear what's taking
> place in the examples.  I believe you should exclude auto from all examples
> except when explaining auto.

Unfortunately this happens in normal code too, not just in examples. auto is 
practically necessary when you use lazy iterables, because their type is 
usually too much complex to write, but in the other cases it obfuscates the 
code a little.

In dynamic languages it's like using auto everywhere. But programmers of 
dynamic languages survive because they program in a way that makes the implicit 
types a bit more easy to guess :-) D code that uses "auto" a lot needs to be 
written in the same way, with very well chosen variable names, etc.

Bye,
bearophile

Re: Uh... destructors?

[Stewart Gordon]

On 22/02/2011 06:08, %u wrote:


- synchronized is meaningless since there's only one thread ever running the 
destructor anyway


As such, destructors are vacuously synchronized.  At least, if you don't have a collision 
between threads that try to delete the same object at the same time, but that would 
indicate a bug in the program anyway.



- private makes no sense since (unless we're trying to imitate C++ here) 
destructors are only
called from the runtime, and nowhere else.
- The only meaningful attribute there is extern(C).


In what way is extern(C) meaningful for a destructor?


I would agree that DMD should ignore the attributes that are redundant or 
optional (e.g. it should
be okay for "static" to be written and/or omitted at the module-level, and DMD 
should ignore it)
but I don't see why _wrong_ attributes should be ignored... it confuses the 
programmer, opens the
potential for error, and doesn't have any benefits.


I entirely agree.  It's been discussed quite a bit:
http://d.puremagic.com/issues/show_bug.cgi?id=3118


(The only exception I can think of to this rule
would be attributes that cannot be removed, like saying "private:" in the 
beginning... for general
attributes like those, I guess DMD can ignore them, but for specifically 
written attributes like
these, is there any benefit whatsoever to allowing them?)


No.

Stewart.

Frustratingly D

[Nicholas]

For about 2 months I've been sinking into D.  I really enjoy it and I want to
love it but I'm constantly annoyed by the presentation of information.
Several times I've built things that were in the standard library because the
website is poorly organized and doesn't contain sufficient examples.  The
online documentation has a bunch of cluttered links at the top, no hierarchy,
no dates, and it reads like a list of nutritional facts.  My only recourse is
to grep like mad through the source files and find the actual implementations
and unit tests.  It's bad enough that there are no modern IDEs so that it
already feels like it's 1994 again.


Here are some particular annoyances that need further
clarification/examples/comparisons to their siblings:
std.concurrency vs std.thread
std.date vs. std.datetime
std.regex vs. std.regexp
std.file vs. std.cstream and there's quite a bit of crossover with std.stream
std.xml: unfortunately one of the few modules that doesn't have a sibling.


And Andrei, you're a great programmer but your example-giving skills could be
strengthened.  From std.array to std.range to std.random, all your examples
are equivalent to this:
auto a = [ 1, 2, 3 ];
assert( ... );

auto a = obj.method( "guess what i'm returning" );


I like auto.  I use it sometimes.  But it's not always clear what's taking
place in the examples.  I believe you should exclude auto from all examples
except when explaining auto.


I see great potential in D and enjoy it.  I would like to see the
documentation improve and the standard library cleaned up.  I'm sure there are
a million reasons why it evolved into what it has so far but for a new user
those reasons are unimportant.  Put them in the "History of D".


No hard feelings.  Just some thoughts.

Re: dmd, x64 and Windows

[Walter Bright]

Trass3r wrote:
While I'm delighted that we finally have a basic D2 x64 compiler I can't 
stop wondering how long it will take till I finally get my hands on it 
on Windows.
God knows I'd have switched to gdc long ago if gcc wasn't such a PITA to 
compile on Windows! Several attempts over the past year failed.


What bothers me most is that the bigger part of the delay is due to an 
antiquated object format, linker and C runtime (that have caused enough 
despair and rage since the beginning of time.. er, D)

ELF is standard on Linux, Mach-O on Mac. And dmd adheres to that.
So isn't Windows' de facto standard COFF in combination with MinGW's ld 
or VC's link the natural choice?


To do 64 bits on Windows requires:

1. 64 bit OMF
2. 64 bit librarian
3. 64 bit generating dmd
4. 64 bit C compiler
5. 64 bit symbolic debug info
6. 64 bit debugger
7. 64 bit C runtime

Just one of those won't do it. All are necessary. The reason I did 64 bit linux 
first is all those things were ready to rock but dmd.

Re: How to do Generic Programming in D?

[bearophile]

Adam D. Ruppe:

> C++0x felt like a crippled, inelegant D. Yes, it has variadic
> templates, but without foreach, I had to use recursion to go
> over them. Without static if and template constraints, it was
> a mess of overloaded functions and what felt like horrible
> abuses of SFINAE.

Is this enough to make some C++ shops switch to D2? Firms that have megabytes 
of complex C++ legacy code are not going to translate it to D2 just because D2 
has something nicer. And there are significant problems in integrating D2 code 
in C++ projects. The switch from C to C++ was much more smooth. And lot of 
people have already stopped using static compilers like C++ ones and have 
switched to the niceties of a virtual machine, dynamic compilation, etc.

Bye,
bearophile

Re: Uh... destructors?

[bearophile]

> A safer idea comes from using the type system, but it's hard. The idea is 
> introducing "pure memory references".

I think I have just invented the idea of referentially transparent 
pointers/references for D, a subtype of normal D pointers/references.

Bye,
bearophile

LDC2 Status

[dsimcha]

I tried LDC2 for Linux out last week and again last night.  I didn't 
spend much time on it on either attempt, but so far I haven't been able 
to get even Hello, World to compile.  It seems like the instructions for 
building druntime, etc. are horribly outdated, the patches bit rotted, 
etc.  Has anyone managed to get past these hurdles and compile Hello, 
World lately?  If so, would you mind posting some instructions?  If LDC2 
is, in fact, mature enough that it would be worthwhile, I'd like to test 
it out, file bug reports, etc.

Re: dmd, x64 and Windows

[Andrej Mitrovic]

I've been trying to compile GDC the last couple of days. I've ran into
some issues, but I've put them in GDC tickets and it seems from the
last comments that Iain Buclaw has managed to create a cross-compiler
setup and working. This is all last-minute info so I don't know if
we'll have GDC working on Windows just yet.

Re: How to do Generic Programming in D?

[Adam D. Ruppe]

Nick wrote:
> Of course, the basic question being: is D2 sufficient to support
> everything that is possible in C++?

So far, everything I've tried has not only been possible, but quite
a bit easier.

Last weekend, I had to go back to C++ to do some quick work. I wanted
to port a boxer function over. In D, I used a variadic template,
foreach, and static if to it off.

The code was about 100 lines long and either worked for all types
or failed meaningfully.


C++ couldn't take that approach. I figured I could get closer
if I used some C++0x features, and since this project only had
to work in environments I control, I enabled them and went to
town.

C++0x felt like a crippled, inelegant D. Yes, it has variadic
templates, but without foreach, I had to use recursion to go
over them. Without static if and template constraints, it was
a mess of overloaded functions and what felt like horrible
abuses of SFINAE.

A simple looped assignment, 4 lines in D, became about 60 lines of
bizarre overloads and recursion, and still didn't handle all
the types quite as elegantly as D.

When it was all said and done, the 100 lines of D became about
250 lines of C++0x. (There's other features that are pretty equal
so it wasn't all so lopsided).

Then, the real ugliness came in. In D, you can do compile time
reflection. Want to automatically implement an interface with
the boxer function? Another simple foreach loop with static ifs
to round it off.

I couldn't figure it out in C++. It was probably possible, but it
was too hard for my simpleton brain to handle. I ended up writing
a helper code generator for it.

(btw, on code generators, if you
write one in D, you can probably call it at compile time and
generate the code all at once... no need for extra steps in your
build process! See string mixins and CTFE for how. Short answer:
write the code generator as a function returning a string with
the code. Then do mixin(myCodeGenFunction()); It'll probably
work!)


That's the big difference between C++ and D. C++ makes it possible.
D makes it accessible.

Re: Uh... destructors?

[bearophile]

> This is an idea to patch that hole a little, doing this inside pure functions:
> 1) Keep disallowing alloca()/malloc()/etc calls;
> 2) Disallow struct allocations;
> 3) Keep allowing object and dynamic array allocations;
> 4) Disallow read and write of the "ptr" fields of dynamic arrays;
> 5) Disallow casts of object references to something else.

Note this is about _inside pure functions_.

A safer idea comes from using the type system, but it's hard. The idea is 
introducing "pure memory references". Any memory allocation inside a pure 
function returns a pointer/reference that can't be _read_ (as value) inside the 
pure function itself, or even outside it, if it among the function results. I 
think it's possible to design a type system able to enforce this safely, but I 
don't think this will happen for D.

Bye,
bearophile

Re: dmd, x64 and Windows

[Trass3r]

antiquated object format, linker and C runtime (that have caused enough  
despair and rage since the beginning of time.. er, D)


Just count the occurrences of "OPTLINK" preceding the post "Bye, D!":
http://h3.gd/devlog/

Re: Uh... destructors?

[bearophile]

Steven Schveighoffer:

> I would think malloc and friends should be pure, as well as free.  They  
> can easily simply be marked pure, since they are C bindings.

D even accepts strongly pure functions like:

pure size_t foo() { 
auto a = new ubyte[1];
return cast(size_t)a.ptr;
}

For practical purposes D allows pure functions to return dynamic arrays, 
objects and structs allocated inside them. This is a significant hole in the D 
idea of purity. I think marking malloc as pure makes the situation worse :-)

This is an idea to patch that hole a little, doing this inside pure functions:
1) Keep disallowing alloca()/malloc()/etc calls;
2) Disallow struct allocations;
3) Keep allowing object and dynamic array allocations;
4) Disallow read and write of the "ptr" fields of dynamic arrays;
5) Disallow casts of object references to something else.

This reduces some flexibility of pure functions, it doesn't fully patch that 
hole, and makes language rules a more complex.

The idea under those ideas is that objects and arrays are usually interesting 
for the data/semantics they contain, and not for the value of their pointer. If 
you ignore the value of their pointer, then the hole vanishes. You can't full 
close this hole, but those ideas help avoid the more blatantly impure semantics 
inside/from pure functions.

I'd like to patch that hole, but it can't be fully patched. So maybe all this 
is useless, or worse it makes the language more rigid and not more safe, so 
it's probably better to not adopt those ideas.

Bye,
bearophile

dmd, x64 and Windows

[Trass3r]

While I'm delighted that we finally have a basic D2 x64 compiler I can't  
stop wondering how long it will take till I finally get my hands on it on  
Windows.
God knows I'd have switched to gdc long ago if gcc wasn't such a PITA to  
compile on Windows! Several attempts over the past year failed.


What bothers me most is that the bigger part of the delay is due to an  
antiquated object format, linker and C runtime (that have caused enough  
despair and rage since the beginning of time.. er, D)

ELF is standard on Linux, Mach-O on Mac. And dmd adheres to that.
So isn't Windows' de facto standard COFF in combination with MinGW's ld or  
VC's link the natural choice?

Re: How to do Generic Programming in D?

[Andrei Alexandrescu]

On 2/22/11 1:04 PM, Nick wrote:

Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how
to implement many of those patterns in D?

In C++ I would work with type lists and use lots of multiple inheritance
and templates to get the magic I need.

D lacks MI, classes and delegates seem heavy (allocated on heap, with
one extra pointer and new for each delegate) and has instead template
mixins which do not create types and string mixing which create...
anything.

So I am a bit lost.

I guess I am looking for some code&examples to read to "get" GP in D. A
bit like "Modern C++ Programming".

Of course, the basic question being: is D2 sufficient to support
everything that is possible in C++?

Thanks!


Welcome to the group.

Using D for the kind of generic designs featured in MC++D may be a bit 
disconcerting because a lot of the C++ implementation is forced to use 
unintuitive mechanisms to get things done. The expectation is that the 
same mechanisms need to be used for the D implementation, too, which 
shouldn't be the case. In fact accomplishing any of MC++D's tasks is 
considerably easier in D.


For example, indeed in C++ a policy-based design would need to use 
multiple inheritance. But this is not motivated by a need for multiple 
subtyping - MI is just the best proxy C++ has for injecting 
parameterized implementation. In D for that goal you'd use mixin 
templates, or for ultimate flexibility string mixins. If you do need 
multiple subtyping, you'd use classes in conjunction with e.g. 
parameterized interfaces and/or "alias this".


Typelists are an elaborate C++ construct that is essentially built in 
into D.


For the Command pattern, delegates would be a great start. Added value 
for e.g. currying and binding is trivial to implement, to the extent 
that we decided to deprecate a dedicated module (std.bind).


There would be more to say. One way or another, policy-based design is 
difficult and often unintuitive. Therefore, it requires mastery of both 
the design topic at hand and of the implementation language. I think 
trying to get a solid PBD component off the ground as a D beginner would 
be pushing it. Nevertheless, it may be worth a try. I suggest starting 
with a simple, well-defined component such as Object Factory.



Andrei

Re: How to do Generic Programming in D?

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ik14sh$2lfi$1...@digitalmars.com...
> "Nick"  wrote in message 
> news:ik11ot$2fms$1...@digitalmars.com...
>> Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how to 
>> implement many of those patterns in D?
>>
>> In C++ I would work with type lists and use lots of multiple inheritance 
>> and templates to get the magic I need.
>>
>
> I abandoned C++ about 10 years ago so I don't know anything about the 
> patterns you're talking about, but:
>
>> D lacks MI,
>
> Replaced by either mixins or interfaces, depending on what you're trying 
> to do.
>

Oh, and also "alias this" which, as explained in Andrei's book "The D 
Programming Language" can be a very useful alternative to MI, particularly 
when combined with nested classes. "alias this" is also good for subtyping 
structs, even though structs still aren't polymorphic.

Like Jason said, if you have specific examples of idioms, we can translate 
to D for you.

Re: Uh... destructors?

[Steven Schveighoffer]

On Tue, 22 Feb 2011 16:34:21 -0500, bearophile   
wrote:



Steven Schveighoffer:


Freeing and allocating memory is fair game for pure functions.


Allocating arrays and objects is possible in pure D functions, despite  
the memory pointers they contain (like the ptr of a returned array) are  
different across different calls. This makes those function only  
formally pure and requires care from both the programmer and the  
optimizations done by the compiler, to avoid some bad bugs :-)


Example: the C calloc() function is not considered pure, despite what it  
does is not so far from a pure D function that allocates and returns a  
dynamic array of ubytes:


import core.stdc.stdlib: calloc;

// OK
pure ubyte* foo1(int n) {
auto a = new ubyte[n];
return a.ptr;
}

// Error: pure function 'foo2' cannot call impure function 'calloc'
pure ubyte* foo2(int n) {
return cast(ubyte*)calloc(n, 1);
}

void main() {}


I would think malloc and friends should be pure, as well as free.  They  
can easily simply be marked pure, since they are C bindings.



Regarding freeing memory in pure functions, I am even less sure.


If allocation is pure, freeing should also be pure.  You should be allowed  
to clean up what you created in a pure function.


To draw a parallel, a GC collect cycle should be "pure", even though it  
affects global state.  Otherwise, the GC would have to be disabled during  
pure functions.


-Steve

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 16:55:29 -0500, Andrei Alexandrescu  
 wrote:



On 2/22/11 3:23 PM, Philippe Sigaud wrote:

Btw, is there a way to have
an empty container and use an output range to fill it? I didn't look
at std.container for quite some time.


No, but this may be an interesting idea to pursue.


s/insert/put

Now all containers that support insertion are output ranges...

Or am I missing something?

-Steve

Re: We need to rethink remove in std.container

[Andrei Alexandrescu]

On 2/22/11 3:23 PM, Philippe Sigaud wrote:

On Tue, Feb 22, 2011 at 15:23, Andrei Alexandrescu
  wrote:


auto singletonRange(T)(T element)
{
static struct Result
{
private T _element;
private bool _done;
@property bool empty() { return _done; }
@property auto front() { assert(!empty); return _element; }
void popFront() { assert(!empty); _done = true; }
auto save() { return this; }
}

return Result(element, false);
}

That's also what many people would like a findFirst function to

return. Either a 1-element range with the found value or an empty
range if the value doesn't exist.

auto v = findFirst(range, needle);

if (!v.empty) { ... }


Good point.


Maybe you could allow for the creation of an empty output
singletonRange where a lone value could then be put.
auto singleton(T)() { ... } but the user would need to provide the 'T'
by himself.


Yah, I thought of that after posting. It would look something like this:

auto singletonRange(T)()
{
typeof(singletonRange(T.init)) result = void;
result._done = true;
return result;
}

No mercy :o). But that's unsafe so probably we'd need to leave out "= void".


and then:

void put(T element) {assert(empty); _element = element;}
That could be a way to modify a container. Btw, is there a way to have

an empty container and use an output range to fill it? I didn't look
at std.container for quite some time.


No, but this may be an interesting idea to pursue.


Andrei

Re: How to do Generic Programming in D?

[Jason House]

Nick Wrote:

> Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how 
> to implement many of those patterns in D?
> 
> In C++ I would work with type lists and use lots of multiple inheritance 
> and templates to get the magic I need.

I don't have the book, but I'm sure that if you posted an example task, someone 
here (or on d.learn) would translate it using their favorite D style.


> D lacks MI, classes and delegates seem heavy (allocated on heap, with 
> one extra pointer and new for each delegate) and has instead template 
> mixins which do not create types and string mixing which create... anything.

Nick addressed some of these already.

I thought delegates were passed like a struct on the stack. The extra pointer 
in a delegate seems handy to me. It's much cleaner than what C++ does. There's 
also C-like function pointers.

You also left out "static if", compile-time function execution, and is 
expressions. They replace a lot of the required magic from C++. A lot of people 
swear by string mixins, but I use them sparingly. There's also conditional 
templates which I've never used, but look useful. 

> 
> So I am a bit lost.
> 
> I guess I am looking for some code&examples to read to "get" GP in D. A 
> bit like "Modern C++ Programming".
> 
> Of course, the basic question being: is D2 sufficient to support 
> everything that is possible in C++?
> 
> Thanks!

Re: How to do Generic Programming in D?

[bearophile]

Nick:

> Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how 
> to implement many of those patterns in D?

Those code patterns come from many years of C++ practice from lot of C++ 
programmers. D2 is not so old and so used, so probably some of the idioms of D2 
are yet to be invented :-)

 
> In C++ I would work with type lists and use lots of multiple inheritance 
> and templates to get the magic I need.

In D there are templates and TypeTuples, etc.


> D lacks MI, classes and delegates seem heavy (allocated on heap, with 
> one extra pointer and new for each delegate) and has instead template 
> mixins which do not create types and string mixing which create... anything.

D also has not-closure delegates (using scope, sometimes it works), function 
pointers, etc.


> So I am a bit lost.

D shares some things with C++, but you need to learn to use new idioms. When 
you go from language X to language Y there are often ways to implement the same 
algorithm Y too, but you need Y-specific idioms to do it. I suggest you to read 
the online D documentation and then Phobos code.


> Of course, the basic question being: is D2 sufficient to support 
> everything that is possible in C++?

Who knows. The answer is probably positive, but you need some creativity.

Bye,
bearophile

Re: Uh... destructors?

[bearophile]

Steven Schveighoffer:

> Freeing and allocating memory is fair game for pure functions.

Allocating arrays and objects is possible in pure D functions, despite the 
memory pointers they contain (like the ptr of a returned array) are different 
across different calls. This makes those function only formally pure and 
requires care from both the programmer and the optimizations done by the 
compiler, to avoid some bad bugs :-)

Example: the C calloc() function is not considered pure, despite what it does 
is not so far from a pure D function that allocates and returns a dynamic array 
of ubytes:

import core.stdc.stdlib: calloc;

// OK
pure ubyte* foo1(int n) {
auto a = new ubyte[n];
return a.ptr;
}

// Error: pure function 'foo2' cannot call impure function 'calloc'
pure ubyte* foo2(int n) {
return cast(ubyte*)calloc(n, 1);
}

void main() {}


Regarding freeing memory in pure functions, I am even less sure.
 

> On closing a file, you couldn't close that file unless the function to  
> close it was marked pure.  I would *hope* that the C call to close a file  
> was not marked as pure.

Changing the state of a file is definitively a not pure operation, even for the 
quite relaxed standards of purity of D :-)

Bye,
bearophile

Re: Uh... destructors?

[Jonathan M Davis]

On Tuesday, February 22, 2011 12:48:42 %u wrote:
> > D pure functions are significantly different than this definition
> 
> (as of recent times, when weak-pure was added).
> 
> > Essentially, a pure function cannot access global variables.
> 
> However, it can access variables referred to via a member of the
> object instance.
> 
> > i.e. this is a valid pure function:
> class C
> {
>int x;
>pure void foo() { x++; }
> }
> 
> I... did not know that. But even in that case, pure wouldn't make much
> sense, because doing anything like freeing memory or closing a file
> handle affects global variables (whether directly in the runtime or
> indirectly in the OS)... right?

Except that newing something up is pure. pure is used in D to allow for 
optimizations. That and being able to say that a function doesn't access 
globals 
are pretty much the only real reasons for its existence, I think. A pure 
function does not allow any access to mutable global variables (and it may or 
may not presently allow access to immutable global variables - I don't remember 
- but it could). A strongly pure function (a pure function whose parameters are 
all immutable or implicitly convertible to immutable) can have multiple calls 
to 
it with the same values optimized out. A weakly pure function (a pure function 
which is not strongly pure) can't be optimized out, but it _can_ be called from 
a strongly pure function - unlike non-pure functions.

Constructors and destructors are funny cases, since they mess with memory, but 
you have to be able to make them pure (or at least you have to be able to make 
constructors pure) or you can't allocate anything in a pure function You can't 
optimize them out, but they _are_ designed such that you can call them from 
pure 
functions if they're pure. So, it would really only matter whether a destructor 
were pure if you called it from a pure function, and you don't normally call 
destructors. So, I don't think that there's necessarily anything wrong with 
marking a destructor as pure, but I'm not sure that there's necessarily much 
point to it either.

- Jonathan M Davis

Re: We need to rethink remove in std.container

[Philippe Sigaud]

On Tue, Feb 22, 2011 at 15:23, Andrei Alexandrescu
 wrote:

> auto singletonRange(T)(T element)
> {
>    static struct Result
>    {
>        private T _element;
>        private bool _done;
>        @property bool empty() { return _done; }
>        @property auto front() { assert(!empty); return _element; }
>        void popFront() { assert(!empty); _done = true; }
>        auto save() { return this; }
>    }
>
>    return Result(element, false);
> }

That's also what many people would like a findFirst function to
return. Either a 1-element range with the found value or an empty
range if the value doesn't exist.

auto v = findFirst(range, needle);
if (!v.empty) { ... }


Maybe you could allow for the creation of an empty output
singletonRange where a lone value could then be put.
auto singleton(T)() { ... } but the user would need to provide the 'T'
by himself.
and then:

void put(T element) {assert(empty); _element = element;}

That could be a way to modify a container. Btw, is there a way to have
an empty container and use an output range to fill it? I didn't look
at std.container for quite some time.

Re: CMake for D2 ready for testers

[Jens Mueller]

David Nadlinger wrote:
> On 2/22/11 6:10 PM, Jens Mueller wrote:
> >I also wanted to test it on Mac OS X but unfortunately I do not have
> >access to a Mac.
> 
> I don't have lots of time for experiments at the moment, but I'd be
> glad to help you out if you just need someone to run an existing set
> of tests on OS X or something.

That would be great.
I want to fix issue
http://code.google.com/p/cmaked2/issues/detail?id=8
For this you need to install CMake. There is a Universal Mac OSX Binary
available at http://www.cmake.org/cmake/resources/software.html
And then you can follow
http://code.google.com/p/cmaked2/wiki/GettingStarted to install CMakeD.
Then update the issue or send me the failing output. I hope it works
out.

Jens

Re: Uh... destructors?

[Steven Schveighoffer]

On Tue, 22 Feb 2011 15:48:42 -0500, %u  wrote:


D pure functions are significantly different than this definition

(as of recent times, when weak-pure was added).

Essentially, a pure function cannot access global variables.

However, it can access variables referred to via a member of the
object instance.

i.e. this is a valid pure function:

class C
{
   int x;
   pure void foo() { x++; }
}

I... did not know that. But even in that case, pure wouldn't make much
sense, because doing anything like freeing memory or closing a file
handle affects global variables (whether directly in the runtime or
indirectly in the OS)... right?


Freeing and allocating memory is fair game for pure functions.  It is one  
of the only exceptions to the rule, because without the ability to  
allocate and free memory, functional programming is quite limited.


On closing a file, you couldn't close that file unless the function to  
close it was marked pure.  I would *hope* that the C call to close a file  
was not marked as pure.


I wasn't advocating that destructors can be pure, I was just pointing out  
that the concept of pure has changed in recent times.


-Steve

Re: Uh... destructors?

[%u]

> D pure functions are significantly different than this definition
(as of recent times, when weak-pure was added).
> Essentially, a pure function cannot access global variables.
However, it can access variables referred to via a member of the
object instance.
> i.e. this is a valid pure function:
class C
{
   int x;
   pure void foo() { x++; }
}

I... did not know that. But even in that case, pure wouldn't make much
sense, because doing anything like freeing memory or closing a file
handle affects global variables (whether directly in the runtime or
indirectly in the OS)... right?

Re: CMake for D2 ready for testers

[Gour]

On Tue, 22 Feb 2011 18:10:11 +0100
Jens Mueller  wrote:

> Yeah. My point is just that I don't know whether CMake will be the way
> to go. I mean it works but there are more elegant build tools in the
> pipeline. That's why I push it only as far as it needs to be.

Well, other, 'more elegant tools' are still immature, small userbase,
not so many devs. On top of that, it's not certain on how many
platforms they work, while seeing something like

http://www.cdash.org/CDash/index.php?project=CMake

is definitely impressive for me.

> That would be very nice.
> So far we have quite decent support for
> * dmd (tested on Linux/Windows)
> * gdc (tested on Linux)

Cool. Soon, when I install (free)pcbsd, I can test on it.


Sincerely,
Gour

-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

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




signature.asc
Description: PGP signature

Re: How to do Generic Programming in D?

[Nick Sabalausky]

"Nick"  wrote in message 
news:ik11ot$2fms$1...@digitalmars.com...
> Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how to 
> implement many of those patterns in D?
>
> In C++ I would work with type lists and use lots of multiple inheritance 
> and templates to get the magic I need.
>

I abandoned C++ about 10 years ago so I don't know anything about the 
patterns you're talking about, but:

> D lacks MI,

Replaced by either mixins or interfaces, depending on what you're trying to 
do.

> classes and delegates seem heavy (allocated on heap, with one extra 
> pointer and new for each delegate)

IIRC, non-heap-based value-semantics classes are kind of rare in C++. If you 
want a value-semantics "class" in D, you use a struct. You give up the 
ability to subclass, but I've heard there are major problems combining 
inheritence with value-semantics even in C++ anyway.

> I guess I am looking for some code&examples to read to "get" GP in D. A 
> bit like "Modern C++ Programming".
>

If by "GP" you mean generic programming, then the primary mechanisms for 
that in D are CTFE (compile-time function execution), templates and 
string/template mixins.

Re: Uh... destructors?

[Steven Schveighoffer]

On Tue, 22 Feb 2011 14:31:30 -0500, %u  wrote:


I just visited Wikipedia (savior of the day) and a quick look at
this article:
http://en.wikipedia.org/wiki/Pure_function

yields the following requirements for a pure function:

1. The function always evaluates the same result value given the
same argument value(s). The function result value cannot depend on
any hidden information or state that may change as program execution
proceeds or between different executions of the program, nor can it
depend on any external input from I/O devices.

2. Evaluation of the result does not cause any semantically
observable side effect or output, such as mutation of mutable
objects or output to I/O devices.

"pure" destructors always fail the first test, because they clearly
cause a state change for the current object, if not for a global
resource like memory. Pure functions need to be timeless and can be
freely reordered; a destructor call, however, is not timeless -- it
depends on the current state of the object, and the changes it makes
are visible to the outside world.

They also usually fail the second test, because if, for example, we
flush a file inside a destructor, that clearly has an observable
output... so I can't see why a destructor would ever be pure.


D pure functions are significantly different than this definition (as of  
recent times, when weak-pure was added).


Essentially, a pure function cannot access global variables.  However, it  
can access variables referred to via a member of the object instance.


i.e. this is a valid pure function:

class C
{
  int x;
  pure void foo() { x++; }
}

-Steve

Re: Uh... destructors?

[%u]

I just visited Wikipedia (savior of the day) and a quick look at
this article:
http://en.wikipedia.org/wiki/Pure_function

yields the following requirements for a pure function:

1. The function always evaluates the same result value given the
same argument value(s). The function result value cannot depend on
any hidden information or state that may change as program execution
proceeds or between different executions of the program, nor can it
depend on any external input from I/O devices.

2. Evaluation of the result does not cause any semantically
observable side effect or output, such as mutation of mutable
objects or output to I/O devices.

"pure" destructors always fail the first test, because they clearly
cause a state change for the current object, if not for a global
resource like memory. Pure functions need to be timeless and can be
freely reordered; a destructor call, however, is not timeless -- it
depends on the current state of the object, and the changes it makes
are visible to the outside world.

They also usually fail the second test, because if, for example, we
flush a file inside a destructor, that clearly has an observable
output... so I can't see why a destructor would ever be pure.

Re: Uh... destructors?

[%u]

> What's the problem with a pure destructor? It only means you can't access 
> global variables.
If the object holds a pointer to somewhere, you can still affect that somewhere.

> In fact, if your struct's destructor isn't pure, how can you use it as local 
> variable inside
of a pure function?

The problem is that a pure destructor makes no sense because "pure" means that 
a function has
no side effects. So anything that a pure function does would need to be 
strictly reflected only
in its output, and in nothing else... and yet, a destructor has no output (and 
no input
either), so it's logically not allowed to perform any action with side 
effects... in other
words, it can't do _anything_, just like in functional programming.

Unless I'm misunderstanding the meaning of "pure", I don't see how a destructor 
marked as
"pure" would be meaningful. (The same reason applies to const.)

Re: Linking COFF and OMF

[%u]

> What does _xi_a even do? Is it anything more than just a marker
> inside the executable?

> have you seen this page:
http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ?
> I think dmc is pretty much in line with it. You can also find these
sections in the map files generated when compiling a D file with dmd.

:O no, I hadn't! That's great information; thanks!

Re: Linking COFF and OMF

[Rainer Schuetze]

%u wrote:

What does _xi_a even do? Is it anything more than just a marker
inside the executable?


have you seen this page: http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ?
I think dmc is pretty much in line with it. You can also find these 
sections in the map files generated when compiling a D file with dmd.

How to do Generic Programming in D?

[Nick]

Coming from Andrei's work in C++ "Modern C++ Programming" I wonder how 
to implement many of those patterns in D?


In C++ I would work with type lists and use lots of multiple inheritance 
and templates to get the magic I need.


D lacks MI, classes and delegates seem heavy (allocated on heap, with 
one extra pointer and new for each delegate) and has instead template 
mixins which do not create types and string mixing which create... anything.


So I am a bit lost.

I guess I am looking for some code&examples to read to "get" GP in D. A 
bit like "Modern C++ Programming".


Of course, the basic question being: is D2 sufficient to support 
everything that is possible in C++?


Thanks!

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 08:58:04 -0500, Steven Schveighoffer  
 wrote:



So essentially, your code would look like this in dcollections:

auto arr = new ArrayList!int(1,2,3,4,5);

auto cursor = arr.find(3);

int[] before = arr[0..cursor];
int value = arr[cursor];



Actually, I haven't used dcollections (or much d code) in so long, I  
forgot the cursor's main function!


int value = cursor.front;

That looks better ;)

-Steve

Re: CMake for D2 ready for testers

[David Nadlinger]

On 2/22/11 6:10 PM, Jens Mueller wrote:

I also wanted to test it on Mac OS X but unfortunately I do not have
access to a Mac.


I don't have lots of time for experiments at the moment, but I'd be glad 
to help you out if you just need someone to run an existing set of tests 
on OS X or something.


David

Re: Uh... destructors?

[Michel Fortin]

On 2011-02-22 13:15:03 -0500, %u  said:


So okay, fine... 2 out of about 8. That still doesn't mean the rest
of them should be allowed, though... think about how confusing code
with a "pure" destructor would be.


What's the problem with a pure destructor? It only means you can't 
access global variables. If the object holds a pointer to somewhere, 
you can still affect that somewhere.


In fact, if your struct's destructor isn't pure, how can you use it as 
a local variable inside of a pure function?


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: We need to rethink remove in std.container

[Jonathan M Davis]

On Tuesday, February 22, 2011 05:01:24 Andrei Alexandrescu wrote:
> On 2/21/11 8:55 PM, Jonathan M Davis wrote:
> > Okay, removing elements from a container sucks right now. You can do
> > stuff like removeAny (generally pretty useless IMHO) or removeFront just
> > fine, but removing an arbitrary range from a container just plain sucks.
> > 
> > remove takes a range type which is the range type for the container that
> > it's on. That makes sense. It's obviously not going to be able to a take
> > an arbitrary range and remove that from itself. How would it know which
> > elements in that range corresponded to which elements in itself -
> > especially when it could be a range which skips elements or something
> > similar? So, _that_ part makes sense.
> > 
> > But have you actually tried to get a range of the appropriate type to
> > remove from a container? It seems like almost ever function in std.range
> > and std.algorithm returns a new range type, making them completely
> > useless for processing a range to be removed from a container.
> > 
> > I was looking to remove a single element for a RedBlackTree. The best
> > function that I could think to get the proper range was findSplit. The
> > middle portion of the return value would be the portion that I was
> > looking for. I'd take that and pass it to RedBlackTree's remove. Wrong.
> > It uses takeExactly in its implementation and the first two portions of
> > the result of findSplit aren't the right range type.
> 
> It's good that positioned remove does not work with findSplit. It would
> be inefficient to use the wonderfully structured tree for linear search.
> The algorithm should be simple - find the key to delete in O(log n),
> then remove it.

Well, if RedBlackTree's remove gets changed to take the return values from take 
and takeExactly as you suggest below, then it _will_ work. Regardless, I don't 
think that findSplit is the best choice for this situation. It's just the best 
that I could think of given that take and takeExactly didn't work. I was then 
frustrated to discover that findSplit used takeExactly (though thinking about 
it 
now, given how forward ranges work, it's not like it could really do 
otherwise). 
removeKey is really what RedBlackTree needs for the most part, however. 
Removing 
a range from a RedBlackTree definitely makes sense in some cases, but usually 
you're looking to remove a particular element or set of elements which aren't 
necessarily in any specific order or adjacent in the tree (which implies that 
perhaps we need a removeKey(s) which takes a range of values - though not 
necessarily a range from RedBlackTree).

> > So, what do I do? The _only_ thing that I can think of at the moment is
> > to use find to locate the beginning of the range that I want, take the
> > length of the range with walkLength and then use popBackN to pop of the
> > elements I don't want.
> 
> [snip]
> 
> What we need to do is add to RedBlackTree a function that accepts the
> result of take() - the same way SList does. It has only recently dawned
> on me that certain generic ranges are pivotal to algorithms and
> containers, and so far I identified take() and takeExactly() to be two
> such important ranges.
> 
> One other thing that we can add to RedBlackTree is a simple removeKey()
> convenience method that does the find-and-remove thing. Any Phobos
> developer (including JMD of course :o)), please feel free to implement
> all of the above and submit it for pulling. And thanks Jonathan for
> using std.container - I am sure there are a few other wrinkles that will
> be revealed and then ironed out following consistent usage.

In this case, it probably makes sense to let Steve take care of it, since he's 
already working on it, though I may just add removeKey and submit a pull 
request 
which Steven can deal with as he sees appropriate, so that I can use it for 
what 
I'm doing.

However, having found a fundamental flaw in how remove currently works with 
RedBlackTree, I thought it best to discuss how to solve the problem before 
making any changes to it anyway. Regardless, RedBlackTree is the container that 
I've been most missing in what I've been doing in D, so I'll definitely be 
using 
it in code now that I have it.

By the way, are we looking at changing the containers to be classes by the next 
release (since, as I recall, you decided that we're definitely making that 
change)? That's one change that RedBlackTree could definitely benefit from 
(since 
you have to run one of its destructors for it to be set up correctly and it 
can't have a default constructor as a struct), and it's probably the sort of 
change that we should make sooner rather than later, since the longer that the 
types in std.container are structs, the more code it will break when they 
become 
classes.

- Jonathan M Davis

Re: Uh... destructors?

[%u]

>> Well, the trouble is, pretty much all of these are invalid
attributes:
>> - static obviously makes no sense
> And here is where you're wrong. You have defined a static
destructor, which is called with module destructor as the program
goes out of scope, rather than when your struct or class is
destroyed.

Oops... I knew that, but I totally forgot about it when I wrote
this; good catch.

So okay, fine... 2 out of about 8. That still doesn't mean the rest
of them should be allowed, though... think about how confusing code
with a "pure" destructor would be.

Re: Ranges and Algorithms -- Templates, Delegates, or Ranges?

[%u]

> Indeed. The solution to OP's problem is std.algorithm.map. Local
instantiation should take care of aliases that refer to local
symbols, so OP's original complaint about std.algorithm.map is
invalid (albeit for a subtle reason). The following code compiles as
expected:
import std.algorithm, std.stdio;
auto fun(int[] a)
{
 auto y = 3;
 auto m = map!((x) { return x < y; })(a);
 return m;
}
void main()
{
 auto a = [ 1, 2, 3, 4, 5 ];
 auto m = fun(a);
 writeln(m);
}
> Note how map's lambda refers to a symbol local to fun.


I... didn't know that works. Wow! And it also seems to work with
function pointers too. :)
D amazes me every day. :D

Thanks for making such a great language guys!!

Re: CMake for D2 ready for testers

[Jens Mueller]

Jens Mueller wrote:
> Gour wrote:
> > On Tue, 22 Feb 2011 15:33:48 +0100
> > Jens Mueller  wrote:
> > 
> > > Further I have the impression that nobody really cares. I mean there
> > > _many_ viable ways to have better configuration/build support for D.
> > 
> > Don't be discouraged...think about the future - having good build
> > support is something like having vim/emacs editing-mode and (many)
> > users simply expect to find one in the ecosystem of every serious
> > language.
> 
> Yeah. My point is just that I don't know whether CMake will be the way
> to go. I mean it works but there are more elegant build tools in the
> pipeline. That's why I push it only as far as it needs to be.
> 
> > I'll try to help as soon as I become somewhat (more) familiar with
> > Cmake and its 'language'.
> 
> That would be very nice.
> So far we have quite decent support for
> * dmd (tested on Linux/Windows)
> * gdc (tested on Linux)
> 
> Linking shared libraries on Linux using the C linker is also nice to
> have. This way you can use your favorite third-party C library in D.

I shouldn't have said nice to have. Because it sounds as if we want it
but don't have it. It is already available thus allowing you to link
with shared libraries.

Jens

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Tue, 22 Feb 2011 15:33:48 +0100
> Jens Mueller  wrote:
> 
> > Further I have the impression that nobody really cares. I mean there
> > _many_ viable ways to have better configuration/build support for D.
> 
> Don't be discouraged...think about the future - having good build
> support is something like having vim/emacs editing-mode and (many)
> users simply expect to find one in the ecosystem of every serious
> language.

Yeah. My point is just that I don't know whether CMake will be the way
to go. I mean it works but there are more elegant build tools in the
pipeline. That's why I push it only as far as it needs to be.

> I'll try to help as soon as I become somewhat (more) familiar with
> Cmake and its 'language'.

That would be very nice.
So far we have quite decent support for
* dmd (tested on Linux/Windows)
* gdc (tested on Linux)

Linking shared libraries on Linux using the C linker is also nice to
have. This way you can use your favorite third-party C library in D.

I also wanted to test it on Mac OS X but unfortunately I do not have
access to a Mac. Looking into ldc may be also worthwhile. I did to a
certain degree. But I never got a simple program to link.

Jens

Re: CMake for D2 ready for testers

[Gour]

On Tue, 22 Feb 2011 15:33:48 +0100
Jens Mueller  wrote:

> I mainly push it as far as I need it because writing CMake code is no
> fun for me (and I do it in my free time). 

Thank you.

> Further I have the impression that nobody really cares. I mean there
> _many_ viable ways to have better configuration/build support for D.

Don't be discouraged...think about the future - having good build
support is something like having vim/emacs editing-mode and (many)
users simply expect to find one in the ecosystem of every serious
language.

I'll try to help as soon as I become somewhat (more) familiar with
Cmake and its 'language'.


Sincerely,
Gour

-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

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




signature.asc
Description: PGP signature

Re: We need to rethink remove in std.container

[spir]

On 02/22/2011 03:13 PM, Steven Schveighoffer wrote:

I wonder if there is a way we could generalize "give me the
implementation-specific representation of the first item *reference*"


If this means a generalisation of what D's builtin 'in' provides, then I think 
this would be great. Then, passing back the 'reference' would provide _direct_ 
access (without [new] lookup) either to read, remove, change... Can't we unify 
this with your notion of cursor? What do you think?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: D3 plans

[Adam Ruppe]

I say we can put out D3 about the time Linux puts out kernel 2.8.

Re: D3 plans

[Andrej Mitrovic]

No need to feed the troll. :)

Re: [OT] Round 2: Webpage design and "Name That Color!"

[Andrej Mitrovic]

IIRC there was a website where you could get two nicely matching
colors for background+foreground by selecting just one color first.
I've no idea where exactly I saw that though.

Re: D3 plans

[Trass3r]

> A legitimate question - where are the D3 plans?
One step at a time. We just got x64 support on Linux, Windows is still far away 
from that. Shared libraries is the next big issue. Proper implementation of 
D2's features is also still ahead.

> Any language not in active development (no don't mean phobos, not toolchain) 
> is dead.
A language with a thousand cool but half- or unimplemented features is of no 
use either, not to mention the role of development tools.

> D2 has little potential without AST macros.
D (the language, ignoring implementation quirks here) is already far ahead of 
many another language, especially in terms of metaprogramming. Even D1 brings 
substantial productivity gains compared to C++. Naturally there's plenty of 
room for improvements but I wouldn't call it having little potential.

Re: D3 plans

[Andrei Alexandrescu]

On 2/22/11 9:00 AM, phobophile wrote:

A legitimate question - where are the D3 plans? Any language not in active 
development (no don't mean phobos, not toolchain) is dead. D2 has little 
potential without AST macros. I want to participate in D3 development. Maybe 
bearophile could lead the process this time?


flamebait alert?

Andrei

Re: [OT] Round 2: Webpage design and "Name That Color!"

[spir]

On 02/22/2011 03:22 AM, Nick Sabalausky wrote:

"Nick Sabalausky"  wrote in message
news:ijpvpl$2l8u$1...@digitalmars.com...

I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
CSS a bit. And, well, I think I've stumbled upon a heisencolor...(or a
heisenhue, rather)

Without reading any replies or "cheating" by inspecting the pixels in a
paint program, take a look at this screenshot:

http://www.semitwist.com/download/goldie0.4docBeta.png

...and reply with what color you think the background looks like (the main
background, not the
sidebar). And whether or not you like it would be helpful, too, of course.
And, strange as this may sound, reply again if you end up changing your
mind on what color it looks like.



Thanks all for the comments! I've made a few more tweaks, put up two sample
pages, and would like to get some opinions on if this now looks "good" or
"acceptable" or "bad" (and maybe improvement suggestions for any "bad"
votes):

http://www.semitwist.com/goldie0.4docBeta2/index.html
http://www.semitwist.com/goldie0.4docBeta2/SampleApps/ParseAnything/index.html

(Most of the links are broken ATM, I know. And FWIW, "beige" is what I was
trying to go for with the background.)

FWIW, the old v0.3 documentation is here:

http://www.semitwist.com/goldiedocs/current/Docs/

I want to at least make sure that the 0.4 docs are an improvement on that.


[Nick: I think you'd rather provide a valid email and ask people to reply off 
list. Would be much nicer, I guess. You can write it down like "nick  site 
 org" to avoid spam bots.]


I think the intention is good, IIUC, but the choice of colors is not.
There are rules and tricks to choose and "marry" colors but it's a big & 
difficult domain in any case (it's about impossible if you use a color chooser 
based on HSV instead of HSL, for some reasons.) And there are indeed questions 
of taste.


Just as an example:
* main background color less sad (hue=44): #FCE6A9 (or even more rose, hue=33: 
#FCD7A9)

* darken it (L component) for side bar color: #E0CD96
* intensify it (S component) for frame bg color: #FFE28F
The contrasts are rather slight, close to minimal; do your own trials.
You can also play with main foreground color, giving it the same hue (instead 
of absolute black): eg #383019. I like to also use a color that constrasts with 
the hue used everywhere else, for instance for titles and/or frame borders: eg 
#1F3832.


Denis

PS: example using such color choosing principles: http://spir.wikidot.com/
--
_
vita es estrany
spir.wikidot.com

Re: Uh... destructors?

[Robert Jacques]

On Tue, 22 Feb 2011 01:08:38 -0500, %u  wrote:

dmd is pretty lax about attributes which don't apply. It generally just  
ignores them. Personally,
I think that it should error on invalid attributes, but for some reason,  
that's not how it works.
Of course, there could be other bugs in play here, but there's every  
possibility that the end

result is completely valid.

Well, the trouble is, pretty much all of these are invalid attributes:
- const and pure make no sense, since destructors (should) change an  
object's state


const is perfectly valid; From one perspective, you're rarely changing the  
actual object state, just free-ing allocated resources. From another, you  
might be logging something and don't want to accidentally change a value.


pure, especially weak purity, is expected from most destructors (and  
functions for that matter). And given that destructors should be able to  
be run on a GC thread, disabling access to TLS variables is perfectly  
valid.


Now, put the two together and you do end up with your hands mostly tied,  
but asserts are still valid as is (IIRC) freeing memory.


- override and final make no sense, since destructors obviously aren't  
ever overridden... they're

always called after the subclass's destructor is called


Regarding override, all class destructors are implicitly override, in  
which case the extra modifiers make no semantic difference. But module  
destructors are not virtual, so override doesn't make sense.


Regarding final, it also makes sense for classes (i.e. preventing  
inheritance), but again module destructors are not virtual, so final  
doesn't make sense in this context.



- static obviously makes no sense


As stated by others, this is a module destructor, which are declared using  
the static keyword.


- synchronized is meaningless since there's only one thread ever running  
the destructor anyway


Well, synchronized(monitor) would make perfect sense (since module  
destructors are run whenever a thread shuts down), and as there should be  
a way to manually set/get the implicit synchronized monitor, this is valid.


- private makes no sense since (unless we're trying to imitate C++ here)  
destructors are only

called from the runtime, and nowhere else.


Well, this comes from the fact that all functions have a protection  
modifier (private,package,protected,public,etc). So it's perfectly valid  
to stick whichever one you want on it, since none of them apply and one  
must be present.

Re: Linking COFF and OMF

[Trass3r]

Sounds like a lot of fun ;)
I'm also sick of dmd's policy to mess everything up on Windows by completely 
depending on dmc and its friends while Linux users have a proper linker, libc 
and object format.
I mean wouldn't it be the easiest way to use COFF + MinGW's ld and libc since 
it's very similar to what is used on Linux?

Re: float equality

[spir]

On 02/21/2011 10:17 PM, so wrote:

If one doesn't know what floating point is and insists on using it, it is
his own responsibility to face the consequences.


I don't buy this argument.


Why not? A logical flaw on my part or the statement being somewhat harsh?
Because i don't think it is the former, i will give an example for the latter.
I am a self-taught programmer and i too made big mistakes when using FP,
probably i still do since it is a strange beast to deal with even if you know
all about it.
For this reason it is somewhat understandable for people like me failing this
kind of traps but can we say same thing for others?
Do they have this excuse? Not knowing the fundamental thing about FP and use it?


I understand your position. But I don't share it.
The problem is binary floating point representations of numbers introduce a 
little set of traps due to the fact that they are implicitely supposed to be 
the type representing "fractional" or real numbers, but they cannot do that in 
a way that matches our (widely unconscious) intuitions in the domain, 
themselves (I guess) a by-product of years of manipulation at school. The 
simple notation "1.1" comes with a huge baggage of pre-existing knowledge by 
everyone (programmers).


We should not blindly make abstraction of that fact, and put the burden on the 
users' shoulders, without even a honest trial in solving the issue.

When a programmer writes:
x = 1.1;
or
x = 1/3.0;
the meaning is just that, and refers to all this knowledge. There is in most 
cases no intention (not even implicite) to use binary floating point numbers, 
instead to have a representation for the plain arithmetics values as written 
down. Hope I'm clear. Very few people (ones that have repetedly been caught by 
the conceptual traps) will have "alarm bell" ring when writing this, and 
consequently take all appropriate precautions required to avoid subsequenty 
falling into the traps and... have buggy code.


This may be a bit different if the notation did not recall all of that 
knowledge:
x = 1.1f; // alarm bell!?

I would advocate that a general-purpose language should use a different 
representation for ordinary need of fractional/real numbers, one that does not 
introduce such traps and/or warns about them (via warnongs/errors, like 
Bearophile's proposal). One possibility may be to use fixed point with a 
/decimal/ scale factor (the mantissa beeing binary or decimal integer). Other 
possibilities: true rationals, decimal 'reals'.
The issue is indeed any of those solutions has a cost (even more with modern 
machines having native float artithmetic). But numeric computation intensive 
apps would just use floats, /explicitely/ (and hopefully correctly).


A similar issue is the one of signed <--> unsigned ints. I would just make as 
default the range of unsigned ints be a subset of signed ones. And let the full 
range available for people who really need it, to be used explicitely.


Anyway, such solutions may not be good for D, beeing (also) a systems 
programming language in the C line. Still, I think it's worth exploring the 
topic instead of letting bug-prone features silently sit at the deep core of 
the language.


Denis
--
_
vita es estrany
spir.wikidot.com

D3 plans

[phobophile]

A legitimate question - where are the D3 plans? Any language not in active 
development (no don't mean phobos, not toolchain) is dead. D2 has little 
potential without AST macros. I want to participate in D3 development. Maybe 
bearophile could lead the process this time?

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 09:23:00 -0500, Andrei Alexandrescu  
 wrote:



On 2/22/11 7:58 AM, Steven Schveighoffer wrote:

A cursor in dcollections is actually a zero or one element range. It can
only reference exactly one element. Since it has no references to other
elements, it is immune to operations that use the surrounding elements.


At this exact point I had what would be either a good idea or a  
brainfart.


I've been thinking for a good while to define a "singleton range", a  
range that has at most one element. I had the intuition that a singleton  
range is a useful concept, but I felt it was a bit tenuous to argue in  
its favor (mostly because one could easily simulate it with repeat(x,  
1)), so I never put it in std.range.


The definition would go like this:

auto singletonRange(T)(T element)
{
 static struct Result
 {
 private T _element;
 private bool _done;
 @property bool empty() { return _done; }
 @property auto front() { assert(!empty); return _element; }
 void popFront() { assert(!empty); _done = true; }
 auto save() { return this; }
 }

 return Result(element, false);
}


This is almost the same as a dcollections cursor.  The only difference is,  
popFront in a cursor not only sets the '_done' member, but also moves to  
the next element.  This distinction is necessary with node-based  
containers that have an end marker node.  So the cursor that is returned  
from 'end()' (or from find where the element was not found, etc.) is an  
already-empty cursor.


I hadn't thought of just setting the empty variable, but I think it  
wouldn't work properly.  You could possibly say "a cursor that points to  
an element but is empty is actually pointing *after* the element."  But  
then I'm not sure how to construct an end cursor.  It's advantageous to  
point at the end of a container, where there is no true node to point at.   
Is there another way to think about this?


But now I realized that singleton ranges are your cursors, so I'll  
definitely add them. And you also made me realize that a singleton range  
is very different from other ranges in the same way 1 is different from  
other numbers. Great.


Yes, that distinction is really important, I'm glad you see that!

This may as well be The Great Unification that was needed to converge  
std.container with dcollections in a harmonious whole.


I'm not sure what to think of this ;)  Is this a "oh what could have been"  
statement or a "let's reopen negotiations" statement?


Note, I would love for dcollections to be mainstream Phobos, but I have  
accepted the current reality and am fine with the way things are now too.


-Steve

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 09:38:04 -0500, Lutger Blijdestijn  
 wrote:



Steven Schveighoffer wrote:


RedBlackTree supports the equalRange function, which gives you a range  
of

elements equal to the value you give.



oo how I missed that. When you are working on RedBlackTree, would you  
please

consider putting an example in the doc that uses it to this effect?



I'm sorry you missed it, better docs is one of the planned improvements.   
Bearophile pointed out quite a few deficiencies which I need to work on.


I'll be sure to make RedBlackTree a much more usable construct by the next  
release.


-Steve

Re: We need to rethink remove in std.container

[Lutger Blijdestijn]

Steven Schveighoffer wrote:

> On Mon, 21 Feb 2011 21:55:20 -0500, Jonathan M Davis 
> wrote:
> 
>> Okay, removing elements from a container sucks right now. You can do
>> stuff like
>> removeAny (generally pretty useless IMHO) or removeFront just fine, but
>> removing
>> an arbitrary range from a container just plain sucks.
>>
>> remove takes a range type which is the range type for the container that
>> it's
>> on. That makes sense. It's obviously not going to be able to a take an
>> arbitrary
>> range and remove that from itself. How would it know which elements in
>> that
>> range corresponded to which elements in itself - especially when it
>> could be a
>> range which skips elements or something similar? So, _that_ part makes
>> sense.
>>
>> But have you actually tried to get a range of the appropriate type to
>> remove
>> from a container? It seems like almost ever function in std.range and
>> std.algorithm returns a new range type, making them completely useless
>> for
>> processing a range to be removed from a container.
>>
>> I was looking to remove a single element for a RedBlackTree. The best
>> function
>> that I could think to get the proper range was findSplit. The middle
>> portion of
>> the return value would be the portion that I was looking for. I'd take
>> that and
>> pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its
>> implementation and the first two portions of the result of findSplit
>> aren't the
>> right range type.
> 
> RedBlackTree supports the equalRange function, which gives you a range of
> elements equal to the value you give.
> 

oo how I missed that. When you are working on RedBlackTree, would you please 
consider putting an example in the doc that uses it to this effect?

Re: CMake for D2 ready for testers

[David Nadlinger]

On 2/22/11 1:32 PM, Russel Winder wrote:

Lua and Python seem, between them, to have about a 100% monopoly on the
dynamic language plugin market, at least in the media software arena.


IIRC, Naughty Dog, the people behind the Uncharted series, are using 
something like PLT Scheme, i.e. LISP, for their scripting needs (e.g. 
http://gameenginebook.com/gdc09-statescripting-uncharted2).


Nevertheless, »about 100%« is probably right.

David

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Tue, 22 Feb 2011 14:10:59 +0100
> Jens Mueller  wrote:
> 
> > Hmm. I do it like this.
> > Download CMake from the official site and install it to
> > /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed.
> > And if I configure CMakeD using my cmake it will install the files to
> > /path/to/myhome/local/where/cmake/puts/its/files.
> 
> I've asked on #cmake about the possibility to include CMakedD in the
> official release...

Thank you for asking.

> Here are some tips I got:
> 
> * "well it needs to be cleaned up more"

Definitely.

> * "as I said before the D support is not in a state that it can be accepted"

I heard that. CMakeD had so many maintainers in such a short time. I
think they already asked for it a while ago.

> * "you need to create a git branch add it"

Minor problem. I prefer git.

> * "compile cmake and it needs to pass ctest -R ModuleNotices -V...and
>   other stuff"

I do not know about these internals.

> I hope it helps and can be tailored for inclusion into release.

I mainly push it as far as I need it because writing CMake code is no
fun for me (and I do it in my free time). Further I have the impression
that nobody really cares. I mean there _many_ viable ways to have better
configuration/build support for D.

Jens

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 08:01:24 -0500, Andrei Alexandrescu  
 wrote:



On 2/21/11 8:55 PM, Jonathan M Davis wrote:
Okay, removing elements from a container sucks right now. You can do  
stuff like
removeAny (generally pretty useless IMHO) or removeFront just fine, but  
removing

an arbitrary range from a container just plain sucks.

remove takes a range type which is the range type for the container  
that it's
on. That makes sense. It's obviously not going to be able to a take an  
arbitrary
range and remove that from itself. How would it know which elements in  
that
range corresponded to which elements in itself - especially when it  
could be a
range which skips elements or something similar? So, _that_ part makes  
sense.


But have you actually tried to get a range of the appropriate type to  
remove

from a container? It seems like almost ever function in std.range and
std.algorithm returns a new range type, making them completely useless  
for

processing a range to be removed from a container.

I was looking to remove a single element for a RedBlackTree. The best  
function
that I could think to get the proper range was findSplit. The middle  
portion of
the return value would be the portion that I was looking for. I'd take  
that and

pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its
implementation and the first two portions of the result of findSplit  
aren't the

right range type.


It's good that positioned remove does not work with findSplit. It would  
be inefficient to use the wonderfully structured tree for linear search.  
The algorithm should be simple - find the key to delete in O(log n),  
then remove it.


This should be possible with equalRange.

However, there can be needs to do a linear search on a RBT if you are not  
searching for keys.  I think we definitely need take as a supported range  
in RBT (I didn't think so originally).




So, what do I do? The _only_ thing that I can think of at the moment is  
to use
find to locate the beginning of the range that I want, take the length  
of the
range with walkLength and then use popBackN to pop of the elements I  
don't want.

[snip]

What we need to do is add to RedBlackTree a function that accepts the  
result of take() - the same way SList does. It has only recently dawned  
on me that certain generic ranges are pivotal to algorithms and  
containers, and so far I identified take() and takeExactly() to be two  
such important ranges.


One other thing that we can add to RedBlackTree is a simple removeKey()  
convenience method that does the find-and-remove thing. Any Phobos  
developer (including JMD of course :o)), please feel free to implement  
all of the above and submit it for pulling. And thanks Jonathan for  
using std.container - I am sure there are a few other wrinkles that will  
be revealed and then ironed out following consistent usage.


I should be able to complete these improvements before the next release  
(excluding any quick-fix releases).  Still need to learn git though...


-Steve

Re: We need to rethink remove in std.container

[Andrei Alexandrescu]

On 2/22/11 7:58 AM, Steven Schveighoffer wrote:

A cursor in dcollections is actually a zero or one element range. It can
only reference exactly one element. Since it has no references to other
elements, it is immune to operations that use the surrounding elements.


At this exact point I had what would be either a good idea or a brainfart.

I've been thinking for a good while to define a "singleton range", a 
range that has at most one element. I had the intuition that a singleton 
range is a useful concept, but I felt it was a bit tenuous to argue in 
its favor (mostly because one could easily simulate it with repeat(x, 
1)), so I never put it in std.range.


The definition would go like this:

auto singletonRange(T)(T element)
{
static struct Result
{
private T _element;
private bool _done;
@property bool empty() { return _done; }
@property auto front() { assert(!empty); return _element; }
void popFront() { assert(!empty); _done = true; }
auto save() { return this; }
}

return Result(element, false);
}

But now I realized that singleton ranges are your cursors, so I'll 
definitely add them. And you also made me realize that a singleton range 
is very different from other ranges in the same way 1 is different from 
other numbers. Great.


This may as well be The Great Unification that was needed to converge 
std.container with dcollections in a harmonious whole.



Andrei

Re: CMake for D2 ready for testers

[Jens Mueller]

Jens Mueller wrote:
> Gour wrote:
> > On Tue, 22 Feb 2011 09:42:46 +0100
> > Gour  wrote:
> > 
> > > I installed CMakeD from the archlinux package, then pulled from the
> > > repo and tried tests suite. Here is the result:
> > 
> > Oops...forgot to run 'make test':
> > 
> > [gour@atmarama build] make test
> > Running tests...
> > Test project /home/gour/repos/cmaked2/tests/build
> > Start 1: app_1
> > 1/9 Test #1: app_1    Passed0.00 sec
> > Start 2: app_2
> > 2/9 Test #2: app_2    Passed0.00 sec
> > Start 3: app_3
> > 3/9 Test #3: app_3    Passed0.00 sec
> > Start 4: app_5
> > 4/9 Test #4: app_5    Passed0.00 sec
> > Start 5: app_4
> > 5/9 Test #5: app_4    Passed0.00 sec
> > Start 6: app_6
> > 6/9 Test #6: app_6    Passed0.00 sec
> > Start 7: app_7
> > 7/9 Test #7: app_7    Passed0.00 sec
> > Start 8: moduleB.d
> > 8/9 Test #8: moduleB.d    Passed0.05 sec
> > Start 9: moduleA.d
> > 9/9 Test #9: moduleA.d    Passed0.05 sec
> > 
> > 100% tests passed, 0 tests failed out of 9
> > 
> > Total Test time (real) =   0.28 sec
> > 
> > 
> > So, everything is fine on x86_64 (however, still using 32bit dmd2
> > waiting for new package).
> 
> If you want a 64-bit build. Change in tests/CMakeLists.txt the lines
> SET( GLOBAL_DMD_DEFS "-w -wi" )
> SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m32" )
> to
> SET( GLOBAL_DMD_DEFS "-w -wi -m64" )
> SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" )
> 
> I just did this.
> $ file app_1/app_1
> app_1/app_1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.18, not
> stripped
> 
> But something is wrong with app7 on amd64.
> 
> $ make test
> Running tests...
> Test project /home/jkm/local/build/cmaked2/tests/build
> Start 1: app_1
> 1/9 Test #1: app_1    Passed0.00 sec
> Start 2: app_2
> 2/9 Test #2: app_2    Passed0.00 sec
> Start 3: app_3
> 3/9 Test #3: app_3    Passed0.00 sec
> Start 4: app_5
> 4/9 Test #4: app_5    Passed0.00 sec
> Start 5: app_4
> 5/9 Test #5: app_4    Passed0.00 sec
> Start 6: app_6
> 6/9 Test #6: app_6    Passed0.00 sec
> Start 7: app_7
> 7/9 Test #7: app_7 ***Exception: SegFault  0.01 
> sec
> Start 8: moduleA.d
> 8/9 Test #8: moduleA.d    Passed0.15 sec
> Start 9: moduleB.d
> 9/9 Test #9: moduleB.d    Passed0.11 sec
> 
> 89% tests passed, 1 tests failed out of 9
> 
> Total Test time (real) =   0.30 sec
> 
> The following tests FAILED:
>   7 - app_7 (SEGFAULT)
> Errors while running CTest
> make: *** [test] Error 8
> 
> Somebody used CMakeD successfully with gdc and even there app_7
> segfaulted. So it appears to be a problem in app_7. If you comment out
> the timing code it works. I will look later into this.

I changed the timing code within app7 to use StopWatch. It now works.
But there are some hacks in CMakeD's test examples.
In
lib_2/CMakeLists.txt
app_5/CMakeLists.txt
the -m32 was pretty hard coded.
For building 64 bit it should be now sufficient to set
SET( GLOBAL_DMD_DEFS "-w -wi -m64" )
SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" )
For 32 Bit
SET( GLOBAL_DMD_DEFS "-w -wi" )
SET( GLOBAL_GCC_DEFS "-Wall -pedantic" )
the way it is set right now should work. But remember that you need to
specify -m32 if you want to use the C linker. Because at least with gcc
on x86-64 it defaults to link 64-bit code.
That's why the -m32 is optional for dmd since this seems to be the
default. But as said earlier this will very likely change once 64-bit is
stable.

I pushed the changes to google code. Have a try.

Jens

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Mon, 21 Feb 2011 21:55:20 -0500, Jonathan M Davis   
wrote:


Okay, removing elements from a container sucks right now. You can do  
stuff like
removeAny (generally pretty useless IMHO) or removeFront just fine, but  
removing

an arbitrary range from a container just plain sucks.

remove takes a range type which is the range type for the container that  
it's
on. That makes sense. It's obviously not going to be able to a take an  
arbitrary
range and remove that from itself. How would it know which elements in  
that
range corresponded to which elements in itself - especially when it  
could be a
range which skips elements or something similar? So, _that_ part makes  
sense.


But have you actually tried to get a range of the appropriate type to  
remove

from a container? It seems like almost ever function in std.range and
std.algorithm returns a new range type, making them completely useless  
for

processing a range to be removed from a container.

I was looking to remove a single element for a RedBlackTree. The best  
function
that I could think to get the proper range was findSplit. The middle  
portion of
the return value would be the portion that I was looking for. I'd take  
that and

pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its
implementation and the first two portions of the result of findSplit  
aren't the

right range type.


RedBlackTree supports the equalRange function, which gives you a range of  
elements equal to the value you give.


If your RedBlackTree does not support duplicate elements, then this should  
always be a 1 or zero element range, which you can then remove.


That's disgusting. All that just to remove one element? And what if the  
range
isn't bidirectional (e.g. SList)? Well, then you have no popBack, and as  
far as
I can tell, you're screwed, since you can't use either take or  
takeExactly,

because both of them return new range types.


take is supported as a range type for SList.  It is not for RedBlackTree  
because there are usually better ways to get ranges from the container.   
However, I can see reasons that take could be used.  For example, in a  
RedBlackTree implementing a map, you may want to search for the first  
element that has a particular value (O(n) complexity find).  In that case,  
you should be able to remove just one element.  This should be added as a  
bugzilla report, and I'll add the ability to do take ranges to the red  
black tree.  RBT is overdue for some improvements anyways (bearophile  
found quite a few shortfalls with it).


But I see your point in that you should really be able to construct *any*  
type of range and have it work.


I wonder if there is a way we could generalize "give me the  
implementation-specific representation of the first item *reference*"


For example, in dcollections, we have the notion of cursors.  The remove  
functions take either a cursor or a range.  However, I could possibly  
extend the range removal function to allow any range type as long as the  
begin() member gives you the correct cursor type.


-Steve

Re: Ranges and Algorithms -- Templates, Delegates, or Ranges?

[Andrei Alexandrescu]

On 2/22/11 5:15 AM, Mafi wrote:

Am 22.02.2011 11:29, schrieb %u:

Having learned functional programming in Scheme a couple months ago, I
tried my hand at using map(), reduce(), and filter() in D:

int addend = 5;
map(delegate int(int x) { return x + addend; }, iota(1, 5));

but it didn't work. It turned out that map() actually took the mapper
as its _template_ argument, not as a function argument. Not too much of
a problem, it probably seemed to be...
except that it's a critical problem. It makes map(), reduce(),
filter(), etc. to become 10x less useful, because there's no way to
change
their behavior at runtime, depending on program's state.



I did never try and so I'm unsure but shouldn't you be able to give a
delegate variable as template parameter.
std.algorithms.map's parameter is an alias parameter so it should be
able alias your variable and use it's runtime value.
If it does not work this way it's a bug IMO.

Mafi



Indeed. The solution to OP's problem is std.algorithm.map. Local 
instantiation should take care of aliases that refer to local symbols, 
so OP's original complaint about std.algorithm.map is invalid (albeit 
for a subtle reason). The following code compiles as expected:


import std.algorithm, std.stdio;

auto fun(int[] a)
{
auto y = 3;
auto m = map!((x) { return x < y; })(a);
return m;
}

void main()
{
auto a = [ 1, 2, 3, 4, 5 ];
auto m = fun(a);
writeln(m);
}

Note how map's lambda refers to a symbol local to fun.

Local instantiation, invented by Walter, is a very innovative feature - 
perhaps one of D's most innovative. When a template is instantiated with 
a local alias (as e.g. map is inside fun) it is in fact instantiated 
within the function, so it has access to its locals.


As this is a new feature and a rather subtle one, it has bugs and 
limitations. In fact the function above has a bug, it prints:


[false, false, false, false, true]

although it should print

[true, true, false, false, false]

But I'm 100% convinced this is the way to go. I just submitted a bug 
report reduced from the code above, see 
http://d.puremagic.com/issues/show_bug.cgi?id=5641.



Andrei

Re: We need to rethink remove in std.container

[Lutger Blijdestijn]

Andrei Alexandrescu wrote:

> On 2/22/11 3:04 AM, Lutger Blijdestijn wrote:
>> The table in the docs mention stableRemoveAny(v) which says "Same as
>> c.removeAny(v), but is guaranteed to not invalidate any iterators."
>>
>> Though c.removeAny(v) itself is not listed in the table nor implemented
>> in RedBlackTree, isn't this the right function for the job? (I take it v
>> stands for a value of the container, rather than a range). builtin aa's
>> also implement this function.
> 
> I don't think removeAny() works for his case because he wants to remove
> a specific element from a container. removeAny() is useful when you want
> to express "pick one element from that container in the easiest way
> possible".
> 
> Andrei

I was looking for remove(ElementType value) but this function is not listed 
anywhere in std.container. The entry for stableRemoveAny(v) references 
removeAny(v) - note the parameter - so I thought that indicated the intent 
of a function removeAny(ElementType) but it doesn't exist in the table 
either.

I assumed (mistakenly) that removeAny(v) would remove any value x where x == 
v from the container, where the choice of which would be left up to the 
container. 

Re: We need to rethink remove in std.container

[Steven Schveighoffer]

On Tue, 22 Feb 2011 03:43:25 -0500, Denis Koroskin <2kor...@gmail.com>  
wrote:




I believe remove operation is better expressed in terms of a Cursor  
(iterator in C++). It also doesn't make much sense (at least of me) for  
a find to return a subrange of the source range. While it does  
generalize well, it's not really what most people expect.


What I'd love to have instead is something like this:

int[] arr = [1, 2, 3, 4, 5];
auto cursor = arr.find(3); // either points to 3 or null

int[] before = arr[0..cursor];
int value = arr[cursor]; // for consistency, C++ uses *cursor
int[] after = arr[arr.advance(cursor)..$];


This is exactly how dcollections works.

Note that typeof(cursor) could/should actually be int*, but I don't use  
arr[cursor+1..$] because cursor doesn't know about range bounds, and as  
such it can't advance on it's own.


Here is how dcollections solves this.

A cursor in dcollections is actually a zero or one element range.  It can  
only reference exactly one element.  Since it has no references to other  
elements, it is immune to operations that use the surrounding elements.   
In contrast, a red black tree range contains references to the begin and  
the end node.  This means operations on these nodes (i.e. removing the end  
node, or inserting an element between the two) can affect the range.


So essentially, your code would look like this in dcollections:

auto arr = new ArrayList!int(1,2,3,4,5);

auto cursor = arr.find(3);

int[] before = arr[0..cursor];
int value = arr[cursor];
cursor.popFront();
int[] after = arr[cursor..arr.end]; // note, $ overrides don't currently  
work, so we can't get the sugar here...


I think it's also worth noting that "find" for trees makes even less  
sense (to me). You can't "slice" a tree arbitrarily, yet find tries to  
do that:



auto rbt = RedBlackTree!int([0, 2, 5, 12, 59, 22]);
assert(to!string(rbt[]) == "[0, 2, 5, 12, 22, 59]");

auto found = find(rbt[], 5);
assert(to!string(found) == "[5, 12, 22, 59]");


What is the type of "found"? It's clearly not a tree anymore. Don't know  
why, but it's still a range. How is it implemented? Without looking at  
the source I can tell it's implemented as an original tree + a cursor.  
And I believe the two are better be separated.


Actually, find is probably not the correct thing to use for this.  Use  
upperBound (or lowerBound, I can never remember which one does what) to  
get all the elements >= 5.


The range is not a tree, and this is intentional.  Containers are *not*  
ranges.  Think of a range as a 'view' into a container, but not a  
container itself.  You can't add/remove elements from the tree using a  
range, you can just traverse it.  If it helps, think of the range as a  
pair of iterators.


-Steve

Re: We need to rethink remove in std.container

[Lutger Blijdestijn]

Jonathan M Davis wrote:

> On Tuesday 22 February 2011 03:52:34 Lutger Blijdestijn wrote:
>> Jonathan M Davis wrote:
>> > On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote:
>> >> Jonathan M Davis wrote:
>> >> > Okay, removing elements from a container sucks right now. You can do
>> >> > stuff like removeAny (generally pretty useless IMHO) or removeFront
>> >> > just fine, but removing an arbitrary range from a container just
>> >> > plain sucks.
>> >> > 
>> >> > remove takes a range type which is the range type for the container
>> >> > that it's on. That makes sense. It's obviously not going to be able
>> >> > to a take an arbitrary range and remove that from itself. How would
>> >> > it know which elements in that range corresponded to which elements
>> >> > in itself - especially when it could be a range which skips elements
>> >> > or something similar? So, _that_ part makes sense.
>> >> 
>> >> I don't understand why not. Given, as you said, that a lot of
>> >> functions return a new type it would make sense. My answer as to how
>> >> would be something like:
>> >> 
>> >> while range not empty
>> >> 
>> >> container.remove range.front
>> >> range.popFront
>> >> 
>> >> Is there a problem with that?
>> > 
>> > It's horribly inefficient for one. Also, I'm not sure that the range is
>> > valid any more after the remove, since it's front was removed. popFront
>> > may not work correctly.
>> 
>> It's a matter of range (in)validation right? I admit at this point I'm
>> not sure how it is supposed to work. remove + popFront is a bad idea if
>> the range is a view into the contained from where stuff is removed, but
>> in c++ this works for map: some_map.erase(i++) where i is an iterator. So
>> it depends on the type of container what is supported I think. But
>> perhaps this falls under Walter's category of useless wankery, since it
>> is easy to write yourself.
> 
> It depends on the implementation. It's possible that iterating an iterator
> or popping the front of a range where that iterator no longer points to a
> valid element actually works. It's also possible that, because it no
> longer points to a valid element, it _doesn't_ work. It wouldn't surprise
> me at all that some_map.erase(i++) isn't guaranteed to work in C++ at all
> but that you've just gotten lucky with the STL implementation that you've
> been using. I'd have to research it to be sure. But my guess would be that
> you've been lucky.

I'm fairly certain this is guaranteed, but specifically tied to std::map. 
The iterator returns the old value and is incremented before erasure, which 
doesn't invalidate iterators except the one that got removed.
 
>> >> > But have you actually tried to get a range of the appropriate type
>> >> > to remove from a container? It seems like almost ever function in
>> >> > std.range and std.algorithm returns a new range type, making them
>> >> > completely useless for processing a range to be removed from a
>> >> > container.
>> >> > 
>> >> > I was looking to remove a single element for a RedBlackTree. The
>> >> > best function that I could think to get the proper range was
>> >> > findSplit. The middle portion of the return value would be the
>> >> > portion that I was looking for. I'd take that and pass it to
>> >> > RedBlackTree's remove. Wrong. It uses takeExactly in its
>> >> > implementation and the first two portions of the result of findSplit
>> >> > aren't the right range type.
>> >> > 
>> >> > So, what do I do? The _only_ thing that I can think of at the moment
>> >> > is to use find to locate the beginning of the range that I want,
>> >> > take the length of the range with walkLength and then use popBackN
>> >> > to pop of the elements I don't want. e.g.
>> >> 
>> >> The table in the docs mention stableRemoveAny(v) which says "Same as
>> >> c.removeAny(v), but is guaranteed to not invalidate any iterators."
>> >> 
>> >> Though c.removeAny(v) itself is not listed in the table nor
>> >> implemented in RedBlackTree, isn't this the right function for the
>> >> job? (I take it v stands for a value of the container, rather than a
>> >> range). builtin aa's also implement this function.
>> > 
>> > removeAny doesn't solve the problem. For starters, the table appears to
>> > be wrong in that stableRemoveAny takes a value and removeAny doesn't.
>> > So, either stableRemoveAny is supposed to not take a value or there's
>> > supposed to be another version of removeAny which takes a value, and
>> > it's missing. So, I don't know what exactly is intended with
>> > stableRemoveAny.
>> > 
>> > Regardless of that, however, remove still needs to work. It's perfectly
>> > valid to want to remove a range of elements rather than just one.
>> > 
>> > - Jonathan M Davis
>> 
>> (stable)removeAny does not solve the problem of removing ranges, but
>> there must be *something* that solves the problem of removing one
>> element. You found one way to do it for RedBlackTree (i gave up), but if
>> I am not mistak

Re: CMake for D2 ready for testers

[Gour]

On Tue, 22 Feb 2011 14:10:59 +0100
Jens Mueller  wrote:

> Hmm. I do it like this.
> Download CMake from the official site and install it to
> /path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed.
> And if I configure CMakeD using my cmake it will install the files to
> /path/to/myhome/local/where/cmake/puts/its/files.

I've asked on #cmake about the possibility to include CMakedD in the
official release...

Here are some tips I got:

* "well it needs to be cleaned up more"
* "as I said before the D support is not in a state that it can be accepted"
* "you need to create a git branch add it"
* "compile cmake and it needs to pass ctest -R ModuleNotices -V...and
  other stuff"


I hope it helps and can be tailored for inclusion into release.


Sincerely,
Gour

-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

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




signature.asc
Description: PGP signature

Re: Uh... destructors?

[Simen Kjaeraas]

%u Wrote:
> Well, the trouble is, pretty much all of these are invalid attributes:

> - static obviously makes no sense

And here is where you're wrong. You have defined a static destructor, which is 
called with module destructor as the program goes out of scope, rather than 
when your struct or class is destroyed.

Re: We need to rethink remove in std.container

[Andrei Alexandrescu]

On 2/22/11 3:04 AM, Lutger Blijdestijn wrote:

The table in the docs mention stableRemoveAny(v) which says "Same as
c.removeAny(v), but is guaranteed to not invalidate any iterators."

Though c.removeAny(v) itself is not listed in the table nor implemented in
RedBlackTree, isn't this the right function for the job? (I take it v stands
for a value of the container, rather than a range). builtin aa's also
implement this function.


I don't think removeAny() works for his case because he wants to remove 
a specific element from a container. removeAny() is useful when you want 
to express "pick one element from that container in the easiest way 
possible".


Andrei

Re: We need to rethink remove in std.container

[Andrei Alexandrescu]

On 2/21/11 11:27 PM, Jonathan M Davis wrote:

The typical way to remove an element in the STL is to use find to find an 
element
and then erase to remove it. remove in std.container is doing the same thing.
The problem is that you can't give the result of find to remove, because instead
of a single iterator, find gives you a whole range, and you probably don't want
to remove that whole range. You generally either want to remove the first 
element
or some set of elements at the front of the range.


This is the exact insight that made me recognize take() is an essential 
range type.


Andrei

Re: CMake for D2 ready for testers

[Jens Mueller]

Russel Winder wrote:
> On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote:
> [ . . . ]
> > With CMakeD, you clone the repository, i.e.
> > $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
> > and
> > $ cd cmaked2/cmaked
> > $ mkdir build
> > $ cd build
> > $ cmake ..
> > $ make install
> > 
> > to install it. That will copy the necessary files into your CMake
> > installation.
> 
> I haven't actually tried it yet I guess I should, but wouldn't that try
> to install into the system area?  i.e. into the CMake installation.  I
> don't allow any extra installation into the system area unless it is via
> a package.

Hmm. I do it like this.
Download CMake from the official site and install it to
/path/to/myhome/local. Then I set PATH and LD_LIBRARY_PATH as needed.
And if I configure CMakeD using my cmake it will install the files to
/path/to/myhome/local/where/cmake/puts/its/files.

> > I'll guess SCons/Waf offers something more than that.
> 
> Yes :-)
> 
> What I would like to do is to have the CMakeD be usable from a location
> different from where the rest of CMake is stored.  In particular I'd
> like to use CMakeD out of the Mercurial clone I have.  Is there a notion
> of CMake search path that would allow this so as to avoid installing as
> above? 

Don't know. My feeling is no.

> > CMakeD just relies on dmd. But you're right it's a bit more complicated.
> 
> So you use DMD for compilation and linking?  Currently in the SCons D
> tool, compilation of D is handled with DMD or GDC and then linking with
> the users choice of linker (usually GCC I guess).

Yes. If you build an D executable then dmd will be used by default. I
think this is good because on Windows there may be only the dmd compiler
available.
But you can tell CMake to use C's linker.
set_target_properties(myExectable PROPERTIES LINKER_LANGUAGE C)

> > It seems that on Linux CMake has no proper way of cross building a 32
> > bit/64 bit version. That kind of cross compiling does not seems to work.
> > I would need to investigate further to find out whether it's a dmd
> > problem. Usually I think for building a 32 bit C binary you just pass
> > -m32 then the linker should search in ...lib32/. If you build a 64 bit
> > binary it should search in ...lib64/. If you don't specify anything it's
> > up to the compiler. CMake's task is just to check whether the dependent
> > library is installed. I think at the moment it does not look in
> > lib32/lib64 separately. In that sense it's support for cross compiling
> > is weak. I may be wrong here.
> 
> Is perhaps a factor that DMD is itself a 32-bit application?

I'll guess not.

> For the SCons D tool I have had to manage the -I and -L paths fairly
> directly.

Meaning you have to specify in the SCons file?

> > They also wrote in what regard CMake didn't work out for them
> > http://code.google.com/p/gyp/wiki/GypVsCMake
> > I like premake for it's readability see
> > http://industriousone.com/sample-script
> > and it's all Lua. Though I'm not sure whether I can keep two scripting
> > languages in my head. But Lua seems to be very simple.
> 
> Lua and Python seem, between them, to have about a 100% monopoly on the
> dynamic language plugin market, at least in the media software arena.

Yes. I heard Lua is heavily in the gaming industry. They use it to
extend their games with scripting capabilities. I heard that Warcraft
used it.

Jens

Re: We need to rethink remove in std.container

[Andrei Alexandrescu]

On 2/21/11 8:55 PM, Jonathan M Davis wrote:

Okay, removing elements from a container sucks right now. You can do stuff like
removeAny (generally pretty useless IMHO) or removeFront just fine, but removing
an arbitrary range from a container just plain sucks.

remove takes a range type which is the range type for the container that it's
on. That makes sense. It's obviously not going to be able to a take an arbitrary
range and remove that from itself. How would it know which elements in that
range corresponded to which elements in itself - especially when it could be a
range which skips elements or something similar? So, _that_ part makes sense.

But have you actually tried to get a range of the appropriate type to remove
from a container? It seems like almost ever function in std.range and
std.algorithm returns a new range type, making them completely useless for
processing a range to be removed from a container.

I was looking to remove a single element for a RedBlackTree. The best function
that I could think to get the proper range was findSplit. The middle portion of
the return value would be the portion that I was looking for. I'd take that and
pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its
implementation and the first two portions of the result of findSplit aren't the
right range type.


It's good that positioned remove does not work with findSplit. It would 
be inefficient to use the wonderfully structured tree for linear search. 
The algorithm should be simple - find the key to delete in O(log n), 
then remove it.



So, what do I do? The _only_ thing that I can think of at the moment is to use
find to locate the beginning of the range that I want, take the length of the
range with walkLength and then use popBackN to pop of the elements I don't want.

[snip]

What we need to do is add to RedBlackTree a function that accepts the 
result of take() - the same way SList does. It has only recently dawned 
on me that certain generic ranges are pivotal to algorithms and 
containers, and so far I identified take() and takeExactly() to be two 
such important ranges.


One other thing that we can add to RedBlackTree is a simple removeKey() 
convenience method that does the find-and-remove thing. Any Phobos 
developer (including JMD of course :o)), please feel free to implement 
all of the above and submit it for pulling. And thanks Jonathan for 
using std.container - I am sure there are a few other wrinkles that will 
be revealed and then ironed out following consistent usage.



Andrei

Re: float equality

[Mike James]

"Andrei Alexandrescu"  wrote in message 
news:ijuub9$tv5$1...@digitalmars.com...
> On 2/21/11 4:48 AM, Jonathan M Davis wrote:
>> On Monday 21 February 2011 01:55:28 Walter Bright wrote:
>>> Kevin Bealer wrote:
 1. To solve the basic problem the original poster was asking -- if you
 are working with simple decimals and arithmetic you can get completely
 accurate representations this way.  For some cases like simple 
 financial
 work this might work really well. e.g. where float would not be because
 of the slow leak of information with each operation.  (I assume real
 professional financial work is already done using a (better)
 representation.)
>>>
>>> A reasonable way to do financial work is to use longs to represent 
>>> pennies.
>>> After all, you don't have fractional cents in your accounts.
>>>
>>> Using floating point to represent money is a disaster in the making.
>>
>> Actually, depending on what you're doing, I'm not sure that you can 
>> legally
>> represent money with floating point values. As I understand it, there are 
>> definite
>> restrictions on banking software and the like with regards to that sort 
>> of thing
>> (though I don't know exactly what they are).
>
> This is a long-standing myth. I worked on Wall Street and have friends who 
> have been doing it for years. Everybody uses double.
>
> Andrei
>

Now we know who to blame for the downfall of the financial sector :-)

-=mike=- 

Re: We need to rethink remove in std.container

[Jonathan M Davis]

On Tuesday 22 February 2011 03:52:34 Lutger Blijdestijn wrote:
> Jonathan M Davis wrote:
> > On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote:
> >> Jonathan M Davis wrote:
> >> > Okay, removing elements from a container sucks right now. You can do
> >> > stuff like removeAny (generally pretty useless IMHO) or removeFront
> >> > just fine, but removing an arbitrary range from a container just plain
> >> > sucks.
> >> > 
> >> > remove takes a range type which is the range type for the container
> >> > that it's on. That makes sense. It's obviously not going to be able to
> >> > a take an arbitrary range and remove that from itself. How would it
> >> > know which elements in that range corresponded to which elements in
> >> > itself - especially when it could be a range which skips elements or
> >> > something similar? So, _that_ part makes sense.
> >> 
> >> I don't understand why not. Given, as you said, that a lot of functions
> >> return a new type it would make sense. My answer as to how would be
> >> something like:
> >> 
> >> while range not empty
> >> 
> >> container.remove range.front
> >> range.popFront
> >> 
> >> Is there a problem with that?
> > 
> > It's horribly inefficient for one. Also, I'm not sure that the range is
> > valid any more after the remove, since it's front was removed. popFront
> > may not work correctly.
> 
> It's a matter of range (in)validation right? I admit at this point I'm not
> sure how it is supposed to work. remove + popFront is a bad idea if the
> range is a view into the contained from where stuff is removed, but in c++
> this works for map: some_map.erase(i++) where i is an iterator. So it
> depends on the type of container what is supported I think. But perhaps
> this falls under Walter's category of useless wankery, since it is easy to
> write yourself.

It depends on the implementation. It's possible that iterating an iterator or 
popping the front of a range where that iterator no longer points to a valid 
element actually works. It's also possible that, because it no longer points to 
a valid element, it _doesn't_ work. It wouldn't surprise me at all that 
some_map.erase(i++) isn't guaranteed to work in C++ at all but that you've just 
gotten lucky with the STL implementation that you've been using. I'd have to 
research it to be sure. But my guess would be that you've been lucky.

> >> > But have you actually tried to get a range of the appropriate type to
> >> > remove from a container? It seems like almost ever function in
> >> > std.range and std.algorithm returns a new range type, making them
> >> > completely useless for processing a range to be removed from a
> >> > container.
> >> > 
> >> > I was looking to remove a single element for a RedBlackTree. The best
> >> > function that I could think to get the proper range was findSplit. The
> >> > middle portion of the return value would be the portion that I was
> >> > looking for. I'd take that and pass it to RedBlackTree's remove.
> >> > Wrong. It uses takeExactly in its implementation and the first two
> >> > portions of the result of findSplit aren't the right range type.
> >> > 
> >> > So, what do I do? The _only_ thing that I can think of at the moment
> >> > is to use find to locate the beginning of the range that I want, take
> >> > the length of the range with walkLength and then use popBackN to pop
> >> > of the elements I don't want. e.g.
> >> 
> >> The table in the docs mention stableRemoveAny(v) which says "Same as
> >> c.removeAny(v), but is guaranteed to not invalidate any iterators."
> >> 
> >> Though c.removeAny(v) itself is not listed in the table nor implemented
> >> in RedBlackTree, isn't this the right function for the job? (I take it v
> >> stands for a value of the container, rather than a range). builtin aa's
> >> also implement this function.
> > 
> > removeAny doesn't solve the problem. For starters, the table appears to
> > be wrong in that stableRemoveAny takes a value and removeAny doesn't.
> > So, either stableRemoveAny is supposed to not take a value or there's
> > supposed to be another version of removeAny which takes a value, and
> > it's missing. So, I don't know what exactly is intended with
> > stableRemoveAny.
> > 
> > Regardless of that, however, remove still needs to work. It's perfectly
> > valid to want to remove a range of elements rather than just one.
> > 
> > - Jonathan M Davis
> 
> (stable)removeAny does not solve the problem of removing ranges, but there
> must be *something* that solves the problem of removing one element. You
> found one way to do it for RedBlackTree (i gave up), but if I am not
> mistaken it doesn't have the right complexity and efficient removal is a
> key property of this container.

If you could just do take or takeExactly on the range you got from find and 
pass 
it to remove, then it wouldn't matter whether you wanted to remove 1 element or 
many. The only difference is the number passed to take. The problem is that 

Re: CMake for D2 ready for testers

[Russel Winder]

On Mon, 2011-02-21 at 21:22 +0100, Jens Mueller wrote:
[ . . . ]
> > Can the code comprising the D support for CMake be "packaged" up so that
> > it can be offerred to everyone direct from a DVCS repository?  SCons and
> > Waf have the tool concept to allow for this.  CMake must have something
> > analogous.  People can then make use of the D support with their CMake
> > without the necessity of it heading upstream -- though it would be good
> > for that to happen eventually.
> 
> Don't know how packaging is done in SCons/Waf.

No problem, I can handle that.  Actually I didn't mean "packaging" as in
creating a Debian/Ubuntu package, I meant more a plugin.  SCons and Waf
have the notion of tools that can be developed, and indeed, stored
separately from the core.  This is crucial for people using tools
without having permission to install things into the core. 

> With CMakeD, you clone the repository, i.e.
> $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
> and
> $ cd cmaked2/cmaked
> $ mkdir build
> $ cd build
> $ cmake ..
> $ make install
> 
> to install it. That will copy the necessary files into your CMake
> installation.

I haven't actually tried it yet I guess I should, but wouldn't that try
to install into the system area?  i.e. into the CMake installation.  I
don't allow any extra installation into the system area unless it is via
a package.

> I'll guess SCons/Waf offers something more than that.

Yes :-)

What I would like to do is to have the CMakeD be usable from a location
different from where the rest of CMake is stored.  In particular I'd
like to use CMakeD out of the Mercurial clone I have.  Is there a notion
of CMake search path that would allow this so as to avoid installing as
above? 

[ . . . ]
> Yeah. I try to help, if I can. Don't hesitate asking. Though I have to
> admit I have almost no Python skills. I like Ruby more. It pleases my
> eyes and there seems to be only enough space for one scripting language
> in my head.

Python is not the issue, it is really more about algorithms and
strategy.  If CMakeD and the SCons D tool both realize the same
comprehensive approach, I think everyone wins.

It is quite a war the Python/Ruby/Groovy/Lua one.  I tend to stick with
Python for now as it has the greatest penetration in the market -- well
except the Ruby on Rails one of course.

[ . . . ]

> CMakeD just relies on dmd. But you're right it's a bit more complicated.

So you use DMD for compilation and linking?  Currently in the SCons D
tool, compilation of D is handled with DMD or GDC and then linking with
the users choice of linker (usually GCC I guess).

> It seems that on Linux CMake has no proper way of cross building a 32
> bit/64 bit version. That kind of cross compiling does not seems to work.
> I would need to investigate further to find out whether it's a dmd
> problem. Usually I think for building a 32 bit C binary you just pass
> -m32 then the linker should search in ...lib32/. If you build a 64 bit
> binary it should search in ...lib64/. If you don't specify anything it's
> up to the compiler. CMake's task is just to check whether the dependent
> library is installed. I think at the moment it does not look in
> lib32/lib64 separately. In that sense it's support for cross compiling
> is weak. I may be wrong here.

Is perhaps a factor that DMD is itself a 32-bit application?

For the SCons D tool I have had to manage the -I and -L paths fairly
directly.

[ . . . ]

> I do not know yet. I think both of them are pretty weak regarding
> already available modules, i.e. files to find a specific dependency. Gyp
> is developed for building Chromium. They had a problem with SCons while
> migrating to it.

I didn't know that (even though perhaps I should), I will investigate.
Thanks for the tip.

> They also wrote in what regard CMake didn't work out for them
> http://code.google.com/p/gyp/wiki/GypVsCMake
> I like premake for it's readability see
> http://industriousone.com/sample-script
> and it's all Lua. Though I'm not sure whether I can keep two scripting
> languages in my head. But Lua seems to be very simple.

Lua and Python seem, between them, to have about a 100% monopoly on the
dynamic language plugin market, at least in the media software arena.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.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: Ranges and Algorithms -- Templates, Delegates, or Ranges?

[Lutger Blijdestijn]

Mafi wrote:

> Am 22.02.2011 11:29, schrieb %u:
>> Having learned functional programming in Scheme a couple months ago, I
>> tried my hand at using map(), reduce(), and filter() in D:
>>
>>  int addend = 5;
>>  map(delegate int(int x) { return x + addend; }, iota(1, 5));
>>
>> but it didn't work. It turned out that map() actually took the mapper as
>> its _template_ argument, not as a function argument. Not too much of a
>> problem, it probably seemed to be... except that it's a critical problem.
>> It makes map(), reduce(), filter(), etc. to become 10x less useful,
>> because there's no way to change their behavior at runtime, depending on
>> program's state.
>>
> 
> I did never try and so I'm unsure but shouldn't you be able to give a
> delegate variable as template parameter.
> std.algorithms.map's parameter is an alias parameter so it should be
> able alias your variable and use it's runtime value.
> If it does not work this way it's a bug IMO.
> 
> Mafi


yes it works: map!((int x) { return x + addend; })(iota(1, 5));

It's called local template instantiation iirc, and is restricted to global 
templates (which map is).

Re: CMake for D2 ready for testers

[Gour]

On Tue, 22 Feb 2011 12:07:13 +0100
Jens Mueller  wrote:

> It does work for me most of the time. I work on Linux. There is one
> neat trick if you need to link against shared libraries which isn't
> supported by dmd yet. For these cases I rely on gcc.
> E.g.
> add_executable(myDExecutable src.d)
> set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C)
> target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES})
> 
> will link myDExecutable against libraries mentioned in
> CMAKE_REQUIRED_LIBRARIES.

Cute...Still, I've to learn more about CMake...

> Yeah. I'll guess though. But since it has it's own language some
> things are really annoying to do. 

I could imagine...still cmake is meta-build system which uses
established mechanisms to do the real build.

> I think the newer systems are better in that regard. They give you a
> nicer syntax and usually a full blown scripting language.

I would say that having full scripting language on disposal might be
blessing as well as the curse. ;)

> I just pick the one that works for me right now since there will be
> a better tool later anyway.

Well, I do not like to think too much about build-system, but having
one that 'just works'. Otherwise, it is distraction only taking focus
away from the real work...In that vein I preferred using darcs as my
DVCS or now using e.g. Fossil over Git. :-)

> But I hope that the tools for configuring software stabilizes more
> and more as time goes by.

I'm also going for stability and that's why I plan to move from Linux
to free(pc)bsd soon. ;)


Sincerely,
Gour

-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

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




signature.asc
Description: PGP signature

Re: [OT] Round 2: Webpage design and "Name That Color!"

[Jacob Carlborg]

On 2011-02-22 03:22, Nick Sabalausky wrote:

"Nick Sabalausky"  wrote in message
news:ijpvpl$2l8u$1...@digitalmars.com...

I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
CSS a bit. And, well, I think I've stumbled upon a heisencolor...(or a
heisenhue, rather)

Without reading any replies or "cheating" by inspecting the pixels in a
paint program, take a look at this screenshot:

http://www.semitwist.com/download/goldie0.4docBeta.png

...and reply with what color you think the background looks like (the main
background, not the
sidebar). And whether or not you like it would be helpful, too, of course.
And, strange as this may sound, reply again if you end up changing your
mind on what color it looks like.



Thanks all for the comments! I've made a few more tweaks, put up two sample
pages, and would like to get some opinions on if this now looks "good" or
"acceptable" or "bad" (and maybe improvement suggestions for any "bad"
votes):

http://www.semitwist.com/goldie0.4docBeta2/index.html
http://www.semitwist.com/goldie0.4docBeta2/SampleApps/ParseAnything/index.html


The beige and yellow looks horrible. It would be better with just black 
on white.


--
/Jacob Carlborg

Re: CMake for D2 ready for testers

[Gour]

On Tue, 22 Feb 2011 12:10:08 +0100
Jens Mueller  wrote:

> Yeah. That looks good. I'd like to add your setup to
> http://code.google.com/p/cmaked2/wiki/TestedPlatforms
> Can please you leave a comment there?

Done.


Sincerely,
Gour

-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

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




signature.asc
Description: PGP signature

Re: We need to rethink remove in std.container

[Lutger Blijdestijn]

Jonathan M Davis wrote:

> On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote:
>> Jonathan M Davis wrote:
>> > Okay, removing elements from a container sucks right now. You can do
>> > stuff like removeAny (generally pretty useless IMHO) or removeFront
>> > just fine, but removing an arbitrary range from a container just plain
>> > sucks.
>> > 
>> > remove takes a range type which is the range type for the container
>> > that it's on. That makes sense. It's obviously not going to be able to
>> > a take an arbitrary range and remove that from itself. How would it
>> > know which elements in that range corresponded to which elements in
>> > itself - especially when it could be a range which skips elements or
>> > something similar? So, _that_ part makes sense.
>> 
>> I don't understand why not. Given, as you said, that a lot of functions
>> return a new type it would make sense. My answer as to how would be
>> something like:
>> 
>> while range not empty
>> container.remove range.front
>> range.popFront
>> 
>> Is there a problem with that?
> 
> It's horribly inefficient for one. Also, I'm not sure that the range is
> valid any more after the remove, since it's front was removed. popFront
> may not work correctly.

It's a matter of range (in)validation right? I admit at this point I'm not 
sure how it is supposed to work. remove + popFront is a bad idea if the 
range is a view into the contained from where stuff is removed, but in c++ 
this works for map: some_map.erase(i++) where i is an iterator. So it 
depends on the type of container what is supported I think. But perhaps this 
falls under Walter's category of useless wankery, since it is easy to write 
yourself.

>> > But have you actually tried to get a range of the appropriate type to
>> > remove from a container? It seems like almost ever function in
>> > std.range and std.algorithm returns a new range type, making them
>> > completely useless for processing a range to be removed from a
>> > container.
>> > 
>> > I was looking to remove a single element for a RedBlackTree. The best
>> > function that I could think to get the proper range was findSplit. The
>> > middle portion of the return value would be the portion that I was
>> > looking for. I'd take that and pass it to RedBlackTree's remove. Wrong.
>> > It uses takeExactly in its implementation and the first two portions of
>> > the result of findSplit aren't the right range type.
>> > 
>> > So, what do I do? The _only_ thing that I can think of at the moment is
>> > to use find to locate the beginning of the range that I want, take the
>> > length of the range with walkLength and then use popBackN to pop of the
>> > elements I don't want. e.g.
>> 
>> The table in the docs mention stableRemoveAny(v) which says "Same as
>> c.removeAny(v), but is guaranteed to not invalidate any iterators."
>> 
>> Though c.removeAny(v) itself is not listed in the table nor implemented
>> in RedBlackTree, isn't this the right function for the job? (I take it v
>> stands for a value of the container, rather than a range). builtin aa's
>> also implement this function.
> 
> removeAny doesn't solve the problem. For starters, the table appears to be
> wrong in that stableRemoveAny takes a value and removeAny doesn't. So,
> either stableRemoveAny is supposed to not take a value or there's supposed
> to be another version of removeAny which takes a value, and it's missing.
> So, I don't know what exactly is intended with stableRemoveAny.
> 
> Regardless of that, however, remove still needs to work. It's perfectly
> valid to want to remove a range of elements rather than just one.
> 
> - Jonathan M Davis

(stable)removeAny does not solve the problem of removing ranges, but there 
must be *something* that solves the problem of removing one element. You 
found one way to do it for RedBlackTree (i gave up), but if I am not 
mistaken it doesn't have the right complexity and efficient removal is a key 
property of this container.

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Tue, 22 Feb 2011 09:42:46 +0100
> Gour  wrote:
> 
> > I installed CMakeD from the archlinux package, then pulled from the
> > repo and tried tests suite. Here is the result:
> 
> Oops...forgot to run 'make test':
> 
> [gour@atmarama build] make test
> Running tests...
> Test project /home/gour/repos/cmaked2/tests/build
> Start 1: app_1
> 1/9 Test #1: app_1    Passed0.00 sec
> Start 2: app_2
> 2/9 Test #2: app_2    Passed0.00 sec
> Start 3: app_3
> 3/9 Test #3: app_3    Passed0.00 sec
> Start 4: app_5
> 4/9 Test #4: app_5    Passed0.00 sec
> Start 5: app_4
> 5/9 Test #5: app_4    Passed0.00 sec
> Start 6: app_6
> 6/9 Test #6: app_6    Passed0.00 sec
> Start 7: app_7
> 7/9 Test #7: app_7    Passed0.00 sec
> Start 8: moduleB.d
> 8/9 Test #8: moduleB.d    Passed0.05 sec
> Start 9: moduleA.d
> 9/9 Test #9: moduleA.d    Passed0.05 sec
> 
> 100% tests passed, 0 tests failed out of 9
> 
> Total Test time (real) =   0.28 sec
> 
> 
> So, everything is fine on x86_64 (however, still using 32bit dmd2
> waiting for new package).

If you want a 64-bit build. Change in tests/CMakeLists.txt the lines
SET( GLOBAL_DMD_DEFS "-w -wi" )
SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m32" )
to
SET( GLOBAL_DMD_DEFS "-w -wi -m64" )
SET( GLOBAL_GCC_DEFS "-Wall -pedantic -m64" )

I just did this.
$ file app_1/app_1
app_1/app_1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.18, not
stripped

But something is wrong with app7 on amd64.

$ make test
Running tests...
Test project /home/jkm/local/build/cmaked2/tests/build
Start 1: app_1
1/9 Test #1: app_1    Passed0.00 sec
Start 2: app_2
2/9 Test #2: app_2    Passed0.00 sec
Start 3: app_3
3/9 Test #3: app_3    Passed0.00 sec
Start 4: app_5
4/9 Test #4: app_5    Passed0.00 sec
Start 5: app_4
5/9 Test #5: app_4    Passed0.00 sec
Start 6: app_6
6/9 Test #6: app_6    Passed0.00 sec
Start 7: app_7
7/9 Test #7: app_7 ***Exception: SegFault  0.01 sec
Start 8: moduleA.d
8/9 Test #8: moduleA.d    Passed0.15 sec
Start 9: moduleB.d
9/9 Test #9: moduleB.d    Passed0.11 sec

89% tests passed, 1 tests failed out of 9

Total Test time (real) =   0.30 sec

The following tests FAILED:
  7 - app_7 (SEGFAULT)
Errors while running CTest
make: *** [test] Error 8

Somebody used CMakeD successfully with gdc and even there app_7
segfaulted. So it appears to be a problem in app_7. If you comment out
the timing code it works. I will look later into this.

Jens

Re: Ranges and Algorithms -- Templates, Delegates, or Ranges?

[Mafi]

Am 22.02.2011 11:29, schrieb %u:

Having learned functional programming in Scheme a couple months ago, I tried my 
hand at using map(), reduce(), and filter() in D:

 int addend = 5;
 map(delegate int(int x) { return x + addend; }, iota(1, 5));

but it didn't work. It turned out that map() actually took the mapper as its 
_template_ argument, not as a function argument. Not too much of
a problem, it probably seemed to be...
except that it's a critical problem. It makes map(), reduce(), filter(), etc. 
to become 10x less useful, because there's no way to change
their behavior at runtime, depending on program's state.



I did never try and so I'm unsure but shouldn't you be able to give a 
delegate variable as template parameter.
std.algorithms.map's parameter is an alias parameter so it should be 
able alias your variable and use it's runtime value.

If it does not work this way it's a bug IMO.

Mafi

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Mon, 21 Feb 2011 12:40:11 +0100
> Jens Mueller  wrote:
> 
> > Recently I've been a bit distracted from CMakeD development since I
> > stumbled over
> > Gyp
> > http://code.google.com/p/gyp/
> > and
> > Premake
> > http://industriousone.com/premake
> > Both address similar needs like CMake but do not support D yet.
> 
> They look interesting, but I'm sure they cannot replace CMake and
> therefore hope D will become 1st class citizen in the CMake country.

Very true. CMake is used widely and has built-in support for finding
different often used library like Boost, SDL, OpenSSL, ...
So if you need to use these library CMake is a good candidate.

Jens

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Tue, 22 Feb 2011 09:42:46 +0100
> Gour  wrote:
> 
> > I installed CMakeD from the archlinux package, then pulled from the
> > repo and tried tests suite. Here is the result:
> 
> Oops...forgot to run 'make test':
> 
> [gour@atmarama build] make test
> Running tests...
> Test project /home/gour/repos/cmaked2/tests/build
> Start 1: app_1
> 1/9 Test #1: app_1    Passed0.00 sec
> Start 2: app_2
> 2/9 Test #2: app_2    Passed0.00 sec
> Start 3: app_3
> 3/9 Test #3: app_3    Passed0.00 sec
> Start 4: app_5
> 4/9 Test #4: app_5    Passed0.00 sec
> Start 5: app_4
> 5/9 Test #5: app_4    Passed0.00 sec
> Start 6: app_6
> 6/9 Test #6: app_6    Passed0.00 sec
> Start 7: app_7
> 7/9 Test #7: app_7    Passed0.00 sec
> Start 8: moduleB.d
> 8/9 Test #8: moduleB.d    Passed0.05 sec
> Start 9: moduleA.d
> 9/9 Test #9: moduleA.d    Passed0.05 sec
> 
> 100% tests passed, 0 tests failed out of 9
> 
> Total Test time (real) =   0.28 sec
> 
> 
> So, everything is fine on x86_64 (however, still using 32bit dmd2
> waiting for new package).

Yeah. That looks good. I'd like to add your setup to
http://code.google.com/p/cmaked2/wiki/TestedPlatforms
Can please you leave a comment there?
I will try adding -m64 flag and see how it goes.

Jens

Re: CMake for D2 ready for testers

[Jens Mueller]

Gour wrote:
> On Mon, 21 Feb 2011 21:22:54 +0100
> Jens Mueller  wrote:
> 
> > With CMakeD, you clone the repository, i.e.
> > $ hg clone http://cmaked2.googlecode.com/hg/ cmaked2
> > and
> > $ cd cmaked2/cmaked
> > $ mkdir build
> > $ cd build
> > $ cmake ..
> > $ make install
> > 
> > to install it. That will copy the necessary files into your CMake
> > installation.
> 
> I installed CMakeD from the archlinux package, then pulled from the
> repo and tried tests suite. Here is the result:
> 
> [gour@atmarama tests] make
> Scanning dependencies of target lib_1
> [ 10%] Building D object lib_1/CMakeFiles/lib_1.dir/lib_1.o
> Linking D static library liblib_1.a
> [ 10%] Built target lib_1
> Scanning dependencies of target lib_2
> [ 20%] Building C object lib_2/CMakeFiles/lib_2.dir/lib_2.o
> Linking C static library liblib_2.a
> [ 20%] Built target lib_2
> Scanning dependencies of target app_1
> [ 30%] Building D object app_1/CMakeFiles/app_1.dir/app_1.o
> Linking D executable app_1
> [ 30%] Built target app_1
> Scanning dependencies of target app_2
> [ 40%] Building D object app_2/CMakeFiles/app_2.dir/app_2.o
> Linking D executable app_2
> [ 40%] Built target app_2
> Scanning dependencies of target app_3
> [ 50%] Building D object app_3/CMakeFiles/app_3.dir/app_3.o
> Linking D executable app_3
> [ 50%] Built target app_3
> Scanning dependencies of target app_5
> [ 60%] Building D object app_5/CMakeFiles/app_5.dir/app_5.o
> [ 70%] Building C object app_5/CMakeFiles/app_5.dir/cfunc.o
> Linking D executable app_5
> [ 70%] Built target app_5
> Scanning dependencies of target app_4
> [ 80%] Building D object app_4/CMakeFiles/app_4.dir/app_4.o
> Linking D executable app_4
> [ 80%] Built target app_4
> Scanning dependencies of target app_6
> [ 90%] Building D object app_6/CMakeFiles/app_6.dir/app_6.o
> Linking D executable app_6
> [ 90%] Built target app_6
> Scanning dependencies of target app_7
> [100%] Building D object app_7/CMakeFiles/app_7.dir/app_7.o
> std.perf has been scheduled for deprecation. Please use std.datetime
> instead.
> Linking D executable app_7
> [100%] Built target app_7
> 
> 
> Is it OK?

That looks good.

> > I do not know yet. I think both of them are pretty weak regarding
> > already available modules, i.e. files to find a specific dependency.
> > Gyp is developed for building Chromium. They had a problem with SCons
> > while migrating to it.
> > They also wrote in what regard CMake didn't work out for them
> > http://code.google.com/p/gyp/wiki/GypVsCMake
> 
> Do you have any issue with CMake that it does not work for you?

It does work for me most of the time. I work on Linux. There is one neat
trick if you need to link against shared libraries which isn't supported
by dmd yet. For these cases I rely on gcc.
E.g.
add_executable(myDExecutable src.d)
set_target_properties(myDExecutable PROPERTIES LINKER_LANGUAGE C)
target_link_libraries(myDExecutable ${CMAKE_REQUIRED_LIBRARIES})

will link myDExecutable against libraries mentioned in
CMAKE_REQUIRED_LIBRARIES.

> Considering that KDE is (still) using it, I assume that, despite its
> possible awkwardness, it must be quite robust build system.

Yeah. I'll guess though. But since it has it's own language some things
are really annoying to do. I think the newer systems are better in that
regard. They give you a nicer syntax and usually a full blown scripting
language.

> > I like premake for it's readability see
> > http://industriousone.com/sample-script and it's all Lua. Though I'm
> > not sure whether I can keep two scripting languages in my head. But
> > Lua seems to be very simple.
> 
> I consider to maybe use Lua as scripting DSL in our app...we'll
> see...it's still too early to say...so, yes, it is cute language, but
> premake then resembles Waf with the exception of using Python instead.

Right. We will see what tool will finally win this race. Anyway I assume
that there will be more tools around and likely people will move to new
tools. autotools wasn't the final thing for configuring software.
I just pick the one that works for me right now since there will be a
better tool later anyway. But I hope that the tools for configuring
software stabilizes more and more as time goes by.

Jens

Ranges and Algorithms -- Templates, Delegates, or Ranges?

[%u]

Having learned functional programming in Scheme a couple months ago, I tried my 
hand at using map(), reduce(), and filter() in D:

int addend = 5;
map(delegate int(int x) { return x + addend; }, iota(1, 5));

but it didn't work. It turned out that map() actually took the mapper as its 
_template_ argument, not as a function argument. Not too much of
a problem, it probably seemed to be...
except that it's a critical problem. It makes map(), reduce(), filter(), etc. 
to become 10x less useful, because there's no way to change
their behavior at runtime, depending on program's state.

This was disappointing, but it wasn't like I couldn't write a better version of 
it, so I did:

static T2[] map(T2, T1)(scope T2 delegate(T1) mapper, T1[] arr)
{
auto result = new T2[arr.length];
foreach (i, item; arr) { result[i] = mapper(item); }
return result;
}

except then I quickly realized that this was array-based, and useless for 
ranges. So I wrote my own MapRange struct (which I didn't paste
here) and map() function:

static auto map(TFn, T...)(TFn map, T args)
if (isCallable!(TFn) && T.length > 0
&& allSatisfy!(isInputRange, T))
{ return MapRange!(TFn, T)(map, args); }


Everything seemed solved until today, when I realized something critical: the 
mapper is no longer a 'scope' variable, and will require a heap
allocation each time a lambda with closure is created.

Of course, lambdas with closures are critical in functional programming, and 
one of the reasons I moved to D was precisely features like the
'scope' keyword, that allowed you to avoid heap allocations. But I couldn't 
make this a scope variable, because the delegate reference is
obviously escaped from the function.


So my question is, what's the solution to these needs? Do we really need three 
versions of every function like map()? After all, we should be
able to perform **any** of the following, depending on the situation:

1. Call map() with the function as a template argument, the way it currently 
works in std.algorithm. This is necessary to allow the compiler
to infer the types; otherwise, if we passed the function addresses, we'd have 
to instantiate the template for the mapper manually, like:
   map(&mapper!(int[typeof(SomeExpression)]), myRange);

2. Call map() with a *scoped* lambda that has a closure. This is critical to 
functional programming, but at the same time, we need to somehow
prevent a reference to the mapper from escaping; otherwise, it will trigger a 
heap allocation, which can be costly in loops. Of course, this
means that the mapping would have to occur entirely _inside_ the map() function 
(because the delegate will no longer be accessible), and so
it means we would either need to pass it a sink() delegate, or we would need to 
aggregate the results into an array. Neither is pretty, but
this feature is needed, so I don't know what a good solution is.

3. Call map() with a *range* and some kind of lambda, and have it return 
another range that maps the original. This prevents the two issues
in #2 (regarding passing a sink or aggregating the results), but it would cause 
a heap allocation.


Ultimately, since there's no universal solution and because all three of these 
situations are useful in many cases, it seems to me that we
really need *three* versions of every higher-order function.

What do you think? Is there a better solution?

Thanks!