Re: DDT 0.11.0 released
On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote: On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 18/03/2015 00:12, Trent Forkert wrote: Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). Why is that 'duh'? I would expect nothing less than for DDT and CDT to interact comprehensively. Fair enough on that last 'duh', it could have been that DDT integrated with CDT. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms. Do they now? I'm inclined to try them out again because I'm a bit skeptical of that comment, as least in how it applies to this discussion. For example, does Mono-D allow to seamlessly create a crossplatform solution with a D project interacting with a C project (and/or the opposite). And what exactly seamlessly means here, what is offered in Mono-D that couldn't be done in DDT? -- Bruno Medeiros https://twitter.com/brunodomedeiros
[Issue 6756] Idea about std.stdio.chunks and std.range.chunks
https://issues.dlang.org/show_bug.cgi?id=6756 John Colvin john.loughran.col...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||john.loughran.colvin@gmail. ||com Resolution|--- |FIXED --- Comment #1 from John Colvin john.loughran.col...@gmail.com --- There is no clash anymore, the example given works fine. --
[Issue 3141] osx syntax problem with touch
https://issues.dlang.org/show_bug.cgi?id=3141 John Colvin john.loughran.col...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||john.loughran.colvin@gmail. ||com Resolution|--- |FIXED --- Comment #1 from John Colvin john.loughran.col...@gmail.com --- touch -t is used once in druntime/posix.mak, where it is used correctly. Perhaps the problem only ever existed in osx.mak which is now done. --
Re: DDT 0.11.0 released
On 19/03/2015 15:55, Trent Forkert wrote:
On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote:
On 19/03/2015 14:45, Trent Forkert wrote:
It seems you are right that it *is* limited, but it shouldn't be. CMake
emits include/import paths into the project structure. I had thought it
emitted into .project, but evidently emits into .cproject. If DDT
supported a .dproject I could also emit, I could get it to work.
DDT does support a .dproject ... it's called dub.json ! ;)
I'm dead serious here though. Why would I invent my own file format to
describe source folders and include/imports paths when dub.json does
that already??
1. I don't consider an XML configuration to be your own file format
Err.., but it is. XML is just syntax, you still have the semantics of
what that data means to be defined. Just as learning XML doesn't mean
you know how to properly read/write HTML5! (Maybe there is a better term
than file format, but regardless I think my comment was clear.
2. For the very reason that started this entire conversation. Not
everybody *wants* to use dub. Not everybody *can* use dub. So it doesn't
make sense for DDT to force dub.
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
It would be silly to use anything else.
VisualD has done pretty well for itself.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 05:30, Manu via Digitalmars-d-announce wrote: On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. I would imagine that if you had complete control over the project description and build process, it would be much easier to integrate with other components in Eclipse? Of course, I have no idea whether that's true or not. But I will hazard a guess that using dub in this way must make it harder for you to interact with CDT/java tools than otherwise? There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. It would also be really nice to have a UI with tick boxes and select boxes for all the relevant build settings like CDT. Yeah, true. Even if using DUB, it would be nice to have UI to control the settings in dub.json, but that's a fair amount of work for little gain, so down in the priority list. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project? Different flags to
different source files? Running a Python script to generate D code?
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
Re: dfmt options
On 2015-03-23 10:47, bearophile wrote: See: https://issues.dlang.org/show_bug.cgi?id=7176 Exactly. -- /Jacob Carlborg
[Issue 14322] New: Menu on downloads.dlang.org is completely broken
https://issues.dlang.org/show_bug.cgi?id=14322 Issue ID: 14322 Summary: Menu on downloads.dlang.org is completely broken Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: d...@me.com The left side menu on http://downloads.dlang.org is completely broken. The logo sits in the middle of the menu. The menu is not up to date with dlang.org, but perhaps that's a separate issue. --
Re: DDT 0.11.0 released
On 20/03/2015 18:07, Trent Forkert wrote: And I don't understand why it is not acceptable. * Because it is not guaranteed to be there. For instance, I don't have dub on my system That's the lamest reason ever. Why is that an issue? Just install it if it is not installed. To me, that's akin to saying DDT shouldn't have a requirement of the Java VM! * Because anybody not using dub should not be required to use dub. This is dlang, not dublang * Because I just want to tell Eclipse about the project, there is no need to involve dub * Because the user said so These are basically all the same reason: me no want to use dub!. Well, you're free not to use DDT either! Seriously, I don't understand the *gripe* here: DUB offers a service, a functionality, that is not offered elsewhere (for D at least): a package management system, for source packages. And this is an important functionality for language ecosystems, because it is so damn useful!! That's why nearly all modern language have a source-package manager (Rust - Cargo, Ruby - rpm, Go - `go get/install`, Java - Maven/OSGi), all of them integrated with a build tool. I hope your experience/mindset has not been too tainted with archaic C/C++ paradigms that you fail to see this. D actually lags behind these languages in that DUB is not an official part of the language/toolchain. Although from what I recall there are plans to make DUB included as part of the DMD installation, so that would change. * Because it is at odds with C/C++ integration, which is an H1 priority This is the only reason with some credence. However, *not using dub* doesn't makes DDT automatically integrate with C/C++, nor doesn't it even necessarily bring it any closer to that. A fair amount of work would still need to be done to properly support this scenario, I suspect. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: OPTLINK Error 45 Too Much DEBUG Data for Old CodeView format
On Sunday, 22 March 2015 at 15:29:00 UTC, Koi wrote: thank you Etienne, after i replaced dmd's link.exe my project compiles successfully in debug-mode again. i'll add this info in my todo-after-installing-DMD.txt just in case. On Sunday, 22 March 2015 at 14:29:14 UTC, Etienne wrote: This is due to a high amount of symbols in your code. I fixed this almost a year ago in the optlink repository: https://github.com/DigitalMars/optlink/pull/15 You should be able to download it on the digitalmars.com website under: Digital Mars C/C++ Compiler Version 8.57 (3662658 bytes) The link.exe file in the bin folder is up-to-date. Maybe this should be distributed in the DMD installer?
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-23 at 00:15, krzaq wrote:
Something like
while (n != EOF) {
n = read(fd, buf, sizeof(buf));
if (n==-1) throw(...);
if (strcmp(buf, PREFIX) == 0) {
return buf;
}
}
return NULL;
Requires no prior knowledge, and have similar effect.
I'm surprised nobody commented on no prior knowledge. How are you supposed to
guess what strcmp(buf, PREFIX) does if you don't know the function? Why is it being
compared to 0? What's this -1 magic number? What does read do? What is EOF? Unless you're
born with C/POSIX programming knowledge, this is prior knowledge. I know C well enough,
but it took me some time to understand what it does.
Indeed. I know of strcmp (because of prior knowledge) but had to have a look at man
2 read just in case to verify if read was used correctly. Of course there is also
this conveniently omitted part in throw(...). Throw what? Use switch to go over errno and
pick the suitable Exception or rather pick one generic Exception and put the output of
strerror as its msg? Why should we be bothered with such low-level tasks?
And honestly, compared to
File(/tmp/a).byChunk(4096).joiner.startsWith(s)
you can *easily* guess that you have a file - do some nonobvious magic on it -
and check if *it* starts with `s` just by reading it as plain English.
Now you've injured yourself with your own weapon. I can guess that File(path)
opens the file for reading (probably because of other language libraries) and
that byChunk(size) reads it one chunk at a time (but frankly only because it
looked similar to byLine which I've known before), but what the hell is joiner?
Does it glue ranges together so that they appear as a single contiguous one?
Oh, wait, I may have actually read about it somewhere already. But if I didn't,
I wouldn't have a clue.
What should start with s? The file, any chunk, the joiner - whatever it meant?
It is much clearer than the loop, but I'm not sure I'd guess what it does,
because of the two middle elements in the UFCS chain. This *nonobvious magic*
may have transformed the contents of the file in a way that makes startsWith(s)
do something different.
Re: Post increment and decrement
Well, things like std::string are not cooperative in this regard. Though, it's copied only to be instantly destructed, theoretically it should be elided if the involved constructors are annotated with sufficient purity or complementary operators. Also the iterator pretends to be copyable, but it can't resume from the point where it was copied, can it?
[Issue 14321] New: No postblit call with struct and AA's
https://issues.dlang.org/show_bug.cgi?id=14321
Issue ID: 14321
Summary: No postblit call with struct and AA's
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: rswhi...@gmail.com
Code:
import std.stdio;
struct Foo {
this(int id) {
writeln(CTor);
}
this(this) {
writeln(Postblit);
}
~this() {
writeln(DTor);
}
}
void main() {
Foo[string] foos;
foos[test] = Foo(42);
writeln(end of main);
}
Expected behaviour
CTor
end of main
or
CTor
Postblit
DTor
end of main
But currently:
CTor
DTor
end of main
That ruins all interaction between AA's and ref counted structs.
--
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - cross-platform GUI for D. https://github.com/buggins/dlangui License: Boost License 1.0 Native library written in D (not a wrapper to other GUI library) - easy to extend. As a backend, uses SDL2 on any platform, Win32 API on Windows, XCB on Linux. Other backends can be added easy. .. Best regards, Vadim coolreader@gmail.com Project Update: == * Mac OSX OpenGL support fixed * High DPI (Retina) displays interface scaling is implemented * Separate resources for high DPI resolutions * Font sizes in themes can be specified in points and % of parent size, in addition to pixels * Dark theme is implemented * Settings dialogs support widgets * Multiline TextWidget * A lot of bugfixes
Re: A few notes on choosing between Go and D for a quick project
On Monday, 23 March 2015 at 11:31:16 UTC, FG wrote: And honestly, compared to File(/tmp/a).byChunk(4096).joiner.startsWith(s) you can *easily* guess that you have a file - do some nonobvious magic on it - and check if *it* starts with `s` just by reading it as plain English. Now you've injured yourself with your own weapon. I can guess that File(path) opens the file for reading (probably because of other language libraries) That's why I used the word guess ;) and that byChunk(size) reads it one chunk at a time (but frankly only because it looked similar to byLine which I've known before), but what the hell is joiner? Does it glue ranges together so that they appear as a single contiguous one? Oh, wait, I may have actually read about it somewhere already. But if I didn't, I wouldn't have a clue. I'd argue that joiner is intuitive enough, but I agree on byChunk. I am also baffled why this byLine/byChunk madness is necessary at all, it should be something like File(path).startsWith(s) or File(path).data.startswith(s) The same goes for stdin, something as simple as cin intvariable in C++ rises to an almost insurmountable task in D. What should start with s? The file, any chunk, the joiner - whatever it meant? It is much clearer than the loop, but I'm not sure I'd guess what it does, because of the two middle elements in the UFCS chain. This *nonobvious magic* may have transformed the contents of the file in a way that makes startsWith(s) do something different. You're right, I didn't even think of that.
[Issue 14317] [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline
https://issues.dlang.org/show_bug.cgi?id=14317 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4511 --
Re: Post increment and decrement
On Monday, 23 March 2015 at 12:10:32 UTC, Kagamin wrote: Well, things like std::string are not cooperative in this regard. Though, it's copied only to be instantly destructed, theoretically it should be elided if the involved constructors are annotated with sufficient purity or complementary operators. That's why using preincrementation is the preferred default - you simply can't know predict what the user's type will do. And sure, maybe the compiler should optimize it away in this case, but as you can see, the pragmatic solution is to simply avoid this problem entirely. Also the iterator pretends to be copyable, but it can't resume from the point where it was copied, can it? Depends on the iterator type, in this case: no, I don't believe that it can be resumed.
Re: [Semi OT] The programming language wars
On Saturday, 21 March 2015 at 19:20:18 UTC, deadalnix wrote: On Saturday, 21 March 2015 at 15:51:38 UTC, Paulo Pinto wrote: I don't expect programming will remain so low level in the future. We are at the infancy of our skills, when comparing with engineerings with a fee centuries of progress. For me the future lyes in something like Wolfram/Mathematic with natural voice processing. People have been saying this for longer than I'm alive. You missed my remark about the age of computing versus other arts from engineering. We are still building bridges with wood and houses with clay. - Paulo
[Issue 14321] No postblit call with struct and AA's
https://issues.dlang.org/show_bug.cgi?id=14321 --- Comment #1 from rswhi...@gmail.com --- Forget to mention, my compiler is DMD v2.067.0-rc1 --
[Issue 14317] [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline
https://issues.dlang.org/show_bug.cgi?id=14317 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14317] [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline
https://issues.dlang.org/show_bug.cgi?id=14317 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0a4928f382d167e221667910bec3abd8bd48d84d fix Issue 14317 - [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline https://github.com/D-Programming-Language/dmd/commit/790afb3748ed61e56e0ad124942a6e90b42b02b3 Merge pull request #4511 from WalterBright/fix14317 fix Issue 14317 - [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline --
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:04:30 +, Dicebot via Digitalmars-d-announce wrote: If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works. Makes sense for -fversion and the like (it would be nice if libraries exported the list of version symbols they had since it is basically ABI...), but not necessarily for things like SSE support where you want to do runtime detection and run the fastest version based on the running processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with different compiler flags. --Ben
Re: A few notes on choosing between Go and D for a quick project
On 3/23/15 4:59 AM, krzaq wrote: File(path).data.startswith(s) We could define File.byByte, but that's minor. I appreciate the ability to decide on the buffering strategy. -- Andrei
Re: Making byLine faster: we should be able to delegate this
On 3/23/15 7:52 AM, Steven Schveighoffer wrote: On 3/22/15 3:03 AM, Andrei Alexandrescu wrote: * assumeSafeAppend() was unnecessarily used once per line read. Its removal led to a whopping 35% on top of everything else. I'm not sure what it does, but boy it does takes its sweet time. Maybe someone should look into it. That's not expected. assumeSafeAppend should be pretty quick, and DEFINITELY should not be a significant percentage of reading lines. I will look into it. Thanks! Just to verify, your test application was a simple byline loop? Yes, the code was that in http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508#29153508 Andrei
Re: Making byLine faster: we should be able to delegate this
On Sunday, 22 March 2015 at 07:03:14 UTC, Andrei Alexandrescu wrote: I just took a look at making byLine faster. It took less than one evening: https://github.com/D-Programming-Language/phobos/pull/3089 I confess I am a bit disappointed with the leadership being unable to delegate this task to a trusty lieutenant in the community. There's been a bug opened on this for a long time, it gets regularly discussed here (with the wrong conclusions (we must redo D's I/O because FILE* is killing it!) about performance bottlenecks drawn from unverified assumptions), and the techniques used to get a marked improvement in the diff above are trivial fare for any software engineer. The following factors each had a significant impact on speed: * On OSX (which I happened to test with) getdelim() exists but wasn't being used. I made the implementation use it. * There was one call to fwide() per line read. I used simple caching (a stream's width cannot be changed once set, making it a perfect candidate for caching). (As an aside there was some unreachable code in ByLineImpl.empty, which didn't impact performance but was overdue for removal.) * For each line read there was a call to malloc() and one to free(). I set things up that the buffer used for reading is reused by simply making the buffer static. * assumeSafeAppend() was unnecessarily used once per line read. Its removal led to a whopping 35% on top of everything else. I'm not sure what it does, but boy it does takes its sweet time. Maybe someone should look into it. Destroy. Andrei What would be really great would be a performance test suite for phobos. D is reaching a point where It'll probably be fast because we did it right or I remember it being fast-ish 3 years ago when i wrote a small toy test isn't going to cut it. Real data is needed, with comparisons to other languages where possible.
Re: [Semi OT] The programming language wars
On Friday, 20 March 2015 at 07:37:04 UTC, Paulo Pinto wrote: An example that stuck with me was that languages that follow Algol/Pascal syntax lead themselves to less bugs, than those that follow C like syntax. There are quite a few other examples. Also the mention that as far as the researcher is aware, only Microsoft is pursuing such studies for language features. Don Syme is in the audience and gives an example how they did it for .NET generics. Anything wrong with VB.NET?
Re: DDT 0.11.0 released
On 23/03/2015 13:39, Ben Boeckel via Digitalmars-d-announce wrote:
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project?
Yes - use DUB sub-packages.
Different flags to different source files?
What dicebot said.
That looks like an invalid, abstraction-breaking thing to do
Running a Python script to generate D code?
Yes, in DUB you can run arbitrary external commands before and after the
D sources compilation.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
I thought about that - VS2013 Community Edition -, but it looks huge and
I don't want to install a bunch of library and stuff on my computer just
to try VisualD out. I'd do it in a virtual machine though, as its
worthwhile to check it out. But it will just have to wait until I get
around to it, I don't have a spare Windows VM or installation at the moment.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: Making byLine faster: we should be able to delegate this
On 3/22/15 3:03 AM, Andrei Alexandrescu wrote: * assumeSafeAppend() was unnecessarily used once per line read. Its removal led to a whopping 35% on top of everything else. I'm not sure what it does, but boy it does takes its sweet time. Maybe someone should look into it. That's not expected. assumeSafeAppend should be pretty quick, and DEFINITELY should not be a significant percentage of reading lines. I will look into it. Just to verify, your test application was a simple byline loop? -Steve
[Issue 14321] 2.067.0-rc1 - No postblit call with struct and AA's
https://issues.dlang.org/show_bug.cgi?id=14321 rswhi...@gmail.com changed: What|Removed |Added Summary|No postblit call with |2.067.0-rc1 - No postblit |struct and AA's |call with struct and AA's --
Re: DDT 0.11.0 released
On 20/03/2015 05:04, Manu via Digitalmars-d-announce wrote: On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I just checked out DDT, and I noticed it seems to use DUB... _ Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one DUB Options box. The comprehensive suite of build options CDT presents would be much nicer. It makes no sense for DDT to use anything else than DUB. At a minimum, DDT needs a way to describe projects: the source files that are part of the project, and which other projects are dependencies of said project. Other aspects of a projects that are good to be able to describe are: which build configurations the project supports, which executables are produced (if any), etc.. Now the reason DUB is used is that it's a bad paradigm for this description mechanism to be Eclipse/DDT specific. It's unequivocally much better to be Eclipse-independent, such that other tools (not just other IDEs, but even other command-line analysis tools) can understand D projects/bundles/packages just as well as DDT. It also saved me a lot of work. If I had to develop my own format to describe all these aspects, it would not be as good as DUB's, guaranteed! I reckon this is true for any other D IDE out there. I use Mono-D and VisualD extensively, and in lieu of those, I fallback to makefiles. Those certainly did make their own equivalent build systems matching the IDE's existing styles. Those IDE's integrate D nicely with the C/C++ experiences. We might have different notions of what as good as DUB's means then. Let's look at these two use cases: * Do those IDEs allow a project specifying a dependency on an D library, without having to download the library, or to configure the build settings for the library? And does doing so still make it possible to integrate with C/C++ projects? * Can you have a cross-plaftorm workspace/solution, and when building the D part of it, the IDE parses the error messages of the D compiler and reports then to the UI in the editor? DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too:( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? I have no idea how Eclipse operates internally... and I shouldn't have to. Isn't that the point of an IDE? All I can say is that CDT works, and I don't know how. If DDT doesn't automatically work with it out of the box, then the IDE experience is kinda pointless (to me at least). If I have to fiddle with a build system by hand, then that undermines the whole point of the IDE as far as I'm concerned. C/C++ and D are related, and they must interoperate. It's the top of the D roadmap. If I'm an IDE user, I think that's more-or-less an admission that I don't understand build environments, and I don't want to. So from that perspective, I think it would be valuable work to make sure DDT and CDT understand eachother. Yes, it would be nice if DDT would automatically integrate with CDT, and handle this use case seamlessly (regardless of using DUB internally or not). But this would be complex work, for little gain. Let me go into detail. First of all, CDT works, and I don't know how: yeah, but CDT only had to concern himself with C/C++, no cross-language stuff. Like you said, DDT and DUB also works well if you stick to the D ecosystem only. If you put a cross-language requirement on DDT, you're actually asking more of DDT than CDT had to worry (which means more work, more complexity). CDT and VisualStudio are IDEs with big companies backing them, they both had multiple developers working on them, full-time, for many, many years now. DDT only has had me working on it, on a volunteer basis (although some of the work I do there, and in Goclipse and RustDT, is related to some commercial work I do). Still, it's just me ATM, so there is an order of magnitude of difference of manpower available. You can't expect the same level of completeness. Only the most critical/important features can be worked on (or simple to implement ones). Also, there is limited gain. Sure, C/C++ and D are related, but A) Not everyone in D world is that concerned with that scenario, C/C++ integration. B) More importantly, adding DDT integration with CDT, would only benefit users of DDTCDT combined, which is a fraction of 'C++ D' users. What about users (and you might be one) that at the end of day don't use DDT/CDT because you can't debug
Re: Release Candidate D 2.067.0-rc1
On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call.
Re: DDT 0.11.0 released
On Monday, 23 March 2015 at 13:40:04 UTC, Ben Boeckel wrote: Different flags to different source files? If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works.
Re: dfmt options
On 03/23/2015 10:55 AM, Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= shortt...@hotmail.com wrote: Perhaps it's too much to wish for, but I think the editor would be the better place for this. IntelliJ IDEA can display short methods as single line. They're still multiline in the source, but on screen they're nice. They used a similar thing with anonymous classes in Java prior to lambdas hitting the language, making single method anonymous classes look almost like the lambdas do today. Why would you write out code that everyone reads abbreviated? Source code is still targeted at human readability not machine parsing.
Re: DDT 0.11.0 released
On 19/03/2015 16:02, Ben Boeckel via Digitalmars-d-announce wrote: It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) Building file-at-a-time is, for developers, on the whole faster than unity builds because you can parallelize it and only have to build what changed. CMake only really works with .d - .o rules (Java support bends this AFAIK due to restrictions in javac, but I vastly prefer -j8 over a single invokation). I think the issue of speed and parallellization is an orthogonal one: The build components should be structured in properly defined, self-contained, versioned libraries/bundles(*) - that can be built, and auto-tested on their own (obviously using the dependencies they require too). That should be the primary (top level) build unit of a build system. But, the way you build each bundle/component, is still up to the build system. You can build it on file-by-file sequentially, or parallelized, etc. I'm not familiar with CMake, so I don't know if it has any concept similar to this, but I suspect not. *: AKA packages in DUB and Ruby, crates in Rust. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Release Candidate D 2.067.0-rc1
On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:25:22 +, Bruno Medeiros via Digitalmars-d-announce wrote: Yes - use DUB sub-packages. Ah, had missed this. Different flags to different source files? What dicebot said. That looks like an invalid, abstraction-breaking thing to do Not all flags are -fversion or -I flags. Running a Python script to generate D code? Yes, in DUB you can run arbitrary external commands before and after the D sources compilation. But not in between? Basically, can you have a tool written in D built with the project and then used to generate code in the same project? --Ben
[Issue 14300] [2.067-rc1] DList casting to base type is broken
https://issues.dlang.org/show_bug.cgi?id=14300 Martin Nowak c...@dawg.eu changed: What|Removed |Added Component|DMD |Phobos --
[Issue 14317] [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline
https://issues.dlang.org/show_bug.cgi?id=14317 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c6b489b4cde70ec194fde21c2603b3e127f51479 Merge pull request #4511 from WalterBright/fix14317 fix Issue 14317 - [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline --
Re: serve - A simple HTTP server for static files
On 03/22/2015 08:56 PM, Walter Bright wrote: If you could write a brief article about it, that would be great! I think there's a lot of potential for D in that space, and having such articles will help promulgate the idea. An article would exceed the amount of code I wrote, but I did read up how to serve static files really fast, that might make for an interesting article.
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 14:19:34 UTC, Ben Boeckel wrote: On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. I need it working on win so we can even start to think about using D for our projects but indeed iOS and Android is very next
Re: Release Candidate D 2.067.0-rc1
On 03/23/2015 02:49 PM, Szymon Gatner wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. As a matter of fact we only have few Windows developers, so unless someone with interest in this platform steps up it will hardly improve. Daniel Murphy did a lot of D/C++ integration to get ddmd to work, and apparently, that also works on Windows, so you might ask him for details. https://auto-tester.puremagic.com/?projectid=10
Re: DDT 0.11.0 released
On Monday, 23 March 2015 at 15:30:43 UTC, Ben Boeckel wrote: On Mon, Mar 23, 2015 at 14:04:30 +, Dicebot via Digitalmars-d-announce wrote: If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works. Makes sense for -fversion and the like (it would be nice if libraries exported the list of version symbols they had since it is basically ABI...), but not necessarily for things like SSE support where you want to do runtime detection and run the fastest version based on the running processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with different compiler flags. I'd suggest to build such modules as separate static libraries (which is possible within dub). Risk remains but it at least becomes obvious for other developers that this needs care. Also parallel build of several static libraries should be generally faster than parallel builds of all modules 1-by-1 (overhead of single file compilation is huge because of redundant import analysis) Also don't forget that there are plenty of implicit versions that get added from compiler flags (like D_NoBoundsChecks or D_PIC).
[Issue 14280] Links to command line tools have disappeared from navigation
https://issues.dlang.org/show_bug.cgi?id=14280 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/ffaef43bfcb8b984e5ef58976ed00f3eeabfdf09 Merge pull request #929 from aG0aep6G/14280 mostly fix Issue 14280 - Links to command line tools have disappeared fr... --
[Issue 14321] No postblit call with struct and AA's
https://issues.dlang.org/show_bug.cgi?id=14321 --- Comment #2 from rswhi...@gmail.com --- (In reply to rswhite4 from comment #1) Forget to mention, my compiler is DMD v2.067.0-rc1 Seems to produce an ICE in 2.065: http://dpaste.dzfl.pl/362689545fb6 --
using vibe.d to parse json
Hi.
struct RawGoogleResults
{
string version_;
string status;
string sig;
string[string][][string] table;
}
enum json =
{version:0.6,status:ok,sig:717451517,table:{cols:[{id:date,label:Date,type:date,pattern:},{id:query0,label:euro
crisis,type:number,pattern:}],rows:[{c:[{v:2004-01-02),f:January
2004},{v:0.0,f:0}]},{c:[{v:2004-02-02),f:February
2004},{v:0.0,f:0}]},{c:[{v:2004-03-02),f:March
2004},{v:0.0,f:0}]},{c:[{v:2004-04-02)...
auto table = deserialize!(JsonSerializer, RawGoogleResults)(json);
I cannot pass a string to deserialize (the documentation suggests
an input range should be fine):
http://vibed.org/api/vibe.data.serialization/deserialize
I have a feeling maybe deserialize doesn't do what I want, but
what should I be using instead. (I would like to parse the json
and shove the results in the struct above).
Thanks.
Laeeth.
Re: Perlin noise benchmark speed
I'd suspect stdc.math to be SSE3/SSE4 optimised assembly, where as std.math uses a very generic (works on almost every float format) implementation that is at least 'pure'. Iain. On 24 Mar 2015 00:30, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 20 June 2014 at 12:32:39 UTC, Nick Treleaven wrote: Hi, A Perlin noise benchmark was quoted in this reddit thread: http://www.reddit.com/r/rust/comments/289enx/c0de517e_ where_is_my_c_replacement/cibn6sr It apparently shows the 3 main D compilers producing slower code than Go, Rust, gcc, clang, Nimrod: https://github.com/nsf/pnoise#readme I initially wondered about std.random, but got this response: Yeah, but std.random is not used in that benchmark, it just initializes 256 random vectors and permutates 256 sequential integers. What spins in a loop is just plain FP math and array read/writes. I'm sure it can be done faster, maybe D compilers are bad at automatic inlining or something. Obviously this is only one person's benchmark, but I wondered if people would like to check their code and suggest reasons for the speed deficit. I saw this thread when searching for something on the site, been a few months since anyone posted- I fixed the D flags, gdc is now about 15% faster than the second fastest in the benchmark(C - gcc) which obviously puts D in first. some notes: LDC is missing _tons_ of inline opportunities, killing it in comparison to GDC. I think GDC inlined pretty much everything. LDC is about 50% slower. Also, AFAICT there's no fast-math switch for LDC(enabling this for GDC might actually be compromising it though : ) ) I think LDC turns the floor in std.math into the same as the stdc one, but GDC does not. std.math.floor is still abysmally slow, I thought it was because it was still using reals but that does not seem to be the case. GDC slows to a crawl(10-20x slower) if you replace the stdc floor with the one in std.math(just remove the alias) I thought this might be interesting to someone(i.e, LDC/GDC folks or phobos math folks) bye.
Re: PrimitiveRef ?
Thanks a lot.
I read it in the D Cookbook from Adam D. Ruppe.
In the chapter of memory management there is a topic,
how to build reference counted objects. Here this
construct is explained.
Kind regards
André
On Monday, 23 March 2015 at 20:58:48 UTC, Namespace wrote:
Something like that?
struct PrimitiveRef(T)
{
private T* _value;
@property
ref inout(T) get() inout pure nothrow {
assert(_value);
return *_value;
}
alias get this;
this(T val) {
_value = new T(val);
}
}
alias BoolRef = PrimitiveRef!bool;
void test(BoolRef b)
{
b = true;
}
void main()
{
BoolRef b = false;
test(b);
assert(b == true);
}
Re: using vibe.d to parse json
On Tuesday, 24 March 2015 at 04:53:39 UTC, Laeeth Isharc wrote:
Hi.
struct RawGoogleResults
{
string version_;
string status;
string sig;
string[string][][string] table;
}
enum json =
{version:0.6,status:ok,sig:717451517,table:{cols:[{id:date,label:Date,type:date,pattern:},{id:query0,label:euro
crisis,type:number,pattern:}],rows:[{c:[{v:2004-01-02),f:January
2004},{v:0.0,f:0}]},{c:[{v:2004-02-02),f:February
2004},{v:0.0,f:0}]},{c:[{v:2004-03-02),f:March
2004},{v:0.0,f:0}]},{c:[{v:2004-04-02)...
auto table = deserialize!(JsonSerializer,
RawGoogleResults)(json);
I cannot pass a string to deserialize (the documentation
suggests an input range should be fine):
http://vibed.org/api/vibe.data.serialization/deserialize
I have a feeling maybe deserialize doesn't do what I want, but
what should I be using instead. (I would like to parse the
json and shove the results in the struct above).
Thanks.
Laeeth.
Okay - figured it out from the source code.
auto results = deserialize!(JsonStringSerializer!string,
RawGoogleResults)(json);
and easier to write:
struct RawGoogleResults
{
string version_;
string status;
string sig;
//Json!array[string][][string] table;
Json table;
}
Re: From the cycle Topic of the day - .gitignore: how big is too big?
On Mon, Mar 23, 2015 at 09:14:15AM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-03-22 02:15, Andrei Alexandrescu wrote: I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087. So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it? Not sure what you're complaining about. Shouldn't generated files be ignored? Or is the problem that they're not put in one single directory? [...] Word on the street is that the recommended way is to put all generated files in a dedicated directory rather than mix them in with source files. Doing so has other side benefits, like being able to parallel build for multiple targets without stomping over each other (assuming the generated files get placed in their respective architecture's subdirectory), avoiding stray orphan generated files causing heisenbugs (stale object file getting linked into the program overriding symbols from the real object file -- I've actually run into this at work, and it's very frustrating). But for Phobos, meh... just stick it in .gitignore and call it a day. No need to make such a big deal out of it. Tempest in a teacup. T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
[Issue 14313] [ld.gold] gdb: wrong value of shared variables
https://issues.dlang.org/show_bug.cgi?id=14313 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9bd7c7c24c5d30db21520d5edf8bf4433164a8e8 Fix Issue 14313 - [ld.gold] gdb: wrong value of shared variables https://github.com/D-Programming-Language/dmd/commit/13af2803c8a0463cae1ab611cda539d035e4b59f Merge pull request #4507 from tramker/bug14313 Fix Issue 14313 - [ld.gold] gdb: wrong value of shared variables --
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report?
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 15:36:42 UTC, Martin Nowak wrote: On 03/23/2015 02:49 PM, Szymon Gatner wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. As a matter of fact we only have few Windows developers, so unless someone with interest in this platform steps up it will hardly improve. Daniel Murphy did a lot of D/C++ integration to get ddmd to work, and apparently, that also works on Windows, so you might ask him for details. https://auto-tester.puremagic.com/?projectid=10 sure I could bug individuals to make things work for me, then discover another problem rinse and repeat. thing is i dont want things to somehow work (possibly only until next release that will breake it) I want to know that this is something that is cared about and can be considered mature (and i am looking for the weakest definition of mature possible)
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: i am typing from my phone so hard to find but i did post it on forums some time ago Posting about something on the forums won't get it fixed, make a bug report if you're encountering a bug.
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago here: http://forum.dlang.org/thread/hsglkscatlniiuacp...@forum.dlang.org#post-mailman.397.1409844359.5783.digitalmars-d-learn:40puremagic.com
DConf 2015 Schedule published
Dconf 2015's programme is on! http://dconf.org/2015/index.html I would like to thank everyone who submitted a proposal. We've had very strong proposals this year and a 50% acceptance rate, which made it very difficult to only choose half. Submitters are encouraged to join the conference; we'll have two panels and ample unstructured time during the evenings to keep discussions going. Last but not least, I encourage everyone in the community to register. The strength of any conference is ultimately decided by its attendees. We're operating at a loss to keep registration costs low, and chose a location that is accessible and affordable. Take the schedule to your employer or academic advisor and ask them if you can attend! Andrei
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/18/15 2:48 PM, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. If the idea is to force it on all users, I'm with deadalnix 100%. But what if -w makes ddoc do this, so you have a choice? Or some other switch? I would also find handy a switch to simply display publicly undocumented functions in the documentation. I recently went through and documented all core.stdc items with empty docs so they would just show up. Was actually quite monotonous. -Steve
Static Const Object Polymorphism
Hi folks.
I just recently started to discovered the D language,
I watched some videos about patterns, but I havent really
something that comes close to the pattern I'm going to present.
I hope the format of this post is correct.If so, I'm sorry to
have wasted your time. The idea behind this pattern is quite
simple, I call it
compile time object orientation. In essence we are replicating
some parts of the object oriented model, just at compile time.
The result will be extremly flexible and easily configurable code,
which to my knowledge can't be produced effectively otherwise,
at least not in languages like C, C++, Java, C# etc. (and maybe
D?)
The code that is used can be found here:
https://github.com/klodkevin/static_polymorphism_D
Let's first start with the problem we are trying to solve.
We are going to build a really generic Queue with
a lot of compile time options, that is:
- The type of the container item.
- A pop behavior that defines results for calling pop on an empty
queue. (Exception, return null, etc.)
- size parameter, with if set to true we get additional function
returning us the size.
- threaded behavior, setting this flag to true will give us
thread safety for each operation
- debugFlag, a flag that prints some debug info.
Parts of the queue is implemented in the source in queue.d.
Now the idea of this pattern is to simply create a compile time
constant object
called QueueOptions, that groups all these options together.
So instead of instantiating the Queue with all five parameters,
we simply have one container.
Here is some code:
enum EmptyBehavior
{
nullvalue,
exception,
ignored
}
// queue option definition
class QueueOptions
{
mixin polymorphType!(type, string);
mixin polymorphField!(bool, threaded, false);
mixin polymorphField!(bool, size, true);
mixin polymorphField!(EmptyBehavior, behavior,
EmptyBehavior.nullvalue);
mixin polymorphField!(bool, debugFlag, false);
}
// implementation for a queue.
class Queue(T)
{
private:
// poly
mixin polymorphCreate!(Q, T);
static if (Q.size)
size_t size;
// mutex for storage
static if (Q.threaded)
Mutex m;
... // further implementation.
}
// our class
class MyClass
{
this(bool t)
{
value = t;
}
bool value;
void print()
{
writeln(Have: ~ std.conv.to!string(value));
}
}
// overrides some of our default options
class Options : QueueOptions
{
mixin polymorphType!(type, MyClass);
mixin polymorphField!(behavior, EmptyBehavior.exception);
}
// some test
unittest
{
auto queue = new Queue!Options();
queue.push(new MyClass(true));
queue.push(new MyClass(false));
queue.push(new MyClass(false));
// remove and print
queue.pop().print();
queue.pop().print();
queue.pop().print();
// throws exception if uncommented.
//queue.pop();
}
What we do here is we apply some compiler magic to override
static const fields.
Here the QueueOptions class defines our five fields with default
values,
and the Options class derives from it, overriding the
EmptyBehavior
and the stored class. We now can use the class pretty easily and
uncommenting the last line yields to a thrown exception, as
specified.
To summarize this example, even if we had like 20 compile time
parameters,
we would still be able to get some nice syntax and a really
flexible way
of using our queue, depending on the need of the user.
The next example covers a sort algorithm.
The idea is the same as before. We make our sort algorithm really
flexible,
if we allow for some additional compile time object that contains
the info
on how to implement the sort. Here we define:
enum SortFunc
{
normal,
quick,
bubble,
random
}
class SortOptions
{
mixin polymorphField!(string, pred, a b);
mixin polymorphField!(bool, debugFlag, false);
}
class NormalSortOptions : SortOptions
{
mixin polymorphField!(SortFunc, method, SortFunc.normal);
mixin polymorphField!(SwapStrategy, strategy,
SwapStrategy.unstable);
}
class RandomSortOptions : SortOptions
{
mixin polymorphField!(SortFunc, method, SortFunc.random);
mixin polymorphField!(int, rng_param, 2);
}
unittest
{
// specify our sort function.
class Options2: RandomSortOptions
{
mixin polymorphField!(rng_param, 3);
mixin polymorphField!(debugFlag, true);
}
void rsort(Range)(Range r) { csort!(Options2)(r); }
// do some testing.
int[] a = [2, 3, 4, 1];
rsort(a);
assert(a == [1, 2, 3, 4]);
}
csort is our custom sort method. (sort.d)
As we see we override the default sort method
to use our random sort (ok the implementation is just a
Re: Making byLine faster: we should be able to delegate this
I made the same test in C# using a 30MB plain ASCII text file. Compared to fastest method proposed by Andrei, results are not the best: D: readText.representation.count!(c = c == '\n') - 428 ms byChunk(4096).joiner.count!(c = c == '\n') - 1160 ms C#: File.ReadAllLines.Length - 216 ms; Win64, D 2.066.1, Optimizations were turned on in both cases. The .net code is clearly not performance oriented (http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,675b2259e8706c26), I suspect that .net runtime is performing some optimizations under the hood. Does the C# version validate the input? Using std.file.read instead of readText.representation halves the runtime on my machine.
Re: DDT 0.11.0 released
On 2015-03-23 13:54, Bruno Medeiros wrote: There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. I would guess he means using C(++) files and D files in the same project and the build system would just work. -- /Jacob Carlborg
Re: Enhancement: issue error on all public functions that are missing ddoc sections
Anyone want to do a rough draft version of a script to build with some version of what Walter has suggested that produes just a simple number for each of druntime and phobos that are the number of undocumented functions? Bonus points for generating a output doc (preferably json) that contains useful data about what's missing to facilitate a website for navigating through the results. I'll set it up to run daily and graph and view the results. On 3/23/2015 12:04 PM, Steven Schveighoffer via Digitalmars-d wrote: On 3/18/15 2:48 PM, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. If the idea is to force it on all users, I'm with deadalnix 100%. But what if -w makes ddoc do this, so you have a choice? Or some other switch? I would also find handy a switch to simply display publicly undocumented functions in the documentation. I recently went through and documented all core.stdc items with empty docs so they would just show up. Was actually quite monotonous. -Steve
Re: pureity of closures
On Sunday, 22 March 2015 at 21:21:59 UTC, ketmar wrote: i believe that both ways is right (i.e. both generating error and not generating error). I am sorry but, this is not an helpful answer. I will stick to my callgraph analysis for now.
Re: pureity of closures
On Sunday, 22 March 2015 at 12:58:25 UTC, Stefan Koch wrote:
dmd infers function closures impure if impure functions are
defined within them.
even if those are never called and can never be accessed
outside of the closure.
Example :
int a;
void closure() pure {
impure_function() {
a++;
}
}
t.d(4): Error: pure function 't.closure.impure_function' cannot
access mutable static data 'a'
is this intended ?
I think this was not intended and is simply a side effect of
limited D call graph analysis. Relaxing that limitation makes
sense to me because unused impure function can be used for
compile-time reflection or returned from pure function as a
result (you need to ensure it does not capture pure functions as
closure context in that case)
Re: From the cycle Topic of the day - .gitignore: how big is too big?
On 2015-03-22 02:15, Andrei Alexandrescu wrote: I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087. So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it? Not sure what you're complaining about. Shouldn't generated files be ignored? Or is the problem that they're not put in one single directory? -- /Jacob Carlborg
Re: dfmt options
Jacob Carlborg: Although I would like that the D syntax allowed to drop the curly braces, like with if-satements. That would result in much nicer one-liner functions. See: https://issues.dlang.org/show_bug.cgi?id=7176 Bye, bearophile
[Issue 14320] New: Improve diagnostic message for undefined identifier error
https://issues.dlang.org/show_bug.cgi?id=14320
Issue ID: 14320
Summary: Improve diagnostic message for undefined identifier
error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
-- gui/widgget.d -
module gui.widget;
class Style {} // originally existed in gui.style
class Widget
{
Style style() {}
void layoutChildren(bool fit, Widget positionReference) {}
}
-- controls/tree.d ---
module controls.tree;
import gui.widget;
class Tree : Widget
{
override void layoutChildren(bool fit, Widget positionReference)
{
gui.style.Style st = style; // line 9
}
}
The error diagnostic is:
controls/tree.d(9): Error: undefined identifier 'style'
It actually explains the unexistent of module 'gui.style' in package 'gui', but
it sounds like the explanation for the invisibility of Widget.style() function.
I think it should be improved as follows:
controls/tree.d(9): Error: undefined identifier 'gui.style' in package 'gui'
--
[Issue 14320] Improve diagnostic message for undefined identifier error
https://issues.dlang.org/show_bug.cgi?id=14320 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4510 --
Re: Post increment and decrement
On Monday, 23 March 2015 at 08:20:59 UTC, Kagamin wrote: On Saturday, 21 March 2015 at 16:59:05 UTC, welkam wrote: In C++ world always writing ++var can save some perf when using with overloaded operators. Do you have an example? The compiler cannot optimize away calls to external functions (such as operator new, as is my experience) that it cannot inline/see fully (I may be not 100% correct here, but I'm pretty sure it's in the right ballpark). Here's an example, compare foo() and bar() (note the -O3): http://goo.gl/H9tCaK
Re: DWT on Mac OS X and with DMD 2
On 2015-03-22 15:41, romain wrote: Hi. I think i might be interested in helping porting from d1 to d2 as far as the Os x version is concerned, even though i don't really know how i could go about that. Any pointer or help would be appreciated. I'm not sure if that's a good idea before the Java - D1 port is finished. If you run in to a bug it's hard to know if it's the Java - D1 port or the D1 - D2 port that caused the bug. I got tried of the manual porting so I'm trying out a new approach to port DWT. That is to create a tool that automatically convert the Java code to D (2). I've created a new project JPort [1], it's written in Scala and uses the Eclipse JDT compiler API's to translate Java to D. It's in a very early stage. If you really do want to port the D1 code to D2 you just need to start rewriting the parts that has changed from D1 to D2. I'm not sure if there's a list of changes between D1 and D2. Looking at the changelog will give you some hints, but it might be too detailed. The -vtls compiler flag will help to show which variables will be but in TLS. The code for the OS X port is available here [2]. The readme in that repository will have some documentation on how to port the Java code to D that is unique to the OS X port. [1] https://github.com/d-widget-toolkit/jport/tree/dev [2] https://github.com/d-widget-toolkit/dwt-mac -- /Jacob Carlborg
Re: A reason to choose D over Go
On Sunday, March 22, 2015 02:32:36 deadalnix via Digitalmars-d wrote: On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens What is the type of b here ? int* a, b; Which is one reason never to declare multiple variables on the same line in C/C++. I never understood why C/C++ made it so that the * went with the variable rather than being treated like part of the type, since in reality, the * is part of the type. I'm definitely glad that D fixed that and made it so that the a and b in your example are both pointers. But much as I hate it when folks put the * next to the variable name in C/C++ instead of putting it with the rest of the type, your example shows exactly why many people put it with the variable name. - Jonathan M Davis
Re: From the cycle Topic of the day - .gitignore: how big is too big?
On Saturday, March 21, 2015 22:56:58 Andrei Alexandrescu via Digitalmars-d wrote: On 3/21/15 8:54 PM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mel52r$252b$1...@digitalmars.com... I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087. So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it? We add it to the .gitignore, then forget about it forever. Having a long gitignore doesn't cost us anything. ... but complicated/wrong clean rules in makefiles and clutter in ls. We should clean our shit. -- Andrei Agreed. - Jonathan M Davis
Re: From the cycle Topic of the day - .gitignore: how big is too big?
bOn Sunday, 22 March 2015 at 21:08:27 UTC, Andrei Alexandrescu wrote: On 3/22/15 1:37 PM, Mengu wrote: while we're at it, let's add D to this list: https://github.com/github/gitignore That's be cool, any takers? -- Andrei btw, i think it'd be good if dub would automatically include this .gitignore file to generated projects.
Re: dfmt options
On Sunday, 22 March 2015 at 17:05:27 UTC, Martin Nowak wrote: I think there should be an option (even default on) to allow small single line functions. (snip) Perhaps it's too much to wish for, but I think the editor would be the better place for this. IntelliJ IDEA can display short methods as single line. They're still multiline in the source, but on screen they're nice. They used a similar thing with anonymous classes in Java prior to lambdas hitting the language, making single method anonymous classes look almost like the lambdas do today.
Re: dfmt options
On 2015-03-22 18:05, Martin Nowak wrote:
Sorry haven't read the whole thread.
I think there should be an option (even default on) to allow small
single line functions.
This can sometimes be fairly annoying. For example when writing range
adapters, see
https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216.
bool empty() { return arr.length == 0; }
T opIndex(size_t i) { return arr[idx]; }
T front() { return arr[0]; }
void popFront() { arr = arr[1 .. $]; }
I really don't like this way of formatting code. Although I would like
that the D syntax allowed to drop the curly braces, like with
if-satements. That would result in much nicer one-liner functions.
--
/Jacob Carlborg
Re: Post increment and decrement
On Saturday, 21 March 2015 at 16:59:05 UTC, welkam wrote: In C++ world always writing ++var can save some perf when using with overloaded operators. Do you have an example?
Re: PrimitiveRef ?
On Monday, 23 March 2015 at 16:58:49 UTC, Andre wrote:
Hi,
(needed for specifying reference behavior in a type tuple).
I need exactly that behavior. I am currently unsure whether it
is possible at all to have such a construct which works at user
side exactly like a boolean (booleans can be assigned and
directly compared with ==) but internally are pointers...
(The coding does not compile)
Kind regards
André
struct PrimitiveRef(T)
{
private T* _value;
alias _value this;
void opAssign(T v)
{
_value = v;
}
}
alias BoolRef = PrimitiveRef!bool;
void test(BoolRef b)
{
b = true;
}
void main()
{
BoolRef b = false;
test(b);
assert(b == true);
}
even if the code would compile you'd get an AV because _value is
null.
Then when you initalize b with false this could not work because
false is not a a pointer to a bool.
struct PrimitiveRef(T)
{
private T* _value;
alias _value this;
void opAssign(T v)
{
*_value = v;
}
}
alias BoolRef = PrimitiveRef!bool;
void test(BoolRef b)
{
b = true;
}
bool btarget;
void main()
{
BoolRef b;
b._value = btarget;
test(b);
assert(*b == true);
}
I don't know where you've read this, but i 'm interseted too.
Maybe it's an ABI thing: since the only member is a reference (so
`size_t.sizeof` bytes) the `struct` can be passed in a register
during the function call, instead of being copied on the stack...
---
void foo(BoolRef aRef)
{
// x86: aRef is in EAX
// X86_64 aRef is in RAX
}
---
What is the source of I read that if a structure only contains a
reference, it will behave like a reference type in function
calls ?
Re: Making byLine faster: we should be able to delegate this
On 3/23/15 2:13 PM, rumbu wrote: Since this code is clearly not the best for this task, as I suspected, I looked into jitted code and it seems that the .net runtime is smart enough to recognize this pattern and is doing the following: - file is mapped into memory using CreateFileMapping - does not perform any decoding, since \r and \n are ASCII - does not create any list - searches incrementally for \r, \r\n, \n using CompareStringA and LOCALE_INVARIANT and increments at each end of line - there is no temporary memory allocation since searching is performed directly on the mapping handle - returns the count. This is great investigative and measuring work. Thanks! -- Andrei
Where's This week in D?
No issue for the past week? -- Andrei
Re: PrimitiveRef ?
Something like that?
struct PrimitiveRef(T)
{
private T* _value;
@property
ref inout(T) get() inout pure nothrow {
assert(_value);
return *_value;
}
alias get this;
this(T val) {
_value = new T(val);
}
}
alias BoolRef = PrimitiveRef!bool;
void test(BoolRef b)
{
b = true;
}
void main()
{
BoolRef b = false;
test(b);
assert(b == true);
}
Solution to problems:
If D had an ide that could do the following I think development and testing could be better managed. 1. IDE that works with a centralized server to be able to change D versions at a drop of a time. e.g., click Master and it checks to see if you have the latest, if not it downloads it, configures it, and sets it up hands free to be used. (If it requires any interaction to work then it is a bug) 2. Patches, bugs, and everything else can be accessed through this IDE. Collaboration can be made between groups of people and individuals. Announcements could be made by head honchos. (In fact, this software could be more generic and used by anyone for any purpose of collaboration in programming... e.g. with php). One can see open bugs, issues, workarounds, etc at a click. 3. Projects could be collaborated on easily with people being able to watch(RD) another persons session(say for debugging help or whatever). 4. The ability to connect resources to projects. e.g. insert a note over a function that links to the D documentation about a bug. 5. etc. If such an IDE existed so that anyone could simply run it, open a bug and start working without having to go through a massive change(by quick, I mean click of a button), then I think people would be more willing to help. The number one reason I don't contribute is that I don't have the time to dedicate to maintain all the knowledge and software/organization to fit it in my schedule. I suspect that is most everyone excuse too. I don't want to spend 30mins to an hour to download the latest version, compile it if I have to, make sure all the configuration stuff is correct, create a setup program... just to find out there is a bug in the latest version at the end. I'm simply not that dedicated to D. Again, I suspect most people aren't. You have really dedicated people here but not enough to get everything that needs to be done, done. Instead, find out how to leverage all the people that would help if you make it worth their time. It might be slower in the short term but better in the long term. In 10 more years I doubt Andrei or Walter will have as much energy to do all the work that they are doing... Better build the infrastructure now while there is time.
Re: Template reference parameter
On Mon, 23 Mar 2015 22:01:03 +, rumbu wrote:
I'm trying to construct a struct template where one of the template
parameters is passed by reference (as option)
struct S(T, U)
{
void opCall(T t, U u) { }
}
alias X = S!(T, U);
alias RX = S!(T, ref U); //not working
The objective is to call X(t, u) or RX(t, u), but in second case I want
u to be passed by reference.
The only solution I found is to pass U as a pointer or as a class.
`ref` is not a part of a type, so you can't do it like this. you have to
have two different templates for that. or try to use `auto ref`, it may
help.
signature.asc
Description: PGP signature
Re: Making byLine faster: we should be able to delegate this
On Monday, 23 March 2015 at 19:25:08 UTC, Tobias Pankrath wrote:
I made the same test in C# using a 30MB plain ASCII text file.
Compared to fastest method proposed by Andrei, results are not
the best:
D:
readText.representation.count!(c = c == '\n') - 428 ms
byChunk(4096).joiner.count!(c = c == '\n') - 1160 ms
C#:
File.ReadAllLines.Length - 216 ms;
Win64, D 2.066.1, Optimizations were turned on in both cases.
The .net code is clearly not performance oriented
(http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,675b2259e8706c26),
I suspect that .net runtime is performing some optimizations
under the hood.
Does the C# version validate the input? Using std.file.read
instead of readText.representation halves the runtime on my
machine.
Source code is available at the link above. Since the C# version
works internally with streams and UTF-16 chars, the pseudocode
looks like this:
---
initilialize a LIST with 16 items;
while (!eof)
{
read 4096 bytes in a buffer;
decode them to UTF-16 in a wchar[] buffer
while (moredata in the buffer)
{
read from buffer until (\n or \r\n or \r);
discard end of line;
if (nomorespace in LIST)
double its size.
add the line to LIST.
}
}
return number of items in the LIST.
---
Since this code is clearly not the best for this task, as I
suspected, I looked into jitted code and it seems that the .net
runtime is smart enough to recognize this pattern and is doing
the following:
- file is mapped into memory using CreateFileMapping
- does not perform any decoding, since \r and \n are ASCII
- does not create any list
- searches incrementally for \r, \r\n, \n using CompareStringA
and LOCALE_INVARIANT and increments at each end of line
- there is no temporary memory allocation since searching is
performed directly on the mapping handle
- returns the count.
Template reference parameter
I'm trying to construct a struct template where one of the
template parameters is passed by reference (as option)
struct S(T, U)
{
void opCall(T t, U u) { }
}
alias X = S!(T, U);
alias RX = S!(T, ref U); //not working
The objective is to call X(t, u) or RX(t, u), but in second case
I want u to be passed by reference.
The only solution I found is to pass U as a pointer or as a class.
Re: Making byLine faster: we should be able to delegate this
On 3/23/15 10:59 AM, Andrei Alexandrescu wrote: On 3/23/15 7:52 AM, Steven Schveighoffer wrote: On 3/22/15 3:03 AM, Andrei Alexandrescu wrote: * assumeSafeAppend() was unnecessarily used once per line read. Its removal led to a whopping 35% on top of everything else. I'm not sure what it does, but boy it does takes its sweet time. Maybe someone should look into it. That's not expected. assumeSafeAppend should be pretty quick, and DEFINITELY should not be a significant percentage of reading lines. I will look into it. Thanks! Just to verify, your test application was a simple byline loop? Yes, the code was that in http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508#29153508 My investigation seems to suggest that assumeSafeAppend is not using that much time for what it does. The reason for the 35% is that you are talking 35% of a very small value. At that level, and with these numbers of calls, combined with the fact that the calls MUST occur (these are opaque functions), I think we are talking about a non issue here. This is what assumeSafeAppend does: 1. Access TypeInfo and convert array to void[] array (this could probably be adjusted to avoid using the TypeInfo, since assumeSafeAppend is a template). 2. Look up block info, which should be a loop through 8 array cache elements. 3. Verify the block has the APPENDABLE flag, and write the new used space into the right place. I suspect some combination of memory cache failures, or virtual function calls on the TypeInfo, or failure to inline some functions is what's slowing it down. But let's not forget that the 35% savings was AFTER all the original savings. On my system, using a 2 million line file, the original took 2.2 seconds, the version with the superfluous assumeSafeAppend took .3 seconds, without it takes .15 seconds. Still should be examined further, but I'm not as concerned as I was before. -Steve
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:11:12 UTC, Kapps wrote: On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: i am typing from my phone so hard to find but i did post it on forums some time ago Posting about something on the forums won't get it fixed, make a bug report if you're encountering a bug. i posted it on forums because i wasnt sure if it was indeed a bug or just me. also it is hard to provide minimal app when mixing code and under msvc as potentially full project is needed. i do get your point tho
Re: Making byLine faster: we should be able to delegate this
On Monday, 23 March 2015 at 15:00:07 UTC, John Colvin wrote: What would be really great would be a performance test suite for phobos. I'm working on it https://github.com/D-Programming-Language/phobos/pull/2995
PrimitiveRef ?
Hi,
I read that if a structure only contains a reference, it will
behave like a reference type in function calls (needed for
specifying reference behavior in a type tuple).
I need exactly that behavior. I am currently unsure whether it is
possible at all to have such a construct which works at user side
exactly like a boolean (booleans can be assigned and directly
compared with ==) but internally are pointers...
(The coding does not compile)
Kind regards
André
struct PrimitiveRef(T)
{
private T* _value;
alias _value this;
void opAssign(T v)
{
_value = v;
}
}
alias BoolRef = PrimitiveRef!bool;
void test(BoolRef b)
{
b = true;
}
void main()
{
BoolRef b = false;
test(b);
assert(b == true);
}
DConf schedule: share, discuss, vote!
Please help us spread the word on DConf 2015. We have a strong schedule this year. Share with your coworkers and friends. Talk to your manager about attending. Be there! https://www.facebook.com/dlang.org/posts/1037831199563894 https://www.reddit.com/r/programming/comments/3010w6/the_d_programming_language_conference_2015/ https://twitter.com/D_Programming/status/580048927178629120 Andrei
Re: A few notes on choosing between Go and D for a quick project
On 2015-03-23 at 12:59, krzaq wrote: I'd argue that joiner is intuitive enough, but I agree on byChunk. I am also baffled why this byLine/byChunk madness is necessary at all, it should be something like File(path).startsWith(s) or File(path).data.startswith(s) Yeah, that would be useful for example to test magic values at the beginning of files: string[] scripts; foreach (string path; dirEntries(topDir, SpanMode.depth)) if (isFile(path) File(path).startsWith(#!)) scripts ~= path; but that's the simplest case of a bigger problem, because here you just need the first few bytes, and you don't want to read the whole file, nor anything more than a sector. OTOH, there are also file formats like ZIP that put the meta information at the end of the file and scatter the rest of the data all over the place using offset information. You don't need to read everything just to grab the metadata. But, when I had a look at the sources of libzip, I went crazy seeing all the code performing tons of file seeking, reading into buffers and handling them[1]. D's std.zip took a simple approach and doesn't deal with that at all; it reads the whole file into the memory. That makes the algorithm more clearly visible, but at the same time it makes the module completely useless if you want to handle archives that are larger than the available memory, and over-the-top if all you wanted was to extract a single file from the archive or only read the directory structure. So, how do you envision something representing a file, i.e. a mix of BufferedRange and SeekableRange, that would neatly handle buffering and seeking, without you dropping to stdc IO or wanting to shoot yourself when you look at the code? [1] for your amusement: http://hg.nih.at/libzip/file/78b8e3fa72a0/lib/zip_open.c
Re: Making byLine faster: we should be able to delegate this
On 3/23/15 10:43 AM, rumbu wrote:
On Monday, 23 March 2015 at 15:00:07 UTC, John Colvin wrote:
What would be really great would be a performance test suite for
phobos. D is reaching a point where It'll probably be fast because we
did it right or I remember it being fast-ish 3 years ago when i
wrote a small toy test isn't going to cut it. Real data is needed,
with comparisons to other languages where possible.
I made the same test in C# using a 30MB plain ASCII text file. Compared
to fastest method proposed by Andrei, results are not the best:
D:
readText.representation.count!(c = c == '\n') - 428 ms
byChunk(4096).joiner.count!(c = c == '\n') - 1160 ms
C#:
File.ReadAllLines.Length - 216 ms;
Win64, D 2.066.1, Optimizations were turned on in both cases.
The .net code is clearly not performance oriented
(http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,675b2259e8706c26),
I suspect that .net runtime is performing some optimizations under the
hood.
At this point it gets down to the performance of std.algorithm.count,
which could and should be improved. This code accelerates speed 2.5x
over count and brings it in the zone of wc -l, which is probably near
the lower bound achievable:
auto bytes = args[1].readText.representation;
for (auto p = bytes.ptr, lim = p + bytes.length;; )
{
import core.stdc.string;
auto r = cast(immutable(ubyte)*) memchr(p, '\n', lim - p);
if (!r) break;
++linect;
p = r + 1;
}
Would anyone want to put some work into accelerating count?
Andrei
[Issue 14317] [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline
https://issues.dlang.org/show_bug.cgi?id=14317 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e52968b55483de0ae2867ca13855e957cb4be5ba fix Issue 14317 - [REG2.066] ICE (cgcod.c 1767) when compiing with -profile -O -inline --
Re: Where is my memory?
On 3/22/15 6:32 AM, anonymous wrote:
On Sunday, 22 March 2015 at 09:42:41 UTC, Ozan Süel wrote:
Hi!
I'm working on a Big Data project, where a huge amount of RAM is
needed. Using D I've run into a - let's called it - memory leak. I
tested this with following code:
foreach(i; 0..1000) {
int[] ints;
foreach(j; 0..1000) {
ints ~= uniform(0, 100);
}
}
Without the first foreach this code use only 220KB,
with the first foreach this code needs 2,5MB.
(220KB x 1000 is something around 2,5MB).
220KB x 1000 would be around 200MB.
But why is GC (Garbage Collector) not running? Following the
explanations in http://wiki.dlang.org/Memory_Management memory usage
should be something around 220KB.
The GC is running. 1000 x 1000 ints would be 4MB. That alone is more
than the 2.5MB you're observing.
I used GC.minimize, slow down the loop, replaced uniform...doesn't work.
(By the way: After a while my LINUX server killed my big data project
because running out of RAM SWAP space)
GC.minimize alone can't do anything if the memory isn't collected. Use
GC.collect(), too.
Also, if you know the final size of the array beforehand, you can
`reserve` it. That avoids a lot of copying (and garbage creation) when
appending.
int[] ints;
ints.reserve(1000); /* - */
foreach(j; 0..1000) {
ints ~= uniform(0, 100);
}
Another tip, don't throw away that memory you allocated!
int[] ints;
ints.reserve(1000);
foreach(i; 0..1000)
{
ints.length = 0;
ints.assumeSafeAppend;
... // inner loop
}
-Steve
Re: DConf schedule: share, discuss, vote!
On Monday, 23 March 2015 at 17:17:19 UTC, Andrei Alexandrescu wrote: Please help us spread the word on DConf 2015. We have a strong schedule this year. Share with your coworkers and friends. Talk to your manager about attending. Be there! https://www.facebook.com/dlang.org/posts/1037831199563894 https://www.reddit.com/r/programming/comments/3010w6/the_d_programming_language_conference_2015/ https://twitter.com/D_Programming/status/580048927178629120 Andrei The link to the schedule seems to be broken on Reddit http://dconf.org/2015/index.html?schedule should be http://dconf.org/2015/schedule/index.html Piotrek
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/20/15 7:25 PM, Walter Bright wrote: On 3/19/2015 3:13 PM, Jeremy Powers via Digitalmars-d wrote: A valid reason for doing things like this is future-proof encapsulation. You can change the internal foo to be something entirely different, and the external api never changes (assuming 'foo' is private). That's why D has properties. Fields can be replaced with property functions. Replacing fields for properties and vice versa is an incompatible API change. -Steve
Re: Making byLine faster: we should be able to delegate this
On Monday, 23 March 2015 at 15:00:07 UTC, John Colvin wrote: What would be really great would be a performance test suite for phobos. D is reaching a point where It'll probably be fast because we did it right or I remember it being fast-ish 3 years ago when i wrote a small toy test isn't going to cut it. Real data is needed, with comparisons to other languages where possible. I made the same test in C# using a 30MB plain ASCII text file. Compared to fastest method proposed by Andrei, results are not the best: D: readText.representation.count!(c = c == '\n') - 428 ms byChunk(4096).joiner.count!(c = c == '\n') - 1160 ms C#: File.ReadAllLines.Length - 216 ms; Win64, D 2.066.1, Optimizations were turned on in both cases. The .net code is clearly not performance oriented (http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,675b2259e8706c26), I suspect that .net runtime is performing some optimizations under the hood.
Re: [Semi OT] The programming language wars
On Monday, 23 March 2015 at 10:40:12 UTC, Paulo Pinto wrote: On Saturday, 21 March 2015 at 19:20:18 UTC, deadalnix wrote: On Saturday, 21 March 2015 at 15:51:38 UTC, Paulo Pinto wrote: I don't expect programming will remain so low level in the future. We are at the infancy of our skills, when comparing with engineerings with a fee centuries of progress. For me the future lyes in something like Wolfram/Mathematic with natural voice processing. People have been saying this for longer than I'm alive. You missed my remark about the age of computing versus other arts from engineering. We are still building bridges with wood and houses with clay. - Paulo Maybe, and we will certainly see more of this in the future. However, that future may be far away, considering it is promised for decades at this point and still not up and running. Also, someone will have to code these systems, so the job we do now will still be necessary.
Re: Solution to problems:
On Monday, 23 March 2015 at 21:34:09 UTC, Jake The Baker wrote: If D had an ide that could do the following I think development and testing could be better managed. 1. IDE that works with a centralized server to be able to change D versions at a drop of a time. e.g., click Master and it checks to see if you have the latest, if not it downloads it, configures it, and sets it up hands free to be used. (If it requires any interaction to work then it is a bug) 2. Patches, bugs, and everything else can be accessed through this IDE. Collaboration can be made between groups of people and individuals. Announcements could be made by head honchos. (In fact, this software could be more generic and used by anyone for any purpose of collaboration in programming... e.g. with php). One can see open bugs, issues, workarounds, etc at a click. 3. Projects could be collaborated on easily with people being able to watch(RD) another persons session(say for debugging help or whatever). 4. The ability to connect resources to projects. e.g. insert a note over a function that links to the D documentation about a bug. 5. etc. If such an IDE existed so that anyone could simply run it, open a bug and start working without having to go through a massive change(by quick, I mean click of a button), then I think people would be more willing to help. The number one reason I don't contribute is that I don't have the time to dedicate to maintain all the knowledge and software/organization to fit it in my schedule. I suspect that is most everyone excuse too. I don't want to spend 30mins to an hour to download the latest version, compile it if I have to, make sure all the configuration stuff is correct, create a setup program... just to find out there is a bug in the latest version at the end. I'm simply not that dedicated to D. Again, I suspect most people aren't. You have really dedicated people here but not enough to get everything that needs to be done, done. Instead, find out how to leverage all the people that would help if you make it worth their time. It might be slower in the short term but better in the long term. In 10 more years I doubt Andrei or Walter will have as much energy to do all the work that they are doing... Better build the infrastructure now while there is time. VCS (Git in this case) and Make are tools of the trade. If a developer cannot use these tools following instructions provided in the Wiki [1] they probably won't have much in the way of useful contributions to Phobos or the compiler. Bye, lobo [1] http://wiki.dlang.org/Pull_Requests
Re: Making byLine faster: we should be able to delegate this
On 3/23/15 2:42 PM, Steven Schveighoffer wrote: On 3/23/15 10:59 AM, Andrei Alexandrescu wrote: On 3/23/15 7:52 AM, Steven Schveighoffer wrote: On 3/22/15 3:03 AM, Andrei Alexandrescu wrote: * assumeSafeAppend() was unnecessarily used once per line read. Its removal led to a whopping 35% on top of everything else. I'm not sure what it does, but boy it does takes its sweet time. Maybe someone should look into it. That's not expected. assumeSafeAppend should be pretty quick, and DEFINITELY should not be a significant percentage of reading lines. I will look into it. Thanks! Just to verify, your test application was a simple byline loop? Yes, the code was that in http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508#29153508 My investigation seems to suggest that assumeSafeAppend is not using that much time for what it does. The reason for the 35% is that you are talking 35% of a very small value. I don't see the logic here. Unless the value is so small that noise margins become significant (it isn't), 35% is large. At that level, and with these numbers of calls, combined with the fact that the calls MUST occur (these are opaque functions), I think we are talking about a non issue here. I disagree with this assessment. In this case it takes us from losing to winning to Python. This is what assumeSafeAppend does: 1. Access TypeInfo and convert array to void[] array (this could probably be adjusted to avoid using the TypeInfo, since assumeSafeAppend is a template). 2. Look up block info, which should be a loop through 8 array cache elements. 3. Verify the block has the APPENDABLE flag, and write the new used space into the right place. I suspect some combination of memory cache failures, or virtual function calls on the TypeInfo, or failure to inline some functions is what's slowing it down. But let's not forget that the 35% savings was AFTER all the original savings. On my system, using a 2 million line file, the original took 2.2 seconds, the version with the superfluous assumeSafeAppend took .3 seconds, without it takes .15 seconds. Still should be examined further, but I'm not as concerned as I was before. We should. Andrei
[Issue 14323] New: Bad code generation in dfmt
https://issues.dlang.org/show_bug.cgi?id=14323 Issue ID: 14323 Summary: Bad code generation in dfmt Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Keywords: wrong-code Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: briancsch...@gmail.com dfmt at commit 48bc7ba0c2c115d3ba3175b591da4b46db57cb95 exhibits a code generation bug. dfmt is located at https://github.com/Hackerpilot/dfmt To reproduce, check out that specific commit and run make test with the line containing version = WTF_DMD; commented out. The code also seems to be sensitive to whether or not the -O flag is enabled. I've inspected the ASM dumps of the program and haven't been able to figure out exactly where things are going wrong. I'll work on reducing this to a smaller test case. --
Re: Perlin noise benchmark speed
On Friday, 20 June 2014 at 12:32:39 UTC, Nick Treleaven wrote: Hi, A Perlin noise benchmark was quoted in this reddit thread: http://www.reddit.com/r/rust/comments/289enx/c0de517e_where_is_my_c_replacement/cibn6sr It apparently shows the 3 main D compilers producing slower code than Go, Rust, gcc, clang, Nimrod: https://github.com/nsf/pnoise#readme I initially wondered about std.random, but got this response: Yeah, but std.random is not used in that benchmark, it just initializes 256 random vectors and permutates 256 sequential integers. What spins in a loop is just plain FP math and array read/writes. I'm sure it can be done faster, maybe D compilers are bad at automatic inlining or something. Obviously this is only one person's benchmark, but I wondered if people would like to check their code and suggest reasons for the speed deficit. I saw this thread when searching for something on the site, been a few months since anyone posted- I fixed the D flags, gdc is now about 15% faster than the second fastest in the benchmark(C - gcc) which obviously puts D in first. some notes: LDC is missing _tons_ of inline opportunities, killing it in comparison to GDC. I think GDC inlined pretty much everything. LDC is about 50% slower. Also, AFAICT there's no fast-math switch for LDC(enabling this for GDC might actually be compromising it though : ) ) I think LDC turns the floor in std.math into the same as the stdc one, but GDC does not. std.math.floor is still abysmally slow, I thought it was because it was still using reals but that does not seem to be the case. GDC slows to a crawl(10-20x slower) if you replace the stdc floor with the one in std.math(just remove the alias) I thought this might be interesting to someone(i.e, LDC/GDC folks or phobos math folks) bye.
