Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 14:56:37 UTC, Andrey Zherikov wrote:
Even without static if I get the same result:
mixin template my_import(alias modName)
{
mixin("import " ~ modName ~ ";");
}
mixin my_import!"mymod";
pragma(msg,fullyQualifiedName!(myfunc)); // Error:
undefined identifier myfunc
pragma(msg,fullyQualifiedName!(mymod.myfunc)); // mymod.myfunc
If I understood template mixin doc correctly this happens
because of "The declarations in a mixin are placed in a nested
scope". So is there a way to make two use cases above to work
the same way, i.e. "myfunc" to be available without "mymod."
prefix?
Exactly. Because of scoping rules mixin templates are nearly
useless, there was a lot of frustration/criticism on them, but
this is by design - to not turn them in macro hell like in C.
My opinion is that if core team are so picky about explicitness
they should also provide a way to explicitly mix into the current
scope, but of course I'm just yet another stranger here.
So you can do string mixin instead, however it requires more
labor, and usually one has to keep in mind all intricacies of the
features used which quickly leads to complexity combinatory
explosion.
But whatever... With helper function above you can try this
@property string my_import(alias mod)()
{
return
"static if (__traits(compiles, isModuleAvailable!\"" ~ mod ~
"\"))" ~
"{" ~
" mixin(\"import \",\"" ~ mod ~ "\", \";\"); " ~
"}";
}
// should import into current scope
mixin(my_import!"std.string");
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 14:20:03 UTC, Ali Çehreli wrote: On 07/25/2019 05:46 AM, Oleg B wrote: On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole wrote: Those restrictions don't stop at runtime. It's vary sad. What reason for such restrictions? It's fundamental idea or temporary implementation? It looks like a bug to me. Ali If the spec is to be believed then it is. I filed a bugzilla, https://issues.dlang.org/show_bug.cgi?id=20086
Re: Is betterC affect to compile time?
On Thursday, July 25, 2019 6:13:38 PM MDT Mike Franklin via Digitalmars-d- learn wrote: > On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote: > > There's probably at least one bug report on it, but as I > > understand it, it's not a bug in the sense that the > > implementation is currently expected to handle such a case. > > It's an area where betterC should be improved upon, but it > > would be an enhancement, not a bug fix. > > Yes. The point is that libraries have to be written with betterC > and compile-time evaluation in mind. If they aren't the code is > likely not going to work in those use cases. Much of the code in > Phobos was written long before betterC was introduced. > > There are probably changes that could be made to Phobos so the OP > could get a build, but that requires someone with enough interest > in the issue to volunteer their time and talent to improve the > implementation for betterC and compile-time use cases. > > We have a GSoC student making changes the druntime to help with > this matter and I have been picking away at it too. It will take > time and could use more contributors. I honestly don't see why how the library works should matter for CTFE so long as it's CTFE-able. format creates a string, and mixin then mixes in that string as code. None of that should have any effect on the generated code or what happens at runtime beyond the code that's mixed in. Sure, whether a library can be used with betterC at runtime depends on how the library was implemented, but runtime is a completely different beast from compile time. IMHO, the fact that you can't use format to create a compile-time construct with betterC is purely a problem with dmd's current implementation. - Jonathan M Davis
cannot use local __lambda1 as parameter to non-global template
Can someone help me understand the details around why this fails?
import std;
struct W(T) {
T value;
auto hook(handlers...)() {
return handlers[0](value);
}
}
template f(handlers...) {
auto ref f(T)(auto ref T value) {
return value.hook!handlers;
}
}
@nogc void main() {
auto a = W!int(3);
auto b = a.f!((_) => "yes");
}
If I specifically type the lambda I pass in to f (i.e. (int _) =>
"yes") then it works. Or if I make hook a global template that
takes a W!T as the first parameter it also works. Is there a work
around for this?
Re: cannot use local __lambda1 as parameter to non-global template
On Friday, 26 July 2019 at 16:20:10 UTC, aliak wrote:
Can someone help me understand the details around why this
fails?
import std;
struct W(T) {
T value;
auto hook(handlers...)() {
return handlers[0](value);
}
}
template f(handlers...) {
auto ref f(T)(auto ref T value) {
return value.hook!handlers;
}
}
@nogc void main() {
auto a = W!int(3);
auto b = a.f!((_) => "yes");
}
If I specifically type the lambda I pass in to f (i.e. (int _)
=> "yes") then it works. Or if I make hook a global template
that takes a W!T as the first parameter it also works. Is there
a work around for this?
Err sorry, that was ldc pre the 5710 bug fix. In DMD I get this:
Error: @nogc function D main cannot call non-@nogc function
onlineapp.main.f!(W!int).f
I guess it's allocating a delegate somewhere. Can I fix that?
Re: cannot use local __lambda1 as parameter to non-global template
On Friday, 26 July 2019 at 16:21:52 UTC, aliak wrote:
On Friday, 26 July 2019 at 16:20:10 UTC, aliak wrote:
Can someone help me understand the details around why this
fails?
import std;
struct W(T) {
T value;
auto hook(handlers...)() {
return handlers[0](value);
}
}
template f(handlers...) {
auto ref f(T)(auto ref T value) {
return value.hook!handlers;
}
}
@nogc void main() {
auto a = W!int(3);
auto b = a.f!((_) => "yes");
}
If I specifically type the lambda I pass in to f (i.e. (int _)
=> "yes") then it works. Or if I make hook a global template
that takes a W!T as the first parameter it also works. Is
there a work around for this?
Err sorry, that was ldc pre the 5710 bug fix. In DMD I get this:
Error: @nogc function D main cannot call non-@nogc function
onlineapp.main.f!(W!int).f
I guess it's allocating a delegate somewhere. Can I fix that?
I can do this but ugh:
import std;
struct W(T) {
T value;
static auto hook(handlers...)(auto ref typeof(this) self) {
return handlers[0](self.value);
}
}
template f(handlers...) {
auto ref f(T)(auto ref T value) {
return value.hook!handlers(value);
}
}
@nogc void main() {
auto a = W!int(3);
auto b = a.f!((_) => "yes");
}
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 03:42:58 UTC, Andrey Zherikov wrote:
Is there a way to check whether some module, say "foo", is
available for import before doing "import foo"?
static if (is(typeof((){import that.module.here;}))) {
// it is available
}
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 14:19:05 UTC, Paul Backus wrote: version(HasStdio) import std.stdio; else pragma(msg, "std.stdio is not available"); Then configure your build system to pass `-version=HasStdio` to dmd (or the equivalent flag to ldc or gdc) when std.stdio is available. I want to achieve similar result without versions.
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 14:14:11 UTC, Anonymouse wrote: I use __traits(compiles, __traits(identifier, moduleName)) now instead and it seems to work. I couldn't find "identifier" docs on https://dlang.org/phobos/std_traits.html. But I tried and it doesn't work - I think because is unknown identifier until "import " is happened.
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 06:24:18 UTC, evilrat wrote:
On Friday, 26 July 2019 at 03:42:58 UTC, Andrey Zherikov wrote:
Is there a way to check whether some module, say "foo", is
available for import before doing "import foo"?
I did some really retarded utility like this in the past,
worked for me, but I can't say it is that well tested and there
might be a better way (after all it just assumes that template
instantiation failure can only mean there is no such module),
so in short template allowed to fail, and we check if it is
failed or not to test if desired module exists. Don't remember
if static is really necessary or you can just return directly.
bool isModuleAvailable(alias modName)() {
mixin("import " ~ modName ~ ";");
static if (__traits(compiles, mixin(modName).stringof))
return true;
else
return false;
}
// use like this
static if (__traits(compiles, isModuleAvailable!"mymod" ))
import mymod;
This works, thanks!
But when I try to wrap usage as a single call to something I get
slightly different result of import:
// mymod.d
module mymod;
void myfunc() { import std.stdio; writeln("myfunc"); }
// use1.d
static if (__traits(compiles, isModuleAvailable!"mymod" )) import
mymod;
pragma(msg,fullyQualifiedName!(myfunc)); // mymod.myfunc
pragma(msg,fullyQualifiedName!(mymod.myfunc)); // mymod.myfunc
// use2.d
mixin template my_import(alias modName)
{
static if (__traits(compiles, isModuleAvailable!modName ))
mixin("import " ~ modName ~ ";");
}
mixin my_import!"mymod";
pragma(msg,fullyQualifiedName!(myfunc)); // Error:
undefined identifier myfunc
pragma(msg,fullyQualifiedName!(mymod.myfunc)); // mymod.myfunc
Even without static if I get the same result:
mixin template my_import(alias modName)
{
mixin("import " ~ modName ~ ";");
}
mixin my_import!"mymod";
pragma(msg,fullyQualifiedName!(myfunc)); // Error:
undefined identifier myfunc
pragma(msg,fullyQualifiedName!(mymod.myfunc)); // mymod.myfunc
If I understood template mixin doc correctly this happens because
of "The declarations in a mixin are placed in a nested scope". So
is there a way to make two use cases above to work the same way,
i.e. "myfunc" to be available without "mymod." prefix?
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 03:42:58 UTC, Andrey Zherikov wrote:
Is there a way to check whether some module, say "foo", is
available for import before doing "import foo"?
I want to create a function that imports module if it's
available or does something else otherwise. So I think the code
should look something like this:
mixin template my_import(alias module_name)
{
if(module_name is available)
mixin("import "~module_name~";");
else
pragma(msg, module_name~" is not available");
}
mixin my_import!("std.stdio"); // == import std.stdio
mixin my_import!("unknown_module"); // == pragma(msg,
"unknown_module is not available")
version(HasStdio)
import std.stdio;
else
pragma(msg, "std.stdio is not available");
Then configure your build system to pass `-version=HasStdio` to
dmd (or the equivalent flag to ldc or gdc) when std.stdio is
available.
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 06:24:18 UTC, evilrat wrote:
On Friday, 26 July 2019 at 03:42:58 UTC, Andrey Zherikov wrote:
bool isModuleAvailable(alias modName)() {
mixin("import " ~ modName ~ ";");
static if (__traits(compiles, mixin(modName).stringof))
return true;
else
return false;
}
// use like this
static if (__traits(compiles, isModuleAvailable!"mymod" ))
import mymod;
I forgot the exact details but I ran into troubles with this
where __traits(compiles, moduleName) would evaluate to false even
if the module was available, if there were top-level errors in it.
I use __traits(compiles, __traits(identifier, moduleName)) now
instead and it seems to work.
Blog Post #0056: MVC IX - A ComboBox with Flair
Today we get to do something unusual. Drawing on and combining a bunch of things we've done in past instalments, we'll build a two-column ComboBox with different images, custom fonts, and background colors for each item in the list. Here's the post: http://gtkdcoding.com/2019/07/26/0056-mvc-ix-a-combobox-with-flair.html
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote: What reason for such restrictions? It's fundamental idea or temporary implementation? I think it's a dmd limitation. Currently it has a bug that it can still generate code for ctfe templated functions, and they will fail to link if they use runtime. So yeah, currently betterC really means betterC all the way down. The alternative is to compile without -betterC switch and just use a minimal runtime if you use runtime features, then you have full language in ctfe.
Re: How to check that import module will succeed?
On Friday, 26 July 2019 at 03:42:58 UTC, Andrey Zherikov wrote:
Is there a way to check whether some module, say "foo", is
available for import before doing "import foo"?
I did some really retarded utility like this in the past, worked
for me, but I can't say it is that well tested and there might be
a better way (after all it just assumes that template
instantiation failure can only mean there is no such module), so
in short template allowed to fail, and we check if it is failed
or not to test if desired module exists. Don't remember if static
is really necessary or you can just return directly.
bool isModuleAvailable(alias modName)() {
mixin("import " ~ modName ~ ";");
static if (__traits(compiles, mixin(modName).stringof))
return true;
else
return false;
}
// use like this
static if (__traits(compiles, isModuleAvailable!"mymod" ))
import mymod;
