Re: New D tool releases
On Sunday, 28 June 2015 at 14:03:21 UTC, Dmitry wrote: On Monday, 8 June 2015 at 19:18:03 UTC, Brian Schott wrote: Dfmt 0.4.0-beta1 and 0.3.6 https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.6 Integration with Sublime Text (I use Sublime Text 2 and Windows) https://github.com/dmi7ry/dfmt-sublime can anyone check? Why not Sublime Text 3?
Re: Announcing libasync, a cross-platform D event loop
On Sunday, 28 June 2015 at 15:09:25 UTC, Suliman wrote:
On Saturday, 27 September 2014 at 18:21:18 UTC, Etienne wrote:
On 2014-09-27 2:13 PM, Etienne wrote:
engine (I have an ASN1 library in the works as well).
It's nearly finished, it will allow BER/DER serialization to
take place from UDAs and native types at compile-time:
https://github.com/globecsys/asn1.d
/// Usage: run() the object, start watching directories,
receive an event in your handler,
/// read the changes by draining the buffer.
Could you show how to use it for monitoring FS?
I did
import libasync.watcher;
So now I need simply call run()? But how to pass folder path to
it?
void main()
{
bool run()
{
return 0;
}
}
It's seems that I missing something...
You can see an example in libasync.tests
Re: auto ref is on the docket
On Sunday, 28 June 2015 at 13:08:48 UTC, rsw0x wrote: On Sunday, 28 June 2015 at 11:06:01 UTC, Marc Schütz wrote: On Sunday, 28 June 2015 at 07:36:41 UTC, Jonathan M Davis wrote: It makes no sense to pass rvalues by ref. The ref has to refer to a memory location so that a pointer can be passed underneath the hood, and rvalues don't qualify for that. I strongly disagree with that. This is an implementation detail. `ref` describes a specific semantic, namely that no copying (observable by a postblit being called) takes place, no, it means pass by reference. this sounds like some convoluted C++ doublespeak definition. Well, try experimenting with LDC with -O3 -output-s on some test programs. You will be surprised ;-) There will often be no reference in the resulting output, especially with inlining. The definition I used is not necessarily the best one, but it needs to be based on observable behaviour, not implementation specifics, otherwise compilers would have no freedom in optimizing.
Map Purity
My understanding of pure is that a function labeled pure can only
include pure functions. I've been confused by the fact that a
function calling map (like below) can be labeled pure without any
problems. The only way I can rationalize it is that map really
isn't a function, it's (if I'm understanding it correctly) a
template that creates a template function that calls a struct
template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
Re: Announcing libasync, a cross-platform D event loop
On Saturday, 27 September 2014 at 18:21:18 UTC, Etienne wrote:
On 2014-09-27 2:13 PM, Etienne wrote:
engine (I have an ASN1 library in the works as well).
It's nearly finished, it will allow BER/DER serialization to
take place from UDAs and native types at compile-time:
https://github.com/globecsys/asn1.d
/// Usage: run() the object, start watching directories, receive
an event in your handler,
/// read the changes by draining the buffer.
Could you show how to use it for monitoring FS?
I did
import libasync.watcher;
So now I need simply call run()? But how to pass folder path to
it?
void main()
{
bool run()
{
return 0;
}
}
It's seems that I missing something...
Re: version: multiple conditions
On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
So you're trying to avoid writing this?
version(linux) version(D_LP32)
version = valistIsCharPointer;
else version(Windows)
version = valistIsCharPointer;
While your version is more concise, I actually think the
current form is more clear.
And wrong. Spot the bug.
Eh, that idiom is not commonly used so I wasn't exactly clear on
the syntax, but you're presumably referring to the need for
braces?
version(linux)
{ version(D_LP32) version = valistIsCharPointer; }
else version(Windows)
version = valistIsCharPointer;
I actually find this even more clear, the best of the bunch. :)
That's the real reason why 'version' needs to be banned from
the codebase. You should *never* use D's 'version'.
If you think it needs to be banned because of some non-obvious
bracing syntax, you don't have much to stand on.
Re: Announcing libasync, a cross-platform D event loop
On Sunday, 28 June 2015 at 16:32:24 UTC, Suliman wrote: You can see an example in libasync.tests thanks! I have got few questions g_cbCheck = new shared bool[19]; what does it do? AsyncDirectoryWatcher g_watcher = new AsyncDirectoryWatcher(getThreadEventLoop()); Am I right understand that it's run new eventloop inside AsyncDirectoryWatcher function? The g_cbCheck is specific to this unit test, everytime a callback succeeds it will set its index to true in the array. The event loop must be passed to the async object because the watcher will register itself to it when it is run. When you've registered your callback in the watcher and run it through the event loop, you have to run the event loop and events will be pushed to your callback
Re: Announcing libasync, a cross-platform D event loop
On Sunday, 28 June 2015 at 16:57:44 UTC, Suliman wrote: Also next code that I take from example after run absolutely do not do nothing: This code will register a directory watcher in the working directory, on the thread's event loop, and then use timers to create file/folder activity to trigger this directory watcher. The only thing needed to make this work is r/w access to the working directory and a running event loop. So, adding the line: g_evl.run(10.seconds); If you don't have an event loop running, your application is basically not going to receive callback events.
Re: Announcing libasync, a cross-platform D event loop
Hmm, sorry that would be g_evl.loop(10.seconds) or
getThreadEventLoop().loop(10.seconds). I use the vibe.d driver
most often.
I changed paths to hardcoded to prevent issue with them, but next
code after run only create hey folder and nothing more. No
files in it:
{
void dirWatcher()
{
auto g_watcher = new
AsyncDirectoryWatcher(getThreadEventLoop());
g_watcher.run({
DWChangeInfo[1] change;
DWChangeInfo[] changeRef = change.ptr[0..1];
while(g_watcher.readChanges(changeRef)){
writeln(change);
}
});
g_watcher.watchDir(.);
AsyncTimer tm = new AsyncTimer(getThreadEventLoop());
tm.duration(1.seconds).run({
writeln(Creating directory ./hey);
mkdir(`D:\code\DirWathcher\hey`);
assert(g_watcher.watchDir(`D:\code\DirWathcher\hey`));
tm.duration(4.seconds).run({
writeln(Writing to ./hey/tmp.tmp for the first
time);
std.file.write(`D:\code\DirWathcher\hey\tmp.tmp`, some
string);
tm.duration(100.msecs).run({
writeln(Removing ./hey/tmp.tmp);
remove(`D:\code\DirWathcher\hey\tmp.tmp`);
});
});
});
getThreadEventLoop().loop(10.seconds);
}
dirWatcher();
destroyAsyncThreads();
}
--
And how to detect if some there was some manipulation inside
monitoring folder? How I can recive name of file that was added
to folder?
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 21:40:49 UTC, Atila Neves wrote: I'd have to benchmark it against something, but I'm pretty sure cerealed is fast. Faster than msgpack?
Re: New D tool releases
On Monday, 8 June 2015 at 19:18:03 UTC, Brian Schott wrote: Dfmt 0.4.0-beta1 and 0.3.6 https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.6 Integration with Sublime Text (I use Sublime Text 2 and Windows) https://github.com/dmi7ry/dfmt-sublime can anyone check?
Re: New D tool releases
On Sunday, 28 June 2015 at 14:13:06 UTC, Namespace wrote: Why not Sublime Text 3? I think it will be work on ST 3 also, bacause it very simple. But can't check. Reasons to use ST 2, and not 3 can be different. For example: free version of ST 2, or some plugins which is not ported to ST 3.
Re: New D tool releases
On Sunday, 28 June 2015 at 14:13:06 UTC, Namespace wrote: Why not Sublime Text 3? Added small fix for ST 3.
Re: Announcing libasync, a cross-platform D event loop
On Sunday, 28 June 2015 at 17:10:16 UTC, Etienne Cimon wrote: g_evl.run(10.seconds); Hmm, sorry that would be g_evl.loop(10.seconds) or getThreadEventLoop().loop(10.seconds). I use the vibe.d driver most often.
Re: What's the story with -property?
On Saturday, 27 June 2015 at 22:55:48 UTC, Mike wrote: There's a regression involving `-property` at https://issues.dlang.org/show_bug.cgi?id=14564. In that issue, it's stated by a reputable source that `-property` is going away. It was also stated in IRC that it never worked anyway. So, what's the story on `-property`? Is it going away? Is the regression worth investing time in? There's also a DMD pull request that, unfortunately, was not followed through on: https://github.com/D-Programming-Language/dmd/pull/2305 Please advise. Thanks, Mike http://wiki.dlang.org/Property_Discussion_Wrap-up
Re: Announcing libasync, a cross-platform D event loop
It's particularity of unit-test blocks, or why function are
specified without return type like:
g_evl = getThreadEventLoop();
Also next code that I take from example after run absolutely do
not do nothing:
void main()
{
auto g_evl = getThreadEventLoop();
auto g_cbCheck = new shared bool[19];
auto g_watcher = new AsyncDirectoryWatcher(g_evl);
g_watcher.run({
DWChangeInfo[1] change;
DWChangeInfo[] changeRef = change.ptr[0..1];
while(g_watcher.readChanges(changeRef)){
g_cbCheck[18] = true;
writeln(change);
}
});
g_watcher.watchDir(.);
AsyncTimer tm = new AsyncTimer(g_evl);
tm.duration(1.seconds).run({
writeln(Creating directory ./hey);
mkdir(./hey);
assert(g_watcher.watchDir(./hey/));
tm.duration(1.seconds).run({
writeln(Writing to ./hey/tmp.tmp for the first time);
std.file.write(./hey/tmp.tmp, some string);
tm.duration(100.msecs).run({
writeln(Removing ./hey/tmp.tmp);
remove(./hey/tmp.tmp);
});
});
});
}
Re: Map Purity
On Sunday, 28 June 2015 at 16:28:20 UTC, jmh530 wrote: Thanks for the reply. Two follow ups: 1) Does labeling a template as pure matter if the compiler infers it anyway? 2) Does the compiler also infer anything for @safe/nothrow in templates? 1) It means you can't instantiate the template function with arguments that would make it non-pure. 2) Yes, pure, nothrow, @safe, @nogc are all inferred.
Re: Map Purity
On Sunday, 28 June 2015 at 16:15:31 UTC, Marc Schütz wrote: Secondly, `map` is indeed a template function, as you write. For templates functions, the compiler infers many properties, including purity. Thanks for the reply. Two follow ups: 1) Does labeling a template as pure matter if the compiler infers it anyway? 2) Does the compiler also infer anything for @safe/nothrow in templates?
Re: Map Purity
On Sunday, 28 June 2015 at 15:55:51 UTC, jmh530 wrote:
My understanding of pure is that a function labeled pure can
only include pure functions. I've been confused by the fact
that a function calling map (like below) can be labeled pure
without any problems. The only way I can rationalize it is that
map really isn't a function, it's (if I'm understanding it
correctly) a template that creates a template function that
calls a struct template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
Map isn't explicitly marked as pure. D can infer purity for
templated functions, so as long as you give it a pure predicate,
map can be inferred as pure. This only works for templated
functions; non-templated functions must be explicitly marked as
pure.
Re: Map Purity
On Sunday, 28 June 2015 at 15:55:51 UTC, jmh530 wrote:
My understanding of pure is that a function labeled pure can
only include pure functions. I've been confused by the fact
that a function calling map (like below) can be labeled pure
without any problems. The only way I can rationalize it is that
map really isn't a function, it's (if I'm understanding it
correctly) a template that creates a template function that
calls a struct template.
auto test_map(T)(T x) pure
{
return x.map!(a = a + a);
}
This is related to
http://forum.dlang.org/thread/ppmokalxdgtszzllz...@forum.dlang.org?page=1
but maybe my question is more basic.
There are two aspects to that. First, purity in D is less strict
than the concept in functional programming languages. It allows
access (even mutation) to anything that is reachable through the
parameters. David Nadlinger has written a nice article about the
concept and its implications:
http://klickverbot.at/blog/2012/05/purity-in-d/
Secondly, `map` is indeed a template function, as you write. For
templates functions, the compiler infers many properties,
including purity. Neither the `map` function nor the constructor
of the struct it returns do anything impure, therefore they are
treated as pure. And indeed, the return value of `test_map` will
only depend on its arguments, which is the first requirement for
purity, and of course it doesn't change global state either,
which fulfills the second requirement.
[Issue 14739] Immutable alias to template triggers dmd assert
https://issues.dlang.org/show_bug.cgi?id=14739 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com Hardware|x86_64 |All OS|Windows |All Severity|enhancement |regression --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- This program compiled in 2.062, and stopped compiling with an ICE after: https://github.com/D-Programming-Language/dmd/pull/1760 The ICE was fixed and the error changed to failed semantic analysis in 2.064, after: https://github.com/D-Programming-Language/dmd/pull/2645 The ICE was reintroduced in 2.066, after: https://github.com/D-Programming-Language/dmd/pull/3383 --
[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed
https://issues.dlang.org/show_bug.cgi?id=14431 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||performance, pull --- Comment #13 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4784 --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- hm. it seems to pull the whole Phobos in (or at least a great amount of it). i removed std.stream from libphobos2.a, the file is smaller (yet still around 800 kb), and now i see other crap there, like std.path, for example. it seems that if this bug will be fixed, linux binaries can become lesser in many cases. --
[Issue 14750] druntime/test/coverage was added to druntime, but not to the MANIFEST - zip file broken again
https://issues.dlang.org/show_bug.cgi?id=14750 --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- In fact, it seems none of the files in the test directory are in the manifest. --
[Issue 14454] Lambda template param doesn't compile with -inline *** is a nested function and cannot be accessed from ***
https://issues.dlang.org/show_bug.cgi?id=14454 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED Hardware|x86 |All Resolution|--- |DUPLICATE OS|Windows |All Severity|minor |major --- Comment #2 from Kenji Hara k.hara...@gmail.com --- (In reply to Vladimir Panteleev from comment #1) This program compiles fine with git master. Fixed by: https://github.com/D-Programming-Language/dmd/pull/4453 The root compiler issue is same with 7104. *** This issue has been marked as a duplicate of issue 7104 *** --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- (In reply to Walter Bright from comment #1) On Win32, I get the same exe file size, and 'stream' symbols do not appear in the executable. The file size is 200Kb. --
[Issue 7104] linker error on void main(){ typeof(new class{}) c; c = new typeof(c); }
https://issues.dlang.org/show_bug.cgi?id=7104 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||dzug...@gmail.com --- Comment #5 from Kenji Hara k.hara...@gmail.com --- *** Issue 14454 has been marked as a duplicate of this issue. *** --
[Issue 14750] druntime/test/coverage was added to druntime, but not to the MANIFEST - zip file broken again
https://issues.dlang.org/show_bug.cgi?id=14750 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- (In reply to Walter Bright from comment #0) When adding files to druntime, PLEASE add them to the manifest. Please stop recommending repeated manual actions as solutions, they don't work. (In reply to Walter Bright from comment #1) In fact, it seems none of the files in the test directory are in the manifest. Why should we distribute the additional tests? --
[Issue 4650] Static data that must be scanned by the GC should be grouped
https://issues.dlang.org/show_bug.cgi?id=4650 --- Comment #13 from Rainer Schuetze r.sagita...@gmx.de --- what is the status of this with the recent pulls? Still valid, fixed? More work needs to be done to move immutable data into the CONST segment (or similar areas that are not scanned). It is currently limited to float values and strings, not user defined data. --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- On Win32, I get the same exe file size, and 'stream' symbols do not appear in the executable. --
Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
In case you don't know what I'm talking about: https://github.com/D-Programming-Language/phobos/pull/3207 Since this is an API issue it's import to get it right the first time. Personally I'm not sure what I prefer (well, I am, but what I actually want isn't syntactically valid D). I think the options so far are: 1) What's there already, namely `shouldEquals`, `shouldBeIn`, etc. 2a) Compile-time strings for operators: `should!==`, `should!in` 2b) Dicebot's `test!==`. `assert` is so much better, I wish we could use that. 3) Composable ones: should.equals, should.not.equals, or another word that isn't should 4) Anything else? I'm not convinced composability brings anything to the table except for editor dot-completion. I don't like the verbosity of what's there now, but my prefererred syntax doesn't work except for the ubiquitous check for equality (`should ==`). Well, the dream would be that `assert(foo == bar)` did what part of this PR does, but that's another story and something that can't be done by a library unless we had AST macros, which we won't. Or Lisp's reader macros, but we won't get those either. Thoughts? Votes? Atila
Re: auto ref is on the docket
On Monday, 29 June 2015 at 19:10:07 UTC, Atila Neves wrote: It seems to me that there's a lot of confusion in this thread. I think I understand what you're saying but I'm not sure everyone else does. So correct me if I'm wrong: your stance (which is how I understand how things should be done in D) is that if a person wants to bind an rvalue to a ref parameter for performance, they shouldn't; they should pass it by value since it'll either get constructed in place or moved, not copied. Essentially, what this guy said about C++ (not the original I read, that's now a 404): http://m.blog.csdn.net/blog/CPP_CHEN/17528669 The reason rvalue references even exist in C++11/14 is because rvalues can bind to const. I remember hearing/reading Andrei say that D doesn't need them precisely because in D, they can't. Pass by value and you get the C++ behaviour when rvalue references are used: a move. In some cases even better, in-place construction. That's perfect - for rvalues, as you said. But for lvalues, a copy must be made - afaik, you don't have the option to explicitly move an lvalue into a byval-param in D as you can in C++. And even moving can be expensive if the type is big. So for efficiency, template auto-ref is a nice option, but requires a template and leads to code-bloat if both lvalues and rvalues are used as arguments. For these reasons, we want to have the additional option to pass both lvalues and rvalues by ref. Jonathan wants a non-templated function to specify explicitly whether it wants to accept an rvalue by ref, apparently to discriminate between 'output parameters' (mutable `ref`, lvalues only) and another category of `auto ref` parameters which also accept rvalues via lowering (I don't know how one would describe that category - to me it seems completely arbitrary and adds complexity, not to mention different interpretations by different developers). I'm solely interested in the safety of binding rvalues to refs, meaning that the compiler should prevent these rvalue refs from being escaped (I'm not talking about returning the ref via `return ref`, which is safe anyway when propagating the rvalue/lvalue origin, but storing derived pointers in external state). That's where `scope ref` (unescapable reference) comes in. But I prefer the compiler to infer scope-ness automatically in the future and would thus like to allow binding rvalues to `ref` in general - for not-so-performance-critical functions taking a value type by reference (for some value types, copying just doesn't make sense - streams, loggers etc.).
Re: std.experimental.color, request reviews
Huey (pronounced with an Australian Twang)? HSx works On Fri, Jun 26, 2015 at 7:11 AM, Guillaume Chatelet via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 25 June 2015 at 21:06:59 UTC, Guillaume Chatelet wrote: On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote: How about HSx ? That's the best I've got! :P Not too bad :-) I'm not too excited about this but how about : HS!L HS!V .,. It could work with a good documentation. Or just an obscure struct and some aliases : alias HueSpace!(Type.xSL) HSL
Re: Looking for GC intensive D programs
On Monday, 29 June 2015 at 21:53:37 UTC, rsw0x wrote: On Monday, 29 June 2015 at 09:35:08 UTC, John Colvin wrote: On Sunday, 28 June 2015 at 01:41:53 UTC, rsw0x wrote: Does anyone know of any GC intensive D programs that can preferably be ran with little to no setup? https://github.com/kostya/benchmarks contains some pretty GC-heavy code, although a lot of the slowness is actually from the AA implementation. The problem with benchmarks optimized for D is that they generally make little to no allocations, which makes them a bad candidate for memory allocation statistics. If you take a look at the code you'll see that they often allocate like crazy.
Analyze a D file for imports
I want to make a simple build utility that will rebuild only those files which changed since last build and those files that depend on them. Which is the easiest and yet reliable way to parse a D source and find all imports in it (and file import()s as well)?
Re: version: multiple conditions
On 6/29/2015 8:30 AM, bitwise wrote: FWIW, I've thought through most of my use cases, and it seems I can do without this feature(both mine and Daniels suggestions). This is mainly because I've decided to write anything close to the system in C++. If/When the day comes that system APIs are written in D, this may change, but I don't see this happening in the foreseeable future. IMO, the D community's time would be better spent improving D/C++ interop than trying to make D a systems language. At a glance, I don't see a binding for OpenCV or FBX SDK, and although there are many bindings for OpenGL and such, I wouldn't feel safe relying on them to be up to date or complete. The lesser evil clearly seems to be writing some C++. I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote: I'm not convinced composability brings anything to the table except for editor dot-completion. I don't like the verbosity of what's there now, but my prefererred syntax doesn't work except for the ubiquitous check for equality (`should ==`). Could you give some examples of your preferred syntax and why it doesn't work?
Re: Attempt to get rid of phobos Makefiles, using reggae
On Monday, 29 June 2015 at 18:59:31 UTC, Atila Neves wrote: On Monday, 29 June 2015 at 16:05:07 UTC, Joakim wrote: On Monday, 29 June 2015 at 10:35:34 UTC, Atila Neves wrote: Worth making a PR for? The PR would only add this file, it wouldn't change anything about the current build, but could be used for testing purposes in the meanwhile. Yes, those who want reggae can use it, and the makefile can remain the default for now. I can't wait to ditch the makefiles. Oh, and given the manual filtering in the config, it obviously won't work on Mac OS. I have to get a hold of a Mac and make it work there too. Then... Windows. You could probably use the auto-tester to test reggae: simply add the reggae source to your PR, build it with a patched makefile, and then use reggae to build druntime/phobos. I've used the auto-tester to test a couple PRs for various OSs that I don't have, especially OS X. You mean make a posix.mak that actually calls reggae instead? Hmm... I guess that's doable. Otherwise I'd have to edit the script the auto-tester is using. Yes, submit a PR that adds the reggae source and modifies the existing druntime or phobos posix.mak to build reggae, then runs reggae to build druntime/phobos, using the linked reggae file. Once you're sure it all works, you can delete the reggae source and the makefile modifications and simply submit the single reggae file that you know works, because you just tested it on the auto-tester. I'm not sure that'd guarantee the same output though. If you follow the process above, I don't see why not.
Re: Analyze a D file for imports
On Tuesday, 30 June 2015 at 04:08:48 UTC, rsw0x wrote: On Tuesday, 30 June 2015 at 04:02:00 UTC, Maaaks wrote: I want to make a simple build utility that will rebuild only those files which changed since last build and those files that depend on them. Which is the easiest and yet reliable way to parse a D source and find all imports in it (and file import()s as well)? dscanner has import analysis, it's likely tied to libdparse. That might be something worth investigating. Yes, it seems to be enough for me. Module imports can be retrieved directly by `dscanner --imports`, and string imports can be found in `dscanner --ast`. Thank you!
Re: version: multiple conditions
On Mon, 29 Jun 2015 22:30:50 -0400, Walter Bright newshou...@digitalmars.com wrote: On 6/29/2015 8:30 AM, bitwise wrote: FWIW, I've thought through most of my use cases, and it seems I can do without this feature(both mine and Daniels suggestions). This is mainly because I've decided to write anything close to the system in C++. If/When the day comes that system APIs are written in D, this may change, but I don't see this happening in the foreseeable future. IMO, the D community's time would be better spent improving D/C++ interop than trying to make D a systems language. At a glance, I don't see a binding for OpenCV or FBX SDK, and although there are many bindings for OpenGL and such, I wouldn't feel safe relying on them to be up to date or complete. The lesser evil clearly seems to be writing some C++. I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either. Was pretty sure I worded that wrong. I'm willing to concede at this point that if I was writing some fresh new systems code, I could deal with the limitations of 'version', and that it does seem like good practice not to spam preprocessors/version everywhere, but for me, a big selling point of D is _not_ having to re-write/refactor/re-think my code. From the point I picked up D, and having a strong background in C++, it just felt natural, and I was able to start programming with it immediately. I've been able to transfer over a lot of design-patterns/code with little to no effort. Still though, I think that with the dominance of C++ for system APIs, it makes more sense right now to keep the interop layer as narrow as possible, and just access the system from C++. I can then create a small group of interfaces for accessing graphics/audio/etc.. So I guess this nullifies my original grievance. Sorry for nagging :) Bit
Re: std.collection - changing the collection while iterating
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote: On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d digitalmars-d@puremagic.com wrote: I think the best approach is the following: * Throw exceptions on debug (usability) * Leave undefined on release (performance) Please no. Different behavior between release and non is not something to be desired. Yeah, wrote that late at night, what I actually meant was for assertions in debug.
Re: Analyze a D file for imports
On Tuesday, 30 June 2015 at 04:02:00 UTC, Maaaks wrote: I want to make a simple build utility that will rebuild only those files which changed since last build and those files that depend on them. Which is the easiest and yet reliable way to parse a D source and find all imports in it (and file import()s as well)? dscanner has import analysis, it's likely tied to libdparse. That might be something worth investigating.
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 14750] New: druntime/test/coverage was added to druntime, but not to the MANIFEST - zip file broken again
https://issues.dlang.org/show_bug.cgi?id=14750 Issue ID: 14750 Summary: druntime/test/coverage was added to druntime, but not to the MANIFEST - zip file broken again Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com When adding files to druntime, PLEASE add them to the manifest. --
Re: Beta D 2.068.0-b1
On Monday, 29 June 2015 at 17:03:19 UTC, Jacob Carlborg wrote: On 29/06/15 15:20, Martin Nowak wrote: Thanks for letting me know, didn't knew it was private. Any reason why it's not public? No, there is none, as I hinted in my answer. It already says it's public on our board though. Maybe it was changed recently? https://trello.com/dlang
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 11:14:55 UTC, Atila Neves wrote:
On Tuesday, 30 June 2015 at 08:38:44 UTC, Adrian Matoga wrote:
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
I'm not convinced composability brings anything to the table
except for editor dot-completion. I don't like the verbosity
of what's there now, but my prefererred syntax doesn't work
except for the ubiquitous check for equality (`should ==`).
Could you give some examples of your preferred syntax and why
it doesn't work?
`foo.should == bar;` works. Nothing else does (and in fact in
retrospect it's surprising that == does) because they do
nothing by themselves. `foo.should != bar` is the same as
`!(foo == bar)`, which on a statement by itself is nonsensical
and rejected by the compiler with has no effect in expression
error. You could write something like `if(foo.should != bar)
{}` and that compiles fine but it's super hacky and ugly.
Atila
Thanks. I took a second look and now it looks obvious.
I'd vote for Dicebot's bikeshed design (2b). It's short and looks
equally readable for every possible test.
Another hackish possibility could be to change the behavior of
assert so that it also passes the stringified expression to
_d_assert* and _d_unittest* in druntime.
Re: Heisenbug involving Destructors GC - Help Needed
On 6/26/15 11:38 PM, Brian Schott wrote:
On Saturday, 27 June 2015 at 03:16:35 UTC, rsw0x wrote:
calling destroy on a pointer should either be fixed or be an error,
that should not be allowed to happen.
Completely agreed. Calling destroy() on a pointer has been incorrect
EVERY time I've seen it done.
I'd say if you want to see cases where it was done correctly, change the
behavior and watch the complaints come in ;)
Wouldn't destroying the pointer target make an assumption about ownership?
Consider a struct that contains a pointer:
struct S
{
T *x;
}
destroy's algorithm for this struct is to call destroy on all of the
members, then set to S.init. But what if S is just *referencing* that T,
and doesn't *own* it? Isn't this the wrong thing to do?
I agree it's inconsistent with class references. How to make it
consistent isn't as easy to decide. For me, it's the class destruction
which is incorrect. Consider that destroy is consistent with scope
destruction for every type except for classes:
class C {}
struct S {}
{
C c = new C;
S s;
S *s2 = new S;
} // calls s.dtor, does not call c.dtor or s2.dtor
And what about arrays? Should calling destroy on an array call destroy
on all of the elements (it currently doesn't)?
If I were to design destroy from scratch, I'd make destroy, and
destroyRef (which destroys referenced data via pointer or class).
-Steve
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
To do it _really_ nice, we would need some sort of .codeof
feature. Possibly, with implicit returns in lambdas. For example:
void test(alias expr)
{
if (!expr())
throw new TestException(
expr.codeof ~ has failed,\n ~
/* investigate expr context pointer and grab a/b */
\ta = x\n ~
\tb = y
}
unittest
{
int a, b;
test!({ a == b; });
}
Of course, this is one of cases where AST macros would really
shine. But I think it should be possible to provide necessary
functionality subset in a much more simple and limited feature.
In absence of language changes, I don't see anything as clear and
simple as operator mixins. Less magic in unittests - better.
Common misconception IMHO is that tests should look nice for
library/app author, while, from the ecosystem PoV, they should
look simple and predictable for contributors - and that is most
important property.
Re: Question about Walter's Memory DisAllocation pattern
On 6/27/15 3:24 PM, Walter Bright wrote: On 6/26/2015 7:45 PM, Parke via Digitalmars-d wrote: Or, perhaps more precisely: Does the caller of toString need to know the size of the struct that toString will return? Yes. In the above example, buf's length is uint.sizeof * 3. But what if buf's length was a function of u (and therefore only known at run-time), rather than a function of uint.sizeof? In cases where the size cannot be known in advance, the returned struct can malloc/free the extra space. Be careful with this. You need a reference counted type to do this properly (or make the result not copyable). Also, malloced data is not scanned for pointers by the GC. -Steve
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote: 2a) Compile-time strings for operators: `should!==`, `should!in` 2b) Dicebot's `test!==`. `assert` is so much better, I wish we could use that. I think these are both bad, for the reason that ! also means logical not. I read `should!==` as should not equal before catching myself.
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote: In case you don't know what I'm talking about: https://github.com/D-Programming-Language/phobos/pull/3207 Since this is an API issue it's import to get it right the first time. Personally I'm not sure what I prefer (well, I am, but what I actually want isn't syntactically valid D). I think the options so far are: 1) What's there already, namely `shouldEquals`, `shouldBeIn`, etc. 2a) Compile-time strings for operators: `should!==`, `should!in` 2b) Dicebot's `test!==`. `assert` is so much better, I wish we could use that. 3) Composable ones: should.equals, should.not.equals, or another word that isn't should 4) Anything else? I'm not convinced composability brings anything to the table except for editor dot-completion. I don't like the verbosity of what's there now, but my prefererred syntax doesn't work except for the ubiquitous check for equality (`should ==`). Well, the dream would be that `assert(foo == bar)` did what part of this PR does, but that's another story and something that can't be done by a library unless we had AST macros, which we won't. Or Lisp's reader macros, but we won't get those either. Thoughts? Votes? Atila Google uses gMock. On top of being a mock framework it provides composable matchers API which are a great way of expressing what you want to test. https://www.youtube.com/watch?v=sYpCyLI47rM?t=19m15s (excerpt from outdated gMock presentation from 2008) The matcher api is based on Hamcrest and I think it's pretty convenient. Crash or log : assertThat(...); expectThat(...); Simple tests are easy to express. assertThat(4, 5); More complex things: assertThat(theBiscuit, is(equalTo(myBiscuit))); assertThat(theBiscuit, not(instanceOf(Liquid.class))); Same thing with container: assertThat(map, not(hasKey(lessThan(5; The tests are pretty readable and predicates compose nicely. Also because you express the condition as a tree of predicates the error reporting can be really nice. Like map contains element which key is not less than 5. Also one can write custom predicates for more specific tests. The C++ implementation relies on ugly template/macros. I'm sure a D implementation can be cleaner and pretty sweet to use. I suspect throwing ufcs in here will makes it even better.
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 13:22:43 UTC, Paul wrote: On Tuesday, 30 June 2015 at 13:19:25 UTC, Marc Schütz wrote: If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation. Thank you, I'll try that. Added info: I wanted to avoid using dub so I could manually figure out what would be required to distribute the application.
Re: Looking for GC intensive D programs
On Sunday, 28 June 2015 at 22:29:22 UTC, deadalnix wrote: On Sunday, 28 June 2015 at 01:41:53 UTC, rsw0x wrote: Does anyone know of any GC intensive D programs that can preferably be ran with little to no setup? I'm not sure what you mean by GC intensive. Most of high perf D programs would have been optimized to reduce GC usage to begin with. this is precisely the issue I'm having finding any GC intensive D programs.
Re: Announcing libasync, a cross-platform D event loop
Ehm, there is issue on Windows or I am again doing something
wrong?
void main()
{
void dirWatcher()
{
auto g_watcher = new
AsyncDirectoryWatcher(getThreadEventLoop());
g_watcher.run({
DWChangeInfo[1] change;
DWChangeInfo[] changeRef = change.ptr[0..1];
while(g_watcher.readChanges(changeRef)){
writeln(change);
}
});
g_watcher.watchDir(.);
getThreadEventLoop().loop();
}
dirWatcher();
destroyAsyncThreads();
}
Without destroyAsyncThreads(); it's fail with exception.
Re: Attempt to get rid of phobos Makefiles, using reggae
On Monday, 29 June 2015 at 18:24:23 UTC, Dicebot wrote: No reason to require -betterC - just getting reggae as a library into Phobos is enough. What are you thinking here? std.build or std.make? I think the plan was to put reggae in the Tools repository, but a library in Phobos that can simply be imported into an rdmd script is more appealing to me. Mike
[Issue 14746] [REG2.068a] Behavior change with struct destructor and alias this
https://issues.dlang.org/show_bug.cgi?id=14746 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Summary|Behavior change with struct |[REG2.068a] Behavior change |destructor and alias this |with struct destructor and ||alias this --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/1310 --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 --- Comment #4 from Ketmar Dark ket...@ketmar.no-ip.org --- anyway, something is wrong with generated object file. i generated hello.o for phobos without PR3443 applied and with PR3443 applied, then linked that object files with libphobos2.a WITH PR3443 applied, and got two ELFs with very different sizes (~900 kb and ~400 kb respectively). so seems that with PR3443 DMD generates an object file which somehow pulls in alot of unnecessary modules. very strange. --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 --- Comment #5 from Ketmar Dark ket...@ketmar.no-ip.org --- oops. disregard my #4, i'm an idiot and messed link commands. --
[Issue 12791] .tupleof does not take base class fields into account
https://issues.dlang.org/show_bug.cgi?id=12791 --- Comment #3 from pabu...@gmail.com --- ok, sorry, indeed __traits can do it. I know this may be out of place here but might still be useful for people landing on this page: --- auto b = new B; // B inherits from A foreach(i, m; __traits(allMembers, B)) static if (__traits(compiles, to!string(__traits(getMember, b, m writeln(m, = , __traits(getMember, b, m)); --- prints 'name = value' for all the fields (inherited or new, static or not, etc.) of an instance of class B. --
[Issue 14746] Behavior change with struct destructor and alias this
https://issues.dlang.org/show_bug.cgi?id=14746 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||wrong-code Component|dmd |druntime Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Introduced in: https://github.com/D-Programming-Language/druntime/pull/1181 --
Re: version: multiple conditions
On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote: On 6/29/2015 8:30 AM, bitwise wrote: [...] I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either. so is that a 'no, D will never get a real macro preprocessor'?
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 30 June 2015 at 06:07:14 UTC, Baz wrote: On Friday, 26 June 2015 at 15:23:25 UTC, Alex Parrill wrote: On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky wrote: [...] Yea, VirtualAlloc seems like a better fit. (I don't actually know the windows API that well) [...] Here's the paragraph I'm reading: Mapped views of a file mapping object maintain internal references to the object, and a file mapping object does not close until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile and close the file mapping object handle by calling CloseHandle. These functions can be called in any order. https://github.com/andralex/phobos/pull/17 By the way, the ddoc comment for mmap needs to be updated (not posix only). I don't know what to write because initially i just wanted to build allocator under win and proposed to the mmap allocator for win without thinking more... currently under win the only difference between a simple malloc is that the allocation happen on commitment...previously it was really an anonymous memory mapped file...).
Re: Static constructors guaranteed to run?
On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote: it doesn't, afair, but it's quite natural. if user type was throwed out as unused, it would be very strange to insist on keeping it's initialization code. Personally I would be kinda pissed if the compiler did this, I expect the static ctor to run, even if I don't use the type.
[Issue 6417] Wrong context for nested functions in virtual class member function contracts
https://issues.dlang.org/show_bug.cgi?id=6417 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Severity|normal |major --- Comment #4 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4789 --
Re: Beta D 2.068.0-b1
On Tuesday, 30 June 2015 at 10:52:39 UTC, Martin Nowak wrote: On Monday, 29 June 2015 at 17:03:19 UTC, Jacob Carlborg wrote: On 29/06/15 15:20, Martin Nowak wrote: Thanks for letting me know, didn't knew it was private. Any reason why it's not public? No, there is none, as I hinted in my answer. It already says it's public on our board though. Maybe it was changed recently? https://trello.com/dlang That seems to be the organization, which is indeed public. maybe boards have individual visibility?
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 13:19:25 UTC, Marc Schütz wrote: If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation. Thank you, I'll try that.
Re: tkd - basic compilation problem
If you don't want to use DUB, you need to download the other two packages from code.dlang.org and specifiy -I/path/to/tcltk -I/path/to/x11 -I/path/to/tkd in the DMD invocation.
tkd - basic compilation problem
I downloaded the archive from https://github.com/nomad-software/tkd and files are same as in the git repo. Tcl/tk is installed on this machine (test 'hello world' script works fine) but I get this error when compiling the example from the github page: tkd/interpreter/tcl.d(16): Error: module tcl is in file 'tcltk/tcl.d' which cannot be read import path[0] = /usr/include/dmd/phobos import path[1] = /usr/include/dmd/druntime/import As far as I can see there is no tcltk directory - can someone tell me where I'm going wrong or if something is missing? TIA Paul
[Issue 14588] [REG2.067] undefined reference error while linking with -debug option to a static library.
https://issues.dlang.org/show_bug.cgi?id=14588 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||link-failure, pull Hardware|x86_64 |All OS|Linux |All --- Comment #4 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4787 --
Re: Announcing libasync, a cross-platform D event loop
Ok, but code still do exit after it's run. Look like loop is not started
Re: Phobos addition formal review: std.experimental.allocator
On Friday, 26 June 2015 at 15:23:25 UTC, Alex Parrill wrote: On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky wrote: [...] Yea, VirtualAlloc seems like a better fit. (I don't actually know the windows API that well) [...] Here's the paragraph I'm reading: Mapped views of a file mapping object maintain internal references to the object, and a file mapping object does not close until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile and close the file mapping object handle by calling CloseHandle. These functions can be called in any order. https://github.com/andralex/phobos/pull/17
Re: D on Windows Phone
bitwise bitwise@gmail.com writes: Has anyone tried to submit an app for iOS with D code in it yet? I'm going to be putting out a game in the next little while, so I was thinking about sticking a D plugin in it to see if it raised any eyebrows. Bit Not to my knowledge, but please do try. The D iOS toolchain built by [1] only creates the armv7 libraries, but I have all the pieces staged to support universal libs for running in the x86 iOS Simulator too. I expect to have that up on github in a week along with prebuilt binaries. I am curious to see what App Store says about a submission. If there are problems, then we can hopefully make fixes. I will be happy to help -- Dan [1] https://github.com/smolt/ldc-iphone-dev
Re: Heisenbug involving Destructors GC - Help Needed
On 6/30/15 10:04 AM, Etienne wrote: I don't think there's a problem with destroy in the first place. The problem is that it's being advertised as calling the destructors: It does for value types and for class references. -Steve
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 14:58:45 UTC, Atila Neves wrote: On Tuesday, 30 June 2015 at 12:42:40 UTC, Sebastiaan Koppe wrote: On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote: [...] These days I am leaning towards BDD, but everybody has his favorite. Maybe just providing the low-level details in std.testing would enough; e.g. a test runner, UDA's and assertions. Yeah, I'm starting to think it might be better to delete `should.d` from my current PR, try to get the rest approved then work on where the community wants the fancy assertions to go. It's a shame though because I think it's a massively important piece of the whole thing. It's a night and day difference when a test fails. Atila Makes sense. You could still keep the should's, just rename the whole lot to isEmpty / isNotEmpty / isGreaterThan and have it return a bool instead of calling fail internally. Then you would simply expect the callee to do that. As in: `assert(5.isEqual(6));`.
GDC adds intrinsic support for core.checkedint
Hi, GDC now recognizes all functions in core.checkedint as intrinsics. May you all enjoy using inlined, hardware leveraged, overflow-checking integer operations. https://github.com/D-Programming-GDC/GDC/pull/110 I say 'you all', but what I really mean is 'bearophile'. :-) Regards Iain.
Re: version: multiple conditions
On Tuesday, 30 June 2015 at 15:55:49 UTC, bitwise wrote: On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote: I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either. Waiiit a minute...reading this again, it seems you are talking about writing code for a single system. In that case, yea, I suppose you can get by without versions. The market in multi-platform mobile apps is not something that should be ignored though. You need version blocks to distinguish between platforms (be it OSes or architectures or whatever), but code like that should be wrapped at a fairly low level, and most code shouldn't have anything like that in it. e.g. druntime has tons of version blocks, whereas Phobos has relatively few. Certainly, in general, if you're using complex expressions for versions, you should probably be rethinking how you're doing your code. I've dealt with code before that shared code across multiple products and altered its behavior via ifdefs, and it was a _disaster_. It would have been _far_ cleaner to just separate it out via libraries and section off the system-specific code such that it was contained and generally small. Once in a while, being able to or || version identifiers like linux and FreeBSD would be nice, but on the whole, I have to agree that if you're doing much of that, it's just a recipe for disaster. I suppose that the problem is that it's just useful enough in some cases that it's annoying not to have it, but if we _did_ have it, it would be abused like there's no tomorrow. - Jonathan M Davis
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 15:25:27 UTC, Alex Parrill wrote: On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote: Using dub I get this during linking: Building tkd-test ~master configuration application, build type debug. Compiling using dmd... Linking... /usr/bin/ld: cannot find -ltcl /usr/bin/ld: cannot find -ltk ...any suggestions please? You need to install the libraries. Ex `sudo apt-get install libtcl8.5 libtk8.5` Or the corresponding -dev packages.
Re: Nullable with reference types
On Tuesday, 30 June 2015 at 15:17:00 UTC, Jonathan M Davis wrote: I tend to think that it's incredibly stupid to use something like Nullable for a type that's already Nullable. Unfortunately, we're stuck with it as changing that would break code. It's just silly. If a type is already nullable, then just use that and stop being adding extra overhead for no good reason. I agree. There are several minuscule advantages you get from wrapping a nullable type with Nullable, but they're almost negligible.
Re: Bug or feature?
On Monday, 29 June 2015 at 14:28:06 UTC, anonymous wrote: On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote: You haven't declared an immutable constructor, so you can't construct an immutable Foo. That's not what's happening. Constructing an immutable Foo works just fine. Then I stand corrected. - Jonathan M Davis
[Issue 14744] std.range DDox page corrupted
https://issues.dlang.org/show_bug.cgi?id=14744 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- Filed DDox GitHub issue: https://github.com/rejectedsoftware/ddox/issues/89 --
[Issue 14503] BigInt to binary/octal and lower case %x (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
Re: Template mixin can not introduce overloads
On Thursday, 25 June 2015 at 03:49:04 UTC, Tofu Ninja wrote:
Is this intended or is it a bug?
On Thursday, 25 June 2015 at 03:53:58 UTC, Adam D. Ruppe wrote:
Intended, the mixin template works on the basis of names. This
The extra step is easy though: alias the name in:
I would like to to this with constructors instead of normal
methods. I have tried to mix in a constructor as follows:
#!/usr/bin/rdmd
import std.stdio;
mixin template MyConstructor() {
this(int x, float y) { writefln(%d, %f, x, y); }
}
class Base {
mixin MyConstructor my_ctor;
this(string s) { writefln(s); }
alias my_ctor this;
}
void main()
{
Base b = new Base(3, 4.5);
}
$ ./mixinctor.d
./mixinctor.d(17): Error: constructor mixinctor.Base.this (string
s) is not callable using argument types (int, double)
Failed: [dmd, -v, -o-, ./mixinctor.d, -I.]
Doing it with
alias this = my_ctor;
errors out too, and demands me to use alias my_ctor this; as in
the original code.
Can I get this to work at all? Or does alias this (for multiple
subtyping) fundamentally clash here with alias my_ctor this?
-- Simon
Re: Static constructors guaranteed to run?
On 6/26/15 6:00 PM, Tofu Ninja wrote: Also are static constructors in templated types guaranteed to run for every instantiation? I'd hazard to guess that the current compiler does run them, but that they probably aren't guaranteed to run by a sufficiently smart future compiler. Note, I strongly would discourage having static ctors inside templates: https://issues.dlang.org/show_bug.cgi?id=14517 -Steve
Re: tkd - basic compilation problem
On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote: Using dub I get this during linking: Building tkd-test ~master configuration application, build type debug. Compiling using dmd... Linking... /usr/bin/ld: cannot find -ltcl /usr/bin/ld: cannot find -ltk ...any suggestions please? You need to install the libraries. Ex `sudo apt-get install libtcl8.5 libtk8.5`
Re: is it safe to call `GC.removeRange` in dtor?
On 6/27/15 5:53 PM, ketmar wrote: is it safe to call `GC.removeRange` in dtor? i believe it should be safe, so one can perform various cleanups, but documentation says nothing about guarantees. Hm... I can't see any reason why it wouldn't be allowed. removeRange shouldn't allocate, so the one forbidden thing is not used. And removing a range, by definition, means it's not being collected. So you can be assured that the data still exists. I'm not 100% sure, though. -Steve
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? I think this might be a problem with vibe.d's `sleep`. Putting a `writeln(...);` there is a lot faster than `sleep`ing even the tiniest amount of time.
[Issue 14553] The return types of std.array.array for narrow strings conflicts with its documentation
https://issues.dlang.org/show_bug.cgi?id=14553 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- The question is, should we change the code to copy the qualifiers to the returned dchar[], or should we fix the docs to match the code? I'm not sure why it's important to keep the qualifiers if we're creating a new array anyway. Why not keep the code as-is and ensure that it's pure, so that the returned array can be implicitly cast to whatever qualifiers the user wants? --
[Issue 4244] AA insert from fixed-sized array much slower than from equivalent struct
https://issues.dlang.org/show_bug.cgi?id=4244 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Confirmed that this performance issue still happens on git HEAD (1ceb899e9ee430bcd223ddeeb907245ea5be3d47). Tested on Linux/64bit, AMD Phenom II X6 1055T (800 MHz). The original code runs a little too fast on my system to have any measurable performance numbers (S/N ratio too low to be accurate), so I bumped N to 1800, and noted that the foo1() version takes on average about 1.4 to 1.5 seconds to complete, whereas the foo2() version takes only about 0.8 to 0.9 seconds on average. Both versions compiled with `dmd -O -release -inline`. (Surprisingly enough, not specifying -inline seems to produce faster code?! It's a small difference, though, so could just be background noise.) Also surprisingly, gdc-5.1.1 produces much slower code than dmd in this case: the foo1() version takes on average about 3.9 seconds, whereas the foo2() version takes on average about 3.4 seconds. Both compiled with `gdc -O3 -finline -frelease`. This may possibly be caused by gdc using an older version of druntime, as recently the AA code in git HEAD has had some performance improvements. Will take a look into the generated assembly code next. --
[Issue 14735] [REG2.068-b1] std.string.indexOf cannot deduce function for char argument
https://issues.dlang.org/show_bug.cgi?id=14735 --- Comment #13 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/709fb22e8ad984d5a77181a2669afaefed5c6a1d Merge pull request #3446 from 9rnsr/fix14735 Supplemental fix for issue 14735 - Prevent self-recursive match --
Re: Heisenbug involving Destructors GC - Help Needed
On Tuesday, 30 June 2015 at 17:10:41 UTC, Steven Schveighoffer wrote: On 6/30/15 10:04 AM, Etienne wrote: I don't think there's a problem with destroy in the first place. The problem is that it's being advertised as calling the destructors: It does for value types and for class references. -Steve Yeah well the types that don't get finalized by it need to be listed somewhere
Re: Replacement of std.stream
On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote: I will convert a Java program into D. The original Java code is based on the class RandomeAccessFile which essentially defines a set of methods for read/write Int/Long/Float/String etc. The module std.stream seems to be a good fit for this job, but in its documentation, it is marked deprecated. So I'd like to know what is the replacement for this module. If I don't use this module, what is the other apporach I should use. Thanks for help. It should be noted that you can always take the code from std.stream and use it as a classical non-standard library.
Re: goroutines vs vibe.d tasks
On Tuesday, 30 June 2015 at 16:43:58 UTC, anonymous wrote: On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote: Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks. Compilers go: go version go1.4.2 linux/amd64 vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23 Code go: http://pastebin.com/2zBnGBpt vibe.d: http://pastebin.com/JkpwSe47 go version build with go build test.go vibe.d version built with dub build --build=release test.d Results on my machine: go: 168.736462ms (overhead ~ 68ms) vibe.d: 1944ms (overhead ~ 1844ms) Why creating of vibe.d tasks is so slow (more then 10 times)??? I think this might be a problem with vibe.d's `sleep`. Putting a `writeln(...);` there is a lot faster than `sleep`ing even the tiniest amount of time. Sleep will almost certainly pause and block the fiber. Vibe.d only switches between them when there's IO to be done or something else from the event loop. A better way of comparing would be to actually do something: use channels to ping-pong back between the goroutines and use vibe.d's concurrency to send messages betweeen fibers. Whatever you do, don't sleep. Atila
Coedit - 1 update 1 - broken DCD !
On Thursday, 25 June 2015 at 04:10:15 UTC, Basile Burg wrote: This is the first update for Coedit 1, and probably the only. Import information: latest version is distributed with a broken DCD version. If you setup DCD with the Coedit setup program or from the zipped binaries you'll have to setup again or rebuild DCD ! see https://github.com/BBasile/Coedit/issues/17
Re: goroutines vs vibe.d tasks
Don't have go installed, but for me, the timings don't change very much depending on compiler and optimization flags: dub --compiler=dmd 13346ms dub --compiler=dmd --build=release 12348ms dub --compiler=ldc212082ms dub --compiler=ldc2 --build=release 9351ms
proper way to calculate toHash() for string
I would like to know proper way to calculate
hash for given member fields.
class Foo {
int value;
string str;
override nothrow @safe size_t toHash() {
// calculate hash based on field value.
// value and str in this example.
}
}
boost::hash provides easy and systematic way
to calculate hash.
I found std.digest.crc is useful.
override nothrow @safe size_t toHash() {
if (str is null) return value;
ubyte[4] hash = crc32Of(str);
return value^((hash[0]24)|(hash[1]16)|(hash[2]8)|hash[3]);
}
Please suggest me if anyone have an idea.
Regards, aki.
[Issue 14712] GIT HEAD : std.net.curl regressions
https://issues.dlang.org/show_bug.cgi?id=14712 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7a20221c263810f005bedd5e4c05fca656503fa1 fix Issue 14712 - GIT HEAD : std.net.curl regressions https://github.com/D-Programming-Language/phobos/commit/bf66cd106ecad30a5322fbfa740fad87efd4f4b6 Merge pull request #3457 from CyberShadow/pull-20150630-152826-cherrypick-3436 fix Issue 14712 - GIT HEAD : std.net.curl regressions --
[Issue 14747] compiler insists on unnecessary return statement
https://issues.dlang.org/show_bug.cgi?id=14747 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/4790 https://github.com/D-Programming-Language/phobos/pull/3456 --
[Issue 14748] Removing std.stdio import causes 2x increase in Hello, world program binary filesize
https://issues.dlang.org/show_bug.cgi?id=14748 --- Comment #6 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Walter Bright from comment #1) On Win32, I get the same exe file size, and 'stream' symbols do not appear in the executable. The test machine that detected this is running Ubuntu Server 14.04 x64. --
[Issue 14503] BigInt to binary/octal and lower case %x (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/47dfc369b07d62988682404edf7b4a95dec93480 Merge pull request #3240 from e10s/issue14503 Fix BigInt.toString with %x --
[Issue 14747] compiler insists on unnecessary return statement
https://issues.dlang.org/show_bug.cgi?id=14747 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/4ceb3ab1599025cc5b8a8659c088d17215b89091 Supplemental fix for issue 14747 - remove unreachable statements https://github.com/D-Programming-Language/phobos/commit/181550b1eaa31a0b9722c80ddfe18c0417ac Merge pull request #3456 from 9rnsr/fix14747 Supplemental fix for issue 14747 - remove unreachable statements --
