Re: gdc-4.5 testing
Iain Buclaw wrote:
> Just announcing (before I nod off) that gdc is working with gcc-4.5.1. Builds
> D1
> and compiles Tango.
>
> Commit:
> https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa
>
> Feedback, patches and bug reports welcome!
>
I was unable to compile it (ArchLinux 64 bits). Apparently it fails
when building Phobos:
> mkdir -p gcc/config
> mkdir -p x86_64-unknown-linux-gnu/gcc/config
> touch stamp-tgtdir
> cp frag-ac x86_64-unknown-linux-gnu/gcc/config/config.d
> gcc -march=k8-sse3 -O2 -pipe -g -Wall -I
> ../../../gcc-4.5.1-build/libphobos/../include -c -o config/x3.o
> ../../../gcc-4.5.1-build/libphobos/config/x3.c
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> make[3]: *** [config/x3.o] Error 1
> make[3]: Leaving directory
> `/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory
> `/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos'
> make[1]: *** [all-target-libphobos] Error 2
> make[1]: Leaving directory `/home/jerome/abs/gdc1-hg/src/gcc-build'
> make: *** [all] Error 2
> Aborting...
I tried going to the x86_64-unknown-linux-gnu/libphobos folder and
typing the failing gcc command manually, it fails too. Then I tried
going to that folder and compiling a simple hello world and I got
the same result (the hello world compiles fine in another folder).
Finally, I ran the command under strace and here is the relevant
part of the trace:
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/lto-wrapper",
> 0x7fff09206310) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/cc1",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.5.1/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> stat("/home/jerome/abs/gdc1-hg/src/gcc-build/x86_64-unknown-linux-gnu/libphobos/../lib/gcc/x86_64-unknown-linux-gnu/4.5.1/../../../../x86_64-unknown-linux-gnu/bin/as",
> 0x7fff09206230) = -1 ENOENT (No such file or directory)
> pipe([3, 4])= 0
> vfork(gcc: error trying to exec 'cc1': execvp: No such file or directory
> ) = 8557
It appears that gcc looks for cc1 in the wrong location. It should
either take the system one
(/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/cc1) or one of those it
compiled itself (gcc/cc1 prev-gcc/cc1 stage1-gcc/cc1).
The build was configured with:
> ../gcc-4.5.1/configure --prefix=/usr \
> --enable-languages=d --enable-threads --enable-__cxa_atexit \
> --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib \
> --disable-shared
> make
I also tried adding C (--enable-languages=c,d) to no avail.
Jerome
PS: followups to D.gnu
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Why Ruby?
On Sat, 18 Dec 2010 18:13:50 -0800
Walter Bright wrote:
> > you could write:
> > sort!(@1>@2)(x);
> [...]
> > I think this idea (or something similar) is worth consideration. It is
> > simply a small extension to an already existing feature that would give D
> > a terser syntax for lambda's than most of the other languages we've been
> > discussing.
>
> but:
>
> sort!("a>b")(x);
>
> is just as short! And it already works.
Short, but wrong. I mean conceptually. In-code string representation of code is
wrong. I cannot explain why, but something in me refuses that. Seems I'm not
the only one.
What's the point? Dunno exactly, but I won't ever use this form. Reminds me of
magic Basic
f = input("function? ") eg: "2*x + 3"
FOR x = 1 TO 1000
y = eval(f)
plot(x,y)
ENDIF
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
syntax for anonymous func(was: Re: Why Ruby?)
On Sun, 19 Dec 2010 01:24:43 + (UTC)
JRM wrote:
> On Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:
> > If size and simplicity of typing are critical, are those really better
> > than:
> >
> >"a>b"
> >
> > ?
>
> I agree that those aren't really much better.
> This entire discussion seems a little odd to me. People are trying to
> find a way to more easily write lambda's, focusing in particular on
> single expression lambda's. This happens to be the one case D already
> has a short syntax for.
>
> In order to support lazy, D already allows an expression to be implicitly
> converted to a delegate returning either void or the type of the
> expression. This covers the case of lambda's taking no arguments, and
> happens to be shorter than any of the proposed syntaxes.
>
> The only issue with this is support for delegates taking arguments. To
> do that, I suggest D define numbered placeholders, similar to those found
> in C++ (tr1 and 0x) and std.bind. When found in an expression that is
> being implicitly cast to a delegate, the placeholders will represent the
> delegate's arguments.
>
> In your "a>b" example, the expression @1>@2 would be converted to the
> delegate:
>
> bool delegate(arg1, arg2) { return arg1>arg2; }
>
> So in actual use, instead of writing:
> sort!((a, b) { return a > b; })(x);
> you could write:
> sort!(@1>@2)(x);
>
> This would make a single-expression lambda almost identical to the string-
> based expressions currently being used. It is similar to the Scala
> example mentioned earlier in this thread (i.e. _ > _), but it allows for
> arbitrary use of the arguments without resorting to named parameters.
> For instance, the Scala form doesn't allow you to use a single parameter
> more than once and it requires the arguments to be used in order. With
> this syntax, we could easily do things like @1...@1 or @2...@1 without
> resorting to named parameters.
>
> I think this idea (or something similar) is worth consideration. It is
> simply a small extension to an already existing feature that would give D
> a terser syntax for lambda's than most of the other languages we've been
> discussing.
If this form, or a form close to it, is syntactically OK, I vote for it :-)
One thousand of "NO!" to any kind of string representation of code. (gut
feeling)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Purity
Andrei Alexandrescu wrote: On 12/17/10 1:42 AM, bearophile wrote: http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/ Bye, bearophile This is an excellent article, which is reflected in high reddit vote and a spirited but troll-free discussion. A homerun! We need more of this stuff. Congratulations, Leonardo! I agree. Nice job!
Re: Inlining Code Test
On Sat, 18 Dec 2010 02:17:46 +0100
Don wrote:
> Nick Voronin wrote:
> > btw, is there no explicit alignment for variables in D at all?
> > align(8) double d; compiles if d is global, but it does nothing.
>
> That's a regression. Large globals are always aligned to a 16-byte
> boundary (see changelog for 2.007)
On second thought large globals in static segment (as log says) are probably
only those with __gshared prefix. And they do look aligned.
> However this code:
>
> import core.stdc.stdio: printf;
>
> int a;
> double[4] d;
>
> void main() {
> printf("%u %u\n", (cast(size_t)&a) % 8, (cast(size_t)&d) % 8);
> }
> shows that it stopped doing that somewhere between 2.027 and 2.030.
--
Nick Voronin
Re: is it possible to learn D(2)?
On 12/18/10 3:44 PM, Jeff Nowakowski wrote: On 12/18/2010 03:16 PM, Don wrote: Jeff Nowakowski wrote: D2 has *never* been officially released (like D1 was), though its release was supposed to coincide with the release of Andrei's book. Where did you get that idea? I've never heard it before. (Genuine question, I'd like to know where that impression came from). Which idea are you questioning? That D2 hasn't been "released", or that the two were supposed to come out together? The answer to both would be the newsgroup. There was plenty of talk about them coming out together, and then time went by, and Andrei's book was relatively quietly released (unless I missed some big announcement; my memory was of posts trickling in of people who had pre-ordered), and no mention was made of D2 being released any more along with the book. I can dig up posts if you like, but I'd rather not unless any of this is in dispute. I don't think it's worth investigating this, but at any rate my thinking has been that finalizing TDPL would finalize the specification of D2. Of course, ideally the compiler would follow the specification as closely as possible, but with the number of extant issues it has always been pretty clear that conformance will be trailing. The book hasn't been released quietly at all; I've sent numerous updates to this group (just search for TDPL in the title) and my website has made the event as prominent as it could. As it was clearly highly anticipated in this group, laying it any thicker would have been inappropriate. Walter and Andrei haven't been very honest in their presentations on the state of the language. I think the initial estimate of how long things would take was wildly optimistic. I am certain that there's been no intention to be dishonest, at any stage. Andrei gives other people a lot of shit over only showing the positive in their presentations. Both Andrei and Walter have misrepresented the open source compiler issues on their slides (and Walter had no excuse after Andrei was called for it on the newsgroup). I saw Andrei's Google presentation and he talked a lot about D2 features and gave away a lot of books, but never once said that D2 was still being implemented and that serious bugs remained. A fair point. Well I didn't give away "a lot" of books, I gave three, and specifically for the three most embarrassing questions. (My budget of giveaway books is fairly limited.) Another thing would be that I tend to focus on language power, because that's perennial, and consider implementation bugs something transitory. As of today I can't offhand think of a feature in TDPL that we don't know how to implement in D, and that topic is important. Andrei
Re: Purity
On 12/17/10 1:42 AM, bearophile wrote: http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/ Bye, bearophile This is an excellent article, which is reflected in high reddit vote and a spirited but troll-free discussion. A homerun! We need more of this stuff. Congratulations, Leonardo! Andrei
Re: Why Ruby?
Oh my.. Gmail is giving me a headache. Sorry guys. :)
Re: Why Ruby?
Argh it started a new topic. Disregard this I'll reply to original thread.
On 12/19/10, Andrej Mitrovic wrote:
> On 12/19/10, Nick Sabalausky wrote:
>>
>> int foo(int x) { ... }
>> map!"foo(a) * 2" // Trivial lambda, but it fails
>
> Currently this will call unaryFunImpl, which tries to evaluate foo(a)
> at compile-time, but foo isn't visible from std.functional, where
> unaryFunImpl is defined.
>
> I don't know, maybe Phobos could construct a closure out of the string
> somehow if it detected that there's a function call in that string,
> here's some pseudocode modified from std.functional:
>
> template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
> {
> static if (is(typeof(fun) : string))
> {
> // added: detect if there's a function call in that string
> static if (hasFunctionCalls(fun))
> {
> // if so construct a closure, and that should be it
> alias newclosure result;
> }
> else
> {
> // Otherwise do as usual in std.functional.unaryFunImpl
> template Body(ElementType)
> {
> }
> // old code...
> }
> }
> else
> {
> alias fun result;
> }
> }
>
Re: Why Ruby?
Currently this will call unaryFunImpl, which tries to evaluate foo(a)
at compile-time, but foo isn't visible from std.functional, where
unaryFunImpl is defined.
I don't know, maybe Phobos could construct a closure out of the string
somehow if it detected that there's a function call in that string,
here's some pseudocode modified from std.functional:
template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
{
static if (is(typeof(fun) : string))
{
// added: detect if there's a function call in that string
static if (hasFunctionCalls(fun))
{
// if so construct a closure, and that should be it
alias newclosure result;
}
else
{
// Otherwise do as usual in std.functional.unaryFunImpl
template Body(ElementType)
{
}
// old code...
}
}
else
{
alias fun result;
}
}
On 12/19/10, Nick Sabalausky wrote:
> "Walter Bright" wrote in message
> news:iejl6i$16f...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> Yes, because in practice "a>b" must end up being evaluated in the wrong
>>> scope. I've used std.algorithm very little so far, and yet I've still
>>> found that limitation to be a problem.
>>
>> But it works fine for trivial lambdas, and if you're going beyond that,
>> there's the fuller, complete syntax.
>
> int foo(int x) { ... }
> map!"foo(a) * 2" // Trivial lambda, but it fails
>
> void bar(int delegate(int) dg) { ... }
> bar("a+7") // Also fails
>
> I don't think it's at all unreasonable to expect both of those to work with
> a short lambda syntax. That neither of them do I think is a clear sign that
> it's more of a clever hack than a real solution.
>
>
>
Re: Why Ruby?
On 12/19/10, Nick Sabalausky wrote:
>
> int foo(int x) { ... }
> map!"foo(a) * 2" // Trivial lambda, but it fails
Currently this will call unaryFunImpl, which tries to evaluate foo(a)
at compile-time, but foo isn't visible from std.functional, where
unaryFunImpl is defined.
I don't know, maybe Phobos could construct a closure out of the string
somehow if it detected that there's a function call in that string,
here's some pseudocode modified from std.functional:
template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
{
static if (is(typeof(fun) : string))
{
// added: detect if there's a function call in that string
static if (hasFunctionCalls(fun))
{
// if so construct a closure, and that should be it
alias newclosure result;
}
else
{
// Otherwise do as usual in std.functional.unaryFunImpl
template Body(ElementType)
{
}
// old code...
}
}
else
{
alias fun result;
}
}
Re: Why Ruby?
"Walter Bright" wrote in message
news:iejl6i$16f...@digitalmars.com...
> Nick Sabalausky wrote:
>> Yes, because in practice "a>b" must end up being evaluated in the wrong
>> scope. I've used std.algorithm very little so far, and yet I've still
>> found that limitation to be a problem.
>
> But it works fine for trivial lambdas, and if you're going beyond that,
> there's the fuller, complete syntax.
int foo(int x) { ... }
map!"foo(a) * 2" // Trivial lambda, but it fails
void bar(int delegate(int) dg) { ... }
bar("a+7") // Also fails
I don't think it's at all unreasonable to expect both of those to work with
a short lambda syntax. That neither of them do I think is a clear sign that
it's more of a clever hack than a real solution.
Re: Why Ruby?
JRM wrote:
you could write:
sort!(@1>@2)(x);
[...]
I think this idea (or something similar) is worth consideration. It is
simply a small extension to an already existing feature that would give D
a terser syntax for lambda's than most of the other languages we've been
discussing.
but:
sort!("a>b")(x);
is just as short! And it already works.
Re: Why Ruby?
On Sun, 19 Dec 2010 02:35:16 +0100, Andrej Mitrovic wrote: > imo, those @'s (or monkeys, as we like to call them) are a sore pain in > the eye. And what if you need to do some simple arithmetic with the > numbered arguments? > > someFunc!(@1+1>@2)(x); > > Might be a silly example, but code like this could exist and will be > confusing. > I agree that all the @'s aren't too easy to read. I might prefer _1, _2, etc. I think someFunc!(_1 + 1 > _2)(x); is a little bit easier on the eyes. But in general, the purpose of a short lambda syntax is to make it easier to read and write simple expressions. If the expression becomes complex enough that they become too difficult to read, there is always the option of writing the full delegate syntax. No matter what, I think some sort of placeholder syntax to shorten the common lambda's (whether it be @1, _1, _a, or something else) would be helpful.
Re: Why Ruby?
imo, those @'s (or monkeys, as we like to call them) are a sore pain in the eye. And what if you need to do some simple arithmetic with the numbered arguments? someFunc!(@1+1>@2)(x); Might be a silly example, but code like this could exist and will be confusing. On 12/19/10, Andrej Mitrovic wrote: > On 12/19/10, Walter Bright wrote: >> Nick Sabalausky wrote: >>> Yes, because in practice "a>b" must end up being evaluated in the wrong >>> scope. I've used std.algorithm very little so far, and yet I've still >>> found >>> that limitation to be a problem. >> >> ..and if you're going beyond that, >> there's >> the fuller, complete syntax. >> > > Exactly. Inventing a whole new syntax or borrowing some kind of > functional-language style syntax would only alienate those already > familiar with C syntax. >
Re: Why Ruby?
On 12/19/10, Walter Bright wrote: > Nick Sabalausky wrote: >> Yes, because in practice "a>b" must end up being evaluated in the wrong >> scope. I've used std.algorithm very little so far, and yet I've still >> found >> that limitation to be a problem. > > ..and if you're going beyond that, > there's > the fuller, complete syntax. > Exactly. Inventing a whole new syntax or borrowing some kind of functional-language style syntax would only alienate those already familiar with C syntax.
Re: Why Ruby?
On Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:
> Simen kjaeraas wrote:
>> The problem of D's lambda syntax is it is optimized for longer
>> functions. Usually, the delegates I write are one line long. I cannot
>> see that this syntax collides with anything at the moment, but feel
>> free to enlighten me:
>>
>> { => 4; }
>> { a => 2*a; }
>> { a, b => a>b; }
>> { => @ + @; } // turns into { a, b => a + b; }
>>
>>
> If size and simplicity of typing are critical, are those really better
> than:
>
>"a>b"
>
> ?
I agree that those aren't really much better.
This entire discussion seems a little odd to me. People are trying to
find a way to more easily write lambda's, focusing in particular on
single expression lambda's. This happens to be the one case D already
has a short syntax for.
In order to support lazy, D already allows an expression to be implicitly
converted to a delegate returning either void or the type of the
expression. This covers the case of lambda's taking no arguments, and
happens to be shorter than any of the proposed syntaxes.
The only issue with this is support for delegates taking arguments. To
do that, I suggest D define numbered placeholders, similar to those found
in C++ (tr1 and 0x) and std.bind. When found in an expression that is
being implicitly cast to a delegate, the placeholders will represent the
delegate's arguments.
In your "a>b" example, the expression @1>@2 would be converted to the
delegate:
bool delegate(arg1, arg2) { return arg1>arg2; }
So in actual use, instead of writing:
sort!((a, b) { return a > b; })(x);
you could write:
sort!(@1>@2)(x);
This would make a single-expression lambda almost identical to the string-
based expressions currently being used. It is similar to the Scala
example mentioned earlier in this thread (i.e. _ > _), but it allows for
arbitrary use of the arguments without resorting to named parameters.
For instance, the Scala form doesn't allow you to use a single parameter
more than once and it requires the arguments to be used in order. With
this syntax, we could easily do things like @1...@1 or @2...@1 without
resorting to named parameters.
I think this idea (or something similar) is worth consideration. It is
simply a small extension to an already existing feature that would give D
a terser syntax for lambda's than most of the other languages we've been
discussing.
Re: Why Ruby?
Nick Sabalausky wrote: Yes, because in practice "a>b" must end up being evaluated in the wrong scope. I've used std.algorithm very little so far, and yet I've still found that limitation to be a problem. But it works fine for trivial lambdas, and if you're going beyond that, there's the fuller, complete syntax.
Re: Why Ruby?
"Nick Sabalausky" wrote in message
news:iejimj$11q...@digitalmars.com...
> "Walter Bright" wrote in message
> news:ieji4j$10k...@digitalmars.com...
>> Simen kjaeraas wrote:
>>> The problem of D's lambda syntax is it is optimized for longer
>>> functions. Usually, the delegates I write are one line long. I cannot
>>> see that this syntax collides with anything at the moment, but feel free
>>> to enlighten me:
>>>
>>> { => 4; }
>>> { a => 2*a; }
>>> { a, b => a>b; }
>>> { => @ + @; } // turns into { a, b => a + b; }
>>>
>>
>> If size and simplicity of typing are critical, are those really better
>> than:
>>
>> "a>b"
>>
>> ?
>
> Yes, because in practice "a>b" must end up being evaluated in the wrong
> scope. I've used std.algorithm very little so far, and yet I've still
> found that limitation to be a problem.
>
> There's also the minor quibble that "a>b" doesn't get highlighted right,
> but that's obviously solvable with q{a>b}.
>
One other issue with the string: You can't pass it to a function that
expects an actual delegate. It may or may not be possible to make a
conversion function, but even if so, you'd lose the simplicity/brevity which
was the whole original point.
All in all, it's just platering over the problem.
Re: Why Ruby?
"Walter Bright" wrote in message
news:ieji4j$10k...@digitalmars.com...
> Simen kjaeraas wrote:
>> The problem of D's lambda syntax is it is optimized for longer
>> functions. Usually, the delegates I write are one line long. I cannot
>> see that this syntax collides with anything at the moment, but feel free
>> to enlighten me:
>>
>> { => 4; }
>> { a => 2*a; }
>> { a, b => a>b; }
>> { => @ + @; } // turns into { a, b => a + b; }
>>
>
> If size and simplicity of typing are critical, are those really better
> than:
>
> "a>b"
>
> ?
Yes, because in practice "a>b" must end up being evaluated in the wrong
scope. I've used std.algorithm very little so far, and yet I've still found
that limitation to be a problem.
There's also the minor quibble that "a>b" doesn't get highlighted right, but
that's obviously solvable with q{a>b}.
Re: Why Ruby?
Walter Bright: > If size and simplicity of typing are critical, are those really better than: > >"a>b" Strings used for that purpose are a hack/kludge. Bye, bearophile
Re: Why Ruby?
"Nick Sabalausky" wrote in message
news:ieji3n$10o...@digitalmars.com...
> "Walter Bright" wrote in message
> news:iejejo$pf...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> Any problem with the other Scala/C#-style one?:
>>>
>>> (x, y) => x * y
>>>
>>> // Lowered to:
>>>
>>> (x, y) { return x * y; }
>>>
>>> (Maybe that was rejected before due the the weird float operators that
>>> are now being ditched?)
>>
>> The problem with the (x,y) parameter lists, where x and y are the
>> parameters, is that it is ambiguous with the existing syntax of (x,y)
>> where x and y are types and the parameters are omitted.
>>
>> For example:
>>
>> void foo(int);
>
> But we already have:
>
>(x, y) { return x * y; }
>
> So either there aren't any problems with it after all, or D's existing
> delegate syntax is already broken.
>
> To be clear, with what I'm trying to suggest, the *only* thing that would
> be different from the current delegate literal syntax is that part *after*
> the parameter list. Ie:
>
>PARAM_LIST_HERE { return x * y; }
>// -->
>PARAM_LIST_HERE => x * y
>
> Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or
> whatever. I'm not suggesting the param list be different in any way
> fromhow t is now. (Although proposals from other people might differ.)
>
Slight correction: There is *one* other difference from the current delegate
literal syntax: The part after => must be an expression rather than a
statement or a block.
But again, I'm not suggesting any change to param list - except *maybe* to
make the param's parens omittable for zero-param or one-param delegates, but
*only* if there isn't a problem with that. I'm ok with keeping them if they
really still need to be there in those cases.
Re: Why Ruby?
Simen kjaeraas wrote:
The problem of D's lambda syntax is it is optimized for longer
functions. Usually, the delegates I write are one line long. I cannot
see that this syntax collides with anything at the moment, but feel free
to enlighten me:
{ => 4; }
{ a => 2*a; }
{ a, b => a>b; }
{ => @ + @; } // turns into { a, b => a + b; }
If size and simplicity of typing are critical, are those really better than:
"a>b"
?
Re: Why Ruby?
"Walter Bright" wrote in message
news:iejejo$pf...@digitalmars.com...
> Nick Sabalausky wrote:
>> Any problem with the other Scala/C#-style one?:
>>
>> (x, y) => x * y
>>
>> // Lowered to:
>>
>> (x, y) { return x * y; }
>>
>> (Maybe that was rejected before due the the weird float operators that
>> are now being ditched?)
>
> The problem with the (x,y) parameter lists, where x and y are the
> parameters, is that it is ambiguous with the existing syntax of (x,y)
> where x and y are types and the parameters are omitted.
>
> For example:
>
> void foo(int);
But we already have:
(x, y) { return x * y; }
So either there aren't any problems with it after all, or D's existing
delegate syntax is already broken.
To be clear, with what I'm trying to suggest, the *only* thing that would be
different from the current delegate literal syntax is that part *after* the
parameter list. Ie:
PARAM_LIST_HERE { return x * y; }
// -->
PARAM_LIST_HERE => x * y
Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or
whatever. I'm not suggesting the param list be different in any way fromhow
t is now. (Although proposals from other people might differ.)
Re: Purity
Steven Schveighoffer: > you sort of lost me at the SPARK example, I don't like C++ a lot because it's sometimes too much hard to understand/remember for me, and I don't like C much because it's too much bug prone for me. I think D shares some of the design philosophy of Ada (despite D2 is more bug-prone and less defined/deterministic than Ada). > but I want to particularly note some inaccuracies that you have. Going to be fixed. Bye, bearophile
Re: Threads and static initialization.
On Sat, 18 Dec 2010 15:04:38 -0700, Michel Fortin wrote: On 2010-12-18 15:57:50 -0500, "Robert Jacques" said: On Sat, 18 Dec 2010 03:27:22 -0700, Pelle Månsson wrote: On 12/18/2010 10:00 AM, Jonathan M Davis wrote: The problem is that the OP wants the static constructors to be skipped. If they're skipped, anything and everything which could be affected by that can't be used. That pretty much means not using TLS, since the compiler isn't going to be able to track down which variables in TLS will or won't be affected by it. So, you're stuck using shared memory only. _That_ is where the problem comes in. Exactly, not using TLS. You can still use the heap, as it is not thread local. Meaning you can create non-shared anything all you like, as long as you're not using TLS. Except that the 'heap' internally uses TLS. The GC does need and use TLS. Using D's TLS for the GC is an implementation choice, not a requirement. If someone wants to optimize 'spawn' for pure functions by skipping D's TLS initialization, he can make the GC and the array appending cache work with that. Not really, as _every_ modern GC requires TLS. And we're talking about a performance optimization here: not supporting modern GCs in order to remove TLS initialization would be a penny-wise pound foolish move. Besides, 'mini' threads shouldn't be created using OS threads; that's what thread-pools, fibers and tasks are for.
Re: New syntax for string mixins
"Don" wrote in message news:iej7eu$b1...@digitalmars.com... > Nick Sabalausky wrote: >> "foobar" wrote in message >> news:ieijt6$21m...@digitalmars.com... >>> I don't see how there needs to be different code to accomplish the above >>> use case. You have a function that tests the hardware it's being run on. >>> When this function is called in the compiler context it would return X, >>> when it's called from the target executable it returns Y. >>> >> >> The problem with that is, what if you're generating >> target-platform-specific code at compile-time? You'd be generating code >> for the wrong platform. I think VladD2 is right: You need to keep track >> of both "current" system and "target" system. Unfortunately, there is >> some information about the "target" system the compile-time code wouldn't >> be able discern without giving it the ability to run code (RPC? >> Virtualization? Really, really good emulator?) on the target system, but >> then again, that's a limitation with any cross-compiling scenario. > > Note that for this to work at all, the compiler needs to be able to > generate exectuable code for platform X as well as for Y -- that is, it > needs to include two back-ends. > But if the compiler doesn't have both backends then the whole question of "how does the user's compile-time code get handled if it's being cross-compiled?" becomes irrelevent - you'd have to compile it on the target plaform anyway, so X == Y. Or am I missing your point? I'm also scared of the implications of allowing arbitrary code execution during compilation. Make a typo in your program, and then compilation may wipe files from your hard disk, or corrupt an external database, etc... On some platforms you may be able to sandbox it, but since it's running as part of the compilation process, rather than with the permissions it will eventually have, it just seems like a security nightmare. >> >> That's an interesting point. OTOH, it's common for software to come with >> its own build script or makefile, and those can certainly do literally >> anything like you describe above - but I haven't seen that as being a >> real problem. > > I don't think it's quite the same. In a makefile, every executable is > listed, and so you can have some degree of control over it. But in this > scenario, the compiler is making calls to arbitrary shared libraries with > arbitrary parameters. > It means the compiler cannot be trusted *at all*. I suppose that's a reasonable point.
Re: executable size
On 18.12.2010 19:07, jovo wrote: Hi, Today I compiled my old two module console program with d-2.50. It uses only std.c.time, std.c.stdio, std.random and templates. Compiled with -O -release, on windows. Executable size (d-2.50): 4.184 kb. Trayed with d-1.30: 84 kb. Is it expected? I'm guessing the new version of std.random pulls in almost all of the rest of phobos, directly or indirectly. This is common throughout phobos, and means that if you want a small executable, you have to stick with basically just the C core.c.* (or std.c.*) stuff. Unless you want to custom build Phobos, of course... If you really need a small executable, use Tango instead of Phobos.
Re: emscripten
"Jeff Nowakowski" wrote in message news:iejblg$jl...@digitalmars.com... > On 12/18/2010 01:49 PM, Nick Sabalausky wrote: >> >> Ok, so why would I want to turn JS on and put up with those shitty >> browser-killing, user-experience-killing JS Ads just for a calculator >> that >> obviously doesn't need it? > > Do as you please. I find it trivial to enable specific pages with > NoScript. I never said turning it was too difficult. Sure it's easy to turn on JS with NoScript. And sometimes I do. Problem is, that frequently turns on a bunch of other crap on the page leaving the page nearly unusable, or at least far less usable. Therefore, it would be far better not to have to. > The question is why should the web author spend extra time for a tiny > minority of users that get up in arms? > The situation does not boil down to that. Like Adam pointed out, it's easy to just do it on the server, and then it works just fine for everyone. And if you *really* want some JS niceties for the tiny minority that actually give a crap about not needing a page or iframe reload, then nothing's stopping you from doing so (and yes, that *is* a tiny minority - they're just very very vocal). So, you could do it the, I'm not going to claim it's a good way, it really is a shitty way (response/request/server scripting) that only excludes the tiny minority of users that get up in arms over a page reload, or you can exclude the non-sheep people just for the sake of being able to use something that's even shittier (JS/AJAX/etc.) > You talk about dinosaurs and being pretentious in another thread, but > you're the biggest curmudgeon on the newsgroup. Even I have learned to > live with JavaScript, and I used to hate it just as much as you. Saying that videogames are dishonorable and provide no benefit to society is idiocy (and in a fairly pompous way; and it is a fallacy that's primarily exhibited by older generations). Saying that it's good to require JS for things that don't need JS is also idiocy (but in a more technical way; and it seems to be more prevailent among newer developers). To claim that's a hypocritical inconsistency inherently implies that dumb notions can't exist in both new and old varieties - that there can only be bad things about the new or that there can only be bad things about the old. Of course there can be both, why wouldn't that be possible? I definitely don't deny being the biggest curmudgeon on the newsgroup. But I don't see that as bad: People generally swallow far too much crap (unless I'm the one dishing stuff out, in which case everyone pounces on me if I get even the slightest thing less-than-perfect...or perhaps more accurately: if it's anything less-than-popular).
Re: [OT] Mozilla Thunderbird
On 18.12.2010 19:40, Nick Sabalausky wrote: "torhu" wrote in message news:iehd51$2gl...@digitalmars.com... [...] I don't mean to sound like an Outlook Express evangelist constantly banging an OE drum, but I've been using OE for years and never had any issues like that. Which actually makes me really puzzed, even though TBird's and OE's uses and basic interfaces are very similar: - Thunderbird apparently has *data loss/corruption* issues, and yet it's very popular. - OE *doesn't* have data loss/corruption issues, and yet it's widely looked-down upon. So what's wrong with this picture? IIRC, I decided against using EO because I wasn't satisfied with its keyboard navigation. TB is has good keyboard navigation, bar a couple of bugs that you learn to work around. I suppose the dataloss issues could be caused by my profile being old. Can't remember if I've tried starting with a new profile or not to fix the issues, but I think I have. I wouldn't be surprised if the newsgroup implementation is buggy. I guess I don't expect starting with a clean profile over again to actually help.
Re: Why Ruby?
Walter Bright wrote:
Jacob Carlborg wrote:
foo(x, y => x * y);
The problem with all these is what is the difference between:
{ x * y }
{ x * y; } <== note the ;
{ return x * y; }
The problem of D's lambda syntax is it is optimized for longer
functions. Usually, the delegates I write are one line long. I cannot
see that this syntax collides with anything at the moment, but feel free
to enlighten me:
{ => 4; }
{ a => 2*a; }
{ a, b => a>b; }
{ => @ + @; } // turns into { a, b => a + b; }
--
Simen
Re: is it possible to learn D(2)?
"Jeff Nowakowski" wrote in message news:ieja3o$gf...@digitalmars.com... > On 12/18/2010 03:16 PM, Don wrote: >> Jeff Nowakowski wrote: >>> D2 has *never* been officially released (like D1 was), though its >>> release was supposed to coincide with the release of Andrei's book. >> >> Where did you get that idea? I've never heard it before. >> (Genuine question, I'd like to know where that impression came from). > > Which idea are you questioning? That D2 hasn't been "released", or that > the two were supposed to come out together? The answer to both would be > the newsgroup. > > There was plenty of talk about them coming out together, and then time > went by, and Andrei's book was relatively quietly released (unless I > missed some big announcement; my memory was of posts trickling in of > people who had pre-ordered), and no mention was made of D2 being released > any more along with the book. > I only remember the talk being about the D2 language spec getting frozen from breaking changes when the book came out. And that's happened.
Re: Why Ruby?
Nick Sabalausky wrote:
Any problem with the other Scala/C#-style one?:
(x, y) => x * y
// Lowered to:
(x, y) { return x * y; }
(Maybe that was rejected before due the the weird float operators that are
now being ditched?)
The problem with the (x,y) parameter lists, where x and y are the parameters, is
that it is ambiguous with the existing syntax of (x,y) where x and y are types
and the parameters are omitted.
For example:
void foo(int);
Re: Why Ruby?
Jacob Carlborg wrote:
foo(x, y => x * y);
The problem with all these is what is the difference between:
{ x * y }
{ x * y; } <== note the ;
{ return x * y; }
The C++ lambda group had the same discussions.
It may not seem like much when the code is trivial, but when it gets more
complex, having 2 or 3 different syntaxes for function bodies seems like a
confusing disaster in the making.
Re: emscripten
Do as you please. I find it trivial to enable specific pages with NoScript. The question is why should the web author spend extra time for a tiny minority of users that get up in arms? You talk about dinosaurs and being pretentious in another thread, but you're the biggest curmudgeon on the newsgroup. Even I have learned to live with JavaScript, and I used to hate it just as much as you. Funny, i think the word "dinosaur" is a compliment. Because mostly "lamer"s call someone dinosaur (Didn't see how Nick used it though). Oh still using that phone? Oh my, you don't have a ### account? Dinosaur! -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why Ruby?
loser wrote: It might even be the case that Walter is too incompetent Guilty as charged.
Re: emscripten
On 12/18/2010 01:49 PM, Nick Sabalausky wrote: Ok, so why would I want to turn JS on and put up with those shitty browser-killing, user-experience-killing JS Ads just for a calculator that obviously doesn't need it? Do as you please. I find it trivial to enable specific pages with NoScript. The question is why should the web author spend extra time for a tiny minority of users that get up in arms? You talk about dinosaurs and being pretentious in another thread, but you're the biggest curmudgeon on the newsgroup. Even I have learned to live with JavaScript, and I used to hate it just as much as you.
Re: Threads and static initialization.
On 2010-12-18 15:57:50 -0500, "Robert Jacques" said: On Sat, 18 Dec 2010 03:27:22 -0700, Pelle Månsson wrote: On 12/18/2010 10:00 AM, Jonathan M Davis wrote: The problem is that the OP wants the static constructors to be skipped. If they're skipped, anything and everything which could be affected by that can't be used. That pretty much means not using TLS, since the compiler isn't going to be able to track down which variables in TLS will or won't be affected by it. So, you're stuck using shared memory only. _That_ is where the problem comes in. Exactly, not using TLS. You can still use the heap, as it is not thread local. Meaning you can create non-shared anything all you like, as long as you're not using TLS. Except that the 'heap' internally uses TLS. The GC does need and use TLS. Using D's TLS for the GC is an implementation choice, not a requirement. If someone wants to optimize 'spawn' for pure functions by skipping D's TLS initialization, he can make the GC and the array appending cache work with that. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: emscripten
Nick Sabalausky wrote:
> Also, I'm not convinced that that duplication can't be abstracted away.
I find some functions are easily copy/pasted from a server side
language out to the javascript. Though as it gets complex, it
needs more and more library support on both ends.
That's why I rarely bother trying with it in practice: writing
sharable code is easy, but just doing it on the server using the
full capabilities it has is /easier/, and its almost the same speed
as doing it in pure script anyway! The http submit and response
really doesn't take a very long time.
http://arsdnet.net/cgi-bin/noscript
Submit some stuff... not really slow. Doesn't even refresh the
whole page if your browser has iframe support, but no script.
And if your browser doesn't support iframes, it still works,
since it's just a standard form anyway.
Here's the source:
=
import arsd.cgi;
import arsd.sha;
void main() {
auto cgi = new Cgi;
scope(exit) cgi.close();
if("text" in cgi.get) {
cgi.write(hashToString(SHA256!string(cgi.get["text"])));
return;
}
cgi.write(`
Enter some text to hash:
`);
}
Trivial.
How much effort would it have been to do this in Javascript?
JS doesn't have the same library ecosystem available to it, nor
does it have the facilities to make things as simple as languages
like D. I've seen implementations of SHA256 in javascript. Pretty
ugly. Of course, my implementation is pretty ugly too, so maybe
that's a push!
Still, the main point is just that the server can do it really
easily anyway, and then it works for everyone, script or not. Might
as well just do it the easy way on the server.
(If you want to compile it yourself, grab the referenced modules
from here: http://arsdnet.net/dcode/ and use a command line
like so:
dmd noscript.d cgi.d sha.d -Idmd2/src/druntime/src/
dmd2/src/druntime/src/object_.d -d
Most that spam is to convince the associative array in cgi.d to
actually link. I think there's a bug somewhere in dmd or druntime, but this
works
around it.)
Re: Why Ruby?
Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:
> As Nick writes here the Scala/C#-style syntax is one suggestion. There
> are also several other syntaxes available, one just have to look at
> other languages to get ideas. Here's a list of the syntax used by a
> couple of different language, some languages are list more than once
> because they support more than one syntax. I've listed the languages in
> order from, what I think, the least verbose to the most verbose
> lambda/delegate syntax (the number in front of the languages is the
> level of verbose, if two languages are at the same level I think they
> are equally verbose).
>
> 1 D: foo(writeln(3)); // lazy argument
That's not really equivalent to lambdas. It would be unfair to not
mention Scala which also supports lazy arguments.
> 1 Scala: foo(_ * _)
This isn't the same. _ * _ is equivalent to (a, b) => a * b
1 Scala: foo(x => x * x)
> 2 C#: foo(x => x * x);
> 3 Scala: foo((x) => x * x)
foo(x => x * x) also works in this case
> 4 Python: foo(lambda x: x * x)
> 5 Ruby: foo { |bar| x * x }
Maybe you meant
foo { |x| x * x }
> 5 Ruby: foo do |x| x * x end
> 6 D: foo((int x) { return x * x; });
> 7 C++1x: foo([](int x){ return x * x; });
> 7 Apple's (Objective)-C(++)
> block extension: foo(^(int x){ return x * x; });
> 8 JavaScript:
> foo(function(x){ return x * x })
> 9 PHP: foo(function ($x) use($fooBar) {
> return $x * $x; }); // "use" is used for explicitly telling what
> variables should be available when the scope is gone.
>
> Note that I have not listed any functional languages here because I've
> never used one.
For example:
Lambda calculus: λx.x*x
Haskell: \x -> x * x
As you can see, most of the verbosity comes from the fact that lambdas in
D and C++ contain statements, not a single expression. It's like if-then-
else vs ternary ?: -- In languages like Scala these are the same built-in
feature.
Re: is it possible to learn D(2)?
On 12/18/2010 03:16 PM, Don wrote: Jeff Nowakowski wrote: D2 has *never* been officially released (like D1 was), though its release was supposed to coincide with the release of Andrei's book. Where did you get that idea? I've never heard it before. (Genuine question, I'd like to know where that impression came from). Which idea are you questioning? That D2 hasn't been "released", or that the two were supposed to come out together? The answer to both would be the newsgroup. There was plenty of talk about them coming out together, and then time went by, and Andrei's book was relatively quietly released (unless I missed some big announcement; my memory was of posts trickling in of people who had pre-ordered), and no mention was made of D2 being released any more along with the book. I can dig up posts if you like, but I'd rather not unless any of this is in dispute. Walter and Andrei haven't been very honest in their presentations on the state of the language. I think the initial estimate of how long things would take was wildly optimistic. I am certain that there's been no intention to be dishonest, at any stage. Andrei gives other people a lot of shit over only showing the positive in their presentations. Both Andrei and Walter have misrepresented the open source compiler issues on their slides (and Walter had no excuse after Andrei was called for it on the newsgroup). I saw Andrei's Google presentation and he talked a lot about D2 features and gave away a lot of books, but never once said that D2 was still being implemented and that serious bugs remained.
Re: Why Ruby?
On Sat, Dec 18, 2010 at 12:09 PM, Jacob Carlborg wrote: > > > Actually if it would be possible to skip the parentheses when the lambda > take more than one argument I would be more happy with that: > > foo(x, y => x * y); > > Pretty sure you'll need parenthesis. Should the above match: func(int function(int, int)) or func(int, int function(int))
Re: New syntax for string mixins
Nick Sabalausky wrote: "foobar" wrote in message news:ieijt6$21m...@digitalmars.com... Don Wrote: VladD2 wrote: Don Wrote: Suppose the pre-compiled code, when run, asks what CPU it's on. What's the answer? Is it X or Y? Current: X Target: Y Macro - a plugin to the compiler. It works on the same platform as the compiler, but generates code through the API which abstracts the macro from the target platform. If you need generate platform specific code, you should worry about it in macro logic. In any case macro is a meta-programm wich generate or/and transform code. Yes. But in D there's no distinction between code which is destined for a macro, versus any other function. You can call a function once at compile time, and the same function at compile time. I think you mean "You can call a function once at compile time, and the same function at **runtime**." My understanding of Nemerle (which is quite likely to be wrong!) is that at least some functions are callable only at compile-time. I'd be surprised. I would think that all you would have to do to use the same Nemerle function at both runtime and compile-time would be to include its module in both the "compile the compiler-plugin step" and in the "load compiler-plugins and compile the app" step. I don't see how there needs to be different code to accomplish the above use case. You have a function that tests the hardware it's being run on. When this function is called in the compiler context it would return X, when it's called from the target executable it returns Y. The problem with that is, what if you're generating target-platform-specific code at compile-time? You'd be generating code for the wrong platform. I think VladD2 is right: You need to keep track of both "current" system and "target" system. Unfortunately, there is some information about the "target" system the compile-time code wouldn't be able discern without giving it the ability to run code (RPC? Virtualization? Really, really good emulator?) on the target system, but then again, that's a limitation with any cross-compiling scenario. Note that for this to work at all, the compiler needs to be able to generate exectuable code for platform X as well as for Y -- that is, it needs to include two back-ends. I'm also scared of the implications of allowing arbitrary code execution during compilation. Make a typo in your program, and then compilation may wipe files from your hard disk, or corrupt an external database, etc... On some platforms you may be able to sandbox it, but since it's running as part of the compilation process, rather than with the permissions it will eventually have, it just seems like a security nightmare. That's an interesting point. OTOH, it's common for software to come with its own build script or makefile, and those can certainly do literally anything like you describe above - but I haven't seen that as being a real problem. I don't think it's quite the same. In a makefile, every executable is listed, and so you can have some degree of control over it. But in this scenario, the compiler is making calls to arbitrary shared libraries with arbitrary parameters. It means the compiler cannot be trusted *at all*.
Re: Threads and static initialization.
On Sat, 18 Dec 2010 03:27:22 -0700, Pelle Månsson wrote: On 12/18/2010 10:00 AM, Jonathan M Davis wrote: The problem is that the OP wants the static constructors to be skipped. If they're skipped, anything and everything which could be affected by that can't be used. That pretty much means not using TLS, since the compiler isn't going to be able to track down which variables in TLS will or won't be affected by it. So, you're stuck using shared memory only. _That_ is where the problem comes in. Exactly, not using TLS. You can still use the heap, as it is not thread local. Meaning you can create non-shared anything all you like, as long as you're not using TLS. Except that the 'heap' internally uses TLS. The GC does need and use TLS.
Re: Why Ruby?
bearophile wrote:
Jacob Carlborg:
1 D: foo(writeln(3)); // lazy argument
1 Scala: foo(_ * _)
2 C#: foo(x => x * x);
3 Scala: foo((x) => x * x)
4 Python: foo(lambda x: x * x)
5 Ruby: foo { |bar| x * x }
5 Ruby: foo do |x| x * x end
6 D: foo((int x) { return x * x; });
7 C++1x: foo([](int x){ return x * x; });
7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x *
x; });
8 JavaScript: foo(function(x){ return x * x })
9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is
used for explicitly telling what variables should be available when the
scope is gone.
(In D there are template lambdas too). This topic was discussed some in
past. I like a syntax similar to:
foo({x,y => x * y})
foo({int x, int y => x * y})
I really like this. The curly braces clearly show it to be a new scope,
and the syntax is concise and understandable.
--
Simen
Re: [OT] Mozilla Thunderbird
"sybrandy" wrote in message news:iej200$30n...@digitalmars.com... >> - Thunderbird apparently has *data loss/corruption* issues, and yet it's >> very popular. >> - OE *doesn't* have data loss/corruption issues, and yet it's widely >> looked-down upon. >> >> So what's wrong with this picture? > > I've never used OE as, well, I preferred Thunderbird, however I've never > experienced any data loss/corruption with Thunderbird. Perhaps it's not > the products themselves but something in the environment that's causing > the issue? > Hmm, perhaps so. > > On a side note, as for why OE is looked down upon, at least from my point > of view any environment where different pieces of software are so closely > tied together that it makes various types of virii very easy to > create/propagate is not one I want on my system. My word processor should > not control my email client and vice-versa. The worm issues were fixed ages ago. As for connections with word processor/etc, I haven't seen any indication of OE ever acting any less like a stand-alone app than anything else. (And actually, Thunderbird has a lot of ties to Firefox, AIUI). Maybe you're thinking of Outlook, not OE? > I'm the type of person that if I don't know that a piece of software is > being installed by company sysops, I'll report a virus since I was unaware > of the installation and I didn't do it myself. And yes, I have done that. > Heh heh, I like that. :)
Re: is it possible to learn D(2)?
Jeff Nowakowski wrote: On 12/18/2010 07:55 AM, Caligo wrote: If there is going to be a D3, will it be backwards compatible with D2? And why is work still being done on the D1 compiler? Shouldn't it be marked deprecated so people stop using it and move to D2? D1 is stable and only bug fixes are being applied to it. For D2, the post you replied to mentioned compiler bugs several times, and also mentioned unimplemented features. D2 has *never* been officially released (like D1 was), though its release was supposed to coincide with the release of Andrei's book. Where did you get that idea? I've never heard it before. (Genuine question, I'd like to know where that impression came from). The date kept on getting pushed further and further back, until finally the book came out (publishers only have so much patience), and no mention of D being released was made. Walter and Andrei haven't been very honest in their presentations on the state of the language. I think the initial estimate of how long things would take was wildly optimistic. I am certain that there's been no intention to be dishonest, at any stage. > I know a software project is never "finished", in that you can't expect perfection, but D2 is still in the alpha state. It's not reasonable for features documented in the definitive book on the language to not work. Agreed. Unfortunately, the publishers couldn't be delayed any further. There are a few things in the book which still don't work, and will take another couple of releases to be implemented. (A few months before release, the list of non-implemented features was quite long. Most of the things on the list _were_ implemented in time. A couple turned out to be unexpectedly difficult). Also, the crown jewel of D2 was supposed to be immutability and concurrency, and those are the buggiest parts. Well, they are the most difficult bits! So if anything were to be incomplete, it would be those.
Re: Game development is worthless? WTF? (Was: Why Ruby?)
"Nick Sabalausky" wrote in message news:iej46p$42...@digitalmars.com... > "Caligo" wrote in message > news:mailman.5.1292651710.4588.digitalmar...@puremagic.com... >> >> IMO there is no honor in game development as it contributes nothing to >> society. I've rarely played any, > > I gotta jump on this as being a giant load of pretentious bullshit. First > of all, there's the patently obvious "how in the world would you know?" > considering the "I've rarely played any". > > But more importantly, games make life suck less - I can't even imagine any > more significant contribution to society than that. Even all of the > endeavors generally considered to be the biggest contributions to society > are *only* significant contributions *because* that's exactly what they > do: they make life suck less, and are therefore well-regarded. > > Seriously, what up with all those presumptuous assholes out there (mostly > baby boomer dinos and their even more anachronistic parents, interestingly > enough) who have barely ever touched a videogame and yet figure they > actually have reason to believe such absurd pretentious crap? Fuck, they > all remind me of that pompous Roger Ebert douchebag. (Speaking of ways to > benefit society, when's he finally gonna keel over? Isn't it about time by > now? And speaking of "contributions to society" what the fuck's he ever > done? Collect a salary just to spout off opinions? Fucking useless > wanker.) > Since it apparently isn't obvious to some people: things don't have to be dull to qualify as a significant a contribution.
Game development is worthless? WTF? (Was: Why Ruby?)
"Caligo" wrote in message news:mailman.5.1292651710.4588.digitalmar...@puremagic.com... > > IMO there is no honor in game development as it contributes nothing to > society. I've rarely played any, I gotta jump on this as being a giant load of pretentous bullshit. First of all, there's the patently obvious "how in the world would you know?" considering the "I've rarely played any". But more importantly, games make life suck less - I can't even imagine any more significant contribution to society than that. Even all of the endevors generally considered to be the biggest contributions to society are *only* significant contributions *because* that's exactly what they do: they make life suck less, and are therefore well-regarded. Seriously, what up with all those presumptuous assholes out there (mostly baby boomer dinos and their even more anachronistic parents, interestingly enough) who have barely ever touched a videogame and yet figure they actually have reason to believe such absurd pretentous crap? Fuck, they all remind me of that pompous Roger Ebert douchebag. (Speaking of ways to benefit society, when's he finally gonna keel over? Isn't it about time by now? And speaking of "contributions to society" what the fuck's he ever done? Collect a salary just to spout off opinions? Fucking useless wanker.)
Re: Purity
spir wrote:
On Sat, 18 Dec 2010 13:46:11 +0100
Don wrote:
spir wrote:
On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis wrote:
Thank you for the explanation about strongly pure funcs calling weakly pure
ones --this fully makes sense.
I would like weakly pure to include output funcs, and exclude all
possibilities to modify (non-local) state.
The problem is that output is accessing global variables - which weakly pure
functions _cannot_ do.
Why? What is the rationale for excluding output (I don't mean I/O, only O)?
You're correct in saying that it doesn't affect the operation of the
program. But in practice, program output is almost always important.
For example, suppose we allowed output to be pure. Then consider:
writeln("Hello, world!");
Since it returns nothing, and has no influence on the future execution
of the program, the writeln can be dropped from the program.
Hmmm
For sure, if you specify (in the compiler behaviour) that the only purpose of a pure function is to return something.
Yes, that's what's done.
Which excudes all "action-fonctions" (= funcs which purpose is to perform an effect).
But why should the compiler rewrite of such a func be to erase it? Just let it alone, it won't bother anybody.
But if you do that, you lose most of the benefits of pure.
>And can safely be qualified as pure. So that, transitively, pure funcs
can call funcs that perform output. Just what we want.
You could do this -- but in order to preserve the usefulness of pure,
you'd need to introduce some way of flagging such functions. The
signature would need to indicate that it is a "action function".
pure Report getReport (Data data) {
// compute report from data (only)
log.write(report);
writefln("report computed:\n\t%s", report); // debug
return report;
}
Anyway, aside practicle & efficiency purposes,
I'm even more annoyed by the "conceptual wrongness" of excluding functions that perform
output from the "world of purity" ;-)
> I would want them included even if this did not buy anything.
I think you're assuming that including them costs nothing. But it does.
Including such functions destroys most of the benefits of pure. You do
need to treat them differently.
All of this would be easier and clearer if D made a proper distinction between
'true' functions (that compute a result) and 'action-functions' (that perform
an effect). The actual purity criteria need not be the same:
* actions must not write to state
* functions must not read from state
Just state: output ports and memory do not belong to program state, and we're
done.
Definitely you could do this. I suspect that it wouldn't be worth it,
though, because action functions are viral. Once a function is an action
function, everything which calls it is also an action function.
And from an optimisation perspective, there isn't much you can do with
action functions.
There is an asymmetry: runtime/variable data input (from user, file,...) must
be considered as state, else a compiler cannot memoize function results.
It also can't memoize the results of functions which call action functions.
But aside from all of this, I'm actually rather sceptical that output
can be done without using static variables. I cannot imagine how it
could be done.
It is an interesting point, that is particularly obvious at a low level.
For example, in DOS text mode, writing 'a' to 0xB000 wrote an 'a' in the
top left corner of the screen, even if the function never reads that
address. But writing 'a' to 0x5000 is not output!
Currently, a pure function cannot write to _any_ static variable. This
disallows a few obscure functions which could be considered to be
logically pure.
Ultimately, I think your definition of 'pure function' would be: never
reads from a static variable, and never writes to a static variable
which is ever read by another function;
and 'pure action function' would be: writes to an output port, or to a
never-read static variable which is designated as an output.
Again, although this could be done, I doubt that it's worth it. The
costs seem high and the benefits low.
Re: Why Ruby?
Jacob Carlborg:
> 1 D: foo(writeln(3)); // lazy argument
> 1 Scala: foo(_ * _)
> 2 C#: foo(x => x * x);
> 3 Scala: foo((x) => x * x)
> 4 Python: foo(lambda x: x * x)
> 5 Ruby: foo { |bar| x * x }
> 5 Ruby: foo do |x| x * x end
> 6 D: foo((int x) { return x * x; });
> 7 C++1x: foo([](int x){ return x * x; });
> 7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x * x; });
> 8 JavaScript: foo(function(x){ return x * x })
> 9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is
> used for explicitly telling what variables should be available when the
> scope is gone.
(In D there are template lambdas too). This topic was discussed some in past. I
like a syntax similar to:
foo({x,y => x * y})
foo({int x, int y => x * y})
Bye,
bearophile
Re: Why Ruby?
Peace! I just got tired of some marketing nonsense and had to address my frustration! Recently someone linked a blog post, guy was talking about i guess Python. He was working on a large, high performance software which uses C++ for its highperf tasks. This was going on for pages and guy was saying what a relief it has been. He could have just said "We scripted our large, high performance software" and save the time for himself and his readers. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why Ruby?
"Ary Borenszweig" wrote in message news:iegfii$ju...@digitalmars.com... > This is very serious. Walter and the rest always complain that C++ is very > hard to > understand, has a very long and verbose syntax and only "a few" can really > master > it. And look at that code. It's impossible to understand. One has to jump > from one > place to another, back and forth, wondering "Why that alias?" and so on. > The > nested depth of curly braces go beyond four and five sometimes. Oh, wait. > But I > can do "scope(exit) ..." and then I save myself one level. > > So imagine if it takes all that effort to understand what it is written, > how hard > it should have been to write it. Probably it's the result of "this doesn't > work, > let's try this as a hack" and everything ends up being a huge hack. > > Please, please, please, look back at what you've done and think hard if it > is > really the right way to go. Everything seems overly complex by now. > > FWIW, I understood it fairly easily, only took a few minutes, and I wasn't already familiar with the code for those modules before. But any C++ with anything like templates or STL just leaves me completely lost, and I practically grew up on C/C++. Not saying there couldn't be improvements of course, but I think it's still a far cry from C++-level.
Re: Why Ruby?
On 2010-12-18 20:03, JRM wrote:
On Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:
I would like a syntax that is a combination of D's lazy argument syntax
and C#'s lambda syntax. Basically like this:
If the lambda doesn't take have any parameters then you can just put the
expression between then the parentheses in the function call:
foo(writeln(3));
If the lambda have one parameter then the following syntax is used:
foo(x => x * x);
If the lambda takes more then one parameter then you have to use
parentheses around the lambda parameters like this:
foo((x, y) => x * y);
Actually if it would be possible to skip the parentheses when the lambda
take more than one argument I would be more happy with that:
foo(x, y => x * y);
Why not define numbered placeholders to avoid the need for named
arguments altogether.
Well, I can't think of all the syntaxes there possible can be :)
foo(@1 * @2);
//lowers to
foo((arg1, arg2) { return arg1 * arg2; });
It would be a fairly simple extension to the lazy argument syntax, and
cover most of the typical uses for short lambdas.
That doesn't look too bad, maybe somewhat confusing with numbers in the
names? And it might also be could to have a way to name the arguments
yourself.
--
/Jacob Carlborg
Re: Why Ruby?
"Don" wrote in message news:iegf5n$im...@digitalmars.com... > > It WAS discussed on the newsgroup, and that => syntax was discussed as > well. > (I didn't get involved in it, but it was quite public). I don't suppose you have a link to the => discussion?
Re: executable size
On 2010-12-18 19:25, Nick Sabalausky wrote: "jovo" wrote in message news:ieit9a$2n5...@digitalmars.com... Hi, Today I compiled my old two module console program with d-2.50. It uses only std.c.time, std.c.stdio, std.random and templates. Compiled with -O -release, on windows. Executable size (d-2.50): 4.184 kb. Trayed with d-1.30: 84 kb. Is it expected? Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code. Building the D runtime and the standard library as a dynamic library will get you the same executable size as a C executable, at least with D1 and Tango on Mac OS X. -- /Jacob Carlborg
Re: Why Ruby?
with no review of the discussion and no elaboration of the conclusion or why you came to the conclusion you did. I agree with this part. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: New syntax for string mixins
"foobar" wrote in message news:ieijt6$21m...@digitalmars.com... > Don Wrote: > >> VladD2 wrote: >> > Don Wrote: >> >> Suppose the pre-compiled code, when run, asks what CPU it's on. What's >> >> the answer? Is it X or Y? >> > >> > Current: X >> > Target: Y >> > >> > Macro - a plugin to the compiler. It works on the same platform as the >> > compiler, but generates code through the API which abstracts the macro >> > from the target platform. If you need generate platform specific code, >> > you should worry about it in macro logic. >> > In any case macro is a meta-programm wich generate or/and transform >> > code. >> >> Yes. But in D there's no distinction between code which is destined for >> a macro, versus any other function. You can call a function once at >> compile time, and the same function at compile time. I think you mean "You can call a function once at compile time, and the same function at **runtime**." >> My understanding of >> Nemerle (which is quite likely to be wrong!) is that at least some >> functions are callable only at compile-time. >> I'd be surprised. I would think that all you would have to do to use the same Nemerle function at both runtime and compile-time would be to include its module in both the "compile the compiler-plugin step" and in the "load compiler-plugins and compile the app" step. > > I don't see how there needs to be different code to accomplish the above > use case. You have a function that tests the hardware it's being run on. > When this function is called in the compiler context it would return X, > when it's called from the target executable it returns Y. > The problem with that is, what if you're generating target-platform-specific code at compile-time? You'd be generating code for the wrong platform. I think VladD2 is right: You need to keep track of both "current" system and "target" system. Unfortunately, there is some information about the "target" system the compile-time code wouldn't be able discern without giving it the ability to run code (RPC? Virtualization? Really, really good emulator?) on the target system, but then again, that's a limitation with any cross-compiling scenario. >> I'm also scared of the implications of allowing arbitrary code execution >> during compilation. Make a typo in your program, and then compilation >> may wipe files from your hard disk, or corrupt an external database, >> etc... On some platforms you may be able to sandbox it, but since it's >> running as part of the compilation process, rather than with the >> permissions it will eventually have, it just seems like a security >> nightmare. >> That's an interesting point. OTOH, it's common for software to come with its own build script or makefile, and those can certainly do literally anything like you describe above - but I haven't seen that as being a real problem. > > This is a void argument since templates are Turing complete. > It's *already* possible to do all of the above in D at compile time, it's > just a matter of how much code is required to accomplish this. > Not true. This is a frequent misconception about Turning-completeness. Just because something is Turing complete does *not* mean it can do anything that any other Turing complete system can do (contrary to how many college profs explain it). It *does* mean that it can *calculate* anything that any other Turing complete system can calculate. But it doesn't necessarily have *access* to everything that any other Turing complete system has access to. And D's compile-time system, whether CTFE or templates, does not currently provide any way to access any I/O, launch any processes, or do any direct memory access.
Re: Why Ruby?
On 2010-12-17 18:36, loser wrote: Andrei Alexandrescu Wrote: On 12/17/10 10:23 AM, Justin Johansson wrote: On 17/12/10 06:52, Andrei Alexandrescu wrote: On 12/16/10 1:30 PM, Jacob Carlborg wrote: The point here isn't that we want "a" and "b" to be replaced with "_" the point is that we want to get rid of the string and have a shorter and less verbose syntax for delegate literals. I understand. Using strings is witnessing the fact that we couldn't find a shorter syntax that didn't have problems. That being said, it's very possible there are some great ones, we just couldn't find them. Andrei "we just couldn't find them" Is that the royal "we" as in singular? If plural, may one politely inquire as to whom "we" are? Walter, Bartosz Milewski, Eric Niebler, David Held and myself have discussed the issue a number of times. It has also been often discussed on this newsgroup. I find few things odd. First, Eric and David are your C++ buddies. Why are you having this secret society instead of openly discussing D features in the D mailing lists? Invite them here, please. We are the community, we also have an opinion of this language. The C++ users' opinions are often very conservative and hostile towards ideas that don't resemble C++ syntax or aren't performance oriented. Evidently the D community in general wants a better lambda syntax, and the recently proposed feature is actually better than the currently used string hack, given a properly optimizing compiler. This has been discussed several times and every time your secret society tells that nothing could be found. We never hear what's the real reason blocking this. Why can't you spend that two minutes writing down your conclusions. It feels like you're not doing your job. Only two things come to my mind: 1) the proposed feature goes too far from C++ syntactically or semantically, 2) Walter cannot implement it probably because of some conflicting legacy C syntax or it requires too much changes in the compiler (== is not a low-hanging fruit => doesn't motivate him), 3) D 2.0 is already set in stone and you don't want to admit that further improvements are still needed in the near future (this would make your template/string lambda idiom and the D 2.0 feature set an embarrasing short sighted hack). Admit it Andrei, it has some problems. The different string parameters generate bloat in object code and the lookup issues are also bad. With a properly optimizing compiler the real la mbda can be optimized to generate equal object code without any of these problems. Not finding the solution is quite surprising considering that almost all other modern languages are finding more or less the same solution and every time a community member here suggests a solution, it's more or less the same. What are the problem you're having? I have to agree with this post. I've also got the feeling more than once that the community is excluded sometimes. The community often receives messages like "It's been discussed and the conclusion was we couldn't solve it/we couldn't find a better way/syntax..." with no review of the discussion and no elaboration of the conclusion or why you came to the conclusion you did. -- /Jacob Carlborg
Re: [OT] Mozilla Thunderbird
- Thunderbird apparently has *data loss/corruption* issues, and yet it's very popular. - OE *doesn't* have data loss/corruption issues, and yet it's widely looked-down upon. So what's wrong with this picture? I've never used OE as, well, I preferred Thunderbird, however I've never experienced any data loss/corruption with Thunderbird. Perhaps it's not the products themselves but something in the environment that's causing the issue? The only thing that I can say definitively is that I did a quick DuckDuckGo Search for ["outlook express" data loss corruption] and ["mozilla thunderbird" data loss corruption] (Search terms between brackets) and where the first search had a number of results discussing data corruption with OE, the second had far fewer. Granted, this is not a scientific, but neither program can ensure data does not become corrupted. On a side note, as for why OE is looked down upon, at least from my point of view any environment where different pieces of software are so closely tied together that it makes various types of virii very easy to create/propagate is not one I want on my system. My word processor should not control my email client and vice-versa. I'm the type of person that if I don't know that a piece of software is being installed by company sysops, I'll report a virus since I was unaware of the installation and I didn't do it myself. And yes, I have done that. Casey
Re: New syntax for string mixins
On 2010-12-17 00:34, Graham St Jack wrote: I've attached a part of how concurrency.d could look like translated to my suggested syntax. It probably contains a lot of errors because did a quick translation and I had some trouble understanding the mixins. Yes, even I couldn't understand them even a week later. Maintenance is a real problem. My initial reaction is that the proposed syntax helps a bit, but isn't really a game-changer. I will let you know if I change my mind on closer inspection. No it's basically just syntactic sugar. -- /Jacob Carlborg
Re: Why Ruby?
On 2010-12-17 17:47, Andrei Alexandrescu wrote: On 12/17/10 10:23 AM, Justin Johansson wrote: On 17/12/10 06:52, Andrei Alexandrescu wrote: On 12/16/10 1:30 PM, Jacob Carlborg wrote: The point here isn't that we want "a" and "b" to be replaced with "_" the point is that we want to get rid of the string and have a shorter and less verbose syntax for delegate literals. I understand. Using strings is witnessing the fact that we couldn't find a shorter syntax that didn't have problems. That being said, it's very possible there are some great ones, we just couldn't find them. Andrei "we just couldn't find them" Is that the royal "we" as in singular? If plural, may one politely inquire as to whom "we" are? Walter, Bartosz Milewski, Eric Niebler, David Held and myself have discussed the issue a number of times. It has also been often discussed on this newsgroup. Andrei And what was the conclusion, more than just "we just couldn't find them" ? -- /Jacob Carlborg
Re: Why Ruby?
On Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:
> I would like a syntax that is a combination of D's lazy argument syntax
> and C#'s lambda syntax. Basically like this:
>
> If the lambda doesn't take have any parameters then you can just put the
> expression between then the parentheses in the function call:
>
> foo(writeln(3));
>
> If the lambda have one parameter then the following syntax is used:
>
> foo(x => x * x);
>
> If the lambda takes more then one parameter then you have to use
> parentheses around the lambda parameters like this:
>
> foo((x, y) => x * y);
>
> Actually if it would be possible to skip the parentheses when the lambda
> take more than one argument I would be more happy with that:
>
> foo(x, y => x * y);
Why not define numbered placeholders to avoid the need for named
arguments altogether.
foo(@1 * @2);
//lowers to
foo((arg1, arg2) { return arg1 * arg2; });
It would be a fairly simple extension to the lazy argument syntax, and
cover most of the typical uses for short lambdas.
Re: emscripten
"Nick Sabalausky" wrote in message news:ieivqj$2s8...@digitalmars.com... > "Jeff Nowakowski" wrote in message > news:ieh83c$26g...@digitalmars.com... >> On 12/17/2010 09:18 PM, retard wrote: >>> >>> FWIW, JavaScript still isn't very efficiently supported on many >>> platforms. >> >> Do you think performance is a problem for a mortgage calculator? >> >> I think the performance issues of JavaScript are way overblown for the >> majority of use cases. I think the biggest problem is people keeping open >> lots of tabs with crappy JavaScript running from ad farms. > > Ok, so why would I want to turn JS on and put up with those shitty > browser-killing, user-experience-killing JS Ads just for a calculator that > obviously doesn't need it? > > As for the "nearly a complete duplication of work", it's a duplication of > *a simple mathematical formula*. It's a near complete duplication *of > something that is utterly trivial to implement either way*. And if you > don't already have a system set up for the request/response stuff then > you've got a *really* dinky site. And if you *do* have such a dinky site, > then tossing in a basic client-server form is trivial. > Also, I'm not convinced that that duplication can't be abstracted away. Actualy, it definitely can be if you use Haxe. And maybe we would already have plenty other good ways to do that if developers weren't wasting their time making awful browser-skinning engines and implementing excel in a webpage.
Re: emscripten
"Jeff Nowakowski" wrote in message news:ieh83c$26g...@digitalmars.com... > On 12/17/2010 09:18 PM, retard wrote: >> >> FWIW, JavaScript still isn't very efficiently supported on many >> platforms. > > Do you think performance is a problem for a mortgage calculator? > > I think the performance issues of JavaScript are way overblown for the > majority of use cases. I think the biggest problem is people keeping open > lots of tabs with crappy JavaScript running from ad farms. Ok, so why would I want to turn JS on and put up with those shitty browser-killing, user-experience-killing JS Ads just for a calculator that obviously doesn't need it? As for the "nearly a complete duplication of work", it's a duplication of *a simple mathematical formula*. It's a near complete duplication *of something that is utterly trivial to implement either way*. And if you don't already have a system set up for the request/response stuff then you've got a *really* dinky site. And if you *do* have such a dinky site, then tossing in a basic client-server form is trivial.
Re: [OT] Mozilla Thunderbird
"torhu" wrote in message news:iehd51$2gl...@digitalmars.com... > > Thunderbird is pretty buggy, but I haven't found a good replacement, at > least not yet. I regularly experience to annoying dataloss bugs. The > first is when TB messes up posts. This is easily fixed by making it > rebuild its index files (yes, TB corrupts its own data files on a regular > basis, with no help at all). The second and worst is when it loses track > of which posts I've read and which I haven't. There's no way that I know > of to fix that. > I don't mean to sound like an Outlook Express evangelist constantly banging an OE drum, but I've been using OE for years and never had any issues like that. Which actually makes me really puzzed, even though TBird's and OE's uses and basic interfaces are very similar: - Thunderbird apparently has *data loss/corruption* issues, and yet it's very popular. - OE *doesn't* have data loss/corruption issues, and yet it's widely looked-down upon. So what's wrong with this picture?
Re: executable size
On 18/12/2010 19:25, Nick Sabalausky wrote: "jovo" wrote in message news:ieit9a$2n5...@digitalmars.com... Hi, Today I compiled my old two module console program with d-2.50. It uses only std.c.time, std.c.stdio, std.random and templates. Compiled with -O -release, on windows. Executable size (d-2.50): 4.184 kb. Trayed with d-1.30: 84 kb. Is it expected? Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code. Jovo compared d1 vs d2.. and here the difference is significant.
Re: executable size
Nick Sabalausky Wrote: > > Yes. The runtime is currently built into the exe. With C/C++, the runtime is > often stored separately so the exe files themseves end up a lot smaller, > even though they rely on at least as much compiled code. > > Thanks!
Re: is it possible to learn D(2)?
"Caligo" wrote in message news:mailman.4.1292676932.4748.digitalmar...@puremagic.com... > > Also, do you know if there are any plans to standardize the language? > There aren't a bunch of diverging implementations of D, so standardization isn't currently needed.
Re: executable size
"jovo" wrote in message news:ieit9a$2n5...@digitalmars.com... > Hi, > Today I compiled my old two module console program with d-2.50. > It uses only std.c.time, std.c.stdio, std.random and templates. > Compiled with -O -release, on windows. > Executable size (d-2.50): 4.184 kb. > Trayed with d-1.30: 84 kb. > > Is it expected? Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code.
executable size
Hi, Today I compiled my old two module console program with d-2.50. It uses only std.c.time, std.c.stdio, std.random and templates. Compiled with -O -release, on windows. Executable size (d-2.50): 4.184 kb. Trayed with d-1.30: 84 kb. Is it expected?
Re: Why Ruby?
On 2010-12-16 23:40, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:iedqos$78...@digitalmars.com...
On 12/16/10 1:30 PM, Jacob Carlborg wrote:
The point here isn't that we want "a" and "b" to be replaced with "_"
the point is that we want to get rid of the string and have a shorter
and less verbose syntax for delegate literals.
I understand. Using strings is witnessing the fact that we couldn't find a
shorter syntax that didn't have problems. That being said, it's very
possible there are some great ones, we just couldn't find them.
Any problem with the other Scala/C#-style one?:
(x, y) => x * y
// Lowered to:
(x, y) { return x * y; }
(Maybe that was rejected before due the the weird float operators that are
now being ditched?)
It wouldn't be used for delegates that involve actual statements (it would
be expression-only), but that fits with the whole point of a lambda
expression.
Also, unlike the strings it doesn't suffer the problem of being evaluated in
the wrong scope. For instance I think it's perfctly sensible to want a short
lambda to be able to do something like this (pardon me if I have the syntax
for map() wrong):
int foo(int x) { ... }
collection.map!"foo(a) + 3"();
// Or if you want proper syntax highlighting:
collection.map!q{ foo(a) + 3 }();
I think that totally fits the charter of short lambdas, but the strings just
can't do it (at least not without turning map() into something that needs to
be mixed in). The lowered Scala/C#-style would be able to though:
int foo(int x) { ... }
collection.map!((a) => foo(a) + 3)();
// Lowered to the messier:
collection.map!((a) { return foo(a) + 3; })();
As Nick writes here the Scala/C#-style syntax is one suggestion. There
are also several other syntaxes available, one just have to look at
other languages to get ideas. Here's a list of the syntax used by a
couple of different language, some languages are list more than once
because they support more than one syntax. I've listed the languages in
order from, what I think, the least verbose to the most verbose
lambda/delegate syntax (the number in front of the languages is the
level of verbose, if two languages are at the same level I think they
are equally verbose).
1 D: foo(writeln(3)); // lazy argument
1 Scala: foo(_ * _)
2 C#: foo(x => x * x);
3 Scala: foo((x) => x * x)
4 Python: foo(lambda x: x * x)
5 Ruby: foo { |bar| x * x }
5 Ruby: foo do |x| x * x end
6 D: foo((int x) { return x * x; });
7 C++1x: foo([](int x){ return x * x; });
7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x * x; });
8 JavaScript: foo(function(x){ return x * x })
9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is
used for explicitly telling what variables should be available when the
scope is gone.
Note that I have not listed any functional languages here because I've
never used one.
I would like a syntax that is a combination of D's lazy argument syntax
and C#'s lambda syntax. Basically like this:
If the lambda doesn't take have any parameters then you can just put the
expression between then the parentheses in the function call:
foo(writeln(3));
If the lambda have one parameter then the following syntax is used:
foo(x => x * x);
If the lambda takes more then one parameter then you have to use
parentheses around the lambda parameters like this:
foo((x, y) => x * y);
Actually if it would be possible to skip the parentheses when the lambda
take more than one argument I would be more happy with that:
foo(x, y => x * y);
--
/Jacob Carlborg
Re: (Improved) Benchmark for Phobos Sort Algorithm
Hello Craig, It was brought to my attention that the quick sort has a very bad worst case, so I implemented a simple fix for it. Now the worst case (completely ordered) is the best case, and it only slows down the general case by a small percentage. I thought to myself, "it can't be this easy to fix quick sort". Does anyone see a flaw in this simple fix? Performs much better than Phobos in completely random and completely sorted data. Perhaps there is another case where it doesn't do as well? I think I've seen it stated as: If you know the implementation, you can always generate a pathological case for QSort.
Re: is it possible to learn D(2)?
Caligo: > If there is going to be a D3, will it be backwards compatible with D2? This is the desire (but some details may be not fully backward compatible). > And why is work still being done on the D1 compiler? Bug fixes, mostly. > Also, do you know if there are any plans to standardize the language? > Is the specification complete? The specification is not complete yet. Several more years will need to pass (probably 3 or 5) before standardization is able to start strongly with hope to be complete too. Bye, bearophile
Re: gdc-4.5 testing
bioinfornatics wrote: i am a fedora packager i have already push into fedora repo ldc,tango,mango,derelict i follow gdc project, for fedora they are a problem gdc do not follow gcc upstream and is not yet a part of gcc It's still possible to install gcc-d as an "add-on" to gcc, if using the same compiler... One could of course install an additional version of GCC, but it's smaller if just adding GDC. For Ubuntu/Debian, GDC is available for the system compiler so there you can just add D to the GCC Compiler Collection... Fedora/Redhat could do that too, possibly using a compat gcc ? when gcc 4.7 comme into fedora how many time will be to wait for have gdc/gcc4.7 ? if gdc build with gcc 4.6 i coud try something but in perfect world gdc is a gscc project. But Fedora 14 is currently running GCC version 4.5, though ? Or you mean that it _will_ be a problem for new Fedora 15, once that is released in about 6 month or so. Yeah, probably. Of course, Fedora could help with porting GDC to 4.6 and on if they want to include D with their supported languages ? Even if GDC came *with* GCC, it would still need packaging... --anders
Re: New syntax for string mixins
Don Wrote: > VladD2 wrote: > > Don Wrote: > >> Suppose the pre-compiled code, when run, asks what CPU it's on. What's > >> the answer? Is it X or Y? > > > > Current: X > > Target: Y > > > > Macro - a plugin to the compiler. It works on the same platform as the > > compiler, but generates code through the API which abstracts the macro from > > the target platform. If you need generate platform specific code, you > > should worry about it in macro logic. > > In any case macro is a meta-programm wich generate or/and transform code. > > Yes. But in D there's no distinction between code which is destined for > a macro, versus any other function. You can call a function once at > compile time, and the same function at compile time. My understanding of > Nemerle (which is quite likely to be wrong!) is that at least some > functions are callable only at compile-time. > I don't see how there needs to be different code to accomplish the above use case. You have a function that tests the hardware it's being run on. When this function is called in the compiler context it would return X, when it's called from the target executable it returns Y. > I'm also scared of the implications of allowing arbitrary code execution > during compilation. Make a typo in your program, and then compilation > may wipe files from your hard disk, or corrupt an external database, > etc... On some platforms you may be able to sandbox it, but since it's > running as part of the compilation process, rather than with the > permissions it will eventually have, it just seems like a security > nightmare. > This is a void argument since templates are Turing complete. It's *already* possible to do all of the above in D at compile time, it's just a matter of how much code is required to accomplish this. > All these problems would be reduced somewhat if it were only permissible > to call pure functions at compile time. Although even that has issues, > since not all compiler platforms may allow calling of shared libraries. > If we build that into the language, we'd be cutting ourselves off from > those platforms. > > I'm not certain that there are any unsurmountable problems, but these > issues make me really cautious.
Re: Purity
On 2010-12-18 07:46:11 -0500, Don said:
spir wrote:
On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis wrote:
Thank you for the explanation about strongly pure funcs calling weakly
pure ones --this fully makes sense.
I would like weakly pure to include output funcs, and exclude all
possibilities to modify (non-local) state.
The problem is that output is accessing global variables - which weakly
pure functions _cannot_ do.
Why? What is the rationale for excluding output (I don't mean I/O, only O)?
You're correct in saying that it doesn't affect the operation of the
program. But in practice, program output is almost always important.
For example, suppose we allowed output to be pure. Then consider:
writeln("Hello, world!");
Since it returns nothing, and has no influence on the future execution
of the program, the writeln can be dropped from the program.
I agree with that for writeln, the function at global scope, can't be
pure. The reason is simple: it refers to the stdout global variable.
However, if someone was to pass stdout as a non-const function
parameter I think it should work:
pure void fun(File output, string msg) {
output.writeln(msg);
}
void main() {
fun(stdout, msg);
}
File.writeln cannot be strongly pure since it gets the File as a
reference (and so it can't be optimized away), but it can be weakly
pure. One could argue that this is not terribly useful since no
strongly pure functions will be able to do IO, but there might be other
reasons one would want a weakly pure function other than enabling
strongly pure ones. (For one instance of this, see my two posts in the
other discussion "Threads and static initialization".)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Purity
On Sat, 18 Dec 2010 12:30:31 +0100
"Simen kjaeraas" wrote:
> spir wrote:
>
> > -1- How can this even compile?
> > pure append (ref int[] a, int i) {a ~= i;}
> > The _only_ task of this func is to change state.
>
> It is designed to be usable in strongly pure functions. A strongly pure
> function may call this weakly pure function without compromising its
> purity. This because the strongly pure function could only pass the
> weakly pure function its own local state, and changes would thus be
> limited to the strongly pure function's scope.
Right, thank you.
> > -2- Why is output writing considered an impure task? It has no influence
> > on the rest/future of the program, lets reasoning easy, does not touch
> > state.
>
> Output would be affected by pure optimizations:
>
> pure int writeStuff() {
> output( "Hi!" );
> return 1;
> }
>
> void foo( ) {
> int a = writeStuff( ) + writeStuff( );
> }
>
> Normally, the compiler could rewrite to
> int a = 2 * writeStuff( );
> but that would fuck up output.
... which means the optimisation scheme is wrong for "action-funcs".
Note: As said in // post, languages maybe should properly make a distinction
between action-functions & true functions (returning a result) --but I'm aware
this goes against the whole culture of the C-line languages.
I consider funcs like this one, that both perform an effect and return a
result, as confusing, and even erroneous, design/style.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Purity
On Sat, 18 Dec 2010 13:46:11 +0100
Don wrote:
> spir wrote:
> > On Sat, 18 Dec 2010 01:08:20 -0800
> > Jonathan M Davis wrote:
> >
> > Thank you for the explanation about strongly pure funcs calling weakly pure
> > ones --this fully makes sense.
> >
> >>> I would like weakly pure to include output funcs, and exclude all
> >>> possibilities to modify (non-local) state.
> >> The problem is that output is accessing global variables - which weakly
> >> pure
> >> functions _cannot_ do.
> >
> > Why? What is the rationale for excluding output (I don't mean I/O, only O)?
>
> You're correct in saying that it doesn't affect the operation of the
> program. But in practice, program output is almost always important.
>
> For example, suppose we allowed output to be pure. Then consider:
>
> writeln("Hello, world!");
>
> Since it returns nothing, and has no influence on the future execution
> of the program, the writeln can be dropped from the program.
>
> Hmmm
For sure, if you specify (in the compiler behaviour) that the only purpose of a
pure function is to return something. Which excudes all "action-fonctions" (=
funcs which purpose is to perform an effect). But why should the compiler
rewrite of such a func be to erase it? Just let it alone, it won't bother
anybody. And can safely be qualified as pure. So that, transitively, pure funcs
can call funcs that perform output. Just what we want.
pure Report getReport (Data data) {
// compute report from data (only)
log.write(report);
writefln("report computed:\n\t%s", report); // debug
return report;
}
Anyway, aside practicle & efficiency purposes, I'm even more annoyed by the
"conceptual wrongness" of excluding functions that perform output from the
"world of purity" ;-) I would want them included even if this did not buy
anything.
All of this would be easier and clearer if D made a proper distinction between
'true' functions (that compute a result) and 'action-functions' (that perform
an effect). The actual purity criteria need not be the same:
* actions must not write to state
* functions must not read from state
Just state: output ports and memory do not belong to program state, and we're
done.
There is an asymmetry: runtime/variable data input (from user, file,...) must
be considered as state, else a compiler cannot memoize function results.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: is it possible to learn D(2)?
On 12/18/2010 07:55 AM, Caligo wrote: If there is going to be a D3, will it be backwards compatible with D2? And why is work still being done on the D1 compiler? Shouldn't it be marked deprecated so people stop using it and move to D2? D1 is stable and only bug fixes are being applied to it. For D2, the post you replied to mentioned compiler bugs several times, and also mentioned unimplemented features. D2 has *never* been officially released (like D1 was), though its release was supposed to coincide with the release of Andrei's book. The date kept on getting pushed further and further back, until finally the book came out (publishers only have so much patience), and no mention of D being released was made. Walter and Andrei haven't been very honest in their presentations on the state of the language. I know a software project is never "finished", in that you can't expect perfection, but D2 is still in the alpha state. It's not reasonable for features documented in the definitive book on the language to not work. Also, the crown jewel of D2 was supposed to be immutability and concurrency, and those are the buggiest parts.
Re: Purity
On Sat, 18 Dec 2010 13:09:19 +0100 David Nadlinger wrote: > On 12/18/10 12:52 PM, spir wrote: > > Why? What is the rationale for excluding output (I don't mean I/O, only O)? > > Where would be the difference between writing to a global variable and > writing to stdout? How can writing to stdout change the result value of a later call to (the same or any other) function? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: New syntax for string mixins
VladD2 wrote: Don Wrote: Suppose the pre-compiled code, when run, asks what CPU it's on. What's the answer? Is it X or Y? Current: X Target: Y Macro - a plugin to the compiler. It works on the same platform as the compiler, but generates code through the API which abstracts the macro from the target platform. If you need generate platform specific code, you should worry about it in macro logic. In any case macro is a meta-programm wich generate or/and transform code. Yes. But in D there's no distinction between code which is destined for a macro, versus any other function. You can call a function once at compile time, and the same function at compile time. My understanding of Nemerle (which is quite likely to be wrong!) is that at least some functions are callable only at compile-time. I'm also scared of the implications of allowing arbitrary code execution during compilation. Make a typo in your program, and then compilation may wipe files from your hard disk, or corrupt an external database, etc... On some platforms you may be able to sandbox it, but since it's running as part of the compilation process, rather than with the permissions it will eventually have, it just seems like a security nightmare. All these problems would be reduced somewhat if it were only permissible to call pure functions at compile time. Although even that has issues, since not all compiler platforms may allow calling of shared libraries. If we build that into the language, we'd be cutting ourselves off from those platforms. I'm not certain that there are any unsurmountable problems, but these issues make me really cautious.
Re: is it possible to learn D(2)?
If there is going to be a D3, will it be backwards compatible with D2? And why is work still being done on the D1 compiler? Shouldn't it be marked deprecated so people stop using it and move to D2? Also, do you know if there are any plans to standardize the language? Is the specification complete? On Sat, Dec 18, 2010 at 3:36 AM, Jonathan M Davis wrote: > On Saturday 18 December 2010 01:14:19 Gour wrote: > > Hello, > > > > Seeing all the threads here about improving D(2) syntax for different > > features of the language, I just wonder if it's possible to learn D(2) > > language which is so much in flux by using TDPL as reference? > > > > Now I may have some time to learn D(2), but wonder when will the > > language become more stable or the proposals/improvements discussed > > here (I skip over majority of such threads) are not major changes? > > TDPL is mostly correct. There are a few features that it discusses that > either > quite buggy or outright unimplemented (e.g. neither inout and alias this is > completely implemented and some of what is implemented is rather buggy). > There > are also some features which may change. However, at this point, stuff is > only > going to change with a really good reason, and most of such changes are > likely > to be additive and wouldn't break much - if anything. For instance, weak > purity > is essentially an additive change. It makes it so that more functions can > be > marked as pure, but it doesn't make more functions optimizable due to > purity, > and it doesn't break any code. > > Prior to the release of TDPL, there were at times major changes between > releases > of dmd which broke a lot of code. That doesn't really happen anymore. > > For the most part, if you follow TDPL, you will be fine. Some stuff in TDPL > won't > work yet in practice, and it is possible that a few changes will be made to > the > language at some point which break current code and/or contradict TDPL. But > no > such changes have yet been made, I don't believe, and there are none which > have > been decided upon. None will be made without a definite, compelling reason, > precisely because TDPL is supposed to be valid. D2 is not entirely stable, > but > it the spec is no longer in constant flux either. > > Some changes likely will happen, but only as necessary, and they're going > to be > rare. And as time passes, they will become even rarer. > > Some folks will continue to discuss possible features for D which will > never > make it into D2. If there is ever a D3, they may be included then, but > stuff like > non-nullable references is not going to make it into the language in D2 > (though > there may be a library solution for it). > > Now, Phobos is certainly in flux. Parts of it are quite stable and won't be > changing particularly, but there's plenty of it which will continue to > evolve, > and there will certainly be more stuff being added. Phobos is still very > much a > work in progress. > > Really, the biggest obstacle to D development at this point is likely > simply > bugs - be they in the compiler or in Phobos. The situation continues to > improve, > but there are bugs which pop up from time to time which can cause major > headaches (like inout being totally broken at the moment). The language > spec is > essentially stable, but not necessarily set in stone. In almost all cases, > you > can rely on TDPL being correct. So, I wouldn't worry too much about that. > Compiler bugs are far more likely to trip you up than any language changes. > If > and when they happen, they'll probably remove certain types of problems > rather > than causing much in the way of new ones anyway. > > - Jonathan M Davis >
Re: Purity
spir wrote:
On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis wrote:
Thank you for the explanation about strongly pure funcs calling weakly pure
ones --this fully makes sense.
I would like weakly pure to include output funcs, and exclude all
possibilities to modify (non-local) state.
The problem is that output is accessing global variables - which weakly pure
functions _cannot_ do.
Why? What is the rationale for excluding output (I don't mean I/O, only O)?
You're correct in saying that it doesn't affect the operation of the
program. But in practice, program output is almost always important.
For example, suppose we allowed output to be pure. Then consider:
writeln("Hello, world!");
Since it returns nothing, and has no influence on the future execution
of the program, the writeln can be dropped from the program.
Hmmm
Re: Purity
On 12/18/10 12:52 PM, spir wrote: Why? What is the rationale for excluding output (I don't mean I/O, only O)? Where would be the difference between writing to a global variable and writing to stdout? David
Re: gdc-4.5 testing
== Quote from bioinfornatics (bioinfornat...@fedoraproject.org)'s article > i am a fedora packager i have already push into fedora repo ldc,tango,mango,derelict i follow gdc project, for fedora they are a problem gdc do not follow gcc upstream and is not yet a part of gcc > when gcc 4.7 comme into fedora how many time will be to wait for have > gdc/gcc4.7 ? > if gdc build with gcc 4.6 i coud try something but in perfect world gdc is a gscc project. > Thanks for all, good works ;) And I'm a debian/ubuntu packager, which has the downside of me being very centric around their releases, rather than others. If you really *need* gdc to be ported to gcc-4.6/trunk, I don't mind helping where questions or guidance are needed. Which is close enough to the same answer I gave to people asking when gdc will be ported to gcc-4.5. In blunt terms though, I'd rather people joined in on the development. :~) Regards
Re: Purity
On Sat, 18 Dec 2010 01:08:20 -0800 Jonathan M Davis wrote: Thank you for the explanation about strongly pure funcs calling weakly pure ones --this fully makes sense. > > I would like weakly pure to include output funcs, and exclude all > > possibilities to modify (non-local) state. > > The problem is that output is accessing global variables - which weakly pure > functions _cannot_ do. Why? What is the rationale for excluding output (I don't mean I/O, only O)? > If you call a weakly pure function from a strongly pure > function, it's still guranteed that the result of the strongly pure function > will be the same and have _no_ side effects - that is, it effectively has the > functional definition of purity. However, if you allowed I/O, you then have a > side effect, and two calls to a particular strongly pure function could > differ, > and yet the optimizer would then only do one call, thereby changing the > results > of the program. I disagree. Again, I'm not talking of I/O. The FP definition of "pure" excluding output is irrational imo. Writing to output cannot change later function return values, so who cares? And it's not only true for debug --even if I very much agree debug is a super important reason for allowing output. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Threads and static initialization.
On 2010-12-18 01:53:04 -0500, Jonathan M Davis said: However, anything that involves the heap wouldn't be okay, and that's a _lot_ of variables. Any and all references and pointers - inluding dynamic arrays - would be in TLS unless you marked them as shared. Things stored in the heap are *not* stored in thread-local storage. TLS is for thread-local global and static variables. Having TLS variables uninitialized shouldn't a problem when playing with the heap. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: gdc-4.5 testing
== Quote from Anders F Björklund (a...@algonet.se)'s article
> > Iain Buclaw wrote:
> >> Commit:
> >> https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa
> >>
> >> Feedback, patches and bug reports welcome!
> >
> > Says "This version of GCC () is not supported".
> > Missing a line for GCC 4.5 it seems, see patch.
> >
> > Other than that, it seemed to apply cleanly to
> > Fedora 14's version of GCC (gcc-4.5.1-20100924)
> Not only applied, but also seems to be working... :-)
> Once the enormous build and test completed, that is.
> So now you can install both "ldc" and "gcc-d" (gdc),
> and work with both Tango and Phobos from RPM packages.
> $ cat hello.d
> version (Tango)
> import tango.io.Console;
> else // Phobos
> import std.stdio;
> void main()
> {
>version (Tango)
>Cout ("Hello, World!").newline;
>else // Phobos
>writefln("Hello, World!");
> }
> $ ldmd hello.d
> $ ./hello
> Hello, World!
> $ gdmd hello.d
> $ ./hello
> Hello, World!
That's certainly nice to hear, considering the number of changes required were
considerably less than what was needed for gcc-4.4 (then again, many of them
were
backports from gcc-4.5 anyway ;). Of those changes made, they all turned out to
be
pretty quick/lazy edits.
Just preparing an update for 4.5.2 (and a strange segfault when building D2).
After that will begin the usual dstress/testsuite run against it to get an idea
of
just how production ready it is.
Regards
Iain
Re: Purity
spir wrote:
-1- How can this even compile?
pure append (ref int[] a, int i) {a ~= i;}
The _only_ task of this func is to change state.
It is designed to be usable in strongly pure functions. A strongly pure
function may call this weakly pure function without compromising its
purity. This because the strongly pure function could only pass the
weakly pure function its own local state, and changes would thus be
limited to the strongly pure function's scope.
-2- Why is output writing considered an impure task? It has no influence
on the rest/future of the program, lets reasoning easy, does not touch
state.
Output would be affected by pure optimizations:
pure int writeStuff() {
output( "Hi!" );
return 1;
}
void foo( ) {
int a = writeStuff( ) + writeStuff( );
}
Normally, the compiler could rewrite to
int a = 2 * writeStuff( );
but that would fuck up output.
--
Simen
freebsd
Does anyone have a freebsd9-current box that they'd be willing to give me an account on for the purposes of running an auto-tester for d2 (currently builds dmd, druntime, and phobos from scratch about once an hour)? I just need a shell account and less than a gig of space during each run. It doesn't need to be a particularly beefy box, nor does it need to have a particularly fat network pipe. It just needs to be a reliable network and always on. Thanks, Brad
Re: Threads and static initialization.
On 12/18/2010 10:00 AM, Jonathan M Davis wrote: The problem is that the OP wants the static constructors to be skipped. If they're skipped, anything and everything which could be affected by that can't be used. That pretty much means not using TLS, since the compiler isn't going to be able to track down which variables in TLS will or won't be affected by it. So, you're stuck using shared memory only. _That_ is where the problem comes in. Exactly, not using TLS. You can still use the heap, as it is not thread local. Meaning you can create non-shared anything all you like, as long as you're not using TLS.
Re: gdc-4.5 testing
i am a fedora packager i have already push into fedora repo ldc,tango,mango,derelict i follow gdc project, for fedora they are a problem gdc do not follow gcc upstream and is not yet a part of gcc when gcc 4.7 comme into fedora how many time will be to wait for have gdc/gcc4.7 ? if gdc build with gcc 4.6 i coud try something but in perfect world gdc is a gscc project. Thanks for all, good works ;)
Re: gdc-4.5 testing
Iain Buclaw wrote:
Commit:
https://bitbucket.org/goshawk/gdc/changeset/8ac6cb4f40aa
Feedback, patches and bug reports welcome!
Says "This version of GCC () is not supported".
Missing a line for GCC 4.5 it seems, see patch.
Other than that, it seemed to apply cleanly to
Fedora 14's version of GCC (gcc-4.5.1-20100924)
Not only applied, but also seems to be working... :-)
Once the enormous build and test completed, that is.
So now you can install both "ldc" and "gcc-d" (gdc),
and work with both Tango and Phobos from RPM packages.
$ cat hello.d
version (Tango)
import tango.io.Console;
else // Phobos
import std.stdio;
void main()
{
version (Tango)
Cout ("Hello, World!").newline;
else // Phobos
writefln("Hello, World!");
}
$ ldmd hello.d
$ ./hello
Hello, World!
$ gdmd hello.d
$ ./hello
Hello, World!
Will rebuild for Rawhide and post packages somewhere,
need to clean up the summaries and description a bit.
But that should make GDC available to Fedora as well,
or at least until they upgrade to GCC 4.6 that is...
* ldc
* tango (missing at the moment)
* tango-devel
* tango-static (missing at the moment)
* gdc
* phobos
* phobos-devel
* phobos-static
Good work!
--anders
Re: is it possible to learn D(2)?
Gour wrote: > Hello, > > Seeing all the threads here about improving D(2) syntax for different > features of the language, I just wonder if it's possible to learn D(2) > language which is so much in flux by using TDPL as reference? > > Now I may have some time to learn D(2), but wonder when will the > language become more stable or the proposals/improvements discussed > here (I skip over majority of such threads) are not major changes? > > > Sincerely, > Gour > Yes, it's not so much in flux as it seems. Like Jonathan says, it's more that some parts of phobos are unstable and certain bugs can stand in the way. Breaking changes to the language itself are very rare / unlikely now. I can't remember when such a thing broke my code whereas it used to happen every month. You can browse the changelog*, which lists new features for every release, to get a picture of the evolution. But also consider that most of the issues talked about are the more 'advanced' parts of the language. The bread and butter features haven't been changed that much for a long time now and are pretty solid. * http://www.digitalmars.com/d/2.0/changelog.html
Re: is it possible to learn D(2)?
On Saturday 18 December 2010 01:14:19 Gour wrote: > Hello, > > Seeing all the threads here about improving D(2) syntax for different > features of the language, I just wonder if it's possible to learn D(2) > language which is so much in flux by using TDPL as reference? > > Now I may have some time to learn D(2), but wonder when will the > language become more stable or the proposals/improvements discussed > here (I skip over majority of such threads) are not major changes? TDPL is mostly correct. There are a few features that it discusses that either quite buggy or outright unimplemented (e.g. neither inout and alias this is completely implemented and some of what is implemented is rather buggy). There are also some features which may change. However, at this point, stuff is only going to change with a really good reason, and most of such changes are likely to be additive and wouldn't break much - if anything. For instance, weak purity is essentially an additive change. It makes it so that more functions can be marked as pure, but it doesn't make more functions optimizable due to purity, and it doesn't break any code. Prior to the release of TDPL, there were at times major changes between releases of dmd which broke a lot of code. That doesn't really happen anymore. For the most part, if you follow TDPL, you will be fine. Some stuff in TDPL won't work yet in practice, and it is possible that a few changes will be made to the language at some point which break current code and/or contradict TDPL. But no such changes have yet been made, I don't believe, and there are none which have been decided upon. None will be made without a definite, compelling reason, precisely because TDPL is supposed to be valid. D2 is not entirely stable, but it the spec is no longer in constant flux either. Some changes likely will happen, but only as necessary, and they're going to be rare. And as time passes, they will become even rarer. Some folks will continue to discuss possible features for D which will never make it into D2. If there is ever a D3, they may be included then, but stuff like non-nullable references is not going to make it into the language in D2 (though there may be a library solution for it). Now, Phobos is certainly in flux. Parts of it are quite stable and won't be changing particularly, but there's plenty of it which will continue to evolve, and there will certainly be more stuff being added. Phobos is still very much a work in progress. Really, the biggest obstacle to D development at this point is likely simply bugs - be they in the compiler or in Phobos. The situation continues to improve, but there are bugs which pop up from time to time which can cause major headaches (like inout being totally broken at the moment). The language spec is essentially stable, but not necessarily set in stone. In almost all cases, you can rely on TDPL being correct. So, I wouldn't worry too much about that. Compiler bugs are far more likely to trip you up than any language changes. If and when they happen, they'll probably remove certain types of problems rather than causing much in the way of new ones anyway. - Jonathan M Davis
is it possible to learn D(2)?
Hello, Seeing all the threads here about improving D(2) syntax for different features of the language, I just wonder if it's possible to learn D(2) language which is so much in flux by using TDPL as reference? Now I may have some time to learn D(2), but wonder when will the language become more stable or the proposals/improvements discussed here (I skip over majority of such threads) are not major changes? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: [OT] Mozilla Thunderbird
On Sat, 18 Dec 2010 05:24:14 +0100 >> "torhu" == torhu wrote: torhu> Thunderbird is pretty buggy, but I haven't found a good torhu> replacement, at least not yet. Although I may be guilty of repeating myself, but I'll, again, recommend Claws-mail which serves as newsreader as well without any problem. Actually, 99% of all the mailing lists I follow are under Gmane and Claws is superb...fast, no loss etc. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Purity
On Saturday 18 December 2010 00:52:23 spir wrote:
> On Fri, 17 Dec 2010 02:42:14 -0500
>
> bearophile wrote:
> > http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/
> >
> > Bye,
> > bearophile
>
> I take the opportunity to question the def of weakly pure.
>
> -1- How can this even compile?
> pure append (ref int[] a, int i) {a ~= i;}
> The _only_ task of this func is to change state.
It's _weakly_ pure, not strongly pure. This pretty much just means that the
function does not access global variables. No optimizations can be done to it.
It's purely so that strongly pure (or other weakly pure) functions can legally
call it. If it's a strongly pure function calling it, then not only do you know
that global state can't be affected, but because all of the function's
parameters
are immutable (or full-on copies of mutable data in the case where it's a type
implicitly convertible to/from immutable).
Weakly pure functions are _not_ pure in the functional sense at all. Only
strongly pure functions are.
> -2- Why is output writing considered an impure task? It has no influence on
> the rest/future of the program, lets reasoning easy, does not touch state.
>
> I would like weakly pure to include output funcs, and exclude all
> possibilities to modify (non-local) state.
The problem is that output is accessing global variables - which weakly pure
functions _cannot_ do. If you call a weakly pure function from a strongly pure
function, it's still guranteed that the result of the strongly pure function
will be the same and have _no_ side effects - that is, it effectively has the
functional definition of purity. However, if you allowed I/O, you then have a
side effect, and two calls to a particular strongly pure function could differ,
and yet the optimizer would then only do one call, thereby changing the results
of the program. Optimizing out calls pure functions should _never_ change the
results of a program. Allowing output in weakly pure functions would allow that.
Now, there is arguably some need for the ability to have _debug_ functions for
printing in pure functions (be they weakly pure or strongly pure), but they'd
likely be used in cases where pure optimizations were not used (since you
wouldn't be using -O for debugging), and if they were used, the programmer
would
effectively be saying that they were okay with the I/O not necessarily occuring
every time that a function call occured in the code (since the call could be
optimized out). That is _not_ acceptible for general I/O.
I/O breaks purity. The way to get around it is to use monads, but that would
affect the signatures of every single function in the chain of function calls
which included the I/O. So, you wouldn't normally want to do that.
- Jonathan M Davis
Re: Threads and static initialization.
On Friday 17 December 2010 23:56:37 Pelle Månsson wrote: > On 12/18/2010 07:53 AM, Jonathan M Davis wrote: > > On Friday 17 December 2010 19:52:19 Vladimir Panteleev wrote: > >> On Sat, 18 Dec 2010 03:06:26 +0200, Jonathan M > >> Davis > >> > >> wrote: > >>> And how about every other variable? > >> > >> I'm sorry, I'm not following you. What other variables? > >> > >> * Globals and class/struct/function statics are in TLS > >> * Explicitly shared vars are in the data segment > >> * Locals are in the stack or registers (no problem here) > >> * Everything else (as referenced by the above three) is in the heap > > > > Value types which on the stack are going to be okay. That's true. You're > > right. They wouldn't be in TLS. > > > > However, anything that involves the heap wouldn't be okay, and that's a > > _lot_ of variables. Any and all references and pointers - inluding > > dynamic arrays - would be in TLS unless you marked them as shared. So, > > you'd have to use shared all over the place except in very simple cases > > or cases where you went out of your way to avoid using the heap. > > > > D is designed to avoid using shared memory except in cases where data is > > immutable. So, if you try to set up your program so that it uses shared > > memory primarily, then you're going to have problems. And not calling > > the static constructors on thread creation would mean using shared > > memory for everything which uses the heap. You couldn't even create > > local variables which are class objects using TLS in such a case, > > because they might have a static constructor which then would never have > > been called. > > > > Really, I don't think that trying to avoid calling static constructors is > > going to work very well. It may very well be a good reason to minimize > > what's done in static constructors, but skipping them entirely would be > > very difficult to pull off safely. > > > > - Jonathan M Davis > > The heap is the heap is the heap. You can have local variables on the > heap which are not shared. I think you are overstating the need for > shared, probably some misunderstanding. > > You could not have classes/structs with static members, or call > functions with static variables. Everything else should work, probably. > > The spawned thread could use the parent thread immutable globals, to > avoid the need to construct them in the spawned tls. I don't know if > this is actually possible :-) The problem is that the OP wants the static constructors to be skipped. If they're skipped, anything and everything which could be affected by that can't be used. That pretty much means not using TLS, since the compiler isn't going to be able to track down which variables in TLS will or won't be affected by it. So, you're stuck using shared memory only. _That_ is where the problem comes in. As for immutable globals, in theory at least (I believe there's an open bug on the issue at the moment), global immutables are all shared. If all that's done correctly, in theory, you'd just create the immutable globals either at compile time or with static constructors (possibly shared or immutable ones) which are just run once and don't have to be run per thread. So, immutable globals shouldn't pose a problem. However, mutable ones would - including those for classes. Because they'd need their static constructors run on thread creation in order to be properly initialized. - Jonathan M Davis - Jonathan M Davis
