Re: How do I install a library?
On Monday, 10 December 2018 at 00:18:52 UTC, Murilo wrote: Hi guys, thank you for helping me out here, there is this facebook group for the D language, here we can help and teach each other. It is called Programming in D. Please join. https://www.facebook.com/groups/662119670846705/?ref=bookmarks Please stop this spam.
Re: Atomic bit operations
On Tuesday, 11 December 2018 at 01:37:25 UTC, Adam D. Ruppe wrote:
On Monday, 10 December 2018 at 23:20:22 UTC, Crayo List wrote:
Are there atomic equivalents of bt(), btc(), bts(), btr() ...
etc from core.bitop?
Those are intrinsics that compile into a single cpu
instruction, so they are probably already atomic...
Thanks Adam,
They need to be prefixed with 'lock' (on x86) in order to be
atomic.
That's what _interlockedbittestandset() on Windows does.
And what this page says;
https://www.felixcloutier.com/x86/LOCK.html
It may be possible to implement using asm { }, but I was
wondering if there wasn't something out there already doing it.
Re: Atomic bit operations
On Monday, 10 December 2018 at 23:20:22 UTC, Crayo List wrote: Are there atomic equivalents of bt(), btc(), bts(), btr() ... etc from core.bitop? Those are intrinsics that compile into a single cpu instruction, so they are probably already atomic...
Re: Calling function explicitly from mixin template results in recursive call instead
On Monday, 10 December 2018 at 21:16:23 UTC, aliak wrote:
Does this fix your issue?
struct S {
mixin operators ops;
S opBinary(string op, T)(T a) {
alias opBinary = ops.opBinary; // explicitly alias
opBinary in this scope
return opBinary!op(a);
}
}
It does, thanks.
Though I now have problems of the mixin scope not being able to
access overloads of the instantiation scope... I'll just stick
everything in the template since this is just an uphill battle.
Atomic bit operations
Are there atomic equivalents of bt(), btc(), bts(), btr() ... etc from core.bitop? Thanks
Re: Calling function explicitly from mixin template results in recursive call instead
On Sunday, 9 December 2018 at 18:36:50 UTC, Dennis wrote:
I'm using Adam's workaround from
https://issues.dlang.org/show_bug.cgi?id=19365, but now I have
endless recursion. Reduced code:
```
mixin template operators() {
S opBinary(string op: "+")(S rhs) {
return rhs;
}
// (A)
auto opBinary(string op, T)(T rhs) if (false) {
return rhs;
}
}
struct S {
mixin operators ops;
S opBinary(string op, T)(T a) {
return ops.opBinary!op(a);
}
}
void main() {
S.init.opBinary!"+"(S.init);
}
```
Believe it or not, `ops.opBinary!op(a);` doesn't call anything
from the mixin template ops, but it calls itself and it results
in a stack overflow. I think this is a bug, but last time I was
wrong, so maybe someone can explain what's going on here.
I think the docs [0] are not as specific as they can be, but
there's this part: "If the name of a declaration in a mixin is
the same as a declaration in the surrounding scope, the
surrounding declaration overrides the mixin one". Later on
there's a section on disambiguating between conflicting symbols,
but that sections feels wanting. Furthremore, this seems to work
as expected:
mixin template Foo() {
void f() {
writeln("Foo.f");
}
}
mixin Foo foo;
void f() {
writeln("f");
foo.f;
}
void main() {
f;
}
I think I'd file this and see if someone complains.
Does anyone know how to get this working?
Does this fix your issue?
struct S {
mixin operators ops;
S opBinary(string op, T)(T a) {
alias opBinary = ops.opBinary; // explicitly alias
opBinary in this scope
return opBinary!op(a);
}
}
Cheers,
- Ali
[0] https://dlang.org/spec/template-mixin.html#mixin_scope
Re: How to set constant value to environment variable at compile time?
On Mon, 10 Dec 2018 17:58:32 +, aliak wrote:
> string parseConfig(string str) {
>string ret;
>foreach (line; str.split("\n")) {
> auto parts = line.split("=");
> ret ~= `string ` ~ parts[0] ~ ` = "` parts[2] `";`;
>}
>return ret;
> }
That works as long as none of the environment variable values contain a
double quote or a newline character.
Re: How to set constant value to environment variable at compile time?
On Monday, 10 December 2018 at 17:47:37 UTC, Neia Neutuladh wrote: On Mon, 10 Dec 2018 11:08:23 +, Narxa wrote: Hello, people! I would like to have a constant with the value of some environment variable that is defined at compile time. In your build script, echo the environment variable into a file. Then import() that file and use the value. I know I could possibly use 'gdc' to achieve that but I want to use the 'dmd' compiler. Defining variables like that is a language-level feature. gdc supports exactly the same options as dmd. It worked! Thank you very much!
Re: How to set constant value to environment variable at compile time?
On Monday, 10 December 2018 at 11:08:23 UTC, Narxa wrote:
Hello, people!
I would like to have a constant with the value of some
environment variable that is defined at compile time.
In FreePascal, it can be done by defining it in source as:
VALUE_OF_SOMETHING = {$I %SOMETHING%};
And I can call the compiler with (bash):
SOMETHING='Anything' export SOMETHING;
And it will automatically assign VALUE_OF_SOMETHING to
'Anything'.
In GCC C compiler, the solution I found was more complicated
but it worked.
I had to explicitly define the environment variable when
calling the compiler with:
gcc -DSOMETHING=\""Anything"\" -o
Now, I would like to do that with the 'dmd' compiler.
I know I could possibly use 'gdc' to achieve that but I want to
use the 'dmd' compiler.
Is it possible to do that such a thing or through source or any
other means?
Thank you!
I don't know if it's possible but one way to do it would be to
use the -J switch and give it a config file that has contents:
VAR1=Value1
VAR2=Value2
And then in source code:
immutable config = import("config");
mixin(parseConfig);
string parseConfig(string str) {
string ret;
foreach (line; str.split("\n")) {
auto parts = line.split("=");
ret ~= `string ` ~ parts[0] ~ ` = "` parts[2] `";`;
}
return ret;
}
You can also echo out the config file with bash or something
Cheers,
- Ali
Re: How to set constant value to environment variable at compile time?
On Mon, 10 Dec 2018 11:08:23 +, Narxa wrote: > Hello, people! > > I would like to have a constant with the value of some environment > variable that is defined at compile time. In your build script, echo the environment variable into a file. Then import() that file and use the value. > I know I could possibly use 'gdc' to achieve that but I want to use the > 'dmd' compiler. Defining variables like that is a language-level feature. gdc supports exactly the same options as dmd.
Re: cannot use local f as parameter to non-global template
On Monday, 10 December 2018 at 16:15:36 UTC, aliak wrote:
Ah, that's a good way of breaking it down. But ok, so then the
other version would be lowered to:
template match(handlers...) {
template match(T) {
auto match(T holder) {
return handlers[0](holder);
}
}
}
So now the second template is accessing a T, which is actually
a Holder!f right? But doing that makes it "work". Even though
the number of "contexts" needed to execute
"handlers[0](holder)" is the same, right?
Holder!f is a type, not a delegate, so passing it as a parameter
to a non-global template is fine. Issue 5710 only applies to
delegates passed directly as parameters.
Trying to reason about the "number of contexts" required is a
waste of time. There's no logical, principled reason why one
works and the other doesn't. It's purely an artifact of details
in the compiler implementation.
Re: cannot use local f as parameter to non-global template
On Saturday, 8 December 2018 at 14:21:01 UTC, Paul Backus wrote:
On Saturday, 8 December 2018 at 09:57:29 UTC, aliak wrote:
This compiles fine. However, if I change the match template to:
template match(handlers...) {
auto match(alias f)(Holder!f holder) {
return handlers[0](holder);
}
}
Notice the template parameter of the eponymous match is an
alias now, and the function parameter is typed as a Holder.
The "de-sugared" version of your second `match` function looks
like this:
template match(handlers...) {
template match(alias f) {
auto match(Holder!f holder) {
return handlers[0](holder);
}
}
}
Notice the second template nested inside the first. That's the
"non-gloal template" the error is complaining about.
Ah, that's a good way of breaking it down. But ok, so then the
other version would be lowered to:
template match(handlers...) {
template match(T) {
auto match(T holder) {
return handlers[0](holder);
}
}
}
So now the second template is accessing a T, which is actually a
Holder!f right? But doing that makes it "work". Even though the
number of "contexts" needed to execute "handlers[0](holder)" is
the same, right?
Re: How may I tell dub where to find a C library for linking?
On Monday, 10 December 2018 at 15:38:24 UTC, Pab De Nápoli wrote: 1) Setting the LD_LIBRARY_PATH environment variable with export LD_LIBRARY_PATH=/usr/lib/llvm-6.0/lib/ and using "libs" : ["LLVM-6.0"] in dub.json. (this is somewhat nasty, it would be nice to keep all the information together in dub.json) Moreover, the information about the path for linking with LLVM can be obtained from the shell script llvconfig as $llvm-config-6.0 --libs --ldflags -L/usr/lib/llvm-6.0/lib -lLLVM-6.0 If you do want to put it in the dub config, the -L option, and any linker options, can go in the "lflags" directive. "libs" is for libraries only. "lflags": ["-L/usr/lib/llvm-6.0/lib"], "libs": ["LLVM-6.0"]
Re: How may I tell dub where to find a C library for linking?
On Monday, 10 December 2018 at 05:24:16 UTC, evilrat wrote: On Monday, 10 December 2018 at 02:59:21 UTC, Pablo De Nápoli wrote: On my system (Debian GNU/Linux 9, 64 bits) the library is in the directory /usr/lib/llvm-6.0/lib/ $ ls -l /usr/lib/llvm-6.0/lib/libLLVM.so lrwxrwxrwx 1 root root 14 oct 24 19:44 /usr/lib/llvm-6.0/lib/libLLVM.so -> libLLVM-6.0.so But how am I supposed to tell dub this, so it passes this information to the linker?? I guess I should set "libs" in dubs.json IIRC your guess is correct. "libs" is passed directly to linker and is the only way to do it, so you just do smth like this "libs" : ["-L/usr/lib/llvm-6.0/lib/", "libLLVM-6.0"] note that this -L will be extended for linker as -L-L... (also note that you can do platform specific way with "libs-windows", "libs-posix"? to pick proper paths per platform) Though I'm not a linux pro and don't remember if linking to .so is same as linking import library, if this is not the case you just need to set RPATH or whatever it is so it can find dynamic lib. Many thanks but that didn't work,as I got the message $ dub build Performing "debug" build using /usr/bin/dmd for x86_64. llvm-d 2.4.1: target for configuration "native-target" is up to date. fibonacci ~master: building configuration "link-single"... Linking... /usr/bin/ld: cannot find -l-L/usr/lib/llvm-6.0/lib/ /usr/bin/ld: cannot find -llibLLVM-6.0 collect2: error: ld returned 1 exit status Error: linker exited with status 1 /usr/bin/dmd failed with exit code 1. The problem is that GNU ld expects the -L for specifying the search path, not -l What actually did work was: 1) Setting the LD_LIBRARY_PATH environment variable with export LD_LIBRARY_PATH=/usr/lib/llvm-6.0/lib/ and using "libs" : ["LLVM-6.0"] in dub.json. (this is somewhat nasty, it would be nice to keep all the information together in dub.json) Moreover, the information about the path for linking with LLVM can be obtained from the shell script llvconfig as $llvm-config-6.0 --libs --ldflags -L/usr/lib/llvm-6.0/lib -lLLVM-6.0 It would be better not to hard-code this information in dub.json but I don't know if it possible to invoke a shell script with something like $(llvm-config-6.0 --libs --ldflags) (as you would do in a Makefile) This method used to be employed by many other libraries besides llvm (but many are migrating to pkgconfig). Many thanks!)
Re: Calling function explicitly from mixin template results in recursive call instead
On Sunday, 9 December 2018 at 18:36:50 UTC, Dennis wrote: Does anyone know how to get this working? I added this to the mixin template: ``` alias mixinOpBinary = opBinary; ``` And called mixinOpBinary instead in the forwarded function. I think that solved it. I think I'll just file an issue for this.
How to set constant value to environment variable at compile time?
Hello, people!
I would like to have a constant with the value of some
environment variable that is defined at compile time.
In FreePascal, it can be done by defining it in source as:
VALUE_OF_SOMETHING = {$I %SOMETHING%};
And I can call the compiler with (bash):
SOMETHING='Anything' export SOMETHING;
And it will automatically assign VALUE_OF_SOMETHING to 'Anything'.
In GCC C compiler, the solution I found was more complicated but
it worked.
I had to explicitly define the environment variable when calling
the compiler with:
gcc -DSOMETHING=\""Anything"\" -o
Now, I would like to do that with the 'dmd' compiler.
I know I could possibly use 'gdc' to achieve that but I want to
use the 'dmd' compiler.
Is it possible to do that such a thing or through source or any
other means?
Thank you!
Re: Library settings, best practices?
On Saturday, 8 December 2018 at 17:05:50 UTC, Adam D. Ruppe wrote: Alternatively, you could perhaps have it keep an internal is_initialized flag and lazily call init on your other function calls if it is not already done. Then if the user wants to customize settings, they just call init before calling anything else, and if not they skip the init call and it gets default setup first time they try to use it. I have not tried this approach before. This might be what I am looking for. Thanks :)
