Re: version identifier hygiene
On 2017-01-16 21:04, Ali Çehreli wrote:
It is plausible to compile and link the sources of multiple packages on
the same command line at the same. (I'm not sure whether this is
required for e.g. LLVM's link-time optimization (LTO) but I think it
helps the compiler as well.)
The trouble is, the version identifiers used by one package may look
strange on the command line and even contradict with another package's:
dmd -version=use-fibers a/a.d b/b.d
use-fibers? Who is using fibers? Does it have any effect on the other
package as well?
So, I think it's a good idea to name-mangle version identifiers with
prefixed package names (a-use-fibers instead of use-fibers):
dmd -version=a-use-fibers a/a.d b/b.d
What do you think?
Is there a way of managing this from the outside? I couldn't do this for
a package by introducing a new file that "translates" to what it
understands:
version (a-use-fibers) {
version=use-fibers;
}
I tried putting it in a module and importing by all sources of package
'a' but version did not have affect on the modules that imported it.
Yeah, I think it only applies to the module it's set in.
String mixins would probably work but it already feels too intrusive to
"fix" third party packages like that.
I don't think it's possible to fix from the outside. I would rather see
that the library is adopted for that. Or even better using some kind of
config file. With Dub it's possible to generate something like a config
file with preGenerateCommands. That config file could look something like:
module liba.config;
version (liba_use_fibers)
enum useFibers = true;
else
enum useFibers = false;
Then the library would use "static if" instead of "version" to pick the
correct implementation.
Or if the user of the library could supply the config file from the
beginning then no version statements are needed. Not sure if that's
possible though.
--
/Jacob Carlborg
Re: Chain a range of ranges?
On Tuesday, 17 January 2017 at 03:21:39 UTC, Yuxuan Shui wrote: The built in chain seems to only be able to chain a fixed number of ranges, is there a way to chain a range/array of ranges? See std.algorithm.iteration.joiner
Chain a range of ranges?
The built in chain seems to only be able to chain a fixed number of ranges, is there a way to chain a range/array of ranges?
Re: Initializing floating point types with explicit mantisa and exponent
On Tuesday, 17 January 2017 at 00:08:24 UTC, Nordlöw wrote: How do I best initialize a D double to an exact mantissa and exponent representation? I'm specifically interested in 2^^i for all i in [min_exp, max_exp] See std.bitmanip : FloatRep , DoubleRep;
Re: Initializing floating point types with explicit mantisa and exponent
On Tuesday, 17 January 2017 at 00:08:24 UTC, Nordlöw wrote: How do I best initialize a D double to an exact mantissa and exponent representation? I'm specifically interested in 2^^i for all i in [min_exp, max_exp] This mach module can do the job: https://github.com/pineapplemachine/mach.d/blob/master/mach/math/floats/inject.d
Initializing floating point types with explicit mantisa and exponent
How do I best initialize a D double to an exact mantissa and exponent representation? I'm specifically interested in 2^^i for all i in [min_exp, max_exp]
Re: Thread will get garbage collected?
On Monday, 16 January 2017 at 22:08:56 UTC, JN wrote:
Am I correctly understanding, that after going out of scope,
it's possible for GC to destroy my thread before the file
finishes loading? How to prevent GC from destroying my thread
before it finishes and make sure the file is loaded completely?
The GC may collect it as soon as there's no reference to the
Thread object anymore. But you'll probably want to keep a
reference anyway, to join it (wait until it's finished),
something like:
Thread loadFileAsync(string path)
{
// start() returns `this`
return new Thread({ writeln(readText(path)); }).start();
}
void main()
{
auto thread = loadFileAsync("foo.txt");
// [do something useful in parallel]
// wait for other thread
thread.join();
}
Thread will get garbage collected?
I'm looking at the example code for core.thread Thread class:
new Thread({
// Codes to run in the newly created thread.
}).start();
let's imagine I put the code in a function:
void loadFileAsync(string path)
{
new Thread({
writeln(readText(path));// imagine the file is
big so it takes some time
}).start();
}
void main()
{
loadFileAsync("foo.txt");
}
Am I correctly understanding, that after going out of scope, it's
possible for GC to destroy my thread before the file finishes
loading? How to prevent GC from destroying my thread before it
finishes and make sure the file is loaded completely?
version identifier hygiene
It is plausible to compile and link the sources of multiple packages on
the same command line at the same. (I'm not sure whether this is
required for e.g. LLVM's link-time optimization (LTO) but I think it
helps the compiler as well.)
The trouble is, the version identifiers used by one package may look
strange on the command line and even contradict with another package's:
dmd -version=use-fibers a/a.d b/b.d
use-fibers? Who is using fibers? Does it have any effect on the other
package as well?
So, I think it's a good idea to name-mangle version identifiers with
prefixed package names (a-use-fibers instead of use-fibers):
dmd -version=a-use-fibers a/a.d b/b.d
What do you think?
Is there a way of managing this from the outside? I couldn't do this for
a package by introducing a new file that "translates" to what it
understands:
version (a-use-fibers) {
version=use-fibers;
}
I tried putting it in a module and importing by all sources of package
'a' but version did not have affect on the modules that imported it.
String mixins would probably work but it already feels too intrusive to
"fix" third party packages like that.
Ali
Re: CMake support for D
On Mon, 2017-01-16 at 17:47 +, King_DuckZ via Digitalmars-d-learn wrote: > […] > > Meson can build D stuff out of the box. > > > > Hadn't heard of this before, I'll have a look. Btw I don't see > any mention of D on their home page. It is very nice. D seems to work OOTB. […] > I'm not saying we shouldn't be learning things, but time is > limited and I'd rather practice my C++ or D than learn yet > another build system, especially if I only have limited use for > it :) Some of us find build fun. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using Dub
On Mon, 2017-01-16 at 16:47 +, cym13 via Digitalmars-d-learn wrote: > […] > > What do you mean it failed? I did that on another computer to > test and it works flawlessly for me. > > […] trying a settings.sdl file failed setting.json works. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Using Dub
On Mon, 2017-01-16 at 16:51 +, cym13 via Digitalmars-d-learn wrote: > […] > Oh, maybe you're on windows, in which case the settings.json file > must be placed in either $ProgramData\dub or in $APPDATA\dub. > Relevant lines of dub.d: > https://github.com/dlang/dub/blob/master/source/dub/dub.d#L165 Windows is anathema. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Namespaces like C++
On Monday, 16 January 2017 at 19:17:57 UTC, Mike Parker wrote:
D namespaces generally follow the format [package
names].moduleName.Type. So to have ui.Manager, then either the
module, not the package, needs to be named 'ui', or you need to
do the following:
// file ui/package.d
module ui;
public import ui.manager;
// file ui/manager.d
module ui.manager;
class Manager {}
Then you should be able to use ui.Manager and bypass the module
name. The alternatives of static and named imports also work,
but they need to be repeated in every module in which you want
to use them.
Thanks! That did the trick!
Re: Namespaces like C++
On Monday, 16 January 2017 at 18:02:09 UTC, Andrey wrote:
Hello, can I using namespaces like in C++, for example:
ui::Widget or ui::Manager? I created ui/widget.d and
ui/manager.d for implementation classes Widget and Manager, bun
I can't import their correctly for using ui.Manager uiManager;
It should be:
ui.manager.Manager uiManager;
D namespaces generally follow the format [package
names].moduleName.Type. So to have ui.Manager, then either the
module, not the package, needs to be named 'ui', or you need to
do the following:
// file ui/package.d
module ui;
public import ui.manager;
// file ui/manager.d
module ui.manager;
class Manager {}
Then you should be able to use ui.Manager and bypass the module
name. The alternatives of static and named imports also work, but
they need to be repeated in every module in which you want to use
them.
Re: Referring to array element by descriptive name
On Monday, 16 January 2017 at 19:03:17 UTC, albert-j wrote: Thank you for all your answers. I was concerned because I'm dealing with a small function that is called many times and where the bulk of the calculations in the simulation takes place. So even 5% performance difference would be significant for me. But it is good to know that compilers are smart enough to optimize this. A while ago I had to deal with that fact, that the optimizations that it does over several levels is often better than my own. Using shifts which obfuscates that I was actually doing a divide. I tried writing a unique array handler to shave a few operations and save time, only to get no real benefit from it.
Re: Referring to array element by descriptive name
Thank you for all your answers. I was concerned because I'm dealing with a small function that is called many times and where the bulk of the calculations in the simulation takes place. So even 5% performance difference would be significant for me. But it is good to know that compilers are smart enough to optimize this.
Re: Namespaces like C++
On Mon, 16 Jan 2017 18:02:09 +, Andrey wrote: > Hello, can I using namespaces like in C++, for example: ui::Widget or > ui::Manager? I created ui/widget.d and ui/manager.d for implementation > classes Widget and Manager, bun I can't import their correctly for using > ui.Manager uiManager; > If it is impossible, then what is the best way to using namespaces in D? > Should I naming my classes with prefix e.g. UIManager and UIWidget? You can do either a static import or renamed import. The static import requires using the fully-qualified name; renamed imports let you set a local name for the module. static import ui.widget; ui.widget.SomeWidget w; import mymanager = ui.manager; mymanager.uiManager m; For more information on modules see http://dlang.org/spec/module.html --Ryan
Namespaces like C++
Hello, can I using namespaces like in C++, for example: ui::Widget or ui::Manager? I created ui/widget.d and ui/manager.d for implementation classes Widget and Manager, bun I can't import their correctly for using ui.Manager uiManager; If it is impossible, then what is the best way to using namespaces in D? Should I naming my classes with prefix e.g. UIManager and UIWidget?
Re: Is it ok to inherit multiple times same templated interface?
On Sunday, 15 January 2017 at 23:25:25 UTC, Ryan wrote: How would overloading work? Overload resolution works based on function/method parameters, not return types. In the example you gave the 3 get functions are indistinguishable. If the template parameter was used for a method parameter type, then they would be distinguishable. Since the functions all have the same signature and interfaces can't store internal state, it doesn't matter which one is called.
Re: CMake support for D
On Monday, 16 January 2017 at 12:29:46 UTC, Russel Winder wrote: On Mon, 2017-01-16 at 11:40 +, King_DuckZ via Digitalmars-d-learn wrote: On Sunday, 3 January 2016 at 17:30:15 UTC, Dibyendu Majumdar wrote: > Does CMake recognise D in the enable_language command? > > If not is there a workaround? > > Thanks and Regards > Dibyendu One year later, is there any progress on this? Now that gdc has gained support for .so (it seems), lack of cmake support is the only thing that is preventing me from adopting D. I agree that cmake is not the prettiest thing out there, but I think there are many good reasons for wanting it: Does this do the job? https://github.com/dcarp/cmake-d I had forgotten about that... I even used it at some point a long time ago, maybe I should give it another try, since it seems to have received lots of commits since then! 1) As already said, it's needed for CLion I wish CLion would support Meson. Meson can build D stuff out of the box. Hadn't heard of this before, I'll have a look. Btw I don't see any mention of D on their home page. 2) Many programmers, including myself, are already familiar with its syntax - pretty or not, learning a new tool is extra work Which can actually be a good thing, learning is something we should all be doing all the time. I'm not saying we shouldn't be learning things, but time is limited and I'd rather practice my C++ or D than learn yet another build system, especially if I only have limited use for it :) 3) As far as I know, you can't mix C++ and D with dub I'm having difficulty getting Dub to compile D and clean up afterwards. :-( 4) I could just drop D code in my pre-existing C++ projects without much effort on the build system I was going to try moving Me TV from C++ to D, but the path of least resistance is to just continue with it in C++ and put all the C++17 stuff in. I feel the same about many small tools I wrote. I hope to hear some promising news on this side!
Re: Changing template parameters
On Monday, 16 January 2017 at 16:08:07 UTC, Rene Zwanenburg wrote:
On Monday, 16 January 2017 at 15:56:16 UTC, Jack Stouffer wrote:
Same way you use any template parameters,
auto i = uniform!("(]")(0, 1000);
Also, if the template parameter consists of a single token you
can omit the parens:
auto i = uniform!"(]"(0, 1000);
Ahhh, thanks a lot!
Re: Using Dub
On Monday, 16 January 2017 at 16:47:29 UTC, cym13 wrote: On Monday, 16 January 2017 at 10:59:33 UTC, Russel Winder wrote: On Mon, 2017-01-16 at 10:47 +, cym13 via Digitalmars-d-learn wrote: On Monday, 16 January 2017 at 09:42:03 UTC, Russel Winder wrote: > On Sun, 2017-01-15 at 17:44 +, cym13 via > Digitalmars-d-learn wrote: > > [...] > > Will an SDL file also work? I don't think so, but as that's about the only option you can put in that file it's ok to use JSON. I tried it, it failed. :-( Humans should never have to manually write XML or JSON. What do you mean it failed? I did that on another computer to test and it works flawlessly for me. This configuration file can contain only two options: default compiler and urls to reach when looking for packets. It's litterally 3 lines, while I support the fact that one should never have to write XML that's about as concise as it can get. Oh, maybe you're on windows, in which case the settings.json file must be placed in either $ProgramData\dub or in $APPDATA\dub. Relevant lines of dub.d: https://github.com/dlang/dub/blob/master/source/dub/dub.d#L165
Re: Using Dub
On Monday, 16 January 2017 at 10:59:33 UTC, Russel Winder wrote:
On Mon, 2017-01-16 at 10:47 +, cym13 via
Digitalmars-d-learn wrote:
On Monday, 16 January 2017 at 09:42:03 UTC, Russel Winder
wrote:
> On Sun, 2017-01-15 at 17:44 +, cym13 via
> Digitalmars-d-learn wrote:
> > On Sunday, 15 January 2017 at 13:23:25 UTC, Russel Winder
> > wrote:
> > > Is there any way of setting dub to default to ldc2
> > > rather than dmd as the compiler of use? (I do not want
> > > to have to put --compiler ldc2 on every dub command.)
> >
> > Create a file ~/.dub/settings.json with the following
> > content:
> >
> > {
> > "defaultCompiler": "ldc2"
> > }
>
> Will an SDL file also work?
I don't think so, but as that's about the only option you can
put in that file it's ok to use JSON.
I tried it, it failed. :-(
Humans should never have to manually write XML or JSON.
What do you mean it failed? I did that on another computer to
test and it works flawlessly for me.
This configuration file can contain only two options: default
compiler and urls to reach when looking for packets. It's
litterally 3 lines, while I support the fact that one should
never have to write XML that's about as concise as it can get.
Re: Changing template parameters
On Monday, 16 January 2017 at 15:56:16 UTC, Jack Stouffer wrote:
Same way you use any template parameters,
auto i = uniform!("(]")(0, 1000);
Also, if the template parameter consists of a single token you
can omit the parens:
auto i = uniform!"(]"(0, 1000);
Re: Using Dub
On Monday, 16 January 2017 at 09:40:55 UTC, Russel Winder wrote: On the one hand Cargo works wonderfully with Rust so I had hoped Dub would work wonderfully with D. Sadly I am finding it doesn't. Possibly my fault, but still annoying. Cargo does not have multiple Rust compilers as an option. Dub could look to find for compiler if it is not set, but that may disappoint users who have multiple compilers installed (myself included)...
Re: Changing template parameters
On Monday, 16 January 2017 at 15:32:33 UTC, Dlearner wrote:
Hey, quick question!
I'm messing around with std.random and noticed that you can
change the boundaries parameter to be either open or closed
intervals on either side. By default it is "[)". How do I
change these template parameters?
Same way you use any template parameters,
auto i = uniform!("(]")(0, 1000);
Changing template parameters
Hey, quick question! I'm messing around with std.random and noticed that you can change the boundaries parameter to be either open or closed intervals on either side. By default it is "[)". How do I change these template parameters?
Re: Parsing a UTF-16LE file line by line, BUG?
On Sunday, 15 January 2017 at 19:48:04 UTC, Nestor wrote:
I see. So correcting my original doubt:
How could I parse an UTF16LE file line by line (producing a
proper string in each iteration) without loading the entire
file into memory?
Could... roll your own? Although if you wanted it to be UTF-8
output instead would require a second pass or better yet changing
how the i iterated.
char[] getLine16LE(File inp = stdin) {
static char[1024*4] buffer; //4k reusable buffer, NOT thread
safe
int i;
while(inp.rawRead(buffer[i .. i+2]) != null) {
if (buffer[i] == '\n')
break;
i+=2;
}
return buffer[0 .. i];
}
Re: Quine using strings?
On Monday, 16 January 2017 at 09:33:23 UTC, Nestor wrote: PS. Isn't this approach considered "cheating" in quines? ;) I'm afraid so - while the empty program has been technically accepted as being a quine (e.g. http://www.ioccc.org/1994/smr.hint) programs which use file io to read their own source have not.
Re: CMake support for D
On Mon, 2017-01-16 at 11:40 +, King_DuckZ via Digitalmars-d-learn wrote: > On Sunday, 3 January 2016 at 17:30:15 UTC, Dibyendu Majumdar > wrote: > > Does CMake recognise D in the enable_language command? > > > > If not is there a workaround? > > > > Thanks and Regards > > Dibyendu > > One year later, is there any progress on this? Now that gdc has > gained support for .so (it seems), lack of cmake support is the > only thing that is preventing me from adopting D. I agree that > cmake is not the prettiest thing out there, but I think there are > many good reasons for wanting it: Does this do the job? https://github.com/dcarp/cmake-d > 1) As already said, it's needed for CLion I wish CLion would support Meson. Meson can build D stuff out of the box. > 2) Many programmers, including myself, are already familiar with > its syntax - pretty or not, learning a new tool is extra work Which can actually be a good thing, learning is something we should all be doing all the time. > 3) As far as I know, you can't mix C++ and D with dub I'm having difficulty getting Dub to compile D and clean up afterwards. :-( > 4) I could just drop D code in my pre-existing C++ projects > without much effort on the build system I was going to try moving Me TV from C++ to D, but the path of least resistance is to just continue with it in C++ and put all the C++17 stuff in. > I hope to hear some promising news on this side! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CMake support for D
On Sunday, 3 January 2016 at 17:30:15 UTC, Dibyendu Majumdar wrote: Does CMake recognise D in the enable_language command? If not is there a workaround? Thanks and Regards Dibyendu One year later, is there any progress on this? Now that gdc has gained support for .so (it seems), lack of cmake support is the only thing that is preventing me from adopting D. I agree that cmake is not the prettiest thing out there, but I think there are many good reasons for wanting it: 1) As already said, it's needed for CLion 2) Many programmers, including myself, are already familiar with its syntax - pretty or not, learning a new tool is extra work 3) As far as I know, you can't mix C++ and D with dub 4) I could just drop D code in my pre-existing C++ projects without much effort on the build system I hope to hear some promising news on this side!
Re: Using Dub
On Mon, 2017-01-16 at 10:47 +, cym13 via Digitalmars-d-learn wrote:
> On Monday, 16 January 2017 at 09:42:03 UTC, Russel Winder wrote:
> > On Sun, 2017-01-15 at 17:44 +, cym13 via
> > Digitalmars-d-learn wrote:
> > > On Sunday, 15 January 2017 at 13:23:25 UTC, Russel Winder
> > > wrote:
> > > > Is there any way of setting dub to default to ldc2 rather
> > > > than dmd as the compiler of use? (I do not want to have to
> > > > put --compiler ldc2 on every dub command.)
> > >
> > > Create a file ~/.dub/settings.json with the following content:
> > >
> > > {
> > > "defaultCompiler": "ldc2"
> > > }
> >
> > Will an SDL file also work?
>
> I don't think so, but as that's about the only option you can put
> in that file it's ok to use JSON.
I tried it, it failed. :-(
Humans should never have to manually write XML or JSON.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using Dub
On Monday, 16 January 2017 at 09:42:03 UTC, Russel Winder wrote:
On Sun, 2017-01-15 at 17:44 +, cym13 via
Digitalmars-d-learn wrote:
On Sunday, 15 January 2017 at 13:23:25 UTC, Russel Winder
wrote:
> Is there any way of setting dub to default to ldc2 rather
> than dmd as the compiler of use? (I do not want to have to
> put --compiler ldc2 on every dub command.)
Create a file ~/.dub/settings.json with the following content:
{
"defaultCompiler": "ldc2"
}
Will an SDL file also work?
I don't think so, but as that's about the only option you can put
in that file it's ok to use JSON.
emplacing extern(C++) class
I'm interfacing to C++ I using emplacing extern(C++) to malloc'ed memory like http://wiki.dlang.org/Memory_Management (see Explicit Class Instance Allocation) This code segfaulted with extern(C++) TestClass. I guess it's because extern(C++) class aren't rooted from Object so instead of destroy(obj) (in heapDeallocation) I should use obj.__dtor()? It works, but I'm not expert and so not sure. Could someone confirm or no my thoughts? Thank in advance
Re: Dub, SDL, and Subpackages
On Mon, 2017-01-16 at 23:16 +1300, rikki cattermole via Digitalmars-d- learn wrote: > […] > Change targetType to "library" and it should work. > It doesn't auto infer that it should be library since you have > overriden > that ability of it. That isn't going to work because it then tries to build everything and then gets the dependencies wrong. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Dub and cleaning
Is it really the case that Dub does not have a way of cleaning up all the stuff it creates? I tried "dub clean" and it doesn't clean. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dub, SDL, and Subpackages
On 16/01/2017 11:14 PM, Russel Winder via Digitalmars-d-learn wrote:
The Dub manual says that:
name "mylib"
targetType "none"
dependency "mylib:component1" version="*"
subPackage {
name "component1"
targetType "library"
sourcePaths "component1/source"
importPaths "component1/source"
}
is reasonable. However whenever I try something of this sort I get:
Main package must have a binary target type, not none. Cannot build.
Change targetType to "library" and it should work.
It doesn't auto infer that it should be library since you have overriden
that ability of it.
Dub, SDL, and Subpackages
The Dub manual says that:
name "mylib"
targetType "none"
dependency "mylib:component1" version="*"
subPackage {
name "component1"
targetType "library"
sourcePaths "component1/source"
importPaths "component1/source"
}
is reasonable. However whenever I try something of this sort I get:
Main package must have a binary target type, not none. Cannot build.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using Dub
On Sun, 2017-01-15 at 17:44 +, cym13 via Digitalmars-d-learn wrote:
> On Sunday, 15 January 2017 at 13:23:25 UTC, Russel Winder wrote:
> > Is there any way of setting dub to default to ldc2 rather than
> > dmd as the compiler of use? (I do not want to have to put
> > --compiler ldc2 on every dub command.)
>
> Create a file ~/.dub/settings.json with the following content:
>
> {
> "defaultCompiler": "ldc2"
> }
Will an SDL file also work?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Using Dub
On Sun, 2017-01-15 at 17:25 +, Daniel N via Digitalmars-d-learn wrote: > On Sunday, 15 January 2017 at 13:23:25 UTC, Russel Winder wrote: > > Is there any way of setting dub to default to ldc2 rather than > > dmd as the compiler of use? (I do not want to have to put > > --compiler ldc2 on every dub command.) > > I have never used dub, but I know it's now also bundled with ldc2. On the one hand Cargo works wonderfully with Rust so I had hoped Dub would work wonderfully with D. Sadly I am finding it doesn't. Possibly my fault, but still annoying. There is a Dub package in Debian. It seems to default to GDC rather than LDC, which is annoying. Meson defaults to LDC, but getting it to handle the Dub repository is going to be impossible I suspect. > I would assume that if your PATH to ldc2 comes before that of > dmd, it would find the ldc2 bundled version of dub and it would > do the smart thing(if not, that's a bug). No DMD installed. Seemingly Dub chooses /usr/bin/gdc over /usr/bin/ldc2. :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Quine using strings?
On Monday, 16 January 2017 at 06:41:50 UTC, Basile B. wrote:
I remember on Rosetta to have seen this:
module quine;
import std.stdio;
void main(string[] args)
{
write(import("quine.d"));
}
compiles with: dmd path/quine.d -Jpath
Very good! By the way, module name and arguments aren't needed,
so:
import std.stdio;void main(){write(import("q.d"));}
compile with: "dmd q -J."
PS. Isn't this approach considered "cheating" in quines? ;)
