Re: How to build static linked executable
On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote: On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote: FYI, -static is not support on macOS. So, how to build static binary for macOS? Static binaries aren't really supported by Apple (anymore). What do you need it for? — David
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program? The best solution would be to profile the startup process and file a bug accordingly. ;) — David
Re: Does the compiler inline the predicate functions to std.algorithm.sort?
On Sunday, 18 March 2018 at 14:15:37 UTC, Stefan Koch wrote: On Sunday, 18 March 2018 at 12:59:06 UTC, tipdbmp wrote: I can't read assembly but it seems to me that it doesn't: https://godbolt.org/g/PCsnPT I think C++'s sort can take a "function object" that can get inlined. Correct it does not get in-lined. Even with -O3 it does not. The reason is that the code the sort instantiation produces is too big for the inliner cost function. If you have a look at the the cg file produced when you specify -vcg-ast you can see that it's a massive amount of code. I believe the original poster was asking about the *predicate* to sort, which is indeed inlined with optimizations on. (@tipdbmp: The string gets turned into the function _D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.) — David
Re: Convert output range to input range
On Friday, 16 March 2018 at 07:57:04 UTC, John Chapman wrote: I need to write to a range created with outputRangeObject, then read from it. Is there a way to convert it to an input range? Could you illustrate your problem a bit further? In the literal sense, converting from an output to an input range would require using coroutines (where .empty() blocks until the output range has supplied the next element). However, I suspect what you want to do is to write results from the output range to a buffer (e.g. an Appender) first, and after that – or possibly every so often in chunks – process the results further? — David
Re: Terminating multiple processes
On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote: The problem is actually a thread blocked in an inotify blocking read. As both Steven and yourself have pointed out I am going to have to use a timeout to check the state of the application. There are better solutions (select/...), But couldn't you in theory just send a custom signal to the thread (which you ignore), and then check for the exit flag after the syscall returned EINTR? The DInotify wrapper might of course have the retry loop hardcoded; I didn't check. —David
Re: Get aliased type
On Tuesday, 2 January 2018 at 11:42:49 UTC, John Chapman wrote: Because an alias of a type is just another name for the same thing you can't test if they're different. I wondered if there was a way to get the aliased name, perhaps via traits? (.stringof returns the original type.) There is indeed no way to do this; as you say, aliases are just names for a particular reference to a symbol. Perhaps you don't actually need the names in your use case, though? — David
Re: partial application for templates
On Monday, 25 December 2017 at 20:39:52 UTC, Mengu wrote:
is partially applying templates possible?
Check out std.meta.Apply{Left, Right}.
— David
Re: Does LDC support profiling at all?
On Saturday, 23 December 2017 at 12:23:33 UTC, Johan Engelen wrote: Fine grained PGO profiling: -fprofile-instr-generate http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html Function entry/exit profiling: -finstrument-functions https://github.com/ldc-developers/ldc/issues/1839 https://www.youtube.com/watch?v=LNav5qvyK7I I suspect it is not too much effort to add DMD's -profile and -profile=gc to LDC, but noone has done it yet. Another thing that is relatively easy to add to LDC: https://llvm.org/docs/XRay.html Apart from profiling based on compiler instrumentation, don't forget that LDC uses the standard object file formats/runtime libraries for the various platforms, so all the usual profiling tools like perf, VTune, Valgrind, etc. work just fine. I would usually start with one of the latter for general-purpose optimization work. — David
Re: Is there anyway to access LLVM's 128 bit int type for C from LDC?
On Thursday, 14 December 2017 at 19:47:53 UTC, Jack Stouffer wrote: Clang has __int128. Is there anyway to use this with D with LDC? There has been some work on this a while ago, by Kai, but it hasn't been merged yet: https://github.com/ldc-developers/ldc/pull/1355 — David
Re: Get pointer or reference of an element in Array(struct)
On Saturday, 9 December 2017 at 06:46:27 UTC, Arun Chandrasekaran wrote: Thanks. Just curious why reference can't be obtained here. Saves nasty null checks in most places. D simply doesn't have a (C++-style) concept of references as part of the type. Arguments can be passed by reference - hence the `ref` keyword -, but "free" references don't exist in the language. The ref in foreach loop variables can be conceptually thought of as a parameter to the loop body as well. (For opApply-based iteration, the loop body indeed gets turned into a function; for "plain" iteration the compiler AST internally has special ref variables, but they are not visible to the language.) -David
Re: GDC generate wrong .exe ("not a valid win32 application")
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote: Fresh install of GDC. (tried with 32x ad 32_64x) Where did you get the GDC executable from? The GDC project doesn't currently offer any official builds that target Windows; the 6.3.0 builds from https://gdcproject.org/downloads in fact generate Linux binaries. — David
Re: libc dependency
On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote: Musl (or similar) should be available as an alternative. That will make it easier to cross-compile as well. This is not relevant for cross-compilation, as long as you have the libraries available. You can actually link a D Windows x64/MSVCRT executable from Linux today if you copy over the necessary libraries. The question is just how we can make this as easy as possible for users. — David
Re: libc dependency
On Tuesday, 20 June 2017 at 18:51:17 UTC, Moritz Maxeiner wrote: On Tuesday, 20 June 2017 at 12:09:06 UTC, Jacob Carlborg wrote: LLD, the LLVM linker [1]. As far as I understand it, it also support cross-platform linking. Using LDC, musl and LLD you have a fully working cross-compiler tool chain. You might need some extra libraries as well, depending on what you need. Hm, so then we could provide a self-contained installer for all major platforms that bundles all you need to get started with D. Neat. Yes, that's part of the idea behind the ongoing work to integrate LLD into LDC: https://github.com/ldc-developers/ldc/pull/2142 For Windows, we use the MS C runtime, though, and the legal situation around redistribution seems a bit unclear. — David
Re: std.path.buildPath
On Saturday, 3 June 2017 at 14:12:03 UTC, Russel Winder wrote: I have no idea what drugs the person who chose that last one to be correct semantics was on at the time, but it was some seriously bad stuff. Of all people, I certainly didn't expect you to stray so far from the tone appropriate here. Please keep it civil. I cannot find any excuse for this to be even remotely reasonable. I suspect the original author had applications in mind where you want to resolve user-specified file system paths that might be relative or absolute. One could just use buildPath to prepend the root path if necessary. (Whether this is useful or just unnecessarily error-prone is another question, of course.) — David
Re: C macros vs D can't do the right thing
On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote: Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work. We could also finally fix the frontend to get around this. At DConf 2015, Walter officially agreed that this is a bug that needs fixing. ;) — David
Re: C macros vs D can't do the right thing
On Saturday, 3 June 2017 at 13:17:46 UTC, Russel Winder wrote: Is this a problem in D or a problem in DStep? It's a limitation of DStep – for that use case, it would need to transform one of the macro arguments into a template argument rather than a runtime function parameter. If you need to make the code work as-is, I suppose you could create some aliases like `enum u32 = __u32.init;` and pass these instead of the types – using runtime values just to convey their type. — David
Re: std.socket classes
On Sunday, 9 April 2017 at 14:47:39 UTC, Jonathan Marler wrote: My guess is that making Socket a class prevents socket handle leaks because you can clean up the handle in the destructor when the memory gets freed if no one closes it. Is this the reason it is a class and are there any other reasons? Just to definitively answer the question: The design has been done way before even D 1.0 – actually, 0.86, I just checked the Git history – and has stayed more or less unchanged since. Several people, including me, have patched up various issues since, but the clunky design stayed unchanged. Including it in D2 proper was of course a mistake – it certainly wouldn't even come close to making it into Phobos today. — David
Re: Is DMD breaking BigInt?
On Friday, 7 April 2017 at 17:06:31 UTC, Russel Winder wrote: If anyone has any useful intelligence as to what happening and how I can workaround it, I'd be a grateful bunny. You might want to check with LDC from Git master first to see whether it is in fact a 2.073-related problem. — David
Re: GitHub detects .d source as Makefile?
On Saturday, 18 March 2017 at 00:34:57 UTC, XavierAP wrote: Is this a known issue with D on GitHub? Should I report it I guess? How smart is GH that it doesn't look at the file extension? What happened? The extension .d can legitimately refer to makefiles as well (specifically, to dependency files). The code GitHub uses to infer source file languages is open-source, and – fittingly – available on GitHub: https://github.com/github/linguist You should check the issues for reports of similar D-related problems, and if there are none, create a new one. Or, better yet, submit a pull request with an appropriate fix. As a workaround, adding a "module …;" declaration to your file should help. You probably want to be doing that anyway. — David
Re: Writing pattern matching macros in D.
On Monday, 6 March 2017 at 02:20:02 UTC, Deech wrote: […] add pattern matching to the language as a macro. D doesn't have macros per se. However, template metaprogramming and mixins can replace them in many cases. Which particular form of pattern matching do you have in mind? You won't get all the way to Haskell (or even Prolog) levels of functionality in a generic way, but for limited use cases, it is definitely possible. — David
Re: Why is &array[0] @safer than array.ptr?
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis wrote: Yes, but my point is that you're normally only going to use .ptr to pass something to a C function, and even if you're doing more with it in D, odds are, you're going to be doing pointer arithmetic. Wrong again. If this were the case, we wouldn't have needed to make it a deprecation at all, since all uses would have been mistakes. A non-negligible amount of real-world D code actually uses single-object pointers. Look up the change history if you are interested – and indeed, making sure one understands the topic sufficiently well to meaningfully contribute before typing out a wall-length sermon would collectively save us a good chunk of time. And when you combine it with marking C function @trusted, this is actually pretty bad. Ex falso quodlibet – once you have a piece of code mistakenly marked @trusted, all guarantees are out of the window even without suspicious-looking client code. @safe-ty is about mechanically verifiable code, not faith-based programming. — David
Re: Why is &array[0] @safer than array.ptr?
On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
This is a fallacy:
---
@safe: // Deprecated, though.
ubyte oops(ubyte[] b) {
return *b.ptr;
}
void main() {
oops(new ubyte[0]);
// - or -
auto b = new ubyte[42];
oops(b[$ .. $]);
}
---
— David
Re: Why is &array[0] @safer than array.ptr?
On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis wrote: Fine, but in the vast majority of cases, you're calling .ptr, because you're going to be passing the pointer to C code, in which case, doing &arr[0] buys you very little, since the C code is inevitably going to be reading more than that one element, In that case, calling the C function isn't going to be @safe anyway, so you might as well use .ptr. So, telling the programmer to use &arr[0] instead of arr.ptr is just plain bizarre. What you call bizarre is a simple, actionable explanation (which is especially important as the behaviour was necessarily a backwards-incompatible change). If &arr[0] doesn't actually apply to your code, then it was mistakenly @safe before. — David
Re: Why is &array[0] @safer than array.ptr?
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis wrote: It seems _slightly_ better from a safety perspective but only slightly. Wrong – one is correct, the other is not. This is because every pointer in SafeD is dereferencable. Pointer arithmetic is not allowed in SafeD, so your concerns about reading from other memory do not apply. — David
Re: Why is &array[0] @safer than array.ptr?
On Tuesday, 24 January 2017 at 11:49:59 UTC, Atila Neves wrote: But it's still annoying to have to do &array[0] just to pass it to a C function, since `my_c_func(array.ptr)` isn't going to screw up anything. How do you know it does not screw up anything? Presumably, the function somehow accesses the object the pointer targets. How would this be @safe to call if the pointer were not dereferencable? — David
Re: Reinstalled Mac
On Thursday, 29 September 2016 at 01:33:00 UTC, Joel wrote: Oops, I got confused and installed with homebrew. I was going to try DVM. Jacob is also the author of DVM, so he might be a bit biased. ;) I've had good experiences using Homebrew, although you sometimes have to wait a day or three for a new release to appear. — David
Re: Compiling vibe.d application for Amazon ec2 instance
On Wednesday, 14 September 2016 at 12:13:58 UTC, Seb wrote: You should try -static in ldc, it's works like a dream for me :) Yep, LDC supports fully static linking on Linux (and is currently the only compiler to do so). — David
Re: Fast multidimensional Arrays
On Monday, 29 August 2016 at 10:20:56 UTC, rikki cattermole wrote: By the looks you're not running the tests more then once. Druntime initialization could be effecting this. Please execute each test (without memory allocation) 1 times atleast and then report back what they are. D program startup is on the order of milliseconds, so the difference is negligible for a benchmark that runs for more than a second vs. 200 ms. — David
Re: InterlockedIncrement, InterlockedCompareExchange, etc
On Sunday, 28 August 2016 at 21:52:48 UTC, Illuminati wrote:
Also D doesn't seem to have a volitile keyword anymore which is
required to prevent the compiler from prematurely optimizing
critical code.
It isn't. In fact, using volatile to achieve thread
synchronisation (seeing as this is what the original post was
about) in C is almost always wrong.
Depending on the use case, {atomic, volatile}{Load, Store}()
should fulfil your needs.
— David
Re: How to avoid ctRegex (solved)
On Saturday, 27 August 2016 at 17:47:33 UTC, Dicebot wrote: But actual value of that Regex struct is perfectly known during compile time. Thus it is possible and fine to use it as initializer. You can use any struct or class as initializer if it can be computed during compile-time. Yes, regex() is CTFEable, but this still comes at a significant compile-time cost as the constructor does quite a bit of string manipulation, etc. I've seen this, i.e. inconsiderate use of regex() globals, cost tens of seconds in build time for bigger codebases. — David
Re: Is it's possible to install DMD/LDC/GDC on CoreOS?
On Sunday, 21 August 2016 at 14:57:15 UTC, Seb wrote: An alternative would be to compile your application locally, then copy it over to your container. I don't know how similar CoreOs to a typical Linux distribution is, but if it comes with the typical shared libraries (libm.so, libc.so, lipthread.so), this should be possible ;-) LDC also allows you to create fully statically linked executables (-static). It allows you to sidestep issues with shared library version incompatibilities, but of course there has been a few technical issues and lot more politicking regarding fully statically linked executables on Linux. — David
Re: Is it's possible to install DMD/LDC/GDC on CoreOS?
On Sunday, 21 August 2016 at 11:38:09 UTC, Suliman wrote: I would like to create small VPS instance with Linux distrib on VPS. Can I use CoreOS as image? Would it possible to install dlang there? For LDC, you can just download the latest release from https://github.com/ldc-developers/ldc/releases and you are good to go. Just make sure you have "gcc" available on your system for linking. — David
Re: typeof.stringof wrong type
On Friday, 19 August 2016 at 15:47:00 UTC, ag0aep6g wrote: https://dlang.org/spec/property.html#stringof Someone should edit that, if fullyQualifiedName is no good either. Indeed. I'm sure the change was well-intentioned, but symbol visibility/import concerns and Voldemort types should make it abundantly clear that this can't work ever work in the general case. — David
Re: typeof.stringof wrong type
On Friday, 19 August 2016 at 15:15:55 UTC, ag0aep6g wrote:
I think that qualifies as a bug, because fullyQualifiedName is
supposed to be usable in code generation.
This is a misconception. Neither .stringof nor fullyQualifiedName
should *ever* be used in code generation. There is a myriad of
things that make strings unsuitable in the general case. The most
obvious reason are imports: think a type coming via an alias
parameter from a second module, which is not even important at
the point of the mixin.
Instead of trying to make .stringof work do things it will never
be able to, you need to use the type just as you would at the
point of the mixin. In this example, you would write
`mixin("typeof(a) d");`.
— David
Re: Searching for a T in a T[]
On Wednesday, 22 June 2016 at 08:04:34 UTC, Nordlöw wrote: Is there now algorithm (similar to `canFind`) that can search for a `T` in a `T[]`? Existing `canFind` only supports sub-sequence needles. What about http://dlang.org/phobos/std_algorithm_searching.html#.canFind.canFind.2? — David
Re: D casting broke?
On Sunday, 19 June 2016 at 21:06:43 UTC, Joerg Joergonson wrote: A!b is derived from A!a if b is derived from a, is it not? If not, then I am wrong, if so then D casting has a bug. You are wrong. The array example given by Adam is actually a neat illustration of precisely your question if you just think of `T[]` as `Slice!T`. In other words, `Slice!b` cannot be derived from `Slice!a` automatically, since then you could use the `Slice!a` interface to push `a` instances into your `Slice!b`. If that's a bit too far of a mental leap to make, you can certainly find a more thorough illustration of the concepts at play here by looking up covariance vs. contravariance in containers/generics online. — David
Re: Default initialization of structs?
On Friday, 17 June 2016 at 11:10:12 UTC, Gary Willoughby wrote:
Thanks, I forgot to mention I'm also doing lots of other stuff
in the constructor to private fields too.
struct Foo(T)
{
private int _bar;
private void* _baz;
this(int bar = 8)
{
this._bar = bar;
this._baz = malloc(this._bar);
}
}
So I have to at least run a constructor.
Structs cannot have a default constructor; .init is required to
be a valid state (unless you @disable default construction). This
is a deliberate language restriction, although you can argue
about its value.
What you can do as a workaround is to provide a public static
factory method while disabling default construction.
— David
Re: An Alternative to Deimos' OpenSSL Bindings
On Sunday, 12 June 2016 at 21:49:21 UTC, Vladimir Panteleev wrote: On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote: I wanted to use OpenSSL from D but I noticed that the Deimos bindings are for version 1.0.0e, which according to OpenSSL.org is an out of date version. Are there any bindings for the latest version, or an alternative that I could use? I know I could use std.digest for SHA512, but I still need a secure random number generator. What's the problem? According to the OpenSSL changelog, SHA-512 was added in v0.9.8. Just in case that isn't clear, what Vladimir is pointing out is that unless you need a feature from the new versions – or OpenSSL breaks binary compatibility, which is unlikely to happen anytime soon – the old headers will work just fine. — David
Re: Why can't I assign a mixin to an alias?
On Friday, 10 June 2016 at 22:38:29 UTC, Dechcaudron wrote: Error: basic type expected, not mixin Why should it be like that? I believe the compiler should not impose restrictions on what mixins can or cannot do :/ This might be a gratuitous grammar restriction. There are a few of those surrounding alias "targets". A template that simply returns its parameter might work, though, such as std.meta.Alias (alias foo = Alias!(mixin(…));). — David
Re: What's up with GDC?
On Friday, 10 June 2016 at 22:01:15 UTC, Joerg Joergonson wrote: The problem I'm getting with ldc, using your simpledisplay, is that the libs aren't loading due to the wrong format. It's the omf vs coff thing or whatever, I guess... How do you mean that? LDC/MSVC uses COFF, and there should be no issues with linking against any external libraries you might need. Knowing Adam, though, simpledisplay probably only depends on the Win32 API, so I'm not sure where the issue would be in the first place. Unless, of course, you are referring to linking an LDC executable against a simpledisplay library built with DMD – the different D compilers are not ABI-compatible, and will not be for the foreseeable future. — David
Re: What's up with GDC?
On Friday, 10 June 2016 at 20:30:36 UTC, Joerg Joergonson wrote: Well, the post was a bit incoherent because getting all this stuff working is. I was searching for ldc and ran across some web site that had only the sources(same for gdc). […] Why isn't there a proper binaries for ldc and gdc that work out of the box like dmd? LDC binaries exist and work out of the box – just extract them anywhere and you are set. Have a look at the official release list: https://github.com/ldc-developers/ldc/releases I'm not sure what other website you came across; maybe there are some links that need fixing? — David
Re: Why I can't pass to datetime.benchmark function with parameters?
On Saturday, 23 April 2016 at 18:52:30 UTC, Suliman wrote:
My error. I mean it should be:
auto r = benchmark!(foo(4))(1);
But thanks for answer!
This would use the result of foo(4) as the template parameter.
Use e.g. { foo(4); } instead (a function that calls foo with the
desired argument).
- David
Re: Instantiate!(Template, args) in Phobos?
On Thursday, 21 April 2016 at 14:47:55 UTC, Nick Treleaven wrote: I found std.meta.ApplyLeft but it doesn't seem to work here. I've needed this before and ended up doing a workaround with a template block and temporary alias but it might be nice if Phobos had this. Or is there a simpler solution? From std.meta: --- /* * Instantiates the given template with the given list of parameters. * * Used to work around syntactic limitations of D with regard to instantiating * a template from an alias sequence (e.g. T[0]!(...) is not valid) or a template * returning another template (e.g. Foo!(Bar)!(Baz) is not allowed). */ // TODO: Consider publicly exposing this, maybe even if only for better // understandability of error messages. alias Instantiate(alias Template, Params...) = Template!Params; --- ;) — David
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 18:02:01 UTC, David Nies wrote: How do I mark it as such? Can you please give an example? Thanks for the quick reply! :) Just add extern(C) to the beginning of the "alias" line. — David
Re: My is the order of parameters reversed for functions that are dynamically loaded from shared C libraries?
On Sunday, 15 November 2015 at 17:54:27 UTC, David Nies wrote: How can I make sure the order is correct? Whenever you use a C function, it must be marked as, even if it's through a function pointer as in this case. Just apply the attribute to the dll2_fn and dll3_fn declarations. Hope this helps, David
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library. "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting). — David
Re: ORM libraries for D
On Thursday, 24 September 2015 at 13:24:14 UTC, Rikki Cattermole wrote: Dvorm is more or less feature complete :) I am the author of it, but unless issues come up I do not intend to continue working upon it. Do you know whether somebody has written an SQLite provide for it? I was going to use SQLite initially, hoping to just switch to MySQL/PostgreSQL later in case I unexpectedly need more than that later. — David
ORM libraries for D
Hi all, I'm having a look at ORM libraries in D right now. So far, I've come across hibernated and dvorm. Are there any other libraries that I should have a look at, particularly actively maintained ones? dvorm and hibernated seem to have received no work during the last couple of months. — David
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Sunday, 8 March 2015 at 18:18:49 UTC, Carl Sturtivant wrote: Should I be doing something special with linkage so this works? What is going on? IIRC there are some fixes to the Win64 context switching code in the 2.067 or master druntime. You might want to try those first before spending more time tracking this down. — David
Re: How do I write __simd(void16*, void16) ?
On Thursday, 9 October 2014 at 20:29:44 UTC, Benjamin Thaut wrote: Unforunately the gcc.buildints module seems to be generated during compilation of gdc, so you might want to get a binary version or compile it yourself to see the module. By the way, LDC has ldc.gccbuiltins_x86 too. LLVM doesn't export all the GCC-style intrinsics, though, if they are easily representable in normal LLVM IR (thus ldc.simd). Daivd
Re: DUB Errors
On Friday, 3 October 2014 at 23:00:53 UTC, Brian Hechinger wrote: With my old set of packages I had no problems. I just now deleted ~/.dub and now I too get this error. Some issue with the openssl module, yes, but what? This is a bit of an issue. :) At first glance, this seems like a forward reference issue. deimos.openssl.ossl_typ imports deimos.openssl.ssl, but also the other way round. I had a similar problem where everything worked before, but then I deleted all DUB caches and now vibe.d doesn't build anymore (master and 0.7.21-rc1). David
Re: Building a dmd that works on old systems: TLS problems with libc
On Friday, 3 October 2014 at 08:47:07 UTC, Atila Neves wrote: ld: <...>/libphobos2.a(sections_linux_570_420.o): undefined reference to symbol '__tls_get_addr@@GLIBC_2.3' /lib64/ld-linux-x86-64.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status So to be clear, this is with a libphobos2.a built on the target system? The error message looks like you might have a Phobos library built for a newer libc. David
Re: String Theory Questions
On Saturday, 13 September 2014 at 22:41:39 UTC, AsmMan wrote: D string are actullay C-strings? No. But string *literals* are guaranteed to be 0-terminated for easier interoperability with C code. David
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 16:36:38 UTC, Kagamin wrote: Looks like mingw supports 3 types of exception handling. LDC usually tightly coupled with mingw version, you shouldn't try it blindly, but follow installation instructions instead. It's not really tightly coupled to the MinGW version per se. What is required is Dwarf 2 EH and a working TLS implementation. The latter is the reason for the "recent version of mingw-w64" requirement, because I fixed the implementation there a year ago or so. No idea if the mingw.org people have gotten their act together since. That being said, it still makes sense to try a known good version first, as LDC exercises quite a large part of the compiler/runtime features, some of which aren't needed in more wide-spread use cases (for example native TLS). David
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 16:11:55 UTC, Russel Winder via Digitalmars-d-learn wrote: I installed the other MinGW option and it provides libgcc_s_sjlj-1.dll which is not helping me actually run ldc2 on Windows :-( It is mentioned both the in README coming with the Windows packages and the on wiki [1] that you need a Dwarf 2 EH package (-dw2) of MinGW-w64 for LDC to work. How can we make this more clear? Cheers, David [1] http://wiki.dlang.org/Building_LDC_on_MinGW_x86
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote: SEH was patented, so llvm doesn't support it. That has changed. Has it? SEH on Win64 is something entirely different from the original (x86) SEH design, and not covered by said patent. David
Re: Threadpools, difference between DMD and LDC
On Monday, 4 August 2014 at 05:14:22 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
This is correct – the LLVM optimizer indeed gets rid of the
loop completely.
OK,that's clever. But I get this even when put a writeln("some
msg")
inside the task. I thought a write couldn't be optimized away
that way
and that it's a slow operation?
You need the _result_ of the computation for the writeln. LLVM's
optimizer recognizes what the loop tries to compute, though, and
replaces it with an equivalent expression for the sum of the
series, as Trass3r alluded to.
Cheers,
David
Re: Threadpools, difference between DMD and LDC
On Sunday, 3 August 2014 at 22:24:22 UTC, safety0ff wrote: On Sunday, 3 August 2014 at 19:52:42 UTC, Philippe Sigaud wrote: Can someone confirm the results and tell me what I'm doing wrong? LDC is likely optimizing the summation: int sum = 0; foreach(i; 0..task.goal) sum += i; To something like: int sum = cast(int)(cast(ulong)(task.goal-1)*task.goal/2); This is correct – the LLVM optimizer indeed gets rid of the loop completely. Although I'd be more than happy to be able to claim a thousandfold speedup over DMD on real-world applications. ;) Cheers, David
Re: Some kind of RPC exists for D?
On Thursday, 19 June 2014 at 12:13:12 UTC, Dicebot wrote: However if you application design implies thousands of RPC calls per second it is quite likely performance won't be good with any RPC implementation :) Backend people at Google, Facebook, and others would beg to disagree. ;) Of course, the calls counted here are from multiple clients to a single server. If your fan-out is in the thousands, then you indeed have a problem. David
Re: Run child process with null stdin/stdout
On Wednesday, 18 June 2014 at 20:00:43 UTC, Justin Whear wrote:
For POSIX, seems like you could pass `File("/dev/null", "r")`
for stdin
and `File("/dev/null", "w")`. On Windows I believe you can use
`File
("nul")` for the same effect.
Implementing this myself is of course always an option, yes, but
I would have liked to avoid platform-dependent code.
Hm, I just checked the source, and there doesn't seem to be a
better option indeed…
Thanks,
David
Run child process with null stdin/stdout
Hi all, is there a platform independent way to do the equivalent of "some_program < /dev/null > /dev/null" using std.process? I neither want to capture/print the standard output of the child process nor have anything available on its input. Quite probably, I'm just missing something obvious… Cheers, David
Re: Some kind of RPC exists for D?
On Wednesday, 18 June 2014 at 19:24:03 UTC, Bienlein wrote: I'm looking for a way to do some kind of RPC in D. Some way of being able to say aFoo.bar(int i, ...) with receiver object and method being marshalled at the sender's site and being unmarshalled and invoked at the receiver's site. Any hints appreciated. I wrote an implementation of Thrift for D a while back. It supports RPC and marshalling of arbitrary objects within the boundaries set by the Thrift protocol (no classes, no pointers, …). David
Re: DMD Compiler Version Dependent Conditional Compilation
On Monday, 9 June 2014 at 17:36:10 UTC, Nordlöw wrote: Can I use the version keyword or static if to perform conditional compilation that depends on the version of DMD? The __VERSION__ magic token should do the job. David
Re: Array!T and find are slow
On Wednesday, 14 May 2014 at 17:36:35 UTC, monarch_dodra wrote: Adding a special case "in" Array.Range allows bypassing the repeated indexing costs, but at the very least, should be implemented "in terms of" find itself, eg: Shouldn't the extra indirection just vanish into thin air once opIndex or what have you is inlined? I don't see a conceptual reason for overhead in this case. Of course, the compiler probably wouldn't be able to infer any of the memchr/… optimizations find does for the array case, but Damian's alternative version doesn't do any of that either. David
Re: Array!T and find are slow
On Wednesday, 14 May 2014 at 15:42:13 UTC, Damian Day wrote: On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger wrote: Could you post a short benchmark snippet explicitly showing the problem? Benchmark found here: http://dpaste.dzfl.pl/0058fc8341830 Unfortunately, I don't have the time to look at the details right now, but https://github.com/D-Programming-Language/phobos/pull/1713 might have improved the situation somewhat. David
Re: Array!T and find are slow
On Wednesday, 14 May 2014 at 14:24:28 UTC, Damian Day wrote: I've written some search functions, which are many times faster, is it worth making a pull request? Generally, we strive to make the algorithms in Phobos as fast as possible even in the general case. I didn't look at the issue at hand in any detail, but if the "-O -release -inline" performance when operating on Arrays is considerably worse than when directly operating on the data, we have a problem, as it likely to also impact other ranges. In short, I don't think the best solution is to add this special case to Array!T, but rather to figure out what exactly is wrong with Array!T and/or find() and fix the problem at its source. Could you post a short benchmark snippet explicitly showing the problem? Best, David
Re: What's the current phobos way to define generic data sources and sinks?
On Wednesday, 16 April 2014 at 21:05:30 UTC, Hannes Steffenhagen wrote: I've looked at std.stream, but it says in big red scary letters that I probably shouldn't be using it. Is there a suitable replacement? If not, I'd just roll my own and provide a couple of templates to automatically generate wrappers for them. Have you looked into input and output ranges? Without knowing the specific details of what you need, ranges would be the way to go. David
Re: TLF = thread local functions
On Thursday, 23 January 2014 at 16:15:46 UTC, Frustrated wrote: The point is that making the **STACK** TLS too should a way around having to use synchronization. Precisely because the STACK is not TLS makes functions not thread safe(since data is already "safe" in d). Maybe you could elaborate a bit on where you see the problem here? The claim that stack memory is not thread-local contradicts commonly used terminology, since the execution stack is intrinsically part of a single thread. In fact, from a user-space perspective a context switch is little more than just switching out the CPU registers, including the stack pointer, for a different set. David
Re: Another purity question
On Tuesday, 14 January 2014 at 20:36:43 UTC, Timon Gehr wrote: Yes, it should. https://d.puremagic.com/issues/show_bug.cgi?id=9148 And, of course, you are right. ;) I missed the analogy to member functions w.r.t. the implicit context parameter. Shame on me. David
Re: Another purity question
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return &bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
---
David
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 15:12:21 UTC, Ben Cumming wrote: On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote: I don't think 2.064 LDC has been released yet So I see, thanks. The "merge-2.064" branch in Git is stable enough already for most purposes, so if you don't mind building from Git, you can have an LDC version based on 2.064.2 already. We really need to work out a plan to get a release done… ;) David
Re: Ultra-pure map()?
On Saturday, 28 December 2013 at 01:41:35 UTC, David Held wrote: Can someone explain to me why map() is not equivalent to foreach in the code above? From what I can tell, map() doesn't do anything at all on objs, even though it is a perfectly legitimate range (as far as I can tell). map() constructs a range that invokes a given function on the source range if an element is requested – but only then. In other words, map is fully lazy. David
Re: std.net.curl - get() is too slow
On Friday, 20 December 2013 at 18:23:30 UTC, Benji wrote: When I call get() function from std.net.curl, I notice it's extremely slow! Maybe 50 times slower than in Python.. Is there any better/faster alternative? How do you benchmark the functions? David
Re: How to correctly deal with unicode strings?
On Wednesday, 27 November 2013 at 14:34:15 UTC, Gary Willoughby wrote: Here i understand what is happening but how could i improve this example to make the expected asserts true? In this specific example you could e.g. use std.uni.normalize, which by default puts the string into NFC, which has all the canonical compositions applied (e.g. ë as a single character). David
Re: pure-ifying my code
On Sunday, 17 November 2013 at 10:33:12 UTC, Philippe Sigaud wrote: But `popFront()` changes an internal state with visible, external effects: it changes `front` return value and in the end, it will affect `empty` return value. So no, I don't consider `popFront` to be pure. That's actually not a reason for them to be impure (see e.g. http://klickverbot.at/blog/2012/05/purity-in-d#pure_member_functions for my attempt on explaining that). David
Re: [challenge] Lazy flatten/avoiding type forward reference with map
On Friday, 1 November 2013 at 09:34:20 UTC, Philippe Sigaud wrote: But can you think of a more simple/elegant workaround? Is a standard lazy struct range authorized? Sure. This wasn't intended as an actual challenge, as I don't have a "right" answer myself (or a prize, for that matter). ;) I just thought I'd be interested to see what the best solution we can find in terms of conciseness is. David
[challenge] Lazy flatten/avoiding type forward reference with map
A while back, somebody raised the topic of implementing a lazy
range for traversing/flattening a tree structure on #d.
The obvious (in terms of Phobos primitives) solution would be
something along the lines of this:
---
struct Node(T) {
T val;
Node!T[] children;
}
auto flatten(T)(Node!T root) {
import std.algorithm, std.range;
return only(root.val).chain(map!flatten(root.children).joiner);
}
void main() {
alias N = Node!int;
auto a = N(1, [
N(2, [
N(3, [
N(4)
])
]),
N(5)
]);
import std.stdio;
writeln(a.flatten); // [1, 2, 3, 4, 5]
}
---
But of course, that piece of code does not compile with current
DMD, as the return type of flatten() can't refer to the function
itself (during name mangling).
Now, one way around this would be to add an array() call at the
end of the return statement, which hides the type of map!flatten,
but at the cost of many unnecessary memory allocations. A second
option would be to use inputRangeObject to convert the return
value to ForwardRange!T (well, that is if it actually worked, due
to an implementation bug it leads to a runtime crash).
But can you think of a more simple/elegant workaround?
(Note aside: Obviously, the fact that the code relies on
recursion might be an issue, and a simple opApply-based solution
with a worklist stack would likely perform better. Still, I think
it's a simple, yet interesting problem.)
David
Re: Lambda are capricious little animals indeed
On Sunday, 27 October 2013 at 14:01:31 UTC, Derix wrote:
I get the immutable(char)[] : an immutable array of characters,
why not. But I really don"t get the set of parens between the
square brackets and the asterisk. Could that mean that what I
get is in fact a pointer to a function ? (said function having
no arguments, or having void as sole argument or ...)
Yes, this is correct.
You still have to call the lambda: { return 42; }().
David
Re: Building derelict
On Tuesday, 22 October 2013 at 22:24:36 UTC, bioinfornatics wrote: derelict/pq/types.d(117): Error: struct derelict.pq.types.PGconn unknown size derelict/pq/types.d(117): Error: struct derelict.pq.types.PGconn no size yet for forward reference That's with LDC, right? We definitely need to improve the error message (it should refer to the actual function definition), but I checked the Derelict source a few weeks back and if you grep it for PGconn, you'll find that it is used in a function parameter (for which the actual type is needed for the x86-64 ABI handling code). If you don't need that function, just comment it out. David
Re: Derelict Assimp RemoveComponent
On Wednesday, 25 September 2013 at 15:32:08 UTC, Lemonfiend wrote: The docs only mention http://assimp.sourceforge.net/lib_html/config_8h.html#afc0a4c00fb90c345eb38fe3f7d7c8637 which is less than helpful.. I'm not sure what the problem is here. Just as the docs say, you have to set the (integer) AI_CONFIG_PP_RVC_FLAGS config option to a bitwise combination of aiComponent members. I think the corresponding C API function is aiSetImportPropertyInteger. David
Re: join of range of ranges?
On Sunday, 22 September 2013 at 14:26:14 UTC, bearophile wrote: In some cases I'd like to join a range of ranges in a single array/string (I know here the inner map could be replaced by something better, this code is just an example): std.algorithm.joiner, or am I missing something? David
Re: Unable to use tradional tools to find memory leaks
On Saturday, 21 September 2013 at 17:03:14 UTC, Brad Roberts wrote: That's wrong. Both DMD and Valgrind are software, both of which can be debugged and changed. Please file appropriate bug reports, hopefully with nicely minimized test cases. I ran into an issue like this once where DMD would generate a strange instruction prefix on Linux x86_64 that was not supported by Valgrind. Never went on to check whether it was actually legal though. If I recall correctly, Valgrind reports details about the problematic instruction on the console before it terminates. If its an instruction encoding issue, just disassemble your program at/around the given address (e.g. using objdump -d) and post the result together with the error message. David
Re: N step fft in D language
On Sunday, 15 September 2013 at 20:58:54 UTC, Kadir Erdem Demir wrote: I believe I am well aware of the things which are explained in the link. There is a sentence in link which says : "The first bin in the FFT is DC (0 Hz), the second bin is Fs / N, where Fs is the sample rate and N is the size of the FFT." My question how can I determine the "N" which is the size of FFT ? In fftw library one can define N like : fftw_create_plan(N, FFTW_FORWARD, FFTW_ESTIMATE); In D do we have a way to do that ? I am not aware of the details of that particular FFTW function, but mathematically, the result of the Fourier transform of a given vector is _always_ a vector of the same size. Thus, I guess using FFTW in that way just amounts to the equivalent of fft(timeDomainAmplitudeVal[0 .. N]). David
Re: is the tools part of the test suite? currently tools/ddemangle doesn't compile on git master
On Saturday, 24 August 2013 at 03:20:42 UTC, Timothee Cour wrote: More often than not, the tools submodule ( https://github.com/D-Programming-Language/tools) will not build on git master. So I'm wondering whether it's even being tested before pushing commits. In short: no, unfortunately. David
Re: Large (>32 byte) concurrency messages
On Thursday, 8 August 2013 at 20:08:11 UTC, JR wrote: I put together http://dpaste.dzfl.pl/d7322971 earlier to demonstrate some of these errors, though I didn't mention the raciness of passing pointers there. To test that race I used http://dpaste.dzfl.pl/e6fd4569. That's just a bug in your code; when taking a pointer to stack data (which is un-@safe), you have to take care not to escape it from the scope. Are there any easy workarounds? Do people use std.concurrency, or is it largely avoided? Variant also seems to have some major issues... or maybe everything is caused by Variant and std.concurrency just exposes it. Yep, the two issues are really just bugs in std.variant. std.concurrency itself is pretty nice and should be rather stable. The only major impediment is that 'shared' isn't really anywhere near useful right now, so you have to pretty much manually add/remove it when processing messages that contain mutable indirections (and hope you don't screw up in the process). David
Re: Large (>32 byte) concurrency messages
On Thursday, 8 August 2013 at 20:08:11 UTC, JR wrote: Passing by value, e.g. tid.send(eventStruct); core.exception.AssertError@/usr/include/d/4.8/std/variant.d(280): target must be non-null http://d.puremagic.com/issues/show_bug.cgi?id=9122, should be fixed now. Passing by immutable, e.g. tid.send(cast(immutable) eventStruct); /usr/include/d/4.8/std/variant.d:552: Error: cannot modify immutable expression *p /usr/include/d/4.8/std/concurrency.d:111: Error: template instance std.variant.VariantN!(32LU).VariantN.opAssign!(immutable(IrcEvent)) error instantiating http://d.puremagic.com/issues/show_bug.cgi?id=10740 David
Re: Socket.select interrupted system call because of GC
On Saturday, 3 August 2013 at 15:59:30 UTC, Marek Janukowicz wrote: It's really nice to have some chat about the correctness of example code snippets, but can anyone help me with the original issue? :) Sorry, apparently I forgot to include the actual content:. ;) Socket.select is an ancient (in D terms) API; you just need to handle the returned error code manually and retry if the errno is actually EINTR resp. its WinSock equivalent. See https://github.com/apache/thrift/blob/master/lib/d/src/thrift/server/transport/socket.d#L144 for a production-tested implementation. When I wrote that code, it wasn't possible to do this in a platform-independent way using std.socket (see https://github.com/apache/thrift/blob/master/lib/d/src/thrift/internal/socket.d for the used constants), and I don't think it is now either. David
Re: Socket.select interrupted system call because of GC
On Saturday, 3 August 2013 at 13:19:53 UTC, dennis luehring wrote: but you should not reduce your sample down to maybe-incorrect (what it seems for me in this case) - the join wouldn't make your sample to big The example given is correct, as druntime guarantees that non-daemon threads will run to completion before the program terminates normally (see Thread.isDaemon). David
Re: Friend class and methods
On Wednesday, 12 June 2013 at 19:01:24 UTC, Maxime Chevalier-Boisvert wrote: Does D have something like the concept of friend classes and functions in C++? I'd like to have a function that can access private members of two classes at the same time. No (t really), you have to stick the two classes into the same module. David
Re: until strange behavior
On Sunday, 2 June 2013 at 16:21:46 UTC, David Nadlinger wrote: On Sunday, 2 June 2013 at 13:26:02 UTC, Jack Applegame wrote: ElementType works as intended. As to whether that is a good idea… – just search the NG archives for "string range element type" or something like that. (See also: ElementEncodingType)
Re: until strange behavior
On Sunday, 2 June 2013 at 13:26:02 UTC, Jack Applegame wrote: It is something wrong with ElementType template. ElementType works as intended. As to whether that is a good idea… – just search the NG archives for "string range element type" or something like that. David
Re: two mains
On Saturday, 26 January 2013 at 20:57:54 UTC, Tyro[17] wrote: On 1/26/13 3:42 PM, Tyro[17] wrote: The second is the use of leave in [2]. If I understand correctly, leave is the exact same as: movRBP,RSP popRBP So why do we need to mov RBP, RSP in [2] but not in [1]? I'm thinking this is because RBP contains the address of args but not sure. Still not clear on this choice. Both functions could be replaced with --- _Dmain: xor EAX, EAX ret --- as they don't need to store anything on the stack at all. What you are seeing is just an odd result of the way the compiler generates the code internally, especially if you are compiling without optimizations on. For further information on what EBP/RBP is needed for, try searching for discussions about the (mis)use of GCC's omit-frame-pointer option, such as: http://stackoverflow.com/questions/579262/what-is-the-purpose-of-the-frame-pointer David
Re: two mains
On Saturday, 26 January 2013 at 20:42:27 UTC, Tyro[17] wrote:
Trying to learn from the ground up and would appreciate some
assistance making sense of the following:
// void main(){} [1]
[...]
This might not be directly relevant here, but in general, I'd
steer clear of main() for such experiments. Due to its special
nature (several possible signatures, but the calling code in
druntime stays the same), there is quite a bit of extra magic
going on internally.
For example, you wouldn't normally find "xor EAX, EAX" in a
void-returning functions, as its purpose is to set the return
value to 0, which implicitly happens to make the void main() and
void main(string[]) variants conform to the "full" int
main(string[]) signature.
David
Re: Is this a bug?
Yes, this seems to be a DMD codegen bug – works with LDC. David
Re: this(this) / opAssign
On Thursday, 10 January 2013 at 23:37:14 UTC, Namespace wrote: Without a declared opAssign, this S s3; s3 = s1; also calls the postblit. That is strange. Think of it like this: Blit means bit-by-bit copy, so a postblit is a function that is invoked on the result of every bit-by-bit copy operation. The default behavior for struct assignment is precisely to copy over the contents, so it makes sense for the postblit to be invoked in that case. David
Re: release mode optimization
On Thursday, 10 January 2013 at 01:14:42 UTC, H. S. Teoh wrote: I tested DMD on a loop containing assert(true);, and apparently that *is* optimized out with -O. I tested it with the program from Jonathan's post – still has an empty inc/cmp/jl loop in there with -O -release (x86_64). David
Re: release mode optimization
On Thursday, 10 January 2013 at 00:40:21 UTC, Jonathan M Davis wrote: So clearly, dmd does _not_ optimize out the loop. I have no idea what gdc and ldc do though. Wow, DMD doesn't optimize it away indeed, just confirmed that by a look at the assembly. LDC does delete the loop though, starting at -O1, and I can't imagine that GDC wouldn't as well. David
Re: detecting POD types
On Sunday, 20 May 2012 at 13:50:17 UTC, japplegame wrote: I write function template that should works only with POD types (i.e. base types, structures, enums etc.). Is there something like C++11 std::is_pod (http://en.cppreference.com/w/cpp/types/is_pod) template? Sorry for resurrecting this old thread, but: What is your definition of "plain old data"? The D language doesn't have one. David
Re: AES-NI
On Saturday, 8 December 2012 at 20:14:09 UTC, Heinz wrote: Just in case i've been looking for the corresponding machine codes and can not find them, i've searched even in Intel's AES whitepaper with no luck. You probably want to have a look at the Intel Instruction Set Reference document. When I am looking for things like this, I'm tend to be lazy and just search my PDF copy of the »Combined Volume Set of Intel® 64 and IA-32 Architectures Software Developer’s Manuals«, downloadable here: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html (the documentation for AESENC, for example, is at Vol. 2A, 3-44) David
Re: template error instantiating
On Sunday, 18 November 2012 at 10:19:47 UTC, Manfred Nowak wrote: I will be quiet on this, because non formal specifications tend to have ambiguities and I believe that the ambiguity I see escapes the intended scope; but I am not willing to check for this---and it is fruitless to explain such cases. I'm pretty sure it is not related at all, you might have just been mistaking it for something else. However, if you really think it is unclear, please don't just ignore that, but submit an issue or preferably a d-p-l.org pull request so that the ambiguity will be removed. David
