View mode: basic / threaded / horizontal-split · Log in · Help
February 27, 2013
Re: Are there any default dmd optimizations
On 2/27/2013 12:05 AM, pjmlp wrote:
> This is not true.
>
> Javadoc uses a plugin architecture known as doclet.

I didn't know about doclets. Thanks for the correction.
February 27, 2013
Re: Are there any default dmd optimizations
On Tuesday, 26 February 2013 at 23:37:57 UTC, Andrei Alexandrescu 
wrote:
<snip>
>
> Agreed, but it does happen often that a language feature is 
> later superseded by a generalization thereof.
>
> Andrei

I agree that this does happen. The question is how the language 
evolve with that in mind. Do we choose to preserve *all* previous 
semantics? Do we have a proper deprecation process? etc, etc..
I think that unfortunately, the D design process is not adequate 
as of yet - there is no proper deprecation process which causes 
things like a "sudden death" for previously valid syntax (alias 
syntax) instead of gradually deprecate it with proper 
announcements *everywhere* (website, NG, ..) on the one hand and 
keeping redundant special cases in the language and refusing to 
change semantics (AAs) to allow for an easier path forward, on 
the other hand.

So I think we agree on the spirit of things but the problems I'm 
voicing are about the details or lack thereof. Where are the 
guidelines describing all these issues? How to address required 
semantic changes in the language? how to address syntax changes? 
how to remove previously failed features or no longer needed 
ones? What constitutes a feature that should be completely 
removed and what should only be put on permanent deprecation 
status? How all those things interact?
If we still (after a decade!) decide these based on c++ common 
wisdom only than I think something is really broken here. 
Previously valid D syntax is easily broken without much regard 
yet we are still stuck on the comma backwards compatibility to C. 
We ignore all other languages that programmers migrate from to D 
and ignore their common wisdom and experience. Isn't it time for 
D to become its own language instead of a leech on C++ idioms?
February 27, 2013
Re: Are there any default dmd optimizations
On Wednesday, 27 February 2013 at 00:01:31 UTC, Andrei 
Alexandrescu wrote:
>
> I understand how you see it, and honestly could see it from a 
> mile. When a post (a) cherry-picks all negatives and (b) has a 
> final tone that mentions no possible solution - it's a foregone 
> conclusion that no amount of explaining, amending, arguing, 
> etc. will improve the poster's outlook.
>
> I could say e.g. "Well I think things have changed, and look 
> we've turned the bug trend curve (http://goo.gl/kf4ZC) which is 
> unprecedented, fixed some incomplete features, break new 
> records on bug fixes with each release, and have a big 
> conference coming." - to which I have no doubt it's possible to 
> concoct a negative answer.
>
> So I understand you have a negative outlook on D. That's 
> entirely fine, as is mentioning it on the forum. The only thing 
> I'd like you to understand and appreciate is that we who work 
> on D are doing our best to find solutions to the various 
> problems in front of us, and in quite a literal sense we don't 
> know how to do any better. The constructive thing I'm getting 
> out of this is that we could use some more radicalization - try 
> things that push stronger against our comfort zone. I have a 
> few in mind but it's too early to discuss them publicly.
>
>
> Andrei

Let me emphasize again, I did *not* intend to discuss the 
specific features, Walter brought that topic up. I intended to 
point out the lack of good general guidelines for the D design 
process. And i did actually mention one (partial) solution. I 
mean no disrespect to the hard work of the contributers and did 
not wish to discourage them, just to prevent wasted effort due to 
lack of proper guidelines.
The other criticism I have is exactly the last paragraph above. 
Rust is designed in the open and so I can read the weekly minutes 
and get the bigger picture of the design process, what are the 
different proposed alternatives, what are the considerations and 
trade-offs, etc. In D on the other hand, it's all closed. D 
claims that it is an open source project but all the major design 
decisions happen personally between you and Walter and this is 
worse than big company languages that at least publish some 
articles online.
February 27, 2013
Re: Are there any default dmd optimizations
On 2013-02-26 21:51, foobar wrote:

> Again, this is a completely superfluous feature. D already has
> annotations (took only several years to convince Walter to add them)
> which are more flexible and much better suited for this.
>
> @unittest // <- this is a unit-test function
> void mySuperDuperTestFunction(...);
>
> There is no benefit in having all those special case features in the
> language which have all sorts of integration issues yet deny the
> usefulness of a more general solution generally accepted in the
> programming world, successfully used in many languages and thus also
> familiar to programmers coming from those languages.

I like that I don't have to create a function for the tests. I can run 
arbitrary code in the unit test blocks. Otherwise I agree with you.

-- 
/Jacob Carlborg
February 27, 2013
Re: Are there any default dmd optimizations
On 2013-02-27 00:37, Andrei Alexandrescu wrote:

> Agreed, but it does happen often that a language feature is later
> superseded by a generalization thereof.

In this case it would be two features:

1. Allow to run arbitrary code at top level
2. Allow to pass a delegate to a function after the parameter list

void unittest (void delegate () dg)

unittest {
    assert(true);
}

Would be lowered to:

unittest({
    assert(true);
});

Then we also can easily support named unit tests:

void unittest (string name, void delegate () dg)

unittest("foo") {
    assert(true);
}

Would be lowered to:

unittest("foo", {
    assert(true);
});

I think it would be nice if D could get better at declarative programming.

-- 
/Jacob Carlborg
February 27, 2013
Re: Are there any default dmd optimizations
On 2013-02-26 21:24, H. S. Teoh wrote:

> But D's built-in unittests, for all their warts and shortcoming, have
> the benefit of being right there, ready to use, and guaranteed to be
> runnable by whoever is compiling the code (don't have to worry about
> people not having Expect/python/whatever installed, so contributors have
> no excuse to not run them, etc.).

I think that is one of the problems with unit tests in D. I don't know 
how to run them. It's just the -unittest flag, but that's not enough.

* How do I run all the unit test in all of my files? Some will have a 
shell script called "test.sh", some will call it "unittest.sh". How do I 
then run the test on Windows, I can run Bash scripts on Windows. Some 
will have a D file "test.d", what the h*ll should I do with that? 
Compile it? run it using RDMD?

* How do I run a single test?
* How do I run a subset of the tests?

The questions go on.

Using Ruby on Rails, the first thing I see when I clone a repository is 
either a "test" or a "spec" folder. These are run using "rake test" or 
"rake spec". All projects using these frameworks support running all 
test, a single test and a subset of test. And it's the same commands on 
for all projects on all platforms.

-- 
/Jacob Carlborg
February 27, 2013
Re: Are there any default dmd optimizations
On 2013-02-26 20:53, Walter Bright wrote:
> On 2/25/2013 11:56 PM, foobar wrote:
>> DDoc isn't part of the language but rather part of the compiler,
>> nevertheless it
>> has its downsides.  [...]
>> unittest is worse,

[SNIP]

I'm going to use the big "if".

If the D compiler was built properly as a library, preferably in D. We 
could build all these features as separate tools (Ddoc, unit test) with 
the help of the compiler. These tools would then be included in the D 
distribution. Actually, the unit test support doesn't need the compiler 
as a library.

The build in unit tests support doesn't give much. It's easily 
implemented as a library with a simple tool to drive it. Example:

void unitTest (void delegate () dg);

static this ()
{
    unitTest({
        assert(true);
    });
}

It's then easy to add support for named unit tests:

void unitTest (string name, void delegate () dg);

static this ()
{
    unitTest("foo", {
        assert(true);
    });
}

If we then add some syntax sugar and allow a delegate to be passed after 
the parameter list we could have this:

static this ()
{
    unitTest("foo") {
        assert(true);
    }
}

If we then could support having arbitrary code at top level we would 
have this:

unitTest("foo") {
    assert(true);
}

Which is basically the same syntax as we have now but it's implemented 
as a library function. It can easily be extended with other similar 
functions doing slightly different things.

-- 
/Jacob Carlborg
February 27, 2013
Re: Are there any default dmd optimizations
On 2013-02-27 00:44, Walter Bright wrote:

> 1. require the user to type the information in twice
> 2. add parsing and semantic analysis capability to the doc generator

3. Build the compiler as a library. Use the library when creating the 
separate ddoc tool.

Number 3 would be the correct approach.

-- 
/Jacob Carlborg
February 27, 2013
Re: Are there any default dmd optimizations
On 2/27/13 5:01 AM, foobar wrote:
> Let me emphasize again, I did *not* intend to discuss the specific
> features, Walter brought that topic up. I intended to point out the lack
> of good general guidelines for the D design process. And i did actually
> mention one (partial) solution. I mean no disrespect to the hard work of
> the contributers and did not wish to discourage them, just to prevent
> wasted effort due to lack of proper guidelines.

I agree we should have a more organized process.

> The other criticism I have is exactly the last paragraph above. Rust is
> designed in the open and so I can read the weekly minutes and get the
> bigger picture of the design process, what are the different proposed
> alternatives, what are the considerations and trade-offs, etc.
> In D on
> the other hand, it's all closed. D claims that it is an open source
> project but all the major design decisions happen personally between you
> and Walter and this is worse than big company languages that at least
> publish some articles online.

Four years ago I would've entirely agreed. But right now it's an odd 
comment to make seeing as we're discussing all major decisions in this 
group and we're switching full-bore to DIPs.


Andrei
February 27, 2013
Re: Are there any default dmd optimizations
On 2/27/13, Jacob Carlborg <doob@me.com> wrote:
> * How do I run a single test?
> * How do I run a subset of the tests?

If this is really an often-requested feature it could be implemented
by default in Druntime. All you'd need is to parse command-line
arguments before calling main(), document these switches, and
implement this feature in the default unit tester that's found in
core.runtime.runModuleUnitTests after the "if(
Runtime.sm_moduleUnitTester is null )" check.

For example I use this:

https://github.com/AndrejMitrovic/dgen/blob/master/src/dgen/test.d

If I want to test specific modules I use:
rdmd --testModsRun=a.b.c --testModsRun=d.e.f main.d

And if I want to ignore running specific tests:
rdmd --testModsSkip=a.b.c main.d
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home