January 21, 2017
On 2017-01-21 00:52, 岩倉 澪 wrote:

> This has already been fixed? Is this fix in a stable release yet? I
> might not be on the latest version...

It's fixed in DMD, _not_ in RDMD.

-- 
/Jacob Carlborg
January 21, 2017
On 01/20/2017 09:15 AM, Russel Winder via Digitalmars-d wrote:
> On Fri, 2017-01-20 at 07:10 +0000, Andrei Alexandrescu via Digitalmars-
> d wrote:
> […]
>>
>> It would be worth it. I think a fix takes some thinking because if I
>> remember correctly the compiler does not accept files without an
>> extension as input. So rdmd would need to use a workaround - e.g.
>> create
>> a temporary symlink, compile, and remove the symlink. -- Andrei
>
> Someone mentioned that rdmd can be separated from the dmd distribution
> and distributed on it's own. I think this would be a splendid idea.
> rdmd over ldc2 could then be distributed via Debian and Fedora
> packaging by the people who package ldc2 for Debian and Fedora.

rdmd is a single-file program distributed under a very permissive license. Would you care to repackage it the way you find more appropriate? -- Andrei

January 22, 2017
On Sat, 2017-01-21 at 11:30 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
[…]
> 
> rdmd is a single-file program distributed under a very permissive license. Would you care to repackage it the way you find more appropriate? -- Andrei

The "problem" here is the role of the D Tools repository. Is it solely for DMD, or is it supposed to be something that can be packaged independent of a particular D compiler. As it is I am not sure it can be the unit of packaging.

Actually the biggest problem is that the repository appears to have no licence statement so it is not clear what may or may not be done.

I believe it may be easiest for the dlang project to separate out
rdmd.d and it's test into a separate repository so that it can have a
development life all of it's own – with a licence acceptable to Debian
and Fedora. It can then have a Make, CMake, or Meson build added so as
to pass the requirements of those distributions (unless Dub has been
added to the list of acceptable build tools). Then it may be possible
to get the same people who package ldc for Debian and Fedora to package
rdmd such that is finds the compilers in some defined order.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

January 22, 2017
On Friday, 20 January 2017 at 03:59:12 UTC, 岩倉 澪 wrote:
> Is anyone else using D for scripting?

Yes!

> I keep my scripts in ~/scripts so that I can just pull them from github and go on my merry way, with symlinks in /usr/local/bin, but rdmd doesn't -I the real directory, it does -I/usr/local/bin, and if I symlink a script.d as /usr/local/bin/script, it can't find the module.
> I can pass -I/home/mio/scripts on the shebang line at least...
>
> Furthermore, if I -J a folder with string imports I would have to type out the fully qualified path just like with -I. It would be so much more convenient if rdmd would follow the symlink to the scripts directory, change the working directory, and then compile, or something like that.
>
> I feel like the shebang is totally worth it if I could name my file without .d and symlink to it. Would it be reasonable to change rdmd to allow these features? I'd be happy to look into writing a patch for it if it wouldn't be a waste of time.

No comments on rdmd, but have you tried using dub instead of rdmd for scripts.  Makes it easier if you have dependencies on code.dlang.org modules.  You can embed the dub.sdl in the header of your script.


January 22, 2017
On 1/22/17 7:45 AM, Russel Winder via Digitalmars-d wrote:
> On Sat, 2017-01-21 at 11:30 -0500, Andrei Alexandrescu via Digitalmars-
> d wrote:
> […]
>>
>> rdmd is a single-file program distributed under a very permissive
>> license. Would you care to repackage it the way you find more
>> appropriate? -- Andrei
>
> The "problem" here is the role of the D Tools repository. Is it solely
> for DMD, or is it supposed to be something that can be packaged
> independent of a particular D compiler. As it is I am not sure it can
> be the unit of packaging.
>
> Actually the biggest problem is that the repository appears to have no
> licence statement so it is not clear what may or may not be done.

It's also the simplest to solve. Should be Boost. Please create a PR copying the Boost license (from e.g. Phobos itself) to the tools repo. Thanks. -- Andrei

January 22, 2017
On Sunday, 22 January 2017 at 13:24:48 UTC, Andrei Alexandrescu wrote:
> It's also the simplest to solve. Should be Boost. Please create a PR copying the Boost license (from e.g. Phobos itself) to the tools repo. Thanks. -- Andrei

RDMD does have license statement already https://github.com/dlang/tools/blob/master/rdmd.d#L9-L11

January 22, 2017
On Sunday, 22 January 2017 at 12:45:26 UTC, Russel Winder wrote:
> The "problem" here is the role of the D Tools repository. Is it solely for DMD, or is it supposed to be something that can be packaged independent of a particular D compiler. As it is I am not sure it can be the unit of packaging.

Some time ago I have been packaging tools from that repo build with LDC in Arch Linux, it is trivially doable (see https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dtools#n26).
January 24, 2017
On Sun, 2017-01-22 at 13:50 +0000, Dicebot via Digitalmars-d wrote:
> On Sunday, 22 January 2017 at 13:24:48 UTC, Andrei Alexandrescu wrote:
> > It's also the simplest to solve. Should be Boost. Please create a PR copying the Boost license (from e.g. Phobos itself) to the tools repo. Thanks. -- Andrei
> 
> RDMD does have license statement already https://github.com/dlang/tools/blob/master/rdmd.d#L9-L11

The repository README.md needs to state what the licence is for the items in the repository if they are all the same or what the licence is for what files so that it is obvious from the repository front page what may and may not be done with the content.

Are all files under the Boost licence?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

January 24, 2017
On Sun, 2017-01-22 at 13:53 +0000, Dicebot via Digitalmars-d wrote:
> On Sunday, 22 January 2017 at 12:45:26 UTC, Russel Winder wrote:
> > The "problem" here is the role of the D Tools repository. Is it solely for DMD, or is it supposed to be something that can be packaged independent of a particular D compiler. As it is I am not sure it can be the unit of packaging.
> 
> Some time ago I have been packaging tools from that repo build
> with LDC in Arch Linux, it is trivially doable (see
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?
> h=packages/dtools#n26).

Perhaps we can convince the people packaging LDC for Debian and Fedora to do the equivalent for those distributions?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

January 24, 2017
On 01/24/2017 10:07 AM, Russel Winder via Digitalmars-d wrote:
> Are all files under the Boost licence?

Affirmative.
1 2
Next ›   Last »