www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - rdmd problems (OS X Leopard, DMD 2.052)

reply Magnus Lie Hetland <magnus hetland.org> writes:
Hi!

When I installed DMD 2.051 on my OS X boxen, the rdmd executable didn't 
work. I saw others have similar problems online, and concluded that it 
must have been compiled for a more recent version of OS X (Snow 
Leopard, I guess) without the necessary compatibility flags.

I found the rdmd sources online [1] and compiled them myself. (Luckily, 
the other binaries work just fine.) No problems.

Now I'm trying to get DMD 2.052 to work. Same issue with the rdmd 
executable. I tried to compile the same rdmd.d file with the new 
compiler/stdlib, but that failed.

$ dmd rdmd.d
std.contracts has been scheduled for deprecation. Please use 
std.exception instead.
std.date and std.dateparse have been scheduled for deprecation. Please 
use std.datetime instead.
rdmd.d(34): Error: std.regexp.split at 
./../../src/phobos/std/regexp.d(498) conflicts with std.string.split at 
./../../src/phobos/std/string.d(69)
rdmd.d(34): Error: function std.regexp.split (string s, RegExp pattern) 
is not callable using argument types (string)
rdmd.d(34): Error: expected 3 function arguments, not 1

I'm sure I can fix this myself -- but I'm guessing there must be a more 
recent version of the rdmd sources somewhere, assuming that the binary 
in the distribution was compiled with dmd 2.052...? The version in the 
trunk at dsource.org seems to be three months old...

For now I just compiled the rdmd.d from dsource.org with dmd 2.051, and 
use that with dmd 2.052. As rdmd is basically an independent entity, I 
guess that should work well, but this isn't exactly user-friendly 
(i.e., having to replace one of the binaries in the distro with one 
compiled with an older compiler, using sources obtained elsewhere... 
:->).

Not sure if I'm missing The Way to Do It[tm], or if perhaps I should 
submit an issue about this?

[1] http://www.digitalmars.com/d/2.0/rdmd.html

-- 
Magnus Lie Hetland
http://hetland.org
Feb 19 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Magnus Lie Hetland" <magnus hetland.org> wrote in message 
news:ijohel$960$1 digitalmars.com...
 I'm sure I can fix this myself -- but I'm guessing there must be a more 
 recent version of the rdmd sources somewhere, assuming that the binary in 
 the distribution was compiled with dmd 2.052...? The version in the trunk 
 at dsource.org seems to be three months old...

The source repo recently moved over to github: https://github.com/D-Programming-Language That said, the 3-month-old version is still the latest version. Unfortunately, rdmd doesn't seem to have gotten much attention lately. I've had a few patches for it sitting in bugzilla for a number of months. (Not that I'm complaning, I realize there's been other priorities.) Actually, if you want, you can grab a version of rdmd.d with my patches applied here: http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d (Yes, it is 4 months old, and I can do the match: 3 < 4, but this *is* the same as the latest official version just with my patches applied: The latest official commit to rdmd.d was one of my patches (albiet slightly modified, IIRC)) However, the latest version of DMD I used this with was 2.050, so it might still need some updating for 2.052.
Feb 19 2011
next sibling parent reply Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

[snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately. 
 I've had a few patches for it sitting in bugzilla for a number of 
 months. (Not that I'm complaning, I realize there's been other 
 priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my patches 
 applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!
 (Yes, it is 4 months old, and I can do the match: 3 < 4, but this *is* 
 the same as the latest official version just with my patches applied: 
 The latest official commit to rdmd.d was one of my patches (albiet 
 slightly modified, IIRC))
 
 However, the latest version of DMD I used this with was 2.050, so it 
 might still need some updating for 2.052.

Hm. Are most minor releases of DMD backward-incompatible? (Sort of a scary prospect to me, at least...) -- Magnus Lie Hetland http://hetland.org
Feb 20 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Magnus Lie Hetland" <magnus hetland.org> wrote in message 
news:ijrm9q$259n$1 digitalmars.com...
 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately. 
 I've had a few patches for it sitting in bugzilla for a number of months. 
 (Not that I'm complaning, I realize there's been other priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my patches 
 applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!
 (Yes, it is 4 months old, and I can do the match: 3 < 4, but this *is* 
 the same as the latest official version just with my patches applied: The 
 latest official commit to rdmd.d was one of my patches (albiet slightly 
 modified, IIRC))

 However, the latest version of DMD I used this with was 2.050, so it 
 might still need some updating for 2.052.

Hm. Are most minor releases of DMD backward-incompatible? (Sort of a scary prospect to me, at least...)

It used to be fairly common for little things to change, but it's becoming much less and less common (And, as you've seen, when they do change, they're generally very trivial to fix). These days there's typically only these three cases where something might break: A. Someone's code is accidentialy relying on a bug in DMD or Phobos, and that bug gets fixed. Not really a frequent occurrance. B. Certain parts of Phobos are still somewhat in flux (only for D2 though). For instance, std.xml is definitely going to get completely replaced. C. The occasional regression. (Which is less and less common these days, because of both an extensive test suite running on multiple OSes and because we now have a beta mailing list with people who test each release candidate before it's actually relesed.) We used to have occasional breking changes in the language itself (in D2-only), since D2 was the deliberately the "development" branch rather than the "stable" branch that D1 has been, but D2's language spec is pretty much finalized now.
Feb 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ijs1vp$3b3$1 digitalmars.com...
 "Magnus Lie Hetland" <magnus hetland.org> wrote in message 
 news:ijrm9q$259n$1 digitalmars.com...
 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately. 
 I've had a few patches for it sitting in bugzilla for a number of 
 months. (Not that I'm complaning, I realize there's been other 
 priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my patches 
 applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!
 (Yes, it is 4 months old, and I can do the match: 3 < 4, but this *is* 
 the same as the latest official version just with my patches applied: 
 The latest official commit to rdmd.d was one of my patches (albiet 
 slightly modified, IIRC))

 However, the latest version of DMD I used this with was 2.050, so it 
 might still need some updating for 2.052.

Hm. Are most minor releases of DMD backward-incompatible? (Sort of a scary prospect to me, at least...)

It used to be fairly common for little things to change, but it's becoming much less and less common (And, as you've seen, when they do change, they're generally very trivial to fix). These days there's typically only these three cases where something might break: A. Someone's code is accidentialy relying on a bug in DMD or Phobos, and that bug gets fixed. Not really a frequent occurrance. B. Certain parts of Phobos are still somewhat in flux (only for D2 though). For instance, std.xml is definitely going to get completely replaced. C. The occasional regression. (Which is less and less common these days, because of both an extensive test suite running on multiple OSes and because we now have a beta mailing list with people who test each release candidate before it's actually relesed.) We used to have occasional breking changes in the language itself (in D2-only), since D2 was the deliberately the "development" branch rather than the "stable" branch that D1 has been, but D2's language spec is pretty much finalized now.

I just realized I didn't give a direct answer to your question: I'd say that most minor releases of DMD are *not* backward-incompatible.
Feb 20 2011
parent Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-02-20 22:42:06 +0100, Nick Sabalausky said:

[snip]
 We used to have occasional breking changes in the language itself (in 
 D2-only), since D2 was the deliberately the "development" branch rather 
 than the "stable" branch that D1 has been, but D2's language spec is 
 pretty much finalized now.
 

I just realized I didn't give a direct answer to your question: I'd say that most minor releases of DMD are *not* backward-incompatible.

Thanks for both the thorough and the more direct answer. Very helpful/useful :) -- Magnus Lie Hetland http://hetland.org
Feb 21 2011
prev sibling parent reply Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:

 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
 
 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately. 
 I've had a few patches for it sitting in bugzilla for a number of 
 months. (Not that I'm complaning, I realize there's been other 
 priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my patches 
 applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!

Humm. I'm still using the rdmd I had (it seems to work, so as long as I have already compiled it... ;) However: I'm a bit baffled by the --shebang option. What's its purpose, really? If I use rdmd without it in a shebang line, it seems to work fine. If I *do* use --shebang, the code doesn't seem to be compiled/executed at all... It seems like it interprets args[1] as a single string containing all the arguments, splitting it into separate items. That seems well an good -- except (in OS X, at least) it doesn't seem to be needed (I get my arguments just fine without it, and the shebang-line switches work well) ... and it doesn't seem to work (that is, with --shebang, nothing happens). Any thoughts on this? -- Magnus Lie Hetland http://hetland.org
Feb 21 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-21 14:16, Lars T. Kyllingstad wrote:
 On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:

 On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:

 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:

 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately.
 I've had a few patches for it sitting in bugzilla for a number of
 months. (Not that I'm complaning, I realize there's been other
 priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my
 patches applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!

Humm. I'm still using the rdmd I had (it seems to work, so as long as I have already compiled it... ;) However: I'm a bit baffled by the --shebang option. What's its purpose, really? If I use rdmd without it in a shebang line, it seems to work fine. If I *do* use --shebang, the code doesn't seem to be compiled/executed at all... It seems like it interprets args[1] as a single string containing all the arguments, splitting it into separate items. That seems well an good -- except (in OS X, at least) it doesn't seem to be needed (I get my arguments just fine without it, and the shebang-line switches work well) ... and it doesn't seem to work (that is, with --shebang, nothing happens). Any thoughts on this?

Say you have a file "myscript", that starts with the line #!/path/to/interpreter --foo --bar If you run this as ./myscript --hello --world then the args[] received by the interpreter program looks like this: args[0] = "/path/to/interpreter" args[1] = "--foo --bar" args[2] = "./myscript" args[3] = "--hello" args[4] = "--world" This is the case on every shell I've tried on Linux, at least. So if you have multiple rdmd options, it should in principle need --shebang to know that it is being run in a shebang line, so it can expand args[1]. I don't know why it works without --shebang for you, though. :) -Lars

Perhaps he's not passing any arguments to rdmd. -- /Jacob Carlborg
Feb 21 2011
parent Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-02-21 15:17:44 +0100, Jacob Carlborg said:

 On 2011-02-21 14:16, Lars T. Kyllingstad wrote:
 
 Say you have a file "myscript", that starts with the line
 
 #!/path/to/interpreter --foo --bar
 
 If you run this as
 
 ./myscript --hello --world
 
 then the args[] received by the interpreter program looks like this:
 
 args[0] = "/path/to/interpreter"
 args[1] = "--foo --bar"
 args[2] = "./myscript"
 args[3] = "--hello"
 args[4] = "--world"
 
 This is the case on every shell I've tried on Linux, at least.


Let me first clarify: By "nothing happens", I really mean that. When I supply --shebang, the code isn't compiled, and nothing is run. Running the script becomes a no-op. As for your example: The switches to rdmd *don't* appear in args for me. So for example, if I have #!/path/to/rdmd -unittest ... as the shebang line, rdmd finds and passes the -unittest switch to dmd (my unit tests work). I get no problems when I add more switches either (i.e., rdmd doesn't complain). But, as far as I can see, none of these end up in args. (Or are we talking about different things here?) Instead, args[0] contains the full path to the temporary executable built and run by rdmd, and args[1..$] contain any arguments I supplied when running the script. The fact that --shebang borks the whole execution seems like it must be a bug. As for the rest of the behavior, it seems pretty useful to me, but perhaps OS X-specific? (That would be odd, but who knows...) -- Magnus Lie Hetland http://hetland.org
Feb 25 2011
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:

 On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:
 
 On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
 
 [snip]
 Unfortunately, rdmd doesn't seem to have gotten much attention lately.
 I've had a few patches for it sitting in bugzilla for a number of
 months. (Not that I'm complaning, I realize there's been other
 priorities.)

I see. Kind of surprising, given that rdmd is distributed in the official DMD zip file. But, yeah, no complaints. :)
 Actually, if you want, you can grab a version of rdmd.d with my
 patches applied here:
 http://www.dsource.org/projects/semitwist/browser/trunk/rdmdAlt.d

Thanks!

Humm. I'm still using the rdmd I had (it seems to work, so as long as I have already compiled it... ;) However: I'm a bit baffled by the --shebang option. What's its purpose, really? If I use rdmd without it in a shebang line, it seems to work fine. If I *do* use --shebang, the code doesn't seem to be compiled/executed at all... It seems like it interprets args[1] as a single string containing all the arguments, splitting it into separate items. That seems well an good -- except (in OS X, at least) it doesn't seem to be needed (I get my arguments just fine without it, and the shebang-line switches work well) ... and it doesn't seem to work (that is, with --shebang, nothing happens). Any thoughts on this?

Say you have a file "myscript", that starts with the line #!/path/to/interpreter --foo --bar If you run this as ./myscript --hello --world then the args[] received by the interpreter program looks like this: args[0] = "/path/to/interpreter" args[1] = "--foo --bar" args[2] = "./myscript" args[3] = "--hello" args[4] = "--world" This is the case on every shell I've tried on Linux, at least. So if you have multiple rdmd options, it should in principle need --shebang to know that it is being run in a shebang line, so it can expand args[1]. I don't know why it works without --shebang for you, though. :) -Lars
Feb 21 2011
prev sibling parent reply Paolo Invernizzi <arathorn NOSPAM.fastwebnet.it> writes:
Hi Magnus,

This is sligthly OT, but... How I loved AnyGui!
It's nice to see you here, in the D bandwagon...

Cheers, 
Paolo Invernizzi

Magnus Lie Hetland Wrote:

 Hi!
 
 When I installed DMD 2.051 on my OS X boxen, the rdmd executable didn't 
 work. I saw others have similar problems online, and concluded that it 
 must have been compiled for a more recent version of OS X (Snow 
 Leopard, I guess) without the necessary compatibility flags.
 
 I found the rdmd sources online [1] and compiled them myself. (Luckily, 
 the other binaries work just fine.) No problems.
 
 Now I'm trying to get DMD 2.052 to work. Same issue with the rdmd 
 executable. I tried to compile the same rdmd.d file with the new 
 compiler/stdlib, but that failed.
 
 $ dmd rdmd.d
 std.contracts has been scheduled for deprecation. Please use 
 std.exception instead.
 std.date and std.dateparse have been scheduled for deprecation. Please 
 use std.datetime instead.
 rdmd.d(34): Error: std.regexp.split at 
 ./../../src/phobos/std/regexp.d(498) conflicts with std.string.split at 
 ./../../src/phobos/std/string.d(69)
 rdmd.d(34): Error: function std.regexp.split (string s, RegExp pattern) 
 is not callable using argument types (string)
 rdmd.d(34): Error: expected 3 function arguments, not 1
 
 I'm sure I can fix this myself -- but I'm guessing there must be a more 
 recent version of the rdmd sources somewhere, assuming that the binary 
 in the distribution was compiled with dmd 2.052...? The version in the 
 trunk at dsource.org seems to be three months old...
 
 For now I just compiled the rdmd.d from dsource.org with dmd 2.051, and 
 use that with dmd 2.052. As rdmd is basically an independent entity, I 
 guess that should work well, but this isn't exactly user-friendly 
 (i.e., having to replace one of the binaries in the distro with one 
 compiled with an older compiler, using sources obtained elsewhere... 
 :->).
 
 Not sure if I'm missing The Way to Do It[tm], or if perhaps I should 
 submit an issue about this?
 
 [1] http://www.digitalmars.com/d/2.0/rdmd.html
 
 -- 
 Magnus Lie Hetland
 http://hetland.org
 

Feb 22 2011
parent Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-02-22 22:46:41 +0100, Paolo Invernizzi said:

 Hi Magnus,
 
 This is sligthly OT, but... How I loved AnyGui!

Haha, cool :D Yeah, too bad the project died. Oh, well -- at least we tried :)
 It's nice to see you here, in the D bandwagon...

Yeah, I've been looking for a more "close to the metal" language to complement Python for a looong time (using C and C++ when I had to -- and sometimes Java or Cython and what-have-you). At the moment I'm hopeful that D might be what I've been looking for. Loving it so far :) (Still using Python, though. Just came out with a new Python book, "Python Algorithms", last fall ;) </OT> -- Magnus Lie Hetland http://hetland.org
Feb 25 2011