shebang launcher for D programs

[Daniel Keep]

Andrei Alexandrescu (See Website For Email) wrote:
> Daniel Keep wrote:
>>
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> [snipitty do dah, snippity day]
>>>
>>> Which brings me to the question: what is the project style with D that
>>> people use? What tool(s) do you use, and in what sequence?  The way I
>>> currently do things is, I have a bunch of modules in a directory tree
>>> and I import them in whichever programs I'm writing. I edit the program,
>>> save it, and then just start it (the .d program; the fact that object
>>> files and a binary executable are generated is entirely transparent)
>>> from the command line. I never need to explicitly compile or build
>>> anything, and I only see any messages (such as gcc's link command) when
>>> the program has an error.
>>>
>>> Andrei
>>
>> I have a slowly growing library of bits & pieces (stuff like my
>> functools, vectors, colors, some concurrency stuff, etc.).  Any
>> "throwaway" programs I write tend to end up in my D sandbox directory.
>>
>> Things I will actually use/want to keep end up in a directory all of
>> their own, with an appropriate package structure, etc.  I tend to have
>> various GVim windows open, editing the source files.
>>
>> In terms of running the programs, half the time I crack open a Cygwin
>> bash shell and use "bud foo -clean -debug -etc -exec", "bud +foo -exec"
>> if I've set up a build.cfg file, I've started using "rebuild -rffoo.rrf
>> && foo" (which I hope is made a little cleaner in future), or just
>> invoke it from the GVim window itself.
>>
>> I rarely, if ever, use dmd directly, since I hate having all those extra
>> files cavorting with my pristine source files, so I tend to use -clean
>> an awful lot :)
>>
>> The #! thing would be cool, but since I run Windows, I don't tend to use
>> it.  That, and the fact that I tend to use lots of switches :3
> 
> Do your switches vary from one build to the next, or only from one file
> to the next? If the latter, you could use:
> 
> #!/path/to/rundmd -clean -debug -etc
> 
> as the first line of the program containing main(), and that works under
> cygwin. You don't have to build your program - ever. It builds itself
> when necessary.

They don't vary a great deal.  Although there are times when I'll add in
some experimental code hidden behind a version identifier, and then play
with the program with and without the code.

The other problem is that some projects are not simply a single program.
 For instance, with my current research project, the base programs are
altered by specifying additional user modules on the compile-line.  I
would be very annoyed having to modify a "main" script every time that
changed :p

>> I think rdmd would be far more useful if it pulled in all the needed
>> modules automatically like build and rebuild do.
>>
>> I'm not sure associating .d files with rdmd under Windows would do much
>> good.  One problem is that Windows makes a distinction between console
>> and window apps, so either your console apps never output anything, or
>> your window apps always have a console window lying around.  Python
>> solves this by having python.exe and pythonw.exe (the latter is a window
>> app, thus it has no console window), and using two extensions: .py and
>> .pyw.
>>
>> To be honest, I think that D really lacks one important thing that I
>> would make shell/system scripting far more appealing: an interpreter.
> 
> I already use D largely as an interpreter. It takes about as long as the
> equivalent Perl script to build and run, and much less to run - with
> readln() of course :o). That's why I can't figure out people's
> indifference vis-a-vis the shebang. It fosters a very attractive
> development cycle. If I had to build each and all of my D programs
> before running and dedicate one flagged command to each, I'd be much
> more frustrated.
> 
> 
> Andrei

I should have qualified: an *interactive* interpreter.  Python is so
massively productive because I can drop into a Python shell and start
playing with code.  It would be an incredible thing if D had an
interactive interpreter and I could say

  "I wonder what happens when I cast a real straight to a ubyte..."

Then just drop into the interpreter and type

  >>> cast(ubyte)3.14159
  3

  "Ah, it turns into an integer.  What?  Well, it *might* have tried to
reinterpret it literally, you know... :("

	-- Daniel

P.S. Incidentally, running that example above has highlighted a new
problem with my Phobos+Tango joint set up... I can't actually run dmd
directly anymore :P

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/