Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 31 July 2018 at 23:02:16 UTC, Rubn wrote: One thing I don't like is that the C++ namespaces takes the name. So if you try to import a module that has C++ namespace of the same with the existing module, then you'll get an error. For effectively no reason, because as you say that namespace is useless and just occupies a name that could otherwise be used for the module name. Indeed, case in point: std
Re: SAoC Updates
On Tuesday, 31 July 2018 at 20:05:28 UTC, 12345swordy wrote: Would it be easier to submit a approved conflict of interest paper with the application? All I'm saying is that each applicant is responsible for making sure they are free and clear to participate. If you have an employment contract that makes participation problematic, then yes, obtaining permission from your employer and including a document to that effect with your application would be fulfilling that responsibility.
Re: Fastest JSON parser in the world is a D project
Am Fri, 13 Jul 2018 18:14:35 + schrieb iris : > Any idea about the performance of this json parser? > https://jsonformatter.org/json-parser ? That one is implemented in client side JavaScript. I didn't measure it, but the closest match in Kostya's benchmark could be the Node JS entry that is an order of magnitude slower. -- Marco
Re: Linking to dynamic druntime with dub
On Tuesday, 31 July 2018 at 14:27:18 UTC, rikki cattermole wrote: On 01/08/2018 2:18 AM, Nicholas Wilson wrote: On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub). No idea for dmd/gdc. But for LDC that would be (json): "dflags-ldc2": ["-link-defaultlib-shared"], Ahh, it turns out that loading shared libraries is not supported on OSX, wonderful.
Re: Moving druntime into the DMD repository
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. I think this is right-on. I don't see the solution yet, but I don't think it's just a matter of moving object.d. Mike
Re: Moving druntime into the DMD repository
On 7/31/2018 11:24 AM, Walter Bright wrote: On 7/27/2018 4:03 AM, Seb wrote: This a thread to explore whether it would be feasible to do so. Since DMD and Druntime require each other, it is the right thing to do. Perhaps my judgement is premature. There are a lot of good points raised in this thread.
Re: When did gdc and ldc start?
On 7/31/2018 12:07 PM, Iain Buclaw wrote: On 31 July 2018 at 20:40, Walter Bright via Digitalmars-d wrote: What's the difference between: DLI GDMD DGCC ? DLI: From what I recall, an independent project that just simply ported DMD front-end to Linux. I don't remember the details how but it had its own backend. GDMD: One failed attempt at getting a GCC back-end working with DMD. DGCC: The first successful GCC based compiler, to which GDC is derived from. You could call DGCC the LUCA of GDC (https://en.wikipedia.org/wiki/Last_universal_common_ancestor :-) Iain Was DGCC started from the GDMD sources?
Re: When did gdc and ldc start?
On 7/31/2018 2:16 PM, PaperBoy wrote: The author has possibly passed away on May 3 : https://necrocanada.com/obituaries-2018/burton-radons-2018/ That makes me sad. I was just reading some of his posts last night. He was still young, too.
Re: When did gdc and ldc start?
Thanks!
Re: Moving druntime into the DMD repository
On 01/08/2018 12:07 PM, Seb wrote: On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Moving object.d to the dmd repository would be rather easy: https://github.com/dlang/dmd/pull/8529 https://github.com/dlang/druntime/pull/2262 and already help a lot in decoupling both. Maybe that's a compromise that can be made? I think we're on to a winner now. Just a matter now of figuring out if we should have an object.d module at all, and if we can split stuff out from it e.g. TypeInfo. There is of course other things like rt.* that could go with it.
Re: Moving druntime into the DMD repository
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Moving object.d to the dmd repository would be rather easy: https://github.com/dlang/dmd/pull/8529 https://github.com/dlang/druntime/pull/2262 and already help a lot in decoupling both. Maybe that's a compromise that can be made?
Re: When did gdc and ldc start?
On Tuesday, 31 July 2018 at 18:21:15 UTC, Walter Bright wrote: What I'm doing is preparing a submission to HOPL on the origins of D. There's an emphasis on accuracy, references, correct dates, correct attributions, and correct credit to the right people. I'd put together a timeline for my LDC talk at DConf 2013: http://dconf.org/2013/talks/nadlinger.pdf I don't have my old notes with the NG post links handy, but the relevant announcements shouldn't be hard to find knowing the year – you'd want to cross-check them anyway. The Git history (which includes all the old SVN commits) should also be handy. As Iain mentioned, the first commit to the SVN repo was on September 1, 2007, which seems to have already compiled quite a bit of D code, judging from the test suite. — David
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 31 July 2018 at 16:23:55 UTC, Manu wrote: On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: On 2018-07-31 10:12, Manu wrote: > Given your favourite example: > > module a; > extern(C++, ns) void foo(); > > module b; > extern(C++, ns) void foo(); > - > module c; > import a, b; > foo(); // error: ambiguous > ns.foo(); // error, ambiguous (obviously) > a.ns.foo(); // naturally, this works... it's the D module > that > correctly organises the symbol. 'ns' is worthless here This works: a.foo(); You don't need "ns" in between the module name and the function. Right... But did you miss the point? The D module does the organisation (as you show). The ns offers nothing and creates other kinds of problems. Just because name resolution traverses the namespace (in simple cases), there is an entire language of complexity that interacts with that name lookup, and as far as I know, it has never proven useful, but rather, only complicated and annoying leading to boilerplate and hacks in certain situations. (ie, this thread exists and many others) Can you give some examples of those certain situations? It would help clear what is wrong with how it is currently implemented. One thing I don't like is that the C++ namespaces takes the name. So if you try to import a module that has C++ namespace of the same with the existing module, then you'll get an error. For effectively no reason, because as you say that namespace is useless and just occupies a name that could otherwise be used for the module name.
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Sunday, 29 July 2018 at 09:35:06 UTC, Abdulhaq wrote: On Saturday, 28 July 2018 at 14:45:19 UTC, Paolo Invernizzi wrote: I forgot the link... here it is: https://www.quantamagazine.org/to-make-sense-of-the-present-brains-may-predict-the-future-20180710 An interesting article. I found that Dennet's Consciousness Explained, which is presumably debunked old hat by now, is full of interesting experiments and speculation about how we model things in our mind and how our perceptions feed into that. It's a long time since I read it but if I remember correctly he shows how we seem to have a kind of mental theatre which has an expectation of what will come next from the senses, leading to interesting mistakes in perception. It's a useful model of how the mind works. That website often carries good articles about new maths as well. Me and my colleague are pretty different, in the approach to that kind of stuff... Maybe I'll post on the Forum a 'Request for D Advocacy', a-la PostgreSQL, so the community can try to address some of his concerns about modern D, and lower his discomfort! :-P If you can explain to me what is the _direction_ of D in terms of interfacing with large C++ libraries it would be very much appreciated! I'd love to be using D for some of my projects but I have a perception that using e.g. VTK is still a difficult thing to do from D. Is that still true? What is the long term plan for D, is it extern(C++), a binding technology? Is there any interest in Calypso from the upper echelons? I want to know where D is trying to go, not just where it is now. I want to know if anyone has got their heart in it. My CV says my main languages are Java, Python and D. That last one is mainly wishful thinking at the moment. I wish it wasn't! Make me believe, Paulo! Well we are hiring D programmers in London and HK in case it's interesting. Dpp doesn't work with STL yet. I asked Atila how long to #include vector and he thought maybe two months of full-time work. That's not out of the question in time, but we have too much else to do right now. I'm not sure if recent mangling improvements help and how much that changes things. But DPP keeps improving as does extern (C++) and probably one way and another it will work for quite a lot. Calypso makes cpp classes work as both value and reference types. I don't know the limit of what's possible without such changes - seems like C++ mangling is improving by leaps and bounds but I don't know when it will be dependable for templates. It's not that relevant what Andrei or Walter might think because it's a community-led project and we will make progress if somebody decides to spend their time working on it, or a company lends a resource for the same purpose. I'm sure they are all in favour of greater cpp interoperability, but I don't think the binding constraint is will from the top, but rather people willing and able to do the work. And if one wants to see it go faster then one can logically find a way to help with the work or contribute financially. I don't think anything else will make a difference. Same thing with Calypso. It's not ready yet to be integrated in a production compiler so it's an academic question as to the leadership's view about it.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 28 July 2018 at 01:03:10 UTC, Walter Bright wrote: On 7/27/2018 4:15 PM, Laeeth Isharc wrote: Can you think of a pragmatic solution to Atila's problem? One way is for the C++ => D translator to gather all the members of a namespace before trying to emit them. Since D does not impose an order on declarations (unlike C++) it is not constrained to follow the same order. So a new post preprocessor stage that parses the produced D code and regroups to group the declarations in the same namespace together ? Using DMD as a library or libdparse or something?
Re: How to get an inout constructor working with a template wrapper
On Tuesday, 31 July 2018 at 21:54:54 UTC, Steven Schveighoffer wrote: Because inout is trying to combine all mutability modifiers into one. You want to specify the type, not the mutability, in the template parameter T. Ahhh. Ok I see... I think. This doesn't make sense. Can you post runnable code? Hehe, ok, so I fell victim to compiler generating an error for number 3 and then nothing else :p But yes you're right, if I comment out number 3 then 6 errors as well. Sorry my bad! When I go back to your original failing example, and replace the 3 with immutable(int)(3), it still fails. So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? Yes. You can see for yourself with pragma msg: pragma(msg, typeof(t)); // immutable(int) But then what does it see in number 6, which works fine? I'm skeptical this is the case. Note that you may only see the instantiation error ONCE. Yep, you nailed that one. And why is 2 ok if 3 is not? because inout(const(T)) cannot have its inout removed. Because it may be an immutable? Or? But the complaint is really the issue. Clearly inout is specified, so it shouldn't complain that it isn't. Aye. I guess that's right. -Steve
Re: How to get an inout constructor working with a template wrapper
On 7/31/18 5:29 PM, aliak wrote: On Tuesday, 31 July 2018 at 12:37:34 UTC, Steven Schveighoffer wrote: On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); Ok bear with me, but I'm really confused why "wrap!int(immutable(int)(3))" is "correct". Because inout is trying to combine all mutability modifiers into one. You want to specify the type, not the mutability, in the template parameter T. Essentially, if this were a normal function that takes only ints, you would write it once for all mutabilities: auto wrap(inout(int) x) Which works for mutable, const, or immutable int. This all seems very inconsistent: 1. wrap!(int)(3); // ok 2. wrap!(const int)(3); // ok 3. wrap!(immutable int)(3); // nope 4. wrap!(int)(3); // ok 5. wrap!(const int)(const(int)(3)); // ok 6. wrap!(immutable int)(immutable(int)(3)); // ok! This doesn't make sense. Can you post runnable code? When I go back to your original failing example, and replace the 3 with immutable(int)(3), it still fails. So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? Yes. You can see for yourself with pragma msg: pragma(msg, typeof(t)); // immutable(int) But then what does it see in number 6, which works fine? I'm skeptical this is the case. Note that you may only see the instantiation error ONCE. And why is 2 ok if 3 is not? because inout(const(T)) cannot have its inout removed. And finally, why can't the compiler leave the inout there and then it doesn't need to complain about it? It has to strip inout to be consistent -- we want canonical types. It's the same reason immutable(const(int)) is just immutable(int), and const(const(const(int))) is just const(int). Having the original types be left in place would make for some weird rules. But the complaint is really the issue. Clearly inout is specified, so it shouldn't complain that it isn't. -Steve
Re: Declaring a pointer to a function returning a ref
On Tuesday, 31 July 2018 at 21:29:26 UTC, Jean-Louis Leroy wrote:
How do I declare a variable that contains a pointer to a
function returning a reference?
import std.stdio;
int foo(return ref int a)
{
a = 42;
return a;
}
ref int bar(return ref int a)
{
a = 42;
return a;
}
void main()
{
int x;
auto apf =
writeln(typeid(apf)); // int function(return ref int)*
int function(return ref int) xpf =
auto apb =
writeln(typeid(apb)); // int function(return ref int) ref*
// int function(return ref int) ref xpb = // Error:
no identifier for declarator `int function(return ref int)`
// ref int function(return ref int) xpb = // Error:
variable `castfunc.main.xpb` only parameters or `foreach`
declarations can be `ref`
}
alias RefFuncT = ref int function(return ref int a);
or
alias RefFuncT = typeof();
then
RefFuncT xpb =
or you can skip that and do
typeof() xpb =
P.S. next time this sort of question would be more appropriate in
the the Learn forum
Re: Declaring a pointer to a function returning a ref
On Tuesday, 31 July 2018 at 21:29:26 UTC, Jean-Louis Leroy wrote:
How do I declare a variable that contains a pointer to a
function returning a reference?
import std.stdio;
int foo(return ref int a)
{
a = 42;
return a;
}
ref int bar(return ref int a)
{
a = 42;
return a;
}
void main()
{
int x;
auto apf =
writeln(typeid(apf)); // int function(return ref int)*
int function(return ref int) xpf =
auto apb =
writeln(typeid(apb)); // int function(return ref int) ref*
// int function(return ref int) ref xpb = // Error:
no identifier for declarator `int function(return ref int)`
// ref int function(return ref int) xpb = // Error:
variable `castfunc.main.xpb` only parameters or `foreach`
declarations can be `ref`
}
I know I could use `typeof() xpb = ` but I wonder if
there is an explicit syntax.
Re: string literal string and immutable(char)* overload ambiguity
In the C++ language, programmers or the users have to face any kind of problems like mutable or immutable objects in the String category. The problem actually arises due to the ambiguity. You may take a suggestion from https://mailhelp.net/gmail-support/ that will help you to resolve such a problem.
Declaring a pointer to a function returning a ref
How do I declare a variable that contains a pointer to a function
returning a reference?
import std.stdio;
int foo(return ref int a)
{
a = 42;
return a;
}
ref int bar(return ref int a)
{
a = 42;
return a;
}
void main()
{
int x;
auto apf =
writeln(typeid(apf)); // int function(return ref int)*
int function(return ref int) xpf =
auto apb =
writeln(typeid(apb)); // int function(return ref int) ref*
// int function(return ref int) ref xpb = // Error: no
identifier for declarator `int function(return ref int)`
// ref int function(return ref int) xpb = // Error:
variable `castfunc.main.xpb` only parameters or `foreach`
declarations can be `ref`
}
Re: How to get an inout constructor working with a template wrapper
On Tuesday, 31 July 2018 at 12:37:34 UTC, Steven Schveighoffer wrote: On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); -Steve Ok bear with me, but I'm really confused why "wrap!int(immutable(int)(3))" is "correct". This all seems very inconsistent: 1. wrap!(int)(3); // ok 2. wrap!(const int)(3); // ok 3. wrap!(immutable int)(3); // nope 4. wrap!(int)(3); // ok 5. wrap!(const int)(const(int)(3)); // ok 6. wrap!(immutable int)(immutable(int)(3)); // ok! So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? But then what does it see in number 6, which works fine? And why is 2 ok if 3 is not? And finally, why can't the compiler leave the inout there and then it doesn't need to complain about it? Cheers, - Ali
Re: Moving druntime into the DMD repository
On 7/31/18 4:48 PM, Seb wrote: On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: On 7/31/18 2:24 PM, Walter Bright wrote: Since DMD and Druntime require each other, it is the right thing to do. I think this is an incorrect relationship. DMD does NOT require Druntime, *testing* DMD requires Druntime. Well DMD ships just happens to ship with Druntime ;-) What I mean is that one can build and use DMD without druntime (see Mike Franklin's project from 2013). The test suite requires it because we are testing the interactions between the DMD binary and the runtime that it uses. This whole thread is really about testing. In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime. That's only partially true. Even with -betterC, `object.d` will still be imported by default and actually many language features that work in -betterC will be lowered to druntime (even in betterC): One simple example: https://run.dlang.io/is/41vvoO True, you can probably say that most of object.d belongs to the compiler. I wouldn't have any problem moving that. As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent. On the contrary, DMD will depend more and more on druntime as the magic is now in druntime and not in the dmd source code. Not really. There is a confusion here about what is a dependency, and what is the interface. The agreed-upon interface between compiler and runtime is really the only thing that requires careful updates and breaks the CI. As long as the rest is independent, it can be done on one side or the other. What I meant by the statement above is, the runtime is going to be deciding more of what actually happens instead of the compiler. When these decisions are moved out of the compiler and into the runtime (in the form of templates), the compiler becomes more streamlined and less crowded with "code generating code". The hooks become simpler and naturally more stable, because the place where you "play with" the functionality is in the library. This means you need to change those hooks less often, and breaking projects becomes less common. A glaring example is the AA library. If the compiler simply lowered any Value[Key] to AssociativeArray!(Key, Value), and let the runtime define *everything*, when would you have to change the compiler again after that? But of course, until then, the compiler and AA runtime have to be altered in lock-step. In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones. Yes and no. Whenever you want to update a library hooks (which are implementation-defined and not part of the specification), it's rather complicated to do with keeping all CIs happy. Yes, exactly my point! The removal of magic means removal of the complicated hooks. If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Good idea! I think object.d can probably go to the compiler, but some stuff in there should probably be moved into a druntime-specific module. I'd have to look more deeply at the rt package to see what makes sense, but everything else should stay in druntime (core, gc). -Steve
Re: When did gdc and ldc start?
On Tuesday, 31 July 2018 at 20:52:03 UTC, Iain Buclaw wrote: Site is no more, but you can grab the sources from the internet archive. https://web.archive.org/web/20180329114817/http://www.opend.org I was correct in my remembering, it has its own backend that writes i386 assembly. Iain The author has possibly passed away on May 3 : https://necrocanada.com/obituaries-2018/burton-radons-2018/
Re: Small program producing binary with large filesize
On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote: Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks! If you use LDC, release build and their full LTO (-flto=full), the resulting binary should get smaller. DFLAGS="-flto=full" dub build --compiler=ldc -b release As an example, dlang-tour is 53M in debug build with DMD, but with LTO + release + ldc it gets down to 6.2M. You also get a smaller build, if instead of using all of Vibe.d, you only use the subset of components you actually use, e.g. dependency "vibe-d:web" version="~>0.8"
Re: When did gdc and ldc start?
On 31 July 2018 at 21:07, Iain Buclaw wrote: > On 31 July 2018 at 20:40, Walter Bright via Digitalmars-d > wrote: >> What's the difference between: >> >> DLI >> GDMD >> DGCC >> >> ? > > DLI: From what I recall, an independent project that just simply > ported DMD front-end to Linux. I don't remember the details how but > it had its own backend. Site is no more, but you can grab the sources from the internet archive. https://web.archive.org/web/20180329114817/http://www.opend.org I was correct in my remembering, it has its own backend that writes i386 assembly. Iain
Re: Moving druntime into the DMD repository
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: On 7/31/18 2:24 PM, Walter Bright wrote: Since DMD and Druntime require each other, it is the right thing to do. I think this is an incorrect relationship. DMD does NOT require Druntime, *testing* DMD requires Druntime. Well DMD ships just happens to ship with Druntime ;-) In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime. That's only partially true. Even with -betterC, `object.d` will still be imported by default and actually many language features that work in -betterC will be lowered to druntime (even in betterC): One simple example: https://run.dlang.io/is/41vvoO As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent. On the contrary, DMD will depend more and more on druntime as the magic is now in druntime and not in the dmd source code. In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones. Yes and no. Whenever you want to update a library hooks (which are implementation-defined and not part of the specification), it's rather complicated to do with keeping all CIs happy. If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Good idea!
Re: Where is TypeInfo_Class.m_init set
Sorry, scratch that, I forgot the `extern` before the dummy
global. After fixing that, I didn't quickly find a solution for
referencing the symbol in the .data.rel.ro section (LLVM asm,
e.g., `void* getInit() { return __asm!(void*)("movq
test.C.__init, %rax", "={rax}"); }` doesn't work either).
The compiler could emit the init symbol as regular global for
`-betterC` though.
---
This issue could also be tackled in the D ctor of the extern(C++)
class, by injecting the blit before the actual ctor body. C++
code wouldn't have to take care about that D-interop
incompatibility anymore (independent of -betterC).
Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On 7/30/18 2:30 PM, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type unless B
specifically disables certain features, but it seems weird that
disabling one opAssign disables all of them inside the aliases type but
not in the aliasing type?
struct A {
void opAssign(int) {}
}
struct B {
A a;
alias a this;
@disable void opAssign(float);
}
void main() {
B b;
b = 3;
}
Error: function `onlineapp.B.opAssign` is not callable because it is
annotated with @disable
OK, so one thing to learn in D, you can't hijack stuff. When you
override a function, you have to override ALL the overloads.
What you have done is defined opAssign as ONLY accepting a float, and
then disabling any calls to it.
This is obfuscated somewhat by the fact that 3 can be a float as well.
So even if you didn't disable the opAssign(float), it would still call
that function.
You can get around it by defining a forwarding function for the
overloads you want to let through:
@disable void opAssign(float);
auto opAssign(int x) { return a.opAssign(x); }
-Steve
[Issue 19130] Disabling opAssign in aliasing struct hides all opAssigns in subtyped alias
https://issues.dlang.org/show_bug.cgi?id=19130
Steven Schveighoffer changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||schvei...@yahoo.com
Resolution|--- |INVALID
--- Comment #1 from Steven Schveighoffer ---
Works as designed. As I mentioned in the forum thread, when you override one
overload of a base function, you override them all. With classes, you can alias
in the base class definitions of the function, but with alias this, that is not
an option (there will be a `this` type mismatch).
The workaround is to forward the other overloads back to the base.
e.g.:
auto opAssign(int x) { return a.opAssign(x); }
--
Re: SAoC Updates
On Tuesday, 31 July 2018 at 13:50:52 UTC, Mike Parker wrote: On Tuesday, 31 July 2018 at 13:36:13 UTC, bachmeier wrote: On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions. That's precisely why I mention it. We expect that applicants to take the necessary steps to verify there are no issues *before* applying. If, during the application process, it is discovered that there are potential issues, that's grounds for an automatic rejection. We do have access to a legal team, so there will be a certain level of due diligence where required. Would it be easier to submit a approved conflict of interest paper with the application? -Alexander
Re: Is there any hope for "lazy" and @nogc?
On 07/31/2018 09:17 AM, Shachar Shemesh wrote:
I'm trying to figure out what's the signature of the built-in assert. It
does not seem that I can define a similar function myself.
Looks like you can do it with a "lazy variadic function" [1], but it's
not pretty:
alias Dg = string delegate() @nogc nothrow;
void myAssert(bool cond, Dg[1] msg_dg ...) @nogc nothrow
{
import core.stdc.stdio;
if (!cond)
{
string msg = msg_dg[0]();
printf("%*s\n", msg.length, msg.ptr);
}
}
[1] https://dlang.org/spec/function.html#lazy_variadic_functions
Re: Moving druntime into the DMD repository
On 7/31/18 2:24 PM, Walter Bright wrote: On 7/27/2018 4:03 AM, Seb wrote: This a thread to explore whether it would be feasible to do so. Since DMD and Druntime require each other, it is the right thing to do. I think this is an incorrect relationship. DMD does NOT require Druntime, *testing* DMD requires Druntime. In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime. As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent. In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones. If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. -Steve
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: This a thread to explore whether it would be feasible to do so. Motivation -- [...] Druntime is not exclusively DMD. For example when porting to other platforms or cruntimes is already hard because of the sync and merge you need to do when you move your changes upstream. Most of the time those changes have nothing to do with dmd. Having dmd source internwined with druntime will make things even harder. Better find a solution on the CI server side rather then merge dmd with druntime.
Re: A vibe.d thing
On 7/31/18 1:22 PM, Russel Winder wrote: I have posted issue 2194 on the Vibe.d GitHub issues. https://github.com/vibe-d/vibe.d/issues/2194 Thanks, that should be good enough to figure out the bug in either your code or vibe.d -Steve
Re: Small program producing binary with large filesize
On 7/31/18 11:19 AM, Dan Barbarito wrote: Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks! D is statically linked, so the file size includes ALL the libraries (except for the C dynamic ones). Comparing this to C binaries, which are generally only linked dynamically, you will see much larger sizes. -Steve
Re: GDC talk at GNU Cauldron 2018
On Tuesday, 31 July 2018 at 08:47:21 UTC, Iain Buclaw wrote: Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. Apologies if this is old news. https://gcc.gnu.org/wiki/cauldron2018 It's happening in Manchester UK, and attendance is free (just send an email ahead of time to register your participation). Just in case anyone else is interested in coming along, or is nearby. Walter & Andrei, Getting D into GCC would be a huge deal in my opinion. Perhaps one of you could join Iain in this GCC meeting (the main annual event I think) to push the case? Regards Dibyendu
Re: When did gdc and ldc start?
On 31 July 2018 at 20:40, Walter Bright via Digitalmars-d wrote: > What's the difference between: > > DLI > GDMD > DGCC > > ? DLI: From what I recall, an independent project that just simply ported DMD front-end to Linux. I don't remember the details how but it had its own backend. GDMD: One failed attempt at getting a GCC back-end working with DMD. DGCC: The first successful GCC based compiler, to which GDC is derived from. You could call DGCC the LUCA of GDC (https://en.wikipedia.org/wiki/Last_universal_common_ancestor :-) Iain
Re: GDC talk at GNU Cauldron 2018
On 31 July 2018 at 20:39, Dibyendu Majumdar via Digitalmars-d wrote: > On Tuesday, 31 July 2018 at 08:47:21 UTC, Iain Buclaw wrote: >>> >>> Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. >>> Apologies if this is old news. >>> >>> https://gcc.gnu.org/wiki/cauldron2018 > > >> It's happening in Manchester UK, and attendance is free (just send an >> email ahead of time to register your participation). Just in case anyone >> else is interested in coming along, or is nearby. >> > > It wasn't clear to me from the schedule what date your talk is - is that to > be decided? > > Regards > Dibyendu > Its to be decided as far as I'm still aware. Iain.
Re: When did gdc and ldc start?
What's the difference between: DLI GDMD DGCC ?
Re: GDC talk at GNU Cauldron 2018
On Tuesday, 31 July 2018 at 08:47:21 UTC, Iain Buclaw wrote: Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. Apologies if this is old news. https://gcc.gnu.org/wiki/cauldron2018 It's happening in Manchester UK, and attendance is free (just send an email ahead of time to register your participation). Just in case anyone else is interested in coming along, or is nearby. It wasn't clear to me from the schedule what date your talk is - is that to be decided? Regards Dibyendu
Re: Moving druntime into the DMD repository
On 7/27/2018 4:03 AM, Seb wrote: This a thread to explore whether it would be feasible to do so. Since DMD and Druntime require each other, it is the right thing to do.
Re: When did gdc and ldc start?
Mike and Iain - yay, this is just what I was looking for. Thanks! What I'm doing is preparing a submission to HOPL on the origins of D. There's an emphasis on accuracy, references, correct dates, correct attributions, and correct credit to the right people. There'll be more questions from me :-)
[Issue 19107] -de produces compilation error, -dw does not
https://issues.dlang.org/show_bug.cgi?id=19107 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/305f34e3ba8a46ba81e55c968c1da0f06fe3fe9e Fix Issue 19107 - -de produces compilation error, -dw does not https://github.com/dlang/dmd/commit/03e7693150c453055b098768e59ebd31cb3ca52e Merge pull request #8519 from JinShil/fix_19107 Fix Issue 19107 - -de produces compilation error, -dw does not --
[Issue 19107] -de produces compilation error, -dw does not
https://issues.dlang.org/show_bug.cgi?id=19107 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: A vibe.d thing
I have posted issue 2194 on the Vibe.d GitHub issues. https://github.com/vibe-d/vibe.d/issues/2194 -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 01:16:29 UTC, Hakan Aras wrote: I was hoping it would be possible without tinkering with the compiler, but it doesn't seem to be the case. I've been playing around with LDC. There is an init symbol for classes, which is normally used as payload for the ClassInfo's m_init. I haven't been able to get its correct address though (I don't know enough about relocations), but it looks as if it could be gotten to work this way, see https://run.dlang.io/is/ZLDCpZ. Remove `-betterC` to see the address discrepancy causing the segfault, something like: init: 0x55dd229dc810 actual: 0x55dd229d3cf0
Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
On Tuesday, 31 July 2018 at 10:09:08 UTC, Jacob Carlborg wrote: Shouldn't be any conflict because the "betterC" symbol would be in a different module. ... I would say, if it's only for internal use then it can be placed in `std.internal` with the `package` protection. If you want this to be used outside of Phobos then I recommend putting it in `core.attribute` in druntime, since that already exists. Cool! std.internal.attributes and @betterC it is then: https://github.com/dlang/phobos/pull/6645 This should allow to gradually annotate more unittests in Phobos with @betterC (like we did with @safe or @nogc), and allow us to gradually increase the -betterC subset.
Re: A vibe.d thing
On Tue, 2018-07-31 at 11:54 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > > Understandable. I actually don't think you ever posted the real > message > that comes out, just a link to the source code, from which I found > it > wasn't obeying the mode variable. > > But now, it looks like it should be obeying the variable, yet you get > an > execption. Knowing what the actual message is would be helpful, at > least > for filing a bug or fixing it. Separate from the CVu Code Critique 112 stuff, I'll see if I can create a suitable test case to try and provide details. It seems like the right thing to do in the circumstances. :-) I guess I should post an issue on the vibe.d GitHub mainline repository rather than post things here. […] > What I mean is, I can't see why it would be throwing an exception > when > you supply the IOMode.once. But possibly if there is a timeout, it > might > be doing that. > > Or maybe there is another issue. Hopefully the actual exception message can reveal the truth! -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 2018-07-31 10:12, Manu wrote: > > > Given your favourite example: > > > > module a; > > extern(C++, ns) void foo(); > > > > module b; > > extern(C++, ns) void foo(); > > - > > module c; > > import a, b; > > foo(); // error: ambiguous > > ns.foo(); // error, ambiguous (obviously) > > a.ns.foo(); // naturally, this works... it's the D module that > > correctly organises the symbol. 'ns' is worthless here > > This works: > > a.foo(); > > You don't need "ns" in between the module name and the function. > Right... But did you miss the point? The D module does the organisation (as you show). The ns offers nothing and creates other kinds of problems. Just because name resolution traverses the namespace (in simple cases), there is an entire language of complexity that interacts with that name lookup, and as far as I know, it has never proven useful, but rather, only complicated and annoying leading to boilerplate and hacks in certain situations. (ie, this thread exists and many others)
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 03:42:15 UTC, Mike Franklin wrote: I would also like to be able to use `extern(C++)` classes without the runtime, but I haven't been able to allocate any time to it yet. If you're trying to use `extern(C++)` classes with betterC, and the compiler is complaining about `TypeInfo` give me an example illustrating the problem, and I might be able to submit a fix to the compiler. Mike It's working fine so far. Only problem is that the class needs to be compiletime constructible to get the initializer.
Re: A vibe.d thing
On 7/31/18 11:20 AM, Russel Winder wrote: On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] Hm.. it appears that there is a timeout exception thrown if there is no data within a certain time period. Are you getting that instead? To be honest, I am not sure. From a "I haven't looked at the library source, it's just a black box" all I can say is that if the buffer is 256 and there are >256 ubytes left the function returns but if there are <256 ubytes left an exception is thrown. I haven't checked the type of the exception or the exception message. Basically I got too annoyed that the documentation was sensible and the implementation wasn't meeting the documentation, I lost interest. Understandable. I actually don't think you ever posted the real message that comes out, just a link to the source code, from which I found it wasn't obeying the mode variable. But now, it looks like it should be obeying the variable, yet you get an execption. Knowing what the actual message is would be helpful, at least for filing a bug or fixing it. I'm not completely familiar with the mechanisms here, but it does appear to obey the other modes properly in this iteration of the library. I tried IOMode.all and IOMode.once but they both appeared to behave the same. I can't remember trying IOMode.immediate. What I mean is, I can't see why it would be throwing an exception when you supply the IOMode.once. But possibly if there is a timeout, it might be doing that. Or maybe there is another issue. -Steve
Re: A vibe.d thing
On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > Hm.. it appears that there is a timeout exception thrown if there is > no > data within a certain time period. Are you getting that instead? To be honest, I am not sure. From a "I haven't looked at the library source, it's just a black box" all I can say is that if the buffer is 256 and there are >256 ubytes left the function returns but if there are <256 ubytes left an exception is thrown. I haven't checked the type of the exception or the exception message. Basically I got too annoyed that the documentation was sensible and the implementation wasn't meeting the documentation, I lost interest. > I'm not completely familiar with the mechanisms here, but it does > appear > to obey the other modes properly in this iteration of the library. I tried IOMode.all and IOMode.once but they both appeared to behave the same. I can't remember trying IOMode.immediate. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Small program producing binary with large filesize
Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks!
Re: Is there any hope for "lazy" and @nogc?
On 7/31/18 3:17 AM, Shachar Shemesh wrote: I'm trying to figure out what's the signature of the built-in assert. It does not seem that I can define a similar function myself. First attempt: void myAssert(bool cond, string msg) @nogc nothrow; No, because msg gets evaluated unconditionally. void myAssert(bool cond, lazy string msg) @nogc nothrow; test.d(8): Error: @nogc function test.myAssert cannot call non-@nogc delegate msg Hm... I would say compiler should be smart enough to know that lazy string messages that are not @nogc shouldn't be able to be passed in here. e.g.: myAssert(a == b, "a and b should be equal); // ok myAssert(a == b, a.name ~ " and " ~ b.name ~ " should be equal"); // error It appears that lazy is not inferring anything, it's strictly transformed into a normal delegate. I'd say at least the template solution should be made to work. -Steve
Re: string literal string and immutable(char)* overload ambiguity
On 7/31/18 10:13 AM, Nicholas Wilson wrote:
is there any particular reason why
void foo(string a) {}
void foo(immutable(char)* b) {}
void bar()
{
foo("baz");
}
result in
Error: foo called with argument types (string) matches both:
foo(string a)
and:
foo(immutable(char)* b)
especially given the pointer overload is almost always
void foo(immutable(char)* b)
{
foo(b[0 .. strlen(b)]);
}
and if I really want to call the pointer variant I can with
foo("baz".ptr);
but I can't call the string overload with a literal without creating a
temp.
I think we should make string literals prefer string arguments.
Absolutely, I didn't realize this was an ambiguity. It should be the
same as foo(long) vs. foo(int) with foo(1).
-Steve
Re: Linking to dynamic druntime with dub
On 01/08/2018 2:18 AM, Nicholas Wilson wrote: On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub). No idea for dmd/gdc. But for LDC that would be (json): "dflags-ldc2": ["-link-defaultlib-shared"],
Re: Linking to dynamic druntime with dub
On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub).
string literal string and immutable(char)* overload ambiguity
is there any particular reason why
void foo(string a) {}
void foo(immutable(char)* b) {}
void bar()
{
foo("baz");
}
result in
Error: foo called with argument types (string) matches both:
foo(string a)
and:
foo(immutable(char)* b)
especially given the pointer overload is almost always
void foo(immutable(char)* b)
{
foo(b[0 .. strlen(b)]);
}
and if I really want to call the pointer variant I can with
foo("baz".ptr);
but I can't call the string overload with a literal without
creating a temp.
I think we should make string literals prefer string arguments.
Re: Is there any hope for "lazy" and @nogc?
On Tuesday, 31 July 2018 at 07:49:40 UTC, Shachar Shemesh wrote: On 31/07/18 10:29, Mike Franklin wrote: Please clarify if I'm missing the point. You are. I want something along the lines of: assertEQ(a, b, "a and b are not equal"); When run, it would issue an assert that says: Assertion failed: 3!=7: a and b are not equal You could also vote for this PR (https://github.com/dlang/dmd/pull/8517) - this PR will generate such error messages. It's intended to work in -betterC and @nogc (once the PR is ready).
Re: Linking to dynamic druntime with dub
On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags".
Re: SAoC Updates
On Tuesday, 31 July 2018 at 13:36:13 UTC, bachmeier wrote: On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions. That's precisely why I mention it. We expect that applicants to take the necessary steps to verify there are no issues *before* applying. If, during the application process, it is discovered that there are potential issues, that's grounds for an automatic rejection. We do have access to a legal team, so there will be a certain level of due diligence where required.
Linking to dynamic druntime with dub
My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub?
Re: SAoC Updates
On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions.
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Tuesday, 31 July 2018 at 12:02:55 UTC, Kagamin wrote: On Saturday, 28 July 2018 at 19:55:56 UTC, bpr wrote: Are the Mozilla engineers behind it deluded in that they eschew GC and exceptions? I doubt it. They are trying to outcompete Chrome in bugs too. You're not Mozilla. And why you mention exceptions, but not bounds checking? Firefox has been complete garbage on my work computer ever since the Quantum update. Works fine at home though.
Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 21:49:12 UTC, Dibyendu Majumdar wrote: https://sqlite.org/whyc.html Personally I think D team should try to convince some well known project to switch from C to D. Not many projects are written in C these days though ... but SQLite is amongst the few. The C language is old and boring. It is a well-known and well-understood language. If C is so well-understood, why we have all these buffer overflows?
Re: A vibe.d thing
On 7/31/18 7:49 AM, Russel Winder wrote: On Tue, 2018-07-31 at 13:10 +0200, Daniel Kozak via Digitalmars-d-learn wrote: On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via Digitalmars-d-learn wrote: Maybe IOMode.immediate or .once? https://vibed.org/api/eventcore.driver/IOMode Oh, it looks like you specified once. Hm... that seems to me like it should work. Looks like IOMode is ignored: https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa 8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. It is implemented with vibe-core driver which should be default now https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9 f4a34/source/vibe/core/net.d#L665 Sadly as of vibe.d 0.8.4 the behaviour of read(buffer, IOMode) is to either fill the buffer completely or throw an exception. On the forum, Sönke has agreed it really does seem like a bug in the implementation. I found a workaround to the problem for my entry to CVu Code Critique 112, which actually is nicer code to the one that highlighted the problem – except that it relies on a property that has been marked deprecated. Deadline for entries is tomorrow, so I am not now in a position to change the article, it has to appear as it is now. Obviously once published, people are most welcome to write an article for CVu reporting how naïve/crap my code is, and providing better answers. Hm.. it appears that there is a timeout exception thrown if there is no data within a certain time period. Are you getting that instead? I'm not completely familiar with the mechanisms here, but it does appear to obey the other modes properly in this iteration of the library. -Steve
Re: How to get an inout constructor working with a template wrapper
On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); -Steve
Re: append uninitialized elements to array
On 7/30/18 5:10 PM, Ali Çehreli wrote:
On 07/30/2018 10:40 AM, realhet wrote:
Hello,
I've already found out how to create an array with uninitialized
elements, but what I'm looking for is a way to append 16 uninitialized
ushorts to it and after I will it directly from 2 SSE registers.
The approximate array length is known at the start so I could be able
to do this by making an uninitializedArray and then doing the
appending manually, but I wonder if there is a way to do this with
array.reserve().
Basically it would be a thing that when this special uninitialized
append is happening and when the reserved array size is big enough, it
only increments the internal array length effectively.
Thanks
Knowing that the length of a slice is its first member:
void appendUninitialized(T)(ref T[] arr, size_t N = 1) {
arr.reserve(arr.length + N);
auto length_p = cast(size_t*)();
*length_p += N;
Instead of above 2 lines:
arr = arr.ptr[0 .. arr.length + N];
}
unittest {
ushort[] arr;
arr.appendUninitialized(2);
assert(arr.length == 2);
arr[0] = 1;
arr[1] = 2;
assert(arr == [ 1, 2 ]);
}
void main() {
int[] arr;
arr.appendUninitialized(100);
import std.stdio : writeln;
writeln(arr);
}
Ali
While this may work, it's unsafe. reserve reserves the space, but does
not adjust the allocated length. You have the potential for overwriting
data if you do this. I wouldn't recommend this method, especially if you
aren't sure of the source of array. The resulting array is also not
going to be appendable (it will reallocate on next append, even using
appendUninitialized).
-Steve
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 19:55:56 UTC, bpr wrote: Are the Mozilla engineers behind it deluded in that they eschew GC and exceptions? I doubt it. They are trying to outcompete Chrome in bugs too. You're not Mozilla. And why you mention exceptions, but not bounds checking? Here we kind of agree. If D is going to support a GC, I want a state of the art precise GC like Go has. Go GC is far from being a state of the art, it trades everything for low latency and ease of configuration.
Re: A vibe.d thing
On Tue, 2018-07-31 at 13:10 +0200, Daniel Kozak via Digitalmars-d-learn wrote: > On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via > Digitalmars-d-learn wrote: > > > > > > > Maybe IOMode.immediate or .once? > > > https://vibed.org/api/eventcore.driver/IOMode > > > > Oh, it looks like you specified once. Hm... that seems to me like it > > should work. > > > > Looks like IOMode is ignored: > > > > > > https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa > > 8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > > > So, no, there isn't a correct way to do this, it's unimplemented. > > > > -Steve > > > > It is implemented with vibe-core driver which should be default now > https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9 > f4a34/source/vibe/core/net.d#L665 Sadly as of vibe.d 0.8.4 the behaviour of read(buffer, IOMode) is to either fill the buffer completely or throw an exception. On the forum, Sönke has agreed it really does seem like a bug in the implementation. I found a workaround to the problem for my entry to CVu Code Critique 112, which actually is nicer code to the one that highlighted the problem – except that it relies on a property that has been marked deprecated. Deadline for entries is tomorrow, so I am not now in a position to change the article, it has to appear as it is now. Obviously once published, people are most welcome to write an article for CVu reporting how naïve/crap my code is, and providing better answers. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blogpost about parallelizing Datacat with std.parallelism
On Thursday, 26 July 2018 at 20:29:56 UTC, ikod wrote: On Thursday, 26 July 2018 at 12:13:01 UTC, Joakim Brännström wrote: Hello, I've written up a blog post[0] of my explorations when parallelizing Datacat[1]. Thanks for nice article. Just in case if you never tried this: https://bitbucket.org/andrewtrotman/d-profile-viewer https://bytebucket.org/andrewtrotman/d-profile-viewer/raw/277a7eff16a2b1ffab656d0c6d76a718e8076745/images/OneMethod.png those function names look interesting :)
Re: A vibe.d thing
On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via Digitalmars-d-learn wrote: > > > > Maybe IOMode.immediate or .once? > > https://vibed.org/api/eventcore.driver/IOMode > > Oh, it looks like you specified once. Hm... that seems to me like it > should work. > > Looks like IOMode is ignored: > > > https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > So, no, there isn't a correct way to do this, it's unimplemented. > > -Steve > It is implemented with vibe-core driver which should be default now https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9f4a34/source/vibe/core/net.d#L665
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Tuesday, 31 July 2018 at 09:09:11 UTC, Nicholas Wilson wrote: [snip] Also I'm working on a D kernel for Jupyter notebook which should be done soon. Excellent.
Re: Is there any hope for "lazy" and @nogc?
On 2018-07-31 09:17, Shachar Shemesh wrote:
I'm trying to figure out what's the signature of the built-in assert. It
does not seem that I can define a similar function myself.
First attempt:
void myAssert(bool cond, string msg) @nogc nothrow;
No, because msg gets evaluated unconditionally.
void myAssert(bool cond, lazy string msg) @nogc nothrow;
test.d(8): Error: @nogc function test.myAssert cannot call non-@nogc
delegate msg
void myAssert(bool cond, lazy string msg @nogc nothrow ) @nogc nothrow;
test.d(4): Error: found @ when expecting )
test.d(4): Error: semicolon expected following function declaration
test.d(4): Error: no identifier for declarator nogc
test.d(4): Error: declaration expected, not )
test.d(9): Error: unrecognized declaration
Templates to the rescue!!!
void myAssert(STR)(bool cond, lazy STR msg );
test.d(14): Error: @nogc function D main cannot call non-@nogc function
test.myAssert!string.myAssert
It seems this is a limitation in the syntax. It works with an explicit
delegate, but then that is required at the call site as well. A lazy
parameter is basically just a delegate with a nicer syntax.
void myAssert(bool cond, string delegate() @nogc nothrow msg) @nogc nothrow
{
auto a = msg();
}
Support for adding UDAs to function parameters was recently added.
Perhaps we need to support other attributes as well.
Please report an issue to http://issues.dlang.org.
--
/Jacob Carlborg
Re: On D in competitive programming
On Tuesday, 31 July 2018 at 00:52:22 UTC, 9il wrote: Are competitors allowed to use mir-algorithm and mir-random? The libraries can be used for graphs (Tarjan algorithm), matrices/tensors, nd-iteration, RNGs, interpolation, and distributions? Sadly, no: most of the time, language compilers on the server side are provided as they are out-of-the-box. I'll try to explain why. When a language is added to a competition, one of the goals for the organizers is to keep the whole thing fair. Different languages have different pros and cons already as they are, and what is an implementation-heavy problem for one language is solved in a couple lines with another. So, the availability of several programming languages already puts some burden on the problemsetters: at least for important competitions, they have to come up with problems which don't play too much into the strengths of any particular language, and that means knowing what to generally expect of all the languages. For example, most problems don't rely on number crunching with integers above 64 bits, since C++ is notoriously lacking in this regard. This all gets a new dimension if a platform decides to supply additional libraries. Once it's done for one language, there are no clear boundaries: if we get mir-algorithm for D, we will have to at least install Boost for C++, and numpy for Python, and the users of other languages also ask for their favourite libraries, which are in turn more powerful than Boost, and so on. And it would take significant expertise to balance such requests so that no language has too much of an unfair advantage or disadvantage. It takes a bit of expertise too to keep the libraries in all languages working and up-to-date. All the way, the problemsetters now have to avoid a different set of topics, changing with new libraries being added. Yet another factor is that there are central competitions perceived as the most important, which are currently ACM ICPC World Finals for university teams, and their regional contests. Many platforms strive to act as training grounds for the important competitions. So when the World Finals, which are understandably conservative, don't do X, it's a disincentive to do X for the training grounds too. So, the default approach is to keep each language at a bare minimum. It would be nice to have this feature, as mir-algorithm can be a good default library for competitive programming. Plus competitors can add additional graph algorithms. It may still be reasonable to ask for additional libraries on the platforms where the focus is not some big competition: e.g., perhaps no for ACM ICPC archives, perhaps yes for interview training sites. For a particular platform and a particular cause (e.g., a training course for a learning platform), it's entirely possible to have D with mir-algorithm installed on the platform. Ivan Kazmenko.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 2018-07-31 10:12, Manu wrote: Given your favourite example: module a; extern(C++, ns) void foo(); module b; extern(C++, ns) void foo(); - module c; import a, b; foo(); // error: ambiguous ns.foo(); // error, ambiguous (obviously) a.ns.foo(); // naturally, this works... it's the D module that correctly organises the symbol. 'ns' is worthless here This works: a.foo(); You don't need "ns" in between the module name and the function. -- /Jacob Carlborg
Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
On 2018-07-29 16:21, Seb wrote:
Phobos has recently gotten a primitive way to run betterC tests
(https://github.com/dlang/phobos/pull/6640).
Now, it would be really cool if we can annotate existing tests with e.g.
`@betterCTest` and thus ensure that those tests work with -betterC (i.e.
extract them and run them with a minimal test runner.
a) @betterC
Probably too popular and would lead to too many conflicts.
Shouldn't be any conflict because the "betterC" symbol would be in a
different module.
b) @TestBetterC
c) @betterCTest || @bettercTest
Would probably be defined a enum somewhere in `std.internal`
d) @("betterC")
A bit ugly and harder to work with. If we ever want to name the
unittests in Phobos, this will make it harder.
I really hate that this is possible to do with UDAs. We should avoid
this as much as possible.
At some point we might also want to test whether something runs even
without any runtime (https://github.com/dlang/phobos/pull/6641), so e.g.
`@baremetalTest` might be defined too.
My favorite is (c) - any objections?
See also: https://github.com/dlang/tools/pull/357 (implementation of the
test extraction filter for UDAs)
I would say, if it's only for internal use then it can be placed in
`std.internal` with the `package` protection. If you want this to be
used outside of Phobos then I recommend putting it in `core.attribute`
in druntime, since that already exists.
--
/Jacob Carlborg
Re: Moving druntime into the DMD repository
On 2018-07-27 13:03, Seb wrote: This a thread to explore whether it would be feasible to do so. Motivation -- DRuntime and DMD heavily depend on each other. It happens very often that a PR needs to touch both and then a complicated three-step (or sometimes four-step PR series) needs to be done to keep the CIs happy. Moreover, as the whole testsuite is at dmd, it happens more often that an error is caught in the testsuite, but would require a druntime PR or the opposite you make a PR to druntime and want its accompanying test to be checked by the CI. Another approach could be to separate the compiler dependent API, i.e. "rt" and the user facing API, i.e. "core". The "rt" API could be moved to the compiler repository while the user facing API could stay. -- /Jacob Carlborg
Re: How to best implement a DSL?
On 2018-07-28 16:59, Robert M. Münch wrote:
Hi, I'm seeking for ideas/comments/experiences how to best implement a
DSL in D.
What I would like to do is something like this:
... my D code ...
my-dsl {
... my multi-line DSL code ...
trade 100 shares(x) when (time < 20:00) and timingisright()
}
... my D code ...
Some things that circle in my head:
* Can the D parser somehow be missued for a DSL? So I can skip all the
generic features for types etc.?
Yes. But it would require your DSL to be syntactically valid D code (but
not semantically). DMD can be used as a library but is lacking quite a
bit i this regard. For example, you cannot get the original source code
from an AST node because the AST node only stores where in the source
code the node starts, not where it ends. Some AST nodes doesn't contain
location information at all. Also, unless you want to write the DSL in a
string literal you need to build some kind of pre-processor that
converts the DSL to valid D code.
--
/Jacob Carlborg
Re: A vibe.d thing
On 2018-07-27 21:02, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, FYI, it's possible to access the vibe.d forum through a news reader by using the following URL [1]. This is noted at the bottom of the forum [2]. [1] nntp://forum.rejectedsoftware.com/ [2] http://forum.rejectedsoftware.com -- /Jacob Carlborg
Re: Is there any hope for "lazy" and @nogc?
On Tuesday, 31 July 2018 at 07:49:40 UTC, Shachar Shemesh wrote: On 31/07/18 10:29, Mike Franklin wrote: Please clarify if I'm missing the point. You are. I want something along the lines of: assertEQ(a, b, "a and b are not equal"); When run, it would issue an assert that says: Assertion failed: 3!=7: a and b are not equal What D really needs is power asserts. assertEQ's and its companions (assertLT, assertLE, ...) feel just like hacks. Power asserts come from Groovy and look like this (http://groovy-lang.org/semantics.html#_power_assertion): assert calc(x,y) == [x,z].sum() || | | | | | 15 2 7 | 2 5 7 false A poorer version exists in C++ (https://www.boost.org/doc/libs/1_67_0/libs/test/doc/html/boost_test/testing_tools/boost_test_universal_macro.html) and of course any language with decent metaprogramming facilities can implement them as a library solution (such as Rust: https://github.com/gifnksm/power-assert-rs and Go: https://github.com/ToQoz/gopwt). If you can not go the route of metaprogramming, provide an assert backend (Javascript: https://github.com/power-assert-js/power-assert). D needs something like this as well, and you can not get there just with lazy.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state across.
Also I'm working on a D kernel for Jupyter notebook which should
be done soon.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 31 July 2018 at 08:33:52 UTC, Daniel N wrote:
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will
use that fork of D forever.
1. Look how it is mangled on the C++ side. (Use "grep" on the
object file.)
2. Use:
pragma(mangle, "the mangled name")
This doesn't work for templates. If it did I wouldn't have an
issue since libclang tells me what the mangling is.
What is the deal-breaker with templates? For simple functions
libclang + pragma seems the best option right now.
template fun()
{
pragma(mangle, "_ZN2ns3funEv")
extern(C++)
void fun() {}
}
mixin fun;
extern(C++) {
void foo(T)() {
}
}
It doesn't have a mangling until it has an instantiation. Even if
it were possible to know which exact instantitations the code
that imports this uses, there's no way I can declare the mangling
scheme to the D compiler.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 31 July 2018 at 08:33:52 UTC, Daniel N wrote:
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will
use that fork of D forever.
1. Look how it is mangled on the C++ side. (Use "grep" on the
object file.)
2. Use:
pragma(mangle, "the mangled name")
This doesn't work for templates. If it did I wouldn't have an
issue since libclang tells me what the mangling is.
What is the deal-breaker with templates? For simple functions
libclang + pragma seems the best option right now.
template fun()
{
pragma(mangle, "_ZN2ns3funEv")
extern(C++)
void fun() {}
}
mixin fun;
Your template doesn't have any template parameter. Bear in mind
mangling is dependent on the instance, not the declaration.
Once you add some template parameter, you need to mangle your
template parameter list, which you could *almost* reasonably do
with CTFE, but since you are on POSIX, you also got fun things
like components and template parameter substitution.
Example:
```
struct Array16479 (Arg) { Arg* data; }
Array16479!(FuncT2) func16479_4 (FuncT1, FuncT2) (FuncT1);
static assert(func16479_4!(int, float).mangleof
== `_Z11func16479_4IifE10Array16479IT0_ET_`);
```
As you see the return value (`Array16479IT0_E`) encode a
backreference to the symbol's template parameter: T0_ reference
the second template argument.
If you throw some more language features (e.g. aliases) you
quickly realize you need a full semantic analysis to get the
mangling right on templates.
More test cases/examples (and shameless self plug):
https://github.com/dlang/dmd/pull/8455/files
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 20:23:25 UTC, Walter Bright wrote:
On 7/30/2018 9:45 AM, Manu wrote:
Sure it 'works', but it's an annoying point of friction, and it
doesn't need to be that way.
You can reduce it to:
mixin(cppNamespace("ns", "void foo();"));
You haven't explained why you can't just move the namespace
ns declarations in
one file together.
Are you serious?
Yes, please explain why you can't coalesce the namespace
declarations in one C++ file into one namespace declaration.
Because one C++ file != one C++ translation unit. All of them
will #include other files and need the symbols in them, which,
for anything using namespaces (the standard library, boost, ...),
will mean several instances of opening and closing the same
namespace.
The only good way (I don't think the mixin template and struct
solutions count) to link to any of that today would be to have
one enormous D file with _everything_ in it, including nested
namespaces.
Re: GDC talk at GNU Cauldron 2018
On 30 July 2018 at 20:36, Dibyendu Majumdar via Digitalmars-d wrote: > Hi, > > Noticed that there is a GDC talk by Iain Buclaw at the GNU Cauldron 2018. > Apologies if this is old news. > > https://gcc.gnu.org/wiki/cauldron2018 > > Regards > Dibyendu > It's happening in Manchester UK, and attendance is free (just send an email ahead of time to register your participation). Just in case anyone else is interested in coming along, or is nearby. Iain
Re: Why does not UFCS work for method defined inside unittest block?
On Tuesday, 31 July 2018 at 08:28:01 UTC, Ky-Anh Huynh wrote:
Hi,
Can I define a new quick function to use inside a unittest
block?
I have the following code:
[code]
auto foo(string[] sta) {
return sta;
}
auto bar(string[] sta) {
return sta;
}
auto h(string[] sta) {
return sta.foo.bar;
}
unittest {
import std.format;
auto f = (string[] sta) => sta.foo.bar;
auto g(string[] sta) {
return sta.foo.bar;
}
assert(f(["test"]) == ["test"]);
assert(g(["test"]) == ["test"]);
assert(["test"].h == ["test"]);
assert(["test"].g == ["test"]);
}
[/code]
(Src:
https://gist.github.com/icy/64ec1838929d448d9f874d1e8261e56a)
The last test will fail: Error: no property g for type string[]
Please advise.
From https://dlang.org/spec/function.html#pseudo-member:
"A free function can be called with a syntax that looks as if the
function were a member function of its first parameter type."
A function defined in a function scope (which a unittest block
is), is not a free function, and so does not benefit from UFCS.
There is an explanation for why at the bottom of the above page:
"The reason why local symbols are not considered by UFCS, is to
avoid unexpected name conflicts."
If you need a function that's available for UFCS in a unittest
but is not there in a non-unittest context, use a version block:
version (unittest) {
auto fun(string[] s) { return s }
}
And if you need something with a context:
version (unittest) {
string delegate (string) test;
}
unittest {
string s1 = "foo";
test = s => s ~ s1;
"foo".test;
}
--
Simen
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 19:51:09 UTC, Walter Bright wrote:
On 7/30/2018 6:45 AM, Atila Neves wrote:
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope, not just a
mangling.
Should they, though?
They do in C++. That was the whole point of adding namespaces:
C:void ns_foo();
C++: namespace ns { void foo(); }
I meant "should they in D, though?". I don't want to import C++
semantics into D. I want D to correctly mangle C++ namespaced
functions and change nothing at all about overload resolution in
D.
Structs aren't namespaces, I wouldn't expect them to behave
the same.
From a language perspective, they are namespaces.
Technically, yes. But not C++ namespaces.
C++ has a lot of bizarre name lookup behavior.
It does. I don't think anyone is suggesting we copy it.
I didn't know about this and it makes things better, but it's
not a real solution to my problem.
See my other post doing this same thing with structs.
It's not the same - if I want to link to std::vector and
std::string, I'd expect them to be used in D as std.vector and
std.string, not std.vector and HackyDThing0.std.string.
I'm arguing that reopening should be allowed.
As detailed in another post, this opens a whole host of other
problems. Even in C++, what names are visible in a namespace at
any particular point in the compilation is a nebulous concept.
(It is actually carefully specified, but you have to be a
language lawyer / compiler implementer to know what they are -
to the user it is erratic, random, and nebulous.)
Right, but D doesn't have to do any of that - as far as D is
concerned it's just mangling. Well, as far as the typical D user
that writes `extern(C++)` anyway.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 31 July 2018 at 06:12:40 UTC, Walter Bright wrote: Thirdly, C and C++ are loaded to the gills with seemed-like-a-good-idea-at-the-time solutions that turned out to have bad unintended consequences that bork up the language for everyone down the line. D has some of those, too. And only experience can tell if those ideas turn out to be bad, as people make use of it and realize how (im)practical they are. We only got a handful known serious users of `extern (C++)` on Windows, and probably only me on POSIX (because anything templated doesn't mangle properly on POSIX, so the STL is unusable). So if all users come together to say that the current design seemed-like-a-good-idea-at-the-time (to you) but is not, and could be *simplified* to yield a better product, it sounds very backward to not listen to them.
Re: Why does not UFCS work for method defined inside unittest block?
dmd version that I'm using: $ dmd --version DMD64 D Compiler v2.081.1-dirty Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved written by Walter Bright
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will use
that fork of D forever.
1. Look how it is mangled on the C++ side. (Use "grep" on the
object file.)
2. Use:
pragma(mangle, "the mangled name")
This doesn't work for templates. If it did I wouldn't have an
issue since libclang tells me what the mangling is.
What is the deal-breaker with templates? For simple functions
libclang + pragma seems the best option right now.
template fun()
{
pragma(mangle, "_ZN2ns3funEv")
extern(C++)
void fun() {}
}
mixin fun;
Why does not UFCS work for method defined inside unittest block?
Hi,
Can I define a new quick function to use inside a unittest block?
I have the following code:
[code]
auto foo(string[] sta) {
return sta;
}
auto bar(string[] sta) {
return sta;
}
auto h(string[] sta) {
return sta.foo.bar;
}
unittest {
import std.format;
auto f = (string[] sta) => sta.foo.bar;
auto g(string[] sta) {
return sta.foo.bar;
}
assert(f(["test"]) == ["test"]);
assert(g(["test"]) == ["test"]);
assert(["test"].h == ["test"]);
assert(["test"].g == ["test"]);
}
[/code]
(Src:
https://gist.github.com/icy/64ec1838929d448d9f874d1e8261e56a)
The last test will fail: Error: no property g for type string[]
Please advise.
Thanks a lot.
Re: append uninitialized elements to array
Thank You!
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Mon, 30 Jul 2018 at 23:15, Walter Bright via Digitalmars-d wrote: > > My issue is you're presenting solutions. But I have no idea what the problem > is, > because every time I present a solution to the examples you give, you say it's > no good, because your problem is something else. I'm not asking for workarounds or 'solutions'. I know the workarounds very well, because I've been writing them repeatedly for years. I want to see this mistake corrected. It's not a case of "can't do the thing", this is a case of "i hate doing the thing (ie, workarounds), the results are particularly unsatisfying, and the whole basis for the problem is unfounded". We repeat it over and over. The case on trial today is that it can't be 'reopened', which is awkward in cases of generative programming (like Atila's case), and is a conversation that shouldn't even need to exist; a namespace given for mangling doesn't exhibit this issue. We can't specify some valid C++ namespace names that are D keywords. (also, 'std' is particularly annoying, since it conflicts with phobos) Other cases where it conflicts with itself when you import 2 modules with symbols spanning the same namespace, which is more common than not. The resolution is explicit disambiguation using the D module scope (which is the whole point of D modules), and so the C++ namespace scope is just redundant. Given your favourite example: module a; extern(C++, ns) void foo(); module b; extern(C++, ns) void foo(); - module c; import a, b; foo(); // error: ambiguous ns.foo(); // error, ambiguous (obviously) a.ns.foo(); // naturally, this works... it's the D module that correctly organises the symbol. 'ns' is worthless here Just like every other instance in D code ever where modules are used to organise symbols. I don't have to convince you that D modules work well... you need to convince us that D modules are insufficient. ns is just annoying complexity, and it interferes with other code. Atila's thing about 'reopening' namespaces is a non-issue if namespace was just for mangling. The whole class of problem ceases to exist. (I have been frustrated by this same problem too) Scanning meta doesn't have to learn to identify and recurse into C++ namespaces to traverse that edge case where a module has some C++ symbols. No scanning meta every written is equipped with that logic. There's no advantage to the ns scope, and it only brings challenges. None of any of our time ever needed to be wasted here. The feature as designed absolutely has not solved any form of problem. It has not saved more time than it's wasted, and it never will. Not to mention that it's ugly and leads to undesirable and unintuitive symbol names. When a C++ namespace spans modules (ie, the C++ namespace encloses the whole library's api), translation to D looks like this: module ns.submodule; extern(C++, ns) void foo(); The name is: ns.submodule.ns.foo(); // <- ns is already present at the head of the qualified name, there's no point repeating it. The converse case where modules are divided by their namespace (which naturally maps to D modules): module cpplib.ns; extern(C++, ns) void foo(); Now the name is: cpplib.ns.ns.foo(); // <- why would anyone want that? In both cases it's just a repeat of what's already in the module name. But the redundancy is more than a nuisance in certain forms of scanning meta. And got forbid the case where C++ namespaces are embedded (namespace for lib name, another for the module), and we have this: module lib_ns.module_ns; extrern(C++, lib_ns) extern(C++, module_ns) void foo(); The name is: lib_ns.module_ns.lib_ns.module_ns.foo(); // <- words can't even > My second point is that changing the language is a last resort solution, not a > first resort. This isn't a last-resort, this was truly a first-resort... I started making this noise within some number of hours after the appearance of the design countable on my fingers. (far less aggressively, having not spent years of my life stewing on this) You've just blocked the conversation for sufficiently long that now you're able to say that sentence you just said. Was that a deliberate strategy? I feel like that strategy's been used before. That said, I'm not proposing a language 'change', we can just support a string version in parallel and everything's fine if we don't want to deprecate the scope version. > Thirdly, C and C++ are loaded to the gills with > seemed-like-a-good-idea-at-the-time solutions that turned out to have bad > unintended consequences that bork up the language for everyone down the line. > D > has some of those, too. extern(C++, ns) is the poster child of exactly that. In this case, it seemed-like-a-good-idea to one person and was implemented with no consultation of anyone. The design was never presented or scrutinised. It just merged, and when we promptly complained, our criticism were rejected on principle. Maybe we should write up a retro-DIP, and see if it passes
Re: Is there any hope for "lazy" and @nogc?
On 31/07/18 10:29, Mike Franklin wrote: Please clarify if I'm missing the point. You are. I want something along the lines of: assertEQ(a, b, "a and b are not equal"); When run, it would issue an assert that says: Assertion failed: 3!=7: a and b are not equal Hooking it later is not an option. I am actually interested in a different assert like function. Whether for asserts or otherwise, the "lazy" feature is completely incompatible with function attributes, and that's not good. Shachar
Re: Is there any hope for "lazy" and @nogc?
On Tuesday, 31 July 2018 at 07:17:34 UTC, Shachar Shemesh wrote:
I'm trying to figure out what's the signature of the built-in
assert. It does not seem that I can define a similar function
myself.
Help??
I'm not sure why you want a different assert, but you can
consider these options.
1) Assign your own assert handler:
https://github.com/dlang/druntime/blob/52d3fe02272d16d32c150ce6f78bc00241a9dd5d/src/core/exception.d#L393
2) You can provide your own implementations of the runtime hooks
at
https://github.com/dlang/druntime/blob/cb5efa9854775c5a72acd6870083b16e5ebba369/src/core/exception.d#L628
extern(C) void _d_assertp(immutable(char)* file, uint line)
{
import core.stdc.stdio;
printf("Houston, we have a problem at %s:%u\n", file, line);
}
void main()
{
assert(false);
}
https://run.dlang.io/is/QZEO9W
3) -betterC seems to forward runtime assertions to the C
implementation. See https://run.dlang.io/is/QZEO9W
For that you have to provide a new implementation of `__assert`:
extern(C) void __assert(const char *msg, const char *file, int
line)
{
import core.stdc.stdio;
printf("Houston, we have a problem at %s:%u\n", file, line);
}
extern(C) void main()
{
assert(false);
}
https://run.dlang.io/is/D5JxCT
4) Otherwise can't you just implement two `myAssert` overloads?
`void assert(bool condition, string msg);`
`void assert(bool condition)`
Please clarify if I'm missing the point.
Mike
Re: Is there any hope for "lazy" and @nogc?
On 31/07/2018 7:17 PM, Shachar Shemesh wrote: I'm trying to figure out what's the signature of the built-in assert. It does not seem that I can define a similar function myself. That is because it isn't a function. It's a language feature that is backed by functions.
Re: DMD, Vibe.d, and Dub
Am Wed, 18 Jul 2018 19:08:32 +0100 schrieb Russel Winder: > On Wed, 2018-07-18 at 17:45 +, Johannes Pfau via Digitalmars-d > wrote: >> Am Wed, 18 Jul 2018 13:29:00 +0100 schrieb Russel Winder: >> >> > […] >> > libssl installed but libssl-dev not. I can't quite see why the linker >> > ld needs the development files, it just needs the shared objects to >> > be present. >> >> Debian moved the lib*.so => lib*.so.123version symlinks into the -dev >> packages some time ago, so now you can't link without -dev packages. >> Not the smartest move imho > > I think I shall find it hard to discover a reason why you are wrong, > but clearly the Debian devs in charge managed to. I actually found a reason why you do not want the .so symlink in normal runtime packages: If you have a library libfoo with different versions, i.e. 1.0 and 2.0, the libfoo packages for 1.0 and 2.0 do not have any conflicting files so you can in theory install both library versions (with same package name) at the same time. I don't know if debian supports this but I think on fedora it's possible to install multiple versions of the same package. Havin the .so symlink in the non-dev package would prevent this usage pattern. -- Johannes
Is there any hope for "lazy" and @nogc?
I'm trying to figure out what's the signature of the built-in assert. It does not seem that I can define a similar function myself. First attempt: void myAssert(bool cond, string msg) @nogc nothrow; No, because msg gets evaluated unconditionally. void myAssert(bool cond, lazy string msg) @nogc nothrow; test.d(8): Error: @nogc function test.myAssert cannot call non-@nogc delegate msg void myAssert(bool cond, lazy string msg @nogc nothrow ) @nogc nothrow; test.d(4): Error: found @ when expecting ) test.d(4): Error: semicolon expected following function declaration test.d(4): Error: no identifier for declarator nogc test.d(4): Error: declaration expected, not ) test.d(9): Error: unrecognized declaration Templates to the rescue!!! void myAssert(STR)(bool cond, lazy STR msg ); test.d(14): Error: @nogc function D main cannot call non-@nogc function test.myAssert!string.myAssert Help?? Shachar
