[Issue 19137] New: D_BoundsChecks / D_NoBoundsChecks does not support -boundschecks=safeonly
https://issues.dlang.org/show_bug.cgi?id=19137 Issue ID: 19137 Summary: D_BoundsChecks / D_NoBoundsChecks does not support -boundschecks=safeonly Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pro.mathias.l...@gmail.com When a program is compiled with `-boundschecks=safeonly`, `D_NoBoundsChecks` is *not* defined, but bounds check is turned off in non-safe code, which might break some assumption, e.g. in `@trusted` code. --
Re: skinny delegates
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer
wrote:
Would it be a valid optimization to have D remove the
requirement for allocation when it can determine that the
entire data structure of the item in question is an rvalue, and
would fit into the data pointer part of the delegate?
Here's what I'm looking at:
auto foo(int x)
{
return { return x + 10; };
}
This is something I've been wanting for a long time as well. It
was also implemented in Ocean (
https://github.com/sociomantic-tsunami/ocean/blob/e53ac93fbf3bfa9b2dceec1a2b6dc4a0ec7f78b2/src/ocean/core/TypeConvert.d#L249-L311 ).
AFAIK it should be possible, although not trivial to do.
[Issue 19136] is expressions don't work as documented
https://issues.dlang.org/show_bug.cgi?id=19136 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 03/08/2018 9:12 AM, Walter Bright wrote: On 8/2/2018 2:05 AM, rikki cattermole wrote: 8. if any identifier starts with a keyword and ends with at minimum one _, one _ from the end of the identifier will be removed for mangling (but not e.g. lookup). This will break existing code. A double underscore prefix is reserved for the implementation, which is why I went down that path. Because it will affect mangling only, do we have any examples of c/c++ code that appends _'s to it that is used by the D community?
[Issue 19134] [C++] static const y = new Derived(); ->pointer cast from const(Derived) to immutable(void*)** is not supported at compile time
https://issues.dlang.org/show_bug.cgi?id=19134 --- Comment #3 from ki...@gmx.net --- https://github.com/dlang/dmd/pull/8533 --
New edition of "The D Programming Language"?
Hi, Will there be a new edition of Andrei A's "The D Programming Language" (2010)? If so when will it be published? Thanks!
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright
wrote:
An example of silent hijacking:
extern (C++, "ab") void foo(long); // original code
... lots of code ...
extern (C++, "cd") void foo(int); // added later by
intern, should have been
// placed in another
module
... a thousand lines later ...
foo(0); // OOPS! now calling cd.foo() rather than
ab.foo(), D sux
You might say "nobody would ever write code like that." But
that's like the C folks saying real C programmers won't write:
You can do that today, just remove the "extern(C++, ...)" part
and you have the same issue. Why should C++ with namespaces be
safer than just regular D ? I don't understand, if it is such
a huge gigantic problem why didn't you do anything to solve
this problem in regards to D then ?
The difference is those names are supposedly in different
namespaces, given that the code is converted from C++:
namespace ab { void foo(long); }
... lots of code ...
namespace cd { void foo(int); }
where the foo()'s do not conflict with each other, and a user
would reasonably expect that same behavior when translated to D.
If you *want* them in the same scope in D, you can do that with
alias.
You can say the same thing in D. If you have "module ab" and
"module cd", if you put the function in the wrong file, you will
face this same bug. It's not a hypothetical, it's the current
implementation in D, yet no one has complained or filed a bug
report about it.
The bug is caused by the implicit conversion from int to long.
That is not, nor should it be, the purpose of C++ namespaces in D
to fix.
[Issue 16479] Missing substitution while mangling C++ template parameter for functions
https://issues.dlang.org/show_bug.cgi?id=16479 --- Comment #6 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/beb2a889124e53a6a6cc5218ffc596177b157086 Correct definition of foo15372 in cppa.d In the C++ file it is defined as `template int foo15372(int)`, but in the D file the argument was the template type. As template arguments are substituted in mangling, this was not correct and only compiled thanks to bug 16479 --
Re: skinny delegates
On Thursday, 2 August 2018 at 21:28:27 UTC, kinke wrote: Leaking may be an issue. Ah, I guess that's why you mentioned the use-as-rvalue requirement.
Re: skinny delegates
Leaking may be an issue. This currently works:
```
static const(int)* global;
auto foo(const int param)
{
return { global = return param + 10; };
}
void main()
{
{
int arg = 42;
auto dg = foo(42);
auto r = dg();
assert(r == 52);
}
assert(*global == 42);
}
```
`global` would be dangling as soon as the delegate `dg` goes out
of scope.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/2/2018 9:58 AM, Manu wrote: Have you ever tried the alias method I proposed? Of course, it's the only tool we have here, and a major source of my frustration! Why is it frustrating?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/2/2018 2:05 AM, rikki cattermole wrote: 8. if any identifier starts with a keyword and ends with at minimum one _, one _ from the end of the identifier will be removed for mangling (but not e.g. lookup). This will break existing code. A double underscore prefix is reserved for the implementation, which is why I went down that path.
Re: What does std.traits.hasAliasing do
On 7/28/18 9:21 PM, Venkat wrote:
On Sunday, 29 July 2018 at 01:05:19 UTC, Venkat wrote:
struct SomeStruct {
string p;
string q;
string[] pq;
}
Session session = req.session;
session.get!SomeStruct("registerBody");
/home/venkat/.dub/packages/vibe-d-0.8.4/vibe-d/http/vibe/http/session.d(83,3):
Error: static assert: "Type SomeStruct contains references, which is
not supported for session storage."
What is happening is the session storage is complaining it can't store
the array. I think because the array data could change without the
struct itself changing.
Even though string has a pointer, the data is immutable, so it is allowed.
vibe.d session won't let me put in a simple struct with an array or an
associative array. session.put calls std.traits.hasAliasing which is
returning true when I have either an array or an associative array. I
looked through the std.traits.hasAliasing code. I can't make a whole
lot of sense there.
The hasAliasing function documentation says as long as the array or
associative array are not immutable it should return true. Since
session.put does !hasAliasing I changed string[] to immutable, that
throws a whole lot of other compilation error messages.
What is hasAliasing doing ?
hasAliasing means there are references to mutable data somewhere in your
struct. In this case, the array pq is a reference to mutable data (yes,
the strings inside are immutable, but they can be changed).
The qualifications are listed here:
https://dlang.org/library/std/traits/has_aliasing.html
"an array U[] and U is not immutable"
Try immutable(string)[] pq.
-Steve
Re: Why does templated interface function return something different than final function?
On 7/18/18 7:09 AM, Timoses wrote:
Why is the interface templated function not also returning the class C
toString return value "in C"??
interface iface
{
void toString(scope void delegate(const(char)[]) sink) const;
final string convert() inout
{
import std.conv;
// assert(std.conv.to!string(this) == "in C"); // fails!
return std.conv.to!string(this);
}
final string convert2() const
{
import std.conv;
assert(std.conv.to!string(this) == "in C");
return std.conv.to!string(this);
}
}
class C : iface
{
void toString(scope void delegate(const(char)[]) sink) const
{
sink("in C");
}
}
void main ()
{
iface i = new C();
import std.stdio;
writeln(i.convert); // "app.C"
writeln(i.convert2()); // "in C"
}
It seems like `inout` triggers some odd behaviour??
Looking at the AST, it appears that toImpl doesn't recognize what
inout(iface) is:
toImpl!(string, inout(iface))
{
@system string toImpl(ref inout(iface) value)
{
import std.array : appender;
import std.format : FormatSpec, formatValue;
Appender!string w = appender();
FormatSpec!char f = FormatSpec;
formatValue(w, value, f);
return w.data();
}
}
Vs. the nice neat call for const(iface)
toImpl!(string, const(iface))
{
@system string toImpl(const(iface) value)
{
return toStr(value);
}
}
Note the ref there, too. This means it can't cast to const. I wonder if
that's an issue.
-Steve
Re: Will the PhotoObject DIP depercated the old Object class?
On 7/24/18 5:50 PM, Jonathan M Davis wrote: On Tuesday, July 24, 2018 20:25:33 12345swordy via Digitalmars-d wrote: I am asking this, because if true then the DIP that I am currently working on has been render obsolete as I have taken the old Object class into account when writing this. It is not the plan to deprecate Object (nice as that would be), but if you're writing a DIP that specifically targets Object, then you may want to rethink it. It will continue to exist, but it's likely that its use will be discouraged, and regardless, whatever you're proposing will have to take into account that many classes will have nothing to do with Object (though that's actually already possible thanks to extern(C++)). Well, I would expect that it's possible at some point to deprecate the *default* base being Object. that is, currently you do not have to type your class as: class C : Object But you would have to type your ProtoObject based class as: class C : ProtoObject We could easily deprecate the default (require people to specify the base), and then at some point remove the requirement for ProtoObject. But I wouldn't expect it to happen for years. Probably after much frustration of having to remember the ProtoObject base specification. -Steve
Re: skinny delegates
On 8/2/18 3:57 PM, kinke wrote:
On Thursday, 2 August 2018 at 15:12:10 UTC, Steven Schveighoffer wrote:
On 8/2/18 11:00 AM, Kagamin wrote:
I suppose it's mostly for mutability, so if it's const, it can be
optimized based on type information only:
auto foo(in int x)
{
return { return x + 10; };
}
I'm not sure what you mean here.
I think he's saying that the check for immutability could simply consist
in checking that all captured variables (well, not too much room for a
lot of them ;)) have a const type.
OK, yes, that's what I was thinking as well. On a 64-bit system, you
could stuff 2 ints in there, which is a common theme for my code :)
It's definitely an interesting idea, and the obvious benefit over a
library solution is that you wouldn't have to think about this
optimization when writing a delegate; if the captured stuff happens to
be const and fit into a pointer, the GC won't be bothered, nice.
Yeah, a library solution is opt-in, whereas if the compiler does it as
an optimization, it's seamless (mostly invisible). And works in @nogc
when possible.
-Steve
Re: skinny delegates
On Thursday, 2 August 2018 at 15:12:10 UTC, Steven Schveighoffer
wrote:
On 8/2/18 11:00 AM, Kagamin wrote:
I suppose it's mostly for mutability, so if it's const, it can
be optimized based on type information only:
auto foo(in int x)
{
return { return x + 10; };
}
I'm not sure what you mean here.
I think he's saying that the check for immutability could simply
consist in checking that all captured variables (well, not too
much room for a lot of them ;)) have a const type.
It's definitely an interesting idea, and the obvious benefit over
a library solution is that you wouldn't have to think about this
optimization when writing a delegate; if the captured stuff
happens to be const and fit into a pointer, the GC won't be
bothered, nice.
[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.
https://issues.dlang.org/show_bug.cgi?id=18472
--- Comment #13 from Mike Franklin ---
(In reply to Mike Franklin from comment #12)
> This appears to work now in nightly:
>
> import std.format;
> import std.stdio;
> void main()
> {
> enum s = "%1$s,%2$s".format("foo","bar");
> writeln(s);
> }
>
> https://run.dlang.io/is/BDyoHF
>
> It may have been fixed inadvertently by
> https://github.com/dlang/dmd/pull/8523
Gah, scratch that. Forgot to add the -betterC flag. :-(
--
[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.
https://issues.dlang.org/show_bug.cgi?id=18472
--- Comment #12 from Mike Franklin ---
This appears to work now in nightly:
import std.format;
import std.stdio;
void main()
{
enum s = "%1$s,%2$s".format("foo","bar");
writeln(s);
}
https://run.dlang.io/is/BDyoHF
It may have been fixed inadvertently by https://github.com/dlang/dmd/pull/8523
--
Re: skinny delegates
On 8/2/18 12:21 PM, Jonathan Marler wrote:
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote:
Would it be a valid optimization to have D remove the requirement for
allocation when it can determine that the entire data structure of the
item in question is an rvalue, and would fit into the data pointer
part of the delegate?
Here's what I'm looking at:
auto foo(int x)
{
return { return x + 10; };
}
In this case, D allocates a pointer on the heap to hold "x", and then
return a delegate which uses the pointer to read x, and then return
that plus 10.
However, we could store x itself in the storage of the pointer of the
delegate. This removes an indirection, and also saves the heap
allocation.
Think of it like "automatic functors".
Does it make sense? Would it be feasible for the language to do this?
The type system already casts the delegate pointer to a void *, so it
can't make any assumptions, but this is a slight break of the type
system.
The two requirements I can think of are:
1. The data in question must fit into a word
2. It must be guaranteed that the data is not going to be mutated
(either via the function or any other function). Maybe it's best to
require the state to be const/immutable.
I've had several cases where I was tempted to not use delegates
because of the allocation cost, and simply return a specialized
struct, but it's so annoying to do this compared to making a delegate.
Plus something like this would be seamless with normal delegates as
well (in case you do need a real delegate).
I think the number of cases where you could optimize this is very
small. And the complexity of getting the compiler to analyze cases to
determine when this is possible would be very large.
It's not that complicated, you just have to analyze how much data is
needed from the context inside the delegate. First iteration, all of the
data has to be immutable, so it should be relatively straightforward.
In addition, a developer can already do this explicitly if they want, i.e.
auto foo(int x)
{
static struct DummyStructToMakeFunctionWithDelegateAbi
{
int passthru() const { return cast(int) }
}
DummyStructToMakeFunctionWithDelegateAbi dummyStruct;
auto dg =
dg.ptr = cast(void*)(x + 10); // treat the void* pointer as an int
value
return dg;
}
Yep, just make that dummyStruct static or else it will allocate, and it
should work. The concern I have with doing it this way is all the
breakage of the type system.
-Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Thu, 2 Aug 2018 at 02:05, Walter Bright via Digitalmars-d wrote: > > On 8/1/2018 11:08 PM, Manu wrote: > > We have demonstrated consistent ongoing issues and frustration for 6 > > years. > > Have you ever tried the alias method I proposed? Of course, it's the only tool we have here, and a major source of my frustration! Every time I type alias this way, I have thoughts that make baby Jesus cry.
Re: skinny delegates
On Thursday, 2 August 2018 at 16:21:58 UTC, Jonathan Marler wrote:
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer
wrote:
Would it be a valid optimization to have D remove the
requirement for allocation when it can determine that the
entire data structure of the item in question is an rvalue,
and would fit into the data pointer part of the delegate?
Here's what I'm looking at:
auto foo(int x)
{
return { return x + 10; };
}
In this case, D allocates a pointer on the heap to hold "x",
and then return a delegate which uses the pointer to read x,
and then return that plus 10.
However, we could store x itself in the storage of the pointer
of the delegate. This removes an indirection, and also saves
the heap allocation.
Think of it like "automatic functors".
Does it make sense? Would it be feasible for the language to
do this? The type system already casts the delegate pointer to
a void *, so it can't make any assumptions, but this is a
slight break of the type system.
The two requirements I can think of are:
1. The data in question must fit into a word
2. It must be guaranteed that the data is not going to be
mutated (either via the function or any other function). Maybe
it's best to require the state to be const/immutable.
I've had several cases where I was tempted to not use
delegates because of the allocation cost, and simply return a
specialized struct, but it's so annoying to do this compared
to making a delegate. Plus something like this would be
seamless with normal delegates as well (in case you do need a
real delegate).
-Steve
I think the number of cases where you could optimize this is
very small. And the complexity of getting the compiler to
analyze cases to determine when this is possible would be very
large.
In addition, a developer can already do this explicitly if they
want, i.e.
auto foo(int x)
{
static struct DummyStructToMakeFunctionWithDelegateAbi
{
int passthru() const { return cast(int) }
}
DummyStructToMakeFunctionWithDelegateAbi dummyStruct;
auto dg =
dg.ptr = cast(void*)(x + 10); // treat the void* pointer as
an int value
return dg;
}
void main(string[] args)
{
auto dg = foo(32);
import std.stdio;
writefln("dg() = %s", dg());
}
It's definitely ugly but it works. This will print the number
"42" as expected.
This would be a case where DIP1011 extern(delegate) would come
in handy :) i.e.
extern(delegate) int passthru(void* ptr) { return cast(int)ptr;
}
int delegate() foo2(int x)
{
return &(cast(void*)(x + 10)).passthru;
}
Actually, I'll do you one better. Here's a potential library
function for it. I'm calling these types of delegates "value
pointer delegates".
// Assume this is in a library somewhere
auto makeValuePtrDelegate(string valueName, string funcBody, T)(T
value)
{
static struct DummyStruct
{
auto method() const
{
mixin("auto " ~ valueName ~ " = cast(T)");
mixin (funcBody);
}
}
DummyStruct dummy;
auto dg =
dg.ptr = cast(void*)value;
return dg;
}
auto foo(int x)
{
return makeValuePtrDelegate!("val", q{ return val + 10; })(x);
}
void main(string[] args)
{
auto dg = foo(32);
import std.stdio;
writefln("dg() = %s", dg());
}
Re: skinny delegates
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer
wrote:
Would it be a valid optimization to have D remove the
requirement for allocation when it can determine that the
entire data structure of the item in question is an rvalue, and
would fit into the data pointer part of the delegate?
Here's what I'm looking at:
auto foo(int x)
{
return { return x + 10; };
}
In this case, D allocates a pointer on the heap to hold "x",
and then return a delegate which uses the pointer to read x,
and then return that plus 10.
However, we could store x itself in the storage of the pointer
of the delegate. This removes an indirection, and also saves
the heap allocation.
Think of it like "automatic functors".
Does it make sense? Would it be feasible for the language to do
this? The type system already casts the delegate pointer to a
void *, so it can't make any assumptions, but this is a slight
break of the type system.
The two requirements I can think of are:
1. The data in question must fit into a word
2. It must be guaranteed that the data is not going to be
mutated (either via the function or any other function). Maybe
it's best to require the state to be const/immutable.
I've had several cases where I was tempted to not use delegates
because of the allocation cost, and simply return a specialized
struct, but it's so annoying to do this compared to making a
delegate. Plus something like this would be seamless with
normal delegates as well (in case you do need a real delegate).
-Steve
I think the number of cases where you could optimize this is very
small. And the complexity of getting the compiler to analyze
cases to determine when this is possible would be very large.
In addition, a developer can already do this explicitly if they
want, i.e.
auto foo(int x)
{
static struct DummyStructToMakeFunctionWithDelegateAbi
{
int passthru() const { return cast(int) }
}
DummyStructToMakeFunctionWithDelegateAbi dummyStruct;
auto dg =
dg.ptr = cast(void*)(x + 10); // treat the void* pointer as
an int value
return dg;
}
void main(string[] args)
{
auto dg = foo(32);
import std.stdio;
writefln("dg() = %s", dg());
}
It's definitely ugly but it works. This will print the number
"42" as expected.
This would be a case where DIP1011 extern(delegate) would come in
handy :) i.e.
extern(delegate) int passthru(void* ptr) { return cast(int)ptr; }
int delegate() foo2(int x)
{
return &(cast(void*)(x + 10)).passthru;
}
[Issue 14770] std.process should use lightweight forks where available
https://issues.dlang.org/show_bug.cgi?id=14770 --- Comment #7 from Hiroki Noda --- (In reply to anonymous4 from comment #6) > Maybe have a branch for linux and call clone there, call posix_spawn or fork > for other systems. vfork looks scary and posix deprecated it. If we use clone(2), the stack of the child process is newly allocated and the stack of the parent process is not shared. It's preferred. Maybe I should add clone(2) to druntime before... https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9ff72da471a509a8c19791efe469f47fa6977410 --
Re: skinny delegates
On 8/2/18 11:00 AM, Kagamin wrote:
I suppose it's mostly for mutability, so if it's const, it can be
optimized based on type information only:
auto foo(in int x)
{
return { return x + 10; };
}
I'm not sure what you mean here.
-Steve
Re: skinny delegates
I suppose it's mostly for mutability, so if it's const, it can be
optimized based on type information only:
auto foo(in int x)
{
return { return x + 10; };
}
Re: Prime number
On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote: I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D you can cheat and download d_primes from dub :)
Re: Prime number
On Thursday, 2 August 2018 at 09:35:20 UTC, Cym13 wrote: On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote: I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D Denis' answer is good but I'd like to add that the idiomatic D solution is to use whatever tool is the most adequate to solve the issue. If two loops is more natural it wouldn't make much sense to force yourself to use range functions (even though I'd obviously understand that stand to learn to use them). Thanks, I like the idea of using helper function from algorithm module to do the magic instead of loops. I want to know How To optimize it to efficient. I will appreciate any help. I will also appreciate a link to a comprehensive tutorial on the algorithm module. The documentation did not give me all the help I needed
Re: Where is TypeInfo_Class.m_init set
On Thursday, 2 August 2018 at 10:54:17 UTC, kinke wrote: Those 4 bytes for the struct is trailing padding, so that the struct is 16 bytes large, a multiple of its 8-bytes alignment (due to the pointer). Classes on the other hand aren't padded (they don't need to be, as there are no contiguous arrays of class instances, just class references). In this case, you could use `align(1) struct BazInitializer` to prevent the struct tail padding. Oh yeah, forgot about alignment. It's no use though. Unless I can get my hands on the internal "struct" type of Baz somehow, LDC is not gonna let me declare it: https://github.com/ldc-developers/ldc/blob/69104bdbf94713431cbc67151c1b34a6a5e0df34/gen/llvmhelpers.cpp#L1759
Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On Tuesday, 31 July 2018 at 07:01:33 UTC, Simen Kjærås wrote:
On Monday, 30 July 2018 at 23:41:09 UTC, aliak wrote:
https://issues.dlang.org/show_bug.cgi?id=19130
Beautiful. :)
Would it take much to fix it up to use with templated
opAssigns as well?
I spent half an hour doing silly things, then I came up with
this:
struct A {
void opAssign(int) {}
void opAssign(float) {}
void opAssign(T)(T t) if (is(T == string)) {}
}
struct B {
A a;
alias a this;
@disable void opAssign(float);
mixin(wrap!(B, "opAssign"));
auto opAssign(T...)(T args)
if (__traits(compiles, a.opAssign(args)))
{
// Look ma, no magic!
return a.opAssign(args);
}
}
unittest {
B b;
b = "Foo!";
}
(Remaining code as in my last post)
Yeah, it really is that simple, since specific overloads are
tried before templates.
--
Simen
Oh nice! So you don't even need all that mixin magic and can get
away with:
struct A {
void opAssign(int) {}
@disable void opAssign(float) {}
void opAssign(T)(T t) if (is(T == string)) {}
}
struct B(T) {
A a;
alias a this;
@disable void opAssign(B!T);
mixin(wrap!(B, "opAssign"));
}
string wrap(T, string methodName)() {
enum targetName = __traits(getAliasThis, T)[0];
return `auto `~methodName~`(T...)(T args)
if (__traits(compiles,
`~targetName~`.`~methodName~`(args))) {
return `~targetName~`.`~methodName~`(args);
}`;
}
void main() {
B!int b;
b = 3;
b = "hello";
static assert(!__traits(compiles, { b = 3f; } ));
static assert(!__traits(compiles, { b = b; } ));
}
Re: Is there any hope for "lazy" and @nogc?
On Wednesday, 1 August 2018 at 20:32:11 UTC, Iain Buclaw wrote: On 1 August 2018 at 18:52, Shachar Shemesh via Digitalmars-d wrote: [...] My first thought was to have a look at enforce(), but on closer observation it is neither @nogc or nothrow. Maybe you should raise a bug report? It's certainly worth an attempt to bridge these two features together. I think it makes sense enough that lazy parameters should infer attributes from the function, and that it should be an error to pass a parameter that does not meet those constraints. i.e: --- // Signatures. void myAssert(bool cond, lazy string msg) @nogc nothrow; string mayAlloc() nothrow; string mayThrow() @nogc; // Code myAssert(cond, mayAlloc());// violates @nogc myAssert(cond, mayThrow());// violates nothrow --- Iain. Isn't this https://issues.dlang.org/show_bug.cgi?id=12647?
Re: skinny delegates
On 7/30/18 5:02 PM, Steven Schveighoffer wrote:
Does it make sense? Would it be feasible for the language to do this?
The type system already casts the delegate pointer to a void *, so it
can't make any assumptions, but this is a slight break of the type system.
One possibility to avoid typesystem breakage is to internally treat a
delegate structure like this:
struct Delegate(RT, PARAMS...)
{
RT function(PARAMS params) funcptr;
union
{
void *ptr;
immutable ubyte[(void*).sizeof] context;
}
}
Whereby the compiler is informed that the context could just be a bunch
of bytes.
-Steve
Re: skinny delegates
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Does it make sense? It is also nice for domains like embedded systems. It is common for embedded systems to only dynamically allocate during system initialization (depending on the application of course). Avoiding the allocation would make the pattern you describe available to systems that have this restriction, and it's always nice to remove such limitations. Mike
Re: skinny delegates
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: In this case, D allocates a pointer on the heap to hold "x", and then return a delegate which uses the pointer to read x, and then return that plus 10. Yeah, that seems like such a disproportionately heavy cost. Does it make sense? I haven't though through the details, but if it can be done, I think it would be nice. I like when programming tools are more intelligent about things like this because after you become familiar with it and build confidence in it, you can just code your ass off and know that the compiler is doing right on your behalf. Mike
Re: skinny delegates
On 8/2/18 9:21 AM, Stefan Koch wrote: On Thursday, 2 August 2018 at 12:57:02 UTC, Steven Schveighoffer wrote: On 8/2/18 8:42 AM, Stefan Koch wrote: On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the entire data structure of the item in question is an rvalue, and would fit into the data pointer part of the delegate? Don't do that. It's valid in simple cases. Those are the cases I'm referring to. I meant it seems valid in simple cases, and I doubt you can distinguish between cases that work and cases which don't work with 100% accuracy. When the data needed in the delegate is all effectively immutable (or maybe *actually* immutable), I can't see how using a pointer to it is different than using a copy of it. As soon as you want to chain delegate pointers it falls apart. And so, don't do the skinny delegate optimization in that case? Again the question is whether you can tell the cases apart with local information. This idea requires cooperation from the compiler, all the way down to code generation -- it's not really a lowering but a change in how the data is fetched from the context. At a minimum, I would say anything that only depends on immutables can be a valid use case. In order to prove effective immutability (anything that could possibly change elsewhere can't qualify for this), you would need a lot of local information. So maybe this only works if the type is actually immutable. Also the delegate might require heap allocation to be memory correct. Does the "might" depend on the caller or on the delegate implementation itself? The former would squash this idea. I am not sure about that, it's just a gut feeling that skinny delegates will be breaking some invariant, I may be wrong. Coming up with specific rules and throwing them at the wall until they don't break anymore, is fine for applications used in limited controlled circumstances, I would not want to do it with a compiler which is used by an unknown number of users. I wasn't planning on that method of proof. What I wanted to do was start with the tightest possible, but easily provable constraints -- all data must be immutable -- and then relax as it makes sense. What I don't know is the implications on the optimizer or semantic analysis -- does the context pointer being really a pointer have any affect on those pieces? I also don't know what you meant by "memory correct". -Steve
Re: How to force console
On Thursday, 2 August 2018 at 13:11:20 UTC, Everlast wrote: But, when I put this stuff in a static this in a windowsx64 dll, the static this is called about 100 times!!! Not once! try shared static this() instead of just static this() the latter is called once per thread, the former once per process. that might be the difference. maybe. 100 times still seems crazy.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Thursday, 2 August 2018 at 12:30:14 UTC, rikki cattermole wrote: On 03/08/2018 12:24 AM, Steven Schveighoffer wrote: I've never seen it, but it's certainly valid C++ and in the realm of possibility. -Steve I see, thanks. That's easy to solve. Split into a package, public import each file and alias if required to get each version. It's easy to work around and most importantly, reasonable. Agreed.
Re: skinny delegates
On Thursday, 2 August 2018 at 12:57:02 UTC, Steven Schveighoffer wrote: On 8/2/18 8:42 AM, Stefan Koch wrote: On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the entire data structure of the item in question is an rvalue, and would fit into the data pointer part of the delegate? Don't do that. It's valid in simple cases. Those are the cases I'm referring to. I meant it seems valid in simple cases, and I doubt you can distinguish between cases that work and cases which don't work with 100% accuracy. As soon as you want to chain delegate pointers it falls apart. And so, don't do the skinny delegate optimization in that case? Again the question is whether you can tell the cases apart with local information. Also the delegate might require heap allocation to be memory correct. Does the "might" depend on the caller or on the delegate implementation itself? The former would squash this idea. I am not sure about that, it's just a gut feeling that skinny delegates will be breaking some invariant, I may be wrong. Coming up with specific rules and throwing them at the wall until they don't break anymore, is fine for applications used in limited controlled circumstances, I would not want to do it with a compiler which is used by an unknown number of users.
Re: How to force console
On Thursday, 2 August 2018 at 13:02:21 UTC, Simen Kjærås wrote:
On Thursday, 2 August 2018 at 12:08:50 UTC, Everlast wrote:
On Thursday, 2 August 2018 at 03:20:30 UTC, Mike Parker wrote:
On Wednesday, 1 August 2018 at 20:57:30 UTC, Everlast wrote:
I can create a console for a dll using AllocConsole and
special Write functions but this is a pain. How do I get all
standard input and output to either use this console or for
the app to create the console automatically?
The problem I'm having is that I can write(using custom
write) but can't read. I'd rather just have a dll with a
normal console window like a normal program.
I do have `-L/SUBSYSTEM:CONSOLE`
but no console appears.
As far as I know, that only works with executables. Loading a
DLL does not trigger the opening of a console. You'll have to
stick with AllocConsole and redirect the I/O.
http://www.asawicki.info/news_1326_redirecting_standard_io_to_windows_console.html
Thanks, but does that work in D?
Error: cannot cast expression `*fp` of type `shared(_iobuf)`
to `File*`
I tried getting it to work, gave up, and found some example
code that I boiled down to this:
import std.stdio : writeln, stdout;
AllocConsole();
freopen("CON", "w", stdout.getFP);
writeln("OHAI!");
That works on my machine, but I haven't read enough to know why
it wouldn't fail on others.
--
Simen
Thanks, seems to work. I have to do input too, hopefully it is as
simple, as this seems to work:
freopen("CON", "r", stdin.getFP);
But, when I put this stuff in a static this in a windowsx64 dll,
the static this is called about 100 times!!! Not once!
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 12:06:16 UTC, Patrick Schluter wrote: On Thursday, 2 August 2018 at 10:31:02 UTC, aliak wrote: On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote: [...] Thanks! And yes, totally aware of that. I have tried to link to relevant forum posts and will try to add more as I go along to where the usages were concocted. So I guess those could be the motivations? But it'd also be nice to just use it for a while and get feedback and experience with the names/APIs/functionalities/etc before adding it to std.meta. Though being in std would be ideal of course. [...] Dammit! You're right! Thank you for pointing that out. Art! It's Art! ... or maybe i can use a hipster "is" ... i.e. "iz" :p ’tis like in "’Tis the season to be jolly." https://en.wiktionary.org/wiki/'tis Ok, Unicode (’ U+2019) in a symbol is not nice but works normally in D. :-) Hehe, I went with iz, and now the docs for iz reads: "Iz is is - reason for choosing iz is because is is a keyword" :-D Are you sure about being able to use U+2019? I get: Error: character 0x2019 is not a valid token
Re: How to force console
On Thursday, 2 August 2018 at 12:08:50 UTC, Everlast wrote:
On Thursday, 2 August 2018 at 03:20:30 UTC, Mike Parker wrote:
On Wednesday, 1 August 2018 at 20:57:30 UTC, Everlast wrote:
I can create a console for a dll using AllocConsole and
special Write functions but this is a pain. How do I get all
standard input and output to either use this console or for
the app to create the console automatically?
The problem I'm having is that I can write(using custom
write) but can't read. I'd rather just have a dll with a
normal console window like a normal program.
I do have `-L/SUBSYSTEM:CONSOLE`
but no console appears.
As far as I know, that only works with executables. Loading a
DLL does not trigger the opening of a console. You'll have to
stick with AllocConsole and redirect the I/O.
http://www.asawicki.info/news_1326_redirecting_standard_io_to_windows_console.html
Thanks, but does that work in D?
Error: cannot cast expression `*fp` of type `shared(_iobuf)` to
`File*`
I tried getting it to work, gave up, and found some example code
that I boiled down to this:
import std.stdio : writeln, stdout;
AllocConsole();
freopen("CON", "w", stdout.getFP);
writeln("OHAI!");
That works on my machine, but I haven't read enough to know why
it wouldn't fail on others.
--
Simen
Re: skinny delegates
On 8/2/18 8:42 AM, Stefan Koch wrote: On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the entire data structure of the item in question is an rvalue, and would fit into the data pointer part of the delegate? Don't do that. It's valid in simple cases. Those are the cases I'm referring to. As soon as you want to chain delegate pointers it falls apart. And so, don't do the skinny delegate optimization in that case? Also the delegate might require heap allocation to be memory correct. Does the "might" depend on the caller or on the delegate implementation itself? The former would squash this idea. -Steve
Re: skinny delegates
On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the entire data structure of the item in question is an rvalue, and would fit into the data pointer part of the delegate? Don't do that. It's valid in simple cases. As soon as you want to chain delegate pointers it falls apart. Also the delegate might require heap allocation to be memory correct.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 03/08/2018 12:24 AM, Steven Schveighoffer wrote: The example that Walter keeps bringing up is one where the C++ code has 2 namespaces in the same header file. Not only that, but then identically named functions in those namespaces. In that case, a direct translation would cause problems with hijacking in D, where it doesn't in C++ (as long as you don't ever use `using` declarations, or only use one or the other). So the difference from your example is that you're not trying to bind 2 different files with 2 different namespaces into one D module, but you are translating a single C++ header file that's written with the 2 bindings as described. Not std and boost, but ns1 and ns2 inside the same header file, which each have identical symbols. I've never seen it, but it's certainly valid C++ and in the realm of possibility. -Steve That's easy to solve. Split into a package, public import each file and alias if required to get each version. It's easy to work around and most importantly, reasonable.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/2/18 5:26 AM, Daniel N wrote: On Thursday, 2 August 2018 at 08:31:28 UTC, Walter Bright wrote: On 8/1/2018 10:06 PM, Johannes Pfau wrote: I guess that would be acceptable if there is a real benefit, but I have not seen a single argument for the current behavior in this thread. Please read my postings in this thread, then. I know you have been very patient with explaining this, but I've been trying to read all threads on this topic and I'm still not sure, can you please acknowledge if I understood you correctly or not? Let's use a simple pseudo example? Let's assume we have two different 'any' implementations... The current extern(c++) design allows us to bind to both of them in a single file. cpp_bindings.d extern(c++, std) ...any-definition... extern(c++, boost) ...any-definition... Personally I would never *bind* to two different namespaces in a single file, are there any other additional benefits to the current design which I'm overlooking? With a non-scoped extern(c++) we could simply use two files. cppstd/any.d extern(c++, std) ...any-definition... boost/any.d extern(c++, boost) ...any-definition... My conclusion is that _if_ I understood you correctly, it must mean that in the examples which you have in mind, it is common to *bind* to two namespaces in the same file? Could you give a real-world examples of two namespaces which you would like to mix like that in the same *bindings* file? Is it for instance 'std' and 'std::experimental'? The example that Walter keeps bringing up is one where the C++ code has 2 namespaces in the same header file. Not only that, but then identically named functions in those namespaces. In that case, a direct translation would cause problems with hijacking in D, where it doesn't in C++ (as long as you don't ever use `using` declarations, or only use one or the other). So the difference from your example is that you're not trying to bind 2 different files with 2 different namespaces into one D module, but you are translating a single C++ header file that's written with the 2 bindings as described. Not std and boost, but ns1 and ns2 inside the same header file, which each have identical symbols. I've never seen it, but it's certainly valid C++ and in the realm of possibility. -Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/18 7:04 PM, Walter Bright wrote: On 8/1/2018 10:24 AM, Jonathan M Davis wrote: Not to say that that can't work, but I have to say that it seems pretty ugly if using extern(C++, NS) requires a bunch of aliases just to use symbols normally. What is normal is a slippery concept, especially when one is comparing different lookup rules between languages. D modules do not a 1:1 correspondence with C++ namespaces, either (not even close). Aliases are a normal and highly useful D tool to copy names from one scope to another. Certainly, it does come across like you didn't trust the D module system to do its job for some reason. Reorganizing the code into modules means potentially forcing users to split code from one C++ file into multiple D files. How's that really going to work if you have a translation tool? One of the aspects of Java I didn't care for was forcing each class into its own file. So while Manu is clearly happy with cutting up a C++ file into multiple D files, I doubt that is universal. His proposal would pretty much require that for anyone trying to work with C++ namespaces who ever has a name collision/hijack or wants to make the code robust against collision/hijacking. An example of silent hijacking: extern (C++, "ab") void foo(long); // original code ... lots of code ... extern (C++, "cd") void foo(int); // added later by intern, should have been // placed in another module ... a thousand lines later ... foo(0); // OOPS! now calling cd.foo() rather than ab.foo(), D sux You might say "nobody would ever write code like that." But that's like the C folks saying real C programmers won't write: int a[10]; for (int i = 0; i <= 10; ++i) ...a[i]... But we both know they do just often enough for it to be a disaster. I challenge you to find any C++ code that has two identical function names in the same header file, but in different namespaces. I've done C++ development, but not really a C++ developer since about 2010 or so, but to me, this sounds like utter stupidity to do that. I think most of the issue with name conflict is between different *projects*, which is why you have a namespace to begin with. In other words, libfoo defines foo, and libbar defines foo (how dare they!) and now there is a conflict, but you can distinguish by using foo::foo, and bar::foo. But it would be no different in D, since they would be in different libraries anyway, not in the same module. I think comparing that to the <= problem is like apples and oranges. While the problem you identify *is* a problem, I believe it only exists on this thread, and not anywhere else. -Steve
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 10:31:02 UTC, aliak wrote: On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote: [...] Thanks! And yes, totally aware of that. I have tried to link to relevant forum posts and will try to add more as I go along to where the usages were concocted. So I guess those could be the motivations? But it'd also be nice to just use it for a while and get feedback and experience with the names/APIs/functionalities/etc before adding it to std.meta. Though being in std would be ideal of course. [...] Dammit! You're right! Thank you for pointing that out. Art! It's Art! ... or maybe i can use a hipster "is" ... i.e. "iz" :p ’tis like in "’Tis the season to be jolly." https://en.wiktionary.org/wiki/'tis Ok, Unicode (’ U+2019) in a symbol is not nice but works normally in D. :-)
Re: Dlang on OpenWrt
On Thursday, 2 August 2018 at 10:47:33 UTC, Ky-Anh Huynh wrote: Hi, can I build my program on OpenWrt? I haven't found any resources on internet maybe I'm missing something. Thanks a lot. LDC 1.10+ should have pretty good support for OpenWRT uClibc for ARM, and some support for uClibc MIPS. If you have the toolchain follow the cross-compile guidelines for LDC. I did those ports a while ago but haven't followed up for some time. I intend to write a report with what works and what doesn't.
Re: How to force console
On Thursday, 2 August 2018 at 03:20:30 UTC, Mike Parker wrote: On Wednesday, 1 August 2018 at 20:57:30 UTC, Everlast wrote: I can create a console for a dll using AllocConsole and special Write functions but this is a pain. How do I get all standard input and output to either use this console or for the app to create the console automatically? The problem I'm having is that I can write(using custom write) but can't read. I'd rather just have a dll with a normal console window like a normal program. I do have `-L/SUBSYSTEM:CONSOLE` but no console appears. As far as I know, that only works with executables. Loading a DLL does not trigger the opening of a console. You'll have to stick with AllocConsole and redirect the I/O. http://www.asawicki.info/news_1326_redirecting_standard_io_to_windows_console.html Thanks, but does that work in D? Error: cannot cast expression `*fp` of type `shared(_iobuf)` to `File*`
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote: On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote: [...] woops, pressed send too early: 2) I don't think "doth" is synonymous with "is" how you're using it. "doth" is for doing, e.g. "Methinks he doth protest too much" or "This code doth stink" is OK "Green doth a colour" or "strstr doth a function" is not OK. Isn't "doth" just an antiquated orthography of "does"?
[Issue 19136] New: is expressions don't work as documented
https://issues.dlang.org/show_bug.cgi?id=19136 Issue ID: 19136 Summary: is expressions don't work as documented Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com The docs say: is ( Type Identifier : TypeSpecialization ) The condition is satisfied if Type is the same as TypeSpecialization, or if Type is a class and TypeSpecialization is a base class or base interface of it. The Identifier is declared to be either an alias of the TypeSpecialization or, if TypeSpecialization is dependent on Identifier, the deduced type. So, if we have Type = int and TypeSpecialization = long, we would expect the result to be false, because int != long and neither are classes or interfaces. But the result is actually true. Furthermore, Indentifier is set to int, whereas the docs say that Identifier should be an alias of TypeSpecialization, long in this case. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
The difference is those names are supposedly in different
namespaces, given that the code is converted from C++:
namespace ab { void foo(long); }
... lots of code ...
namespace cd { void foo(int); }
where the foo()'s do not conflict with each other, and a user
would reasonably expect that same behavior when translated to D.
This is a trivial problem to solve.
mangle(C++, ab) { void foo(long); }
mangle(C++, cd) { void foo(int); }
It's certainly not obvious to me why anyone would do that, write
foo(3);
and then blame you when it doesn't work.
Re: Constructing a class in-place
On Thursday, 26 July 2018 at 12:45:52 UTC, Johan Engelen wrote: Thanks for pointing to D's placement new. This is bad news for my devirtualization work; before, I thought D is in a better situation than C++, but now it seems we may be worse off. Just say that devirtualization is incompatible with method-changing reemplace. I don't think this imposes notable portability restrictions.
Re: Is there any hope for "lazy" and @nogc?
On 8/1/18 10:14 PM, Shachar Shemesh wrote:
On 01/08/18 17:13, Steven Schveighoffer wrote:
The lazy variadic thing is a distinction between specifying variadic
lazy parameters and a lazy variadic array.
I have now read that sentence 4 times, and I still have no idea what it
means.
Can you give examples of both?
import std.stdio;
// lazy variadic array
void foo(lazy int[] arr...)
{
writeln(arr[0]);
writeln(arr[1]);
writeln(arr[2]);
}
// variadic lazy paramters
void bar(int delegate()[] items...)
{
writeln(items[0]());
writeln(items[1]());
writeln(items[2]());
}
int param(int x)
{
writeln("param ", x);
return x;
}
void main()
{
foo(param(0), param(1), param(2));
bar(param(0), param(1), param(2));
}
output:
param 0
param 1
param 2
0
param 0
param 1
param 2
1
param 0
param 1
param 2
2
param 0
0
param 1
1
param 2
2
So in the first case, the ENTIRE array is evaluated lazily, and then an
element selected. In the second case, each item is evaluated when used.
-Steve
Re: Dlang on OpenWrt
You could give LDC's armhf build a try. It's built on Debian Jessie and requires ARMv6 or newer, so it might work. Download: https://github.com/ldc-developers/ldc/releases
[Issue 19126] Compiler removes inout on templated parameter and then complains it's not there
https://issues.dlang.org/show_bug.cgi?id=19126 --- Comment #6 from anonymous4 --- Uh, no, it does. --
[Issue 19134] [C++] static const y = new Derived(); ->pointer cast from const(Derived) to immutable(void*)** is not supported at compile time
https://issues.dlang.org/show_bug.cgi?id=19134 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #2 from ki...@gmx.net --- See https://github.com/dlang/dmd/pull/8362#pullrequestreview-142565787. --
[Issue 19126] Compiler removes inout on templated parameter and then complains it's not there
https://issues.dlang.org/show_bug.cgi?id=19126 --- Comment #5 from anonymous4 --- (In reply to Steven Schveighoffer from comment #4) > Aye, the compiler is stripping inout from the type because it knows that > inout(immutable(T)) can be rewritten as immutable(T). Then wrap1 would suffer from it too, but it doesn't. --
Re: pointer cast from const(Y) to immutable(void*)** is not supported at compile time
On Thursday, 2 August 2018 at 02:13:41 UTC, Hakan Aras wrote: I do want it at compiletime though. Totally understandable; that's a regression and needs to be fixed. See https://github.com/dlang/dmd/pull/8362#pullrequestreview-142565787.
Re: Where is TypeInfo_Class.m_init set
On Thursday, 2 August 2018 at 02:52:44 UTC, Hakan Aras wrote:
LDC complains about the type of initializer though:
onlineapp.d(22): Error: Global variable type does not match
previous declaration with same mangled name:
_D5bclib3Baz6__initZ
onlineapp.d(22):Previous IR type: %bclib.Baz = type {
[1 x i8*]*, i32 }
onlineapp.d(22):New IR type: %bclib.BazInitializer
= type { [1 x i8*]*, i32, [4 x i8] }
Any ideas on how to match the type exactly? I don't quite
understand why there are 4 bytes at the back of BazInitializer.
Those 4 bytes for the struct is trailing padding, so that the
struct is 16 bytes large, a multiple of its 8-bytes alignment
(due to the pointer). Classes on the other hand aren't padded
(they don't need to be, as there are no contiguous arrays of
class instances, just class references).
In this case, you could use `align(1) struct BazInitializer` to
prevent the struct tail padding.
Dlang on OpenWrt
Hi, can I build my program on OpenWrt? I haven't found any resources on internet maybe I'm missing something. Thanks a lot.
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote: On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote: This looks cool. Lots of things that lots of people have reimplemented lots of times over the years, but all in one place and documented. 2 points: 1) Are you aware of this: https://github.com/dlang/phobos/blob/master/std/meta.d ? I think if a bunch of good motivating examples are given, making this public would be possible. Then everyone would be using the same one and your library would truly just be utilities. Thanks! And yes, totally aware of that. I have tried to link to relevant forum posts and will try to add more as I go along to where the usages were concocted. So I guess those could be the motivations? But it'd also be nice to just use it for a while and get feedback and experience with the names/APIs/functionalities/etc before adding it to std.meta. Though being in std would be ideal of course. woops, pressed send too early: 2) I don't think "doth" is synonymous with "is" how you're using it. "doth" is for doing, e.g. "Methinks he doth protest too much" or "This code doth stink" is OK "Green doth a colour" or "strstr doth a function" is not OK. Dammit! You're right! Thank you for pointing that out. Art! It's Art! ... or maybe i can use a hipster "is" ... i.e. "iz" :p Cheers, - Ali
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 01 Aug 2018 16:04:01 -0700, Walter Bright wrote: > On 8/1/2018 10:24 AM, Jonathan M Davis wrote: >> Not to say that that can't work, but I have to say that it seems pretty >> ugly if using extern(C++, NS) requires a bunch of aliases just to use >> symbols normally. > > What is normal is a slippery concept, especially when one is comparing > different lookup rules between languages. D modules do not a 1:1 > correspondence with C++ namespaces, either (not even close). Disclaimer: no knowledge or experience to back up my assumptions: This is the part of the discussion I don't understand. Why do we need to care about [all of the] C++ lookup rules? Even if the D compiler has to know about them, I'd think it's an implementation detail on the D side that wouldn't necessarily need to be passed to the user. If the goal is to link with C++ object files, the only thing that matters is what's available in those files, right? Anything to do with C++ rules that doesn't achieve this goal seems like it's just noise to me.
Re: Prime number
On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote: I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D Denis' answer is good but I'd like to add that the idiomatic D solution is to use whatever tool is the most adequate to solve the issue. If two loops is more natural it wouldn't make much sense to force yourself to use range functions (even though I'd obviously understand that stand to learn to use them).
Re: Prime number
On Thursday, 2 August 2018 at 08:30:05 UTC, Greatsam4sure wrote:
I know D is very powerful from my little experience. What is
the idiomatic way to get prime numbers say from 1-30 without
using loops(outer and inner loop). Can map, filter, fold etc in
algorithm be use. Pls show some code with chain call.
I can easily achieve even numberd and odd numbers using filter.
But prime numbers I have to use 2loops.
I will appreciate any help,just a newbie in D
If you just want a small number of prime numbers and your goal is
to make it a simple chain of range functions, I would do this:
```
import std.stdio: writeln;
import std.algorithm: filter, canFind;
import std.range: iota;
void main()
{
auto isPrime = (int number) => number >= 2 && !iota(2,
number).canFind!(x => (number % x) == 0);
writeln(iota(30).filter!isPrime);
}
```
You first make a simple prime filter, and then apply it to a
range of integers 0 to 30 using `iota(30)`.
I use lambda syntax for isPrime, but you can also make it an
explicit function:
```
bool isPrime(int number) {
return number >= 2 && !iota(2, number).canFind!(x => (number %
x) == 0);
}
```
`iota(2, number)` generates a range of integers from 2 to
`number` (excluding `number` itself), and with canFind we can see
if any of those divide our number. If so, then number isn't prime.
Note that if you're serious about calculating primes, you should
look for an efficient algorithm. Even in this naive algorithm
there are many optimization possibilities, like stopping the iota
at sqrt(number), but it would make the range code more
complicated.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Thursday, 2 August 2018 at 08:31:28 UTC, Walter Bright wrote: On 8/1/2018 10:06 PM, Johannes Pfau wrote: I guess that would be acceptable if there is a real benefit, but I have not seen a single argument for the current behavior in this thread. Please read my postings in this thread, then. I know you have been very patient with explaining this, but I've been trying to read all threads on this topic and I'm still not sure, can you please acknowledge if I understood you correctly or not? Let's use a simple pseudo example? Let's assume we have two different 'any' implementations... The current extern(c++) design allows us to bind to both of them in a single file. cpp_bindings.d extern(c++, std) ...any-definition... extern(c++, boost) ...any-definition... Personally I would never *bind* to two different namespaces in a single file, are there any other additional benefits to the current design which I'm overlooking? With a non-scoped extern(c++) we could simply use two files. cppstd/any.d extern(c++, std) ...any-definition... boost/any.d extern(c++, boost) ...any-definition... My conclusion is that _if_ I understood you correctly, it must mean that in the examples which you have in mind, it is common to *bind* to two namespaces in the same file? Could you give a real-world examples of two namespaces which you would like to mix like that in the same *bindings* file? Is it for instance 'std' and 'std::experimental'?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 02/08/2018 8:59 PM, Walter Bright wrote: If this problem were to be solved, it should be solved, not hacked for one case only. There are many ways of dealing with it: 1. pragma(mangle) 2. change the names in the C/C++ side 3. use a macro -Dwith=with_ when compiling the C/C++ code 4. write wrappers/forwarders/trampolines in C/C++, compile them and link them in 5. write a tool that patches the object file (not as hard as it sounds, the symbol table is usually in one spot, but of course the patcher would have to be implemented for each object file format). I've written object file patchers before, they work surprisingly well. Nobody else does it, presumably because the thought inspires terror :-) 6. provide some switch to the D compiler to rename A=>B in the object file symbols, though I'd worry such would slow the compiler down 7. perhaps amend the language such that an identifier of the form "__keyword" would appear in the object file as "keyword". 8. if any identifier starts with a keyword and ends with at minimum one _, one _ from the end of the identifier will be removed for mangling (but not e.g. lookup).
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 11:08 PM, Manu wrote: We have demonstrated consistent ongoing issues and frustration for 6 years. Have you ever tried the alias method I proposed?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 11:08 PM, Manu wrote: I think implementing the string alternative is the only robust way forward, because that also solves the additional problem of being able to name C++ namespaces that are invalid D keywords, which has bitten me in at least 2 particularly noteworthy occasions. Which keywords were those? In any case, this is a general problem when dealing with C and C++ interoperability, and your solution would only deal with one case of it. For example, --- C++ --- void with(); int scope; enum pure; --- If this problem were to be solved, it should be solved, not hacked for one case only. There are many ways of dealing with it: 1. pragma(mangle) 2. change the names in the C/C++ side 3. use a macro -Dwith=with_ when compiling the C/C++ code 4. write wrappers/forwarders/trampolines in C/C++, compile them and link them in 5. write a tool that patches the object file (not as hard as it sounds, the symbol table is usually in one spot, but of course the patcher would have to be implemented for each object file format). I've written object file patchers before, they work surprisingly well. Nobody else does it, presumably because the thought inspires terror :-) 6. provide some switch to the D compiler to rename A=>B in the object file symbols, though I'd worry such would slow the compiler down 7. perhaps amend the language such that an identifier of the form "__keyword" would appear in the object file as "keyword".
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote:
On Thursday, 2 August 2018 at 07:47:19 UTC, aliak wrote:
Hi, just a release of a meta programming library
(https://bolts.dub.pm) that has utilities that I use in
personal projects, and that I find in phobos, and or in the
forums. A notable difference is that functions here try to
operate on any compile time entities if they can be resolved.
I.e.:
int i;
void g0(int) {}
struct S { void g1(int) {} }
alias g2 = (int a) => a;
static assert(isFunctionOver!(g0, int));
static assert(isFunctionOver!(S.g1, 3));
static assert(isFunctionOver!(g2, i));
And there's a "doth" super template that tries to contain most
things under what I feel is a nicer api ("is" was taken, so i
looked to Shakespearian gibberish :p) and also allows for
easier use with meta functions:
E.g.:
int *pi = null;
static assert( doth!3.of!int);
static assert(!doth!pi.nullable);
static assert( doth!((a, b, c, d) => a).functionOver!(int,
int, int, int));
int i;
import std.meta: allSatisfy;
static assert(allSatisfy!(doth!int.of, 3, 4, int, i));
Here's an example of a gem adapted from inside the
forms/phobos sources as well:
alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);
alias d = staticZip!(a, b, c);
static assert(d.length == 3);
static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9))
static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5,
8, 3, 6, 9));
Cheers,
- Ali
This looks cool. Lots of things that lots of people have
reimplemented lots of times over the years, but all in one
place and documented.
2 points:
1) Are you aware of this:
https://github.com/dlang/phobos/blob/master/std/meta.d ? I
think if a bunch of good motivating examples are given, making
this public would be possible. Then everyone would be using the
same one and your library would truly just be utilities.
woops, pressed send too early:
2) I don't think "doth" is synonymous with "is" how you're using
it. "doth" is for doing, e.g.
"Methinks he doth protest too much" or "This code doth stink" is
OK
"Green doth a colour" or "strstr doth a function" is not OK.
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 07:47:19 UTC, aliak wrote:
Hi, just a release of a meta programming library
(https://bolts.dub.pm) that has utilities that I use in
personal projects, and that I find in phobos, and or in the
forums. A notable difference is that functions here try to
operate on any compile time entities if they can be resolved.
I.e.:
int i;
void g0(int) {}
struct S { void g1(int) {} }
alias g2 = (int a) => a;
static assert(isFunctionOver!(g0, int));
static assert(isFunctionOver!(S.g1, 3));
static assert(isFunctionOver!(g2, i));
And there's a "doth" super template that tries to contain most
things under what I feel is a nicer api ("is" was taken, so i
looked to Shakespearian gibberish :p) and also allows for
easier use with meta functions:
E.g.:
int *pi = null;
static assert( doth!3.of!int);
static assert(!doth!pi.nullable);
static assert( doth!((a, b, c, d) => a).functionOver!(int, int,
int, int));
int i;
import std.meta: allSatisfy;
static assert(allSatisfy!(doth!int.of, 3, 4, int, i));
Here's an example of a gem adapted from inside the forms/phobos
sources as well:
alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);
alias d = staticZip!(a, b, c);
static assert(d.length == 3);
static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9))
static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5,
8, 3, 6, 9));
Cheers,
- Ali
This looks cool. Lots of things that lots of people have
reimplemented lots of times over the years, but all in one place
and documented.
2 points:
1) Are you aware of this:
https://github.com/dlang/phobos/blob/master/std/meta.d ? I think
if a bunch of good motivating examples are given, making this
public would be possible. Then everyone would be using the same
one and your library would truly just be utilities.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/1/2018 10:06 PM, Johannes Pfau wrote: I guess that would be acceptable if there is a real benefit, but I have not seen a single argument for the current behavior in this thread. Please read my postings in this thread, then.
Prime number
I know D is very powerful from my little experience. What is the idiomatic way to get prime numbers say from 1-30 without using loops(outer and inner loop). Can map, filter, fold etc in algorithm be use. Pls show some code with chain call. I can easily achieve even numberd and odd numbers using filter. But prime numbers I have to use 2loops. I will appreciate any help,just a newbie in D
Bolts 0.4 meta programming library
Hi, just a release of a meta programming library
(https://bolts.dub.pm) that has utilities that I use in personal
projects, and that I find in phobos, and or in the forums. A
notable difference is that functions here try to operate on any
compile time entities if they can be resolved.
I.e.:
int i;
void g0(int) {}
struct S { void g1(int) {} }
alias g2 = (int a) => a;
static assert(isFunctionOver!(g0, int));
static assert(isFunctionOver!(S.g1, 3));
static assert(isFunctionOver!(g2, i));
And there's a "doth" super template that tries to contain most
things under what I feel is a nicer api ("is" was taken, so i
looked to Shakespearian gibberish :p) and also allows for easier
use with meta functions:
E.g.:
int *pi = null;
static assert( doth!3.of!int);
static assert(!doth!pi.nullable);
static assert( doth!((a, b, c, d) => a).functionOver!(int, int,
int, int));
int i;
import std.meta: allSatisfy;
static assert(allSatisfy!(doth!int.of, 3, 4, int, i));
Here's an example of a gem adapted from inside the forms/phobos
sources as well:
alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);
alias d = staticZip!(a, b, c);
static assert(d.length == 3);
static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9))
static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5, 8,
3, 6, 9));
Cheers,
- Ali
[Issue 19135] New: std.json : JSON_TYPE does not match D Style.
https://issues.dlang.org/show_bug.cgi?id=19135 Issue ID: 19135 Summary: std.json : JSON_TYPE does not match D Style. Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: default_357-l...@yahoo.de std.json.JSON_TYPE is not conformant with the D Style Guidelines https://dlang.org/dstyle.html : * The names of user-defined types should be PascalCased * The members of enums should be camelCased, so their first letter is lowercase. * If a name would conflict with a keyword, and it is desirable to use the keyword rather than pick a different name, a single underscore ‘_’ should be appended to it. Names should not be capitalized differently in order to avoid conflicting with keywords. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 22:13:05 -0700 schrieb Walter Bright: > On 8/1/2018 12:01 PM, Manu wrote: >> You've never justified the design complexity and the baggage it >> carries. > Don't confuse you not agreeing with it with I never justified it. > > And please don't confuse me not listening to you with me not agreeing > with you. > > It *is* possible for reasonable people to disagree, especially when any > solution will involve many tradeoffs and compromises. In your most recent posts you provided some rationale for this, but nowhere as much as would have been necessary if anybody else proposed this feature and had to write a DIP for it. Introducing c++ namespace scopes added quite some complexity to the language and so far, you seem to be the only proponent of this, whereas we have many opponents. In the DIP process, such a change would have required quite a solid justification, examples, comparison to alternative solutions etc. Such a detailed rationale has never been given for this feature. -- Johannes
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Wed, 1 Aug 2018 at 22:15, Walter Bright via Digitalmars-d wrote: > > On 8/1/2018 12:01 PM, Manu wrote: > > You've never justified the design > > complexity and the baggage it carries. > Don't confuse you not agreeing with it with I never justified it. > > And please don't confuse me not listening to you with me not agreeing with > you. > > It *is* possible for reasonable people to disagree, especially when any > solution > will involve many tradeoffs and compromises. We have demonstrated consistent ongoing issues and frustration for 6 years. Your counter-argument is hypothetical at best, and has never demonstrated an advantage. Can you agree on that? I don't think that's a subjective quantity where reasonable people may disagree. If the namespace is useful in a minor subset of cases in the way you argue, then it should be a secondary feature which can be deployed independently as appropriate. It should not be conflated into a basic mangling request which we can't opt-out of. We are yet to observe a case where it was useful, and we have to do ongoing work to try and un-do the effect on our code. I also want to stress, I'm not trying to change the existing code. I'm not for a breaking change. I think implementing the string alternative is the only robust way forward, because that also solves the additional problem of being able to name C++ namespaces that are invalid D keywords, which has bitten me in at least 2 particularly noteworthy occasions. Your hypothetical scenario may continue to be served if you like.
Re: Is there any good reason why C++ namespaces are "closed" in D?
Am Wed, 01 Aug 2018 16:04:01 -0700 schrieb Walter Bright: > > Now, with D: > > extern (C++, ab) void foo(long); > foo(0);// works! > --- > extern (C++, ab) void foo(long); > extern (C++, ab) void foo(int); // error! > --- > extern (C++, ab) void foo(long); > extern (C++, cd) void foo(int); > foo(0);// error! > > I juxtaposed the lines so it's obvious. It's not so obvious when there's > a thousand lines of code between each of those lines. It's even worse > when foo(long) sends a birthday card to your daughter, and foo(int) > launches nuclear missiles. You probably didn't completely think this through: Earlier you suggested to use aliases to avoid explicitly specifying the c++ scopes. Then you suggested to use mixins or translator tools to automate alias generation and avoiding manually writing that boiler plate code. But if you do that: - extern (C++, ab) void foo(long); extern (C++, cd) void foo(int); alias foo = ab.foo; alias foo = cd.foo; - You've now got exactly the same problem with hijacking... So the benefit of explicit c++ namespace scoping is only a benefit if you do not use this alias trick. But then you face all other problems mentioned earlier... As a result, everybody now has to use the aliasing trick, the hijacking problem still exists and we have to write lots of useless boilerplate. -- Johannes
