www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - shebang launcher for D programs

reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
I used the shebang feature like this:

#!/usr/bin/env rdmd
... D code ...

Unfortunately, rdmd only works on single-file code. As soon as you try 
to import another file of yours, rdmd won't handle that.

So I wrote a Perl script rundmd that parses the D source looking for 
import directives, then does the same for all imported files, 
transitively (using a worklist approach). The script caches the results 
so it only does that minimally, after modifications. Then the script 
launches the proper compile command (if needed), and finally runs the 
produced executable.

In short, rundmd does what rdmd does but works on multi-module programs.

I suspect other people have written similar scripts, but just in case, I 
thought I'd ask. If people are interested, I'll be glad to comb the 
script a little and post it here.


Andrei
Mar 21 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 In short, rundmd does what rdmd does but works on multi-module programs.
 
 I suspect other people have written similar scripts, but just in case, I 
 thought I'd ask. If people are interested, I'll be glad to comb the 
 script a little and post it here.

Rebuild has a similar feature (-exec), but it's a program not a script. I think build/bud also did, but I had problems with it and GDC/Tango... Not sure how you pass runtime / program arguments over to it, though ? But it does parse and compile all the imported modules for the program. --anders
Mar 21 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 In short, rundmd does what rdmd does but works on multi-module programs.

 I suspect other people have written similar scripts, but just in case, 
 I thought I'd ask. If people are interested, I'll be glad to comb the 
 script a little and post it here.

Rebuild has a similar feature (-exec), but it's a program not a script. I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).
 Not sure how you pass runtime / program arguments over to it, though ?
 But it does parse and compile all the imported modules for the program.

(The way I do it is simple but ambiguous - any flags that come before the program name are passed to dmd, and any stuff that comes after the program name is considered that program's arguments. The program name is the first thing without a leading "-".) I think such a tool should be part of the standard distribution - it's very, very useful. Andrei
Mar 21 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Rebuild has a similar feature (-exec), but it's a program not a script.
 I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).

It's part of the DSSS project: (the "D Shared Software System") http://www.dsource.org/projects/dsss/wiki/Rebuild I did a RPM package and manpage for it, will post them* on gdcgnu as part of the requirements for using Tango instead of Phobos... --anders * See http://www.algonet.se/~afb/d/rebuild.spec for a preview
Mar 21 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Anders F Björklund wrote:

 Andrei Alexandrescu (See Website For Email) wrote:
 
 Rebuild has a similar feature (-exec), but it's a program not a script.
 I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).

It's part of the DSSS project: (the "D Shared Software System") http://www.dsource.org/projects/dsss/wiki/Rebuild I did a RPM package and manpage for it, will post them* on gdcgnu as part of the requirements for using Tango instead of Phobos...

Well, rebuild is not a requirement anymore, at least not for Windows and Linux DMD, and x86 Linux GDC as we're in the process of providing prebuilt libraries. Still a very useful tool though. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 21 2007
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Lars Ivar Igesund wrote:

I did a RPM package and manpage for it, will post them* on gdcgnu
as part of the requirements for using Tango instead of Phobos...

Well, rebuild is not a requirement anymore, at least not for Windows and Linux DMD, and x86 Linux GDC as we're in the process of providing prebuilt libraries. Still a very useful tool though.

Actually I meant for actually *using* Tango, not just building it :-) My little hello/test program didn't work when I was just using dmd/gdmd, but does work just fine when using bud/rebuild to include dependencies: $ more 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!"); } $ gdmd -version=Tango -version=Posix hello.d hello.o: In function `_Dmain': hello.d:(.text+0x13): undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output' hello.d:(.text+0x2d): undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output' hello.o:(.data+0x30): undefined reference to `_D5tango2io7Console12__ModuleInfoZ' collect2: ld returned 1 exit status $ rebuild -version=Tango -version=Posix hello.d WARNING: Module (null) does not have a module declaration. This can cause problems with rebuild's -oq option. If an error occurs, fix this first. $ ./hello Hello, World! Or are you working on that too, as I thought it was done that way on purpose because of limitations with including D templates in libraries (i.e. requiring you to include the Tango sources directly in your app) --anders
Mar 21 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Anders F Björklund wrote:

 Lars Ivar Igesund wrote:
 
I did a RPM package and manpage for it, will post them* on gdcgnu
as part of the requirements for using Tango instead of Phobos...

Well, rebuild is not a requirement anymore, at least not for Windows and Linux DMD, and x86 Linux GDC as we're in the process of providing prebuilt libraries. Still a very useful tool though.

Actually I meant for actually *using* Tango, not just building it :-) My little hello/test program didn't work when I was just using dmd/gdmd, but does work just fine when using bud/rebuild to include dependencies: $ more 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!"); } $ gdmd -version=Tango -version=Posix hello.d hello.o: In function `_Dmain': hello.d:(.text+0x13): undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output' hello.d:(.text+0x2d): undefined reference to `_D5tango2io7Console4CoutC5tango2io7Console7Console6Output' hello.o:(.data+0x30): undefined reference to `_D5tango2io7Console12__ModuleInfoZ' collect2: ld returned 1 exit status $ rebuild -version=Tango -version=Posix hello.d WARNING: Module (null) does not have a module declaration. This can cause problems with rebuild's -oq option. If an error occurs, fix this first. $ ./hello Hello, World! Or are you working on that too, as I thought it was done that way on purpose because of limitations with including D templates in libraries (i.e. requiring you to include the Tango sources directly in your app) --anders

Yes, that was what I meant. We intend to provide both libphobos and libtango (libgphobos and libgtango for GDC), since the template issues no longer seems to be a problem. There are some interesting linker issues with DMD, but that's more in the ld interaction area and should be easily fixable once I post in bugzilla :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 21 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 Rebuild has a similar feature (-exec), but it's a program not a script.
 I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).

It's part of the DSSS project: (the "D Shared Software System") http://www.dsource.org/projects/dsss/wiki/Rebuild I did a RPM package and manpage for it, will post them* on gdcgnu as part of the requirements for using Tango instead of Phobos... --anders * See http://www.algonet.se/~afb/d/rebuild.spec for a preview

I gave rebuild's dox a quick read, and it looks like it's almost there. Just in case you don't have enough work on your plate, here are two suggestions: 1. I'm not sure whether rebuild caches dependency information (it should, and the dox should emphatically reflect that). 2. rebuild should come with a companion program "launch" or something, which does not need any flags to compile a program - just takes the main program in argv[1], builds it, and launches it pasing to it argv[2 .. $]. This is necessary for the shebang syntax: #!/usr/bin/env launch ... D code ... On some platforms, env can't handle multiple words, e.g. this will not work: #!/usr/bin/env launch -someflag ... D code ... So launch needs to make-do flag-free. More about shebang at http://en.wikipedia.org/wiki/Shebang_(Unix). Bottom line: rebuild is very close to the above, and implementing that will add much value for little effort. Andrei
Mar 21 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:

 In short, rundmd does what rdmd does but works on multi-module programs.

 I suspect other people have written similar scripts, but just in 
 case, I thought I'd ask. If people are interested, I'll be glad to 
 comb the script a little and post it here.

Rebuild has a similar feature (-exec), but it's a program not a script. I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).
 Not sure how you pass runtime / program arguments over to it, though ?
 But it does parse and compile all the imported modules for the program.

(The way I do it is simple but ambiguous - any flags that come before the program name are passed to dmd, and any stuff that comes after the program name is considered that program's arguments. The program name is the first thing without a leading "-".) I think such a tool should be part of the standard distribution - it's very, very useful. Andrei

I agree, from first hand experience. I've made some D scripts myself, and there are some modules that I use often in such D scripts, such that I had to create a shell script wrapper to automatically include those module libs in D script compilation. (although I guess I could have put them in the shebang line as well, but that was more annoying) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:

 In short, rundmd does what rdmd does but works on multi-module 
 programs.

 I suspect other people have written similar scripts, but just in 
 case, I thought I'd ask. If people are interested, I'll be glad to 
 comb the script a little and post it here.

Rebuild has a similar feature (-exec), but it's a program not a script. I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).
 Not sure how you pass runtime / program arguments over to it, though ?
 But it does parse and compile all the imported modules for the program.

(The way I do it is simple but ambiguous - any flags that come before the program name are passed to dmd, and any stuff that comes after the program name is considered that program's arguments. The program name is the first thing without a leading "-".) I think such a tool should be part of the standard distribution - it's very, very useful. Andrei

I agree, from first hand experience. I've made some D scripts myself, and there are some modules that I use often in such D scripts, such that I had to create a shell script wrapper to automatically include those module libs in D script compilation. (although I guess I could have put them in the shebang line as well, but that was more annoying)

Finally :o). I was surprised by the responses to this topic, which basically revolved around the theme "Tool X and tool Y could be changed to do that". For me, the availability of a simple shebang script that takes care of'em all made a very inconvenient problem just disappear, and I also think that making such a tool part of the standard distribution would reduce the entry barrier to D enormously. 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
Mar 23 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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 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. Anyway, just some random thoughts. -- Daniel -- 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/
Mar 23 2007
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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.
 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
Mar 23 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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/
Mar 24 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 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

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

No, but it's good you have a default. The shebang does not prevent you from actually compiling the program from the command line - it will be ignored.
 To be honest, I think that D really lacks one important thing that I
 would make shell/system scripting far more appealing: an interpreter.

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... :("

I actually toyed a little with the idea of writing a little shell that reads a line, builds a small program with main() around that line, and compiles and runs that program. Should be reasonably fast. The problem is that this approach won't remember the previously-defined symbols.
 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

Yah, me too. But you can put ". dmdconf phobos" or ". dmdconf tango" in your startup file. Andrei
Mar 24 2007
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Daniel Keep wrote:
 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

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

No, but it's good you have a default. The shebang does not prevent you from actually compiling the program from the command line - it will be ignored.
 To be honest, I think that D really lacks one important thing that I
 would make shell/system scripting far more appealing: an interpreter.

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... :("

I actually toyed a little with the idea of writing a little shell that reads a line, builds a small program with main() around that line, and compiles and runs that program. Should be reasonably fast. The problem is that this approach won't remember the previously-defined symbols.

Yes!! I thought about making this too! Like the old times with MSX and C64! I loved having a "playground" like that. It's possible to do in D as well, just append all lines to an in-memory D-file and it'll "remember" variables. You'll have to take care about multiply defined symbols, by ignoring the first? Not sure about the details yet. L.
Mar 25 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 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.

When doing more complex such "scripts", this seems to work OK: #!/usr/bin/env rdmd --compiler=rebuild i.e. just using rebuild as a drop-in replacement for gdmd/dmd This caches the resulting program in /tmp (or $TEMP on Windows) and passes any additional arguments over to the compiled program: $ more run.d #!/usr/bin/env rdmd --compiler=rebuild import std.stdio; void main(char[][] args) { foreach (char[] arg; args) writefln("%s", arg); } $ ./run.d foo bar /tmp/run-501-234881028-13386453-4D8B5B0DF758A62AAB383FC432A9EED4 foo bar The program name is a little "interesting", but otherwise it's good. (for shell scripts or perl programs, then $0 would be the script...) Tested briefly under Mac OS X and Linux, without larger incidents ? (rdmd --force would rebuild the program if external things changed) Should also work OK with Tango. --anders PS. http://www.algonet.se/~afb/d/rdmd.d (GDC version of DMD bin) http://svn.dsource.org/projects/dsss/downloads/rebuild/0.14/
Mar 24 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 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.

When doing more complex such "scripts", this seems to work OK: #!/usr/bin/env rdmd --compiler=rebuild i.e. just using rebuild as a drop-in replacement for gdmd/dmd This caches the resulting program in /tmp (or $TEMP on Windows) and passes any additional arguments over to the compiled program: $ more run.d #!/usr/bin/env rdmd --compiler=rebuild import std.stdio; void main(char[][] args) { foreach (char[] arg; args) writefln("%s", arg); } $ ./run.d foo bar /tmp/run-501-234881028-13386453-4D8B5B0DF758A62AAB383FC432A9EED4 foo bar The program name is a little "interesting", but otherwise it's good. (for shell scripts or perl programs, then $0 would be the script...) Tested briefly under Mac OS X and Linux, without larger incidents ? (rdmd --force would rebuild the program if external things changed) Should also work OK with Tango.

This won't work if your script includes one of your own modules. Andrei
Mar 24 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 When doing more complex such "scripts", this seems to work OK:

 #!/usr/bin/env rdmd --compiler=rebuild

 i.e. just using rebuild as a drop-in replacement for gdmd/dmd

 This caches the resulting program in /tmp (or $TEMP on Windows)
 and passes any additional arguments over to the compiled program:


 Should also work OK with Tango.

This won't work if your script includes one of your own modules.

I'm not sure what you mean. If I import foo and bar, then rebuild will include foo.o and bar.o when compiling the main D program... Had I used gdmd, then I *would* have needed to include foo.o/bar.o (or a library containing those), but rebuild picks dependencies up: run.d: ====== #!/usr/bin/env rdmd -v --verbose --compiler=rebuild import std.stdio; import foo; import bar; void main(char[][] args) { writefln("%s %s", foo.foo, bar.bar); } foo.d: ====== module foo; char[] foo() { return "Hello"; } bar.d: ====== module bar; char[] bar() { return "World"; } And if we run this program with full verbosity, it will show us: $ ./run.d running: rebuild -quiet -v ./run.d -of/tmp/run-501-234881028-13386453-A1689B41B25F1EA1A08CED3004FB04D6 -od/tmp/ parse run meta run import std.stdio (/usr/bin/../include/d/4.0.1/std/stdio.d) import std.c.stdio (/usr/bin/../include/d/4.0.1/std/c/stdio.d) import std.stdint (/usr/bin/../include/d/4.0.1/std/stdint.d) import gcc.builtins (/usr/bin/../include/d/4.0.1/gcc/builtins.d) import std.c.stddef (/usr/bin/../include/d/4.0.1/std/c/stddef.d) import std.c.stdarg (/usr/bin/../include/d/4.0.1/std/c/stdarg.d) import gcc.config (/usr/bin/../include/d/4.0.1/i686-apple-darwin8/gcc/config.d) import gcc.configext (/usr/bin/../include/d/4.0.1/gcc/configext.d) import std.c.darwin.ldblcompat (/usr/bin/../include/d/4.0.1/std/c/darwin/ldblcompat.d) import std.format (/usr/bin/../include/d/4.0.1/std/format.d) import std.stdarg (/usr/bin/../include/d/4.0.1/std/stdarg.d) import std.utf (/usr/bin/../include/d/4.0.1/std/utf.d) import std.c.stdlib (/usr/bin/../include/d/4.0.1/std/c/stdlib.d) import std.c.string (/usr/bin/../include/d/4.0.1/std/c/string.d) import std.string (/usr/bin/../include/d/4.0.1/std/string.d) import std.uni (/usr/bin/../include/d/4.0.1/std/uni.d) import std.array (/usr/bin/../include/d/4.0.1/std/array.d) import std.ctype (/usr/bin/../include/d/4.0.1/std/ctype.d) import foo (foo.d) import bar (bar.d) meta stdio meta stdio meta stdint meta builtins meta stddef meta stdarg meta config meta configext meta ldblcompat meta format meta stdarg meta utf meta stdlib meta string meta string meta uni meta array meta ctype meta foo meta bar code run code stdio code stdio code stdint code builtins code stddef code stdarg code config code configext code ldblcompat code format code stdarg code utf code stdlib code string code string code uni code array code ctype code foo code bar compile gdmd -version=Posix -c ./run.d foo.d bar.d -quiet -od/tmp/ link gdmd /tmp/run.o /tmp/foo.o /tmp/bar.o -of/tmp/run-501-234881028-13386453-A1689B41B25F1EA1A08CED3004FB04D6 running: /tmp/run-501-234881028-13386453-A1689B41B25F1EA1A08CED3004FB04D6 Hello World I'm not sure it caches the object files (like C/C++'s "ccache"* does), but it does cache the resulting program which works fine for "scripts". If you have the same module name in different levels, you can use the -oq flag that writes object files using fully-qualified module names. It also picks up needed system modules, such as the one Tango uses... (but above it decided correctly that all std modules were in gphobos) Think you can get it to pick up external libraries using the library build/lib pragmas, or by adding the linker flags to the shebang line. If I want to change between dmd or gdc, or between Phobos and Tango, then all I need is to change the "default" setting of rebuild.conf/. --anders * See http://ccache.samba.org/
Mar 24 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 When doing more complex such "scripts", this seems to work OK:

 #!/usr/bin/env rdmd --compiler=rebuild

 i.e. just using rebuild as a drop-in replacement for gdmd/dmd

 This caches the resulting program in /tmp (or $TEMP on Windows)
 and passes any additional arguments over to the compiled program:


 Should also work OK with Tango.

This won't work if your script includes one of your own modules.

I'm not sure what you mean. If I import foo and bar, then rebuild will include foo.o and bar.o when compiling the main D program... Had I used gdmd, then I *would* have needed to include foo.o/bar.o (or a library containing those), but rebuild picks dependencies up: run.d: ====== #!/usr/bin/env rdmd -v --verbose --compiler=rebuild

Great. For some reason, it didn't work in my initial tests; I guess I've been sloppy somewhere. Any chance you make the --compiler=rebuild a default? Or is rebuild a separate product? (If so, that's not an attractive option.) Essentially what you want is to make rdmd do the deed flag-free: $ rdmd prog args does whatever it takes to build prog.d (if necessary) and then runs it passing args. Each extra needed flag cuts your cult following in half. :o) Andrei
Mar 24 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) skrev:

 I'm not sure what you mean. If I import foo and bar, then rebuild
 will include foo.o and bar.o when compiling the main D program...

 Had I used gdmd, then I *would* have needed to include foo.o/bar.o
 (or a library containing those), but rebuild picks dependencies up:

 run.d:
 ======
 #!/usr/bin/env rdmd -v --verbose --compiler=rebuild

Great. For some reason, it didn't work in my initial tests; I guess I've been sloppy somewhere. Any chance you make the --compiler=rebuild a default? Or is rebuild a separate product? (If so, that's not an attractive option.)

Let's see now... rdmd as it stands at the moment is intended for dmd/gdmd, which means that it won't work with multi-module programs (implicitly, that is...) And Build/Bud or alternatively Rebuild are separate products as you say, so it probably shouldn't be made the default option (even if it works) Bud: http://dsource.org/projects/build/ Rebuild: http://dsource.org/projects/dsss/ But this is the same for all D programs, not just the "script" variant, with the regular D compilers you need to give it all the object files like you do with C/C++ compilers but with these alternative "build" compilers you only give it the first program like you do with javac. i.e. even if you do use your own modules, you *could* compile those into a library and then link that with all your scripts using a -l option... It's just that the "build" tools do this for you, and can also be taught to pick up external libraries using: "version(build) pragma(link, baz);" So I think it's fair to have the rdmd program default to using dmd/gdmd, even if bud/rebuild do exist as an optional (and recommended) D add-on ?
 Essentially what you want is to make rdmd do the deed flag-free:
 
 $ rdmd prog args
 
 does whatever it takes to build prog.d (if necessary) and then runs it
 passing args. Each extra needed flag cuts your cult following in half. :o)

Currently this can be done by recompiling rdmd... (assuming here that the rdmd source code eventually gets included in the DMD distribution) This is the section to modify: char[] exepath, dfilepath, compiler = "dmd", tmpdir = "/tmp"; version (GNU) { compiler = "gdmd"; } version (Windows) { tmpdir = toString(getenv("TEMP")); } Maybe it could even use a configuration file for those two options. (i.e. a simple INI file for overriding --compiler and --tmpdir ?) --anders
Mar 25 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) skrev:
 
 I'm not sure what you mean. If I import foo and bar, then rebuild
 will include foo.o and bar.o when compiling the main D program...

 Had I used gdmd, then I *would* have needed to include foo.o/bar.o
 (or a library containing those), but rebuild picks dependencies up:

 run.d:
 ======
 #!/usr/bin/env rdmd -v --verbose --compiler=rebuild

Great. For some reason, it didn't work in my initial tests; I guess I've been sloppy somewhere. Any chance you make the --compiler=rebuild a default? Or is rebuild a separate product? (If so, that's not an attractive option.)

Let's see now... rdmd as it stands at the moment is intended for dmd/gdmd, which means that it won't work with multi-module programs (implicitly, that is...) And Build/Bud or alternatively Rebuild are separate products as you say, so it probably shouldn't be made the default option (even if it works) Bud: http://dsource.org/projects/build/ Rebuild: http://dsource.org/projects/dsss/ But this is the same for all D programs, not just the "script" variant, with the regular D compilers you need to give it all the object files like you do with C/C++ compilers but with these alternative "build" compilers you only give it the first program like you do with javac. i.e. even if you do use your own modules, you *could* compile those into a library and then link that with all your scripts using a -l option... It's just that the "build" tools do this for you, and can also be taught to pick up external libraries using: "version(build) pragma(link, baz);" So I think it's fair to have the rdmd program default to using dmd/gdmd, even if bud/rebuild do exist as an optional (and recommended) D add-on ?

Well fair of course it is, it's IMHO just not enough. I strongly believe that an rdmd that automatically figures out dependencies must be part of the standard D distribution.
 Essentially what you want is to make rdmd do the deed flag-free:

 $ rdmd prog args

 does whatever it takes to build prog.d (if necessary) and then runs it
 passing args. Each extra needed flag cuts your cult following in half. 
 :o)

Currently this can be done by recompiling rdmd... (assuming here that the rdmd source code eventually gets included in the DMD distribution) This is the section to modify: char[] exepath, dfilepath, compiler = "dmd", tmpdir = "/tmp"; version (GNU) { compiler = "gdmd"; } version (Windows) { tmpdir = toString(getenv("TEMP")); } Maybe it could even use a configuration file for those two options. (i.e. a simple INI file for overriding --compiler and --tmpdir ?)

If you make the code open source, I'd be glad to hack into it to make it do the deed without relying on any other tool. Andrei
Mar 25 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 So I think it's fair to have the rdmd program default to using dmd/gdmd,
 even if bud/rebuild do exist as an optional (and recommended) D add-on ?

Well fair of course it is, it's IMHO just not enough. I strongly believe that an rdmd that automatically figures out dependencies must be part of the standard D distribution.

A lot of us feel the same way. And since DMD does this anyway, adding a compilation feature doesn't seem too onerous. Sean
Mar 25 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 So I think it's fair to have the rdmd program default to using dmd/gdmd,
 even if bud/rebuild do exist as an optional (and recommended) D add-on ?

Well fair of course it is, it's IMHO just not enough. I strongly believe that an rdmd that automatically figures out dependencies must be part of the standard D distribution.

Seeing as how rebuild is based on the DMD sources, I don't think this is impossible. But if it complicates the release of the compilers, it might as well be stand-alone ? As in: installing Bud or Rebuild separately... In the end it is up to Walter if he wants to include the functionality in the regular DMD compiler or leave it as a "third-party opportunity" ? The pragmatic approach is rdmd in the main, and bud/rebuild as add-ons.
 Currently this can be done by recompiling rdmd... (assuming here that
 the rdmd source code eventually gets included in the DMD distribution)

 Maybe it could even use a configuration file for those two options.
 (i.e. a simple INI file for overriding --compiler and --tmpdir ?)

If you make the code open source, I'd be glad to hack into it to make it do the deed without relying on any other tool.

The code is public domain, but if it's not included it can be somewhat hard to find... It was released on the digitalmars.D.announce newsgroup: rdmd 1.0 (DMD/linux) digitalmars.D.announce:2668, 13 Feb 2006 rdmd 1.1 (DMD/Windows) digitalmars.D.announce:2673, 14 Feb 2006 As far as I can tell it (rdmd binaries) was introduced with DMD 0.148 ? I posted my modified rdmd code at http://www.algonet.se/~afb/d/rdmd.d: rdmd "1.2" (GDC/Unix) digitalmars.D.announce:8010, 21 Mar 2007 But I was only talking about changing "rdmd" so that it calls upon an external "bud" or "rebuild" program, as opposed to "dmd" or "gdmd"... --anders
Mar 25 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Daniel Keep wrote:
 
 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.
 

Hum, it's exactly like Java then (java.exe and javaw.exe) :) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 26 2007
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Bruno Medeiros wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:

 In short, rundmd does what rdmd does but works on multi-module 
 programs.

 I suspect other people have written similar scripts, but just in 
 case, I thought I'd ask. If people are interested, I'll be glad to 
 comb the script a little and post it here.

Rebuild has a similar feature (-exec), but it's a program not a script. I think build/bud also did, but I had problems with it and GDC/Tango...

Sounds great. Where is rebuild? (Bud aka build is easy to find on dsource.org).
 Not sure how you pass runtime / program arguments over to it, though ?
 But it does parse and compile all the imported modules for the program.

(The way I do it is simple but ambiguous - any flags that come before the program name are passed to dmd, and any stuff that comes after the program name is considered that program's arguments. The program name is the first thing without a leading "-".) I think such a tool should be part of the standard distribution - it's very, very useful. Andrei

I agree, from first hand experience. I've made some D scripts myself, and there are some modules that I use often in such D scripts, such that I had to create a shell script wrapper to automatically include those module libs in D script compilation. (although I guess I could have put them in the shebang line as well, but that was more annoying)

Finally :o). I was surprised by the responses to this topic, which basically revolved around the theme "Tool X and tool Y could be changed to do that". For me, the availability of a simple shebang script that takes care of'em all made a very inconvenient problem just disappear, and I also think that making such a tool part of the standard distribution would reduce the entry barrier to D enormously. 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 do much the same (Cashew on dsource started out as a clip from my personal lib) although I sometimes go a step further, where whole apps are in the tree so to say. For example the entire Bovis application is under a bovis.* package -- including the main program file, bovis.Main -- which makes my life easier when working on the companion program Guru, it just imports bovis.db.* and suddenly has just as much access to the Bovis database format as the main program does. Useful since Guru is supposed to be a utility for expediating new db development and/or db tweaking. Beyond that, its just a collection of .brf files I pass to build, and the occasional script to run multiple builds. (Such as Cashew's buildall which compiles a debug .lib, a release .lib, and the docs, and runs my little docfix utility to make the docs work with a slightly modified CanDyDoc the way I prefer.) Ultimately its not far off from your own pattern. -- Chris Nicholson-Sauls
Mar 24 2007
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 Which brings me to the question: what is the project style with D that
 people use?

Same as with C/C++, I am using sh/perl for scripting - or even lua/ruby.
 What tool(s) do you use, and in what sequence?

GNU make or IDEs, which calls upon either $DC - normally gdc (also dmd)
 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.

I build the project and then install the import modules and libraries into a system directory, like /usr/local/include/d and /usr/local/lib. When it's finished, use something like RPM to package the binaries up... Still haven't got the entire hang of using build or something like rdmd. (prefer installing first, over linking to the source directory directly) But at least they compile and work OK now, using rebuild and GDC rdmd... But if there's any demand, rdmd could be added to the GDC distribution ? For some tasks it is *very* useful, kinda like the gdmd syntax wrapper. Bud or Rebuild are probably large enough to be separate installations. Shouldn't add more than 250k to the gdcmac download (or 750k unpacked) /usr/local/bin/rdmd: Mach-O universal binary with 2 architectures /usr/local/bin/rdmd (for architecture i386): Mach-O executable i386 /usr/local/bin/rdmd (for architecture ppc): Mach-O executable ppc --anders
Mar 24 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Bruno Medeiros wrote:
 
 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

Well, I have two distinct scenarios. 1: D "scripts", which are small, one-file programs, only linked to some common utility shell scripting modules. I started using these as an alternative to bash scripting which didn't scale well (if at all, lol). 2: Normal D programs. I don't have any actual D project, but for bigger apps (multi-modules) I use a simple Ant script that wraps around bud. D code is edited in Eclipse, and also launched from Eclipse. This is also my sandbox where I do test code and try features and stuff (even if just on one file). I, like many others here, have also always recognized the great advantage of having the functionality of build (automatically include dependencies) and rdmd (create temporary files in temporary dirs, automatically run the target program) into the standard dmd distribution. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 26 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 I used the shebang feature like this:
 
 #!/usr/bin/env rdmd
 ... D code ...
 
 Unfortunately, rdmd only works on single-file code. As soon as you try 
 to import another file of yours, rdmd won't handle that.

Where can I find the source code for the rdmd program, by the way ? I seem to only find binaries for Windows and Linux, not for Mac :-) Is it part of the back-end, or is it open source like the front-end ? --anders
Mar 21 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 I used the shebang feature like this:

 #!/usr/bin/env rdmd
 ... D code ...

 Unfortunately, rdmd only works on single-file code. As soon as you try 
 to import another file of yours, rdmd won't handle that.

Where can I find the source code for the rdmd program, by the way ? I seem to only find binaries for Windows and Linux, not for Mac :-) Is it part of the back-end, or is it open source like the front-end ?

Walter knows. Andrei
Mar 21 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 Where can I find the source code for the rdmd program, by the way ?
 I seem to only find binaries for Windows and Linux, not for Mac :-)
 
 Is it part of the back-end, or is it open source like the front-end ?

Never mind, found Dave Fladebo's and Roberto Mariottini's versions attached in the digitalmars.D.announce newsgroup... (and it was under the free-for-all Public Domain license, so definitely "open source") Are these the same versions that are used in the DMD distribution ? If so, is there any chance of including the rdmd.d file used, in it. And it looks straightforward to port over from DMD/linux to GDC/Unix. --anders
Mar 21 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Anders F Björklund wrote:
 Where can I find the source code for the rdmd program, by the way ?
 I seem to only find binaries for Windows and Linux, not for Mac :-)

 Is it part of the back-end, or is it open source like the front-end ?

Never mind, found Dave Fladebo's and Roberto Mariottini's versions attached in the digitalmars.D.announce newsgroup... (and it was under the free-for-all Public Domain license, so definitely "open source") Are these the same versions that are used in the DMD distribution ? If so, is there any chance of including the rdmd.d file used, in it. And it looks straightforward to port over from DMD/linux to GDC/Unix.

It already is there. But it would be much more useful with only a little additional work. Andrei
Mar 21 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 If so, is there any chance of including the rdmd.d file used, in it.
 And it looks straightforward to port over from DMD/linux to GDC/Unix.

It already is there. But it would be much more useful with only a little additional work.

I can't seem to find "rdmd.d" anywhere in my version of dmd.1.009.zip ? 307924 02-25-06 11:34 dmd/bin/rdmd 131100 11-26-06 00:57 dmd/bin/rdmd.exe 8029 05-31-06 16:12 dmd/html/d/rdmd.html Binaries, yes. Documentation, yes. Source code, no. But I found it, np. --anders
Mar 21 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 
 So I wrote a Perl script rundmd...

My first reaction to this was: what does this have to do with old-school rap? -- - EricAnderton at yahoo
Mar 21 2007
parent kris <foo bar.com> writes:
Pragma wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 So I wrote a Perl script rundmd...

My first reaction to this was: what does this have to do with old-school rap?

rofl
Mar 21 2007