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
