Discussion:
dmd 2.029 release
(too old to reply)
Walter Bright
2009-04-20 07:09:09 UTC
Permalink
This is a major revision to Phobos, including Andrei's revolutionary new
range support.

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Simen Kjaeraas
2009-04-20 07:14:18 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Butbutbut... I've just barely managed to install 2.028 yet.

Great work! Can't wait to try out the new ranges.

--
Simen
BCS
2009-04-20 07:14:55 UTC
Permalink
Hello Walter,
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Cool template function literals sounds interesting
bearophile
2009-04-20 08:40:29 UTC
Permalink
Post by BCS
Cool template function literals sounds interesting
May I have one example of them?
I am looking in the docs, but I am not finding anything...

Bye,
bearophile
Walter Bright
2009-04-20 09:12:16 UTC
Permalink
Post by bearophile
Post by BCS
Cool template function literals sounds interesting
May I have one example of them?
I am looking in the docs, but I am not finding anything...
void foo(alias f)()
{
f(3, 4);
}

foo!((x,y){return x * y;))();
bearophile
2009-04-20 09:48:11 UTC
Permalink
Post by Walter Bright
void foo(alias f)()
{
f(3, 4);
}
foo!((x,y){return x * y;))();
I have tried:

import std.stdio: writeln;
void foo(alias f)() {
f(3, 4);
}
void main() {
foo!( (x, y) { writeln(x * y); } )();
}

And it works, printing 12 :-) Very cute.
This is able to simplify some of the code of (D1) dlibs :-)

I didn't even know that lambda delegates in D2 can now infer the type of their input argument, so you can use (x, y) instead of (int x, int y). Can you tell me when this was changed? :-)

Bye,
bearophile
bearophile
2009-04-20 10:05:12 UTC
Permalink
In D1 I have written a very hairy (but not too much long) apply() function, that given a function and some arguments, returns the result of the function applied to them. (apply() is a basic higher-order thing common in most functional languages).

So now I'm playing with this new toy of D2, not using it in a serious way yet, and I have written:

import std.stdio: writeln;
auto apply(alias f, TyArgs...)(TyArgs args) {
return f(args);
}
void main() {
writeln( apply!( (x, y) { return x * y; } )(3, 4) );
}

But when I compile it the compile spits out at compile-time:
Assertion failure: '0' on line 935 in file 'glue.c'

Bye,
bearophile
Andrei Alexandrescu
2009-04-20 13:55:41 UTC
Permalink
Post by bearophile
In D1 I have written a very hairy (but not too much long) apply() function, that given a function and some arguments, returns the result of the function applied to them. (apply() is a basic higher-order thing common in most functional languages).
import std.stdio: writeln;
auto apply(alias f, TyArgs...)(TyArgs args) {
return f(args);
}
void main() {
writeln( apply!( (x, y) { return x * y; } )(3, 4) );
}
Assertion failure: '0' on line 935 in file 'glue.c'
Bye,
bearophile
Your code should work as expected. (Also, right off the bat, any
assertion failure in the compiler is a bug.) Could you submit to bugzilla?

Andrei
Walter Bright
2009-04-20 17:07:39 UTC
Permalink
Post by bearophile
Assertion failure: '0' on line 935 in file 'glue.c'
All assertion failures are compiler bugs and belong in bugzilla:

http://d.puremagic.com/issues/show_bug.cgi?id=2863
Walter Bright
2009-04-20 17:04:04 UTC
Permalink
Post by bearophile
I didn't even know that lambda delegates in D2 can now infer the type
of their input argument, so you can use (x, y) instead of (int x, int
y). Can you tell me when this was changed? :-)
That change *is* the template function literals, and they are only valid
as template arguments.
tama
2009-04-20 10:19:43 UTC
Permalink
On Mon, 20 Apr 2009 18:12:16 +0900, Walter Bright
Post by Walter Bright
Post by bearophile
Post by BCS
Cool template function literals sounds interesting
May I have one example of them?
I am looking in the docs, but I am not finding anything...
void foo(alias f)()
{
f(3, 4);
}
foo!((x,y){return x * y;))();
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();

This code doesn't work(compile error). But, following code works.

void bar(alias f)()
{
writefln(f("bar"));
}
bar!((str) { return str; })();

Is this a bug?
--
tama <repeatedly at gmail.com>
http://profile.livedoor.com/repeatedly/
???????
http://tpf.techtalk.jp/
bearophile
2009-04-20 10:28:41 UTC
Permalink
Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).
To me the following works:

import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}

Bye,
bearophile
tama
2009-04-20 10:58:38 UTC
Permalink
Post by bearophile
Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).
import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}
I see.

I tested following code.

writefln(3 * 4);

This code doesn't work in the first place:-<
Sorry, it didn't matter.
--
tama <repeatedly at gmail.com>
http://profile.livedoor.com/repeatedly/
???????
http://tpf.techtalk.jp/
Denis Koroskin
2009-04-20 11:27:04 UTC
Permalink
Post by tama
Post by bearophile
Post by Walter Bright
void foo(alias f)()
{
writefln(f(3, 4));
}
foo!((x,y){ return x * y; })();
This code doesn't work(compile error).
import std.stdio: writeln;
void foo(alias f)() {
writeln(f(3, 4));
}
void main() {
foo!((x,y){ return x * y; })();
}
I see.
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<
Sorry, it didn't matter.
writefln now expects a string as a first argument.
Use writeln() if you need no formattings, it is both faster and safer.
tama
2009-04-20 12:07:20 UTC
Permalink
Post by Denis Koroskin
writefln now expects a string as a first argument.
Use writeln() if you need no formattings, it is both faster and safer.
To one's shame, I didn't know detailed writef/writefln spec.
I checked D2 changelog and founded it at version 2.006 and 2.029.

Thanks!
--
tama <repeatedly at gmail.com>
http://profile.livedoor.com/repeatedly/
???????
http://tpf.techtalk.jp/
Walter Bright
2009-04-20 17:10:41 UTC
Permalink
Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<
Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.

If it isn't, use writeln instead.
Russell Lewis
2009-04-20 06:31:05 UTC
Permalink
Post by Walter Bright
Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<
Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.
If it isn't, use writeln instead.
I just hit the same breakage. :(

Since the compiler can detect this situation statically, shouldn't
Phobos just statically redirect the call to writeln() ?
Andrei Alexandrescu
2009-04-20 18:41:50 UTC
Permalink
Post by Russell Lewis
Post by Walter Bright
Post by tama
I tested following code.
writefln(3 * 4);
This code doesn't work in the first place:-<
Yes, that's one of the breaking changes in the new phobos2. writefln
expects its first argument to be a format string.
If it isn't, use writeln instead.
I just hit the same breakage. :(
Since the compiler can detect this situation statically, shouldn't
Phobos just statically redirect the call to writeln() ?
It did for a while. For cleanliness purposes, I thought it was about
time to eliminate that. Also, extraneous arguments passed to writef will
be ignored, not printed with default formatting.

Andrei
bearophile
2009-04-20 19:26:08 UTC
Permalink
Post by Andrei Alexandrescu
extraneous arguments passed to writef will
be ignored, not printed with default formatting.
That sounds bad:
=> "Errors should never pass silently."
It's better to raise a compilation error. (And if that's not possible, then an exception at run-time. But a compilation error is much better).

Bye,
bearophile
Andrei Alexandrescu
2009-04-20 20:18:02 UTC
Permalink
extraneous arguments passed to writef will be ignored, not printed
with default formatting.
That sounds bad: => "Errors should never pass silently." It's better
to raise a compilation error. (And if that's not possible, then an
exception at run-time. But a compilation error is much better).
If it were an error, I wouldn't let it go. A good use case is string
tables - a formatted message may or may not use all of the available
information.

Andrei
bearophile
2009-04-20 21:33:21 UTC
Permalink
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.

Bye,
bearophile
BCS
2009-04-20 21:46:16 UTC
Permalink
Reply to bearophile,
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Bye,
bearophile
Then there need to be a way for the format string to use an argument without
generating output for it because as Andrei is saying, there are real world
cases where not using all the args is *normal* and not an error.

One option would be to not throw an error if the format string uses indexing
formats (e.i. out of order formatting)
Andrei Alexandrescu
2009-04-20 21:45:39 UTC
Permalink
Post by BCS
Reply to bearophile,
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Bye,
bearophile
Then there need to be a way for the format string to use an argument
without generating output for it because as Andrei is saying, there are
real world cases where not using all the args is *normal* and not an error.
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.

Andrei
Nick Sabalausky
2009-04-20 22:16:10 UTC
Permalink
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by BCS
Reply to bearophile,
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Bye,
bearophile
Then there need to be a way for the format string to use an argument
without generating output for it because as Andrei is saying, there are
real world cases where not using all the args is *normal* and not an error.
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.
That would be far too clumbsy, unless you made it into two separate
functions.

For instance (psuedocode):
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error
BCS
2009-04-20 22:48:45 UTC
Permalink
Reply to Nick,
Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.
That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error
They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.
Nick Sabalausky
2009-04-21 00:47:59 UTC
Permalink
"BCS" <ao at pathlink.com> wrote in message
Post by BCS
Reply to Nick,
Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.
That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error
They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.
I was just using names for illustrative purposes. Also, I was under the
impression that printf-style "get the next arg" formatting codes were the
only ones writef supported. Is this not so?
Andrei Alexandrescu
2009-04-21 00:49:20 UTC
Permalink
Post by Nick Sabalausky
"BCS" <ao at pathlink.com> wrote in message
Post by BCS
Reply to Nick,
Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.
That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error
They are in order but are listed by name so the error doesn't throw. The
case where the error would be thrown is where the only format strings used
are the "get the next arg" kind.
I was just using names for illustrative purposes. Also, I was under the
impression that printf-style "get the next arg" formatting codes were the
only ones writef supported. Is this not so?
Since a few versions ago writef supports positional arguments with Posix
syntax.

Andrei
Georg Wrede
2009-04-21 06:08:27 UTC
Permalink
Post by Andrei Alexandrescu
Post by Nick Sabalausky
Post by BCS
Reply to Nick,
Post by Nick Sabalausky
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
Post by Andrei Alexandrescu
Post by BCS
One option would be to not throw an error if the format string uses
indexing formats (e.i. out of order formatting)
Yah, that's an option I considered. Maybe it's the best way to go.
That would be far too clumbsy, unless you made it into two separate
functions.
auto userInput = getUserInput()
// userInput now contains "{Name} at {Address}", zip deliberately ignored
writefln(userInput, name, address, zip); // They're used in-order, but there
shouldn't be an error
They are in order but are listed by name so the error doesn't throw.
The case where the error would be thrown is where the only format
strings used are the "get the next arg" kind.
I was just using names for illustrative purposes. Also, I was under
the impression that printf-style "get the next arg" formatting codes
were the only ones writef supported. Is this not so?
Since a few versions ago writef supports positional arguments with Posix
syntax.
Andrei
Positional format specifications really make a huge difference,
especially where one needs to have the user interface in several
languages. Thanks for them!!

Now, for the case without positional format specifications, we could
(and I guess, should) have a solution to "the wrong number of arguments"
problem. If we have:

- a non-printing format spec
- a munch-the-remaining-ones format spec
- an ignore-too-few-arguments format spec

we could cover all the needed cases.

The first one lets you use one parameter without printing it. (Maybe you
don't want to print the middle part of somebody's name.) The second is
used when you don't want to print possibly many remaining arguments, say
the address of someone, or the country.

The last one, is for the case where you use a single format string in
several contexts, some of which you suspect may not contain enough
information to be formally correct, but where you are satisfied to print
an empty string '' (that is, not print anything) for them.

This situation might arise when the format string originates from
outside the program.

** When none of the latter two are used, and there is the wrong number
of arguments, I think a runtime exception should be thrown.

The only time where I think a compile time error is warranted, is when
the format string is a string literal, with the wrong number of arguments.


The programmer may put the ignore-too-few-arguments format spec anywhere
in the format string. Its effect starts from that point on.
Andrei Alexandrescu
2009-04-20 21:44:54 UTC
Permalink
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Well at most you could say it's error-prone, something that is easier to
argue. The problem is that forcing it into an error makes quite a number
of valid uses impossible. An example is a logging application that
provides you a number of pieces of information (date, time, message,
etc.) and you get to specify how they should be formatted. Oftentimes
you'd choose to ignore some data.

Andrei
Russell Lewis
2009-04-20 11:30:03 UTC
Permalink
Post by Andrei Alexandrescu
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Well at most you could say it's error-prone, something that is easier to
argue. The problem is that forcing it into an error makes quite a number
of valid uses impossible. An example is a logging application that
provides you a number of pieces of information (date, time, message,
etc.) and you get to specify how they should be formatted. Oftentimes
you'd choose to ignore some data.
Andrei
Fair enough. But then let's split off a version of the function which
allows unused arguments. For most users, in most cases, unused
arguments are indicative of an error.

Case in point: I have been bitten by this perhaps half a dozen times
*already* porting older code. This code used to work fine:

writefln("The value is: %d", myVar, ". Do something!");

Now, it interprets the trailing string as an unused argument, and
ignores it (silently). Ugh.

Ofc, looking back, I don't like that old coding style...I'm migrating
back more to C-style (give the whole format string first). But the fact
that I had a *silent* error was frustrating.

Russ
Lutger
2009-04-22 06:50:43 UTC
Permalink
Russell Lewis wrote:

...
Post by Russell Lewis
Case in point: I have been bitten by this perhaps half a dozen times
writefln("The value is: %d", myVar, ". Do something!");
...

I bet a lot of to-be-ported D code will have this bug, I know my code will.
When you want to print a format string this way - last argument(s) simply
appended, it saves you two characters typing. When something saves any
characters typing and produces the same result, programmers will do that.
Nick Sabalausky
2009-04-20 22:07:58 UTC
Permalink
"bearophile" <bearophileHUGS at lycos.com> wrote in message
Post by bearophile
Post by Andrei Alexandrescu
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Sometimes it is an error, but there are times when it isn't:

Suppose you're writing a reporting module for an employee database:

---------------------
ID: 3234
Last: Doe
First: John
Phone: 555-5555
Zip: 90210

ID: 7642
Last: Smith
Etc...
---------------------

And you want the admins to be able to define their own reports:

---------------------
Privileged Report:
For Each Person: "ID #{ID}\nName: {First} {Last}\nPhone: {Phone}\nZip:{Zip}"

Unprivileged Report:
For Each Person: "Name: {Last}, {First}\nContact Info Classified"

Call List In Psuedo-Japanese:
For Each Person Where Name="Smith": "SmithSan {LoopIndex}'s DenwaBango:
{Phone}"
---------------------

So then the report creation code:

---------------------
foreach(int i, Person p; people.subset(customReport.whereClause))
writefln(customReport.formatStr, i, p.id, p.first, p.last, p.phone,
p.zip);
---------------------

That would be very difficult/limiting if every arg had to be used in the
format string.

(Incidentally, this example also demonstrates why I consider C#/Tango-style
string formatting superior to C/Phobos-style)
Daniel Keep
2009-04-20 09:11:55 UTC
Permalink
Post by bearophile
Post by BCS
Cool template function literals sounds interesting
May I have one example of them?
I am looking in the docs, but I am not finding anything...
Bye,
bearophile
alias (T)(T a, T b) { return (a+b)/2.0; } average;
Haven't had a chance to TRY that yet, mind you. :P

-- Daniel
Daniel Keep
2009-04-20 09:26:05 UTC
Permalink
Post by Daniel Keep
Post by bearophile
Post by BCS
Cool template function literals sounds interesting
May I have one example of them?
I am looking in the docs, but I am not finding anything...
Bye,
bearophile
alias (T)(T a, T b) { return (a+b)/2.0; } average;
Haven't had a chance to TRY that yet, mind you. :P
-- Daniel
(Sees Walter's post)

Guess not. :P

-- Daniel
Georg Wrede
2009-04-20 09:31:50 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Ooohhh, just half way through the change log, and already breathless!!!
Saaa
2009-04-20 12:47:44 UTC
Permalink
Using D1 feels especially retarded today :(
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Georg Wrede
2009-04-20 13:37:40 UTC
Permalink
Post by Saaa
Using D1 feels especially retarded today :(
Don't cry now. :-)
Soon you'll be using D2 for work, and cry when you see the D3 change log...
Tomas Lindquist Olsen
2009-04-20 12:49:42 UTC
Permalink
Post by Saaa
Using D1 feels especially retarded today :(
Why retarded ?
Georg Wrede
2009-04-20 12:46:43 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
The documentation for completeSort in std.algorithm says:

Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.

I wonder what it should be.
Andrei Alexandrescu
2009-04-20 13:05:41 UTC
Permalink
Post by Georg Wrede
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.
I wonder what it should be.
Sorry, what was I thinking? I think (without being sure) that the
complexity of completeSort is O(rhs.length * log(t)) in the
best case, and O(t * log(t)) in the worst case, where t = lhs.length +
rhs.length.


Andrei
Andrei Alexandrescu
2009-04-20 13:52:51 UTC
Permalink
Post by Andrei Alexandrescu
Post by Georg Wrede
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Performs O(n * log(n)) (best case)
to O(n * log(n)) (worst-case) evaluations of swap.
I wonder what it should be.
Sorry, what was I thinking? I think (without being sure) that the
complexity of completeSort is O(rhs.length * log(t)) in the
best case, and O(t * log(t)) in the worst case, where t = lhs.length +
rhs.length.
I revise that. Best case, there's temporary memory to allocate and then
the complexity is that of sorting rhs plus merge lhs and rhs using extra
memory. That is O(lhs.length + rhs.length * log(rhs.length)).

Worst case, there's no temporary memory available so we need to sort the
whole thing. That means O((lhs.length + rhs.length) * log(rhs.length +
rhs.length)).

I committed the fixed module.


Andrei
dsimcha
2009-04-20 14:52:22 UTC
Permalink
== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Two small issues I've just run into that might warrant a quick update:

Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.

Also, when using std.string, I get the following linker errors on the Win32 build:


Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya
dsimcha
2009-04-20 15:05:14 UTC
Permalink
== Quote from dsimcha (dsimcha at yahoo.com)'s article
Post by dsimcha
== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.
Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya
Never mind on the linker error. That was caused by me forgetting to recompile
parts of my code. The random thing looks legit, though.
Andrei Alexandrescu
2009-04-20 15:26:41 UTC
Permalink
Post by dsimcha
== Quote from dsimcha (dsimcha at yahoo.com)'s article
Post by dsimcha
== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Line 908 in random.d calls the deprecated rand_seed() for the old school random
number generators from the static constructor. This means that std.random just
plain can't be used out of the box.
Symbol Undefined _D3std6string6striprFAyaZAya
Symbol Undefined _D3std6string6striplFAyaZAya
Never mind on the linker error. That was caused by me forgetting to recompile
parts of my code. The random thing looks legit, though.
Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand()
entirely from this release, but Walter pointed out it would break too
much code. So I left rand() and rand_seed() as deprecated. Now I only
left rand() deprecated so at least the static constructor works.


Andrei
Walter Bright
2009-04-20 17:13:47 UTC
Permalink
Post by Andrei Alexandrescu
Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand()
entirely from this release, but Walter pointed out it would break too
much code. So I left rand() and rand_seed() as deprecated. Now I only
left rand() deprecated so at least the static constructor works.
I think the right fix for that is for the compiler to not complain about
deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.
Walter Bright
2009-04-20 17:15:27 UTC
Permalink
http://d.puremagic.com/issues/show_bug.cgi?id=2864
Andrei Alexandrescu
2009-04-20 17:20:34 UTC
Permalink
Post by Walter Bright
Post by Andrei Alexandrescu
Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate
rand() entirely from this release, but Walter pointed out it would
break too much code. So I left rand() and rand_seed() as deprecated.
Now I only left rand() deprecated so at least the static constructor
works.
I think the right fix for that is for the compiler to not complain about
deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.
Reading this, I thought "No chance Walter will ever do this" until I saw
the poster's name :o).

Andrei
Walter Bright
2009-04-20 17:30:06 UTC
Permalink
Post by Andrei Alexandrescu
Post by Walter Bright
I think the right fix for that is for the compiler to not complain
about deprecated symbol usage if the usage is in the same module the
deprecated symbol is defined in.
Reading this, I thought "No chance Walter will ever do this" until I saw
the poster's name :o).
It is consistent with the ideas behind private access. Presumably the
person working on the module knows what they're doing, no need to hide
it from himself.
Craig Black
2009-04-20 16:07:25 UTC
Permalink
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!

-Craig
superdan
2009-04-20 16:36:30 UTC
Permalink
Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig
holy guacashit this works.

import std.algorithm;
import std.range;
import std.stdio;

void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}

i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.
downs
2009-04-20 17:08:33 UTC
Permalink
Post by superdan
Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig
holy guacashit this works.
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}
i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.
Poop is funny! :)
Andrei Alexandrescu
2009-04-20 17:22:24 UTC
Permalink
Post by superdan
Post by Craig Black
I like very much the direction D2 is going now. Language refactoring and
enhancements driven by the goal of more elegant implementation of standard
libraries. This approach seems very practical and promising. Thank you
very much and keep it up!
-Craig
holy guacashit this works.
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
string[] a = [ "shit", "poop" ];
string[] b = [ "dump", "shite" ];
sort!((a, b) { return a > b; })(chain(a, b));
writeln(a, " ", b);
}
i'll be shat on. couple shitty problems tho. auto don't work shit for a and b. complains about fixed size strings'n'shit. then writeln(chain(a, b)) shites ChainImpl!(immutable(char)[][],immutable(char)[][]) to stdout. tat's liable to scare da shit outta a beginner.
Thanks... I guess :o). Any chance you could submit the issues to
bugzilla? I think the problem with string arrays is already known, but I
need a memento to make writeln work with ranges.

Andrei
Andrei Alexandrescu
2009-04-20 17:36:15 UTC
Permalink
Post by Craig Black
I like very much the direction D2 is going now. Language refactoring
and enhancements driven by the goal of more elegant implementation of
standard libraries. This approach seems very practical and promising.
Thank you very much and keep it up!
-Craig
Thanks. Walter pointed out to me something interesting - STL is
non-intuitive. That doesn't make it any less true (as a pursuit of the
most generic incarnation of fundamental structs and algos). It's
non-intuitive the same way complex numbers and relativity theory are
non-intuitive.

No language has ever managed to comprehend STL by sheer chance. (This in
spite of e.g. C# adding a boatload of new features with each release.)
There are two that can express it at all: C++ and D. Both C++ and D had
to be changed to allow STL to exist, and became better languages as a
result. The range shtick and D's support for lambdas is taking STL
support to a whole new level.

The downside is, it's rather difficult to explain the STL to anyone
using other languages and wanting to just figure what the STL buzz is
all about.


Andrei
Georg Wrede
2009-04-21 06:25:55 UTC
Permalink
Post by Andrei Alexandrescu
Post by Craig Black
I like very much the direction D2 is going now. Language refactoring
and enhancements driven by the goal of more elegant implementation of
standard libraries. This approach seems very practical and
promising. Thank you very much and keep it up!
-Craig
Thanks. Walter pointed out to me something interesting - STL is
non-intuitive. That doesn't make it any less true (as a pursuit of the
most generic incarnation of fundamental structs and algos). It's
non-intuitive the same way complex numbers and relativity theory are
non-intuitive.
No language has ever managed to comprehend STL by sheer chance. (This in
spite of e.g. C# adding a boatload of new features with each release.)
There are two that can express it at all: C++ and D. Both C++ and D had
to be changed to allow STL to exist, and became better languages as a
result. The range shtick and D's support for lambdas is taking STL
support to a whole new level.
The downside is, it's rather difficult to explain the STL to anyone
using other languages and wanting to just figure what the STL buzz is
all about.
I wrote my MSc thesis about the STL. I think the conceptual idea was
clean and clear, and at the time it was reasonably easy to explain it to
even the professors. ;-)

Today, however, and especially with the advanced implementation we have
here in D, if someone has no prior knowledge of the STL way of thinking,
it may be really hard to get them to 'get it'. There are too many trees
up front to grasp the forest.

What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library
really sucks at introducing the STL on a conceptual level. Even worse,
that is actually the only thing it *should* do. Everyting else is optional.
Leandro Lucarella
2009-04-21 14:08:01 UTC
Permalink
Post by Georg Wrede
What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library
really sucks at introducing the STL on a conceptual level. Even worse, that is
actually the only thing it *should* do. Everyting else is optional.
You should improve it then =)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Georg Wrede
2009-04-20 16:54:49 UTC
Permalink
Walter Bright wrote:

In std.array, the example for back() is the same as for front().


The example for put() seems to be correct (and put() behaves
accordingly), however, the asserted results are not what the reader
would expect.

If we are verbose enough to explain the dot notation here, then it would
be prudent to elaborate a little as to the point of put(), and possibly
the example (or the explanation) could include a use case.
Russell Lewis
2009-04-20 06:44:55 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Was fwritefln() removed intentionally? Or should I write up a Bugzilla?
I didn't noteice a mention in changelog.
Andrei Alexandrescu
2009-04-20 18:40:51 UTC
Permalink
Post by Russell Lewis
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Was fwritefln() removed intentionally? Or should I write up a Bugzilla?
I didn't noteice a mention in changelog.
Sorry. It was removed intentionally along with all functions that
manipulate FILE* directly.

Its functional equivalent is File.writefln. If all you have is a handle,
use File.wrapFile(fhandle).writefln.


Andrei
annoyed
2009-04-20 23:26:53 UTC
Permalink
It's in dmd-v2.026/src/phobos/std/stdio.d:void fwritefln(FILE* fp, ...)

but I cannot find it in 2.029.
unknown
2009-04-20 23:34:30 UTC
Permalink
Post by annoyed
It's in dmd-v2.026/src/phobos/std/stdio.d:void fwritefln(FILE* fp, ...)
but I cannot find it in 2.029.
It was removed, use File.writefln() instead. std.stdio has been rewritten so you might want to take a look at the docs.

Andrew
Stewart Gordon
2009-04-21 01:20:43 UTC
Permalink
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.

Stewart.
Walter Bright
2009-04-21 02:16:17 UTC
Permalink
Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.
As far as I know, it is current. Everything got checked in.
BCS
2009-04-21 02:38:43 UTC
Permalink
Hello Walter,
Post by Walter Bright
Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.
As far as I know, it is current. Everything got checked in.
I think he was asking about the otherway (not that I known why)
Walter Bright
2009-04-21 05:33:52 UTC
Permalink
Post by BCS
I think he was asking about the otherway (not that I known why)
I think he'll need to be more specific!
Unknown W. Brackets
2009-04-21 05:50:44 UTC
Permalink
Well, there's push (svn commit) and pull (svn up), so he must mean one
or the other...

-[Unknown]
Post by Walter Bright
Post by BCS
I think he was asking about the otherway (not that I known why)
I think he'll need to be more specific!
Stewart Gordon
2009-04-21 19:28:26 UTC
Permalink
Post by Walter Bright
Post by Stewart Gordon
Walter, how often do you update your working copy from the SVN?
Obviously less than once every 2 releases.
As far as I know, it is current. Everything got checked in.
So how has the fix for
http://d.puremagic.com/issues/show_bug.cgi?id=2580
(and probably others) not been included?

Stewart.
Max Samukha
2009-04-20 07:57:55 UTC
Permalink
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Wicked awesome!

file:///C:/dmd/html/d/phobos/std_range.html#cons
Looks like bug 2676 was fixed in 2.027
Max Samukha
2009-04-21 08:02:08 UTC
Permalink
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha
Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons
http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
Post by Max Samukha
Looks like bug 2676 was fixed in 2.027
Andrei Alexandrescu
2009-04-21 12:42:46 UTC
Permalink
Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha
Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons
http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
Post by Max Samukha
Looks like bug 2676 was fixed in 2.027
Thanks. I uncommented the unittest, updated the doc, and checked in.

Andrei
Max Samukha
2009-04-22 08:25:29 UTC
Permalink
On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha
Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons
http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
Post by Max Samukha
Looks like bug 2676 was fixed in 2.027
Thanks. I uncommented the unittest, updated the doc, and checked in.
Andrei
A couple more minor doc issues:
http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of
"the popFront" need to be corrected to "the next".

On the std.algorithm page, the examples for "map" and "filter" don't
compile due to the fixed size array in equal().

The example for "bringToFront" is outdated.

The comments for "remove": "If $(s =" -> "If $(D s ="
Brad Roberts
2009-04-22 07:32:27 UTC
Permalink
Post by Max Samukha
On Tue, 21 Apr 2009 07:42:46 -0500, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Max Samukha
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha
Post by Max Samukha
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Wicked awesome!
file:///C:/dmd/html/d/phobos/std_range.html#cons
http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons
Post by Max Samukha
Looks like bug 2676 was fixed in 2.027
Thanks. I uncommented the unittest, updated the doc, and checked in.
Andrei
http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of
"the popFront" need to be corrected to "the next".
On the std.algorithm page, the examples for "map" and "filter" don't
compile due to the fixed size array in equal().
The example for "bringToFront" is outdated.
The comments for "remove": "If $(s =" -> "If $(D s ="
Please file a bug report. Posts here are are good way for issues to
fall through the cracks.

Thanks,
Brad

Lars T. Kyllingstad
2009-04-21 09:48:02 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...

I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?

I admit I don't know much about these things, and what I'm going to say
next may not make sense at all, but here goes:

x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.

I know it is possible to run the 32-bit compiler (and the executables it
produces) on a 64-bit operating system, but it isn't possible to link
against 64-bit libraries. This means that one has to install and
maintain 32-bit versions of all the libraries one wants to use, and
those are, in general, not available through the repositories of most
64-bit distros.

-Lars
Frits van Bommel
2009-04-21 10:59:23 UTC
Permalink
Post by Lars T. Kyllingstad
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I admit I don't know much about these things, and what I'm going to say
x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.
It's not quite that simple. It's not a full superset; some x86 instructions are
not valid x86-64 instructions.
For example, I think 'inc' was removed to make place for prefixes that set some
flags for the next instruction and allow it to use the extra registers r8-r15.
Daniel Keep
2009-04-21 11:02:16 UTC
Permalink
Post by Lars T. Kyllingstad
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I admit I don't know much about these things, and what I'm going to say
x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
first step in the direction of a full-fledged x86-64 compiler, to simply
make one that uses the same instruction set as the current DMD, but, I
dunno, marks the executable as 64-bit (or something like that)?
Specialisation and optimisation for the 64-bit architecture could then
come at a later point in time.
I'm pretty sure that 64-bit code is binary incompatible with 32-bit
code. For example:

struct Foo { void* ptr; }

Is a different size for 32-bit and 64-bit code.
Post by Lars T. Kyllingstad
I know it is possible to run the 32-bit compiler (and the executables it
produces) on a 64-bit operating system, but it isn't possible to link
against 64-bit libraries. This means that one has to install and
maintain 32-bit versions of all the libraries one wants to use, and
those are, in general, not available through the repositories of most
64-bit distros.
This is because the OS puts the CPU into a 32-bit compatible mode, but
it can't magic away the differences between 32-bit and 64-bit code.
Post by Lars T. Kyllingstad
-Lars
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.

-- Daniel
Frits van Bommel
2009-04-21 11:07:39 UTC
Permalink
Post by Daniel Keep
Post by Lars T. Kyllingstad
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
[snip]
Post by Daniel Keep
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
The state for D2 is currently "very broken", AFAIK.
Lutger
2009-04-21 12:29:35 UTC
Permalink
Daniel Keep wrote:

...
Post by Daniel Keep
-Lars
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel
if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!
Don
2009-04-21 13:05:30 UTC
Permalink
Post by Lutger
...
Post by Daniel Keep
-Lars
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel
if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!
They're just part of the standard OBJ file format. Nothing to do with
code generation. Much more fun is:
$ cd src/dmd
$ grep "goto " * -R
Lutger
2009-04-21 13:35:39 UTC
Permalink
Post by Don
Post by Lutger
...
Post by Daniel Keep
-Lars
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel
if you grep the dmd backend sources for x86_64, you'll get some results.
Don't know what that means though, the source looks like magic to me!
They're just part of the standard OBJ file format. Nothing to do with
$ cd src/dmd
$ grep "goto " * -R
you forgot " | less" there, what the hell...this code can't be human.
Walter Bright
2009-04-21 18:50:40 UTC
Permalink
Post by Lutger
what the hell...this code can't be human.
I was replaced by Colossus years ago.
Georg Wrede
2009-04-21 20:44:10 UTC
Permalink
Post by Walter Bright
Post by Lutger
what the hell...this code can't be human.
I was replaced by Colossus years ago.
Michael A. Jackson wouldn't approve 1175 gotos in 113 files.
Don
2009-04-22 07:24:58 UTC
Permalink
Post by Georg Wrede
Post by Walter Bright
Post by Lutger
what the hell...this code can't be human.
I was replaced by Colossus years ago.
Michael A. Jackson wouldn't approve 1175 gotos in 113 files.
It'd be really funny to pass it through one of those "code quality"
metrics, one of the ones with a ridiculously heavy penalty for using
goto. I think it'd tell you that DMD source is almost the lowest-quality
code on the planet. <g>

Actually, looking through the DMD source it becomes obvious that goto is
really not a problem at all. The lack of comments is much more of a
problem. (Especially with files with names like "e2ir.c". What the heck
is "fltables.c", "cdxxx.c", "elxxx.c" ?). Even so, it's mostly not that
difficult to understand.
Andrei Alexandrescu
2009-04-21 12:38:54 UTC
Permalink
Post by Lars T. Kyllingstad
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I would kill for a 64-bit Linux DMD. I think it could take a lot of ways
of coding to a whole new level. Sean and I have also been discussing how
to integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.


Andrei
Lars T. Kyllingstad
2009-04-21 12:49:11 UTC
Permalink
Post by Lars T. Kyllingstad
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary
new range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked
for this before, but is making a 64-bit Linux version of DMD a lot of work?
I would kill for a 64-bit Linux DMD. [...]
Who does one have to kill to get a 64-bit compiler around here? :)

But seriously, now that the language itself is stabilising, I would
consider this a major priority for further development of DMD. 64 bits
is the (immediate) future.

-Lars
Leandro Lucarella
2009-04-21 14:25:01 UTC
Permalink
Post by Lars T. Kyllingstad
This is a major revision to Phobos, including Andrei's revolutionary new range
support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked for this
before, but is making a 64-bit Linux version of DMD a lot of work?
I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of
coding to a whole new level. Sean and I have also been discussing how to
integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.
Can you elaborate on that?

Thanks.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Andrei Alexandrescu
2009-04-21 14:50:24 UTC
Permalink
Post by Leandro Lucarella
Post by Lars T. Kyllingstad
This is a major revision to Phobos, including Andrei's revolutionary new range
support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
This is looking very nice! I want to switch from D1 to D2, but...
I don't want to sound greedy or anything, and I know others have asked for this
before, but is making a 64-bit Linux version of DMD a lot of work?
I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of
coding to a whole new level. Sean and I have also been discussing how to
integrate memory-mapped files with the garbage collector. In a 64-bit
environment this makes for an awesome programming model.
Can you elaborate on that?
Not much time, but in short: Memory-mapped files are not a pure library
thing, they are core because they manipulate the address space. So they
are quite like memory allocation. Unmapping files by hand is as unsafe
as calling delete. So memory mapped files must be integrated with the
collector: you map a file by hand, and the garbage collector closes it
when there are no more references to the memory mapped for the file.

The programming model is pretty cool - in 32 bit I always need to mind
the address space because it's so densely populated. In 64 bits I can
map all of my data files in memory and let the paging system and the
garbage collector take care of the rest.


Andrei
Lutger
2009-04-21 12:31:23 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Thanks so much, looking good!

The lambda template parameters: very cool.
Don
2009-04-21 13:16:05 UTC
Permalink
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Missing from the changelog:

From 2.208:
2804 Impure nested functions should be legal inside pure functions

From 2.209:
std.math:
Intrinsics std.math.yl2x and yl2xp1 added. Improves performance of
std.math.log() and similar functions (and they are now pure nothrow).

(Yes, I know, not very exciting compared to Andrei's new Phobos <g>).
bearophile
2009-04-21 14:20:49 UTC
Permalink
Post by Don
2804 Impure nested functions should be legal inside pure functions
Very good. Now that little example works:

import std.c.stdio: printf;
import std.conv: to;

pure int double_sqr(int x) {
int y, z;
void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

The outout is correct:
4 * x * x = 400


"Cleaned up" ASM produced by DMD V.2.029, -O -release -inline:

double_sqr:
push EAX
mov ECX,EAX
mov [ESP],0
mov [ESP],ECX
imul EAX,[ESP]
mov EDX,EAX
mov [ESP],EAX
mov EAX,ECX
mov [ESP],ECX
imul EAX,[ESP]
add EDX,EAX
mov [ESP],EAX
mov EAX,EDX
pop ECX
ret

double_sqr.do_sqr:
mov ECX,[EAX]
imul ECX,[EAX]
mov [EAX],ECX
ret

main:
L0: sub ESP,014h
cmp dword ptr 018h[ESP],2
jne L21
mov EDX,01Ch[ESP]
mov EAX,018h[ESP]
mov EAX,8[EDX]
mov EDX,0Ch[EDX]
push EDX
push EAX
call near ptr parseString
jmp short L26
L21: mov EAX,0Ah
L26: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf

As you can see there's only one call to double_sqr in the main program, so the pure semantics is working here.

You can also see do_sqr is inlined into double_sqr. But the asm code inside double_sqr looks very hairy and long, and double_sqr itself isn't inlined in the main.

Bye,
bearophile
bearophile
2009-04-21 14:46:18 UTC
Permalink
I have tried the following code:

import std.c.stdio: printf;
import std.conv: to;

nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

The compiler spits the following error:

pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr' is nothrow yet may throw

but I don't understand why. What are the things inside it that can throw an exception?

Bye,
bearophile
bearophile
2009-04-21 15:00:12 UTC
Permalink
I have also tested the semantics of nested function purity:

import std.c.stdio: printf;
import std.conv: to;

pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}

void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}

Compiled without inlining:
-O -release

double_sqr.sqr:
mov EAX,4[ESP]
imul EAX,EAX
ret 4

double_sqr:
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret

main:
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf

There's one call to double_sqr but unfortunately two to double_sqr.sqr.

Bye,
bearophile
Don
2009-04-21 15:18:39 UTC
Permalink
Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
-O -release
mov EAX,4[ESP]
imul EAX,EAX
ret 4
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.

I'm not sure that nested pure member functions should be legal.
Don
2009-04-21 15:39:15 UTC
Permalink
Post by Don
Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
-O -release
mov EAX,4[ESP]
imul EAX,EAX
ret 4
L0: push EAX
push EAX
xor EAX,EAX
call near ptr double_sqr.sqr
push EAX
sub ESP,4
xor EAX,EAX
push dword ptr 8[ESP]
call near ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
L0: push EAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
push dword ptr 0Ch[EDX]
push dword ptr 8[EDX]
call near ptr to!(int)()
jmp short L22
L1D: mov EAX,0Ah
L22: call near ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
push EAX
push ECX
call near ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.
The bug is bugzilla 2807.
Post by Don
I'm not sure that nested pure member functions should be legal.
And it turns out that sqr() isn't actually pure, in the same way that it
wasn't nothrow in your first example. The 'pure' marker is silently
being ignored. If you put the 'pure' at the end, you get bug 2807.

--
bearophile
2009-04-21 16:16:32 UTC
Permalink
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.
It's not fully equivalent to moving it out of the function because once you pull it out you add a name to the outer namespace: nested functions are useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.

pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}

Thank you,
bye,
bearophile
Don
2009-04-21 18:56:01 UTC
Permalink
Post by bearophile
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.
It's not fully equivalent to moving it out of the function because once you pull it out you add a name to the outer namespace: nested functions are useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile
That's true, but it seems quite difficult to get right. A pure nested
function can in theory access immutable members in the outer function --
but must not access the parameters of the outer function.
If there are no immutable members in the outer function, the compiler
would ideally convert it into an external pure function, so that it
doesn't need a frame pointer to the outer function. But it would need
error messages for any use of mutable outer function members. Etc.
It seems quite a lot of work for something of very limited use.
Making it into a external, private pure function is almost the same.
Tomas Lindquist Olsen
2009-04-21 22:23:14 UTC
Permalink
Post by Don
Post by bearophile
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.
It's not fully equivalent to moving it out of the function because once
you pull it out you add a name to the outer namespace: nested functions are
useful to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
?pure int foo(int y) { return y * y; }
?return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile
That's true, but it seems quite difficult to get right. A pure nested
function can in theory access immutable members in the outer function -- but
must not access the parameters of the outer function.
If there are no immutable members in the outer function, the compiler would
ideally convert it into an external pure function, so that it
doesn't need a frame pointer to the outer function. But it would need error
messages for any use of mutable outer function members. Etc.
It seems quite a lot of work for something of very limited use.
Making it into a external, private pure function is almost the same.
why not just make it a static pure nested function? or is that no
longer proper D2 ?
Michel Fortin
2009-04-22 00:43:59 UTC
Permalink
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.
What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
Daniel Keep
2009-04-22 02:19:25 UTC
Permalink
Post by Michel Fortin
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and
so it creates inefficient and possibly buggy code.
What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.
If you treat the nested function's context pointer as a pointer to a
struct matching the stack layout, then you can have pure nested
functions -- they have exactly the same semantics as a pure struct
member function.

-- Daniel
Don
2009-04-22 07:12:04 UTC
Permalink
Post by Daniel Keep
Post by Michel Fortin
Post by Don
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and
so it creates inefficient and possibly buggy code.
What about immutable local variables? A pure function can access
immutable globals, so it should be able to access immutable locals too.
If you treat the nested function's context pointer as a pointer to a
struct matching the stack layout, then you can have pure nested
functions -- they have exactly the same semantics as a pure struct
member function.
-- Daniel
True, but that would mean that it'd be pretty useless. It's almost
exactly the same as not marking it pure.
pure foo(int x)
{
int y;
pure int bar(int z) { return z*z; }

int a= bar(2);
y++;
int b = bar(2); // has to recalculate bar(2), because y has changed.
}

---
The basic issue is that the situations where marking a nested function
as 'pure' is a good idea, is extremely limited.
Compared to making it an external pure private function, with any
desired immutable members passed as parameters, it has these advantages
and disadvantages.
+ inaccessable to other functions in the same module.
+ can access immutable members in the outer function, without passing
them as parameters.
- slower, since it needs a context pointer as well as a frame pointer.

I think those benefits are pathetic.
Don
2009-04-21 15:24:52 UTC
Permalink
Post by bearophile
import std.c.stdio: printf;
import std.conv: to;
nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr' is nothrow yet may throw
but I don't understand why. What are the things inside it that can throw an exception?
Bye,
bearophile
Obviously my 2808 patch only solved one part of the problem.
It compiles if you change do_sqr to
void do_sqr() nothrow { y *= y; }
Please add a bug report to Bugzilla.
tama
2009-04-21 22:03:45 UTC
Permalink
On Mon, 20 Apr 2009 16:09:09 +0900, Walter Bright
Post by Walter Bright
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Range is so cool!

Though...
I tried following code:

void main()
{
writeln("Case1");
{
Mt19937 gen = Mt19937(0);
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen = Mt19937(0);
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("?nCase2");
{
Mt19937 gen;
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen;
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
}

Result:

Case1
2357136044 (1)
2546248239 (2)
---
2546248239 (2)
3071714933 (3)

Case2
581869302 (1)
3890346734 (2)
---
581869302 (1)?
3890346734 (2)?

I think 'Case1' is correct, but 'Case2' is wrong.
Mt19937's bug?
--
tama <repeatedly at gmail.com>
http://profile.livedoor.com/repeatedly/
???????
http://tpf.techtalk.jp/
Continue reading on narkive:
Loading...