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

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

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

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

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

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

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

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/

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

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