[Issue 8523] [CTFE] compile time parsing of hex floats
https://issues.dlang.org/show_bug.cgi?id=8523 --- Comment #3 from Joakim --- Got rid of all the hex bit-packing in `std.conv.parse`, only missing bit is the call to C's `ldexp`, which still causes this to fail at compile-time. You can replace that with manual exponentiation if wanted to fix this, just as done for decimal strings now. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote: Let's see if we can find some common ground. The boilerplate I suggested seems to enable DPP to generate working code that behaves "as if" the namespace scope is not there, even for nested namespaces. Is this correct? Yes, but only for a single instance of the namespace. In the general case no, see the first reply in https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
Re: Is there any good reason why C++ namespaces are "closed" in D?
Let's see if we can find some common ground. The boilerplate I suggested seems to enable DPP to generate working code that behaves "as if" the namespace scope is not there, even for nested namespaces. Is this correct?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/5/2018 9:53 PM, Manu wrote: If we produce a DIP to fix this, will you reject it in principle? Producing a DIP is a good idea, it provides an anchor point for any future discussion of the topic, rather than the tangle and noise that is this thread. It is an ample opportunity to put the best foot forward on your ideas. I'm not going to categorically say we'll reject it, but will say that you'll need to make a more compelling case, and a DIP is the right method for that. Please keep in mind that a good DIP will address the counterarguments and other methods of solving the issue. As this thread affirms, trying to design things in the forums doesn't work very well, and I should have asked for a DIP in the first place.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/6/2018 3:19 PM, tide wrote: That's just a deflection, 1. I'm only here to help, and am not interested in scoring debate points. 2. To bring up other topics, please start a new thread. Especially since this one is quite voluminous.
[Issue 19123] -allinst gives undefined reference linker errors
https://issues.dlang.org/show_bug.cgi?id=19123 --- Comment #4 from Mike Franklin --- I've narrowed this down somewhat. What's happening is `-allinst` causes symbols to be emitted to the object file that otherwise wouldn't be. Those symbols, however, call other symbols, and it's those other symbols that aren't being emitted for some reason, resulting in linker errors. --
[Issue 19147] git
https://issues.dlang.org/show_bug.cgi?id=19147 Nathan S. changed: What|Removed |Added Summary|Reduce template bloat in|git |std.complex by using const | |arguments | --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6656 --
[Issue 19147] New: Reduce template bloat in std.complex by using const arguments
https://issues.dlang.org/show_bug.cgi?id=19147 Issue ID: 19147 Summary: Reduce template bloat in std.complex by using const arguments Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Labeling scalar arguments as const even when not logically necessary allows the same type to be inferred for a template function when called with const, non-const, & immutable scalars. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 20:35:37 UTC, Walter Bright wrote: On 8/6/2018 11:26 AM, tide wrote: What's your crossplatform workaround if I have a namespace named "version" or "package" ? See my reply to Rick Cattermole. https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507 But that's not currently implemented is it? Your proposed solution adds an exception to the rule that just increases complexity of the language. No where else does "__" remove itself from the name it is used with. With the syntax extern(C++, "...") it is more easily understood, no crazy exceptions need to be made. You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. That's a longstanding issue and has nothing to do with namespaces. That's just a deflection, we are talking about C++ name mangling, not namespaces. How do you mangle const pointers to mutable data in D to be able to call C++ ? You don't need to implement the feature, you just need a way to create the C++ mangle, which there is none. The only way is to change C++ code, like you said, telling people to rewrite their code is never, ever going to work.
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 21:23:36 UTC, Paul Backus wrote:
On Monday, 6 August 2018 at 20:22:36 UTC, vit wrote:
On Monday, 6 August 2018 at 19:56:03 UTC, Steven Schveighoffer
wrote:
BTW, is there a reason you aren't just using Algebraic?
https://dlang.org/phobos/std_variant.html#.Algebraic
-Steve
primarily visit for Algebraic isn't pure, @nogc, @safe,
nothrow.
I wrote the 'sumtype' package to solve this exact problem:
https://code.dlang.org/packages/sumtype
I'm using simpler (and less powerful) version with different
visit/visitor syntax:
struct Foo{
string foo;
}
struct Bar1{
string bar;
}
struct Bar2{
string bar;
}
void main()pure nothrow @safe @nogc{
Variant!(true, Foo, Bar1, Bar2) var; ///Nullable == true
static visit(T)(auto ref const(T) x, string def = ""){
import std.experimental.all;
static if(is(T == Foo)){
return x.foo;
}
else static if(false
|| is(T == Bar1)
|| is(T == Bar2)
){
return x.bar;
}
else static if(is(T == typeof(null))){
return def;
}
else static assert(0, "no impl");
}
assert(var.isa!null);
assert(var.visitor!visit("null") == "null");
var = Foo("foo");
assert(var.isa!Foo);
assert(var.visitor!visit == "foo");
var = Bar1("bar1");
assert(var.isa!Bar1);
assert(var.visitor!visit == "bar1");
var = Bar2("bar2");
assert(var.isa!Bar2);
assert(var.visitor!visit == "bar2");
var = null;
assert(var.isa!null);
auto var2 = Variant!(false, Foo, Bar1,
Bar2)(Foo("foo"));///Nullable == false
assert(var2.visitor!visit == "foo");
assert(var2.as!Foo.foo == "foo");
///var2 = null; //error, variant is not null
}
full code: https://dpaste.dzfl.pl/d83ecca23694
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 20:22:36 UTC, vit wrote: On Monday, 6 August 2018 at 19:56:03 UTC, Steven Schveighoffer wrote: BTW, is there a reason you aren't just using Algebraic? https://dlang.org/phobos/std_variant.html#.Algebraic -Steve primarily visit for Algebraic isn't pure, @nogc, @safe, nothrow. I wrote the 'sumtype' package to solve this exact problem: https://code.dlang.org/packages/sumtype
Re: scope variable values assigned to non-scope this.placeholder
On Monday, 6 August 2018 at 20:29:29 UTC, Alexandru Ermicioi wrote: Hi Dlang community! I've been playing with dip1000 and scope storage class and stumbled upon a strange error that I can't to understand yet. Here is minimized version of code that generates the error: [...] Parameter values must be `return scope` and this need to be in compiler: https://issues.dlang.org/show_bug.cgi?id=19097
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/6/2018 11:26 AM, tide wrote: What's your crossplatform workaround if I have a namespace named "version" or "package" ? See my reply to Rick Cattermole. https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507 You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. That's a longstanding issue and has nothing to do with namespaces. How can you suggest DPP then go on to say you've never even used it or know how it is even used? Because I have full confidence in Atila and Laeeth. I've also written such a translator myself (HTOD) so I know what they're capable of.
scope variable values assigned to non-scope this.placeholder
Hi Dlang community!
I've been playing with dip1000 and scope storage class and
stumbled upon a strange error that I can't to understand yet.
Here is minimized version of code that generates the error:
The link: https://run.dlang.io/is/rg2Odu
--
import std.stdio;
import std.range;
import std.algorithm;
@safe:
class C {
const int*[] placeholder;
this(scope int*[] values) {
this.placeholder = values;
}
}
void main()
{
auto array = iota(0, 20).map!((int i) => new int(i)).array;
auto c = new C(array);
writeln(c.placeholder.map!(p => *p));
}
--
I'm not sure what I'm doing wrong, but from what I understand it
should check 'this' lifetime to lifetime of scoped 'values' and
error only in case when passed value has shorter lifetime than
the container itself.
I'll be thankful if someone could explain what is wrong with this
example.
Regards,
Alexandru.
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 19:56:03 UTC, Steven Schveighoffer wrote: BTW, is there a reason you aren't just using Algebraic? https://dlang.org/phobos/std_variant.html#.Algebraic -Steve primarily visit for Algebraic isn't pure, @nogc, @safe, nothrow.
Re: GC and void[N] in struct
On 8/6/18 3:43 PM, Steven Schveighoffer wrote:
On 8/6/18 2:59 PM, vit wrote:
On Monday, 6 August 2018 at 18:28:11 UTC, Steven Schveighoffer wrote:
On 8/6/18 2:22 PM, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
define "N"
}
Instances of struct S are allocated by standard GC new and S.data_
can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC enabled
then it fail randomly.
how does it fail?
private auto sizeOf(T)(){return T.sizeof;}
Hm... wouldn't enum sizeOf(T) = T.sizeof work better?
struct ExprImpl(Ts...){
enum N = max(staticMap!(sizeOf, Ts));
This is clever!
invariant(kind_ != 0);
uint kind_ = 0;
void[N] data_;
this(T)(auto ref T x){/+emplace T to data_ and change kind_ to
something != 0+/}
}
Ts == structs
data change without triggering invariant after allocation in other
part of program.
Most definitely this is alignment problem.
Here is what I *think* is happening:
1. You are constructing one of these structs, and storing a pointer as
the T type.
2. You are on a 64-bit CPU.
3. The pointer is misaligned on the CPU, so when the GC scans this
struct to see if it's pointing at anything, it sees one half as the
kind_ value, and the other half is half of the pointer.
4. It misses the object being pointed at by the T inside the struct, and
collects it, leaving a dangling pointer.
5. Memory corruption.
when you put the void[N] member *first*, it can properly align the item
(most cases where the compiler is placing data, it starts out aligned)
but this does not guarantee you have proper alignment, as void[N] has no
alignment constraints.
I'd recommend instead, changing the uint kind_ to a size_t. This not
only aligns the void[N] to size_t size, which should put any pointers in
the right place, but it also makes sure the entire struct is aligned.
BTW, is there a reason you aren't just using Algebraic?
https://dlang.org/phobos/std_variant.html#.Algebraic
-Steve
Re: GC and void[N] in struct
On 8/6/18 2:59 PM, vit wrote:
On Monday, 6 August 2018 at 18:28:11 UTC, Steven Schveighoffer wrote:
On 8/6/18 2:22 PM, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
define "N"
}
Instances of struct S are allocated by standard GC new and S.data_
can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC enabled then
it fail randomly.
how does it fail?
private auto sizeOf(T)(){return T.sizeof;}
Hm... wouldn't enum sizeOf(T) = T.sizeof work better?
struct ExprImpl(Ts...){
enum N = max(staticMap!(sizeOf, Ts));
This is clever!
invariant(kind_ != 0);
uint kind_ = 0;
void[N] data_;
this(T)(auto ref T x){/+emplace T to data_ and change kind_ to
something != 0+/}
}
Ts == structs
data change without triggering invariant after allocation in other part
of program.
Most definitely this is alignment problem.
Here is what I *think* is happening:
1. You are constructing one of these structs, and storing a pointer as
the T type.
2. You are on a 64-bit CPU.
3. The pointer is misaligned on the CPU, so when the GC scans this
struct to see if it's pointing at anything, it sees one half as the
kind_ value, and the other half is half of the pointer.
4. It misses the object being pointed at by the T inside the struct, and
collects it, leaving a dangling pointer.
5. Memory corruption.
when you put the void[N] member *first*, it can properly align the item
(most cases where the compiler is placing data, it starts out aligned)
but this does not guarantee you have proper alignment, as void[N] has no
alignment constraints.
I'd recommend instead, changing the uint kind_ to a size_t. This not
only aligns the void[N] to size_t size, which should put any pointers in
the right place, but it also makes sure the entire struct is aligned.
-Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
Yes. But then you'll have the people who want a 1:1
correspondence with their C++ files and the corresponding D
files. I happen to be one of those people, for the ease of
maintaining a translation (and for comparing it with the
original C++ source code if it is not behaving correctly).
This would still be true if current behavior was kept and
extern(C++, "ns") or extern(C++, ns, noscope) or something was
added though no?
Though I do think the string is superior though because then this
would actually compile:
extern(C++, "shared") {
void f();
}
It feels the two preferences being mutually exclusive has somehow
occupied a lot of this discussion when they are not.
Cheers,
- Ali
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 19:17:58 UTC, nkm1 wrote:
On Monday, 6 August 2018 at 18:22:24 UTC, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
}
Instances of struct S are allocated by standard GC new and
S.data_ can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC
enabled then it fail randomly.
If the definition of S look like this:
struct S{
void[N] data_;
uint kind;
}
then program run fine with GC.enable.
Whats the problem? Something with alignment?
Probably. Try something like:
struct S
{
uint kind;
align((void *).alignof) void[N] data_;
}
And see if it solves the problem.
align((void *).alignof) work, thanks.
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 18:22:24 UTC, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
}
Instances of struct S are allocated by standard GC new and
S.data_ can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC
enabled then it fail randomly.
If the definition of S look like this:
struct S{
void[N] data_;
uint kind;
}
then program run fine with GC.enable.
Whats the problem? Something with alignment?
Probably. Try something like:
struct S
{
uint kind;
align((void *).alignof) void[N] data_;
}
And see if it solves the problem.
Re: GC and void[N] in struct
On Monday, 6 August 2018 at 18:28:11 UTC, Steven Schveighoffer
wrote:
On 8/6/18 2:22 PM, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
define "N"
}
Instances of struct S are allocated by standard GC new and
S.data_ can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC
enabled then it fail randomly.
how does it fail?
-Steve
private auto sizeOf(T)(){return T.sizeof;}
struct ExprImpl(Ts...){
enum N = max(staticMap!(sizeOf, Ts));
invariant(kind_ != 0);
uint kind_ = 0;
void[N] data_;
this(T)(auto ref T x){/+emplace T to data_ and change kind_
to something != 0+/}
}
Ts == structs
data change without triggering invariant after allocation in
other part of program.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 5 August 2018 at 23:28:06 UTC, Walter Bright wrote:
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've
put these forth before, and I could repeat myself rebutting
each. I expect we're at a dead end with that.
But the fact remains, I've shown both you and Atila how to make
things work for you, in a hygienic manner, with the language as
it is now. For you, it's adding an alias declaration. For
Atila, it's a couple lines of boilerplate dpp can add, without
disrupting dpp's internal design.
What's your crossplatform workaround if I have a namespace named
"version" or "package" ?
extern(C++, version) // error
{
void foo();
}
extern(C++, package) // error
{
void bar();
}
You also didn't mention your reasoning behind not including a way
to use const pointers to mutable data. The only workaround that
exists currently is to rewrite C++ code, which you stated wasn't
a valid solution you considered for extern(C++).
I understand you don't want to type in the alias declaration.
May I suggest using Atila's dpp? Then you won't have to even
look at the output. I also expect that your use cases can help
make dpp better, and that would be good for all of us.
---
P.S. I have no experience with dpp and how it is used. But my
experience with translators is that nobody expects to nor wants
to look at its output. They just want it to work. And it seems
a fact of life that the output of machine translation resists
being purty, because what's purty in A never looks purty in B.
How can you suggest DPP then go on to say you've never even used
it or know how it is even used?
Re: GC and void[N] in struct
On 8/6/18 2:22 PM, vit wrote:
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
define "N"
}
Instances of struct S are allocated by standard GC new and S.data_ can
contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC enabled then it
fail randomly.
how does it fail?
-Steve
GC and void[N] in struct
Hello,
I have this struct:
struct S{
uint kind;
void[N] data_;
}
Instances of struct S are allocated by standard GC new and
S.data_ can contain pointers/ranges to GC allocated data.
If is GC disabled then program run fine. But when is GC enabled
then it fail randomly.
If the definition of S look like this:
struct S{
void[N] data_;
uint kind;
}
then program run fine with GC.enable.
Whats the problem? Something with alignment?
Re: Prime number
On Thursday, 2 August 2018 at 14:37:56 UTC, Greatsam4sure wrote: 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. Computing prime numbers efficiently would require something more complex like an Atkin sieve which I doubt will be very easy to implement without loop. That said, to start optimizing without changing the algorithm you can profile your code with -profile to see where you're spending time that you can shave off and rewrite the code to accelerate those parts. You should really start by changing the algorithm though. 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 Not specifically on the algorithm module but I'd recommend reading [1] for a good intro to D from basics to advanced topics. For algorithms especially, I'd recommend reading on templates [2] and ranges [3]. Especially one thing you should know to understand the concepts behind most range-based functions is that most of them try to work on infinite sequences of things and therefore make assumptions only about the first items and never about the last ones. That's why functions like std.algorithm.find don't just return the element or its position but the sub-sequence starting at that element. There are exceptions though, and this comment may not make much sense at first so feel free to ignore it for the moment, but hopefully it'll come back to you when you need it. [1]: https://ddili.org/ders/d.en/index.html [2]: https://ddili.org/ders/d.en/templates.html [3]: https://ddili.org/ders/d.en/ranges.html
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:13:02 UTC, Timoses wrote: Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas? You can upload the files that get installed somewhere, I don't think the installer does anything other than setup the sc.ini file which seems to have become rather basic.
Re: DMD installation prompts "Windows protected your PC"
On Mon, 06 Aug 2018 14:13:02 +, Timoses wrote: > Thanks Windows, not! > > Since our department switched to Windows 10 I'm now unable to install > DMD. > > To make it even worse, there's no way I see to install a virtual machine > any more (VirtualBox or VMWare) since they collide with Hyper-V. I've > disabled Hyper-V, but it seems there can be a lot of things using it > around one's back anyway. By "disable Hyper-V", do you mean uninstall via Add/Remove Windows Features? I've never had a problem with VirtualBox after that. Have you tried the DMD zip instead of installer? --Ryan
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 12:18:21 UTC, tide wrote: On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote: On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote: The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility. Why would you write bindings if the computer can do it for you, better, faster and consistently? With the current tools the ones that generate D files to be used aren't very good. They evaluate Macros based on the current implementation, so if there's a define MACHINE_X86 or MACHINE_x64, those macro and #if's will be evaluated based on the current system running the tool instead of generating equivalent version() statements. If the D files are to be checked in, then yes, that'd be a problem. If they're not, as is the case with dpp, then... that's actually what you want. dpp: I fought the preprocessor and the preprocessor won. It would be, but I don't think it'll ever be 100% and will require manual intervention. If manual intervention is required, dpp has failed. Some problems will be tricky, especially where the preprocessor is concerned. But a lot of real-life production code works.
[Issue 19140] [REG master] AssertError@dmd/ctfeexpr.d(229): Assertion failure
https://issues.dlang.org/show_bug.cgi?id=19140 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/efb8ec6defe809a182d18ba1819105fea7c86868 fix Issue 19140 - AssertError@dmd/ctfeexpr.d(229): Assertion failure https://github.com/dlang/dmd/commit/e15d4df77e0a3c9cd71051da6d4cd7e87eebd64c Merge pull request #8537 from ibuclaw/issue19140 fix Issue 19140 - AssertError@dmd/ctfeexpr.d(229): Assertion failure --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote: On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d wrote: [...] Faster and consistently, sure. But I don't think 'better' is possible. [...] Bindings != wrappers. I agree that wrappers will nearly always need to be written, I'm trying to automate the writing of the declarations needed to link. It should be possible to automate translating everything, but some things will be tricky in C++. std::vector is quite clearly a value type, yet the GNU implementation declares it as a class with protected inheritance from _Vector_base. That's going to be fun...
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 21:49:53 UTC, Walter Bright wrote:
On 8/3/2018 3:58 AM, Atila Neves wrote:
I would only be able to alias a nested namespace once, since
the code below obviously won't work:
mixin CppNamespace0!() x;
alias chrono = x.std.chrono;
mixin CppNamespace1!() y;
alias chrono = y.std.chrono;
Try this:
mixin template X() { // boilerplate prefix
extern (C++, std) extern(C++, chrono) int foo(); //
original line
} mixin X!() x; alias foo = x.std.chrono.foo; //
boilerplate suffix
That doesn't solve the problem at all. I was toying with being
able to have a nested namespace be an alias in a module. I can't
realias chrono after the first `alias chrono = `, nor can I alias
it to the different `chrono`s in all the different template
mixins.
I considered for a while whether or not this would be truly
bad, and the more I think about it the more convinced I am
that Manu is right and there should be _no_ scoping whatsoever
in D regarding C++ namespaces. We have packages and modules,
we can use those to put the C++ functions we declare in
whatever hierarchy we want.
I am puzzled. With:
namespace std {
namespace chrono {
void foo();
}
}
namespace std {
namespace chrono {
void bar();
}
}
you have stated that it is impractical for your translator to
rewrite this as:
namespace std {
namespace chrono {
void foo();
void bar();
}
}
Ok, I get that. But it is practical to rewrite it as:
module std.chrono;
void foo();
void bar();
?
I don't understand what your question has to do with what you
quoted. What I'm trying to say is that I think `extern(C++,
foo.bar)` should NOT introduce a scope in D in any way, shape, or
form. The D module/import/overload system should have no idea of
what `foo` or `foo.bar` are - they don't exist.
> I mean `std` should never be part of the fully qualified name
of, for
> instance, `core.stdcpp.exception.std.bad_exception`. It
should just
> be `core.stdcpp.exception.bad_exception` instead.
C++ recognizes that, too, which is why it has "using"
declarations. D has the equivalent thing, "alias".
You can do things like:
import std = core.stdcpp.exception;
and then refer to:
std.bad_exception
or:
import exception = core.stdcpp.exception;
exception.bad_exception;
or whatever works best for one's project. Aliasing and import
renaming (which are really just more aliasing) is very capable,
and was designed for just these sorts of issues.
I think we're talking past each other. I know how to alias in D,
and how to use `using` in C++. What I'm saying is that, with the
file we have now (core.stdcpp.exception):
extern(C++, std) {
class exception { /* ... */ }
}
Currently the fully qualified name of `exception` is
`core.stdcpp.exception.std.exception`. I'm arguing that this is a
mistake, and the the FQN should instead be
`core.stdcpp.exception.exception`.
Yes, namespaces introduce scope in C++. Yes, lookup rules in C++
are crazy. The main points I'm (and, I think, Manu) arguing are:
1. We already have D packages, modules, and overload rules. We
don't need to import any from C++
2. That namespaces introduce a scope in C++ does not mean that
`extern(C++, ns)` should introduce one in D
i.e. Keep everything about D as-is, _except_ for no scoping for
`extern(C++, ns)`.
Re: foreach on a tuple using aliases
On 06.08.2018 14:37, Steven Schveighoffer wrote: On 8/5/18 11:40 AM, Timon Gehr wrote: On 05.08.2018 16:07, Steven Schveighoffer wrote: So is this a bug? Is it expected? It's a bug. The two copies of 'item' are not supposed to be the same symbol. (Different types -> different symbols.) Yep. I even found it has nothing to do with foreach on a tuple: https://run.dlang.io/is/vxQlIi I wonder though, it shouldn't really be a different type that triggers it, right? It shouldn't.
[Issue 19146] std.process.spawnProcess: Set signal handlers are reset to SIG_DFL between fork-exec
https://issues.dlang.org/show_bug.cgi?id=19146 Hiroki Noda changed: What|Removed |Added Summary|std.process.spawnProcess: |std.process.spawnProcess: |Set signal handlers are |Set signal handlers are |reset to SIG_DFL before |reset to SIG_DFL between |fork|fork-exec --
Re: DMD installation prompts "Windows protected your PC"
On 07/08/2018 2:53 AM, Timoses wrote: On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing). Well, there is Kaspersky installed and I know there's been a discussion about it here (https://forum.dlang.org/post/wjvfkteddmwhhiktv...@forum.dlang.org). However, it's not Kaspersky that is complaining. At least it doesn't look like it. Perhaps Windows wraps it somehow, idk. Windows prompt: http://oi68.tinypic.com/2eevoxt.jpg All I can do is "Don't run". It has to do with the Windows Defender settings, which I can't change. As of Win8, it definitely is code signing. https://answers.microsoft.com/en-us/windows/forum/windows_other-windows_install/windows-defender-smartscreen-prevented-an/0e5bf2b8-932f-4df0-a984-a70b2fd0cc7a
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing). Well, there is Kaspersky installed and I know there's been a discussion about it here (https://forum.dlang.org/post/wjvfkteddmwhhiktv...@forum.dlang.org). However, it's not Kaspersky that is complaining. At least it doesn't look like it. Perhaps Windows wraps it somehow, idk. Windows prompt: http://oi68.tinypic.com/2eevoxt.jpg All I can do is "Don't run". It has to do with the Windows Defender settings, which I can't change.
Re: Dpp on run.dlang.io
On Monday, 6 August 2018 at 13:43:46 UTC, Laeeth Isharc wrote: And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab If an Octave extension written in D works, do you have anywhere to point me to on what's needed to make it work with Matlab? (Is it usually drop-in compatible?) Unfortunately I don't use Matlab and don't have a license to try out. However, as I understand Octave's mex interface, the original goal was to allow Matlab extensions to be compiled and run in Octave. Otherwise you could have a core language that ran Matlab code but extensions would still lock you in to Matlab. Thus, I'm assuming that the ability to use Octave's mex interface implies ability to use Matlab's.
Re: Why does templated interface function return something different than final function?
On Thursday, 2 August 2018 at 20:35:57 UTC, Steven Schveighoffer
wrote:
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
Thanks for the insight. To me it sounds like std.conv `toImpl`
doesn't properly handle inout types in this case.
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: (e.g. require code signing). Why don't we just sign the code anyway? This shouldn't be a big deal and it has been a problem for many people for many years.
Re: DMD installation prompts "Windows protected your PC"
On 07/08/2018 2:13 AM, Timoses wrote: Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas? dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing).
DMD installation prompts "Windows protected your PC"
Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas?
More fun with autodecoding
I wanted to share a story where I actually tried to add a new type with
autodecoding and failed.
I want to create a wrapper type that forwards an underlying range type
but adds one feature -- tracking in the original range where you were.
This is in a new library I'm writing for parsing.
So my first idea was I will just forward all methods from a given range
manually -- I need to override certain ones which affect the offset into
the original range.
However, typically parsing is done from text.
I realized, strings are a range of dchar, but I need the length and
other things forwarded so they can be drop-in replacements for strings
(I treat strings wstrings as character buffers in iopipe). However,
phobos will then assume length() as the number of dchar elements, and
assume it has indexing, etc.! Here is a case where I can't repeat the
mistakes of phobos of auto-decoding for my own type! I never thought I'd
have that problem...
So I thought, maybe I'll just alias this the underlying range and only
override the parts that are needed. I end up with a nice tiny
definition, and things are looking pretty good:
static struct Result
{
private size_t pos;
B _buffer;
alias _buffer this;
// implement the slice operations
size_t[2] opSlice(size_t dim)(int start, int end) if (dim == 0)
in
{ assert(start >= 0 && end <= _buffer.length); }
do
{
return [start, end];
}
Result opIndex(size_t[2] dims)
{
return Result(pos + dims[0], _buffer[dims[0] .. dims[1]]);
}
void popFront()
{
import std.traits : isNarrowString;
static if(isNarrowString!B)
{
auto prevLen = _buffer.length;
_buffer.popFront;
pos += prevLen - _buffer.length;
}
else
{
_buffer.popFront;
++pos;
}
}
// the specialized buffer reference accessor.
@property auto bufRef()
{
return BufRef(pos, _buffer.length);
}
}
Note already the sucky part in popFront.
But then I got a surprise when I went to use it:
import std.algorithm : splitter;
auto buf = "hi there this is a sentence";
auto split1 = buf.bwin.splitter; // specialized split range
auto split2 = buf.splitter; // normal split range
while(!split1.empty)
{
assert(split1.front == split2.front);
assert(split1.front.bufRef.concrete(buf) == split2.front); //
FAILS!
split1.popFront;
split2.popfront;
}
What happened? It turns out, the splitter looks for length and indexing
*OR* that it is a narrow string. Splitter is trying to ignore the fact
that Phobos forces autodecoding on char arrays to achieve performance.
With this taken into account, I think my type does not pass any of the
constraints for any of the overloads (not 100% sure on that), so it
devolves to just using the alias this'd element directly, completely
circumventing the point of my wrapper. The error I get is "no member
`bufRef` for type `string`".
My next attempt will be to use byCodeUnit when I detect a narrow string,
which hopefully will work OK. But I'm not sure if the performance is
going to be the same, since now it will likely FORCE autodecoding on the
algorithms that have specialized versions to AVOID autodecoding (I think).
I'm very tempted to start writing my own parsing utilities and avoid
using Phobos algorithms...
-Steve
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Example of idea for student: A deep learning framework using together a LLVM SPIR-V enable and https://github.com/libmir/dcompute would be awesome
Re: Dpp on run.dlang.io
On Monday, 6 August 2018 at 13:32:23 UTC, bachmeier wrote: On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote: One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab If an Octave extension written in D works, do you have anywhere to point me to on what's needed to make it work with Matlab? (Is it usually drop-in compatible?)
Re: dtoh
On Monday, 6 August 2018 at 13:28:05 UTC, Laeeth Isharc wrote: Hi Walter. Can dtoh be open-sourced now that dmd is? Laeeth. Better write Walter a direct mail. He doesn't check the learn NG very often.
Re: Dpp on run.dlang.io
On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote: One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab
[Issue 19146] New: std.process.spawnProcess: Set signal handlers are reset to SIG_DFL before fork
https://issues.dlang.org/show_bug.cgi?id=19146 Issue ID: 19146 Summary: std.process.spawnProcess: Set signal handlers are reset to SIG_DFL before fork Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: kub...@gmail.com It's a possibility that rewriteing global variables may be performed by singal handler,So set signal handlers are reset to SIG_DFL. In order to prevent race condition, it is necessary to mask signals once in the parent process before fork. --
dtoh
Hi Walter. Can dtoh be open-sourced now that dmd is? Laeeth.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 09:48:30 UTC, Danni Coy wrote: Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing? I haven't read all of the posts in this thread, but my understanding of Walter's argument is that he believes there is only one correct way to work with C++ code. If that's the case, there's no need for warnings, because the language should prevent you from doing it wrong in the first place. The first step will be to convince him that the "mangle only" approach is valid.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 04:53:05 UTC, Manu wrote: If we produce a DIP to fix this, will you reject it in principle? I think you and Walter Bright made good points and I think a creation of a DIP that addresses his concerns would be a best course of action IMO. -Alexander
[Issue 19122] Multiple destruction of union members
https://issues.dlang.org/show_bug.cgi?id=19122 ZombineDev changed: What|Removed |Added Keywords||spec, wrong-code CC||petar.p.ki...@gmail.com Hardware|x86 |All OS|Windows |All --
Re: foreach on a tuple using aliases
On 8/5/18 11:40 AM, Timon Gehr wrote: On 05.08.2018 16:07, Steven Schveighoffer wrote: So is this a bug? Is it expected? It's a bug. The two copies of 'item' are not supposed to be the same symbol. (Different types -> different symbols.) Yep. I even found it has nothing to do with foreach on a tuple: https://run.dlang.io/is/vxQlIi I wonder though, it shouldn't really be a different type that triggers it, right? I mean 2 separate aliases to different variables that are the same type, I would hope would re-instantiate. Otherwise something like .offsetof would be wrong. Is it too difficult to fix? ... Unlikely. https://issues.dlang.org/show_bug.cgi?id=19145 -Steve
[Issue 19145] New: template alias with same name in function doesn't re-instantiate
https://issues.dlang.org/show_bug.cgi?id=19145
Issue ID: 19145
Summary: template alias with same name in function doesn't
re-instantiate
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
If I define 2 variables in the same function with the same name using separate
scopes, the compiler treats them as the same alias when passing to templates:
// using old template style to work with older versions
template isInt(alias var)
{
pragma(msg, "instantiated with " ~ typeof(var).stringof);
enum isInt = is(typeof(var) == int);
}
void main()
{
{
int item;
static assert(isInt!item);
}
{
long item;
static assert(!isInt!item); // failure all the way back to 2.060
}
}
The pragma prints only ONCE, and only prints the first type.
Just for sanity, I reversed the tests, and it's the same thing:
void main()
{
{
long item;
static assert(!isInt!item);
}
{
int item;
static assert(isInt!item); // fails
}
}
--
Re: foreach on a tuple using aliases
On 8/5/18 10:48 AM, Alex wrote:
void main()
{
Foo foo;
assert(isFoo!foo);
static struct X { int i; Foo foo; }
X x;
static foreach(i, item; typeof(x).tupleof)
static if(is(typeof(item) == Foo)) // line A
static assert(isFoo!item); // line B
else
static assert(!isFoo!item);
}
I did try static foreach, but it doesn't work.
The difference here is you are using typeof(x).tupleof, whereas I want
x.tupleof.
Note that in my real code, I do more than just the static assert, I want
to use item as a reference to the real field in x.
-Steve
[Issue 19123] -allinst gives undefined reference linker errors
https://issues.dlang.org/show_bug.cgi?id=19123 Mike Franklin changed: What|Removed |Added Component|phobos |dmd --- Comment #3 from Mike Franklin --- (In reply to Mike Franklin from comment #2) > According to digger it was https://github.com/dlang/phobos/pull/6190 that > caused this regression. ...though it may have just revealed a bug in DMD. --
[Issue 19123] -allinst gives undefined reference linker errors
https://issues.dlang.org/show_bug.cgi?id=19123 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com Component|dmd |phobos --- Comment #2 from Mike Franklin --- According to digger it was https://github.com/dlang/phobos/pull/6190 that caused this regression. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing? On Mon, Aug 6, 2018, 14:53 Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d > wrote: > > > > On 8/4/2018 12:45 AM, Manu wrote: > > > [...] > > I get it, Manu, you don't find my arguments compelling. You've put these > forth > > before, and I could repeat myself rebutting each. I expect we're at a > dead end > > with that. > > So, what you're saying is "I hear you, and I will never change it > because I subjectively prefer it the way it is in spite of every users > experience". > Will you commit to that position officially, so we can refer back to > it in future? > > Just support the string namespace? It won't hurt you, our code will be > better, and you'll make us all that actually link to C++ so much > happier for it. > > If we produce a DIP to fix this, will you reject it in principle? >
Re: getProtection gives different result when member is accessed via getMember
On Sunday, 5 August 2018 at 01:48:08 UTC, Yuxuan Shui wrote: file1.d: import std.stdio; file2.d: import file1; pragma(msg, __traits(getProtection, __traits(getMember, m1, "std"))); // public pragma(msg, __traits(getProtection, m1.std)); // private Bug? Intended? reported for you https://issues.dlang.org/show_bug.cgi?id=19144
[Issue 19144] New: Imported package have different protection depending on how it's accessed
https://issues.dlang.org/show_bug.cgi?id=19144 Issue ID: 19144 Summary: Imported package have different protection depending on how it's accessed Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com file1.d --- import std.stdio; file2.d --- import file1; pragma(msg, __traits(getProtection, __traits(getMember, file1, "std"))); pragma(msg, __traits(getProtection, file1.std)); static assert( __traits(isSame, __traits(getMember, file1, "std"), file1.std)); output: public private instead of private private Bug seems to happen only for packages. --
Re: getProtection gives different result when member is accessed via getMember
On Sunday, 5 August 2018 at 01:48:08 UTC, Yuxuan Shui wrote: file1.d: import std.stdio; file2.d: import file1; pragma(msg, __traits(getProtection, __traits(getMember, m1, "std"))); // public pragma(msg, __traits(getProtection, m1.std)); // private Bug? Intended? It's a bug since in both cases it's the same symbol how can the result be different ?
[Issue 19143] New: error or warn when assigning `this.foo = foo` when the lone foo is this.foo (i.e.not a constructor parameter)
https://issues.dlang.org/show_bug.cgi?id=19143
Issue ID: 19143
Summary: error or warn when assigning `this.foo = foo` when the
lone foo is this.foo (i.e.not a constructor parameter)
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: iamthewilsona...@hotmail.com
struct Foo
{
int i;
this (int ii)
{
this.i = i;
}
}
void main()
{
auto foo = Foo(2);
import std.stdio : writeln;
writeln(foo); // prints Foo(0);
}
should error or at least warn. It leads to very confusing behaviours (you think
i is assigned but its not).
--
Re: Dpp on run.dlang.io
On Monday, 6 August 2018 at 02:17:28 UTC, Mike Franklin wrote: The C standard library not a true and intrinsic dependency of D, and is outside of D's charter. [...] D is a much more capable programming language than C, and whatever functionality is being imported from the C standard library can be better implemented in D with compile-time optimizations via templates, memory safety, and other benefits. So if I understood correctly, you did not mean ejecting core.stdc but that DRuntime should not depend on it? Yeah, that sound reasonable for me too (If it is practical effort), regardless of DPP. But C libraries should be kept as a backup for platforms where there aren't D implementations. For example, IO functions could first try (using design by introspection) some implementation like https://github.com/schveiguy/iopipe. And if that does not support the enviroment, then fallback to C IO.
