Walter Bright wrote:
> "Sean Kelly" <sean@f4.ca> wrote in message news:ds03jc$ctu$1@digitaldaemon.com...
>> Please do.  I would love to be able to use D for shell scripting at work. *sigh* that settles it then... sounds like I'm going to look into a Solaris port of GDC.
> 
> I have the easy part, just ignore the first line <g>. 

Lucky ;-)  I just had a look at the glibc POSIX headers and was immediately reminded just how nice we have it in D.  The C preprocessor is an evil, evil thing.


Sean

"Dave" <Dave_member@pathlink.com> wrote

> In article <ds0dut$le6$1@digitaldaemon.com>, Kris says...
>>Well, one concern (that nobody mentioned yet) is that such things are for
>>*nix only; yes?
>>
>
> It wouldn't have to be - you (or an installation) could set up a windows
> association to '.d' files that would run 'rdmd for windows'. If the '#!'
> was
> there it would run it like linux, otherwise it could complain that it
> isn't
> executable (or it could do more advanced things like look for another
> association, like an editor or ide).


So, I have .d associated with emacs. I double-click the file and it opens up in the editor.

How do I resolve that with an association (as described) that tries to execute the file instead? Doesn't it seem that ".d" is being badly overloaded here? And, why would I not just compile such a file/script into an executable in the first place? What is the overriding value in trying to execute a ".d" ? Are you trying to hide the compiler for some reason?

It seems like a good idea to make D more 'approachable' at the language level, yet what you describe above appears to cause difficulties instead?

Lots of questions :)

In article <ds0hpf$p5m$1@digitaldaemon.com>, Kris says...
>
>"Dave" <Dave_member@pathlink.com> wrote
>
>> In article <ds0dut$le6$1@digitaldaemon.com>, Kris says...
>>>Well, one concern (that nobody mentioned yet) is that such things are for
>>>*nix only; yes?
>>>
>>
>> It wouldn't have to be - you (or an installation) could set up a windows
>> association to '.d' files that would run 'rdmd for windows'. If the '#!'
>> was
>> there it would run it like linux, otherwise it could complain that it
>> isn't
>> executable (or it could do more advanced things like look for another
>> association, like an editor or ide).
>
>
>So, I have .d associated with emacs. I double-click the file and it opens up in the editor.
>
>How do I resolve that with an association (as described) that tries to execute the file instead? Doesn't it seem that ".d" is being badly overloaded here? And, why would I not just compile such a file/script into an executable in the first place? What is the overriding value in trying to execute a ".d" ? Are you trying to hide the compiler for some reason?
>
>It seems like a good idea to make D more 'approachable' at the language level, yet what you describe above appears to cause difficulties instead?
>
>Lots of questions :)

Well, in that case: just go with ".ds" (or something else) as your extension and you handily solve the shebang line problem (its now saying that it's special by name) and the file-type association problem.  The downside: you're stepping away from throwing the file to DMD directly, should you ever want to do that.

- Eric Anderton at yahoo

In article <ds09nc$hpo$1@digitaldaemon.com>, Kris says...
>
>Yes; a lot of the scripting simplicity comes from output formatting. You haven't mentioned 'automatic' conversion of numerics to strings, such as "int: "~23~", float: "~3.14159; is there a reason for that?
>

I'm thinking writefln() et al would take care of quite a bit of that.

Instead of 'print "Sum = $sum\n";' it would be 'writefln("Sum = ",sum);'

23 characters for D, 21 for Perl <g>

>> import std.script;
>>
>> This would publically include, say, std.stdio, std.file, std.string, std.regexp.
>
>But it's a trap that's easy to fall into :)
>
>For example, the 'automatic' conversions above would probably link directly to Phobos? That would tends to exclude alternate libraries? The imports you describe bind directly to Phobos also. That tends to heavily bias the "scripts" toward a library that many of us feel is 'closed'. Perhaps this needs to be considered? Some of this could be addressed by Walter leaving some indirection within the bindings (rather than binding directly to some 'internal-only' label, like the way comparison/equality is performed).
>

Oh, I meant that 'import std.script;' would actually import a file out on disk in std/script.d:

std/script.d:
-------------
// one could put whatever they want in here, but the
// lib. distro. would have a default good for most
// 'scripting'
import std.stdio, std.file, std.string, std.regexp;
-------------

This wouldn't be any type of compiler intrinsic thing.

Unless you mean things like native regex support - that would just call an ABI that any new library could plug into like AA's do now?

>- Kris
>
>

> One other thing about scripts of course is that you fire them up at the command-line w/o compilation.
>
> I just built a small 'interpreter' that will take a D file prefaced with '#!/usr/bin/rdmd', compile it and run it.

I recommend looking at TinyCC http://www.tinycc.org.
It's an embeddable C preprocessor, compiler, and linker that can be used in
scripting mode. I've been using it for my compiler-hacking by aiming in the
exact direction you indicate - make something partly between C and a
scripting language. The benefit of scripting is an amazing productivity
boost. The benefit of C is performance. For example TinyCC can be invoked
using #!

#!/usr/local/bin/tcc -run
#include <stdio.h>
int main()
{
    printf("Hello World\n");
    return 0;
}

"pragma" <pragma_member@pathlink.com> wrote ...
>
> Well, in that case: just go with ".ds" (or something else) as your
> extension and
> you handily solve the shebang line problem (its now saying that it's
> special by
> name) and the file-type association problem.  The downside: you're
> stepping away
> from throwing the file to DMD directly, should you ever want to do that.

Which is why I asked what value there might be in attempting to hide the compiler. I mean, doesn't the ".exe" extension exist for a reason?  Why not just compile the .d "script" and be done with it?

Please try to forgive my ignorance, but is there something vaguely mystical here that I just don't get?

In article <ds0jm0$qtc$1@digitaldaemon.com>, Kris says...
>
>Please try to forgive my ignorance, but is there something vaguely mystical here that I just don't get?
>

I think the advantage here is that it takes advantage of the same use idiom that shell scripts do.  Both the shebang line (for unix) and a file-type association (for Win) become a transparent wrapper.  But yes, it boils down to a few keystrokes really - but that's less to screw up, isn't it?

me@host> myscript.ds arg1 arg2

-= versus =-

me@host> dmdr myscript.ds arg1 arg2


As an exercise in contrast, *right now* you can get *really* close by doing this:

me@host> build myscript.d -silent -run"arg1 arg2"

(or just throw it into a script and leave it on the path somewhere)

The only reason why you wouldn't want to use build in this manner is that it 0) is fairly verbose 1) likes to drop the executable in the current directory and 2) imports can/will be overridden by files in the current path.

Honestly, I think its a step toward true cross-platform scripting (no more .bat and .sh files), which would be a very nice addition to our toolchain for D.  The only hard part is standardizing the configuration work, or at a minimum, making such a task impossible to misconfigure via a utility.

- Eric Anderton at yahoo

pragma wrote:
> 
> As an exercise in contrast, *right now* you can get *really* close by doing
> this:
> 
> me@host> build myscript.d -silent -run"arg1 arg2"
> 
> (or just throw it into a script and leave it on the path somewhere)
> 
> The only reason why you wouldn't want to use build in this manner is that it 0)
> is fairly verbose 1) likes to drop the executable in the current directory and
> 2) imports can/will be overridden by files in the current path.

Is there any way to override any of this behavior with Build?  Line length really isn't an issue as I'd probably just alias it anyway.


Sean

Sorry for the long post:

"pragma" <pragma_member@pathlink.com> wrote...
> In article <ds0jm0$qtc$1@digitaldaemon.com>, Kris says...
>>
>>Please try to forgive my ignorance, but is there something vaguely
>>mystical
>>here that I just don't get?
>>
>
> I think the advantage here is that it takes advantage of the same use
> idiom that
> shell scripts do.  Both the shebang line (for unix) and a file-type
> association
> (for Win) become a transparent wrapper.  But yes, it boils down to a few
> keystrokes really - but that's less to screw up, isn't it?
>
> me@host> myscript.ds arg1 arg2
>
> -= versus =-
>
> me@host> dmdr myscript.ds arg1 arg2
>
>
> As an exercise in contrast, *right now* you can get *really* close by
> doing
> this:
>
> me@host> build myscript.d -silent -run"arg1 arg2"
>
> (or just throw it into a script and leave it on the path somewhere)
>
> The only reason why you wouldn't want to use build in this manner is that
> it 0)
> is fairly verbose 1) likes to drop the executable in the current directory
> and
> 2) imports can/will be overridden by files in the current path.


Yes, I see that. But what's the difference here:

> me@host> myscript.ds arg1 arg2
>
> -= versus =-
>
> me@host> myscript arg1 arg2

The second case is an executable, which doesn't appear to be a burden. .

I see Ben has just posted something saying that there is some kind of enormous productivity gain via scripting? This is the part I don't comprehend at all. If you'll bear with me, let's take an example:

1) I want to write a program/script
2) I open an editor and either crib an existing .d file or create a new one
3) I think about how I'm going to construct this program/script
4) I start typing, think some more, and type some more. Repeat.
5) I exit the editor (or start another console) and run my program/script
6) It doesn't quite do what I expected. I re-open the file and goto #4
7) Eventually it does what I want, and I move onto something else.

Speculatively, how long is the writing/thinking process? 10 minutes perhaps? 2 minutes, if we already know exactly what we want and are intimately familiar with the language? Let's pick five minutes as a middle ground?

OK. You spend 5 mins typing and thinking. How long does it take to compile a script file that took 5 minutes to write? One second? a quarter second perhaps?

You see what I'm getting at? If you eliminate the compile cycle, what exactly do you gain? Where does this enormous productivity gain come from, that Ben talks about? (Yes I should ask him that question :-)

~~~~~~~~~~~~

I think there's a few points here that are interesting:

1) Any productivity gain must surely be in the scripting language itself, and not in simply sidestepping the compile cycle. The D compiler is exceedingly fast.

2) Any simplification in getting our 5 minute program compiled is surely handled by Build? You just type "build myfile" and you're done. That's it.

3) The program thus compiled is an independent entity ~ it does not rely on backward or forward compatability with the "hidden" compiler or libraries.

4) What happens when you need to debug a "script"?  Do you have to break out the compiler and debugger at that point? Learn a different way of doing things?

~~~~~~~~~~~~

So, while I can clearly see benefits in making the language itself more "approachable" (such as native regex), the notion of a D script appears to be something of a hollow promise? It's still just normal D, after all. Yes?

Debugging concerns aside, here's a hypothesis :: productivity gains using a D "script" (actually, an attempt to hide the compiler) might gain you one second of time out of five minutes.

Thoughts?

"Kris" <fu@bar.com> wrote in message news:ds0hpf$p5m$1@digitaldaemon.com...
> How do I resolve that with an association (as described) that tries to execute the file instead? Doesn't it seem that ".d" is being badly overloaded here? And, why would I not just compile such a file/script into an executable in the first place? What is the overriding value in trying to execute a ".d" ? Are you trying to hide the compiler for some reason?
>
> It seems like a good idea to make D more 'approachable' at the language level, yet what you describe above appears to cause difficulties instead?

I think this is not going to work on Windows for the reasons you mentioned. It'll work on *nix systems, but that still won't adversely affect Windows.

The reason to have it, where it can be supported, is simply sugar. One file apps can be distributed as source, and it's not necessary for the user to worry about compiling them, where to store the executable, what if the source gets out of sync with the executable, etc. A good implementation can, as Dave suggested, cache the generated executables so it really is just as good as compiling them manually. It's cool enough to put the idea in peoples' minds "why am I using a scripting language instead of D?"