March 04, 2009
A suggestion: make the --eval temporary source file nicer looking:

46c46,47
<     std.zlib;";
---
>     std.zlib;
> """;
121,122c122,123
<         return .eval(importWorld ~ "void main(string[] args) { "
<             ~ "foreach (line; stdin.byLine()) { " ~ eval ~ "; } }");
---
>         return .eval(importWorld ~ "void main(string[] args)\n{\n"
>             ~ "foreach (line; stdin.byLine()) { " ~ eval ~ ";\n}\n");
126,127c127,128
<         return .eval(importWorld ~ "void main(string[] args) { "
<                 ~ eval ~ "; }");
---
>         return .eval(importWorld ~ "void main(string[] args)\n{\n"
>                 ~ eval ~ ";\n}\n");


This helps debugging by putting the "user code" properly on its own lines.


March 04, 2009
Georg Wrede wrote:
> No, it's bash having a problem.
> 
> And I wouldn't make a bug report, it's too much to ask that all of linux is made msdos-file proof. :-)

Linux has actually gotten a lot better. As late as 2000, even gnu make couldn't read makefiles with CR's in them.


> The shebang stuff stumbles on a ^M at the end. I tested it without rdmd and got the same problem.

At least it lets us off the hook!
March 04, 2009

Georg Wrede wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>> And now a major gripe: I have just spent *half a day* trying to figure out what's wrong when I try to use shebang with rdmd. I was basically using hello.d with a shebang. And with rdmd I got this peculiar error message:
>>>
>>> .d'nnot read file ' /usr/local/digitalmars/dmd1040/linux/bin/rdmd: Couldn't compile or execute ./numma.d.
>>>
>>> Just now I figured it out: numma.d was a copy of hello.d, which of course has Windows line endings. Aaaaaaaaaaaaaaaarrrrghhhhhh!
>>
>>
>> Is that a bug in rdmd or elsewhere? We should as far as possible work seamlessly with different line endings.
> 
> No, it's bash having a problem.
> 
> And I wouldn't make a bug report, it's too much to ask that all of linux is made msdos-file proof. :-)
> 
> The shebang stuff stumbles on a ^M at the end. I tested it without rdmd and got the same problem.

Ray, when Cygwin asks if you want to use MSDOS newlines, you say YES!

Of course, then it chokes on anything extracted from a tarball...

  -- Daniel
March 04, 2009
On Wed, Mar 4, 2009 at 6:11 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>
> Linux has actually gotten a lot better. As late as 2000, even gnu make couldn't read makefiles with CR's in them.

OT - it's weird to think that that was almost a decade ago.  Ten years!

2000 used to sound so futuristic, and now it sounds quaint :P
March 04, 2009
Should I be able to

$ rdmd --eval='printf("Yay, rdmd!")'

March 04, 2009
Jarrett Billingsley wrote:
> On Wed, Mar 4, 2009 at 6:11 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Linux has actually gotten a lot better. As late as 2000, even gnu make
>> couldn't read makefiles with CR's in them.
> 
> OT - it's weird to think that that was almost a decade ago.  Ten years!
> 
> 2000 used to sound so futuristic, and now it sounds quaint :P

Yep. Horrible. 2037 is approaching with giant leaps. That's the year I expect to die of old age, at 80. Better grab my Vodka right now!

March 05, 2009
Georg Wrede wrote:
> Should I be able to
> 
> $ rdmd --eval='printf("Yay, rdmd!")'
> 

Yah. For my money, I can't fathom working in D without rdmd. Now with --eval and passable regexes it's even better because I can easily do tasks (from shell files) that would take longer in Perl.

Since the current source uses the not-yet-released phobos, I wanted to attach a binary so you can try it, but it's too big for the news server.


Andrei
March 05, 2009
Andrei Alexandrescu wrote:
> Georg Wrede wrote:
>> Should I be able to
>> 
>> $ rdmd --eval='printf("Yay, rdmd!")'
>> 
> 
> Yah. For my money, I can't fathom working in D without rdmd.

You can't imagine the initial resistance... :-)

> Now with --eval and passable regexes it's even better because I can
> easily do tasks (from shell files) that would take longer in Perl.

That, and one could concentrate on one language. And Pride!! "We do it
with D!"

> Since the current source uses the not-yet-released phobos, I wanted
> to attach a binary so you can try it, but it's too big for the news
> server.

Yup, I've been fighting and tweaking and compiling...

And the thought crossed my mind, too.
March 05, 2009
Georg Wrede wrote:
> Andrei Alexandrescu wrote:
>> Georg Wrede wrote:
>>> Should I be able to
>>>
>>> $ rdmd --eval='printf("Yay, rdmd!")'
>>>
>>
>> Yah. For my money, I can't fathom working in D without rdmd.
> 
> You can't imagine the initial resistance... :-)
> 
>> Now with --eval and passable regexes it's even better because I can
>> easily do tasks (from shell files) that would take longer in Perl.
> 
> That, and one could concentrate on one language. And Pride!! "We do it
> with D!"
> 
>> Since the current source uses the not-yet-released phobos, I wanted
>> to attach a binary so you can try it, but it's too big for the news
>> server.
> 
> Yup, I've been fighting and tweaking and compiling...
> 
> And the thought crossed my mind, too.

FYI, I just implemented caching of the executables generated by --eval. They'll be kept around for 24 hours. It's pretty neat. On my laptop, the first --eval='printf("Yay, rdmd!\n")' takes 0.34 seconds to compile and run. Subsequent calls are under 0.1 (practically instant).


Andrei
March 05, 2009
Andrei Alexandrescu wrote:
> Georg Wrede wrote:
>> Andrei Alexandrescu wrote:
>>> Georg Wrede wrote:
>>>> Should I be able to
>>>>
>>>> $ rdmd --eval='printf("Yay, rdmd!")'
>>>>
>>>
>>> Yah. For my money, I can't fathom working in D without rdmd.
>>
>> You can't imagine the initial resistance... :-)
>>
>>> Now with --eval and passable regexes it's even better because I can
>>> easily do tasks (from shell files) that would take longer in Perl.
>>
>> That, and one could concentrate on one language. And Pride!! "We do it
>> with D!"
>>
>>> Since the current source uses the not-yet-released phobos, I wanted
>>> to attach a binary so you can try it, but it's too big for the news
>>> server.
>>
>> Yup, I've been fighting and tweaking and compiling...
>>
>> And the thought crossed my mind, too.
> 
> FYI, I just implemented caching of the executables generated by --eval. They'll be kept around for 24 hours. It's pretty neat. On my laptop, the first --eval='printf("Yay, rdmd!\n")' takes 0.34 seconds to compile and run. Subsequent calls are under 0.1 (practically instant).

Just downloaded D 2.026 and tried rdmd. No eval?????

$ rdmd --help
Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]...
Builds (with dependents) and runs a D program.
Example: rdmd -release myprog --myprogparm 5

Any option to be passed to dmd must occur before the program name. In addition
to dmd options, rdmd recognizes the following options:
  --build-only      just build the executable, don't run it
  --chatty          write dmd commands to stdout before executing them
  --compiler=comp   use the specified compiler (e.g. gdmd) instead of dmd
  --dry-run         do not compile, just show what commands would be run
                      (implies --chatty)
  --force           force a rebuild even if apparently not necessary
  --help            this message
  --man             open web browser on manual page


I'd *really* appreciate a --version switch. (Probably, instead of fancy version numbers, either the repo version, and/or just plain compilation date would be nice.) Currently, since the binary is packed, there is no way to even peek at the strings in hopes of getting a clue....


It also seems to accept just any switch:

$ rdmd --bullcrap="bull crap"
Error: crap.d: No such file or directory

And from my bash dmd-wrapper log:

compiling /usr/local/digitalmars/dmd2026/linux/bin/dmd --bullcrap=bull -v -o- crap.d

--------
I hope it's not just me...