Re: dip1000 rule 5
On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote: Did DIP1000 go through any review process? I'm seeing it is a draft. The previous DIP manager marked DIPs as Draft while they were under review. I don't use that anymore. I left DIP1000 untouched after I took over, however. Walter told me he'll revise it at some point to reflect the actual implementation. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts". It was originally my intention to push new DIPs into a Drafts subdirectory for the Draft Review stage, but it's more convenient to handle it in the pull request thread. I never edited the document to reflect that and didn't notice it when I've looked it over. Now that you've pointed it out, I'll revise it.
Re: D is supposed to compile fast.
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote: So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? Yes, C and C++ compilers behave the same way. #1 How to I only build files that are dirty? Do I actually need a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds? cmake doesn't actually build anything. It generates make files or IDE project files. I don't know if DUB currently has an option to build only dirty files. Make does it by default. To do something like that requires looking for a source file's corresponding object file in the output directory and only compiling the source if the object file doesn't exist or if it has an older timestamp. But consider what happens when you change the command line options, say enable a version on a build that wasn't enabled earlier. With make, you have to run `make clean` first, otherwise only dirty files will get the new options. It doesn't track build options per file from run to run. What should the compiler do? Have a -clean command line switch? Maintain a database of command line options per file? That's the realm of build systems. The compiler just compiles. I've heard "just use dub" but I've also heard that dub have flaws/gotchas that I can't remember when it comes to say, dynamic linking DLLs/SOs. So I've been hesitant to learn it. DUB is easy. I've been using it for years and I do full compilation of every file on every invocation in a code->build->run cycle. Some aren't happy with it because it doesn't support some of the things they want to use it for, but it has plenty of satisfied users. I'm unaware of any gotchas about linking shared libraries. #2 I ran individual file times. They're pretty shocking. --- I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Now let's stop for a moment. I'm not accusing anyone, and "lie" is a strong word with heavy guilt implications--like people are intentionally being very sneaky to deceive new-comers. I'm not saying any of that, so you can relax and put down the pitchfork. I'm not attacking you or your group personally. However, I can't think of any better word. So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected. There is no misleading or misconception or lying or misdirection here. DMD has fast compile times. Heavily templated code is going to slow it down, but if you compile the same sort of heavily templated code in C++, you'll get slow downs there as well. And in your case, you'll find that if you add many more files to your project and they aren't heavily templated, the increase in build time will be very small. If someone can dig into the compilers and optimize how templates are handled, they might be able to shave a bit of time off, but when you are using a code base that does a lot of work at compile time, then there's no avoiding increasing the length of that compile time. But that by no means is the same as saying it's not fast, because overall compile times in D are still fast. I mean, can you think of any module in the Python/Javascript/C# standard library that simply including it will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language. Have you reached the point in D where you can't compile?
Re: D Language 2.1
On Sun, 25 Nov 2018 20:46:28 +, Tony wrote: > From std.compiler.D_major and std.compiler.D_minor I see that my D > language version is at 2.0 . But the version of gdc front-end I am using > (via Debian default gdc package as of a few months ago) from > std.compiler.version_major and std.compiler.version_minor is at 2.68. D_minor is 0 in both. version_minor is 68 in your version of GDC, which matches version_minor for DMD 2.068.*. > That is a lot of bug fixes, with 0 changes to the language. In semantic versioning terms, the product is D2 and the current version is 83.0.0. > Actually, I realize that changes to the language are being reflected in > compiler versions, not language versions. Just wondering why it was > decided not to version the language (2.1, 2.2, etc.) There are feature changes with every major compiler release, so it would be pointless complexity to version the language separate from DMD.
Re: Convert multibyte `string` to `dstring`
On Sunday, 25 November 2018 at 21:33:15 UTC, Stanislav Blinov
wrote:
On Sunday, 25 November 2018 at 21:23:31 UTC, Vladimirs Nordholm
wrote:
Is there a proper way to convert a string with multibyte
characters into a dstring?
void main() {
import std.conv : to;
import std.stdio : writeln;
string a = "abc123";
auto b = to!dstring(a);
assert(b.length == 7);
writeln(b);
}
Oh! It was so simple.
Thank you so much Stanislav
Re: D is supposed to compile fast.
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote: On Saturday, 24 November 2018 at 20:44:57 UTC, welkam wrote: On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote: D is supposed to compile fast. You didnt read the fine print. It compiles simple code fast. Also compilation is separate step from linking and your program might spend half of "compilation" time in link phase. Wait wait wait wait wait. So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? "runs the files every time"? If that means "compiles the files every time", then no. D works exactly like C/C++ - you only need to compile-to-object-code source files in the project that have changed since the last time they were compiled.
Re: D is supposed to compile fast.
On Saturday, 24 November 2018 at 20:44:57 UTC, welkam wrote: On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote: D is supposed to compile fast. You didnt read the fine print. It compiles simple code fast. Also compilation is separate step from linking and your program might spend half of "compilation" time in link phase. Wait wait wait wait wait. So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? Two questions/topics/issues: --- #1 How to I only build files that are dirty? Do I actually need a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds? I have the simplest project ever. Less than 10 files and my non-VStudio build-scripts have always been simple. A few lines or one long line running GCC/Clang/etc. I don't want to learn a make program's huge syntax just to compile a program if I can avoid it! (I've still got so many D and networking topics to learn on the back-burner!) I've heard "just use dub" but I've also heard that dub have flaws/gotchas that I can't remember when it comes to say, dynamic linking DLLs/SOs. So I've been hesitant to learn it. #2 I ran individual file times. They're pretty shocking. --- std.regex is still, the Devil (TM), clocking in at almost FOUR SECONDS for a very simple set of code that simply matches lines for a poor-man's INI file parser (with a custom feature that allows tab indents to be nested sections). I was considering ripping it out and replacing it with JSON and this has REALLY motivated me to rip out the regex. Here's the file times: novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c molto.d Class 4 - Scaled Rotated hello hello -- it matches! real0m0.377s user0m0.344s sys 0m0.028s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c helper.d real0m0.118s user0m0.096s sys 0m0.020s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c editor.d real0m0.626s user0m0.536s sys 0m0.072s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c common.d real0m0.755s user0m0.636s sys 0m0.092s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c map.d real0m1.045s user0m0.904s sys 0m0.112s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c object_t.d real0m0.359s user0m0.336s sys 0m0.024s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c animation.d real0m0.365s user0m0.280s sys 0m0.068s novous@saturn:~/Desktop/bitbucket/ss14$ time dmd -c ini.d real0m3.672s <--- WOWZA user0m3.292s sys 0m0.332s I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Now let's stop for a moment. I'm not accusing anyone, and "lie" is a strong word with heavy guilt implications--like people are intentionally being very sneaky to deceive new-comers. I'm not saying any of that, so you can relax and put down the pitchfork. I'm not attacking you or your group personally. However, I can't think of any better word. So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected. And if I'm experiencing this, there are dozens (hundreds?) who hit the same roadblocks and gotchas and many people are much less forgiving/understanding than I am and simply just "give up" without ever telling you. So I'm trying to say this with the best of intentions. You can't have standard modules with no warning documentation that explode your RAM usage and compile times orders-of-a-magnitude more than other ones. You can have an "alpha" or "beta" or "Addon" or "external" module. But putting it in your standard framework implies that it works well with the other modules (::cough::std.variant and threads::cough::), and that it's not incredibly slower or more resource intensive. Having it in your standard library implies it meets a certain _STANDARD_. I mean, can you think of any module in the
Re: version(StdDoc)
On Sunday, 25 November 2018 at 21:38:43 UTC, H. S. Teoh wrote:
Actually, I just thought of a way to do this with the existing
language: use a struct to simulate an enum:
struct E {
alias Basetype = int;
Basetype impl;
alias impl this;
enum a = E(1);
enum b = E(2);
version(Windows) {
enum c = E(3);
}
version(Posix) {
enum c = E(4);
enum d = E(100);
}
}
Heh, that can work in a pinch. Disgusting though :D
It's not 100% the same thing, but gets pretty close, e.g., you
can reference enum values as E.a, E.b, you can declare
variables of type E and pass it to functions and it implicitly
converts to the base type, etc..
There are some differences, like cast(E) won't work like an
enum...
It should, you can cast values of same sizeof to a struct.
and .max has to be manually declared, etc.. You'll also need to
explicitly assign values to each member, but for OS-dependent
enums you have to do that already anyway.
Yeah, those aren't a huge concern for that particular scenario.
Re: version(StdDoc)
On Sun, Nov 25, 2018 at 07:22:54AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Sunday, 25 November 2018 at 07:19:50 UTC, Stanislav Blinov wrote:
>
> > Granted, it may require some special syntax, i.e.
> >
> > enum E {
> > a,
> > b if version(Windows),
> > c if version(Windows),
> > d if version(Posix),
> > }
> >
> > or something to that effect.
>
> Come to think of it, since UDAs are now allowed, the compiler could
> potentially be taught this:
>
> enum E {
> a,
> @version(Windows) b,
> @version(Windows) c,
> @version(Posix) d,
> }
Actually, I just thought of a way to do this with the existing language:
use a struct to simulate an enum:
struct E {
alias Basetype = int;
Basetype impl;
alias impl this;
enum a = E(1);
enum b = E(2);
version(Windows) {
enum c = E(3);
}
version(Posix) {
enum c = E(4);
enum d = E(100);
}
}
It's not 100% the same thing, but gets pretty close, e.g., you can
reference enum values as E.a, E.b, you can declare variables of type E
and pass it to functions and it implicitly converts to the base type,
etc..
There are some differences, like cast(E) won't work like an enum, and
.max has to be manually declared, etc.. You'll also need to explicitly
assign values to each member, but for OS-dependent enums you have to do
that already anyway.
T
--
Let's eat some disquits while we format the biskettes.
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote: Did DIP1000 go through any review process? I'm seeing it is a draft. Review links are at the very end. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts". Not sure about that one. Maybe Mike Parker could elaborate on this.
Re: version(StdDoc)
On Saturday, November 24, 2018 10:41:56 PM MST H. S. Teoh via Digitalmars-d-
learn wrote:
> On Sat, Nov 24, 2018 at 05:48:16PM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> > On Saturday, 24 November 2018 at 17:43:35 UTC, Jonathan M Davis wrote:
> > > I'm still inclined to think though that it should be legal to just
> > > use version directly in the member list.
> >
> > Yup. UDAs did get in there eventually, and version should too.
>
> I think this would be a trivial DIP, by making it such that a version
> block inside an enum would lower to the above code. Of course, it could
> be taken further: the above trick doesn't quite handle this case:
>
> enum E {
> a,
> version(Windows) {
> b, c
> }
> version(Posix) {
> d
> }
> }
>
> But this looks like such an antipattern that it probably should be
> written differently anyway, or just generated via a string mixin.
It's something that comes up fairly frequently actually when dealing with
system APIs. For instance, if you want your socket API to provide the full
functionality of the underlying C API, then you're going to have to provide
not only differing enum values for things like socket options or socket
family, but you're actually going to have to provide different enum members
in some cases.
So, sure, if you're writing something that's purely D and can be properly
platform-agnostic, then having different enum members for different
platforms would be bad, but once C APIs get involved, I definitely would not
consider it to be an anti-pattern. At that point, it has a tendency to
become a necessity, and I've had several occasions where being able to
version enum members would have made the code shorter. It also would have
eliminated the need for version(D_Ddoc) (or the druntime or Phobos
equivalents).
- Jonathan M Davis
Re: Convert multibyte `string` to `dstring`
On Sunday, 25 November 2018 at 21:23:31 UTC, Vladimirs Nordholm
wrote:
Is there a proper way to convert a string with multibyte
characters into a dstring?
void main() {
import std.conv : to;
import std.stdio : writeln;
string a = "abc123";
auto b = to!dstring(a);
assert(b.length == 7);
writeln(b);
}
Convert multibyte `string` to `dstring`
Hello.
Is there a proper way to convert a string with multibyte
characters into a dstring?
Case scenario:
string a = "abc123"; // a.length == 10 ("abc"==3 + ""==4 +
"123"==3)
dstring b = foo(a); // b.length = 7 ("abc"==3 + ""==1 +
"123"==3)
dstring foo(string str) {
// code...
}
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 19:49:03 UTC, Stanislav Blinov wrote: On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote: There are 4 rules listed. ... What is rule 5? ... Wouldn't you call it D3 because of the name mangling of DIP1000 once activated by default? That "rule 5" looks like a straight up mistake. As for D3... IMHO, no, not by a long shot. There's 1014 and 1016, 1008, there's `shared`, there are improved move-assignments, there's `__mutable` and `@__future`, there are tons of issues in Bugzilla, the standard library is long overdue for a huge look-over... Did DIP1000 go through any review process? I'm seeing it is a draft. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts". I only see accepted archived //old stuff rejected
D Language 2.1
From std.compiler.D_major and std.compiler.D_minor I see that my D language version is at 2.0 . But the version of gdc front-end I am using (via Debian default gdc package as of a few months ago) from std.compiler.version_major and std.compiler.version_minor is at 2.68 . That is a lot of bug fixes, with 0 changes to the language. Actually, I realize that changes to the language are being reflected in compiler versions, not language versions. Just wondering why it was decided not to version the language (2.1, 2.2, etc.)
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote: There are 4 rules listed. ... What is rule 5? ... Wouldn't you call it D3 because of the name mangling of DIP1000 once activated by default? That "rule 5" looks like a straight up mistake. As for D3... IMHO, no, not by a long shot. There's 1014 and 1016, 1008, there's `shared`, there are improved move-assignments, there's `__mutable` and `@__future`, there are tons of issues in Bugzilla, the standard library is long overdue for a huge look-over...
dip1000 rule 5
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) <
lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) <
lifetime(global_ptr)
int* j;
global_ptr = j;// Ok, j is not scope
}
Also it says scope inferred for i
int * i = a;
So inferred, does that mean?
scope int *i = a;
It looks very similar to the error rule 5.
scope int* c = a; // Error, rule 5
When DIP1000 is in and copy constructors, then the language is
more or less finished?
Wouldn't you call it D3 because of the name mangling of DIP1000
once activated
by default?
[Pegged] making parsing error informative
I have the following grammar https://run.dlang.io/is/gRTGm3 If user types `ubyte1` instead of `ubyte` the whole string parsing fails and error message says string is wrong from the start. How can I get more informative message like "unknown type ubyte1" or at least error position points to `ubyte1` not the whole string?
Re: How to get all modules in a package at CT?
On Saturday, 24 November 2018 at 08:44:19 UTC, Domain wrote: I have a package named command, and many modules inside it, such as command.build, command.pack, command.help... I want to get all these modules at compile time so that I know what command is available. As far as I understand there is s.th. called separate compilations. Your program may is compiled in parts. Your logic which loops over the modules only knows which modules are available at the specific point in time. I do not know whether there is some functionality which tells you all modules available at compile time. But if this functionality exists, you (the developer) has to be aware of separate compilation and should have a plan how to mitigate. Either do not use separate compilation or always force recompilation of all source code files... In would really like to have such functionality and also the possibility to express in code: always recompile this part of code (the loop over the modules) even in separate compilation. I do not know whether that is technically possible... Kind regards Andre
