Debug info for druntime.
What is the fastest way to have the detailed debug info for druntime? I have a program that fails in Fiber constructor after I create and delete at least 68_209 Fibers one after another. For 68_208 works fine, one more and it aborts. I'm trying to use gdb to debug, but most likely don't have symbols for druntime. I compiled the druntime from source, is there a way to make the dmd/dub use the source compiled version?
Re: Metaprogramming, generate argument list.
On Tuesday, 23 August 2016 at 07:17:16 UTC, Jack Applegame wrote:
This is impossible since pointers to local variables are
unknown at compile time.
This is a bit strange, as the local variables aren't known either
and they seem to work. I do not want to get the address, rather
an alias to `` expression.
But you can generate arguments list that contains functions
that return pointers at run-time:
template Repeat(int N, alias variable) {
auto ptr() @property { return }
import std.meta : AliasSeq;
static if(N == 1) alias Repeat = ptr;
else alias Repeat = AliasSeq!(ptr, Repeat!(N-1, variable));
}
void foo(int* x, int* y, int* z) {
}
void main() {
int bar = 42;
foo(Repeat!(3, bar));
}
Anyway, this solution works perfectly fine, thanks.
Metaprogramming, generate argument list.
Is it possible to generate an argument list that contains
pointers to local variables at compile time?
For example, consider following code:
template Repeat(alias int N, alias variable)
{
// Magic
alias Repeat = /* Even more magic */;
}
void foo(int* x, int* y, int* z)
{
// [...]
}
void fun()
{
int bar = 42;
foo(Repeat!(3, bar)); // want to replace it with , ,
}
Re: C-binding external array.
On Wednesday, 10 August 2016 at 15:07:52 UTC, Ali Çehreli wrote:
On 08/10/2016 02:05 AM, ciechowoj wrote:
Better with some mixin magic:
mixin template CArray(string symbol, T) {
pragma(mangle, symbol) extern extern(C) __gshared
mixin ("T[0] _c" ~ symbol ~ ";");
@property
mixin ("T* " ~ symbol ~ "() { return _c" ~ symbol ~ ".ptr;
}");
}
mixin CArray!("tab", int);
tab[42] = 42;
This is very tempting to use. The only thing that stops me from
doing that is I am unsure if the 'property' tab behaves in all
contexts the same way the standard array behaves.
Re: C-binding external array.
On Tuesday, 9 August 2016 at 19:16:46 UTC, Ali Çehreli wrote:
Well, C's array symbol is used as a pointer to the first
element and D allows array indexing for pointers as well.
Here is the C code:
// c.c
#include "stdio.h"
int tab[64];
int *get() {
return tab;// or [0]
}
void info() {
printf("%p\n", tab);
}
[...]
The problem is, I do not have a control over the C source code.
Re: C-binding external array.
On Tuesday, 9 August 2016 at 19:16:42 UTC, Steven Schveighoffer
wrote:
D has an answer:
pragma(mangle, "tab")
extern extern(C) int[1] _ctab;
@property int* tab() { return _ctab.ptr; }
I still don't recommend doing this, for previously stated
reasons.
This is really interesting :).
Re: C-binding external array.
On Tuesday, 9 August 2016 at 15:41:08 UTC, Steven Schveighoffer
wrote:
Well, you can via properties:
@property int* tabp() { return tab.ptr; }
tabp[elem];
This is nice. The best would be to have it with the same name as
original symbol, but I can't imagine how it could be done.
Essentially, tab is a symbol that points at some undetermined
number of elements. Since it's undetermined, D doesn't allow
safe easy access.
If you did int *tab, then it would think the symbol points at a
pointer.
tab.ptr is a shortcut to [0].
You could potentially do int tab, and then use ()[elem].
Or if you know the number of elements, you can just declare
them.
If it were me, I'd access it via tab.ptr, because it *is* an
unsafe operation and I'd want to highlight that for future
readers.
If something defines tab's length, I'd highly recommend
wrapping the two:
extern(C) int tabLength(); // mythical mechanism or no?
@property int[] dtab { return tab.ptr[0 .. tabLength]; }
And this is even better. However, I suppose you are right and I
should stick to `tab.ptr`.
Re: C-binding external array.
On Tuesday, 9 August 2016 at 14:25:15 UTC, Kagamin wrote: Well extern extern(C) __gshared int[64] tab; My assumption is you do not know the size of the array.
Re: C-binding external array.
On Tuesday, 9 August 2016 at 14:01:17 UTC, Steven Schveighoffer wrote: I think this should work: extern extern(C) int[1] tab; Then if you want to access the elements, use the tab.ptr[elem] If it's a global variable, tack on __gshared. -Steve I've already tried this and works (64-bit at least on linux). But is it portable? No other way that allow to access the `tab` directly (without .ptr proxy) ?
C-binding external array.
Is there a way to access a static array from D without knowing the size of the array? Let suppose there is an array, somewhere in lib.c. int tab[64]; and there is header file lib.h with following reference: extern int tab[]; How to declare `tab` in the D code without knowing the size of the array? In other words, how to map external declaration of the `tab` to the D code?
Re: Linking on MS Windows.
On Saturday, 6 August 2016 at 11:58:31 UTC, rikki cattermole wrote: We provide Optlink so that we have support for Windows out of the box. Unfortunately since Optlink does not understand COFF, we are forced to provide a second command option to force MSVC tooling for 32bit usage. That makes sense.
Re: Linking on MS Windows.
On Saturday, 6 August 2016 at 12:06:02 UTC, Kai Nacke wrote: If you are already using Visual Studio and LLVM/clang then why not use ldc? The compiler itself is built with this toolchain... I'm considering that option. However, as the project I want to compile is dstep, I want it to compile smoothly with dmd. Any ideas about that strange liker error?
Re: Linking on MS Windows.
I managed to compile both 32 and 64 bit release versions and it seems to work fine, however with 64-bit debug version I'm getting a strange error: LINK : fatal error LNK1101: incorrect MSPDB120.DLL version; recheck installation of this product Does anyone know why it is so? I'm compiling with -m64 switch, so I suppose the linker from Visual Studio is used by default. Another question that is troubling me is why to use OPTLINK as a default for 32-bit version, if for 64-bit version a Visual Studio linker is used anyway?
Re: Linking on MS Windows.
On Friday, 5 August 2016 at 18:37:43 UTC, Jonathan M Davis wrote: I know that dmd supports VS' binary format and linker for 64-bit (dmc and optlink were never updated to support 64-bit), and I think that 32-bit support for using VS' library format and linker were added later. So, I'm fairly certain that you could compile your D program to be compatible with that statically linked library by using the right compiler flag with dmd. But I don't use Windows much aside from work, so I'm not very familiar with how to use dmd with Windows beyond the basics and am not going to be very helpful in telling you how to actually do it. You might be able to figure it out by looking at dmd's compiler flags, but if not, I'm sure that someone else here who actually uses Windows with D will be able to tell you. - Jonathan M Davis Owing to your reply I found this: http://stackoverflow.com/questions/36332219/linking-with-c-libraries-on-windows-with-dub And it even seems to work. Thanks.
Linking on MS Windows.
Is default dmd linker (on MS Windows, OPTILINK) supposed to link against static libraries created with Visual Studio? Specifically I want to link a project compiled on windows with dmd against pre-compiled library `libclang.lib` from LLVM suite. I'm pretty sure they used Visual Studio to compile the library.
Re: C's void func() vs. void func(void).
On Friday, 29 July 2016 at 12:20:17 UTC, Mike Parker wrote:
Though, I should add the caveat that you need to ensure the
definition of the C function does not specify any parameters.
AFAIK, this is legal:
// foo.h
void func();
// foo.c
void func(int a, int b) { ... }
In which case you would want to include the parameters in your
binding.
Thanks, good to know.
C's void func() vs. void func(void).
In C, a function `void func()` doesn't declare a function without arguments, instead it declares a function that takes unspecified number of arguments. The correct way to declare a function that takes no arguments is to use the `void` keyword: `void func(void)`. What is the correct way to refer to such a function (`void func()`) from D bindings? If I assume that the unspecified number of arguments (for some particular function) is equal to zero, is `extern (C) void func()` a correct D binding to the both functions `void func()` and `void func(void)` declared in C? Specifically, I'm concerned about calling convention issues.
Re: Speed up `dub`.
On Sunday, 5 June 2016 at 21:20:20 UTC, Andrej Mitrovic wrote:
On Thursday, 2 June 2016 at 13:04:00 UTC, ciechowoj wrote:
and found that an assert from `std/path.d:3168` (`globMatch`)
contributes a major amount to the running time of dub.
```
assert(balancedParens(pattern, '[', ']', 0));
assert(balancedParens(pattern, '{', '}', 0));
```
Hmm.. that sounds like the dub binary that's distributed is
running its unittests at start. If that's true I don't think
they should be part of the released binary..
Actually, that assertions are invoked from precondition block of
`globMatch`. On the other hand `globMatch` is invoked from
`std.file.dirEntry`. So, I suppose it is fine if it goes about
unit tests.
Re: Speed up `dub`.
Maybe it would be worth to write something about the issue here https://github.com/dlang/dub#installation . I'm curious how the pre-compiled versions are built.
Re: Speed up `dub`.
On Thursday, 2 June 2016 at 12:20:50 UTC, Jacob Carlborg wrote:
On 2016-06-01 23:33, ciechowoj wrote:
Hahahaa. Who could possibly think that `build.sh` builds dub
in debug
mode? With -release -O -inline -m64 it runs 5 times faster :
P. It made
my day...
Haha really?
Yes, I should have done it at the beginning, but yesterday I
decided to see what is really happening and compiled dub with
`-profile` and found that an assert from `std/path.d:3168`
(`globMatch`) contributes a major amount to the running time of
dub.
```
assert(balancedParens(pattern, '[', ']', 0));
assert(balancedParens(pattern, '{', '}', 0));
```
Re: Speed up `dub`.
Hahahaa. Who could possibly think that `build.sh` builds dub in debug mode? With -release -O -inline -m64 it runs 5 times faster : P. It made my day...
Re: mutable keyword
On Saturday, 21 May 2016 at 00:39:21 UTC, Jonathan M Davis wrote: Well, if you actually tried marking functions with pure, you'd see pretty fast that this won't work with pure. A function that's marked with pure cannot access any global, mutable state. It can only access what's passed to it (though in the case of a member function, that includes the this pointer/reference). So, your refCountPool will not be accessible from any pure functions. Well, I do not have much experience with @pure in D. But I believe that as far as I'm not using refCounter-modifying methods of sharedPtr (constructors, assignement, destructor) it should work. Maybe I'll try it in some future. You can think of pure as @noglobal, because it can't access global variables (unless they're constants). That's it's only restriction, but it's enough to make it so that the only way that you'd have a backdoor out of const in a pure, const member function is if you passed a mutable reference to the object as one of the function arguments. At this point, if you want ref-counting, you give up on const. They simply do not go together. The same goes for stuff like caching or lazy initialization. Sure, you can get around const to some extent by giving up on pure, but that only works because you're putting the state of the object outside of the object itself, which is usally a bad idea. It also makes it so that const seems like a lie, since the state of the object isn't really const, since it's not actually in the object. I didn't tried the proposed solution, but if this is only ideological problem and not a technical one, I would be good with such a solution. On one side the memory reachable from object isn't modified on the other side the object feels like a const for the end-used. I mean I miss a logical const from C++ : ). The standard library already has std.typecons.RefCounted, if you want to ref-count anything other than classes, but it really doesn't work with const and fundamentally can't. In order to have const ref-counting, we're going to need language support. D does not and likely will never have any form of "logical" const. If it's const, it's const. Either that fits with what you're doing, and you can use const, or it doesn't, and you can't. I'm currently doing that, but std.typecons.RefCounted is uncomfortable to use. Probably for reasons mentioned above.
Re: mutable keyword
On Friday, 20 May 2016 at 20:45:05 UTC, Jonathan M Davis wrote:
If you want something that's ref-counted and works in pure
code, const will _not_ work, because you can't legally alter
the ref-count.
What about something like this (ignoring multi-threading issues):
struct RefCountPool {
size_t acquireIndex();
void releaseIndex(size_t index);
size_t* accessRefCounter(size_t index);
}
RefCountPool refCountPool;
struct SharedPtr
{
size_t index;
void* ptr;
SharedPtr(void* ptr) {
this.ptr = ptr;
index = refCountPool.acquireIndex();
}
// more methods, counter manipulation through accessRefCounter
}
Is is still legal? Would it breach @pure requirements (I believe
so...)? After all it doesn't differs much from having a pointer
instead of index.
Re: mutable keyword
On Friday, 20 May 2016 at 18:23:26 UTC, Jack Applegame wrote:
On Friday, 20 May 2016 at 17:28:55 UTC, Namespace wrote:
But you can cheat:
You can just cast const away:
struct A {
int id = 0;
this(int id) {
this.id = id;
}
void change() const {
(cast() id)++;
}
}
void main() {
import std.stdio;
A a = A(42);
a.change();
writeln(a.id);
}
Is it valid code (I'm asking about undefined behavior)?
Re: mutable keyword
On Thursday, 19 May 2016 at 23:21:14 UTC, Jonathan M Davis wrote: On Thursday, May 19, 2016 20:44:54 ciechowoj via Digitalmars-d-learn wrote: Is there D equivalent of C++'s mutable keyword? Like the one that allows to modify a field of struct from constant method. Or some alternative solution? Now, if your functions aren't pure, you can put state outside of the object itself and have a const member function access and mutate that external state, but that's not exactly great for encapsulation, and then you can't use that function in pure code. But it's the closest thing to a backdoor from const that exists in D, because const is set up so that it's actually const and not just const until the implementation decides to mutate it anyway. Whether that's better or worse than C++'s const depends on what you're trying to do, but the reality of the matter is that D's const is ultimately very different from C++'s const because of how restrictive it is. You get better guarantees but can't use it anywhere near as much precisely because of the restrictions that are required to provide those guarantees. - Jonathan M Davis Thanks for explanation. It makes implementing things like shared_ptr somewhat troublesome when they are supposed to work in const environment. Isn't there a way to escape a pure environment (like trusted for safe)? Or/and would modifying an external state from pure function be an undefined behavior?
mutable keyword
Is there D equivalent of C++'s mutable keyword? Like the one that allows to modify a field of struct from constant method. Or some alternative solution?
Re: Speed up `dub`.
On Sunday, 15 May 2016 at 01:48:41 UTC, cy wrote: dub build --nodeps It's amazing. I tried it, doesn't seem to do anything, maybe something is broken.
Re: Speed up `dub`.
On Sunday, 15 May 2016 at 06:49:00 UTC, Russel Winder wrote: I am not sure about DStep build, but for the two projects I have (using GtkD) build times using Dub were sufficiently long that I switched to SCons and it is OK and allows for a reasonable development rhythm. That SCons looks very nice but don't have time (and dub isn't that bad) to research it more/can't migrate to it. If I have more time I'll certainly try it out.
Re: Speed up `dub`.
On Monday, 7 March 2016 at 21:56:11 UTC, Seb wrote: Use ld.gold - it will speed up your linking quite dramatically! https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html Thanks, it improves things a little. However I've just had idea that it should be possible to implement 'speculative dependency checking' for dub. What I mean by that is to start build process and dependency checking in parallel and then if something changes (with dependencies), apply the changes and restart the build process, and if dependencies are OK continue.
Re: Garbage Collector : Ignoring a reference
Thus, i need a way to tell the gc to ignore the reference ( or something similar ) in that hashmap. So, having pointer that doesn't hold a reference isn't that hard (store it in memory region that is unreachable to gc), but don't you need a way to tell if that pointer ins't dangling, beyond initial problem?
Re: Garbage Collector : Ignoring a reference
On Tuesday, 26 April 2016 at 09:07:59 UTC, Begah wrote: How could i tell the garbage collector to ignore the reference in the hashmap and to free it if there isn't any other reference that in my hashmap? You could always zero the reference in the hashmap, as it won't be valid after reload anyway...
Re: How do you use D to launch/open a window?
On Friday, 22 April 2016 at 21:13:31 UTC, anonymousuer wrote: What code is needed to tell D to open a window? Thank you in advance. Could you specify what kind of window do you need?
Re: Clearing associative array.
On Sunday, 13 March 2016 at 13:42:02 UTC, cym13 wrote: The problem was brought up a few days ago (can't remember where) and it happens to be a documentation mistake: there is a clear() method planned but for a future release (the next one?). That would be great : )
Re: Clearing associative array.
On Saturday, 12 March 2016 at 12:42:04 UTC, Adam D. Ruppe wrote: On Saturday, 12 March 2016 at 12:34:16 UTC, ciechowoj wrote: If above doesn't work how am I supposed to clear the array? `x = string[string].init;` is somewhat ugly. Read the Tip of the Week section here: http://arsdnet.net/this-week-in-d/dec-13.html Short answer: use `= null` to clear the AA. [] doesn't work just because the compiler is a bit stupid about the type you intend it to be, but null works fine. BTW you might want to glance through more of the issues for the tip section too and see if there's more that interest you. Nice article :), thanks. But still, what about clear()? In the documentation https://dlang.org/spec/hash-map.html#properties there is written that associative arrays have clear property.
Clearing associative array.
Could someone explain to me, why following code does not compile?
int main()
{
string[string] x = [ "foo" : "bar" ];
x.clear();
x = [];
return 0;
}
Errors:
main.d(7): Error: no property 'clear' for type 'string[string]'
main.d(8): Error: cannot implicitly convert expression ([]) of
type void[] to string[string]
Failed: ["dmd", "-v", "-o-", "main.d", "-I."]
If above doesn't work how am I supposed to clear the array? `x =
string[string].init;` is somewhat ugly.
dmd --version
DMD64 D Compiler v2.070.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
Re: Speed up `dub`.
dub --version DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016 `dub.json` is `dub.json` of dstep `dub test --skip-registry=all` Do not helps.
Re: Speed up `dub`.
On Monday, 7 March 2016 at 09:22:16 UTC, Daniel Kozak wrote: maybe: dub build --nodeps Dne 7.3.2016 v 10:18 ciechowoj via Digitalmars-d-learn napsal(a): I'm using `dub` to build project. And every time I run `dub` it seems to check if dependencies are up to date, which takes some time. Is there a way to switch of that checking? Or any other way to speed up building process? It really slows down my modify-compile-check iteration time. I've tried that one already - it makes no difference. Currently when I run `dub test` it takes about 9s (project is already built). When running the executable directly takes only 0.2s :/.
Speed up `dub`.
I'm using `dub` to build project. And every time I run `dub` it seems to check if dependencies are up to date, which takes some time. Is there a way to switch of that checking? Or any other way to speed up building process? It really slows down my modify-compile-check iteration time.
Customizing printing of structs (writeln / to!sth behavior).
It there a way to change how writeln converts structs to strings?
I read in the documentation it uses to!string to convert the
struct. Is there a way to overload to!string for my own type?
Let say I have:
struct Point {
int x, y;
}
and I want writeln(Point(3, 4)); to print "[3, 4]" instead of
"Point(3, 4)".
